Szyfrowanie dysku na cudzej maszynie

Każdy dostawca hostingu, który sprzedaje prywatność, twierdzi, że dyski są szyfrowane. Zwykle to prawda i zwykle odpowiada na pytanie, którego nikt nie zadał. Szyfrowanie ma trzy stany, o które trzeba się martwić, a serwer spędza całe swoje życie robocze w tym jednym, którego pełne szyfrowanie dysku nie obejmuje. Poniżej wyjaśniono, gdzie faktycznie przebiega granica, co leży po każdej jej stronie i który z dwóch rozwiązań sprzedawanych pod tą samą nazwą jest tym, w którym to klient trzyma klucz.

Trzy stany, i ten, którego nikt nie szyfruje

Mówi się, że dane znajdują się w jednym z trzech stanów, a branża w przekonujący sposób rozwiązała dwa z nich. Dane w spoczynku to dane leżące na dysku, którego akurat nikt nie odczytuje: rozwiązuje to pełne szyfrowanie dysku oraz szyfrowanie bazy danych lub magazynu obiektów, nałożone o warstwę wyżej. Dane w tranzycie to dane przemieszczające się przez sieć: rozwiązuje to TLS, na tyle skutecznie, że błędnie wystawiony certyfikat trafia dziś na pierwsze strony. Dane w użyciu to dane wczytane do pamięci działającego procesu — a tam musi się znaleźć każdy bajt serwowany przez serwer, choćby na chwilę, żeby w ogóle mógł zostać podany dalej.

Określenie szyfrowanie danych w spoczynku jest precyzyjne — i precyzyjne w sposób, który łatwo przeoczyć. Opisuje ono stan danych w chwili, gdy maszyna jest wyłączona. Tymczasem cała praca serwera polega właśnie na tym, żeby nie być wyłączonym. Przez miesiące działania jego woluminy są otwarte, pliki bazy danych są czytelne dla każdego procesu działającego z odpowiednimi uprawnieniami, a szyfrowanie nie robi nic poza czekaniem na przerwę w zasilaniu.

Druga rzecz, którą te słowa ukrywają, to czyj to właściwie jest klucz. Pod tą samą nazwą sprzedaje się dwa zupełnie różne rozwiązania. Dostawca może zaszyfrować warstwę pamięci masowej kluczami, którymi sam zarządza: chroni to jego proces wycofywania sprzętu z użytku i zmniejsza jego własną ekspozycję na wyciek, chroni też przed dyskiem, który opuszcza budynek — ale stroną trzymającą klucz jest wtedy właśnie ta strona, o którą pytano. Albo wolumin można zaszyfrować wewnątrz własnej maszyny, kluczem, który nie istnieje nigdzie poza pamięcią osoby, która go zna, i pamięcią działającego jądra systemu. Tylko to drugie rozwiązanie zmienia, co jest w stanie uzyskać strona trzecia, i tylko o nim mówi reszta tego poradnika.

Nic z powyższego nie jest argumentem przeciwko szyfrowaniu dysków. Jest to argument za tym, by wiedzieć, które z ośmiu poniższych scenariuszy zostały pokryte, a które nie. Szyfrowanie, które powstrzymuje jedną realną rzecz, warto mieć; szyfrowanie, o którym sądzi się, że powstrzymuje osiem, jest gorsze niż jego brak, bo to przekonanie kończy rozmowę.

Gdzie jest klucz, gdy maszyna działa

Przy odblokowywaniu woluminu LUKS wpisywane hasło nie jest samym kluczem. Odwija ono klucz główny przechowywany w nagłówku woluminu, a ten klucz główny jest następnie utrzymywany w pamięci jądra, dopóki wolumin nie zostanie zamknięty albo maszyna nie straci zasilania. Przechodzi przez niego każdy odczyt i każdy zapis. Nie istnieje taka konfiguracja działającego zaszyfrowanego dysku, w której klucz znajdowałby się gdzie indziej, podczas gdy dysk jest w użyciu — to nie jest szczegół implementacyjny, który dałoby się poprawić, to po prostu znaczy korzystać z zaszyfrowanego dysku.

