Vaatimuksen ja Arkkitehtuurin Välinen Kuilu
Jokainen pilvipalveluntarjoaja, joka käsittelee arkaluontoisia tietoja, esittää jonkinlaisen version samasta väitteestä: "Salataan tietosi." Väite on lähes aina totta — ja lähes aina riittämätön.
LastPassin vuoto vuonna 2022 on määrittävä tapaustutkimus. LastPass salasi käyttäjiensä salasanalokerot. He käyttivät salausta. Väite oli tarkka. Ja silti 25 miljoonaa käyttäjää menetti salatut lokeronsa, ja $438 miljoonaa varastettiin LastPassin käyttäjiltä myöhemmissä kryptovaluuttahöykytyksissä vuoteen 2025 mennessä, Coinbase Institutional -tutkimuksen mukaan.
Iso-Britannian tietosuojavaltuutetun toimisto määräsi LastPassin brittiläiselle toimijalle £1.2 miljoonan sakon joulukuussa 2025 "sopivien teknisten ja organisatoristen turvallisuustoimenpiteiden toteuttamatta jättämisestä." Salaus oli olemassa. Turvatoimenpiteet eivät täyttäneet vaadittua standardia.
Yrityksille, jotka arvioivat pilvipalveluiden yksityisyystyökaluja — mukaan lukien PII-anonymisointialustat — LastPassin ennakkotapaus muuttaa hankintakysymystä. Kysymys ei ole "salataanko tietojamme?" vaan "voivatko he purkaa tietojamme?"
Neljä Nollatietokysymystä, Jotka Oikeasti Merkitsevät
Kun arvioidaan myyjän nollatietovaatimusta, neljä kysymystä määrittää, onko arkkitehtuuri aito:
1. Missä avaimen johdanto tapahtuu?
Aidossa nollatietoaarkkitehtuurissa salausavaimen johdanto tapahtuu asiakaspäässä — selaimessa tai työpöytäsovelluksessa — ennen kuin mitään tietoa siirretään. Johdettu avain käytetään tietojen salaamiseen paikallisesti. Vain salattu salakirjoitus kulkee myyjän palvelimille.
Jos myyjä johdattaa salausavaimia omilla palvelimillaan, he pitävät avaimet. Jos he pitävät avaimet, he voivat purkaa. Väite on teknisesti tarkka ("me salataan") mutta harhaanjohtava sen implikaatiossa.
2. Onko myyjällä koskaan pääsy selkokieleen?
Jotkut työkalut salaavat tietoja levossa, mutta purkavat niitä käsittelyä varten — AI-mallien, analytiikan, hakemiston tai auditointilokien luomisen aikana. Käsittelyikkunan aikana selkokieli on saatavilla myyjän infrastruktuurissa. Murto tuona aikana paljastaa tiedot salaamattomassa muodossa.
3. Mitä tapahtuu oikeudellisen prosessin aikana?
Jos hallituksen viranomainen toimittaa myyjälle haasteen, mitä tietoja he voivat tuottaa? Myyjä, jolla on palvelinpuolen avaimet, voidaan pakottaa tuottamaan purettua sisältöä. Myyjä, jolla on nollatietoaarkkitehtuuri, voi tuottaa vain salausta — edes oikeudellisen pakon alla heillä ei ole mitään hyödyllistä annettavaa.
4. Mitä täydellinen palvelinmurto paljastaa?
Aidossa nollatietototeutuksessa myyjän infrastruktuurin täydellinen murto tuottaa vain salattuja tietoja. Hyökkääjä saa salakirjoituksen ilman avaimia sen purkamiseksi. Myyjän hallitsemalla avaimella toteutuksessa palvelinmurto paljastaa avaimet yhdessä tietojen kanssa.
LastPassin Toteutuksen Epäonnistuminen
LastPassin vuoto paljasti erityisen toteutuseron: vanhemmat tilit käyttivät PBKDF2:ta vain 1 iteraatiolla avaimen johdannossa, sen sijaan että olisi käytetty suositeltuja 600,000 iteraatiota. Heikompi avaimen johdanto teki bruteforce-hyökkäyksistä exfiltraatioituneita lokeroita laskennallisesti mahdollisia.
Tämä havainnollistaa, miksi nollatietovaatimusten arvioiminen vaatii toteutustietojen tarkastelua, ei vain arkkitehtonisia kuvauksia. Myyjä voi käyttää nollatietosuunnittelua, mutta toteuttaa sen heikosti. Oikeat kysymykset kattavat sekä arkkitehtuurin (avaimen johdannon sijainti) että toteutuksen vahvuuden (algoritmi ja iteraatiomäärä).
Okta-vuoto: Eri Epäonnistumistapa
Lokakuussa 2023 Okta paljasti, että yli 600,000 asiakastukitietoa vuoti murrossa. Okta on identiteettialusta — yritys, jota monet organisaatiot käyttävät suojatakseen pääsyn muihin pilvipalveluihinsa. Okta-vuoto oli erilainen epäonnistumistapa kuin LastPass: ei heikkous nollatietototeutuksessa, vaan asiakastietoja sisältävän tukirakenteen kompromissi.
SaaS-vuotojen nousu 300% vuonna 2024 (AppOmni/CSA) heijastaa molempia epäonnistumistapoja: arkkitehtonisia heikkouksia kuten LastPass ja infrastruktuurin kompromisseja kuten Okta. Nollatietoaarkkitehtuuri käsittelee arkkitehtonista epäonnistumistapaa. Se ei poista kaikkia murto- ja riskejä, mutta se varmistaa, että jopa täydellinen infrastruktuurin kompromissi ei paljasta purettavia asiakastietoja.
Miltä Aito Arviointi Näyttää
Hankintatiimeille, jotka arvioivat nollatietovaatimuksia, arviointitarkistuslista:
Arkkitehtuurin tarkastus:
- Pyydä dokumentaatiota, joka osoittaa, missä avaimen johdanto tapahtuu (asiakaspäässä vs. palvelinpuolella)
- Kysy salausalgoritmia, avaimen pituutta ja iteraatiomäärää
- Pyydä vahvistusta siitä, että selkokieltä ei koskaan siirretä myyjän palvelimille
Murto-skenaarion testaus:
- Pyydä myyjältä kuvausta siitä, mitä täydellinen palvelinmurto paljastaisi
- Jos vastaus sisältää jotain muuta kuin "salattua salausta, jota emme voi purkaa," väite ei ole aito nollatieto
Oikeudellisen prosessin tarkastus:
- Kysy, voiko myyjä noudattaa haasteen, joka vaatii asiakasselkokielen tuottamista
- Aidot nollatietomyynnit eivät voi tuottaa sitä, mitä heillä ei ole
Sääntöjen noudattamisen dokumentaatio:
- Pyydä myyjän GDPR:n artikla 32 -sääntöjen noudattamisen dokumentaatio
- ISO 27001 -sertifiointi (erityisesti liite A salaustekniikoissa) tarjoaa ulkoista vahvistusta avainhallintakäytännöistä
£1.2 miljoonan LastPassin ICO-sakko osoittaa, että salausvaatimuksia esittävät myyjät ovat sääntelyarvioinnin alaisia sen arvioimiseksi, täyttävätkö nämä vaatimukset vaaditun standardin. Sama arviointikehys, jota sääntelijät soveltavat, on saatavilla hankintatiimeille ennen murtoa.