Na šifrovanie používateľských údajov nepoužívajte prístupové kľúče

Prístupové kľúče sú najzaujímavejším vývojom overovania za posledné roky. Eliminujú phishing, odstraňujú záťaž z hesiel a poskytujú bezproblémové prihlasovanie podporované kryptografiou s verejným kľúčom. Komunitami vývojárov sa však šíri nebezpečná mylná predstava: ak sú prístupové kľúče kryptografické, určite dokážu zašifrovať aj používateľské údaje. Nemôžu – a pokus o ich použitie týmto spôsobom vytvorí krehké, nespoľahlivé systémy, ktoré by mohli vašim používateľom natrvalo zablokovať prístup k ich vlastným informáciám. Pochopenie prečo si vyžaduje jasný pohľad na to, čo sú vlastne prístupové kľúče, aké sú požiadavky na šifrovanie a kde sa tieto dva odlišujú spôsobmi, ktoré sú mimoriadne dôležité pre akúkoľvek platformu, ktorá spracováva citlivé obchodné údaje.

Autentifikácia a šifrovanie sú zásadne odlišné úlohy

Autentifikácia odpovedá na jednu otázku: „Ste tým, za koho sa vydávate?“ Šifrovanie odpovedá na úplne inú otázku: "Môžu tieto údaje zostať nečitateľné pre všetkých okrem oprávnených strán?" Tieto dva problémy majú spoločné kryptografické primitíva, ale technické požiadavky sa výrazne líšia. Autentifikácia sa musí vykonať raz za reláciu, môže tolerovať občasné zlyhanie s elegantnými záložnými chybami a nemusí zakaždým produkovať rovnaký výstup. Šifrovanie vyžaduje deterministický, reprodukovateľný prístup ku kľúčom počas celej životnosti údajov – čo môže byť roky alebo desaťročia.

Keď sa overíte pomocou prístupového kľúča, vaše zariadenie vygeneruje kryptografický podpis, ktorý dokazuje, že vlastníte súkromný kľúč priradený k vášmu účtu. Server overí tento podpis a udelí prístup. Server – ani vaša aplikácia – v žiadnom momente nezíska prístup k samotnému materiálu súkromného kľúča. Toto je funkcia, nie obmedzenie. Celý bezpečnostný model prístupových kľúčov závisí od súkromného kľúča, ktorý nikdy neopustí zabezpečenú enklávu vášho zariadenia. Šifrovanie však vyžaduje, aby ste použili kľúč na transformáciu údajov a neskôr použili rovnaký kľúč (alebo jeho náprotivok) na zvrátenie transformácie. Ak nemáte spoľahlivý prístup ku kľúču, nemôžete spoľahlivo dešifrovať.

Platformy ako Mewayz, ktoré spravujú citlivé obchodné informácie – faktúry, mzdové záznamy, CRM kontakty, HR dokumenty v rámci 207 modulov – potrebujú stratégie šifrovania postavené na kľúčoch, ktoré sú odolné, obnoviteľné a trvalo prístupné. Stavať to na základoch navrhnutých špeciálne na zabránenie prístupu ku kľúčom je architektonický rozpor.

Prečo sa prístupové kľúče bránia použitiu ako šifrovacie kľúče

Špecifikácia WebAuthn, ktorá podporuje prístupové kľúče, bola zámerne navrhnutá s obmedzeniami, ktoré znemožňujú použitie šifrovania. Pochopenie týchto obmedzení odhaľuje, prečo toto nie je priepasť, ktorú môže šikovné inžinierstvo preklenúť – je to základná hranica dizajnu.

• Žiadny export kľúča: Súkromné kľúče vygenerované počas registrácie prístupového kľúča sú uložené v hardvérovo chránených zabezpečených enklávach (TPM, Secure Enclave alebo ekvivalent). Operačný systém a rozhrania API prehliadača neposkytujú žiadny mechanizmus na extrahovanie surového kľúčového materiálu. Môžete požiadať kľúč, aby niečo podpísal, ale nemôžete prečítať samotný kľúč.
• Nedeterministické generovanie kľúča: Vytvorením prístupového kľúča pre toho istého používateľa na inom zariadení sa vytvorí úplne odlišný pár kľúčov. Neexistuje žiadna počiatočná fráza, žiadna cesta odvodenia, žiadny spôsob, ako rekonštruovať rovnaký kľúč na inom zariadení. Každá registrácia je kryptograficky nezávislá.
• Dostupnosť viazaná na zariadenie: Aj pri synchronizácii prístupových kľúčov (iCloud Keychain, Google Password Manager) dostupnosť závisí od zapojenia do ekosystému. Používateľ, ktorý sa zaregistruje na iPhone a neskôr prejde na Android, môže stratiť prístup. Používateľ, ktorého zariadenie bolo stratené, odcudzené alebo obnovené z výroby, čelí rovnakému problému.
• Iba odpoveď na výzvu: WebAuthn API odhaľuje navigator.credentials.get(), ktorý vracia podpísané tvrdenie, nie surový kľúčový materiál. Dostanete podpis cez výzvu poskytnutú serverom – užitočné na preukázanie identity, zbytočné na odvodenie šifrovacieho kľúča.
• Žiadna flexibilita algoritmu: Prístupové kľúče zvyčajne používajú ECDSA s krivkou P-256. Aj keby ste mali prístup ku kľúču, ECDSA je podpisový algoritmus, nie šifrovací algoritmus. Budete potrebovať ďalšie transformácie (dohoda kľúča ECDH, odvodenie KDF), ktoré rozhranie API v tomto kontexte nepodporuje.

