In dit artikel vindt u antwoorden op enkele van de meest voorkomende vragen over Azure Attestation.
Als uw Azure-probleem niet wordt opgelost in dit artikel, kunt u ook een ondersteuning voor Azure aanvraag indienen op de pagina ondersteuning voor Azure.
Wat is Trusted Hardware Identity Management (THIM) en de rol ervan in enclave-attestation
Met Trusted Hardware Identity Management (THIM) wordt de Azure-beveiligingsbasislijn opgehaald voor de knooppunten van Azure Confidential Computing (ACC) van Intel en worden de gegevens in de cache opgeslagen. De gegevens in de cache worden verder gebruikt door Azure Attestation bij het valideren van TEE's (Trusted Execution Environments).
THIM wordt aanbevolen om de volgende redenen:
- Biedt hoge beschikbaarheid
- Vermindert afhankelijkheden van extern gehoste services en internetverbinding.
- Haalt periodiek de nieuwere versies van Intel-certificaten, CRL's, TCB-gegevens (Trusted Computing Base) en Quoting Enclave-identiteit van de ACC-knooppunten van Intel op. De service bevestigt daarom dat de Azure-beveiligingsbasislijn wordt verwezen door Azure Attestation tijdens het valideren van de TEE's, waardoor attestation-fouten aanzienlijk worden verminderd vanwege ongeldigheid of intrekking van Intel-certificaten
Wordt SGX-attestation ondersteund door Azure Attestation in niet-Azure-omgevingen
Nee Azure Attestation is afhankelijk van de beveiligingsbasislijn die wordt opgegeven door Trusted Hardware Identity Management (THIM) om de TEE's te valideren. THIM is momenteel ontworpen ter ondersteuning van alleen Azure Confidential Computing-knooppunten.
Welke validaties voert Azure Attestation uit voor het attesteren van SGX-enclaves
Tijdens het SGX-attestation-proces voert Azure Attestation de volgende validaties uit:
- Valideert of de vertrouwde hoofdmap van de ondertekende enclave-offerte deel uitmaakt van Intel
- Valideert of de TEE-offerte voldoet aan de Azure-beveiligingsbasislijn zoals gedefinieerd door Trusted Hardware Identity Management (THIM)
- Als de klant een attestation-provider heeft gemaakt en een aangepast beleid heeft geconfigureerd, evalueert Azure Attestation naast de bovenstaande validaties de TEE-offerte op basis van het attestation-beleid. Met attestation-beleid kunnen klanten autorisatieregels definiëren voor de TEE en ook uitgifteregels dicteren voor het genereren van het attestation-token
Hoe kan een verificator het onderpand verkrijgen voor SGX-attestation die wordt ondersteund door Azure Attestation
Over het algemeen praat attestation-client voor de attestation-modellen met Intel als basis voor vertrouwen met enclave-API's om het enclave-bewijs op te halen. Enclave-API's roepen intern intel PCK-cachingservice aan om Intel-certificaten van het knooppunt op te halen die moeten worden getest. De certificaten worden gebruikt om het enclave-bewijs te ondertekenen, waardoor een extern attestable onderpand wordt gegenereerd.
Hetzelfde proces kan worden geïmplementeerd voor Azure Attestation. Als u echter gebruik wilt maken van de voordelen van Trusted Hardware Identity Management (THIM), wordt het aanbevolen om na de installatie van de virtuele ACC-machine de Azure DCAP-bibliotheek te installeren. Wanneer de Azure DCAP-bibliotheek is geïnstalleerd, worden de aanvragen voor het genereren van enclave-bewijs omgeleid van de Intel PCK-cachingservice naar THIM op basis van de overeenkomst met Intel. Azure DCAP-bibliotheek wordt ondersteund in Windows- en Linux-omgevingen.
Overstappen op Azure Attestation van andere SGX-attestation-modellen
- Na de installatie van de virtuele machine van Azure Confidential Computing installeert u de Azure DCAP-bibliotheek (Windows/Linux) om gebruik te maken van de voordelen van Trusted Hardware Identity Management (THIM).
- Er moet een externe attestation-client worden gemaakt waarmee het enclave-bewijs kan worden opgehaald en aanvragen naar Azure Attestation kunnen worden verzonden. Zie codevoorbeelden voor naslaginformatie
- Attestation-aanvragen kunnen worden verzonden naar het REST API-eindpunt van standaardproviders of aangepaste attestation-providers
- In de API-versie van 2018-09-01-preview moet de client microsoft Entra-toegangstoken verzenden, samen met het bewijsmateriaal naar het eindpunt van de SGX-attest-API. Het Microsoft Entra-toegangstoken is geen vereiste parameter voor het uitvoeren van SGX-attestation in api-versie 2020-10-01
Hoe kan de relying party de integriteit van het Attestation-token verifiëren en bevestigen dat Azure Attestation wordt uitgevoerd in een enclave
Het Attestation-token dat door Azure Attestation wordt gegenereerd, wordt ondertekend met behulp van een zelfondertekend certificaat. De handtekeningcertificaten worden weergegeven via een eindpunt voor OpenID-metagegevens. Relying party kan de handtekeningcertificaten ophalen van dit eindpunt en handtekeningverificatie van het attestation-token uitvoeren. Het handtekeningcertificaat bevat ook een SGX-offerte van de TEE waarin Azure Attestation wordt uitgevoerd. Als relying party ook liever controleert of Azure Attestation wordt uitgevoerd in een geldige SGX-enclave, kan de SGX-offerte worden opgehaald uit het handtekeningcertificaat en lokaal worden gevalideerd. Zie codevoorbeelden voor meer informatie
Hoe lang is een attestation-token geldig?
De geldigheidsduur van het attestation-token is 8 uur. Er is momenteel geen inrichting om de waarde aan te passen.
Het certificaat identificeren dat moet worden gebruikt voor handtekeningverificatie vanuit het OpenID-metagegevenseindpunt
Meerdere certificaten die worden weergegeven in het OpenID-eindpunt voor metagegevens komen overeen met verschillende use cases (bijvoorbeeld SGX-attestation) die worden ondersteund door Azure Attestation. Volgens de standaarden die zijn opgegeven door RFC 7515, moet het certificaat met sleutel-id (kid) die overeenkomen met de kid-parameter in de attestation-tokenheader worden gebruikt voor handtekeningverificatie. Als er geen overeenkomend kind wordt gevonden, wordt verwacht dat alle certificaten worden geprobeerd die worden weergegeven door het OpenID-metagegevenseindpunt.
Is het mogelijk dat de relying party geheimen deelt met de gevalideerde TEE's (Trusted Execution Environments)
Op het moment dat TEE-bewijs wordt gemaakt, kan code die in de TEE wordt uitgevoerd willekeurige informatie in het bewijsmateriaal bevatten. De TEE kan bijvoorbeeld een of meer asymmetrische sleutelparen maken, de onderdelen van deze sleutelparen serialiseren als JWKS JSON-tekenreeks en de JWKS JSON-tekenreeks opnemen in het TEE-bewijs als RunTimeData { quote, JWKS JSON string }. Azure Attestation controleert of SHA256-hash van de RuntimeData overeenkomt met de lagere 32 bytes van het kenmerk 'rapportgegevens' van de offerte. Na het evalueren van het TEE-bewijs genereert Azure Attestation JWT met de JWKS die beschikbaar is als een claim met de naam 'sleutels' onder de claim 'x-ms-runtime'. RunTimeData kan verder worden gebruikt door relying party om een beveiligd kanaal tot stand te brengen en gegevens veilig naar de TEE teE te verzenden.
Waar worden klantgegevens opgeslagen in Azure Attestation?
Azure Attestation slaat inactieve klantgegevens op tijdens de verwerking en replicatie voor BCDR-doeleinden binnen de geografie waarin de klant het service-exemplaar implementeert.