De sier at dataene deres er kryptert. Hvem kan likevel lese dem?

Hva beskytter «kryptert i hvile» egentlig mot?

Dere finner uttrykket på sikkerhetssiden til hver eneste leverandør. Det betyr at dataene er uleselige mens de ligger på disken, og lesbare i det øyeblikket noe logger inn. Kall det lagringskryptering.

Lagringskryptering er laget for å være usynlig. Det er salgsargumentet, ikke en tilfeldighet. Databasen låser opp dataene når den leser, og låser dem når den skriver, automatisk, for hver spørring som kommer med en gyldig innlogging. Søk, sortering, filtrering og rapporter fungerer akkurat som før.

Les det en gang til, og tenk på en angriper.

Tenk på det som å låse lageret om natta. Det stopper den som kommer gjennom veggen. Det gjør ingenting med den som går inn hoveddøra med adgangskort, fordi døra er laget for å åpne seg for adgangskort.

Krypteringen blir aldri knekt. Den gjør nøyaktig det den ble laget for, for noen den aldri var ment å tjene.

Trusselen den ble laget for, er ekte nok. En disk blir kastet. Et bånd med sikkerhetskopier forsvinner i posten. En bærbar PC blir stjålet. I alle disse tilfellene er dataene verdiløse uten nøkkelen. Men tidligere sto slike hendelser for en reell andel av datatapene, og i dag er de en avrundingsfeil.

Hvordan kommer data seg egentlig ut av en organisasjon?

Fem mønstre dekker de fleste rapporterte sikkerhetsbrudd. Hold hvert av dem opp mot lagringskryptering, og svaret blir det samme hver gang.

En gyldig innlogging i feil hender. Et passord blir gjenbrukt, stjålet med phishing eller glemt i et kodelager. En innloggingsøkt blir stjålet. En tilgangsnøkkel som ble limt inn i en chat for to år siden, virker fortsatt. Angriperen sender nå spørringer til systemet som en ekte bruker, og alle svarene kommer tilbake lesbare — for så langt databasen kan se, er angriperen en ekte bruker.

Tjenestekontoen ingen husker å ha opprettet. Rapportjobben. Synkroniseringsintegrasjonen. Migreringsskriptet som skulle være midlertidig. Slike kontoer får bred lesetilgang tidlig, når systemet er lite og tilgangen ser harmløs ut, og de blir nesten aldri strammet inn senere. De fleste har verken eier eller utløpsdato. En tjenestekonto som leser alt klokka tre om natta, ser akkurat ut som en tjenestekonto som gjør jobben sin.

Kopien som ble laget av en god grunn. Sikkerhetskopier. Datavarehuset for analyse. Testmiljøet som ble fylt med produksjonsdata forrige kvartal, bare for å ha noe realistisk. Regnearket noen eksporterte til et styremøte. Hver kopi tar med seg dataene og lar kontrollene ligge igjen. En gjenopprettet sikkerhetskopi er en fungerende database, og en fungerende database låser opp dataene når den leser.

Systemet i utkanten. Det spesialiserte planleggingsverktøyet. Koblingen til lønnssystemet. Tredjepartsportalen som trengte «bare lesetilgang» for å holde to systemer i takt. Ofte den dårligst forsvarte delen av kjeden, med det mest sensitive datauttrekket, og utenfor den sikkerhetsgjennomgangen hovedsystemet eventuelt fikk.

Personen som har lov. En administrator. En supportingeniør. En innleid konsulent med en tilgang som varte lenger enn kontrakten. Ingen bryter seg inn i det hele tatt. Noen med legitim tilgang leser eller eksporterer mer enn jobben krever, og alle tekniske kontroller er enige i at det er tillatt.

Én rad er et ja for lagringskryptering. Det er raden som nesten aldri skjer.

Endrer en stor skyleverandør svaret?

Team slapper av når plattformen driftes av et selskap med en stor sikkerhetsavdeling. Den første halvdelen av det resonnementet stemmer som regel. Konklusjonen holder ikke, av en strukturell grunn.

Alle de store plattformene publiserer den samme ansvarsfordelingen. Leverandøren sikrer infrastrukturen: byggene, maskinvaren, nettverket. Det er de svært gode på. Dere sikrer det som kjører på den, og hvem som kan nå det: innlogginger, tilgangsomfang, hvilken tjenestekonto som får lese hvilke registreringer.