Niektorí vývojári navrhli riešenia – napríklad pomocou rozšírenia PRF (Pseudo-Random Function) pre WebAuthn odvodiť symetrické kľúče počas overovania. Aj keď toto rozšírenie existuje v špecifikácii, podpora prehliadača zostáva nekonzistentná, nie je k dispozícii na mnohých mobilných platformách a stále zdedí problém s väzbou na zariadenie. Kľúč odvodený prostredníctvom PRF na jednom zariadení nie je možné reprodukovať na inom zariadení s iným prístupovým kľúčom, a to ani pre rovnaký používateľský účet.

Scenár straty údajov, ktorý nikto nechce dodať

Zvážte, čo sa stane, keď zašifrujete údaje používateľa pomocou kľúča odvodeného z jeho prístupového kľúča. Všetko funguje krásne v prvý deň. Používateľ sa prihlási, odvodí sa kľúč, dáta sa bez problémov zašifrujú a dešifrujú. O tri mesiace neskôr ich telefón spadne do jazera.

Pri tradičnej autentifikácii je strata zariadenia nepríjemná. Používateľ obnoví svoj účet prostredníctvom e-mailu, nastaví nové poverenia a pokračuje v práci. Ale ak boli ich údaje zašifrované kľúčom viazaným na zabezpečenú enklávu teraz ponoreného zariadenia, tieto údaje sú preč. Nie je „ťažké obnoviť“ – kryptograficky nezvratné preč. Žiadny lístok na zákaznícku podporu, žiadny tok obnovenia účtu, žiadna eskalácia výkonnej moci nemôže zvrátiť matematiku. Údaje mohli byť tiež odstránené.

Hlavné pravidlo návrhu šifrovacieho systému: ak má vaša stratégia správy kľúčov akýkoľvek bod zlyhania, ktorý natrvalo zničí prístup k údajom používateľa, nevytvorili ste funkciu zabezpečenia – vytvorili ste mechanizmus straty údajov s ďalšími krokmi.

Pre firmu prevádzkujúcu operácie prostredníctvom platformy – spravovanie 50 klientskych vzťahov v CRM, spracovanie mesačných miezd pre 30 zamestnancov, sledovanie vozového parku – trvalá strata dát z vypadnutého telefónu nie je menší problém UX. Je to katastrofa kontinuity podnikania. To je presne dôvod, prečo architektúra Mewayz oddeľuje autentifikačné mechanizmy od vrstiev ochrany údajov, čím zaisťuje, že žiadne zlyhanie jedného zariadenia nemôže ohroziť prístup k dôležitým obchodným informáciám v rámci ktoréhokoľvek z jeho integrovaných modulov.

Čo by ste mali namiesto toho použiť

Dobrou správou je, že existujú dobre zavedené vzory na šifrovanie používateľských údajov bez toho, aby sa dostali do pasce prístupových kľúčov. Tieto prístupy sú testované v boji, široko podporované a navrhnuté špeciálne pre prípad použitia šifrovania.

Šifrovanie na strane servera pomocou spravovaných kľúčov zostáva najpraktickejšou voľbou pre veľkú väčšinu aplikácií. Vaša platforma šifruje neaktívne údaje pomocou kľúčov spravovaných prostredníctvom správnej služby správy kľúčov (KMS) – AWS KMS, Google Cloud KMS, HashiCorp Vault alebo ekvivalentu. Používateľ sa overí (ak chcete pomocou prístupových kľúčov!) a server transparentne spracuje šifrovanie a dešifrovanie. Takto chráni väčšina platforiem SaaS údaje a funguje to, pretože kľúče sú odolné, zálohované, otočné a nezávislé od zariadenia akéhokoľvek používateľa.

