Confidential computing dla AI: TEE bez marketingu

Confidential computing ma chronić dane w trakcie użycia, kiedy procesor wykonuje obliczenia na odszyfrowanej pamięci. W systemach AI obietnica jest atrakcyjna: firma może uruchamiać wrażliwe dane i własne wagi w chmurze, ograniczając zaufanie do administratora hosta, hypervisora lub operatora infrastruktury. Samo oznaczenie „confidential VM” nie zamyka jednak modelu zagrożeń.

Najkrótsza odpowiedź: skuteczne wdrożenie wymaga sprzętowo izolowanego TEE, wiarygodnej zdalnej atestacji, polityki porównującej pomiary z zatwierdzoną konfiguracją oraz mechanizmu, który uwalnia klucze dopiero po pozytywnej weryfikacji. TEE nie naprawia podatnej aplikacji, prompt injection, nadmiernych uprawnień agenta, wycieku przez odpowiedź ani błędów w danych. Zmienia część granicy zaufania i ogranicza wybrane klasy ataków infrastrukturalnych.

Confidential Computing Consortium definiuje tę dziedzinę jako ochronę danych w użyciu przez obliczenia wykonywane w sprzętowo wspieranym, atestowanym Trusted Execution Environment. Architektura IETF RFC 9334: Remote ATtestation procedureS opisuje role i przepływy atestacji niezależnie od konkretnego producenta procesora.

Trzy stany danych

Klasyczny model wyróżnia:

Stan	Typowa kontrola	Przykład
data at rest	szyfrowanie dysku/obiektu	checkpoint w magazynie
data in transit	TLS/mTLS	prompt wysyłany do inference API
data in use	TEE + izolacja pamięci	wagi i batch podczas obliczeń

Szyfrowanie dysku przestaje chronić po zamontowaniu wolumenu. TLS kończy się w procesie lub proxy. Model i dane muszą być odszyfrowane gdzieś, aby GPU lub CPU wykonał obliczenie. TEE ma sprawić, że ten „gdzieś” będzie izolowany od części uprzywilejowanego oprogramowania platformy.

To nie oznacza niewidzialności wszystkiego. Operator może nadal obserwować metadane, rozmiary, czas, dostępność, ruch sieciowy i zużycie zasobów, zależnie od platformy. Aplikacja wewnątrz TEE widzi dane jawne i może je wyprowadzić, jeżeli jest złośliwa lub podatna.

Co właściwie jest TEE

Trusted Execution Environment to chronione środowisko wykonania o określonych właściwościach izolacji, poufności i integralności. Implementacje różnią się zakresem:

enclave izoluje wybrany fragment procesu i jego pamięć;
confidential VM obejmuje większą maszynę wirtualną;
CPU TEE + GPU TEE próbuje chronić pełną ścieżkę akcelerowanego obliczenia;
mechanizmy kontenerowe opierają się na confidential VM i polityce obrazu.

Większy TEE ułatwia migrację istniejącej aplikacji, ale zwiększa Trusted Computing Base. Kernel, biblioteki, sterowniki i cały runtime wewnątrz chronionego środowiska stają się częścią tego, czemu trzeba ufać. Mniejsza enklawa może mieć węższy TCB, lecz wymaga przeprojektowania aplikacji i ostrożnej obsługi wywołań do świata zewnętrznego.

Microsoft opisuje Trusted Execution Environment jako oddzielony obszar pamięci i CPU chroniony przed resztą systemu z użyciem mechanizmów sprzętowych. Dokumentacja rozróżnia podejście typu lift-and-shift dla confidential VM od aplikacji projektowanych pod enklawy.

Atestacja: jak nie uwierzyć samej etykiecie

Szyfrowana pamięć nie odpowiada na pytanie: jaki kod otrzyma moje dane? Zdalna atestacja dostarcza dowodów o środowisku wykonania. W modelu RFC 9334 występują trzy role:

Attester tworzy Evidence opisujące swoje środowisko;
Verifier ocenia Evidence według polityki i wartości referencyjnych;
Relying Party podejmuje decyzję na podstawie Attestation Result.

Pomiary mogą dotyczyć hardware, firmware, boot chain, obrazu VM, konfiguracji lub workloadu. Weryfikator porównuje je z zatwierdzonym stanem. Świeżość dowodu jest ważna, dlatego protokół używa czasu, nonce albo innego mechanizmu przeciwdziałającego replay.

Atestacja nie mówi „system jest bezpieczny” w sensie absolutnym. Mówi, że przedstawione dowody spełniają konkretną politykę. Jeżeli polityka akceptuje podatny obraz, wynik będzie formalnie poprawny, ale system pozostanie podatny. Jeżeli pipeline wartości referencyjnych został przejęty, zaufanie również upada.

Wzorzec uwalniania klucza po atestacji

