Microsoft Azure Attestation (Usługa Poświadczenia)

Microsoft Azure Attestation to zintegrowane rozwiązanie do zdalnego weryfikowania wiarygodności platformy oraz integralności wykonywanych na niej binariów. Usługa obsługuje poświadczanie platform opartych na modułach Trusted Platform Modules (TPM), a także poświadczanie stanu zaufanych środowisk wykonawczych (TEE), takich jak enklawy Intel® Software Guard Extensions (SGX), enklawy Virtualization-based Security (VBS), Trusted Platform Modules (TPMs), Trusted launch for Azure VMs oraz Azure confidential VMs.

Atestacja to proces demonstrowania, że binaria oprogramowania zostały poprawnie uruchomione na zaufanej platformie. Zdalne strony ufające mogą wtedy nabrać pewności, że tylko zamierzone oprogramowanie działa na zaufanym sprzęcie. Azure Attestation to zintegrowana usługa skierowana do klienta i ramy działania do poświadczania.

Azure Attestation umożliwia nowoczesne modele bezpieczeństwa takie jak Azure Confidential computing i ochrona Intelligent Edge. Usługa otrzymuje dowody od jednostek obliczeniowych, przekształca je w zestaw roszczeń, weryfikuje je według konfigurowalnych polityk i generuje kryptograficzne dowody na potrzeby zastosowań opartych na roszczeniach (na przykład stron ufających i organów audytowych).

Azure Attestation obsługuje zarówno atestację platformową, jak i gościa w przypadku Poufnych Maszyn Wirtualnych (CVM) opartych na AMD SEV-SNP. Platforma atestacji oparta na Azure działa automatycznie podczas krytycznej ścieżki rozruchowej maszyn wirtualnych CVM, bez potrzeby działania ze strony klienta. Aby uzyskać więcej informacji na temat atestacji gości, zobacz Announcing general availability of guest attestation for confidential VMs.

Przypadki użycia

Azure Attestation oferuje kompleksowe usługi atestacyjne dla wielu środowisk i różnorodnych przypadków użycia.

Poświadczenie AMD SEV-SNP dla poufnych maszyn wirtualnych

Azure Konfidentialne Maszyny Wirtualne (VM) (CVM) są oparte na procesorach AMD z technologią SEV-SNP. CVM oferuje opcję szyfrowania dysku systemu operacyjnego maszyny wirtualnej za pomocą kluczy zarządzanych przez platformę lub kluczy zarządzanych przez klienta i wiąże klucze szyfrowania dysku z TPM maszyny wirtualnej. Gdy CVM się uruchamia, raport SNP zawierający pomiary oprogramowania układowego gościa VM jest wysyłany do Azure Attestation. Usługa sprawdza pomiary i wydaje token poświadczenia, który jest używany do zwolnienia kluczy z Managed-HSM lub Azure Key Vault. Te klucze są używane do odszyfrowania stanu vTPM maszyny wirtualnej gościa, odblokowania dysku systemu operacyjnego i uruchomienia CVM. Proces atestacji i wydania kluczy odbywa się automatycznie przy każdym uruchomieniu CVM i proces ten zapewnia, że CVM uruchamia się tylko po pomyślnej atestacji sprzętu.

Atestacja AMD SEV-SNP na Poufnych Kontenerach

Azure Confidential Containers opiera się na procesorach AMD z technologią SEV-SNP. Poufne kontenery, hostowane w Azure Container Instances i na Azure Kubernetes Service (w wersji zapoznawczej) oferują możliwość uruchamiania grup kontenerów w SEV-SNP chronionym zaufanym środowisku wykonywania, które izoluje grupę kontenerów od płaszczyzny sterowania kontenerami i innych uruchomionych kontenerów. Attestacja w poufnych kontenerach polega na pobieraniu raportu dotyczącym atestacji sprzętu AMD bezpośrednio z procesora. To zadanie można wykonać za pomocą kontenera przyczepki SKR lub skompilować je bezpośrednio w logice aplikacji. Raport sprzętowy można następnie wymienić z usługą Azure Attestation oraz zarządzanym modułem HSM lub usługą Premium Azure Key Vault (AKV), aby pobrać klucze tajne. Możesz również dostarczyć raport sprzętowy do własnego systemu kluczy, jeśli chcesz.

Zaświadczanie zaufanego uruchamiania

Klienci Azure mogą zapobiegać infekcjom bootkit i rootkit, włączając zaufane uruchomienie dla swoich maszyn wirtualnych (VM). Gdy maszyna wirtualna jest uruchomiona z włączonym Secure Boot i vTPM oraz z zainstalowanym rozszerzeniem atestacji gościa, pomiary vTPM są okresowo przesyłane do Azure Attestation w celu monitorowania integralności procesu rozruchu. Niepowodzenie w uwierzytelnieniu wskazuje na potencjalne złośliwe oprogramowanie, które jest prezentowane klientom za pośrednictwem Microsoft Defender dla Chmury, w formie Alertów i Rekomendacji.

Poświadczenie TPM