Šifrovacie kľúče odvodené z hesla (používajúce Argon2id alebo scrypt na odvodenie kľúča) sú vhodné, keď potrebujete skutočné šifrovanie s nulovými znalosťami, keď ani server nedokáže prečítať údaje používateľa. Kompromisom je, že strata hesla znamená stratu údajov, ale heslá si možno zapamätať, zapísať a uložiť v manažéroch hesiel – nie sú uzamknuté v hardvérovej enkláve. Služby ako 1Password a Standard Notes využívajú tento prístup efektívne.

1. Na overenie – overenie identity používateľa, použite prístupové kľúče (alebo akúkoľvek silnú metódu).
2. Po overení získajte alebo získajte šifrovacie kľúče prostredníctvom samostatného, účelovo vytvoreného systému správy kľúčov.
3. Implementujte mechanizmy úschovy kľúčov alebo obnovovacích mechanizmov – kľúče na obnovenie, synchronizáciu kľúčov viacerých zariadení alebo úschovu organizačných kľúčov pre firemné účty.
4. Zašifrujte dáta v pokoji a počas prenosu pomocou AES-256-GCM alebo XChaCha20-Poly1305 pomocou kľúčov z vášho KMS.
5. Pravidelne striedajte kľúče a udržujte zašifrované zálohy kľúčov, ktoré prežijú každé zlyhanie.

Toto oddelenie obáv nie je len osvedčeným postupom – je to jediná architektúra, ktorá vám umožňuje inovovať metódy overovania nezávisle od vašej stratégie šifrovania. Keď sa prístupové kľúče nakoniec vyvinú alebo budú nahradené niečím lepším, vaše šifrované údaje zostanú dokonale dostupné.

Rozšírenie PRF: Sľuby a nástrahy

Vývojári, ktorí presne dodržiavajú špecifikáciu WebAuthn, môžu poukázať na rozšírenie prf ako na potenciálny most medzi prístupovými kľúčmi a šifrovaním. Toto rozšírenie umožňuje spoliehajúcej sa strane požiadať o pseudonáhodnú hodnotu odvodenú z tajného materiálu prístupového kľúča počas obradu autentifikácie. Teoreticky by táto hodnota mohla slúžiť ako šifrovací kľúč alebo základ.

V praxi rozšírenie PRF čelí značným prekážkam prijatia. Začiatkom roku 2026 sa podpora medzi prehliadačmi a platformami výrazne líši. Implementácia Safari sa líši od implementácie prehliadača Chrome. Mnoho zariadení so systémom Android to vôbec nepodporuje. Hardvérové ​​bezpečnostné kľúče majú nekonzistentnú podporu. Pre akúkoľvek platformu slúžiacu rôznorodej používateľskej základni – a Mewayz obsluhuje viac ako 138 000 používateľov naprieč všetkými hlavnými operačnými systémami a typmi zariadení – je budovanie šifrovania na funkcii s nepravidelnou dostupnosťou prevádzkovo neudržateľné.

V podstate PRF nerieši problém viacerých zariadení. Pseudonáhodný výstup je odvodený od špecifického prístupového kľúča na konkrétnom zariadení. Používateľ, ktorý zaregistruje prístupové kľúče na svojom notebooku aj telefóne, získa dva rôzne výstupy PRF pre ten istý účet. Budete musieť zašifrovať údaje pomocou odvodeného kľúča jedného zariadenia a potom nejakým spôsobom znova zašifrovať alebo zdieľať tento kľúč s druhým zariadením – čo vás aj tak privedie späť k vytvoreniu správneho systému správy kľúčov. V tomto bode kľúč odvodený od prístupového kľúča zvyšuje zložitosť bez pridania zabezpečenia.

Lekcie pre staviteľov: Použite správny nástroj pre správnu vrstvu

Pokušenie používať prístupové kľúče na šifrovanie pochádza z dobrého inštinktu – vývojári chcú využiť silnú kryptografiu a znížiť počet tajomstiev, ktoré musia používatelia spravovať. Ale bezpečnostné inžinierstvo je v podstate o použití správneho primitíva na správnej vrstve. Zámok aj trezor chránia cennosti, ale do trezoru by ste nenainštalovali závoru ani sa nepokúšali nosiť trezor vo vrecku.

Prístupové kľúče vynikajú svojím navrhnutým účelom. V internom nasadení Google znížili prevzatie účtov súvisiacich s phishingom až o 99,9 %. Úplne eliminujú útoky na vypchávanie poverení. Poskytujú prihlasovacie prostredie, ktoré je zároveň bezpečnejšie a pohodlnejšie ako heslá. To je pozoruhodný úspech a stačí. Žiadať prístupové kľúče, aby riešili aj šifrovanie, je ako žiadať váš firewall, aby slúžil aj ako váš záložný systém – nesprávne to chápe architektúru.

