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.
Vad är Trusted Hardware Identity Management (THIM) och dess roll i enklavattestering
Trusted Hardware Identity Management (THIM) hämtar Azure-säkerhetsbaslinjen för Azure Confidential Computing-noderna (ACC) från Intel och cachelagrar data. Den cachelagrade informationen används ytterligare av Azure Attestation för validering av 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 nyare versioner av Intel-certifikat, CRL:er, TCB-information (Trusted Computing Base) och quoting Enclave-identitet för ACC-noderna från Intel. Tjänsten bekräftar därför azure-säkerhetsbaslinjen som ska refereras av Azure-attestering samtidigt som tees verifieras, vilket avsevärt minskar attesteringsfel på grund av ogiltigförklaring eller återkallande av Intel-certifikat
Stöds SGX-attestering av Azure Attestation i miljöer som inte är Azure-miljöer
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.
Vilka valideringar utför Azure Attestation för attestera SGX-enklaver
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. Med hjälp av attesteringsprinciper kan kunder definiera auktoriseringsregler för TEE och även diktera utfärdanderegler för att generera attesteringstoken
Hur kan en kontrollant få säkerhet för SGX-attestering som stöds av Azure Attestation
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 och därigenom generera en fjärrattesterbar säkerhet.
Samma process kan implementeras för Azure-attestering. Men om du vill utnyttja fördelarna med THIM (Trusted Hardware Identity Management) när du har installerat 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.
Så här övergår du till Azure Attestation från andra SGX-attesteringsmodeller
- När du har installerat en virtuell Dator för konfidentiell databehandling i Azure installerar du Azure DCAP-biblioteket (Windows/Linux) för att utnyttja 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
Hur länge är en attesteringstoken giltig?
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 (t.ex. 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 (TEE)
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.
Var lagrar Azure Attestation kunddata?
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.