Alle bruddmønstrene ovenfor ligger på deres side av den linja. Leverandørens kompetanse er nesten helt rettet mot den ene trusselen som allerede har forsvunnet. Den grønne haken i konsollen betyr lagringskryptering, og databasen returnerer fortsatt lesbare data til gyldige spørringer. Det må den, ellers ville produktet slutte å virke.

Hva er kryptering på feltnivå?

Kryptering på feltnivå flytter grensen. I stedet for at lagringslaget beskytter filene under databasen, låser applikasjonen hver verdi før den i det hele tatt sendes til databasen, og låser den opp når den kommer tilbake. Databasen lagrer, indekserer, kopierer og tar sikkerhetskopi av uleselige data. Den har aldri nøkkelen.

Dette er en annen egenskap, ikke en sterkere versjon av den samme. Lagringskryptering svarer på: Hvor blir dataene oppbevart? Kryptering på feltnivå svarer på: Hvem kan hente dem ut i lesbar form? Og den svarer ved å gjøre databasen varig ute av stand til det.

Kan dere fortsatt søke i dataene?

Delvis. En verdi kan låses på to måter. Lås den forskjellig hver gang, så kan ikke databasen søke i den i det hele tatt — maksimal beskyttelse, brukt for ting som en melding eller et kontonummer, der ingenting trenger å matche. Lås den likt hver gang, så virker oppslag på eksakt treff fortsatt, og det trenger en e-postadresse, fordi innloggingen må finne den.

Den andre måten har en kostnad som bør sies rett ut: Verdier som går igjen, kan sees som gjentakelser. En observatør kan se at to registreringer har samme verdi, og telle hvor ofte hver verdi forekommer, uten noen gang å få vite hva den er.

Noen kolonner må også forbli lesbare, ellers slutter systemet å virke: ID-ene til registreringene, statusen en arbeidsflyt filtrerer på, datoene som styrer når gamle registreringer utløper. De er skjelettet, valgt med vilje, ikke noe som ble til overs. De er heller ikke harmløse — de avslører struktur: hvem som henger sammen med hvem, hvor ofte og når. Riktig tilnærming er å holde dem få, navngi dem og ikke late som om grensen ligger et sted den ikke gjør.

Hvorfor gjør så få leverandører dette?

Det skyldes sjelden uvitenhet. Arbeidet er virkelig kostbart, på måter som berører alle deler av et produkt — mens alternativet tar én ettermiddag og gir den samme grønne haken i det samme compliance-skjemaet.

Man mister databasen. En låst kolonne kan ikke sorteres, grupperes, søkes i etter intervall eller matches med jokertegn. For databasen er den en sekk med byte. Eksakt treff kan man få tilbake. Sortering ikke. Hvert søkefelt og hver rapport må tenkes nytt, og arbeidet flyttes inn i applikasjonen.

Hvert nytt felt blir en beslutning, med konsekvenser for søk, rapportering og hva en angriper får vite. Det finnes ingen trygg standardinnstilling. Team som legger til felt raskt, synes dette er irriterende, og det er litt av poenget: Det gjør en usynlig risiko synlig, mens den fortsatt kan endres.

Og feil skjer i det stille. Blir noe glemt, går ingenting i stykker, og ingen test blir rød. Dataene blir bare skrevet i lesbar form og ser helt normale ut, helt til den dagen noen leser lagringen direkte. Den trygge veien må være den eneste veien.

Ingenting av dette er intellektuelt vanskelig. Alt sammen koster tid, og ingenting av det vises i en salgsdemo. Det er hele forklaringen på hvorfor avkrysningsboksen som regel vinner.

Dette har vi bygget

En artikkel som denne ville vært lite verdt som argument for noe vi ennå ikke hadde gjort. Så her er hvor vi står, beskrevet som ting dere kan teste oss på.

• Databaseadministratorene våre kan ikke lese registreringene deres. Nøkkelen er ikke tilgjengelig på det laget.
• En gjenopprettet sikkerhetskopi er uleselig. Den inneholder låste verdier, ikke en fungerende kopi av dataene deres.
• Dataene deres er skilt fra andres på databasenivå, i stedet for å ligge i delte tabeller og være avhengige av et filter i hver spørring. Ett glemt filter kan ikke ende med at én kundes data blir synlige for en annen.
• Nøkkelforvaltningen kan flyttes uten at noe må krypteres på nytt, og det er det som gjør det praktisk mulig å tilby forvaltning i et bestemt land eller hos en uavhengig part.
• AI-søket vårt inneholder ingen lesbar tekst. Indeksen lagrer verken dokumentinnhold eller personopplysninger. Den returnerer referanser, og applikasjonen henter og låser deretter opp registreringene for en bruker som allerede har fått tilgangen sin kontrollert.
• Hvert felt klassifiseres når det opprettes — lesbart med vilje, låst og søkbart, eller låst og ikke søkbart. Klassifiseringen ligger på selve feltet, så de to kan ikke gli fra hverandre.

Det femte punktet fortjener en setning til, fordi det er her vi venter at de fleste plattformer kommer til å lekke de neste årene. Det er helt vanlig — og nesten aldri undersøkt — at en AI-søkeindeks også inneholder originalteksten i lesbar form, i et lager ingen noen gang har klassifisert som et sted med personopplysninger.

Dette jobber vi fortsatt med

Dette er bygget og i drift, og deler av det utvides fortsatt — et eldre område av plattformen ligger utenfor grensen, og klassifiseringsarbeidet fortsetter. Vi har en oppdatert liste over nøyaktig hva som er ferdig, og hva som pågår, og den gir vi dere under en evaluering. En leverandør som påstår at beskyttelsen er uten begrensninger, har enten unngått å se etter eller bestemt seg for å tie.

Hva skjer med slettede data i sikkerhetskopiene deres?

Det ligger en motsetning i kjernen av alle oppbevaringsregler, og de fleste organisasjoner har i det stille blitt enige om ikke å se på den.

Dere lover at personopplysninger blir slettet etter en bestemt periode, eller på forespørsel. Dere tar også sikkerhetskopier, fordi en organisasjon som ikke kan komme seg etter løsepengevirus eller menneskelige feil, er uaktsom på en annen måte. Sikkerhetskopier er med vilje uforanderlige — det er hele poenget. Så registreringen dere lovet å slette, ligger fortsatt i forrige måneds øyeblikksbilde, og i det før der, og i den arkivkopien noen laget for en migrering i 2023 og aldri nevnte.

Å slette den fra produksjonsdatabasen er enkelt. Å slette den fra sikkerhetskopiene er enten umulig eller uklokt.

Umulig, fordi en sikkerhetskopi er et konsistent bilde av ett øyeblikk, og å fjerne enkeltregistreringer ødelegger egenskapen som gjør den pålitelig. Uklokt, fordi det å bygge evnen til å skrive om gamle sikkerhetskopier betyr å bygge et verktøy som skriver om historien — akkurat den muligheten en angriper helst vil ha, og en revisor minst vil at dere skal ha.

De vanlige svarene, og hva som er galt med hvert av dem

• «Sikkerhetskopiene går ut på dato.» Slettingene sprer seg etter hvert som gamle øyeblikksbilder utløper. Dette er bransjens standardsvar, og det kan forsvares — selv om dataene faktisk fortsatt finnes så lenge det tidsvinduet varer, og argumentet faller sammen for langtidsarkiver og rettslig pålagt oppbevaring.
• «Vi kjører en slettelogg på nytt etter hver gjenoppretting.» Bedre, og det finnes organisasjoner som faktisk gjør det. Det er også et løfte om en prosedyre et menneske må utføre riktig midt i en katastrofe, når alle er utslitte. Kontroller som bare virker når folk er rolige, er ingen kontroller.
• «Sikkerhetskopier er utenfor omfanget.» De er innenfor omfanget, og en leverandør som sier dette, forteller dere at de ennå ikke har tenkt over det.

Det som faktisk løser det

Én tilnærming får problemet til å forsvinne i stedet for å håndtere det, og den finnes bare hvis dataene ble låst felt for felt fra starten av.

Det snur problemet på hodet. Vanligvis er sletting et søk gjennom et ukjent antall steder, og dere kan aldri bevise at dere fant alle. Her er det én handling på ett sted, med et resultat som kan bevises, og kopiene dere ikke fant, slutter å ha betydning.

To betingelser må være oppfylt. Nøklene må holdes utenfor sikkerhetskopien — ellers har dere tatt sikkerhetskopi av låsen sammen med nøkkelen. Og hvor finmasket nøklene er delt opp, avgjør hva dere kan slette:

Den vanskelige delen har vi allerede: Hver kunde har sin egen nøkkel for selve dataene, noe som er virkelig uvanlig, og som er forutsetningen for den midterste raden. I dag fungerer slettingen vår på den vanlige måten — mot produksjonsdataene, mens sikkerhetskopiene går ut på dato i sin egen rotasjon. Å gå over til den midterste raden er et definert stykke arbeid, ikke en markedsføringspåstand, og vi forteller dere nøyaktig hvor langt det har kommet når dere spør.