Na sprzęcie własnym ta pamięć znajduje się w obudowie, w pomieszczeniu pod pełną kontrolą, a atak na nią jest egzotyczny: wymaga fizycznej obecności i wykorzystania kilku sekund resztkowego ładunku, jaki kości pamięci zatrzymują po odcięciu zasilania. Na serwerze wirtualnym sytuacja różni się nie stopniem, lecz rodzajem. Pamięć jądra systemu jest fragmentem pamięci hosta. Hiperwizor ma do niej dostęp z definicji, bo to właśnie poprzez zaadresowanie jej hiperwizor w ogóle ją przydzielił. Odczytują ją trzy zupełnie zwyczajne operacje:

• Migracja na żywo. Przenoszenie działającej maszyny wirtualnej między fizycznymi hostami kopiuje jej pamięć w trakcie działania. To funkcja — dzięki niej host jest utrzymywany bez restartowania klienta — a klucz główny znajduje się właśnie wśród kopiowanych stron pamięci.
• Migawka obejmująca pamięć. Migawka samego dysku, zaszyfrowanego samodzielnie, zawiera wyłącznie szyfrogram i nic poza tym. Migawka pozwalająca maszynie wznowić działanie dokładnie w tym samym miejscu zawiera też klucz, ponieważ klucz jest częścią tego, z czego składa się „dokładnie to samo miejsce”.
• Zrzut pamięci. Pamięć maszyny gościa znajduje się w przestrzeni adresowej procesu działającego na hoście. Odczyt pamięci tego procesu to rutynowa operacja debugowania, a odpowiednie narzędzia są częścią standardowego stosu wirtualizacji, więc nie trzeba ich niczym przemycać.

Nic z powyższego nie twierdzi, że dany dostawca robi którąkolwiek z tych rzeczy. Stwierdza jedynie, że te działania nie wymagają żadnej współpracy ze strony klienta, nie zostawiają śladu w niczym, co można zobaczyć, i są nieodróżnialne od zwykłej konserwacji platformy. To jedyna właściwość, którą warto zapisać w modelu zagrożeń: nie to, co ktoś robi, lecz to, co jest w stanie zrobić, nie dając się zauważyć. Ten sam tok rozumowania, o warstwę dalej, jest powodem, dla którego rejestr obrazów i serwer proxy stojący przed maszyną należą do tej samej listy co host.

Problem restartu i skrót, który go unieważnia

Zaszyfrowany wolumin główny musi zostać odblokowany, zanim system zdąży się rozruchowo rozwinąć na tyle, by przyjąć połączenie SSH. Na laptopie hasło wpisuje się z klawiatury. Na maszynie oddalonej o dwa tysiące kilometrów, w budynku, w którym nikt nigdy nie postawił nogi, żadna klawiatura nie jest w zasięgu w potrzebnym momencie. Każda praktyczna odpowiedź na ten problem to kompromis — a jeden z czterech poniższych wcale nim nie jest, tylko sprawia takie wrażenie.

Cztery sposoby odblokowania zaszyfrowanego woluminu głównego na zdalnej maszynie

Metoda	Restart bez obsługi	Powstrzymuje skradziony dysk	Co to kosztuje
SSH do obrazu rozruchowego	Nie	Tak	Minimalny serwer SSH wewnątrz initramfs pozwala się połączyć i wpisać hasło. Maszyna pozostaje wyłączona, dopóki ktoś nie jest dostępny i przytomny. To uczciwa opcja, a jej koszt jest realny: restart o czwartej nad ranem oznacza przestój, dopóki ktoś tego nie zauważy.
Klucz powiązany z siecią	Tak	Częściowo	Maszyna przy rozruchu pobiera klucz odblokowujący z serwera uruchomionego gdzie indziej, dzięki czemu można odmówić wydania klucza maszynie, która się przemieściła lub której nikt nie restartował. Serwer kluczy musi być stale dostępny i musi znajdować się tam, gdzie nie sięgnie ten sam nakaz — inaczej klucz zostaje rozdzielony między dwoje drzwi zamkniętych na jeden zamek.
Plik klucza w obrazie rozruchowym	Tak	Nie	Klucz znajduje się w initramfs, initramfs leży na niezaszyfrowanej partycji rozruchowej, a partycja rozruchowa leży na tym samym dysku, który miał być chroniony. Kto zabiera dysk, zabiera wraz z nim klucz. Ta konfiguracja jest powszechna, uruchamia się bez zarzutu i nie chroni zupełnie przed niczym.
Zapieczętowany w TPM	Tak	Częściowo	Na sprzęcie własnym prawdziwy układ zabezpieczający wydaje klucz wyłącznie niezmienionemu łańcuchowi rozruchowemu. Na serwerze wirtualnym ten układ jest emulowany przez hosta, więc zapieczętowanie klucza w nim oddaje go dokładnie tej stronie, przed którą miał być zabezpieczony.

