Nemojte koristiti pristupne ključeve za šifriranje korisničkih podataka

Zaporke su najuzbudljiviji razvoj autentifikacije u posljednjih nekoliko godina. Oni eliminišu krađu identiteta, uklanjaju teret lozinki i pružaju besprekorno iskustvo prijavljivanja podržano kriptografijom javnog ključa. Ali opasna zabluda se širi zajednicama programera: ako su pristupni ključevi kriptografski, sigurno mogu i šifrirati korisničke podatke. Ne mogu — a pokušaj da ih se koristi na taj način stvorit će krhke, nepouzdane sisteme koji bi vašim korisnicima mogli trajno blokirati njihove vlastite informacije. Razumijevanje zašto zahtijeva jasan pogled na to šta su to pristupni ključevi, šta šifriranje zahtijeva i gdje se to dvoje razilazi na načine koji su od ogromnog značaja za bilo koju platformu koja rukuje osjetljivim poslovnim podacima.

Provjera autentičnosti i šifriranje su fundamentalno različiti poslovi

Provjera autentičnosti odgovara na jedno pitanje: "Jeste li vi ono za šta tvrdite da jeste?" Enkripcija odgovara na potpuno drugačiji odgovor: "Mogu li ovi podaci ostati nečitljivi svima osim ovlaštenim stranama?" Ova dva problema dijele kriptografske primitive, ali inženjerski zahtjevi se oštro razlikuju. Provjera autentičnosti treba da se dogodi jednom po sesiji, može tolerirati povremeni neuspjeh s gracioznim rezervama i ne mora proizvoditi isti izlaz svaki put. Šifriranje zahtijeva deterministički pristup ključu koji se može reproducirati tokom cijelog životnog vijeka podataka — što može trajati godinama ili decenijama.

Kada se autentifikujete pomoću lozinke, vaš uređaj generira kriptografski potpis koji dokazuje da posjedujete privatni ključ povezan s vašim računom. Server potvrđuje ovaj potpis i odobrava pristup. Ni u jednom trenutku server — pa čak ni vaša aplikacija — ne dobija pristup samom materijalu privatnog ključa. Ovo je karakteristika, a ne ograničenje. Cijeli sigurnosni model pristupnih ključeva ovisi o privatnom ključu koji nikada ne napušta sigurnu enklavu vašeg uređaja. Ali šifriranje zahtijeva da koristite ključ za transformaciju podataka, a kasnije koristite taj isti ključ (ili njegov pandan) za poništavanje transformacije. Ako ne možete pouzdano pristupiti ključu, ne možete pouzdano dešifrirati.

Platforme kao što je Mewayz koje upravljaju osjetljivim poslovnim informacijama — fakturama, evidencijama o plaćama, CRM kontaktima, HR dokumentima u 207 modula — trebaju strategije šifriranja izgrađene na ključevima koji su trajni, povratni i dosljedno dostupni. Izgradnja toga na temelju dizajniranom posebno da spriječi pristup ključu je arhitektonska kontradikcija.

Zašto se pristupni ključevi opiru da se koriste kao ključevi za šifriranje

Specifikacija WebAuthn, koja podupire pristupne ključeve, namjerno je dizajnirana s ograničenjima koja čine korištenje enkripcije nepraktičnim. Razumijevanje ovih ograničenja otkriva zašto ovo nije jaz koji pametni inženjering može premostiti – to je osnovna granica dizajna.

• Bez izvoza ključeva: Privatni ključevi generirani tokom registracije lozinke pohranjuju se u hardverski podržanim sigurnim enklavama (TPM, Secure Enclave ili ekvivalent). Operativni sistem i API-ji pretraživača ne pružaju nikakav mehanizam za izdvajanje sirovog ključnog materijala. Možete tražiti da ključ nešto potpiše, ali ne možete pročitati sam ključ.
• Generacija nedeterminističkog ključa: Kreiranje lozinke za istog korisnika na drugom uređaju proizvodi potpuno drugačiji par ključeva. Ne postoji početna fraza, nema putanje derivacije, nema načina da se rekonstruiše isti ključ na drugom uređaju. Svaka registracija je kriptografski nezavisna.
• Dostupnost vezana za uređaj: Čak i sa sinhronizacijom lozinki (iCloud Keychain, Google Password Manager), dostupnost zavisi od učešća ekosistema. Korisnik koji se registruje na iPhone-u i kasnije pređe na Android može izgubiti pristup. Korisnik čiji je uređaj izgubljen, ukraden ili vraćen na fabrička podešavanja suočava se sa istim problemom.
• Samo odgovor na izazov: WebAuthn API izlaže navigator.credentials.get() koji vraća potpisanu tvrdnju, a ne sirovi ključni materijal. Dobijate potpis preko izazova koji vam daje server — korisno za dokazivanje identiteta, beskorisno za izvođenje ključa za šifriranje.
• Bez fleksibilnosti algoritma: pristupni ključevi obično koriste ECDSA sa P-256 krivom. Čak i kada biste mogli pristupiti ključu, ECDSA je algoritam za potpisivanje, a ne algoritam za šifriranje. Trebat će vam dodatne transformacije (ECDH ključ sporazum, KDF derivacija) koje API ne podržava u ovom kontekstu.

