Den här artikeln innehåller svar på några av de vanligaste frågorna om Azure-attestering.
Om ditt Azure-problem inte åtgärdas i den här artikeln kan du även skicka en Azure-supportbegäran på Azure-supportsidan.
Trusted Hardware Identity Management (THIM) hämtar Azure-säkerhetsbaslinjen för Azure Confidential Computing-noderna (ACC) från Intel och cachelagrar data. Azure Attestation använder också cachelagrad information för att validera betrodda körningsmiljöer (TEE).
THIM rekommenderas av följande skäl:
- Erbjuder hög tillgänglighet
- Minskar beroenden för externt värdbaserade tjänster och Internetanslutning.
- Hämtar regelbundet de nyare versionerna av Intel-certifikat, CRL:er, TCB-information (Trusted Computing Base) och quoting Enclave-identiteten för ACC-noderna från Intel. Tjänsten bekräftar att Azure-säkerhetsbaslinjen refereras av Azure-attesteringen samtidigt som du validerar TEE:erna, vilket avsevärt minskar attesteringsfelen på grund av att Intel-certifikaten har ogiltigförklarats eller återkallats.
Nej. Azure-attestering är beroende av säkerhetsbaslinjen som anges av THIM (Trusted Hardware Identity Management) för att verifiera TEE:erna. THIM är för närvarande utformat för att endast stödja Azure Confidential-beräkningsnoder.
Under SGX-attesteringsprocessen utför Azure Attestation följande valideringar:
- Verifierar om den betrodda roten för signerat enklavercitat tillhör Intel
- Verifierar om TEE-offerten uppfyller Azures säkerhetsbaslinje enligt definitionen i Trusted Hardware Identity Management (THIM)
- Om kunden har skapat en attesteringsprovider och konfigurerat en anpassad princip utvärderar Azure Attestation, utöver ovanstående valideringar, TEE-offerten mot attesteringsprincipen. Kunder kan använda attesteringsprinciper för att definiera auktoriseringsregler för TEE och även diktera utfärdanderegler för att generera attesteringstoken.
I allmänhet för attesteringsmodellerna med Intel som roten till förtroende, talar attesteringsklienten med enklaver-API:er för att hämta enklavens bevis. Enklaver-API:er anropar internt Intel PCK-cachelagringstjänsten för att hämta Intel-certifikat för noden som ska intygas. Certifikaten används för att signera enklaverbeviset, vilket genererar en fjärrattesterbar säkerhet.
Samma process kan implementeras för Azure-attestering. Men om du vill dra nytta av fördelarna med THIM (Trusted Hardware Identity Management) efter installationen av den virtuella ACC-datorn rekommenderar vi att du installerar Azure DCAP-biblioteket. Baserat på avtalet med Intel omdirigeras begäranden om att generera enklaver från Intel PCK-cachelagringstjänsten till THIM när Azure DCAP-biblioteket installeras. Azure DCAP-biblioteket stöds i Windows- och Linux-baserade miljöer.
- När du har installerat en virtuell dator med azure confidential computing installerar du Azure DCAP-biblioteket (Windows/Linux) för att dra nytta av fördelarna med THIM (Trusted Hardware Identity Management).
- Fjärrattesteringsklienten måste redigeras som kan hämta enklavens bevis och skicka begäranden till Azure Attestation. Se kodexempel för referens.
- Attesteringsbegäranden kan skickas till REST API-slutpunkten för standardprovidrar eller anpassade attesteringsproviders.
- I API-versionen 2018-09-01-preview måste klienten skicka Microsoft Entra-åtkomsttoken tillsammans med bevisen för att SGX-attest-API-slutpunkten. Microsoft Entra-åtkomsttoken är inte en obligatorisk parameter för att utföra SGX-attestering i API-versionen 2020-10-01 .
Hur kan den förlitande parten verifiera integriteten för attesteringstoken och bekräfta att Azure Attestation körs i en enklav?
Attesteringstoken som genereras av Azure Attestation är signerad med ett självsignerat certifikat. Signeringscertifikatet exponeras via en metadataslutpunkt för OpenID. Förlitande part kan hämta signeringscertifikaten från den här slutpunkten och utföra signaturverifiering av attesteringstoken. Signeringscertifikatet innehåller även SGX-offert för tee där Azure Attestation körs. Om förlitande part också föredrar att kontrollera om Azure Attestation körs i en giltig SGX-enklav kan SGX-offerten hämtas från signeringscertifikatet och valideras lokalt. Mer information finns i kodexempel.
Giltighetstiden för attesteringstoken är 8 timmar. Det finns för närvarande ingen etablering för att anpassa värdet.
Så här identifierar du certifikatet som ska användas för signaturverifiering från OpenID-metadataslutpunkten
Flera certifikat som exponeras i OpenID-metadataslutpunkten motsvarar olika användningsfall (till exempel SGX-attestering) som stöds av Azure Attestation. Enligt de standarder som anges i RFC 7515 ska certifikatet med nyckel-ID (kid) som matchar barnparametern i attesteringstokens huvud användas för signaturverifiering. Om ingen matchande unge hittas förväntas den prova alla certifikat som exponeras av OpenID-metadataslutpunkten.
Är det möjligt för den förlitande parten att dela hemligheter med de verifierade betrodda körningsmiljöerna ??
När TEE-bevis skapas kan kod som körs i TEE innehålla godtycklig information i bevisen. T.ex. kan TEE skapa ett eller flera asymmetriska nyckelpar, serialisera de offentliga nyckelkomponenterna i dessa nyckelpar som JWKS JSON-sträng och inkludera JWKS JSON-strängen i TEE-bevisen som RunTimeData { quote, JWKS JSON-sträng }. Azure Attestation kontrollerar om SHA256-hash för RuntimeData matchar de lägre 32 byteen i citationsattributet "rapportdata". Efter utvärdering av TEE-bevisen genererar Azure Attestation JWT med JWKS tillgängligt som ett anspråk med namnet "nycklar" under anspråket "x-ms-runtime". The RunTimeData can be further used by relying party to establish secure channel and securely transmit data to the TEE.
Azure Attestation lagrar kunddata i vila under bearbetning och replikering för BCDR-ändamål inom det geografiska område som kunden distribuerar tjänstinstansen i.