Lemeztitkosítás egy olyan gépen, amely nem az Öné

Minden szolgáltató, amely adatvédelmet árul, azt állítja, hogy a lemezei titkosítva vannak. Ez legtöbbször igaz, és legtöbbször egy olyan kérdésre válaszol, amelyet senki sem tett fel. A titkosításnak három állapota van, amelyekkel számolni kell, és a szerver a teljes működő élettartamát abban az állapotban tölti, amelyet a teljes lemeztitkosítás nem fed le. Ez az útmutató azt mutatja meg, hol húzódik valójában a határvonal, mi van a két oldalán, és a négy azonos szó alatt árult két megoldás közül melyikben van Önnél a kulcs.

Három állapot, és amelyiket senki sem titkosítja

Az adatoknak három állapotát szokás megkülönböztetni, és az iparág meggyőzően megoldotta ezek közül kettőt. A nyugalmi állapot azt jelenti, hogy az adat egy olyan lemezen fekszik, amelyet éppen semmi sem olvas: ezt a teljes lemeztitkosítás oldja meg, kiegészítve az arra rétegzett adatbázis- vagy objektumtár-titkosítással. A továbbítás közbeni állapot azt jelenti, hogy az adat egy hálózaton kel át: ezt a TLS oldja meg, mégpedig olyan alaposan, hogy egy hibásan kiállított tanúsítvány ma már híranyag. A használat közbeni állapot azt jelenti, hogy az adat egy futó folyamat memóriájába van betöltve — és minden bájtnak, amelyet az Ön szervere kiszolgál, előbb vagy utóbb ide kell kerülnie ahhoz, hogy egyáltalán kiszolgálható legyen.

A nyugalmi állapotban titkosítva kifejezés pontos, és épp azért könnyű átsiklani felette, mert az. Azt az állapotot írja le, amelyben az adat akkor van, amikor a gép ki van kapcsolva. A szerver pedig olyan gép, amelynek egész feladata az, hogy ne legyen kikapcsolva. A hónapokig tartó működés alatt a kötetei nyitva állnak, az adatbázisfájljai olvashatók minden megfelelő jogosultsággal futó folyamat számára, a titkosítás pedig semmit sem tesz, csupán az áramkimaradásra vár.

A négy szó másik dolgot is elrejt: kié valójában a kulcs. Két teljesen különböző megoldást árulnak alattuk. A szolgáltató titkosíthatja a tárolási réteget a saját kezelésű kulcsaival: ez védi a szolgáltató selejtezési folyamatát és csökkenti a saját adatszivárgási kockázatát, és valóban véd egy olyan meghajtó ellen, amely elhagyja az épületet — de a kulcsot birtokló fél pontosan az a fél, aki felől Ön eredetileg érdeklődött. Vagy a kötet titkosítható a gépen belül, olyan kulccsal, amely sehol máshol nem létezik, csak az Ön fejében és egy futó kernel memóriájában. Egyedül ez a második megoldás változtatja meg azt, amit egy harmadik fél megszerezhet, és egyedül erre vonatkozik ennek az útmutatónak a további része.

Mindebből nem az következik, hogy ne titkosítsa a lemezeit. Az következik, hogy tudnia kell, az alábbi nyolc forgatókönyv közül melyikre nyújt fedezetet, és melyikre nem. Egy olyan titkosítás, amely egyetlen valódi dolgot megakadályoz, megéri; egy olyan, amelyről azt hiszi, hogy nyolcat akadályoz meg, rosszabb a semminél, mert ez a hit lezárja a beszélgetést.

Hol van a kulcs, amíg a gép fut

Amikor feloldja a LUKS-kötetet, a beírt jelmondat nem maga a kulcs. A jelmondat egy, a kötet fejlécében tárolt mesterkulcsot csomagol ki, és ez a mesterkulcs ezután a kernel memóriájában marad, amíg a kötetet le nem zárják, vagy a gép áram alá nem esik. Minden olvasás és minden írás rajta keresztül halad. Nincs olyan működő titkosított lemez, amelynél a kulcs máshol lenne, amíg a lemezt használják — ez nem egy javítható implementációs részlet, hanem maga az, amit a titkosított lemez használata jelent.

