Diskkryptering på en maskin du inte äger

Varje leverantör som säljer integritet säger att diskarna är krypterade. Det stämmer oftast, och det besvarar oftast en fråga ingen ställde. Kryptering har tre tillstånd att hålla reda på, och en server tillbringar hela sitt arbetsliv i det enda som fullständig diskkryptering inte täcker. Det här är var gränsen faktiskt går, vad som ligger på var sida om den, och vilken av de två lösningar som säljs under samma fyra ord som är den där du själv har nyckeln.

Tre tillstånd, och det ingen krypterar

Data beskrivs som befinna sig i ett av tre tillstånd, och branschen har övertygande löst två av dem. Vilande data är data som ligger på en disk som ingenting just då läser: löst genom fullständig diskkryptering, och genom kryptering i databasen eller objektlagret ovanpå den. Data i rörelse är data som korsar ett nätverk: löst genom TLS, så grundligt att ett felaktigt utfärdat certifikat numera är en nyhet. Data i bruk är data inläst i minnet hos en körande process — vilket är där varje byte din server levererar måste befinna sig, hur kort det än är, för att överhuvudtaget levereras.

Uttrycket kryptering av vilande data är exakt, och det är exakt på ett sätt som är lätt att läsa förbi. Det beskriver tillståndet din data befinner sig i medan maskinen är avstängd. En server är en maskin vars hela uppgift är att inte vara avstängd. Under de månader den är i drift står dess volymer öppna, dess databasfiler är läsbara för varje process som körs som rätt användare, och krypteringen gör ingenting annat än att vänta på ett strömavbrott.

Det andra dessa fyra ord döljer är vems nyckel det är. Två helt olika lösningar säljs under dem. En leverantör kan kryptera lagringslagret med nycklar leverantören förvaltar: det skyddar leverantörens process för att ta maskiner ur bruk och minskar dess egen exponering vid ett intrång, och det skyddar dig faktiskt mot en disk som lämnar byggnaden — men parten som har nyckeln är parten du egentligen frågade om. Eller så kan volymen krypteras inne i din egen maskin, med en nyckel som inte finns någon annanstans än i ditt huvud och i minnet hos en körande kärna. Bara den andra lösningen förändrar vad en tredje part kan komma över, och bara den andra är vad resten av den här guiden menar.

Inget av detta är ett argument mot att kryptera diskar. Det är ett argument för att veta vilka av de åtta scenarierna nedan du har täckt och vilka du inte har. Kryptering som stoppar en enda verklig sak är värd att ha; kryptering du tror stoppar åtta är värre än ingen alls, eftersom tron avslutar samtalet.

Var nyckeln finns medan maskinen körs

När du låser upp en LUKS-volym är lösenfrasen du skriver inte själva nyckeln. Den packar upp en huvudnyckel som ligger lagrad i volymens huvud, och den huvudnyckeln hålls sedan i kärnans minne tills volymen stängs eller maskinen förlorar ström. Varje läsning och varje skrivning går via den. Det finns ingen konfiguration av en fungerande krypterad disk där nyckeln ligger någon annanstans medan disken används — det är ingen implementationsdetalj någon kunde åtgärda, det är vad det innebär att använda en krypterad disk.

På hårdvara du äger sitter det minnet i ett chassi i ett rum du kontrollerar, och angreppet mot det är ovanligt: fysisk närvaro, och de sekunder av restdata minneskretsar behåller efter att strömmen bryts. På en virtuell server skiljer sig läget till sin art, inte bara till sin grad. Din kärnas minne är ett område av värdens minne. Hypervisorn kan adressera det per definition, eftersom just den adresseringen var hur hypervisorn gav dig det från början. Tre helt vanliga åtgärder läser det:

• En live-migrering. Att flytta en körande virtuell maskin mellan fysiska värdar kopierar dess minne medan den kör. Det är en funktion — det är så en värd underhålls utan att du behöver starta om — och din huvudnyckel finns bland de sidor som kopieras.
• En ögonblicksbild som innefattar minnet. En ögonblicksbild av enbart disken för en volym du krypterat själv innehåller chiffertext och inget annat. En ögonblicksbild som låter maskinen återuppta exakt där den var innehåller nyckeln, eftersom nyckeln är en del av vad ”exakt där den var” består av.
• En minnesdump. Din gästs minne finns inom adressrymden för en process på värden. Att läsa den processens minne är en rutinmässig felsökningsåtgärd, och verktygen ingår i virtualiseringsstacken snarare än att behöva smugglas in.

Inget av detta påstår att din leverantör gör något av detta. Det påstår att dessa åtgärder inte kräver någon medverkan från dig, inte lämnar något spår i något du kan se, och inte går att skilja från vanligt plattformsunderhåll. Det är den enda egenskap som är värd att skriva in i en hotmodell: inte vad någon gör, utan vad de är i stånd att göra utan att du märker det. Samma resonemang ett steg längre ut är varför registret och proxyn framför dig hör hemma på samma lista som värden.

Omstartsproblemet, och genvägen som upphäver det

En krypterad rotvolym måste låsas upp innan systemet startat tillräckligt långt för att ta emot en SSH-anslutning. På en bärbar dator skriver du lösenfrasen på tangentbordet. På en maskin två tusen kilometer bort, i en byggnad du aldrig satt din fot i, finns inget tangentbord du kan nå i det ögonblick det behövs. Varje praktiskt svar på det är en avvägning — och en av de fyra nedan är ingen avvägning alls, utan ett sätt att bara se ut som en.

Fyra sätt att låsa upp en krypterad rotvolym på en maskin på distans

Metod	Obevakad omstart	Stoppar en stulen disk	Vad det kostar dig
SSH in i uppstartsavbilden	Nej	Ja	En minimal SSH-server inuti initramfs låter dig ansluta och skriva lösenfrasen. Maskinen förblir nere tills en människa är vaken och nåbar. Det här är det ärliga alternativet, och kostnaden är verklig: en omstart klockan fyra på natten är ett driftstopp tills någon märker det.
Nätverksbunden nyckel	Ja	Delvis	Maskinen hämtar sin upplåsningsnyckel vid start från en server du kör någon annanstans, och du kan vägra lämna ut en nyckel till en maskin som flyttats eller som du inte startat om själv. Nyckelservern måste hållas i drift, och den måste stå någonstans samma beslut inte når — annars har du bara delat nyckeln på två dörrar med ett lås.
Nyckelfil i uppstartsavbilden	Ja	Nej	Nyckeln ligger i initramfs, initramfs ligger på en okrypterad uppstartspartition, och uppstartspartitionen ligger på disken du försökte skydda. Den som tar disken tar nyckeln med sig. Den här konfigurationen är vanlig, den startar utmärkt, och den skyddar mot ingenting alls.
Förseglad till en TPM	Ja	Delvis	På hårdvara du äger släpper en riktig säkerhetskrets ifrån sig nyckeln bara till en uppstartskedja som inte har ändrats. På en virtuell server emuleras den kretsen av värden, så att försegla en nyckel till den ger nyckeln till exakt den part du försökte försegla den bort ifrån.

Den tredje raden förtjänar en lång blick. Det är dit du hamnar när kravet skrevs som diskarna ska vara krypterade och ingen frågade i vilket syfte. Revisionen godkänns. Blockenheten är verkligen krypterad. Nyckeln följer med på samma bit metall, i en fil en räddningsshell läser på ungefär fyra sekunder.

Det här är också den tydligaste praktiska skillnaden mellan en hyrd virtuell maskin och en maskin du äger själv. På dedikerad hårdvara ger hanteringsgränssnittet utanför bandet dig en konsol som överlever en omstart, så att den första raden slutar vara ett driftstopp och blir ett tvåminutersavbrott — och problemet med den emulerade kretsen i fjärde raden försvinner, eftersom kretsen är fastlödd på ett kort snarare än skriven i mjukvara av den part du försöker skydda dig mot.

Vad fullständig diskkryptering faktiskt köper

Samma fråga, ställd på åtta sätt. Kolumnen som spelar roll är den sista, eftersom något annat gör nytta i varje rad där kryptering inte hjälper — och att sätta namn på det något är hela värdet av övningen.

Åtta scenarier, och om fullständig diskkryptering förändrar utfallet

Scenario	Kryptering hjälper	Vad som faktiskt avgör det
En disk tas ur bruk, säljs vidare eller returneras på garanti	Ja	Inget annat täcker det här. Diskar lämnar datacenter ständigt, sanering är en process, och processer misslyckas tyst. Det här är scenariot fullständig diskkryptering uppfanns för, och mot det fungerar den exakt som utlovat.
Maskinen är avstängd och disken tas ut	Ja	Samma skydd med samma gräns, och gränsen är ordet avstängd. En maskin som tas medan den kör är en maskin som tas upplåst, med öppna volymer och nyckeln närvarande.
En säkerhetskopia finns någon annanstans	Delvis	Kryptering på källvolymen gör ingenting för en kopia av datan. Det som avgör är om säkerhetskopian krypterades innan den lämnade maskinen, med en nyckel som inte lagras på maskinen som säkerhetskopieras.
Plattformen tar en ögonblicksbild	Delvis	En ögonblicksbild av enbart disken för en volym du krypterat själv är chiffertext och oanvändbar för alla utan din lösenfras. En ögonblicksbild som fångar minnestillståndet fångar nyckeln med sig. Båda kallas ögonblicksbilder.
Någon får ett skal på den körande maskinen	Nej	Volymen är redan öppen, och en inkräktare läser filer snarare än block. Patchning, minsta möjliga behörighet, och autentiseringsuppgifter som inte återanvänds mellan tjänster avgör den här raden, och kryptering bidrar inte med något till den.
Värdoperatören, eller den som har värdoperatörens åtkomst	Nej	Bara kryptering vars nyckel aldrig kommer in i maskinen alls. Kryptering av hårdvaruminnet är det enda undantaget, och det är avstängt som standard överallt, vilket täcks i nästa avsnitt.
Ett beslut delges leverantören	Delvis	Jurisdiktionen avgör vem som får fråga och på vilka grunder; kryptering avgör vad ett svar skulle kunna innehålla. Vår egen publicerade hållning är två separata meningar, och båda spelar roll: vi förvarar inte kunders nycklar och kan inte lämna ut dem, och en okrypterad volym på en virtuell server kräver ändå ett beslut som namnger just den tjänsten.
Du måste anmäla ett dataintrång	Delvis	Om dina användare finns i EU nämner artikel 32 i GDPR kryptering bland de åtgärder som förväntas av dig, och artikel 34 upphäver skyldigheten att underrätta de registrerade — aldrig tillsynsmyndigheten — om datan gjorts obegriplig. Om det gäller avgörs helt av var nyckeln fanns när datan lämnade maskinen.

Ovanför disken: vad som överlever en fientlig värd

Allt hittills gäller ett lager som stannar vid blockenheten. Tre saker ligger ovanför det, och tillsammans är de de enda svaren på tabellens femte, sjätte och sjunde rad.

Kryptera ovanför applikationen, inte under den

Fältnivåkryptering innebär att applikationen krypterar ett värde innan det når databasen och dekrypterar det när det läses tillbaka. En dump av databasen ger chiffertext, oavsett vem som tog dumpen och på vilken väg. Det kostar dig möjligheten att söka i eller indexera de krypterade kolumnerna, vilket är varför den hör hemma på de få fält som förtjänar den — meddelandetexter, uppladdade dokument, tredjepartstoken — och inte på allt. Slutpunkten på den vägen är totalsträckkryptering: nyckeln tillhör användaren, servern håller aldrig klartext, och en fientlig värd får ingenting eftersom det inte finns något där att få. Det är den enda arkitekturen på den här sidan som är genuint likgiltig för vem som sköter maskinvaran, och det är ett produktbeslut långt innan det är ett infrastrukturbeslut.

Säkerhetskopior är ett eget beslut, inte en följd

Det vanligaste sättet data lämnar en krypterad maskin på är en säkerhetskopia. En ögonblicksbild som skickas till objektlagring, en databasdump som synkas till en andra leverantör, ett arkiv som hämtas ner till en arbetsstation — ingen av dem ärver någonting alls från volymen de kom ifrån. Kryptera i det ögonblick datan skrivs in i säkerhetskopian, med en nyckel som förvaras någonstans maskinen själv inte kan nå, så att en komprometterad server inte kan dekryptera sin egen historik. Återställ sedan en, på en annan maskin, innan du behöver det: en krypterad säkerhetskopia du inte kan öppna är ett ovanligt städat sätt att förlora allt på en gång. En kopia i ett annat land är också en kopia under ett annat regelverk, vilket är en andra jurisdiktion du valt utan att märka det.

Minneskryptering, och varför du förmodligen inte har den

Tillståndet ingen krypterar har faktiskt ett hårdvarusvar. Tillägg för konfidentiell databehandling — AMD:s SEV-SNP, Intels TDX — krypterar en gästs minne och registertillstånd under en nyckel som hålls av en separat säkerhetsprocessor snarare än av hypervisorn, så att en värd som dumpar minnet får tillbaka chiffertext. Det är verkligt och det finns redan i drift. Det är också begränsat: SEV-SNP kräver EPYC-kisel av tredje generationen eller nyare, värden måste medvetet konfigureras för det, och gästen måste intyga att den fått det. Nästan ingen generell virtuell server erbjuder det, och ingen erbjuder det tyst. Utgå från att du inte har det om inte en leverantör skriftligen säger att du har det och kan berätta hur du själv verifierar intyget.

En konfiguration som är ärlig om sina gränser

Inget av det här slutar vid bry dig inte. Det slutar vid en konfiguration vars gränser du kan säga högt utan att rygga.

1. Skriv ner det enda scenario du försvarar dig mot (5 min). En uttjänt disk, en maskin som beslagtas medan den kör, en fientlig värd, ett domstolsbeslut, ett intrång du måste anmäla. De har olika svar, och en konfiguration inriktad på alla fem uppnår med säkerhet ingen av dem.
2. Lägg krypteringen där din nyckel finns (beslut). Om leverantören har nyckeln har du köpt skydd mot en disk som lämnar byggnaden och inget mer än det. Vill du ha mer än så måste volymen låsas upp inifrån gästen, av dig, med något plattformen aldrig ser.
3. Kryptera datavolymen snarare än roten (konfiguration). En krypterad rot innebär att varje omstart väntar på dig. En separat krypterad volym som rymmer databaskatalogen, uppladdningarna och hemligheterna låter maskinen komma tillbaka av sig själv medan den känsliga delen förblir stängd tills du öppnar den. Det här är den kompromiss de flesta små plattformar borde göra, och nästan ingen skriver ner den.
4. Lämna aldrig nyckelfilen på den okrypterade uppstartspartitionen (regel). Om maskinen startar obevakat utan nyckelserver och utan konsol ligger nyckeln på disken; det finns ingen tredje möjlighet. Det är en fullt rimlig avvägning när en stulen disk verkligen är hela din hotmodell, och självbedrägeri i varje annat fall.
5. Kryptera säkerhetskopior i skrivögonblicket, med en nyckel som förvaras någon annanstans (konfiguration). Återställ sedan en på en annan maskin, en dag då ingenting brinner.
6. Säg i en enda mening vad du har täckt (5 min). Ungefär: en angripare som drar ut den här disken ur racket får ingenting, och vem som helst med root på den körande maskinen eller på dess värd får allt. Om den meningen är obekväm att skriva ner beror det på att den är sann.

Två av de sex är beslut och fyra är konfiguration. Besluten tar en eftermiddag och konfigurationen tar en timme, och timmen är värd ingenting utan eftermiddagen. Att göra dem i omvänd ordning är hur man hamnar i tredje raden i den första tabellen, med en maskin som klarar revisionen och skyddar en från ingen.

Vilket scenario du försvarar dig mot är en hotmodelleringsfråga innan den är en krypteringsfråga, och entimmesversionen av den övningen ger meningen i steg sex nästan som en biprodukt. Om svaret visar sig vara ett domstolsbeslut snarare än en disk, ligger lagret som avgör utfallet inte alls på din disk — det är vems lag som når din leverantör, och hur du kontrollerar det innan du litar på det.

Skrivet av de ingenjörer som driver plattformen, och omläst idag. Om något här är fel eller har blivit inaktuellt, säg till via panelen – det är därifrån ungefär hälften av dessa kommer.