Neki programeri su predložili zaobilazna rješenja — korištenje ekstenzije PRF (Pseudo-Random Function) za WebAuthn, na primjer, za izvođenje simetričnih ključeva tokom autentifikacije. Iako ovo proširenje postoji u specifikaciji, podrška pretraživača ostaje nedosljedna, nedostupna je na mnogim mobilnim platformama i još uvijek nasljeđuje problem povezivanja uređaja. Ključ izveden putem PRF-a na jednom uređaju ne može se reproducirati na drugom uređaju s drugim pristupnim ključem, čak ni za isti korisnički račun.

Scenarij gubitka podataka Niko ne želi poslati

Razmotrite šta se dešava kada šifrirate podatke korisnika pomoću ključa izvedenog iz njihove lozinke. Sve radi prelepo prvog dana. Korisnik se prijavljuje, ključ se izvodi, podaci se šifriraju i dešifriraju neprimjetno. Onda tri mjeseca kasnije, njihov telefon pada u jezero.

Uz tradicionalnu autentifikaciju, gubitak uređaja predstavlja neugodnost. Korisnik oporavlja svoj račun putem e-pošte, postavlja nove vjerodajnice i nastavlja s radom. Ali ako su njihovi podaci šifrirani ključem vezanim za sigurnu enklavu uređaja koji je sada potopljen, tih podataka nema. Nije "teško za oporaviti" - nestalo je kriptografski nepovratno. Nema tiketa za korisničku podršku, nema toka oporavka naloga, nikakva izvršna eskalacija ne može preokrenuti matematiku. Podaci su mogli biti i izbrisani.

Kardinalno pravilo dizajna sistema šifriranja: ako vaša strategija upravljanja ključevima ima bilo koju tačku kvara koja trajno uništava pristup korisničkim podacima, niste izgradili sigurnosnu funkciju – izgradili ste mehanizam za gubitak podataka s dodatnim koracima.

Za posao koji vodi operacije preko platforme — upravljanje 50 odnosa sa klijentima u CRM-u, obrada mjesečnog platnog spiska za 30 zaposlenika, praćenje voznog parka — trajni gubitak podataka iz ispuštenog telefona nije manji UX problem. To je katastrofa kontinuiteta poslovanja. Upravo zbog toga Mewayzova arhitektura odvaja mehanizme provjere autentičnosti od slojeva zaštite podataka, osiguravajući da nijedan kvar na jednom uređaju ne može ugroziti pristup kritičnim poslovnim informacijama kroz bilo koji od njegovih integriranih modula.

Šta biste trebali koristiti umjesto toga

Dobra vijest je da postoje dobro uspostavljeni obrasci za šifriranje korisničkih podataka bez upadanja u zamku s pristupnim ključevima. Ovi pristupi su testirani u borbi, široko podržani i dizajnirani posebno za slučaj upotrebe šifriranja.

Šifrovanje na strani servera sa upravljanim ključevima ostaje najpraktičniji izbor za veliku većinu aplikacija. Vaša platforma šifrira podatke u mirovanju koristeći ključeve kojima se upravlja putem odgovarajuće usluge upravljanja ključevima (KMS) — AWS KMS, Google Cloud KMS, HashiCorp Vault ili ekvivalentno. Korisnik se autentifikuje (sa pristupnim ključevima, ako želite!), a server transparentno rukuje šifriranjem i dešifriranjem. Ovako većina SaaS platformi štiti podatke, a to funkcionira jer su ključevi izdržljivi, sigurnosno kopirani, rotirajući i neovisni o uređaju bilo kojeg korisnika.

Ključevi za šifriranje izvedeni iz lozinke (koristeći Argon2id ili scrypt za izvođenje ključa) su prikladni kada vam je potrebna istinska enkripcija bez znanja gdje čak ni server ne može čitati korisničke podatke. Kompromis je u tome što gubitak lozinke znači gubitak podataka, ali lozinke se mogu zapamtiti, zapisati i uskladištiti u menadžerima lozinki – nisu zaključane unutar hardverske enklave. Usluge kao što su 1Password i Standard Notes efikasno koriste ovaj pristup.

