Jak zweryfikować atestację sprzętową w Azure Confidential Computing

By Mirko Peters · 2026-10-26

Dowiedz się, jak działa atestacja sprzętowa w Azure, porównaj AMD SEV-SNP z Intel SGX i sprawdź, jak wbudować weryfikację kryptograficzną w potoki CI/CD.

Automatically translated with AI from the original post. Read the English original

Atestacja sprzętowa w Azure to krytyczny proces kryptograficznej weryfikacji, który potwierdza, że zaufane środowisko wykonawcze jest autentyczne i nienaruszone, zanim załadowane zostaną wrażliwe obciążenia. Porównując pomiary secure boot oraz klucze sprzętowe z wzorcami bazowymi firmy Microsoft i producentów, atestacja zamyka lukę zaufania między operatorami chmury a prywatnością danych dzierżawy.

Najważniejsze wnioski

• Atestacja sprzętowa kryptograficznie potwierdza, że Trusted Execution Environment (TEE) jest autentyczne i nieskompromitowane.
• Zdalna usługa atestacji ocenia pomiary platformy względem wzorców bezpieczeństwa, zanim udostępni klucze deszyfrujące.
• Zarówno architektury AMD SEV-SNP, jak i Intel SGX opierają się na zdalnej weryfikacji, aby administratorzy chmury nie mogli sprawdzić pamięci używanej w działaniu.
• Włączenie atestacji do potoków wdrażania CI/CD automatyzuje weryfikację zaufania i blokuje uruchamianie zmodyfikowanych kontenerów.
• Zrozumienie wymiany atestacyjnej jest niezbędne, by utrzymać podejście zero trust we współczesnych hybrydowych środowiskach chmurowych.

Deficyt zaufania w chmurach publicznych

Podczas migracji wrażliwych obciążeń do chmury publicznej tradycyjne modele bezpieczeństwa chronią dane w tranzycie za pomocą TLS, a dane w spoczynku za pomocą szyfrowania AES-256. Pozostaje jednak istotna luka: dane w użyciu. Historycznie, gdy procesor wykonywał kod, dane musiały zostać odszyfrowane i umieszczone w postaci jawnej w pamięci systemowej. W wielodzierżawnym środowisku chmurowym oznaczało to konieczność ufania hiperwizorowi, dostawcy infrastruktury chmurowej oraz każdemu, kto ma uprawnienia administracyjne do bazowego sprzętu fizycznego.

Azure Confidential Computing zmienia ten paradygmat, wprowadzając sprzętowe Trusted Execution Environments, czyli TEE. Te bezpieczne enklawy i izolowane maszyny wirtualne szyfrują zawartość pamięci za pomocą dedykowanych kluczy sprzętowych zarządzanych bezpośrednio przez krzemowy układ procesora. Sama zamknięta komnata to jednak dopiero połowa sukcesu. Musisz także mieć sposób, by sprawdzić, czy zamka nie wytrychem, czy drzwi są prawidłowo zbudowane i czy wewnątrz bezpiecznej granicy nie działa nieautoryzowane oprogramowanie, zanim przekażesz klucze kryptograficzne.

Jak działa zdalna atestacja

Zdalna atestacja to mechanizm weryfikacji, który odpowiada na podstawowe pytanie: skąd wiesz, że środowisko chmurowe, w którym wdrażasz obciążenie, jest rzeczywiście bezpieczne i nienaruszone? Bez atestacji atakujący z uprawnieniami na poziomie hiperwizora mógłby teoretycznie podmienić złośliwy BIOS lub zmodyfikować bootloader, przechwytując klucze szyfrujące w chwili ich załadowania do pamięci.

Przepływ atestacji składa się z rygorystycznej, wieloetapowej wymiany kryptograficznej:

Krok 1: Secure Boot i pomiar platformy

Gdy poufna maszyna wirtualna lub instancja kontenera Azure się uruchamia, sprzęt i oprogramowanie układowe zapisują kryptograficzne pomiary każdego komponentu biorącego udział w procesie rozruchu. Dotyczy to modułu ładującego (bootloader), obrazów jądra oraz wszelkich początkowych dysków RAM (initial ramdisk). Pomiary te są bezpiecznie przechowywane w rejestrach sprzętowych wewnątrz procesora, których nie może zmodyfikować system operacyjny hosta ani hiperwizor.

Krok 2: generowanie kryptograficznego raportu

Gdy obciążenie zostanie zainicjowane wewnątrz TEE, żąda ono od procesora podpisanego sprzętowo raportu. Procesor podpisuje ten raport pomiarowy za pomocą zaszytego na stałe, niezmiennego klucza prywatnego, wbudowanego w krzem podczas produkcji. Raport ten pełni rolę nie do podrobienia cyfrowego paszportu, odzwierciedlającego dokładny stan stosu oprogramowania działającego w odizolowanym środowisku.

Krok 3: ocena przez usługę Azure Attestation

Podpisany sprzętowo raport trafia do usługi Microsoft Azure Attestation (MAA) lub zgodnego narzędzia weryfikującego innej firmy. Usługa attestation porównuje otrzymane pomiary z wzorcowymi zasadami, zdefiniowanymi przez dzierżawę. Jeśli kod działający w enklawie jest zgodny z autoryzowanymi zasadami, usługa generuje token attestation.

Krok 4: udostępnianie sekretów

Mając ważny token attestation, aplikacja może bezpiecznie zażądać poświadczeń do bazy danych, certyfikatów TLS lub kluczy szyfrowania danych z zabezpieczonego Key Vault Managed HSM. Key Vault weryfikuje token i udostępnia sekrety wyłącznie zweryfikowanemu TEE, dzięki czemu żadne nieautoryzowane środowisko nigdy nie uzyska dostępu do danych jawnych.

Różnice architektoniczne: AMD SEV-SNP kontra Intel SGX

Wdrożenie attestation wymaga zrozumienia architektury sprzętowej, na której działają węzły Azure Confidential Computing. Microsoft Azure obsługuje dwie główne technologie sprzętowe, z których każda realizuje izolację i attestation nieco inaczej.

Intel Software Guard Extensions (SGX) koncentruje się na izolacji na poziomie procesu. Zamiast chronić całą maszynę wirtualną, SGX pozwala deweloperom izolować wybrany kod i struktury danych w drobnoziarnistych enklawach. Attestation w SGX opiera się w dużej mierze na enklawach cytujących (quoting enclaves), które pakują stan sprzętu w weryfikowalny cytat (quote), a następnie ten cytat jest weryfikowany w infrastrukturze Enhanced Privacy ID (EPID) lub nowocześniejszej infrastrukturze Data Center Attestation Primitives (DCAP) firmy Intel.

Z kolei AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) chroni całe maszyny wirtualne. SEV-SNP zapewnia integralność pamięci dzięki szyfrowaniu pamięci realizowanemu sprzętowo oraz uniemożliwia złośliwym hiperwizorom przemapowywanie fizycznych adresów gościa. Raport attestation wygenerowany przez maszynę wirtualną AMD SEV-SNP zawiera konfigurację zasad gościa oraz pomiary uruchomienia (launch measurements), co ułatwia przeniesienie istniejących aplikacji kontenerowych (lift-and-shift) bez konieczności przepisywania kodu pod kątem interfejsów API enklaw.

Wdrażanie attestation w potokach CI/CD

Dla architektów chmurowych i inżynierów DevOps ręczna weryfikacja raportów attestation nie jest ani skalowalna, ani praktyczna. Aby zbudować odporną infrastrukturę chmurową, attestation musi być głęboko zintegrowane z zautomatyzowanymi potokami wdrożeniowymi.

Nowoczesne wdrożenia kontenerów działające w Azure Kubernetes Service (AKS) z węzłami poufnymi mogą wykorzystywać kontenery sidecar lub wtyczki urządzeń (device plugins), aby automatycznie obsługiwać wymianę danych attestation. Gdy poufny pod się uruchamia, klient attestation pobiera raport sprzętowy, przesyła go do usługi Azure Attestation i zapisuje uzyskany token w pamięci podręcznej. Dopiero po zweryfikowaniu tokenu kontener aplikacji montuje bezpieczne woluminy i rozpoczyna obsługę żądań.

Wbudowując kontrole attestation w bramki wydań (release gates), zapewniasz, że każda nieautoryzowana zmiana kodu – czy to przypadkowa, czy złośliwa – natychmiast unieważnia pomiary sprzętowe. Wstrzymuje to proces udostępniania kluczy i zapobiega uruchomieniu skompromitowanego obciążenia w środowisku produkcyjnym.

Podsumowanie: zabezpieczanie danych w użyciu już dziś

Azure Confidential Computing zapewnia techniczne podstawy potrzebne do ochrony wrażliwych obciążeń w chmurze przed zagrożeniami dla nowoczesnej infrastruktury, ale sama izolacja sprzętowa jest niewystarczająca bez rygorystycznej weryfikacji. Opanowanie zdalnej atestacji pozwala architektom chmury ustanowić weryfikowalne zaufanie między kodem dzierżawy a sprzętem bare-metal, dzięki czemu dane w użyciu są równie dobrze chronione jak dane w spoczynku i w tranzycie. Aby posłuchać kompleksowego omówienia tych koncepcji bezpieczeństwa chmury i poznać szerszy krajobraz Microsoft 365 i Azure, posłuchaj pełnego odcinka podcastu M365 FM Podcast.

Często zadawane pytania

Jaki jest główny cel usługi Azure Attestation?

Azure Attestation to ujednolicona usługa chmurowa, która kryptograficznie weryfikuje wiarygodność Trusted Execution Environment i sprawdza integralność oprogramowania działającego wewnątrz niego, zanim zostaną udostępnione sekrety lub klucze szyfrujące.

Czy administrator chmury może obejść atestację sprzętową?

Nie. Atestacja sprzętowa opiera się na kluczach kryptograficznych wbudowanych bezpośrednio w krzem procesora przez producenta sprzętu. Ponieważ te klucze są niedostępne dla hiperwizorów i operatorów chmury, administratorzy nie mogą sfałszować prawidłowego raportu atestacji dla zagrożonego środowiska.

Jaka jest różnica między atestacją na poziomie maszyny wirtualnej a atestacją na poziomie procesu?

Atestacja na poziomie maszyny wirtualnej (na przykład AMD SEV-SNP) mierzy i weryfikuje cały system operacyjny maszyny wirtualnej wraz z jej obciążeniami. Atestacja na poziomie procesu (na przykład Intel SGX) izoluje i poddaje atestacji konkretne fragmenty kodu lub enklawy w ramach standardowego środowiska systemu operacyjnego.

Jak tokeny atestacji integrują się z Azure Key Vault?

Gdy poufne obciążenie pomyślnie zakończy uzgadnianie atestacji, otrzymuje podpisany token. Token ten może zostać przedstawiony usłudze Azure Key Vault Managed HSM w celu potwierdzenia integralności środowiska, co uruchamia automatyczne udostępnienie kluczy szyfrujących i poświadczeń bazy danych.