Poufne przetwarzanie dla tajnych obciążeń: enklawy i atestacja

Dane niejawne były historycznie chronione w dwóch z trzech swoich stanów. Szyfrowanie w spoczynku chroni je na dysku; szyfrowanie podczas transmisji chroni je w sieci. Trzeci stan – dane w użyciu, odszyfrowane do rejestrów procesora i pamięci RAM, aby mogły być faktycznie przetwarzane – zawsze był czułym punktem. Każdy kod z wystarczającymi uprawnieniami na hoście, w tym system operacyjny, hiperwizor i operator chmury z fizycznym dostępem do magistrali pamięci, może odczytać ten tekst jawny. Poufne przetwarzanie zamyka tę lukę, uruchamiając obciążenie w izolowanym sprzętowo zaufanym środowisku wykonawczym (TEE), gdzie procesor utrzymuje pamięć zaszyfrowaną i nieczytelną dla wszystkiego poza enklawy. W przypadku tajnych obciążeń zmienia to zakres podmiotów, którym trzeba ufać – i ta zmiana jest sednem sprawy.

Problem danych w użyciu i model zagrożeń poufnego przetwarzania

Podstawowym założeniem poufnego przetwarzania jest zmniejszona zaufana baza obliczeniowa. W konwencjonalnym wdrożeniu chmurowym najemca jest zmuszony ufać całemu stosowi poniżej aplikacji: jądru systemu operacyjnego gościa, hiperwizorowi, oprogramowaniu układowemu hosta, płaszczyźnie kontroli chmury i osobom obsługującym centrum danych. Każda z nich stanowi ścieżkę do tekstu jawnego podczas działania obciążenia. W przypadku obciążeń Secret lub wrażliwych kompartmentowanych ta powierzchnia zaufania jest nie do zaakceptowania.

TEE odwraca ten model. Sam procesor egzekwuje granicę izolacji, szyfrując pamięć enklawy kluczami generowanymi i przechowywanymi w sprzętowym module bezpieczeństwa procesora, nigdy nieujawnianymi oprogramowaniu. System operacyjny hosta może planować enklawy, przydzielać jej strony pamięci i ją zatrzymywać – ale nie może odczytać jej zawartości. Hiperwizor skompromitowany przez atakującego lub złośliwy administrator podłączający debugger lub zrzucający fizyczną pamięć widzi wyłącznie szyfrogramy. Granica zaufania sprowadza się do dwóch elementów: sprzętu dostawcy krzemu i kodu, który świadomie ładujesz do enklawy.

To właśnie ta właściwość sprawia, że organizacje obronne rozważają hosting wrażliwych obciążeń na infrastrukturze, której fizycznie nie kontrolują. Samo w sobie nie akredytuje komercyjnego regionu dla danych niejawnych – to wymaga pełnego zestawu kontroli omówionych w naszej analizie architektury zero-trust dla sieci wojskowych – ale usuwa operatora z granicy zaufania dla danych w użyciu, co zasadniczo zmienia kalkulację ryzyka.

Zaufane środowiska wykonawcze: SGX, SEV-SNP, TDX i CCA

Istnieją dwie architektoniczne rodziny TEE, a wybór między nimi jest pierwszą i najbardziej konsekwentną decyzją projektową.

Enklawy na poziomie procesu (Intel SGX). Software Guard Extensions wydziela mały, zdefiniowany przez aplikację obszar pamięci – enklawy – z procesu i izoluje go od wszystkiego innego, w tym od jądra. Zaufana baza obliczeniowa jest minimalna: tylko kod umieszczony wewnątrz enklawy jest zaufany, nie otaczający system operacyjny. Kosztem jest konieczność partycjonowania aplikacji na zaufane i niezaufane połowy z kontrolowanym interfejsem wywołań między nimi, a pamięć enklawy jest ograniczona. SGX to właściwe narzędzie, gdy chcesz mieć jak najmniejszą powierzchnię ataku wokół konkretnej procedury obsługi sekretów – usługa opakowywania kluczy, kryptograficzny sygnatariusz, mały silnik polityk.

Poufność na poziomie maszyny wirtualnej (AMD SEV-SNP, Intel TDX, Arm CCA). Secure Encrypted Virtualization with Secure Nested Paging, Trust Domain Extensions i Arm's Confidential Compute Architecture Realms — wszystkie chronią całą maszynę wirtualną. Pamięć gościa jest przezroczyście szyfrowana i chroniona integralnością, a hiperwizor jest usuwany z granicy zaufania, przy czym obciążenie wewnątrz działa bez modyfikacji. Istniejąca tajna aplikacja może być przeniesiona do poufnej maszyny wirtualnej bez zmiany kodu. Zaufana baza obliczeniowa jest większa – obejmuje cały system operacyjny gościa – ale koszt wdrożenia jest dramatycznie niższy. W przypadku większości obciążeń obronnych migrowanych zamiast pisanych od zera poufność na poziomie maszyny wirtualnej jest pragmatycznym wyborem.

SEV-SNP i TDX dodały funkcję, której brakowało pierwszej generacji SGX i która ma kluczowe znaczenie dla danych niejawnych: ochronę integralności pamięci, broniącą przed atakującym, który odtwarza lub przemapowuje zaszyfrowane strony zamiast je jedynie odczytywać. Każde TEE wybrane do zastosowań z danymi niejawnymi musi zapewniać zarówno poufność, jak i integralność; sama poufność pozostawia obciążenie otwarte na aktywne ataki uszkodzenia pamięci ze strony hosta.

Zdalna atestacja: udowodnienie enklawy przed obdarzeniem jej zaufaniem

Izolacja sprzętowa jest konieczna, ale niewystarczająca. Strona przechowująca dane niejawne – lub klucz je szyfrujący – potrzebuje dowodu, że enklawy, z którą zamierza się komunikować, to autentyczny sprzęt TEE uruchamiający dokładnie oczekiwany kod, a nie emulator, zmodyfikowany obraz lub platforma z wycofanym mikrokodem udająca bezpieczną. Tym dowodem jest zdalna atestacja i to ona sprawia, że poufne przetwarzanie jest godne zaufania, a nie tylko pozornie bezpieczne.

Jak działa przepływ atestacji

Gdy enklawy startuje, procesor mierzy załadowany kod i konfigurację do rejestru sprzętowego i na żądanie generuje podpisany certyfikat: strukturę zawierającą te pomiary, numery wersji bezpieczeństwa TEE i podpis łączący się z kluczem wtopionym w krzem podczas produkcji. Enklawy wysyła ten certyfikat do weryfikatora – usługi, którą właściciel danych kontroluje lub której ufa. Weryfikator waliduje łańcuch podpisów aż do certyfikatu głównego dostawcy, potwierdza, że platforma jest na aktualnym, nieodwołanym mikrokodzie i porównuje zgłoszone pomiary z listą dozwolonych kodów, którym jest skłonny zaufać. Tylko jeśli wszystkie kontrole przejdą pomyślnie, weryfikator autoryzuje kolejny krok.

Kluczową dyscypliną inżynierską jest tu odtwarzalność pomiaru. Enklawy lub obraz gościa musi być budowany deterministycznie, tak aby jego pomiar był identyczny bit po bicie za każdym razem, ponieważ polityka atestacji jest listą dozwolonych dokładnych wartości pomiarowych. Nieodtwarzalny build oznacza stale zmieniający się pomiar, co zmusza operatorów do kardynalnego grzechu rozluźniania polityki, aż zacznie akceptować prawie wszystko – co niweczy cel. Traktuj pomiar uruchomienia jako artefakt wydania, rejestrowany i zarządzany wersją obok wersji oprogramowania układowego i mikrokodu, od których zależy.

Polityka atestacji jako rzeczywista granica bezpieczeństwa

Sprzęt wykonuje kryptografię, ale polityka podejmuje decyzje, a słaba polityka unieważnia silny sprzęt. Polityka atestacji klasy obronnej stwierdza wprost: które typy TEE są akceptowane; minimalna wersja zaufanej bazy obliczeniowej, z kontrolami numeru wersji bezpieczeństwa odrzucającymi wycofany mikrokod po ujawnieniu podatności; dokładny zestaw dozwolonych pomiarów kodu; oraz wymagania dotyczące aktualności, by stary certyfikat nie mógł być odtworzony. Najczęstszym trybem awarii w rzeczywistych wdrożeniach nie jest uszkodzona enklawy – to zbyt permisywna polityka akceptująca niedozwolone pomiary lub nigdy niesprawdzająca statusu odwołania platformy. Atestacja jest tylko tak dobra, jak reguły egzekwowane przez weryfikatora.

Wydawanie kluczy: wiązanie sekretów z zweryfikowanym środowiskiem

Atestacja staje się operacyjnie użyteczna, gdy warunkuje dostęp do sekretów. Wzorzec to wydawanie kluczy powiązane z atestacją: usługa zarządzania kluczami jest skonfigurowana tak, że klucz szyfrowania danych niejawnych jest wydawany dopiero po potwierdzeniu przez weryfikatora pozytywnej atestacji. Enklawy żąda klucza, przedstawia świeże dowody, a KMS udostępnia opakowany klucz do kanału zakończonego wewnątrz TEE, dzięki czemu klucz w postaci jawnej nigdy nie istnieje poza enklawy. Niezatestowany host, zdegradowana platforma lub zmodyfikowany obraz po prostu nigdy nie otrzymują materiału niezbędnego do odszyfrowania czegokolwiek.

Odwraca to zwykłą relację między tożsamością a autoryzacją. Zamiast wydawać klucz, bo wywołujący przedstawia poświadczenie, które mogłoby zostać skradzione, klucz jest wydawany, ponieważ środowisko uruchomieniowe kryptograficznie udowodniło swoją integralność. W przypadku obciążeń, które muszą przenosić dane przez granice, komponuje się to czysto z kontrolami opisanymi w naszym artykule o rozwiązaniach między domenami dla obronności: enklawy wykonująca transfer może być zobowiązana do atestacji, zanim zostanie jej powierzone dane z wyższego poziomu klasyfikacji.

Wzorce wdrożeń chmurowych dla tajnych obciążeń

Wszystkie główne rządowe regiony chmurowe udostępniają teraz SKU poufnych maszyn wirtualnych oparte na SEV-SNP lub TDX oraz zarządzane usługi enklaw i atestacji. Trzy wzorce wdrożeń powtarzają się w programach niejawnych i wrażliwych.

Poufne przetwarzanie danych. Obciążenie dotykające danych niejawnych – analityczne, silnik fuzji, usługa wnioskowania modelu – działa w całości w poufnych maszynach wirtualnych. Dane docierają zaszyfrowane, klucze są wydawane tylko atestowanym enklawy, a odszyfrowane dane istnieją wyłącznie w chronionej pamięci. To wzorzec lift-and-shift: istniejące aplikacje zyskują ochronę danych w użyciu przy minimalnych zmianach, usuwając operatora chmury z granicy zaufania bez konieczności re-architektury.

Poufne zarządzanie kluczami i brokering. Mała enklawy w stylu SGX pełni rolę kotwicy zaufania: przechowuje klucze opakowujące, przeprowadza weryfikację atestacji dla innych obciążeń i pośredniczy w wydawaniu kluczy szyfrowania danych do atestowanych poufnych maszyn wirtualnych. Koncentrowanie najbardziej wrażliwej logiki w minimalnej enklawy utrzymuje małą zaufaną bazę obliczeniową dla obsługi kluczy nawet wtedy, gdy obciążenia główne działają jako pełne poufne maszyny wirtualne.

Poufne przetwarzanie wielostronne i koalicyjne. Dwie organizacje, które nie mogą dzielić się surowymi danymi – partnerzy koalicji lub agencje na różnych poziomach klasyfikacji – wnoszą zaszyfrowane dane wejściowe do poufnej maszyny wirtualnej, która oblicza wspólny wynik. Ponieważ żadna ze stron, w tym host, nie może odczytać danych wejściowych pozostałych, enklawy staje się neutralnym gruntem. Atestacja pozwala każdemu z wnoszących zweryfikować dokładnie, jaki kod przetworzy jego dane, zanim je udostępni.

Zagrożenia rezydualne i dyscyplina operacyjna

Poufne przetwarzanie dramatycznie zawęża powierzchnię zagrożeń, ale jej nie eliminuje. Ataki kanałami bocznymi na TEE to aktywny obszar badań i kilka z nich wymagało łatek mikrokodu – dlatego egzekwowanie numerów wersji bezpieczeństwa w polityce atestacji nie jest opcjonalne. Sam kod enklawy jest wewnątrz granicy zaufania, więc podatność w nim jest podatnością w chronionym obciążeniu; minimalna zaufana baza obliczeniowa ogranicza promień wybuchu. A łańcuch dostaw krzemu jest ostatecznie zaufany. Żadne z tych zagrożeń nie obala modelu, ale definiuje dyscyplinę operacyjną: szybkie łatanie mikrokodu, utrzymywanie małej enklawy, ciągła re-atestacja zamiast wyłącznie podczas uruchomienia i rejestrowanie każdej decyzji atestacyjnej w niezmiennym magazynie na potrzeby audytu.

Poufne przetwarzanie jest jedną silną kontrolą w szerszej akredytowanej architekturze, a nie substytutem akredytacji. Należy do niej obok kontroli rezydencji danych, upoważnienia do działania na właściwym poziomie wpływu, audytowanego zarządzania kluczami oraz sieci zero-trust i mechanizmów między domenami omówionych gdzie indziej w tej serii. To, co oferuje w unikalny sposób, to audytowalna ochrona danych w użyciu – stanu, który do niedawna był po prostu zakładany jako narażony.