Confidential Computing – jak chronić dane nawet przed dostawcą chmury

Trzeci stan danych, o którym mało kto pamięta

W bezpieczeństwie danych od lat mówi się o dwóch stanach wymagających ochrony: danych w spoczynku (at rest), czyli zapisanych na dysku, oraz danych w transmisji (in transit), czyli przesyłanych siecią. Oba te stany od dawna szyfrujemy standardowo – dyski BitLockerem, transmisję protokołem TLS.

Istnieje jednak trzeci stan, który przez dekady pozostawał praktycznie niezabezpieczony: dane w użyciu (in use). To moment, w którym aplikacja faktycznie przetwarza informacje w pamięci operacyjnej serwera. Żeby procesor mógł wykonać obliczenia, dane muszą zostać odszyfrowane i załadowane do RAM w formie jawnej. Teoretycznie administrator dostawcy chmury, złośliwe oprogramowanie działające na hoście, a nawet inny najemca współdzielonej infrastruktury mógł w tym momencie podejrzeć zawartość pamięci.

Dla małej firmy korzystającej z chmury publicznej oznaczało to, że pełne zaufanie do dostawcy było warunkiem koniecznym bezpieczeństwa danych. Confidential computing ma to zmienić.

Jak działa ochrona danych w trakcie przetwarzania

Confidential computing opiera się na sprzętowych enklawach zaufania (Trusted Execution Environment, TEE) – wydzielonych, zaszyfrowanych obszarach pamięci procesora, do których nie ma dostępu ani system operacyjny hosta, ani hipervisor, ani administrator infrastruktury. Dane trafiające do enklawy są odszyfrowywane wyłącznie wewnątrz niej, obliczenia wykonują się w izolacji, a wynik opuszcza enklawę ponownie zaszyfrowany.

Kluczowe technologie stojące za tym mechanizmem to między innymi:

• Intel SGX i Intel TDX – enklawy na poziomie procesu oraz całych maszyn wirtualnych
• AMD SEV-SNP – szyfrowanie pamięci na poziomie całej maszyny wirtualnej
• ARM CCA – rozwiązanie enklawowe dla procesorów ARM, coraz częściej spotykanych w centrach danych

Dodatkowym elementem jest zdalna atestacja (remote attestation) – mechanizm, który pozwala kryptograficznie zweryfikować, że kod uruchomiony w enklawie jest dokładnie tym, co firma tam umieściła, bez żadnej modyfikacji po drodze.

Co oferują Azure, AWS i Google Cloud

Wszyscy trzej najwięksi dostawcy chmury publicznej mają już w ofercie usługi confidential computing, choć różnią się dojrzałością i zakresem. Najprostszy punkt wejścia to zwykle confidential virtual machines – maszyny wirtualne, które można uruchomić niemal identycznie jak zwykłe, ale z automatycznym szyfrowaniem pamięci na poziomie sprzętowym.

W praktyce dla większości MŚP oznacza to, że wdrożenie nie wymaga przepisywania aplikacji od zera – wystarczy wybrać odpowiedni typ instancji przy migracji obciążenia do chmury.

Dla kogo ma to sens w małej i średniej firmie

Confidential computing nie jest technologią, którą każda firma potrzebuje wdrożyć od zaraz, ale są sytuacje, w których zaczyna mieć konkretne uzasadnienie biznesowe:

• Przetwarzanie danych medycznych lub wrażliwych danych osobowych klientów, gdzie kontrakt lub przepisy wymagają dowodu, że dane nie są dostępne dla osób trzecich nawet teoretycznie
• Firmy pracujące dla dużych kontrahentów lub instytucji finansowych, które w umowach coraz częściej wymagają potwierdzenia poziomu izolacji danych
• Wspólne przetwarzanie danych z partnerami biznesowymi, gdzie żadna ze stron nie chce ujawniać surowych danych drugiej stronie, a mimo to potrzebne jest wspólne obliczenie na nich (np. wspólna analiza ryzyka kredytowego)
• Firmy działające w sektorach regulowanych, gdzie audytorzy pytają wprost o ochronę danych w trakcie przetwarzania, a nie tylko w spoczynku

Dla przeciętnej firmy usługowej czy handlowej, która trzyma dane księgowe i CRM w Microsoft 365 czy standardowej bazie danych, confidential computing na razie pozostaje technologią z przyszłości, a nie pilną potrzebą.

Ograniczenia, o których warto wiedzieć

Zanim ktokolwiek w firmie zapyta o wdrożenie confidential computing, warto znać realne bariery tej technologii. Po pierwsze, koszt – maszyny confidential są zwykle droższe od standardowych odpowiedników, choć różnica systematycznie maleje. Po drugie, wydajność – szyfrowanie i deszyfrowanie w locie generuje narzut obliczeniowy, zwykle rzędu kilku do kilkunastu procent, co przy obciążeniach wrażliwych na opóźnienia bywa odczuwalne.

Po trzecie, ekosystem narzędzi wciąż dojrzewa. Nie każda baza danych, framework czy narzędzie DevOps jest w pełni kompatybilne z enklawami bez dodatkowej konfiguracji. Wreszcie, sama technologia bywa przedmiotem badań akademickich wykazujących luki w konkretnych implementacjach sprzętowych, co pokazuje, że to wciąż rozwijający się obszar, a nie ostateczne, w pełni domknięte rozwiązanie.

Jak podejść do tematu w praktyce

Jeśli Twoja firma przetwarza dane, które podlegają szczególnym wymogom kontraktowym lub regulacyjnym, warto potraktować confidential computing jako element strategii bezpieczeństwa do rozważenia przy najbliższej migracji lub odnowieniu infrastruktury, a nie jako projekt do wdrożenia w oderwaniu od reszty środowiska IT.

Najbardziej praktyczne pierwsze kroki to: zidentyfikowanie, które dane w firmie faktycznie wymagają takiego poziomu ochrony, sprawdzenie, czy obecny dostawca chmury oferuje confidential VM w regionie, z którego korzysta firma, oraz przetestowanie wpływu na wydajność na wybranym obciążeniu przed pełnym wdrożeniem produkcyjnym.