1. Koristite pristupne ključeve (ili bilo koju jaku metodu) za autentifikaciju — provjeru identiteta korisnika.
2. Nakon autentifikacije, izvedite ili preuzmite ključeve za šifriranje putem zasebnog, namjenski izgrađenog sistema za upravljanje ključevima.
3. Implementirajte ključeve deponovanja ili mehanizme oporavka — ključeve za oporavak, sinhronizaciju ključeva na više uređaja ili čuvanje organizacijskih ključeva za poslovne račune.
4. Šifrirajte podatke u mirovanju i u prijenosu pomoću AES-256-GCM ili XChaCha20-Poly1305 ključevima iz vašeg KMS-a.
5. Periodično rotirajte ključeve i održavajte šifrirane sigurnosne kopije ključeva koje prežive bilo koju tačku kvara.

Ovo razdvajanje briga nije samo najbolja praksa – to je jedina arhitektura koja vam omogućava da nadogradite metode provjere autentičnosti neovisno o vašoj strategiji šifriranja. Kada se pristupni ključevi na kraju razviju ili budu zamijenjeni nečim boljim, vaši šifrirani podaci ostaju savršeno dostupni.

PRF ekstenzija: obećanje i zamke

Programeri koji pažljivo prate WebAuthn specifikaciju mogu ukazati na ekstenziju prf kao potencijalni most između pristupnih ključeva i enkripcije. Ovo proširenje omogućava pouzdanoj strani da zatraži pseudo-slučajnu vrijednost izvedenu iz tajnog materijala lozinke tokom ceremonije provjere autentičnosti. U teoriji, ova vrijednost može poslužiti kao ključ za šifriranje ili seme.

U praksi, proširenje PRF se suočava sa značajnim preprekama za usvajanje. Od početka 2026. podrška se dramatično razlikuje od pretraživača i platformi. Safarijeva implementacija se razlikuje od Chromeove. Mnogi Android uređaji to uopće ne podržavaju. Hardverski sigurnosni ključevi imaju nedosljednu podršku. Za bilo koju platformu koja opslužuje raznoliku korisničku bazu — a Mewayz opslužuje više od 138.000 korisnika na svim glavnim operativnim sistemima i tipovima uređaja — izgradnja enkripcije na funkciji sa promjenjivom dostupnošću je operativno neodrživa.

U osnovi, PRF ne rješava problem više uređaja. Pseudo-slučajni izlaz se izvodi iz specifične lozinke na određenom uređaju. Korisnik koji registruje pristupne ključeve i na svom laptopu i na telefonu dobija dva različita PRF izlaza za isti nalog. Trebali biste šifrirati podatke pomoću izvedenog ključa jednog uređaja, a zatim nekako ponovo šifrirati ili podijeliti taj ključ s drugim uređajem — što vas ionako dovodi do pravljenja odgovarajućeg sistema za upravljanje ključevima. U tom trenutku, ključ izveden iz lozinke dodaje složenost bez dodavanja sigurnosti.

Lekcije za graditelje: Koristite pravi alat za pravi sloj

Iskušenje da se koriste pristupni ključevi za enkripciju dolazi iz dobrog instinkta — programeri žele iskoristiti jaku kriptografiju i smanjiti broj tajni kojima korisnici trebaju upravljati. Ali sigurnosni inženjering je u osnovi korištenje pravog primitivnog elementa na pravom sloju. Brava i sef štite dragocjenosti, ali ne biste ugradili zasun u trezor ili pokušali nositi sef u džepu.

Lozinke su izvrsne u svojoj namjeni. Smanjili su preuzimanja računa vezana za phishing do 99,9% u Googleovoj internoj implementaciji. Oni u potpunosti eliminišu napade punjenja vjerodajnica. Oni pružaju iskustvo prijave koje je istovremeno sigurnije i praktičnije od lozinki. To je izvanredno dostignuće, i dovoljno je. Tražiti pristupne ključeve da također riješe enkripciju je isto kao da tražite od vašeg zaštitnog zida da vam služi i kao rezervni sistem – to pogrešno razumije arhitekturu.