Egy saját tulajdonú hardveren ez a memória egy Ön által ellenőrzött helyiségben lévő gépházban van, és az ellene irányuló támadás egzotikus: fizikai jelenlétet igényel, és azt a néhány másodpercnyi maradványt használja ki, amelyet a memóriachipek az áramkimaradás után még megőriznek. Virtuális szerveren a helyzet nem csupán fokában, hanem jellegében is más. Az Ön kerneljének memóriája a host memóriájának egy tartománya. A hypervisor definíció szerint el tudja érni, hiszen éppen ennek az elérésével adta azt Önnek. Három teljesen hétköznapi művelet olvassa ezt a memóriát:

• Élő migráció. Egy futó virtuális gép fizikai hostok közötti áthelyezése a memóriáját is átmásolja, miközben az fut. Ez egy funkció — így tartható karban a host anélkül, hogy Önt újra kellene indítani —, és a mesterkulcsa is a másolt lapok között van.
• Memóriát is tartalmazó pillanatkép. Egy Ön által titkosított kötet puszta lemez-pillanatképe csak titkosított szöveget tartalmaz, mást semmit. Egy olyan pillanatkép viszont, amely lehetővé teszi, hogy a gép pontosan onnan folytassa, ahol tartott, magát a kulcsot is tartalmazza, mert a kulcs is része annak, hogy „pontosan hol tartott”.
• Memóriadömpölés. A vendégrendszer memóriája egy, a hoston futó folyamat címterében él. E folyamat memóriájának olvasása rutinszerű hibakeresési művelet, és az eszköz maga is a virtualizációs stack része, nem kell csempészni.

Mindez nem azt állítja, hogy a szolgáltatója bármelyiket meg is teszi. Azt állítja, hogy ezekhez a műveletekhez nincs szükség az Ön közreműködésére, semmilyen Ön által látható nyomot nem hagynak, és megkülönböztethetetlenek a szokásos platformkarbantartástól. Ez az egyetlen tulajdonság, amelyet érdemes egy fenyegetettségi modellbe beleírni: nem az, hogy valaki mit tesz, hanem az, hogy mire képes anélkül, hogy Ön észrevenné. Ugyanez a logika eggyel kijjebb az oka annak, hogy a registry és az Ön előtt álló proxy ugyanarra a listára kerül, mint a host.

Az újraindítás gondja, és a gyorsmegoldás, amely aláássa

Egy titkosított gyökérkötetet fel kell oldani, mielőtt a rendszer eljut odáig, hogy SSH-kapcsolatot fogadjon. Egy laptopon a jelmondatot a billentyűzeten gépeli be. Egy kétezer kilométerre lévő, Ön által soha be nem lépett épületben álló gépnél nincs olyan billentyűzet, amelyet abban a pillanatban elérne. Minden gyakorlati válasz erre egyfajta kompromisszum — az alábbi négy közül azonban az egyik egyáltalán nem kompromisszum, csupán annak látszatát kelti.

Négy módszer egy titkosított gyökérkötet feloldására egy távoli gépen

Módszer	Felügyelet nélküli újraindítás	Megállítja az ellopott lemezt	Mibe kerül Önnek
SSH a boot image-be	Nem	Igen	Egy minimális SSH-szerver az initramfs-ben lehetővé teszi, hogy csatlakozzon és beírja a jelmondatot. A gép addig marad leállítva, amíg egy ember ébren és elérhető nincs. Ez az őszinte megoldás, és az ára valós: egy hajnali négyórai újraindítás kiesés marad, amíg valaki észre nem veszi.
Hálózathoz kötött kulcs	Igen	Részben	A gép indításkor egy máshol futtatott szerverről kéri le a feloldókulcsot, és Ön megtagadhatja a kulcs kiadását egy olyan gépnek, amely elköltözött, vagy amelyet nem Ön indított újra. A kulcsszervernek fent kell maradnia, és olyan helyen kell lennie, amelyet ugyanaz a végzés nem ér el — különben a kulcsot két ajtóra osztotta szét, de csak egyetlen zárral.
Kulcsfájl a boot image-ben	Igen	Nem	A kulcs az initramfs-ben van, az initramfs egy titkosítatlan boot partíción van, a boot partíció pedig azon a lemezen van, amelyet éppen védeni próbált. Aki elviszi a lemezt, a kulcsot is elviszi vele. Ez a beállítás gyakori, kifogástalanul indul, és semmi ellen nem véd.
TPM-hez zárva	Igen	Részben	Egy saját tulajdonú hardveren egy valódi biztonsági chip csak egy meg nem változtatott boot-láncnak adja ki a kulcsot. Egy virtuális szerveren ezt a chipet a host emulálja, így a kulcs hozzá zárása pontosan annak a félnek adja át a kulcsot, akitől el akarta zárni.