Trzeci wiersz zasługuje na dłuższą uwagę. To miejsce, w którym się kończy, gdy wymaganie zapisano jako dyski muszą być szyfrowane i nikt nie zapytał po co. Audyt przechodzi pomyślnie. Urządzenie blokowe rzeczywiście jest zaszyfrowane. Klucz jedzie na tym samym kawałku metalu, w pliku, który powłoka ratunkowa odczyta w jakieś cztery sekundy.

To także najbardziej wyraźna praktyczna różnica między wynajętą maszyną wirtualną a sprzętem własnym. Na sprzęcie dedykowanym interfejs zarządzania poza pasmem daje konsolę, która przetrwa restart, dzięki czemu pierwszy wiersz przestaje być przestojem i staje się dwuminutową przerwą — a problem emulowanego układu z czwartego wiersza znika, bo układ jest przylutowany do płyty, a nie napisany w oprogramowaniu przez stronę, przed którą trzeba się bronić.

Co naprawdę daje pełne szyfrowanie dysku

To samo pytanie, zadane na osiem sposobów. Liczy się ostatnia kolumna, bo w każdym wierszu, w którym szyfrowanie nie pomaga, pomaga coś innego — a wskazanie tego czegoś jest całą wartością tego ćwiczenia.

Osiem scenariuszy i to, czy pełne szyfrowanie dysku zmienia wynik

Scenariusz	Szyfrowanie pomaga	Co naprawdę decyduje
Dysk jest wycofywany z użytku, odsprzedawany lub zwracany z gwarancji	Tak	Nic innego tego nie pokrywa. Dyski nieustannie opuszczają centra danych, sanityzacja jest procesem, a procesy zawodzą po cichu. To scenariusz, dla którego wymyślono pełne szyfrowanie dysku, i w tym przypadku działa ono dokładnie tak, jak obiecano.
Maszyna jest wyłączona, a dysk wymontowany	Tak	Ta sama ochrona, z tą samą granicą — a granicą jest słowo wyłączona. Maszyna zabrana w trakcie działania to maszyna zabrana odblokowana, z otwartymi woluminami i kluczem obecnym w pamięci.
Kopia zapasowa znajduje się gdzie indziej	Częściowo	Szyfrowanie woluminu źródłowego nic nie daje kopii danych. Decyduje to, czy kopia zapasowa została zaszyfrowana zanim opuściła maszynę, kluczem, który nie jest przechowywany na kopiowanej maszynie.
Platforma wykonuje migawkę	Częściowo	Migawka samego dysku, zaszyfrowanego samodzielnie, to szyfrogram bezużyteczny dla każdego bez odpowiedniego hasła. Migawka obejmująca stan pamięci przechwytuje wraz z nim także klucz. Obie nazywa się migawkami.
Ktoś zdobywa powłokę na działającej maszynie	Nie	Wolumin jest już otwarty, a intruz odczytuje pliki, a nie bloki. O tym wierszu decydują aktualizacje, zasada najmniejszych uprawnień i dane uwierzytelniające, których nie używa się ponownie w innych usługach — szyfrowanie nie wnosi tu nic.
Operator hosta lub każdy, kto dysponuje jego dostępem	Nie	Pomaga tylko szyfrowanie, którego klucz w ogóle nigdy nie trafia do maszyny. Sprzętowe szyfrowanie pamięci jest jedynym wyjątkiem i wszędzie jest domyślnie wyłączone, co omówiono w kolejnej części.
Dostawcy doręczono nakaz	Częściowo	Jurysdykcja decyduje o tym, kto może pytać i na jakiej podstawie; szyfrowanie decyduje o tym, co może zawierać odpowiedź. Nasze własne opublikowane stanowisko to dwa osobne zdania i oba mają znaczenie: nie przechowujemy kluczy klientów i nie możemy ich udostępnić, a niezaszyfrowany wolumin na serwerze wirtualnym wciąż wymaga nakazu wskazującego konkretną usługę.
Konieczność zgłoszenia naruszenia	Częściowo	Jeśli użytkownicy znajdują się w UE, art. 32 RODO wymienia szyfrowanie wśród oczekiwanych środków, a art. 34 znosi obowiązek zawiadomienia osób, których dane dotyczą — nigdy organu nadzorczego — jeśli dane stały się nieczytelne. To, czy ma to zastosowanie, zależy wyłącznie od tego, gdzie znajdował się klucz w chwili wycieku danych.