Attestacja oparta na Trusted Platform Modules (TPM) jest kluczowa dla dostarczenia dowodu na stan platformy. TPM działa jako źródło zaufania i koprocesor bezpieczeństwa, aby zapewnić kryptograficzną wiarygodność pomiarom (dowodom). Urządzenia z TPM mogą polegać na potwierdzeniu, aby udowodnić, że integralność rozruchu nie została naruszona, i używać twierdzeń do wykrywania włączenia stanu funkcji podczas rozruchu.

Aplikacje klienckie mogą być zaprojektowane, aby wykorzystać poświadczanie TPM, przez delegowanie zadań wymagających wysokiego poziomu bezpieczeństwa, aby odbywały się dopiero po zweryfikowaniu zabezpieczeń platformy. Takie aplikacje mogą następnie korzystać z Azure Attestation, aby rutynowo ustanawiać zaufanie do platformy i jej zdolności do dostępu do danych wrażliwych.

Poświadczenie enklawy SGX

Intel® Software Guard Extensions (SGX) oznacza izolację na poziomie sprzętowym, która jest wspierana przez niektóre modele procesorów Intel. SGX umożliwia uruchamianie kodu w oczyszczonych przedziałach nazywanych enklawami SGX. Dostęp i uprawnienia pamięci są następnie zarządzane przez sprzęt, aby zapewnić minimalną powierzchnię ataku z właściwą izolacją.

Aplikacje klienckie można zaprojektować tak, aby korzystały z enklaw SGX, delegując zadania wrażliwe na zabezpieczenia, które mają być wykonywane wewnątrz tych enklaw. Takie aplikacje mogą następnie korzystać z usługi Azure Attestation do rutynowego ustanawiania zaufania do enklawy i jej zdolności do dostępu do wrażliwych danych.

Procesory Intel® Xeon® Scalable obsługują tylko rozwiązania do atestacji oparte na ECDSA dla zdalnej atestacji enklaw SGX. Wykorzystując model atestacji oparty na ECDSA, usługa Azure Attestation wspiera walidację procesorów Intel® Xeon® E3 oraz platform serwerowych opartych na procesorach Intel® Xeon® Scalable.

Note

Aby przeprowadzić atestację platform serwerowych opartych na procesorach Intel® Xeon® Scalable za pomocą Azure Attestation, użytkownicy powinni zainstalować Azure DCAP w wersji 1.10.0 lub nowszą.

Open Enclave zaświadczenie

Open Enclave (OE) to zbiór bibliotek przeznaczonych do tworzenia jednolitej abstrakcji enklawowej, umożliwiających deweloperom tworzenie aplikacji opartych na TEE. Oferuje uniwersalny bezpieczny model aplikacji, który minimalizuje specyfikę platformy. Microsoft postrzega to jako istotny etap na drodze do upowszechnienia sprzętowych technologii enklaw, takich jak SGX, oraz zwiększenia ich wykorzystania w usłudze Azure.

OE standaryzuje określone wymagania dotyczące weryfikacji dowodu enklawy. To sprawia, że OE jest bardzo odpowiednim odbiorcą poświadczeń z usługi Azure Attestation.

Attestacja Azure działa w TEE

Azure Attestation ma kluczowe znaczenie dla scenariuszy poufnego przetwarzania, ponieważ wykonuje następujące czynności:

  • Sprawdza, czy dowody z enklawy są prawidłowe.
  • Ocenia materiał dowodowy enklawy na podstawie polityki zdefiniowanej przez klienta.
  • Zarządza i przechowuje polityki specyficzne dla dzierżawcy.
  • Generuje i podpisuje token używany przez strony ufające do interakcji z enklawą.

Aby zachować Microsoft operacyjnie poza zaufaną bazą obliczeniową (TCB), krytyczne operacje Azure Attestation takie jak walidacja oferty, generowanie tokenów, ocena zasad i podpisywanie tokenów są przenoszone do kontenerów poufnych opartych na SEV-SNP AMD.

Dlaczego warto używać Azure Attestation

Azure Attestation jest preferowanym wyborem do zaświadczania TEEs, ponieważ oferuje następujące korzyści:

  • Jednolita platforma do poświadczania wielu środowisk, takich jak moduły TPM, enklawy SGX i enklawy VBS.
  • Umożliwia tworzenie niestandardowych dostawców zaświadczania i konfigurację zasad w celu ograniczenia generowania tokenów.
  • Chroni dane podczas użycia dzięki implementacji w środowisku TEE.
  • Usługa o wysokiej dostępności.

Jak ustanowić relację zaufania z Azure Attestation

  1. Zweryfikuj, czy token poświadczenia jest generowany przez Azure Attestation - Token poświadczenia generowany przez Azure Attestation jest podpisywany przy użyciu certyfikatu samopodpisanego. URL certyfikatów podpisu jest udostępniany przez punkt końcowy metadanych OpenID. Zaufana strona może pobrać certyfikat podpisu i przeprowadzić weryfikację podpisu tokenu atestacji. Aby uzyskać więcej informacji, zobacz przykłady kodu.
  2. Sprawdź, czy Azure Attestation działa wewnątrz kontenera SEV-SNP — certyfikaty podpisywania tokenu zawierają informacje o środowisku TEE, w którym jest uruchomiona Azure Attestation. To zabezpieczenie TEE jest raportem SEV-SNP. Strona ufająca może sprawdzić, czy usługa Azure Attestation działa w prawidłowym środowisku TEE, poprzez lokalną weryfikację raportu. Aby zapoznać się z przykładami kodu, zobacz SEV-SNP.
  3. Zweryfikuj powiązanie raportu TEE usługi Azure Attestation z kluczem użytym do podpisania tokenu atestacyjnego — strona ufająca może sprawdzić, czy skrót klucza publicznego użytego do podpisania tokenu atestacyjnego jest zgodny z polem danych raportu TEE usługi Azure Attestation. Aby uzyskać więcej informacji, zobacz przykładowy kod.
  4. Zweryfikuj, czy pomiary kodu Azure Attestation są zgodne z opublikowanymi wartościami Azure - Kolateral TEE osadzony w certyfikatach podpisywania tokenów poświadczeń zawiera pomiary kodu TEE dla Azure Attestation. Jednostka uzależniona może sprawdzić, czy raport należy do Azure Attestation, porównując określone wartości pobrane z zabezpieczenia TEE w certyfikacie podpisywania tokenu zaświadczania z wartościami dostarczonymi przez zespół Azure Attestation. W przypadku SEV-SNP należy zweryfikować HOST_DATA. Aby uzyskać więcej informacji, zobacz przykładowy kod. Jeśli chcesz wykonać tę walidację, prześlij żądanie na stronie pomoc techniczna platformy Azure. Zespół Azure Attestation skontaktuje się z Tobą, gdy te konkretne wartości mają zostać poddane rotacji.
  5. Uzyskaj pewność co do pochodzenia kompilacji — usługa Azure Attestation jest zintegrowana z mechanizmem przejrzystości podpisywania firmy Microsoft (MST). MST rejestruje podpisy kodu w niezmiennym rejestrze odpornym na manipulacje. Usługa MST zapewnia kryptograficznie weryfikowalne potwierdzenia zgodne ze standardem SCITT, które zapewniają jasny wgląd w wdrożenia Azure Attestation — zwiększając zaufanie, inspekcję i zgodność z przepisami. Aby dowiedzieć się więcej o MST i o tym, jak weryfikować artefakty kompilacji, zobacz Informacje o rejestrze Microsoft Signing Transparency.

Wartości identyfikujące prawidłowe wystąpienia Azure Attestation powinny ulec zmianie podczas rotacji certyfikatów podpisywania kodu lub gdy aktualizacje zabezpieczeń wymagają nowych wersji zasad. Zespół Azure Attestation stosuje następujący harmonogram wdrożenia dla każdej planowanej rotacji:

  1. Zespół Azure Attestation powiadamia użytkowników o nowych wartościach z dwumiesięcznym okresem prolongaty w celu zaimplementowania odpowiednich zmian kodu.
  2. Po dwumiesięcznym okresie prolongaty Azure Attestation zaczyna korzystać z nowych wartości.
  3. Trzy miesiące po dacie powiadomienia Azure Attestation przestają używać starych wartości.

Dla nieplanowanych rotacji, w tym tych wymaganych przez aktualizacje zabezpieczeń, zespół Azure Attestation przekazuje nowe wartości z jednomiesięcznym okresem łaski.

Obsługa ciągłości działania i odzyskiwania po awarii (BCDR)

Ciągłość działania biznesu i odzyskiwanie po awarii (BCDR) dla Azure Attestation umożliwia ograniczenie przerw w świadczeniu usług wynikających z poważnych problemów z dostępnością lub zdarzeń katastroficznych w regionie.

Klastery wdrażane w dwóch regionach działają niezależnie w normalnych warunkach. W przypadku awarii lub wyłączenia jednej części regionu, następuje co następuje:

  • Azure Attestation BCDR zapewnia płynne przełączanie awaryjne, w którym klienci nie muszą podejmować żadnych dodatkowych kroków, aby odzyskać.
  • Moduł Azure Traffic Manager dla regionu wykrywa pogorszenie stanu sondy kondycji i przełącza punkt końcowy do regionu sparowanego.
  • Istniejące połączenia nie działają i powodują błędy serwera wewnętrznego lub problemy z przekroczeniem limitu czasu.
  • Wszystkie operacje płaszczyzny sterowania są zablokowane. Klienci nie mogą tworzyć dostawców zaświadczania w regionie podstawowym.
  • Wszystkie operacje płaszczyzny danych, w tym wywołania atestacji i konfiguracja zasad, są obsługiwane przez region pomocniczy. Klienci mogą nadal pracować na operacjach płaszczyzny danych przy użyciu oryginalnego identyfikatora URI odpowiadającego regionowi podstawowemu.

Kolejne kroki

  • Last updated on