A harmadik sor hosszabb elgondolkodást érdemel. Ide jut, ha a követelményt úgy fogalmazták meg, hogy a lemezeknek titkosítva kell lenniük, és senki sem kérdezte meg, minek. Az audit átmegy. A blokkeszköz valóban titkosítva van. A kulcs pedig ugyanazon a fémdarabon utazik, egy olyan fájlban, amelyet egy helyreállító shell nagyjából négy másodperc alatt kiolvas.

Ez egyben a legvilágosabb gyakorlati különbség egy bérelt virtuális gép és egy saját gép között is. Dedikált hardveren a sávon kívüli menedzsmentfelület egy olyan konzolt biztosít, amely túléli az újraindítást, így az első sorból nem kiesés lesz, csupán kétperces megszakítás — a negyedik sorban szereplő emulált chip problémája pedig eltűnik, mert a chip egy alaplapra van forrasztva, nem pedig annak a félnek a szoftverében létezik, aki ellen éppen védekezik.

Mit nyújt valójában a teljes lemeztitkosítás

Ugyanaz a kérdés, nyolcféleképpen feltéve. Az utolsó oszlop számít igazán, mert minden olyan sorban, ahol a titkosítás nem segít, valami más igen — és ennek a valaminek a megnevezése adja a gyakorlat teljes hasznát.

Nyolc forgatókönyv, és hogy a teljes lemeztitkosítás megváltoztatja-e a kimenetelt

Forgatókönyv	A titkosítás segít	Ami valójában eldönti
Egy meghajtót selejteznek, továbbértékesítenek vagy garanciában visszaküldenek	Igen	Erre semmi más nem nyújt fedezetet. Meghajtók folyamatosan hagyják el az adatközpontokat, a törlés egy folyamat, a folyamatok pedig csendben elromlanak. Erre a forgatókönyvre találták ki a teljes lemeztitkosítást, és ez ellen pontosan úgy működik, ahogyan ígérik.
A gépet kikapcsolják, és kiveszik a lemezt	Igen	Ugyanaz a védelem, ugyanazzal a határral, és ez a határ a kikapcsolva szó. Egy futás közben elvitt gép feloldott állapotban vitt gép: a kötetei nyitva vannak, a kulcsa pedig a memóriában lakik.
Egy biztonsági másolat máshol van	Részben	A forráskötet titkosítása semmit sem ér az adat egy másolata szempontjából. Az dönt, hogy a mentést azelőtt titkosították-e, hogy elhagyta a gépet, olyan kulccsal, amelyet nem magán a mentett gépen tárolnak.
A platform pillanatképet készít	Részben	Egy Ön által titkosított kötet puszta lemez-pillanatképe titkosított szöveg, amellyel a jelmondata nélkül senki sem tud mit kezdeni. Egy olyan pillanatkép azonban, amely a memória állapotát is rögzíti, a kulcsot is rögzíti vele együtt. Mindkettőt pillanatképnek hívják.
Valaki parancssori hozzáférést szerez a futó géphez	Nem	A kötet ekkor már nyitva van, a behatoló pedig fájlokat olvas, nem blokkokat. Ezt a sort a foltozás, a legkisebb jogosultság elve, valamint a szolgáltatások között nem újrafelhasznált hitelesítő adatok döntik el, a titkosítás pedig semmivel sem járul hozzá.
A host üzemeltetője, vagy bárki, aki hozzáfér az üzemeltető jogosultságaihoz	Nem	Csak az a titkosítás segít, amelynek kulcsa soha nem is kerül a gépre. A hardveres memóriatitkosítás az egyetlen kivétel, ez azonban mindenhol alapértelmezetten ki van kapcsolva — erről a következő szakasz szól.
Végzést kézbesítenek a szolgáltatónak	Részben	A joghatóság dönti el, ki kérdezhet és milyen alapon; a titkosítás dönti el, mit tartalmazhat a válasz. A saját nyilvánosan közölt álláspontunk két külön mondatból áll, és mindkettő számít: nem birtokoljuk az ügyfelek kulcsait, ezért nem is tudjuk átadni őket, egy virtuális szerveren lévő titkosítatlan kötethez pedig továbbra is az adott szolgáltatást megnevező végzés szükséges.
Adatvédelmi incidenst kell bejelentenie	Részben	Ha a felhasználói az EU-ban vannak, a GDPR 32. cikke nevesítve említi a titkosítást az elvárt intézkedések között, a 34. cikk pedig feloldja az érintettek — sosem a hatóság — értesítésének kötelezettségét, ha az adatot értelmezhetetlenné tették. Hogy ez alkalmazható-e, kizárólag azon múlik, hol volt a kulcs, amikor az adat kikerült.

A lemezen túl: mi marad ellenséges host esetén

Eddig minden egy olyan rétegről szólt, amely a blokkeszköznél véget ér. Efölött három dolog áll, és együtt ők adják az egyetlen választ a táblázat ötödik, hatodik és hetedik sorára.

Titkosítson az alkalmazás fölött, ne alatta

A mezőszintű titkosítás azt jelenti, hogy az alkalmazás titkosítja az értéket, mielőtt az az adatbázisba kerülne, és visszaolvasáskor fejti vissza. Az adatbázis egy dump-ja így titkosított szöveget ad, függetlenül attól, ki készítette a dump-ot és milyen úton. Ennek ára az, hogy a titkosított oszlopokban nem lehet keresni vagy indexelni, ezért ezt csak azokra a kevés mezőre érdemes alkalmazni, amelyek megérdemlik — üzenettörzsek, feltöltött dokumentumok, harmadik féltől származó tokenek —, nem pedig mindenre. Ennek az útnak a vége a végpontok közötti titkosítás: a kulcs a felhasználóé, a szerver soha nem látja a nyílt szöveget, és egy ellenséges host semmit sem szerez meg, mert nincs is mit megszereznie. Ez az egyetlen architektúra ezen az oldalon, amely valóban közömbös azzal szemben, ki üzemelteti a vasat, és ez sokkal inkább termékdöntés, mint infrastruktúra-döntés.

A biztonsági mentés külön döntés, nem automatikus következmény

Az adat leggyakrabban egy mentésen keresztül hagyja el a titkosított gépet. Egy objektumtárba feltöltött pillanatkép, egy másik szolgáltatóra szinkronizált adatbázis-dump, egy munkaállomásra letöltött archívum — egyik sem örököl semmit attól a kötettől, ahonnan származik. Titkosítson abban a pillanatban, amikor az adat a mentésbe kerül, olyan kulccsal, amelyet maga a gép nem tud elérni, hogy egy feltört szerver ne tudja visszafejteni a saját múltját. Ezután állítson vissza egyet egy másik gépen, még mielőtt szüksége lenne rá: egy olyan titkosított mentés, amelyet nem tud megnyitni, szokatlanul rendezett módja annak, hogy mindent egyszerre veszítsen el. Egy másik országban tárolt másolat egyben egy másik szabályrendszer alatti másolat is, vagyis egy második joghatóság, amelyet észrevétlenül választott.

Memóriatitkosítás, és miért valószínűleg nincs Önnek ilyene

Arra az állapotra, amelyet senki sem titkosít, van hardveres válasz. A bizalmas számítástechnikai kiterjesztések — az AMD SEV-SNP-je, az Intel TDX-e — a vendégrendszer memóriáját és regiszterállapotát egy különálló biztonsági processzor által birtokolt kulccsal titkosítják, nem a hypervisorral, így egy, a memóriát kiolvasó host csak titkosított szöveget kap. Ez valós, és már elérhető. Ugyanakkor szűk körű is: a SEV-SNP legalább harmadik generációs EPYC szilíciumot igényel, a hostot erre szándékosan be kell állítani, a vendégrendszernek pedig igazolnia kell, hogy ezt megkapta. Szinte egyetlen általános célú virtuális szerver sem kínálja, és amelyik igen, az sem csendben teszi. Feltételezze, hogy Önnek nincs ilyen, hacsak a szolgáltató írásban nem állítja, és nem mondja meg, hogyan ellenőrizheti maga az igazolást.

Egy beállítás, amely őszinte a korlátairól

Mindebből nem az következik, hogy hagyja az egészet. Az következik, hogy jusson el egy olyan beállításig, amelynek korlátait hangosan is ki tudja mondani anélkül, hogy zavarba jönne.

1. Írja le, pontosan mely egyetlen forgatókönyv ellen védekezik (5 perc). Egy selejtezett meghajtó, egy futás közben lefoglalt gép, egy ellenséges host, egy bírósági végzés, egy bejelentendő adatvédelmi incidens. Ezekre eltérő válasz kell, és egy mind az öt ellen célzott beállítás megbízhatóan egyiket sem éri el.
2. Oda tegye a titkosítást, ahol a kulcsa van (döntés). Ha a kulcsot a szolgáltató birtokolja, Ön csak azt a védelmet vásárolta meg, amely egy épületet elhagyó meghajtó ellen szól, semmi mást. Ha ennél többet szeretne, a kötetet a vendégrendszeren belülről, Ön által kell feloldani, olyasmivel, amit a platform sosem lát.
3. Az adatkötetet titkosítsa, ne a gyökeret (beállítás). Egy titkosított gyökér azt jelenti, hogy minden újraindítás Önre vár. Egy külön titkosított kötet, amely az adatbázis-könyvtárat, a feltöltéseket és a titkokat tartalmazza, lehetővé teszi, hogy a gép magától visszatérjen, miközben az érzékeny rész zárva marad, amíg Ön ki nem nyitja. A legtöbb kis platformnak ez a kompromisszum kellene, mégis szinte senki sem írja le.
4. Sose hagyja a kulcsfájlt a titkosítatlan boot partíción (szabály). Ha a gép felügyelet nélkül indul, kulcsszerver és konzol nélkül, akkor a kulcs a lemezen van; harmadik lehetőség nincs. Ez egészen elfogadható kompromisszum, ha valóban egy ellopott meghajtó a teljes fenyegetettségi modellje, minden más esetben viszont önámítás.
5. A mentéseket az írás pillanatában titkosítsa, máshol tárolt kulccsal (beállítás). Majd állítson vissza egyet egy másik gépen, egy olyan napon, amikor éppen semmi nem ég.
6. Egyetlen mondatban mondja ki, mire terjed ki a védelme (5 perc). Valami ilyesmit: aki kihúzza ezt a lemezt a rackből, semmit sem kap, aki viszont root jogosultsággal fér hozzá a futó géphez vagy annak hostjához, mindent megkap. Ha kellemetlen leírni ezt a mondatot, az azért van, mert igaz.

A hat közül kettő döntés, négy pedig beállítás. A döntések egy délutánt vesznek igénybe, a beállítások egy órát, és az az óra semmit sem ér a délután nélkül. Aki fordított sorrendben csinálja, az köt ki az első táblázat harmadik sorában, egy auditon átmenő géppel, amely senkitől sem védi.

Az, hogy melyik forgatókönyv ellen védekezik, előbb fenyegetettségmodellezési kérdés, csak azután titkosítási kérdés, és ennek a gyakorlatnak az egyórás változata szinte melléktermékként adja ki a hatodik lépésben szereplő mondatot. Ha a válasz végül nem egy meghajtó, hanem egy bírósági végzés, akkor a kimenetelt eldöntő réteg egyáltalán nem a lemezén van — hanem az, hogy kinek a joga éri el az Ön szolgáltatóját, és hogyan ellenőrizheti ezt, mielőtt megbízna benne.

A platformot üzemeltető mérnökök írták, és ma újraolvasták. Ha valami itt hibás vagy elavult, jelezze az ügyfélpanelből — ezeknek is körülbelül a fele onnan származik.