Ponad dyskiem: co przetrwa wrogi host

Wszystko dotychczas omówione dotyczy warstwy kończącej się na urządzeniu blokowym. Ponad nią znajdują się trzy elementy, które razem stanowią jedyną odpowiedź na piąty, szósty i siódmy wiersz powyższej tabeli.

Szyfrować ponad aplikacją, nie pod nią

Szyfrowanie na poziomie pola oznacza, że aplikacja szyfruje wartość, zanim trafi do bazy danych, i odszyfrowuje ją dopiero po odczytaniu. Zrzut bazy danych daje wtedy szyfrogram, niezależnie od tego, kto go wykonał i jaką drogą. Kosztuje to możliwość wyszukiwania czy indeksowania zaszyfrowanych kolumn, dlatego stosuje się je tylko na nielicznych polach, które na to zasługują — treściach wiadomości, przesłanych dokumentach, tokenach zewnętrznych usług — a nie na wszystkim. Kresem tej drogi jest szyfrowanie end-to-end: klucz należy do użytkownika, serwer nigdy nie przechowuje treści jawnej, a wrogi host nie zdobywa niczego, bo nie ma tam niczego do zdobycia. To jedyna architektura na tej stronie, dla której faktycznie nie ma znaczenia, kto zarządza sprzętem, i jest to decyzja produktowa na długo przed tym, jak stanie się decyzją infrastrukturalną.

Kopie zapasowe to osobna decyzja, nie konsekwencja

Najczęstszym sposobem, w jaki dane opuszczają zaszyfrowaną maszynę, jest kopia zapasowa. Migawka wypchnięta do magazynu obiektów, zrzut bazy danych zsynchronizowany z drugim dostawcą, archiwum pobrane na stację roboczą — żadne z nich nie dziedziczy niczego po woluminie, z którego pochodzi. Należy szyfrować w chwili zapisu danych do kopii, kluczem przechowywanym gdzieś poza zasięgiem samej maszyny, tak by przejęty serwer nie mógł odszyfrować własnej historii. Następnie warto odtworzyć jedną z kopii na innej maszynie, zanim będzie to naprawdę potrzebne: zaszyfrowana kopia zapasowa, której nie da się otworzyć, to niezwykle schludny sposób na utratę wszystkiego naraz. Kopia w innym kraju to również kopia podlegająca innemu zbiorowi przepisów, czyli druga jurysdykcja wybrana bez świadomej decyzji.

Szyfrowanie pamięci — i dlaczego zwykle go nie ma

Stan, którego nikt nie szyfruje, ma jednak sprzętową odpowiedź. Rozszerzenia poufnego przetwarzania — AMD SEV-SNP, Intel TDX — szyfrują pamięć i stan rejestrów maszyny gościa kluczem przechowywanym przez osobny procesor bezpieczeństwa, a nie przez hiperwizor, więc host, który wykona zrzut pamięci, otrzyma z powrotem tylko szyfrogram. To rozwiązanie realne i już dostępne. Jest też wąskie: SEV-SNP wymaga krzemu EPYC trzeciej generacji lub nowszego, host musi zostać do tego celowo skonfigurowany, a gość musi poświadczyć, że rzeczywiście z niego korzysta. Niemal żaden ogólnego przeznaczenia serwer wirtualny tego nie oferuje, a żaden nie robi tego po cichu. Należy zakładać brak tej ochrony, dopóki dostawca nie potwierdzi jej na piśmie i nie wyjaśni, jak samodzielnie zweryfikować poświadczenie.