Najbardziej praktyczny model wygląda tak:

Workload startuje w TEE bez dostępu do klucza danych lub modelu.
Generuje świeży dowód atestacyjny związany z instancją i kluczem sesyjnym.
Verifier sprawdza łańcuch, pomiary, świeżość i politykę.
Relying Party lub KMS wydaje krótkotrwały klucz tylko zatwierdzonemu środowisku.
Workload odszyfrowuje dane wewnątrz TEE i usuwa klucz po użyciu.
Ponowna atestacja jest wymagana po zmianie lub upływie ważności.

RFC 9334 zawiera nawet referencyjny przypadek ochrony poufnego modelu ML: usługa wydaje model albo klucz do jego odszyfrowania dopiero po pozytywnej atestacji urządzenia. To ważne rozróżnienie — zaszyfrowany checkpoint przechowywany obok klucza dostępnego bez weryfikacji nie daje tej samej właściwości.

CPU i GPU w jednym łańcuchu zaufania

Duże modele wymagają akceleratorów. Ochrona pamięci CPU nie wystarczy, jeśli wagi są przesyłane jawnie do GPU albo sterownik poza TEE ma do nich dostęp. Potrzebny jest chroniony kanał CPU–GPU, atestacja obu stron i polityka, która wiąże wynik z konkretnym workloadem.

NVIDIA opisuje dla H100 sprzętowy root of trust, TEE GPU oraz bezpieczną sesję z driverem działającym w CPU TEE w materiale Confidential Computing on NVIDIA H100 GPUs. Dokument dostawcy jest ważnym źródłem implementacyjnym, ale zespół powinien sprawdzić dokładny tryb, generację sprzętu, wersję firmware i zakres chronionych operacji.

Nie każde zadanie akcelerowane korzysta automatycznie z confidential computing. Fallback na niechroniony kernel, preprocessing poza TEE albo zapis tensorów tymczasowych na zwykłym dysku może złamać założenie end-to-end.

Realne zastosowania AI

Wnioskowanie na danych regulowanych

Organizacja może chcieć analizować dane medyczne, finansowe lub tajemnice handlowe bez pełnego zaufania do operatora hosta. TEE ogranicza dostęp części warstwy infrastrukturalnej, ale aplikacja nadal musi stosować minimalizację danych, kontrolę dostępu, retencję i ochronę prywatności.

Ochrona własnych wag

Dostawca może wdrożyć model u klienta, wydając klucz tylko zatestowanemu środowisku. Chroni to przed prostym odczytem pliku lub pamięci przez administratora systemu, lecz nie gwarantuje, że odpowiedzi API nie umożliwią model extraction.

Wspólne przetwarzanie danych

Dwie organizacje mogą uruchomić uzgodniony workload na połączonych danych i wydać klucze po atestacji. Nadal potrzebują polityki wyniku: zatwierdzony kod może ujawniać pojedyncze rekordy przez zbyt szczegółowy output.

Izolacja agentów i narzędzi

TEE może chronić sekrety agenta przed hostem, ale nie zatrzyma prompt injection, które nakłoni zatwierdzony kod do użycia sekretu w niepożądany sposób. Potrzebne są osobne mechanizmy: sandbox dla agentów AI, least privilege i kontrola egressu.

Czego confidential computing nie rozwiązuje

Podatności workloadu

Jeżeli aplikacja ma RCE, SQL injection, niebezpieczną deserializację albo błąd autoryzacji, atakujący może działać wewnątrz zaufanego środowiska. TEE chroni przed określonym przeciwnikiem na zewnątrz, nie przed własnym zaakceptowanym kodem.

Wycieki przez legalny interfejs

Model może ujawnić dane w odpowiedzi, logu, metryce lub wywołaniu narzędzia. TEE nie rozpoznaje, czy token jest dozwolony. Bezpieczeństwo RAG nadal wymaga autoryzacji dokumentów i filtracji kontekstu.

Side channels i DoS

Zakres ochrony przed kanałami bocznymi zależy od technologii i modelu atakującego. Czas, wzorce dostępu, cache, stronicowanie lub zużycie zasobów mogą ujawniać informacje. Operator infrastruktury zwykle nadal może zatrzymać workload lub odmówić zasobów; poufność i integralność nie gwarantują dostępności.

Łańcuch dostaw

Atestacja złośliwego, lecz zatwierdzonego obrazu potwierdza jego tożsamość, nie dobre intencje. Potrzebujesz podpisów, kontroli budowy, SBOM i recenzji. Sigstore i SLSA odpowiadają na inne pytanie niż TEE i powinny tworzyć jeden łańcuch dowodowy.

Metadane i output

Rozmiar modelu, częstotliwość zapytań, czas inference i adresy połączeń mogą pozostać widoczne. Wynik opuszcza TEE i musi być chroniony dalej przez TLS, autoryzację i politykę odbiorcy.

Jak projektować politykę atestacji

Polityka powinna być kodem wersjonowanym i recenzowanym. Określ:

dopuszczone typy hardware i minimalne poziomy firmware;
pomiary boot chain, obrazu i konfiguracji;
podpis i pochodzenie artefaktu workloadu;
dozwolone debug modes — zwykle wyłączone dla produkcji;
świeżość Evidence i maksymalny wiek wyniku;
powiązanie z tenantem, regionem i kluczem sesyjnym;
zachowanie przy braku atestacji, revocation lub awarii verifiera.

Fail-open przy awarii usługi atestacyjnej może całkowicie zniszczyć właściwość bezpieczeństwa. Fail-closed może zatrzymać krytyczny biznes. Decyzję trzeba świadomie powiązać z dostępnością, cache wyniku, krótkimi TTL i procedurą awaryjną.

Operacyjny model wdrożenia

Faza	Kontrola	Dowód
build	powtarzalny obraz, skan, podpis	digest, provenance, SBOM
deploy	polityka dopuszcza konkretny pomiar	wersja policy-as-code
start	świeża atestacja TEE	Evidence i Attestation Result
key release	klucz związany z zatwierdzoną instancją	log KMS i nonce
runtime	egress, IAM, telemetryka, limity	zdarzenia powiązane z workloadem
update	nowe wartości referencyjne przed rolloutem	zatwierdzenie i plan rollbacku
revoke	blokada podatnego firmware/obrazu	lista revocation i incydent

Logi atestacji same mogą zawierać identyfikatory urządzeń i dane wrażliwe, na co zwraca uwagę RFC 9334. Retencja i dostęp do Evidence powinny być ograniczone. Nie publikuj surowych tokenów atestacyjnych w zwykłej telemetrii aplikacji.

Koszt, wydajność i kryterium wyboru

Confidential computing może zwiększać koszt infrastruktury, czas startu, złożoność observability i ograniczać dostępne typy maszyn lub funkcje akceleratora. Narzut zależy od workloadu, trybu TEE, I/O, pamięci i generacji sprzętu, dlatego nie warto kopiować jednego procentu z materiału marketingowego. Wykonaj benchmark własnego modelu: cold start, throughput, latency p95/p99, zużycie pamięci i czas atestacji.

Technologia ma sens, gdy redukcja konkretnego ryzyka uzasadnia tę złożoność. Jeżeli zagrożeniem jest głównie błąd autoryzacji aplikacji, najpierw napraw IAM. Jeżeli wymaganie dotyczy ograniczenia dostępu operatora hosta do danych w użyciu, TEE może być właściwą kontrolą — pod warunkiem, że pełny przepływ spełnia założenia.

Test bezpieczeństwa confidential AI

Test powinien sprawdzić nie tylko, czy konsola pokazuje zielony status. Spróbuj uruchomić niezatwierdzony obraz, zmienić konfigurację, użyć starego Evidence, podmienić nonce, włączyć debug, odtworzyć snapshot i zażądać klucza po wygaśnięciu atestacji. Wszystko w kontrolowanym środowisku bez obchodzenia sprzętowych zabezpieczeń poza zakresem.

Następnie zweryfikuj granice danych: pliki tymczasowe, swap, core dumps, logi, preprocessing, komunikację CPU–GPU, output i backupy. Zarządzanie sekretami powinno wiązać politykę KMS z wynikiem atestacji, a nie tylko z tożsamością chmurową VM.

Checklista decyzyjna

Przed którym przeciwnikiem chronimy dane: administratorem hosta, chmurą, klientem czy malware?
Jaki dokładnie kod i hardware obejmuje TCB?
Czy pełna ścieżka CPU–GPU–storage pozostaje chroniona?
Czy klucz jest wydawany dopiero po świeżej, zweryfikowanej atestacji?
Czy polityka sprawdza workload, firmware, debug i provenance?
Co dzieje się przy awarii verifiera: fail-open czy fail-closed?
Czy aplikacja nadal ma least privilege, sandbox, egress i kontrolę outputu?
Czy mamy procedurę revocation dla podatnego obrazu lub firmware?
Czy potrafimy udowodnić właściwość niezależnym testem, a nie nazwą produktu?

Confidential computing jest wartościową technologią, gdy model zagrożeń obejmuje uprzywilejowaną infrastrukturę i dane w użyciu. Nie jest magiczną pieczęcią „secure AI”. Najlepsze wdrożenie łączy atestację, bezpieczny build, zarządzanie kluczami, ograniczenia workloadu i test całego przepływu. Zamów audyt bezpieczeństwa AI — zweryfikujemy architekturę TEE i to, czy klucze faktycznie trafiają tylko do zatwierdzonego kodu.