Pri vytváraní platforiem, ktoré zvládajú citlivé obchodné operácie, by architektúra mala odrážať jasné hranice. Autentifikácia overuje identitu. Oprávnenie určuje prístup. Šifrovanie chráni dáta v pokoji a pri prenose. Správa kľúčov zaisťuje, že šifrovacie kľúče prežijú stratu zariadenia, fluktuáciu zamestnancov a zmeny infraštruktúry. Každá vrstva má špeciálne nástroje a ich zmiešanie vytvára krehkosť, ktorá sa objavuje v najhorších možných momentoch – keď používateľ najviac potrebuje prístup k svojim údajom a nemôže.

Získanie bezpečnosti bez prílišnej komplikácie

Pre väčšinu aplikácií SaaS a obchodných platforiem je praktické odporúčanie jednoduché: s nadšením prijmite prístupové kľúče na autentifikáciu a šifrujte výhradne na strane servera pomocou spravovaného KMS. To poskytuje vašim používateľom najlepší možný zážitok z prihlasovania, aký je dnes k dispozícii, a zároveň chráni ich údaje pomocou infraštruktúry navrhnutej špeciálne na trvanlivosť a obnovu.

Ak váš model hrozby skutočne vyžaduje šifrovanie typu end-to-end, kde server nemôže pristupovať k údajom vo formáte obyčajného textu, investujte do správnej architektúry šifrovania na strane klienta s kľúčmi odvodenými z hesla, kódmi na obnovenie a úschovou kľúčov organizácie – nie skratkami odvodenými z prístupového kľúča. Investície do inžinierstva sú väčšie, ale alternatívou je dodanie systému, ktorý nakoniec nenávratne zničí niečie údaje.

Bezpečnostné rozhodnutia sa časom skomplikujú. Skratka prijatá dnes sa o tri roky stane migračnou nočnou morou, keď sa základné primitívne zmeny, ekosystém zariadení zmení svoju politiku synchronizácie alebo prehliadač zavrhne rozšírenie. Stavanie na správnych abstrakciách od začiatku – autentifikácia ako autentifikácia, šifrovanie ako šifrovanie, každý s vlastným životným cyklom kľúča – je základom, ktorý umožňuje platformám škálovať na státisíce používateľov bez tikajúcej časovanej bomby pochovanej v kryptografickom potrubí.

Často kladené otázky

Prečo nemožno na šifrovanie používateľských údajov použiť prístupové kľúče?

Prístupové kľúče sú určené výhradne na overenie, nie na šifrovanie. Na overenie vašej identity počas prihlasovania sa spoliehajú na kryptografiu s verejným kľúčom, ale súkromný kľúč nikdy neopustí vaše zariadenie a nie je prístupný aplikáciám. Šifrovanie vyžaduje stabilné, reprodukovateľné kľúče, ktoré dokážu konzistentne dešifrovať údaje v priebehu času. Prístupové kľúče postrádajú túto schopnosť už od návrhu, čo ich robí zásadne nevhodnými na ochranu uložených používateľských informácií.

Čo sa stane, ak sa napriek tomu pokúsite zašifrovať údaje pomocou prístupových kľúčov?

Riskujete, že vytvoríte krehký systém, v ktorom budú používatelia natrvalo zablokovaní voči svojim vlastným údajom. Prístupové kľúče je možné odvolať, otočiť alebo vymeniť na rôznych zariadeniach bez varovania. Ak sú šifrované údaje viazané na konkrétny prístupový kľúč, ktorý sa odstráni alebo aktualizuje, neexistuje žiadna cesta na obnovenie. To vytvára katastrofický scenár straty údajov, ktorému nemôže spoľahlivo zabrániť žiadne technické riešenie.

Čo by mali vývojári používať namiesto prístupových kľúčov na šifrovanie údajov?

Vývojári by mali používať účelové riešenia šifrovania, ako napríklad AES-256 so správnou správou kľúčov, šifrovanie obálok alebo zavedené knižnice ako libsodium. Ponechajte autentifikáciu a šifrovanie ako samostatné záležitosti. Používajte prístupové kľúče na to, v čom vynikajú – prihlasovanie bez hesla – a vyhradené šifrovacie kľúče spravované prostredníctvom zabezpečených systémov na odvodenie kľúčov a ukladania na ochranu citlivých používateľských údajov.

Ako Mewayz rieši autentifikáciu a bezpečnosť údajov pre firmy?

Mewayz poskytuje 207-modulový obchodný operačný systém od 19 USD/mesiac, ktorý oddeľuje autentifikáciu od ochrany údajov pomocou osvedčených postupov v odvetví. Platforma na adrese app.mewayz.com namiesto zneužívania prístupových kľúčov implementuje správne vrstvy šifrovania spolu so zabezpečenými tokmi prihlasovania, čím zaisťuje, že podniky môžu spoľahlivo chrániť údaje zákazníkov bez toho, aby riskovali scenáre blokovania, ktoré vznikajú pri spájaní overenia so šifrovaním.