Konfiguracja uczciwa wobec własnych ograniczeń

Nic z tego nie kończy się na nie ma sensu tego robić. Kończy się na konfiguracji, której ograniczenia da się wypowiedzieć na głos bez zająknięcia.

1. Zapisać jeden konkretny scenariusz, przed którym się broni (5 min). Wycofany dysk, maszyna przejęta w trakcie działania, wrogi host, nakaz sądowy, naruszenie wymagające zgłoszenia. Każdy ma inną odpowiedź, a konfiguracja celująca we wszystkie pięć naraz niezawodnie nie osiąga żadnego z nich.
2. Umieścić szyfrowanie tam, gdzie jest klucz (decyzja). Jeśli klucz trzyma dostawca, kupiono ochronę przed dyskiem opuszczającym budynek i nic ponadto. Jeśli potrzeba więcej, wolumin musi być odblokowywany od wewnątrz maszyny gościa, samodzielnie, czymś, czego platforma nigdy nie widzi.
3. Szyfrować wolumin z danymi, a nie wolumin główny (konfiguracja). Zaszyfrowany wolumin główny oznacza, że każdy restart czeka na obsługę. Osobny zaszyfrowany wolumin z katalogiem bazy danych, przesłanymi plikami i sekretami pozwala maszynie wrócić do działania samodzielnie, podczas gdy wrażliwa część pozostaje zamknięta, dopóki nie zostanie otwarta. To kompromis, który powinna stosować większość małych platform, a niemal nikt go nie zapisuje.
4. Nigdy nie zostawiać pliku klucza na niezaszyfrowanej partycji rozruchowej (zasada). Jeśli maszyna uruchamia się bez obsługi, bez serwera kluczy i bez konsoli, klucz znajduje się na dysku; trzeciej możliwości nie ma. To dobry kompromis, gdy skradziony dysk rzeczywiście stanowi cały model zagrożeń, a samooszukiwanie się w każdym innym przypadku.
5. Szyfrować kopie zapasowe w chwili zapisu, kluczem przechowywanym gdzie indziej (konfiguracja). Następnie odtworzyć jedną z nich na innej maszynie, w dniu, w którym nic akurat nie płonie.
6. Ujmować pokryty zakres ochrony w jednym zdaniu (5 min). Coś bliskiego temu: napastnik, który wyciągnie ten dysk z szafy, nie dostaje niczego, a każdy z dostępem root na działającej maszynie lub na jej hoście dostaje wszystko. Jeśli to zdanie trudno zapisać, to dlatego, że jest prawdziwe.

Dwa z tych sześciu punktów to decyzje, a cztery to konfiguracja. Decyzje zajmują popołudnie, konfiguracja godzinę, a ta godzina nic nie znaczy bez wcześniejszego popołudnia. Odwrócenie tej kolejności to sposób, w jaki ludzie kończą w trzecim wierszu pierwszej tabeli, z maszyną przechodzącą audyt, która nikogo nie chroni.

Przed jakim scenariuszem się broni, to pytanie z zakresu modelowania zagrożeń, zanim stanie się pytaniem o szyfrowanie, a godzinna wersja tego ćwiczenia niemal przy okazji daje zdanie z kroku szóstego. Jeśli odpowiedzią okaże się nakaz sądowy, a nie kradziony dysk, warstwą decydującą o wyniku wcale nie jest dysk — jest nią to, czyje prawo sięga dostawcy, i jak to sprawdzić, zanim się temu zaufa.

Napisane przez inżynierów, którzy prowadzą tę platformę, i ponownie sprawdzone dziś. Jeśli coś tu jest błędne albo nieaktualne, można to zgłosić z panelu — stamtąd pochodzi mniej więcej połowa z tych treści.