A titkosítás illúziója
2022 decemberében a LastPass bejelentett egy adatszivárgást. A hivatalos közlemény megnyugtató hangvételű volt: a felhasználói jelszavak „titkosítva” vannak. A tárolóadatok „biztonságban” vannak.
2025-re a LastPass felhasználóinak több mint 438 millió dollárját lopták el – egyenesen az állítólag titkosított tárolókból.
Hogyan? A LastPass tartotta a kulcsokat.
Ezt az alapvető különbséget minden vállalati biztonsági csapatnak meg kell értenie, mielőtt bármilyen felhőalapú, érzékeny adatokat – köztük személyes adatokat – kezelő eszközt választ.
Szerver oldali titkosítás vs. zero-knowledge architektúra
A legtöbb felhős eszköz, amely azt állítja, hogy „titkosítja adatait”, szerver oldali titkosítást (SSE) használ. Ezt jelenti valójában:
| Tulajdonság | Szerver oldali titkosítás | Zero-knowledge architektúra |
|---|---|---|
| Hol történik a titkosítás | A szállító szerverén | Az Ön eszközén (böngésző/asztali alkalmazás) |
| Ki tartja a kulcsokat | A szállító | Csak Ön |
| A szállító olvashatja az adatait | Igen | Nem |
| Szerver feltörése adatot tesz közzé | Igen | Nem (csak titkosszöveg) |
| A szállítótól hatósági végzéssel adatot lehet kérni | Igen | Nem (nincs náluk) |
| Hatóságok/rendészet hozzáférése | A szállítón keresztül | Nem lehetséges az Ön kulcsa nélkül |
A LastPass szerver oldali titkosítást alkalmazott általa kontrollált kulcsokkal. Amikor a támadók feltörték az infrastruktúrát, megszerezték mind a titkosszöveget, mind a visszafejtési lehetőséget – alkalmazottak megtévesztésével, gyenge mesterjelszavak feltörésével és régebbi fiókokra vonatkozó metaadatok kihasználásával.
Miért számít ez a GDPR 25. cikkéhez?
A GDPR 25. cikke (beépített adatvédelem) előírja, hogy az adatkezelők „megfelelő technikai és szervezési intézkedéseket” alkalmazzanak, amelyek beépítik az adatvédelmet a feldolgozásba „alapértelmezés és tervezés szerint”.
Az Európai Adatvédelmi Testület (EDPB) pontosította, hogy ez magában foglalja a kriptográfiai adatminimalizálást – vagyis az architektúrának magának kell az adatokat elérhetetlenné tennie jogosulatlan felek számára, nem csak hozzáférés-vezérlők útján.
Egy olyan szállító, aki tartja az Ön titkosítási kulcsait, a legszigorúbb értelmezés szerint nem tud eleget tenni a 25. cikknek, mert:
- Az infrastruktúra sikeres feltörése közzéteheti az Ön adatait
- A szállítónak kézbesített bírósági végzés kiadhatja az Ön adatait
- A szállító egy rosszindulatú alkalmazottja hozzáférhet az Ön adataihoz
- A szállító kulcskezelési szolgáltatásának ellátási lánc feltörése adatot tehet közzé
A Szövetségi Adatvédelmi Biztos (BfDI) és az osztrák Datenschutzbehörde egyaránt útmutatást adott ki arról, hogy a zero-knowledge architektúra az előnyben részesített technikai megvalósítás a nagy kockázatú adatkezelésnél.
A SaaS-szivárgások valósága
Az AppOmni / Cloud Security Alliance 2024-es jelentése 300%-os növekedést dokumentált a SaaS-szivárgásokban 2022 és 2024 között. A támadások egyre kifinomultabbak:
- Átlagos feltörési idő: 9 perc (órákról csökkent)
- Harmadik fél részvétele a szivárgásokban: évente megduplázódott (Verizon DBIR 2025)
- Conduent-szivárgás: 25,9 millió rekord közzétéve (TB-számok, egészségbiztosítási adatok)
- NHS-szállítói szivárgás: 9 millió beteg adatai kerültek ki
Ebben a fenyegetési környezetben az architektúrális garanciák felváltották a szabályzati ígéreteket mint minimálisan elfogadható szabvánnyá a nagy kockázatú adatkezelésnél.
Hogyan néz ki a valódi zero-knowledge architektúra?
Egy valódi zero-knowledge architektúrának ezek az ellenőrizhető tulajdonságai vannak:
1. Kliens oldali kulcslevezetés A titkosítási kulcs az Ön jelszavából memóriaigényes KDF-fel (Argon2id, bcrypt vagy scrypt) az Ön eszközén kerül levezetésre. A levezetett kulcs soha nem hagyja el az eszközét.
2. Kliens oldali titkosítás Az adat titkosítva kerül el az Ön böngészőjéből vagy asztali alkalmazásából. A szerver csak titkosszöveget kap – kulcs nélkül értelmetlen.
3. Nincs szerver oldali kulcstárolás A szállító nem tárol kulcsokat, kulcstöredékeket vagy kulcsbiztonsági mentéseket. A helyreállítás felhasználó által kontrollált helyreállítási mondattal történik.
4. Kriptográfiai ellenőrizhetőség Az architektúrának dokumentálhatónak és auditálhatónak kell lennie – ideálisan nyitottnak külső felülvizsgálatra. A technikai részletek nélküli homályos „végponttól végpontig titkosítás” állításokat szkepticizmussal kell kezelni.
Hogyan valósítja meg az anonym.legal a zero-knowledge architektúrát?
Az anonym.legal zero-knowledge hitelesítése a következőket alkalmazza:
- Argon2id kulcslevezetés: 64 MB memória, 3 iteráció – az OWASP által ajánlott paraméterek nagy biztonságú alkalmazásokhoz
- AES-256-GCM titkosítás: A tárolt titkosítási kulcsokat és az asztali alkalmazás helyi tárolóját védi – nem az anonimizálásra küldött szöveget, amelyet az anonym.legal EU-ban üzemeltetett API-ja dolgoz fel
- 24 szavas BIP39 helyreállítási mondat: Az egyetlen helyreállítási mód – az anonym.legal nem tárolja
- Zero-knowledge bejelentkezés: a jelszava soha nem kerül az anonym.legal szervereire; a mentett titkosítási kulcsok titkosítva (AES-256-GCM) vannak tárolva, de nem zero-knowledge módon Fontos pontosan meghatározni, mire vonatkozik ez: a zero-knowledge a bejelentkezésre vonatkozik. A mentett titkosítási kulcsokat az anonym.legal szerverei Németországban titkosítva tárolják, és a szerverek képesek visszafejteni azokat, hogy visszaadják az alkalmazásainak.
A szállítóértékelési ellenőrzőlista
Bármilyen érzékeny adatokat kezelő felhős eszköz értékelésekor tegye fel ezeket a kérdéseket:
Architektúrális kérdések:
- Hol történik a titkosítás/visszafejtés – az Ön eszközén vagy a szállító szerverén?
- Ki generálja a titkosítási kulcsokat?
- Hol tárolják a titkosítási kulcsokat?
- A szállító bírósági végzésre ki tudja-e adni az Ön adatainak nyílt szöveges másolatát?
- Mi történik az Ön adataival, ha a szállítót felvásárolják?
Szivárgásállósági kérdések:
- Ha a szállító teljes infrastruktúráját feltörik, milyen adatok kerülnek ki?
- Ha egy szállítói alkalmazott rosszindulatúan jár el, milyen adatokhoz férhet hozzá?
- Ha egy ellátási lánc támadás kompromittálja a szállító infrastruktúráját, mi kerül ki?
Szabályozási kérdések:
- Tud a szállító GDPR 25. cikkét kielégítő dokumentációt biztosítani?
- Átvizsgálta-e független biztonsági auditor az architektúrát?
- Van-e ISO 27001 vagy SOC 2 tanúsítás, amely lefedi a titkosítás megvalósítását?
Bármely szállító, aki a szivárgásállósági kérdésekre nem tudja egyértelműen azt válaszolni, hogy „semmi – adatai titkosítva vannak, mielőtt elhagyják az eszközét”, szerver oldali titkosítást alkalmaz.
Felhasználási eset: Német egészségbiztosító átvilágítása
Egy jelentős német egészségbiztosító (Krankenkasse) megfelelőségi tisztviselőjének felhőalapú anonimizáló eszközre volt szüksége a biztosítottak panaszainak feldolgozásához. Az adatvédelmi tisztviselő ellenőrzőlistája tartalmazta:
- A szállító nem férhet hozzá a biztosítotti adatokhoz
- Nincs adatfeldolgozás Németországon kívüli infrastruktúrán
- GDPR 32. cikk szerinti technikai intézkedések dokumentálva
- Minimalizált adatvédelmi hatóságnak bejelentendő szivárgási kockázat
Egy vezető amerikai anonimizáló SaaS megbukott az első kritériumnál: a támogatási csapat vissza tudta állítani a felhasználói tárolókat, ami szerver oldali kulcshozzáférésre utal. Egy második eszköz 30 napig tárolta a feldolgozott szöveget „auditnaplózási célokra” – megint csak szerver oldali hozzáféréssel.
Az anonym.legal zero-knowledge architektúrája mind a négy kritériumnak megfelelt. Az adatvédelmi tisztviselő dokumentálhatta: „Még egy teljes szállítói infrastruktúra feltörés esetén sem kerülnek ki használható biztosítotti adatok – a titkosítási kulcsok csak a mi munkaállomásainkon léteznek.” A GDPR 32. cikk dokumentálása négy óra alatt elkészült.
Az ICO végrehajtási precedens
2025 decemberében az Egyesült Királyság Információs Biztosa 1,2 millió fonttal bírságolta meg a LastPass brit egységét „a megfelelő technikai és szervezési biztonsági intézkedések elmulasztása” miatt.
A bírság nem magáért a szivárgásért szabták ki – hanem azokért az architektúrális döntésekért, amelyek katasztrofálissá tették: az elégtelen KDF-iterációk a régebbi fiókoknál, a metaadatok kitettség, és a kulcsok szerver oldali tárolásának alapvető döntése.
A szabályozók mostantól nem csak azt értékelik, hogy történt-e szivárgás, hanem azt is, hogy az architektúra minimalizálta-e a szivárgás hatását. A zero-knowledge architektúra a legvilágosabb technikai demonstráció erre az szándékra.
Mikor nem megfelelő a zero-knowledge architektúra?
A zero-knowledge titkosítás kompromisszumokat vezet be, amelyek egyes felhasználási esetekben számítanak:
Helyreállítási összetettség: Ha a felhasználók elveszítik titkosítási kulcsaikat, az adatok örökre elérhetetlenek. A hagyományos felhőtárolással ellentétben, ahol a rendszergazdák visszaállíthatják a hozzáférést, nincs hátsó ajtós helyreállítási útvonal. Nagy felhasználói forgalmú vagy rossz kulcskezelési gyakorlatú szervezetek problémásnak találhatják ezt.
Együttműködési súrlódás: A titkosított adatokat csak akkor lehet megosztani, ha a címzett rendelkezik a megfelelő visszafejtési képességgel. Ez extra lépéseket jelent a normál felhőszolgáltatások egyszerű linkosztásához képest.
Szabályozási szélső esetek: Egyes joghatóságok bírósági végzés alapján rendészeti hozzáférést írnak elő az adatokhoz. A zero-knowledge architektúrák ezt tervezésnél fogva megakadályozzák – ami jogi kitettséget okozhat bizonyos iparágakban (pénzügyi szolgáltatások, telekommunikáció).
Számítási többletteher: A kliens oldali Argon2id kulcslevezetés és az AES-256-GCM titkosítás késleltetést okoz, ami nagyléptékű valós idejű feldolgozási forgatókönyveknél számít.
A naponta több millió dokumentumot feldolgozó csapatoknál egy hibrid megközelítés jobban működhet. Csak a legérzékenyebb mezőket titkosítsa, a metaadatokat hagyja nyitva.
Következtetés
„Titkosítjuk az Ön adatait” nem biztonsági garancia – ez egy marketing állítás, amely vizsgálatot igényel.
A lényeges kérdések: ki tartja a kulcsokat, hol történik a titkosítás, és mi kerül ki, ha a szállító infrastruktúráját feltörik?
GDPR, HIPAA vagy bármely hasonló keretrendszer alatt érzékeny adatokat feldolgozó szervezetek számára ezekre a kérdésekre adott architektúrális válasz határozza meg mind a szabályozási kitettséget, mind a tényleges szivárgási kockázatot.
A LastPass titkosította felhasználói adatait. A zero-knowledge architektúra a 2022-es szivárgást eseménytelen epizóddá tette volna. A felhasználóktól ellopott 438 millió dollár az architektúrális rövidítés ára.
Az anonym.legal a bejelentkezésre alkalmazza a zero-knowledge elvet: az Argon2id kulcslevezetés az Ön böngészőjében vagy asztali alkalmazásában fut, így a jelszava soha nem hagyja el az eszközét, az anonimizálásra küldött szöveget az anonym.legal EU-ban üzemeltetett API-ja dolgozza fel (Hetzner, Falkenstein), és a mentett titkosítási kulcsokat az anonym.legal szerverei titkosítva tárolják, és a szerverek képesek visszafejteni azokat, hogy visszaadják az alkalmazásainak.
Források: