Gapet mellom påstanden og arkitekturen
Hver skyleverandør som håndterer sensitive data gjør en eller annen versjon av den samme påstanden: "Vi krypterer dataene dine." Påstanden er nesten alltid sann — og nesten alltid utilstrekkelig.
LastPass-bruddet i 2022 er den definitive casestudien. LastPass krypterte brukernes passordlommebøker. De brukte kryptering. Påstanden var nøyaktig. Og likevel 25 millioner brukere fikk sine krypterte lommebøker eksfiltrert, og $438 millioner ble deretter stjålet fra LastPass-brukere i påfølgende kryptovalutaheist frem til 2025, ifølge forskning fra Coinbase Institutional.
Det britiske informasjonskontorets kontor ilagte LastPass sin britiske enhet en bot på £1,2 millioner i desember 2025 for "manglende implementering av passende tekniske og organisatoriske sikkerhetstiltak." Krypteringen eksisterte. Sikkerhetstiltakene oppfylte ikke de nødvendige standardene.
For bedrifter som evaluerer skyverktøy for personvern — inkludert PII-anonymiseringsplattformer — endrer LastPass-precedens spørsmålet om anskaffelse. Spørsmålet er ikke "krypterer de dataene våre?" Det er "kan de dekryptere dataene våre?"
De fire null-kunnskaps spørsmålene som faktisk betyr noe
Når man evaluerer en leverandørs null-kunnskapskrav, bestemmer fire spørsmål om arkitekturen er ekte:
1. Hvor skjer nøkkelutledningen?
I ekte null-kunnskapsarkitektur skjer utledningen av krypteringsnøkkel på klientsiden — i nettleseren eller skrivebordsapplikasjonen — før noen data overføres. Den utledede nøkkelen brukes til å kryptere data lokalt. Bare kryptert tekst reiser til leverandørens servere.
Hvis leverandøren utleder krypteringsnøkler på sine servere, holder de nøklene. Hvis de holder nøklene, kan de dekryptere. Påstanden er teknisk nøyaktig ("vi krypterer") men misvisende i sin implikasjon.
2. Har leverandøren noen gang tilgang til klartekst?
Noen verktøy krypterer data i ro, men dekrypterer dem for behandling — kjører AI-modeller, analyser, søkeindeksering eller generering av revisjonslogger. I løpet av behandlingsvinduet er klarteksten tilgjengelig på leverandørens infrastruktur. Et brudd i løpet av det vinduet eksponerer dataene i ukryptert form.
3. Hva skjer under rettslige prosesser?
Hvis et statlig organ sender en stevning til leverandøren, hvilke data kan de produsere? En leverandør med server-side nøkler kan bli tvunget til å produsere dekryptert innhold. En leverandør med null-kunnskapsarkitektur kan bare produsere kryptert tekst — selv under rettslig tvang, har de ingenting nyttig å overlevere.
4. Hva eksponerer et fullstendig serverkompromiss?
I en ekte null-kunnskapsimplementering gir et fullstendig brudd på leverandørens infrastruktur bare krypterte blobber. Angriperen mottar tekst uten nøklene for å dekryptere den. I en leverandørkontrollert nøkkelimplementering eksponerer et serverbrudd nøklene sammen med dataene.
LastPass-implementeringsfeilen
LastPass-bruddet avdekket et spesifikt implementeringsgap: eldre kontoer brukte PBKDF2 med så få som 1 iterasjon for nøkkelutledning, i stedet for de anbefalte 600 000 iterasjonene. Den svakere nøkkelutledningen gjorde brute-force angrep på de eksfiltrerte lommebøkene beregningsmessig gjennomførbare.
Dette illustrerer hvorfor evaluering av null-kunnskapskrav krever å undersøke implementeringsdetaljer, ikke bare arkitektoniske beskrivelser. En leverandør kan bruke en null-kunnskapsdesign mens de implementerer den svakt. De riktige spørsmålene å stille dekker både arkitekturen (nøkkelutledningssted) og implementeringsstyrken (algoritme og iterasjonsantall).
Okta-bruddet: En annen feilmodus
I oktober 2023 avslørte Okta at over 600 000 kundestøtterekorder ble lekket i et brudd. Okta er en identitetsplattform — selskapet som mange bedrifter bruker for å sikre tilgang til sine andre skyverktøy. Okta-bruddet var en annen feilmodus enn LastPass: ikke en svakhet i null-kunnskapsimplementeringen, men en kompromittering av støttestrukturen som tilfeldigvis inneholdt kundedata.
Den 300% økningen i SaaS-brudd i 2024 (AppOmni/CSA) reflekterer begge feilmodusene: arkitektoniske svakheter som LastPass og infrastrukturkompromisser som Okta. Null-kunnskapsarkitektur adresserer den arkitektoniske feilmodusen. Den eliminerer ikke all bruddrisiko, men den sikrer at selv en fullstendig infrastrukturkompromiss ikke eksponerer dekrypterbare kundedata.
Hvordan en ekte evaluering ser ut
For anskaffelsesteam som vurderer null-kunnskapskrav, sjekklisten for evaluering:
Arkitekturgjennomgang:
- Be om dokumentasjon som viser hvor nøkkelutledningen skjer (klientside vs. serverside)
- Be om krypteringsalgoritmen, nøkkellengden og iterasjonsantallet
- Be om bekreftelse på at klartekst aldri overføres til leverandørens servere
Testing av bruddscenarier:
- Be leverandøren beskrive hva et fullstendig serverkompromiss ville eksponere
- Hvis svaret inkluderer noe annet enn "kryptert tekst vi ikke kan dekryptere," er påstanden ikke ekte null-kunnskap
Gjennomgang av rettslige prosesser:
- Spør om leverandøren kan overholde en stevning som krever produksjon av kundeklartekst
- Ekte null-kunnskapsleverandører kan ikke produsere det de ikke har
Samsvars dokumentasjon:
- Be om leverandørens GDPR Artikkel 32 samsvars dokumentasjon
- ISO 27001-sertifisering (spesielt Annex A kryptografiske kontroller) gir ekstern verifisering av nøkkelhåndteringspraksis
Den £1,2 millioner LastPass ICO-boten etablerer at leverandører som gjør krypteringskrav er underlagt regulatorisk evaluering av om disse kravene oppfyller de nødvendige standardene. Den samme evalueringsrammen som regulatorer bruker er tilgjengelig for anskaffelsesteam før et brudd skjer.
Kilder: