Salauksen harha
Joulukuussa 2022 LastPass ilmoitti tietomurrosta. Virallisessa lausunnossa käytettiin rauhoittavaa kieltä: käyttäjien salasanat olivat "salattu". Holvidata oli "suojattu".
Vuoteen 2025 mennessä LastPass-käyttäjiltä oli varastettu yli 438 miljoonaa dollaria – suoraan heidän oletetusti salattuihin holveistaan.
Miten? LastPass piti avaimet.
Tämä on kriittinen ero, jonka jokaisen yritystietoturvan tiimin on ymmärrettävä ennen minkään pilvipalvelun valintaa, joka käsittelee arkaluonteista dataa – mukaan lukien PII-anonymisointialustat.
Palvelinpuolinen salaus vs. zero-knowledge-arkkitehtuuri
Useimmat pilvipalvelut, jotka väittävät "salaavansa datasi", käyttävät palvelinpuolista salausta (SSE). Mitä se todella tarkoittaa:
| Ominaisuus | Palvelinpuolinen salaus | Zero-knowledge-arkkitehtuuri |
|---|---|---|
| Missä salaus tapahtuu | Toimittajan palvelimella | Laitteellasi (selain/työpöytä) |
| Kuka pitää avaimet | Toimittaja | Vain sinä |
| Toimittaja voi lukea datasi | Kyllä | Ei |
| Palvelimen tietomurto paljastaa datan | Kyllä | Ei (vain salateksti) |
| Toimittaja voidaan pakottaa luovuttamaan data | Kyllä | Ei (heillä ei ole sitä) |
| Viranomaisten/poliisin pääsy | Toimittajan kautta | Ei mahdollista ilman avaintasi |
LastPass käytti palvelinpuolista salausta avaimilla, joita he hallitsivat. Kun hyökkääjät tunkeutuivat heidän infrastruktuuriinsa, he saivat sekä salatekstin että keinot purkaa se – hyödyntämällä sosiaalista manipulointia, murtamalla heikkoja pääsalasanoja ja hyväksikäyttämällä vanhempien tilien metatietoja.
Miksi tämä on tärkeää GDPR:n artiklan 25 kannalta
GDPR:n artikla 25 (tietosuoja suunnitteluvaiheessa) vaatii, että rekisterinpitäjät toteuttavat "asianmukaiset tekniset ja organisatoriset toimenpiteet", jotka integroivat tietosuojan käsittelyyn "suunnittelun ja oletusasetuksen kautta".
Euroopan tietosuojaneuvosto (EDPB) on selventänyt, että tähän kuuluu kryptografinen tietojen minimointi – arkkitehtuurin itsessään pitäisi tehdä data luvattomille osapuolille saavuttamattomaksi, ei vain suojata pääsyvalvonnalla.
Toimittaja, joka pitää salausavaimiasi, ei pysty täyttämään artiklaa 25 tiukimmassa tulkinnassa, koska:
- Onnistunut hyökkäys heidän infrastruktuuriinsa voisi paljastaa datasi
- Toimittajalle kohdistettu oikeudellinen haaste voisi tuottaa datasi
- Toimittajan väärinkäyttöä tekevä henkilökunnan jäsen voisi päästä dataasi käsiksi
- Toimitusketjun kompromissi avaintenhallinnan osalta voisi paljastaa datasi
Saksan liittovaltion tietosuojavaltuutettu (BfDI) ja Itävallan Datenschutzbehörde ovat molemmat antaneet ohjeistuksen, jonka mukaan zero-knowledge-arkkitehtuuri on suositeltu tekninen toteutus korkean riskin käsittelylle.
SaaS-tietomurtojen todellisuustarkistus
AppOmnin / Cloud Security Alliancen 2024-raportti dokumentoi 300 %:n kasvun SaaS-tietomurroissa vuodesta 2022 vuoteen 2024. Hyökkäysten kehittyneisyys on kasvanut dramaattisesti:
- Keskimääräinen tietomurtoon kuluva aika: 9 minuuttia (tuntien sijaan aiemmin)
- Kolmansien osapuolien osallisuus tietomurroissa: kaksinkertaistunut vuositasolla (Verizon DBIR 2025)
- Conduentinin tietomurto: 25,9 miljoonaa tietuetta paljastui (sosiaaliturvatunnukset, sairausvakuutusdata)
- NHS:n toimittajan tietomurto: 9 miljoonaa potilasta paljastui
Tässä uhkaympäristössä arkkitehtuuriset takuut ovat korvanneet poliittiset lupaukset minimivaatimuksena korkean riskin datan käsittelylle.
Miltä aito zero-knowledge-arkkitehtuuri näyttää?
Aidolla zero-knowledge-arkkitehtuurilla on nämä todennettavat ominaisuudet:
1. Asiakaspuolinen avainjohtaminen Salausavain johdetaan salasanastasi muistiintensiivistä KDF:ää (Argon2id, bcrypt tai scrypt) käyttäen laitteellasi. Johdettu avain ei koskaan poistu laitteeltasi.
2. Asiakaspuolinen salaus Data salataan ennen kuin se poistuu selaimestasi tai työpöytäsovelluksestasi. Palvelin vastaanottaa vain salatekstin – merkityksettömän ilman avainta.
3. Ei palvelinpuolista avainvarastoa Toimittaja ei tallenna avaimia, avainpaloja eikä avainvarmuuskopioita. Palautus tapahtuu käyttäjän hallitseman palautuslauseen kautta.
4. Kryptografinen todennettavuus Arkkitehtuurin tulisi olla dokumentoitavissa ja tarkastettavissa – mieluiten avoimen ulkoisen tarkastelun kohteena. Epämääräisiä "end-to-end-salaus"-väitteitä ilman teknisiä yksityiskohtia tulisi kohdella skeptisesti.
Miten anonym.legal toteuttaa zero-knowledgen
anonym.legalin zero-knowledge-todennus käyttää:
- Argon2id-avainjohtaminen: 64 Mt muistia, 3 iteraatiota – OWASP:n suosittelemia parametreja korkean turvallisuuden sovelluksille
- AES-256-GCM-salaus: Sovelletaan kokonaan selaimessa/työpöydällä ennen datan lähettämistä
- 24-sanan BIP39-palautuslause: Ainoa tapa palauttaa pääsy – anonym.legal ei tallenna sitä
- Nolla palvelinpuolista avainpääsyä: anonym.legal-palvelimet vastaanottavat vain AES-256-GCM-salatekstin ilman avaimia sen purkamiseen
Täydellinen anonym.legal-palvelinrikko tuottaisi salattuja blobeja, joita ei voida purkaa ilman kunkin käyttäjän johdettua avainta – joka on olemassa vain heidän laitteellaan.
Toimittajan arviointitarkistuslista
Arvioitaessa mitä tahansa pilvipalvelua, joka käsittelee arkaluonteista dataa, kysy nämä kysymykset:
Arkkitehtuurikysymykset:
- Missä salaus/purkaminen tapahtuu – laitteellasi vai toimittajan palvelimella?
- Kuka luo salausavaimet?
- Missä salausavaimia säilytetään?
- Voiko toimittaja tuottaa selkokieliset kopiot datastasi haasteen vastauksena?
- Mitä datastallesi tapahtuu, jos toimittaja ostetaan?
Tietomurtosietokysymykset:
- Jos toimittajan koko infrastruktuuri vaarantuu, mitä dataa paljastuu?
- Jos toimittajan henkilökunnan jäsen tekee väärinkäytöksiä, mihin dataan hän pääsee?
- Jos toimitusketjuhyökkäys vaarantaa toimittajan infrastruktuurin, mitä paljastuu?
Sääntelykysymykset:
- Voiko toimittaja tuottaa GDPR:n artiklaa 25 täyttävän dokumentaation?
- Onko arkkitehtuuri tarkastettu riippumattoman tietoturva-auditoijan toimesta?
- Onko olemassa ISO 27001- tai SOC 2 -sertifikaatti, joka kattaa salauksen toteutuksen?
Mikä tahansa toimittaja, joka ei pysty selkeästi vastaamaan "nolla – datasi on salattu ennen kuin se poistuu laitteeltasi" tietomurtosietokysymyksiin, luottaa palvelinpuoliseen salaukseen.
Käyttötapaus: saksalaisen sairausvakuuttajan due diligence
Suuren saksalaisen sairausvakuuttajan (Krankenkasse) vaatimustenmukaisuuspäällikkö tarvitsi pilvi-anonymisointityökalun vakuutetujen valituslokien käsittelyyn. Tietosuojavastaavan tarkistuslista sisälsi:
- Toimittaja ei voi päästä vakuutettujen dataan
- Ei datan käsittelyä Saksan ulkopuolisessa infrastruktuurissa
- GDPR:n artiklan 32 tekniset toimenpiteet dokumentoitu
- DPA-ilmoitettava rikkomusriski minimoidaan
Johtava yhdysvaltalainen anonymisointi-SaaS epäonnistui ensimmäisessä kriteerissä: heidän tukitiiminsä pystyi nollaamaan käyttäjäholvit, mikä viittasi palvelinpuoliseen avainpääsyyn. Toinen työkalu tallensi käsiteltyä tekstiä 30 päivän ajan "tilintarkastusketjua varten" – jälleen palvelinpuolinen pääsy.
anonym.legalin zero-knowledge-arkkitehtuuri täytti kaikki neljä kriteeriä. Tietosuojavastaava pystyi dokumentoimaan: "Jopa täydellinen toimittajan infrastruktuurin kompromissi ei tuota käyttökelpoista vakuutettujen dataa – salausavaimet ovat olemassa vain työasemillamme." GDPR:n artiklan 32 dokumentaatio valmistui neljässä tunnissa.
ICO:n täytäntöönpanoennakkotapaus
Joulukuussa 2025 Yhdistyneen kuningaskunnan tietosuojavaltuutettu (ICO) sakotti LastPassin Yhdistyneen kuningaskunnan yksikköä 1,2 miljoonalla punnalla "asianmukaisten teknisten ja organisatoristen turvatoimenpiteiden toteuttamatta jättämisestä".
Sakkoa ei määrätty itse rikkomuksesta – vaan arkkitehtuuripäätöksistä, jotka tekivät rikkomuksesta katastrofaalisen: riittämättömät KDF-iteraatiot vanhemmille tileille, metatietojen altistuminen ja perustavanlaatuinen valinta pitää avaimia palvelinpuolella.
Viranomaiset arvoivat nyt paitsi sitä, tapahtuiko rikkomus, myös sitä, minimoiko arkkitehtuuri rikkomuksen vaikutukset. Zero-knowledge-arkkitehtuuri on selkein tekninen osoitus tästä tarkoituksesta.
Milloin zero-knowledge-arkkitehtuuri ei sovi?
Zero-knowledge-salaus tuo mukanaan kompromisseja, jotka ovat merkittäviä joissain käyttötapauksissa:
Palautuksen monimutkaisuus: Jos käyttäjät menettävät salausavaimensa, data on pysyvästi saavuttamattomissa. Toisin kuin perinteisessä pilvivarastoinnissa, jossa ylläpitäjät voivat nollata pääsyn, takaovea ei ole. Organisaatiot, joilla on suuri henkilöstön vaihtuvuus tai huonot avaintenhallintatavat, saattavat pitää tätä ongelmallisena.
Yhteistyön kitka: Salattua dataa voidaan jakaa vain, kun vastaanottajalla on vastaava salauksenpurkukyky. Tämä lisää vaiheita verrattuna yksinkertaiseen linkkijakamiseen tavanomaisissa pilvipalveluissa.
Sääntelyreunatapaaukset: Joissakin lainkäyttöalueissa vaaditaan lainvalvontaviranomaisten pääsy dataan tuomioistuimen määräyksellä. Zero-knowledge-arkkitehtuurit estävät tämän suunnittelulähtöisesti – mikä voi luoda oikeudellista altistumista tietyillä toimialoilla (rahoituspalvelut, televiestintä), joihin kohdistuu laillisia siepausvelvollisuuksia.
Laskennallinen yleiskustannus: Asiakaspuolinen Argon2id-avainjohtaminen ja AES-256-GCM-salaus lisäävät viivettä, joka on merkittävä reaaliaikaisessa suurimittakaavaisessa käsittelyssä.
Organisaatioille, jotka käsittelevät erittäin suuria tekstivolyymejä (miljoonia asiakirjoja/päivä) tai joilla on tiukat lailliset siepausvelvollisuudet, hybridiarkkitehtuuri – joka salaa vain arkaluonteisimmat kentät pitäen metatiedot saatavilla – saattaa olla käytännöllisempi kuin end-to-end zero-knowledge.
Yhteenveto
"Salaamme datasi" ei ole turvallisuustakuu – se on markkinointilausuma, joka vaatii tutkintaa.
Tärkeät kysymykset ovat: kuka pitää avaimet, missä salaus tapahtuu ja mitä paljastuu, jos toimittajan infrastruktuuri vaarantuu?
Organisaatioille, jotka käsittelevät arkaluonteista dataa GDPR:n, HIPAA:n tai minkä tahansa vertailukelpoisen kehyksen alla, arkkitehtuurinen vastaus näihin kysymyksiin määrittää sekä sääntely-altistumisesi että todellisen rikkomusriskisi.
LastPass salasi käyttäjiensä datan. Zero-knowledge-arkkitehtuuri olisi tehnyt vuoden 2022 rikkomuksesta merkityksettömän. Käyttäjiltä varastettu 438 miljoonaa dollaria oli arkkitehtuurisen oikotien hinta.
anonym.legal toteuttaa zero-knowledge-arkkitehtuurin PII-anonymisointiin: Argon2id-avainjohtaminen toimii selaimessasi tai työpöytäsovelluksessasi, AES-256-GCM-salaus tapahtuu ennen kuin data poistuu laitteeltasi, ja anonym.legal-palvelimet tallentavat vain salatekstiä, jota ne eivät pysty purkamaan.
Lähteet: