Szyfrowany hosting VPSSzyfrowanie danych w spoczynku chroni maszynę, która jest wyłączona.

Trzy stany i ten jeden, którego branża nie sprzedaje

Mówi się, że dane znajdują się w jednym z trzech stanów, i to rozróżnienie stanowi sedno całej tej strony. W spoczynku to dysk, którego nikt nie odczytuje. W tranzycie to pakiet przesyłany siecią. W użyciu to proces przechowujący w pamięci tekst jawny, aby móc coś z nim zrobić.

Dwa pierwsze są już rozwiązane i sprzedaje je każdy dostawca. Transmisję zabezpiecza TLS, a fizyczne nośniki danych pod spodem niemal na pewno są zaszyfrowane. O trzecim mówi się bardzo niewiele, ponieważ to właśnie tam stoi dostawca: działający serwer ma odblokowany wolumin, klucz rezydujący w pamięci i dane w postaci jawnej. To nie jest wada szyfrowania. Na tym właśnie polega to, że serwer działa.

Co znaczy “zaszyfrowane w spoczynku”, gdy mówi to dostawca

Szyfrowanie danych w spoczynku po stronie dostawcy jest realne i warte posiadania. Oznacza ono, że dysk, macierz lub magazyn migawek jest zaszyfrowany kluczem zarządzanym przez dostawcę, dzięki czemu dysk opuszczający budynek — uszkodzony, wymieniony, odsprzedany, skradziony — staje się bezużytecznym kawałkiem sprzętu, a nie kopią Państwa bazy danych. Robi tak każda poważna platforma i nie kosztuje to Państwa nic.

Czego nie potrafi zrobić, to wykluczyć dostawcy, ponieważ z definicji to dostawca trzyma klucz. To zabezpieczenie przed rampą załadunkową, nie przed operatorem. Dostawca, który na pytanie o własny dostęp odpowiada opisem szyfrowania danych w spoczynku, odpowiedział na inne pytanie — i zwykle doskonale zdaje sobie z tego sprawę.

Wersja, która rzeczywiście wyklucza dostawcę, to ta, w której klucz nigdy do niego nie dociera. Ten kompromis jest opisany w procedurze poświęconej temu zagadnieniu: migawki są tu przechowywane w postaci zaszyfrowanej, ta infrastruktura nie posiada klucza do zawartości dysku zaszyfrowanego samodzielnie przez Państwa, a co za tym idzie, nie jest też w stanie takiego dysku uratować. Obie połowy tego zdania to ten sam fakt, a host oferujący wyłącznie pierwszą połowę wciąż trzyma klucz.

Trzy maszyny, trzy różne odpowiedzi

“Czy mój host może odczytać mój dysk” rozstrzyga się inaczej na instancji współdzielonej, na całej maszynie i w szafie wynajmowanej w jednostkach. Warto przedstawić te różnice, ponieważ zwykle sprzedaje się je jako ten sam produkt, różniący się jedynie liczbami przy nim.

Żaden z tych wierszy nie jest argumentem przeciwko produktowi znajdującemu się nad nim. Są one argumentem za tym, by wiedzieć, przed jakim zagrożeniem się Państwo zabezpieczają. Operator prowadzący hypervisor może odczytać pamięć działającej na nim maszyny gościa, a dostawca twierdzący inaczej błędnie rozumie własną infrastrukturę. To, co odczyta, jest albo Państwa danymi, albo szumem — a które z tych dwóch, zostało przesądzone miesiące wcześniej, w momencie wyboru miejsca przechowywania klucza.

Ceremonia klucza to cała gwarancja

Wszystko powyższe sprowadza się do jednego pytania operacyjnego: skąd bierze się klucz w chwili, gdy maszyna się uruchamia? W praktyce stosowane są trzy odpowiedzi, i pod względem siły nie są one nawet blisko siebie.

1. Przechowywany na maszynie. Plik klucza na tym samym woluminie albo hasło zaszyte na stałe w skrypcie provisioningu, tak by serwer mógł uruchamiać się bez nadzoru. To szyfrowanie jako formalność: kto może odczytać dysk, ten odczyta też leżący obok niego klucz.
2. W posiadaniu dostawcy. Wygodne, odzyskiwalne i dokładnie ten układ, na którym może zadziałać nakaz prawny. Klucz istnieje, ktoś go przechowuje, a sam fakt jego przechowywania to coś, co można wprost zapisać w treści nakazu.
3. Podawany przez Państwa przy każdym rozruchu. Maszyna uruchamia się do initramfs i nie robi zupełnie nic, dopóki nie połączą się Państwo i nie przekażą jej hasła. Klucz istnieje w pamięci tej maszyny — tylko podczas jej działania i nigdzie indziej na świecie.

Tylko trzecie rozwiązanie wyprowadza to pytanie z rejestru prawnego. Nakaz może zmusić dostawcę do przekazania tego, co posiada; nie może zmusić go do przekazania klucza, którego nigdy nie otrzymał. To różnica jakościowa, a nie tylko stopnia, i dlatego podpisany warrant canary zawiera tu osobne oświadczenie dotyczące wymuszonego osłabienia zabezpieczenia kryptograficznego. Obietnica dotycząca zachowania i fakt dotyczący arytmetyki to różne rodzaje instrumentów, a tylko jeden z nich przetrwa osobę, która go złożyła.

Co pełne szyfrowanie dysku nadal pozostawia w postaci jawnej

Zaszyfrowany główny system plików nie jest nieprzezroczystą skrzynką. Kilka elementów z założenia pozostaje poza nim, a wiedza, które to elementy, stanowi różnicę między modelem zagrożeń a przeczuciem.

• Łańcuch rozruchowy. /boot oraz initramfs są odczytywane, zanim cokolwiek może zostać odszyfrowane, więc pozostają niezaszyfrowane, a na wynajmowanym sprzęcie, którego firmware nie da się poddać atestacji, również niezweryfikowane. Kto może tam zapisywać, ten może umieścić coś, co przechwyci Państwa hasło.
• Swap i hibernacja. Niezaszyfrowany swap będzie bez najmniejszego problemu przechowywał strony odszyfrowanej pamięci. Należy go zaszyfrować albo wyłączyć; nie istnieje żadna trzecia, bezpieczna opcja.
• Kształt maszyny. Rozmiary partycji, nagłówek LUKS, ilość wykorzystanego miejsca na woluminie oraz sam fakt, że w ogóle jest on zaszyfrowany.
• Wszystko, co przechowuje działający proces. Baza danych w pamięci podręcznej stron, klucz prywatny TLS wczytany przez serwer WWW przy starcie, zmienne środowiskowe, otwarte gniazda. To największa kategoria na tej liście, a szyfrowanie danych w spoczynku nie dotyka żadnego z tych elementów.
• Państwa ruch sieciowy. Z kim się Państwo łączą, kiedy i jak często — dokładnie tak jak wcześniej. To temat przewodnika o braku logów, a nie niniejszego.

Łańcuch rozruchowy to element, który ludzie najczęściej nie doceniają. Jeśli to właśnie w initramfs wpisują Państwo hasło, initramfs staje się monitem o dane uwierzytelniające na maszynie, nad którą nie sprawują Państwo fizycznej kontroli — dlatego odcisk jego klucza hosta SSH ma takie samo znaczenie jak samo hasło. To inny klucz niż ten, który prezentuje już działający system, i właśnie dlatego zmieniony przy rozruchu odcisk tak łatwo przechodzi bez sprawdzenia. Warto zapisać go za pierwszym razem i sprawdzać przy każdym kolejnym. Cały ten atak sprowadza się do monitu, który wygląda poprawnie, a nie jest.

Co to powstrzymuje, a czego nie

Warto prześledzić środkową kolumnę. Szyfrowanie ma znaczenie rozstrzygające dokładnie w tych przypadkach, gdy maszyna jest wyłączona albo klucz nigdy nie został przekazany, i jest nieistotne w każdym przypadku, w którym maszyna działa, a ktoś jest już w jej wnętrzu. To nie jest słabość, którą da się obejść inżynieryjnie. Na tym właśnie polega szyfrowanie, a strona, która sugeruje coś innego, coś sprzedaje.

Koszt, przedstawiony zanim się Państwo na to zdecydują

To sekcja, której nie mają strony reklamujące “szyfrowany hosting”, a powód jest taki, że każdy punkt na niej to realna niedogodność, z którą zetkną się Państwo w ciągu miesiąca.

• Brak nienadzorowanego restartu. Aktualizacja jądra, zdarzenie związane z zasilaniem lub migracja między hostami pozostawiają maszynę czekającą przy monicie o hasło, aż pojawi się człowiek. Dostępność staje się teraz funkcją Państwa harmonogramu snu.
• Brak trybu ratunkowego. Dostawca, który nie potrafi odczytać woluminu, nie potrafi go też naprawić. Sprawdzanie systemu plików, odzyskiwanie danych i “czy dałoby się po prostu skopiować z niego config” — to wszystko staje się wyłącznie Państwa sprawą.
• Kopie zapasowe to szyfrogram. I słusznie — oznacza to jednak, że do przywrócenia danych również potrzebny jest klucz. Kopia zapasowa, której nie można otworzyć, nie jest kopią zapasową.
• Uszkodzony nagłówek jest fatalny w skutkach. Nagłówek LUKS przechowuje zawinięty klucz główny w niewielkim obszarze na początku woluminu. Warto skopiować go poza maszynę już pierwszego dnia — bez niego nawet poprawne hasło niczego nie otworzy.
• Pewien narzut. Realny, widoczny w benchmarku, a rzadko stanowiący ograniczenie dla obciążenia — każdy obecny procesor obsługuje AES sprzętowo. Zamiast się o to spierać, warto zmierzyć go na wynajętej maszynie.

Konfiguracja, która sprawia, że warto to mieć

Polecenia znajdują się w bazie wiedzy. To, co następuje poniżej, to kolejność ich wykonania — czyli ta część, która nie jest poleceniem.

1. Dostęp do konsoli warto zapewnić sobie przed rozpoczęciem, a nie po fakcie. Pierwszy błąd zdarza się właśnie przy monicie rozruchowym, a to akurat tam SSH nie jest dostępne.
2. Warto najpierw zaszyfrować dodatkowy wolumin. Dane na osobnym zaszyfrowanym dysku dają większość korzyści przy ułamku ryzyka operacyjnego, a przy okazji pozwalają poznać tryby awarii na maszynie, która wciąż uruchamia się samodzielnie.
3. Główny system plików warto przenieść za nie dopiero, gdy stanie się to rutyną — z niewielkim serwerem SSH w initramfs, który odbierze hasło przy rozruchu.
4. Odcisk klucza hosta initramfs warto zapisać przy pierwszym odblokowaniu i weryfikować go przy każdym kolejnym. To nie ten sam klucz, który prezentuje działający już system, a traktowanie jego zmiany jako czegoś normalnego to właśnie sposób, w jaki przechwytuje się hasło.
5. Kopię zapasową nagłówka LUKS warto przechowywać poza tą maszyną, a następnie sprawdzić — zamiast zakładać — że ta kopia rzeczywiście otwiera wolumin.
6. Swap należy zaszyfrować albo wyłączyć, a następnie sprawdzić, co faktycznie powstało: lsblk -o NAME,FSTYPE,MOUNTPOINT pokazuje, co stoi za mapperem, a co po cichu tego unika.
7. Warto raz, świadomie, zrestartować maszynę, zanim znajdzie się na niej coś, czego żal by było stracić. Pierwszy nienadzorowany restart o trzeciej nad ranem to nie moment na uczenie się tej procedury.

Jak w dziesięć minut zweryfikować deklarację szyfrowania dostawcy

Ten sam test, co wszędzie indziej na tej półce: każde pytanie poniżej albo ma odpowiedź w postaci dokumentu, albo jej nie ma.

1. Czy szyfrowana jest platforma, wolumin czy maszyna gościa — i o które z nich Państwo właściwie pytali?
2. Kto generuje klucz, gdzie jest on przechowywany i jaka jest procedura, gdy klient go zgubi? Ścieżka odzyskiwania to drugi klucz, a drugi klucz to drugi element, którego przekazania można zażądać nakazem.
3. Czy mogą Państwo dostarczyć własny klucz i odmówić jego udostępnienia? Jeśli tak, warto zapytać, co wtedy przestaje działać. Jeśli nic nie przestaje działać, szyfrowanie nie dawało żadnej ochrony.
4. Czy dostępna jest konsola działająca nawet wtedy, gdy maszyna nie chce się uruchomić, i czy jest ona wliczona w cenę, czy rozliczana godzinowo?
5. Co dostawca deklaruje, że po zaszyfrowaniu przestaje móc zrobić? Dostawca twierdzący, że oferuje jednocześnie pełną prywatność i pełne wsparcie, albo nie przemyślał tego do końca, albo opisuje klucz, który wciąż posiada.

Ten ostatni punkt jest tym, co wszystko zdradza. Każda uczciwa odpowiedź w tym obszarze coś dostawcę kosztuje, a twierdzenie, które nic nie kosztuje, opisuje produkt, a nie gwarancję. To, co ta infrastruktura zrobi, a czego nie zrobi, zostało opisane w przewodniku dla organów ścigania i zliczone w raporcie przejrzystości.

Pytania, które faktycznie są zadawane

Każda cena w tej infrastrukturze jest publikowana w całości, w jednym miejscu. Zobacz cały katalog