Vurderer dere en leverandør som i dag hevder å slette ved å destruere nøkkelen, er de to betingelsene over nøyaktig det dere bør teste dem på. De fleste har ennå ikke sett på det.

Hva kryptering på feltnivå ikke beskytter dere mot

En sikkerhetsartikkel som bare lister opp styrker, bør leses som markedsføring. Dette er begrensningene, og det første punktet er den viktigste setningen her.

En tilgang som ikke burde finnes. Kryptering beskytter data der de er lagret. Den gir ingenting mot en tilgang som er for bred. Får en person tilgang til et område de burde holde seg unna, låser plattformen opp dataene for dem, korrekt og umiddelbart, fordi det er det en tilgang betyr. Ingen kryptering redder dere fra en feil i tilgangsstyringen. Det gjør bare en gjennomgang av hvem som har tilgang til hva, etter en fast plan, utført av noen som forstår organisasjonen.

En kompromittert applikasjon. Applikasjonen har nøklene. Det må den ha, ellers kunne den ikke vise noen noe som helst. Kryptering på feltnivå gjør et angrep betydelig dyrere og fjerner hele kategorier av angrep, men applikasjonen selv er like viktig som før. Den flytter målet i stedet for å fjerne det.

Legitim eksport. En bruker som får se en skjerm, kan ta skjermbilde av den, kopiere fra den eller eksportere den. Hver rapportfunksjon er en mulig vei ut, med krypteringen allerede fjernet. Det er tilgangsomfang og revisjonslogg som styrer dette, ikke kryptering.

Struktur, om ikke innhold. De lesbare kolonnene forteller en historie: hvilke registreringer som henger sammen med hvilke, hvor mange det finnes, når de ble opprettet. I noen sammenhenger er strukturen alene sensitiv. Å holde den på et minimum er ekte arbeid, og det blir aldri helt ferdig.

Fjorten spørsmål å stille enhver leverandør

Hvis denne artikkelen er nyttig til én ting, la det være dette. Spørsmålene er vanskelige å svare usant på, og lette å svare på der arbeidet faktisk er gjort. Still dem til alle leverandører som har data om de ansatte deres — og still dem til oss.

Når vi publiserer en slik liste, følger det tre forpliktelser, og det er dem vi vil at dere skal holde oss til. Hvert nytt felt klassifiseres når det opprettes, aldri i etterkant. Den utrygge veien er stengt, ikke frarådet, så en manglende innstilling feiler høylytt under utvikling i stedet for stille i produksjon. Og begrensningene publiseres før noen spør etter dem — en leverandør som ikke kan fortelle dere hva beskyttelsen ikke dekker, har enten unngått å se etter eller bestemt seg for å tie, og begge deler bør bekymre dere like mye.

Hvis dere skal ta med dere én ting

Spørsmålet å stille om ethvert system med data om mennesker er aldri er det kryptert. Alle systemer er kryptert. Spørsmålet er hvem som kan hente dataene ut i lesbar form, og hva som skal til for at uvedkommende havner på den lista.

Er svaret «det gjør databasen automatisk for alt med en gyldig innlogging», da beskytter det dere har kjøpt, mot en trussel som stort sett har forsvunnet, og sikkerhetsbruddet som når kundene deres, vil forløpe nøyaktig som om beskyttelsen ikke fantes.

Kryptering på feltnivå er ikke gratis, ikke komplett og ingen erstatning for tilgangsstyring. Det er en bevisst beslutning om å gjøre databasen varig ute av stand til å lese det den inneholder — og å betale for det med mindre lettvint søk, ekstra designarbeid og en langsommere vei fra idé til funksjon. Vi mener den avveiningen er riktig, og vi tror de kommende årene vil vise det tydeligere enn noen artikkel kan.

Hvor kommer belegget fra?

Her siteres det med vilje ingen bruddstatistikk, bransjeundersøkelser eller leverandørfinansiert forskning. De fleste tallene som sirkulerer mye på dette feltet, stammer fra markedsføringsmateriell. Hver påstand om hvordan disse kontrollene oppfører seg, følger av hvordan de virker, og en leser som er uenig, kan sjekke den mot dokumentasjonen til et hvilket som helst databaseprodukt i stedet for å ta oss på ordet. Beskrivelsen av vår egen plattform er sjekket mot det som faktisk kjører.