Kada gradite platforme koje upravljaju osjetljivim poslovnim operacijama, arhitektura bi trebala odražavati jasne granice. Autentifikacija potvrđuje identitet. Autorizacija određuje pristup. Šifriranje štiti podatke u mirovanju i u prijenosu. Upravljanje ključevima osigurava da ključevi za enkripciju prežive gubitak uređaja, fluktuaciju zaposlenih i promjene infrastrukture. Svaki sloj ima namjenski izrađene alate, a njihovo miješanje stvara krhkost koja se pojavljuje u najgorim mogućim trenucima — kada korisnik najviše treba da pristupi svojim podacima, a ne može.

Ispraviti sigurnost bez pretjeranog kompliciranja

Za većinu SaaS aplikacija i poslovnih platformi, praktična preporuka je jasna: usvojite pristupne ključeve s entuzijazmom za autentifikaciju i upravljajte enkripcijom u potpunosti na strani servera pomoću upravljanog KMS-a. Ovo vašim korisnicima pruža najbolje iskustvo prijave koje je dostupno danas, a istovremeno štiti njihove podatke infrastrukturom dizajniranom posebno za trajnost i oporavak.

Ako vaš model prijetnji zaista zahtijeva end-to-end enkripciju gdje server ne može pristupiti podacima otvorenog teksta, investirajte u odgovarajuću arhitekturu šifriranja na strani klijenta s ključevima izvedenim lozinkom, kodovima za oporavak i deponiranjem organizacijskog ključa – a ne prečicama izvedenim iz lozinke. Investicija u inženjering je veća, ali alternativa je isporuka sistema koji će na kraju nepovratno uništiti nečije podatke.

Sigurnosne odluke se vremenom pogoršavaju. Prečica koja se koristi danas postaje noćna mora migracije za tri godine kada se osnovni primitiv promijeni, ekosistem uređaja promijeni svoju politiku sinhronizacije ili pretraživač zakine ekstenziju. Izgradnja pravih apstrakcija od samog početka — autentifikacija kao autentikacija, enkripcija kao enkripcija, svaki sa svojim životnim ciklusom ključa — temelj je koji omogućava platformama da se prošire na stotine hiljada korisnika bez tempirane bombe zakopane u kriptografskim kanalima.

Često postavljana pitanja

Zašto se pristupni ključevi ne mogu koristiti za šifriranje korisničkih podataka?

Zaporke su dizajnirane isključivo za autentifikaciju, a ne šifriranje. Oni se oslanjaju na kriptografiju javnog ključa za provjeru vašeg identiteta tokom prijave, ali privatni ključ nikada ne napušta vaš uređaj i nije dostupan aplikacijama. Šifriranje zahtijeva stabilne, reproducibilne ključeve koji mogu konzistentno dešifrirati podatke tokom vremena. Pristupnim ključevima nedostaje ova mogućnost po dizajnu, što ih čini suštinski neprikladnim za zaštitu pohranjenih korisničkih informacija.

Šta se događa ako ipak pokušate šifrirati podatke pomoću pristupnih ključeva?

Rizikujete da izgradite krhki sistem u kojem korisnici trajno ostaju bez vlastitih podataka. Ključevi se mogu opozvati, rotirati ili zamijeniti na različitim uređajima bez upozorenja. Ako su šifrirani podaci vezani za određeni pristupni ključ koji se briše ili ažurira, nema putanje za oporavak. Ovo stvara katastrofalan scenario gubitka podataka koji nikakvo inženjersko rješenje ne može pouzdano spriječiti.

Šta bi programeri trebali koristiti umjesto pristupnih ključeva za šifriranje podataka?

Programeri bi trebali koristiti namjenski izrađena rješenja za šifriranje kao što je AES-256 s odgovarajućim upravljanjem ključevima, enkripcijom omotača ili uspostavljenim bibliotekama kao što je libsodium. Zadržite autentifikaciju i šifriranje kao zasebne brige. Koristite pristupne ključeve za ono u čemu su izvrsni — prijavu bez lozinke — i namjenske ključeve za šifriranje kojima se upravlja putem sigurnih sistema za izvođenje ključeva i skladištenja za zaštitu osjetljivih korisničkih podataka.

Kako Mewayz upravlja autentifikacijom i sigurnošću podataka za preduzeća?

Mewayz nudi poslovni OS sa 207 modula počevši od 19 USD mjesečno koji odvaja autentifikaciju od zaštite podataka koristeći najbolju praksu u industriji. Umjesto da zloupotrebljava pristupne ključeve, platforma na app.mewayz.com implementira odgovarajuće slojeve enkripcije uz sigurne tokove prijavljivanja, osiguravajući da preduzeća mogu pouzdano zaštititi korisničke podatke bez rizika od scenarija zaključavanja koji proizlaze iz spajanja autentifikacije s enkripcijom.