De säger att era data är krypterade. Vem kan ändå läsa dem?

Vad skyddar ”krypterad i vila” egentligen mot?

Uttrycket finns på varje leverantörs säkerhetssida. Det betyder att data är oläsbara medan de ligger på disken, och läsbara i samma ögonblick som något loggar in. Vi kallar det här lagringskryptering.

Lagringskryptering är byggd för att vara osynlig. Det är själva försäljningsargumentet, ingen slump. Databasen låser upp data när den läser och låser dem när den skriver, automatiskt, för varje databasfråga som kommer in med en giltig inloggning. Sökning, sortering, filtrering och rapporter fungerar precis som förut.

Läs det där igen, med en angripare i tankarna.

Se det som att låsa lagerlokalen på natten. Det stoppar den som tar sig in genom väggen. Det gör ingenting åt den som går in genom ytterdörren med ett passerkort, eftersom dörren är byggd för att öppnas för passerkort.

Krypteringen knäcks aldrig. Den gör precis det den byggdes för, åt någon den aldrig var tänkt att tjäna.

Hotet den byggdes för finns på riktigt. En hårddisk slängs. Ett band med säkerhetskopior försvinner i posten. En bärbar dator blir stulen. I alla de fallen är data värdelösa utan nyckeln. Men förr stod sådana situationer för en betydande andel av alla dataläckor, och i dag är de ett avrundningsfel.

Hur lämnar data egentligen en organisation?

Fem mönster täcker de flesta rapporterade dataintrång. Pröva vart och ett mot lagringskryptering, så blir svaret detsamma varje gång.

En giltig inloggning i fel händer. Ett lösenord återanvänds, fångas genom nätfiske eller blir kvar i ett kodförråd. En session stjäls. En åtkomstnyckel som klistrades in i en chatt för två år sedan fungerar fortfarande. Angriparen ställer nu frågor till systemet som en riktig användare, och varje svar kommer tillbaka läsbart — för i databasens ögon är det en riktig användare.

Tjänstekontot som ingen minns att man skapade. Rapportjobbet. Synkintegrationen. Migreringsskriptet som skulle vara tillfälligt. De får bred läsbehörighet tidigt, när systemet är litet och behörigheten ser ofarlig ut, och de begränsas nästan aldrig i efterhand. De flesta har varken ägare eller utgångsdatum. Ett tjänstekonto som läser allt klockan tre på natten ser precis ut som ett tjänstekonto som gör sitt jobb.

Kopian som gjordes av goda skäl. Säkerhetskopior. Datalagret för analys. Testmiljön som fick en färsk kopia av produktionsdata förra kvartalet, bara för att ha något realistiskt. Kalkylbladet som någon exporterade inför ett styrelsemöte. Varje kopia tar med sig data men lämnar skydden bakom sig. En återställd säkerhetskopia är en fungerande databas, och en fungerande databas låser upp data när den läser.

Systemet i utkanten. Specialverktyget för schemaläggning. Kopplingen till lönesystemet. Tredjepartsportalen som behövde ”bara läsbehörighet” för att hålla två system i synk. Ofta den sämst skyddade delen av kedjan, med det känsligaste utdraget, och utanför den säkerhetsgranskning som huvudsystemet eventuellt fick.

Personen som har behörighet. En administratör. En supporttekniker. En konsult vars åtkomst överlevde avtalet. Ingen bryter sig in alls. Någon med legitim åtkomst läser eller exporterar mer än jobbet kräver, och alla tekniska skydd är överens om att det är tillåtet.

En rad är ett ja för lagringskryptering. Det är raden som nästan aldrig inträffar.

Ändrar en stor molnleverantör svaret?

Team slappnar av när plattformen drivs av ett företag med en stor säkerhetsavdelning. Första halvan av det resonemanget stämmer oftast. Slutsatsen håller inte, och det av ett strukturellt skäl.

Alla stora plattformar publicerar samma arbetsfördelning. Leverantören säkrar infrastrukturen: byggnaderna, hårdvaran, nätverket. Det är de mycket bra på. Ni säkrar det som körs ovanpå och vem som kommer åt det: inloggningar, åtkomstens omfattning, vilket tjänstekonto som får läsa vilka poster.

Varje intrångsmönster ovan ligger på er sida av den gränsen. Leverantörens kompetens riktar sig nästan helt mot det enda hot som redan har slutat inträffa. Den gröna bocken i konsolen betyder lagringskryptering, och databasen returnerar fortfarande läsbara data till giltiga frågor. Det måste den, annars skulle produkten sluta fungera.

Vad är kryptering på fältnivå?

Kryptering på fältnivå flyttar gränsen. I stället för att lagringsnivån skyddar filerna under databasen låser applikationen varje värde innan det över huvud taget skickas till databasen, och låser upp det när det kommer tillbaka. Databasen lagrar, indexerar, kopierar och säkerhetskopierar oläsbara data. Den har aldrig nyckeln.

Det här är en annan egenskap, inte en starkare version av samma. Lagringskryptering svarar på frågan: var förvaras data? Kryptering på fältnivå svarar på frågan: vem kan läsa ut dem? Den svarar genom att göra det permanent omöjligt för databasen.

Går det fortfarande att söka?

Delvis. Ett värde kan låsas på två sätt. Lås det olika varje gång, så kan databasen inte söka i det alls — maximalt skydd, som används för sådant som ett meddelande eller ett kontonummer, där ingenting behöver matcha. Lås det likadant varje gång, så fungerar uppslag på exakt matchning fortfarande, vilket en e-postadress behöver, eftersom inloggningen måste hitta den.

Det andra läget har ett pris som förtjänar att sägas rakt ut: upprepade värden syns som upprepningar. Den som tittar kan se att två poster har samma värde, och räkna hur ofta varje värde förekommer, utan att någonsin få veta vad det är.

Vissa kolumner måste dessutom förbli läsbara, annars slutar systemet fungera: postidentifierare, statusen som ett arbetsflöde filtrerar på, datum som används för att gallra gamla poster. De är skelettet, valda med avsikt och inte något som blev över. De är inte heller ofarliga — de bär på struktur: vem som hör ihop med vem, hur ofta och när. Rätt sätt är att hålla nere antalet, namnge dem och inte låtsas att gränsen går någon annanstans än där den gör.

Varför gör så få leverantörer så här?

Sällan av okunskap. Arbetet är verkligen dyrt, på sätt som berör varje del av en produkt — medan alternativet tar en eftermiddag och ger samma gröna bock i samma frågeformulär om regelefterlevnad.

Man förlorar databasen. En låst kolumn kan inte sorteras, grupperas, sökas på intervall eller matchas med jokertecken. För databasen är den bara en samling byte. Exakt matchning går att få tillbaka. Sortering går inte. Varje sökruta och varje rapport måste tänkas om, och arbetet flyttas in i applikationen.

Varje nytt fält blir ett beslut, med följder för sökning, rapportering och vad en angripare får veta. Det finns inget säkert standardval. Team som lägger till fält i snabb takt tycker att det är irriterande, vilket egentligen är poängen: det gör en osynlig risk synlig medan den fortfarande går att ändra.

Och misstagen syns inte. Missar man något går ingenting sönder och inget test blir rött. Data skrivs helt enkelt i läsbar form och ser helt normala ut, tills den dag någon läser lagringen direkt. Den säkra vägen måste vara den enda vägen.

Inget av det här är intellektuellt svårt. Allt kostar tid, och inget av det syns i en säljdemo. Det är hela förklaringen till att kryssrutan oftast vinner.

Det här har vi byggt

En artikel som den här vore inte värd mycket som argument för något vi ännu inte hade gjort. Så här står vi, formulerat som saker ni kan pröva oss på.

• Våra databasadministratörer kan inte läsa era poster. Nyckeln finns inte tillgänglig på den nivån.
• En återställd säkerhetskopia är oläsbar. Den innehåller låsta värden, inte en fungerande kopia av era data.
• Era data är åtskilda på databasnivå, i stället för att dela tabeller och förlita sig på ett filter i varje fråga. Ett missat filter kan inte leda till att en kunds data visas för en annan.
• Nyckelförvaringen kan flyttas utan att något behöver krypteras om, och det är det som gör det praktiskt möjligt att erbjuda förvaring i ett visst land eller hos en oberoende part.
• Vår AI-sökning innehåller ingen läsbar text. Indexet lagrar inget dokumentinnehåll och inga personuppgifter. Det returnerar referenser, och applikationen hämtar och låser sedan upp posterna åt någon vars behörighet redan har kontrollerats.
• Varje fält klassas när det skapas — läsbart med avsikt, låst och sökbart, eller låst och inte sökbart. Klassningen sitter på själva fältet, så de två kan inte glida isär.

Den femte punkten förtjänar en extra mening, eftersom det är där vi räknar med att de flesta plattformar kommer att läcka de närmaste åren. Det är helt normalt — och nästan aldrig granskat — att ett AI-sökindex också innehåller originaltexten i läsbar form, på en lagringsplats som ingen någonsin har klassat som en plats med personuppgifter.

Det vi fortfarande arbetar med

Det här är byggt och i drift, och delar av det byggs fortfarande ut — en äldre del av plattformen ligger utanför gränsen, och klassningsarbetet fortsätter. Vi har en aktuell lista över exakt vad som är klart och vad som pågår, och den lämnar vi till er under en utvärdering. En leverantör som säger att deras skydd inte har några begränsningar har antingen undvikit att titta eller valt att tiga.

Vad händer med raderade data i era säkerhetskopior?

Det finns en motsägelse i kärnan av varje gallringspolicy, och de flesta organisationer har i tysthet kommit överens om att inte titta på den.

Ni lovar att personuppgifter raderas efter en bestämd tid, eller på begäran. Ni har också säkerhetskopior, eftersom en organisation som inte kan återhämta sig från ransomware eller mänskliga misstag är försumlig åt ett annat håll. Säkerhetskopior är medvetet oföränderliga — det är hela poängen. Så posten ni lovade att radera ligger kvar i förra månadens ögonblicksbild, och i den före, och i den arkivkopia som någon gjorde inför en migrering 2023 och aldrig nämnde.

Att radera den ur produktionsdatabasen är enkelt. Att radera den ur säkerhetskopiorna är antingen omöjligt eller oklokt.

Omöjligt, eftersom en säkerhetskopia är en konsistent bild av ett enda ögonblick, och att ta bort enskilda poster bryter den egenskap som gör den pålitlig. Oklokt, eftersom förmågan att skriva om gamla säkerhetskopior innebär att bygga ett verktyg som skriver om historien — precis den förmåga som en angripare allra helst och en revisor allra minst vill att ni ska ha.

De vanliga svaren, och vad som är fel med vart och ett

• ”Säkerhetskopiorna gallras bort med tiden.” Raderingarna slår igenom allteftersom gamla ögonblicksbilder löper ut. Det är branschens standardsvar och det går att försvara — även om data faktiskt finns kvar så länge det fönstret varar, och argumentet faller när det gäller långtidsarkiv och bevarandeplikt vid rättslig process.
• ”Vi tillämpar en raderingslogg på nytt efter varje återställning.” Bättre, och riktiga organisationer gör så. Det är också ett löfte om en rutin som en människa måste utföra korrekt mitt i en katastrof, när alla är utmattade. Skydd som bara fungerar när folk är lugna är inget skydd.
• ”Säkerhetskopior omfattas inte.” Det gör de, och en leverantör som säger så berättar att de ännu inte har tänkt på saken.

Det som faktiskt löser det

Ett sätt löser upp problemet i stället för att hantera det, och det finns bara om data låstes fält för fält från första början.

Det vänder på problemet. Normalt är radering ett sökande på ett okänt antal ställen, och ni kan aldrig bevisa att ni hittade alla. Här är det en enda handling på ett enda ställe, med ett resultat som går att bevisa, och de kopior ni inte hittade slutar spela någon roll.

Två villkor måste vara uppfyllda. Nycklarna måste hållas utanför säkerhetskopian — annars har ni säkerhetskopierat låset tillsammans med nyckeln. Och hur finmaskigt nycklarna är uppdelade avgör vad ni kan radera:

Den svåra delen har vi redan: varje kund har en egen nyckel till själva uppgifterna, vilket verkligen är ovanligt och är förutsättningen för mittenraden. I dag fungerar vår radering på det vanliga sättet — den gäller produktionsdata, och säkerhetskopiorna gallras bort enligt sitt eget rotationsschema. Att gå över till mittenraden är ett avgränsat arbete, inte ett marknadsföringspåstående, och vi berättar exakt hur långt det har kommit när ni frågar.

Om ni utvärderar en leverantör som påstår att de redan i dag har radering genom nyckelförstöring är de två villkoren ovan precis det ni ska pröva dem på. De flesta har inte tittat på det än.

Vad den inte skyddar er mot

En säkerhetsartikel som bara räknar upp styrkor bör läsas som marknadsföring. Här är begränsningarna, och den första är den viktigaste meningen i texten.

En behörighet som inte borde finnas. Kryptering skyddar data i lagringen. Den ger ingenting mot en för bred behörighet. Om en person får åtkomst till ett område där personen inte har något att göra, låser plattformen upp data åt den personen, korrekt och omedelbart, eftersom det är vad en behörighet betyder. Ingen kryptering räddar er från ett misstag i behörighetsstyrningen. Det gör bara en granskning av vem som har åtkomst till vad, enligt ett fast schema, av någon som förstår organisationen.

En komprometterad applikation. Applikationen har nycklarna. Det måste den, annars skulle den inte kunna visa någon något. Kryptering på fältnivå gör en attack betydligt dyrare och tar bort hela kategorier av attacker, medan applikationen själv är precis lika viktig som förut. Den flyttar måltavlan i stället för att ta bort den.

Legitim export. En användare som får se en skärm kan ta en skärmbild av den, kopiera från den eller exportera den. Varje rapportfunktion är en möjlig utgång där krypteringen redan är borttagen. Det här styrs av åtkomstens omfattning och av revisionsloggning, inte av kryptering.

Strukturen, om än inte innehållet. De läsbara kolumnerna berättar en historia: vilka poster som hör ihop med vilka, hur många det finns, när de skapades. I vissa sammanhang är strukturen i sig känslig. Att hålla den till ett minimum är verkligt arbete som aldrig blir helt klart.

Fjorton frågor att ställa till varje leverantör

Om den här artikeln ska vara användbar till en enda sak, låt det vara den här. Frågorna är svåra att svara osant på och lätta att svara på där arbetet faktiskt är gjort. Ställ dem till varje leverantör som har data om era medarbetare — och ställ dem till oss.

Att publicera en sådan lista innebär tre åtaganden, och det är dem vi vill att ni ska hålla oss ansvariga för. Varje nytt fält klassas när det skapas, aldrig i efterhand. Den osäkra vägen är stängd, inte bara avrådd, så att en inställning som saknas ger ett tydligt fel under utvecklingen i stället för att passera obemärkt i produktion. Och begränsningarna publiceras innan någon frågar efter dem — en leverantör som inte kan berätta vad deras skydd inte täcker har antingen undvikit att titta eller valt att tiga, och båda borde oroa er lika mycket.

Om ni bara tar med er en sak

Frågan att ställa om ett system som har data om människor är aldrig är det krypterat. Alla system är krypterade. Frågan är vem som kan läsa ut innehållet, och vad som skulle krävas för att någon som inte var tänkt att vara med ska hamna på den listan.

Om svaret är ”det gör databasen automatiskt för allt som har en giltig inloggning”, då skyddar det ni har köpt mot ett hot som i stort sett har slutat inträffa, och det intrång som når era kunder kommer att gå till precis som det hade gjort utan det skyddet.

Kryptering på fältnivå är inte gratis, inte heltäckande och ingen ersättning för behörighetsstyrning. Det är ett medvetet beslut att göra databasen permanent oförmögen att läsa det den innehåller — och att betala för det med mindre bekväm sökning, extra designarbete och en långsammare väg från idé till funktion. Vi tror att det är en riktig avvägning, och vi tror att de kommande åren kommer att visa det tydligare än någon artikel kan.

Var kommer beläggen ifrån?

Här citeras medvetet ingen intrångsstatistik, inga branschundersökningar och ingen leverantörsfinansierad forskning. De flesta siffror som sprids flitigt inom området kommer ursprungligen från marknadsföringsmaterial. Varje påstående om hur de här skydden beter sig följer av hur de fungerar, och den som inte håller med kan kontrollera det mot dokumentationen till vilken databasprodukt som helst i stället för att ta oss på orden. Beskrivningen av vår egen plattform har kontrollerats mot det som faktiskt är i drift.