Nejčastější dotazy k ověření identity Microsoft Azure

Trusted Hardware Identity Management (THIM) načítá standardní hodnoty zabezpečení Azure pro uzly Azure Confidential Computing (ACC) z Intelu a ukládá data do mezipaměti. Ověření identity Azure také používá informace uložené v mezipaměti při ověřování důvěryhodných spouštěcích prostředí (TEE).

THIM se doporučuje z následujících důvodů:

• Nabízí vysokou dostupnost.
• Snižuje závislosti na externě hostovaných službách a připojení k internetu.
• Pravidelně načítá novější verze certifikátů Intel, seznamů CRL, informací o důvěryhodné výpočetní bázi (TCB) a uvozování identity enklávy uzlů ACC z Intelu. Služba potvrzuje standardní hodnoty zabezpečení Azure, na které se odkazuje ověření identity Azure při ověřování TEE, což výrazně snižuje selhání ověření identity kvůli zneplatnění nebo odvolání certifikátů Intel.

Ne. Ověření identity Azure závisí na standardních hodnotách zabezpečení uvedených službou Trusted Hardware Identity Management (THIM) k ověření TEE. ThiM je momentálně navržený tak, aby podporoval pouze důvěrné výpočetní uzly Azure.

Během procesu ověření identity SGX provádí ověření identity Azure následující ověření:

• Ověří, jestli důvěryhodný kořen podepsaných enklávových uvozovek patří intel.
• Ověří, jestli citace TEE splňuje standardní hodnoty zabezpečení Azure definované službou THIM (Trusted Hardware Identity Management).
• Pokud zákazník vytvořil zprostředkovatele ověření identity a nakonfiguroval vlastní zásadu, kromě výše uvedených ověření služba Azure Attestation vyhodnotí nabídku TEE vůči zásadám ověření identity. Zákazníci můžou k definování autorizačních pravidel pro TEE použít zásady ověření identity a také diktovat pravidla vystavování pro generování tokenu ověření identity.

Obecně platí, že pro modely ověření identity s Intel jako kořenem důvěryhodnosti klient ověření identity komunikuje s enklávovými rozhraními API za účelem načtení důkazů enklávy. Rozhraní API enklávy interně volají službu ukládání do mezipaměti Intel PCK, která načítá certifikáty Intel uzlu k otestování. Certifikáty se používají k podepsání důkazů enklávy, čímž se generuje vzdáleně potvrzené zajištění.

Stejný proces je možné implementovat pro ověření identity Azure. Pokud ale chcete po instalaci virtuálního počítače ACC využít výhody, které nabízí Trusted Hardware Identity Management (THIM), doporučujeme nainstalovat knihovnu Azure DCAP. Na základě smlouvy s Intelem se při instalaci knihovny Azure DCAP žádosti o generování důkazů enklávy přesměrují ze služby ukládání do mezipaměti Intel PCK do THIM. Knihovna Azure DCAP se podporuje v prostředích s Windows a Linuxem.

• Po instalaci virtuálního počítače Azure Confidential Computing nainstalujte knihovnu Azure DCAP (Windows/Linux), abyste získali výhody nabízené důvěryhodnou správou identit hardwaru (THIM).
• Klient vzdáleného ověření identity musí být vytvořený, který může načíst důkazy enklávy a odesílat žádosti do ověření identity Azure. Referenční informace najdete v ukázkách kódu.
• Žádosti o ověření identity je možné odeslat do koncového bodu rozhraní REST API výchozích poskytovatelů nebo vlastních zprostředkovatelů ověření identity.
• Ve verzi API verze 018-09-01-Preview musí klient odeslat přístupový token Microsoft Entra spolu s důkazy do koncového bodu rozhraní API pro ověření SGX. Přístupový token Microsoft Entra není povinný parametr pro ověření identity SGX ve verzi rozhraní API 2020-10-01 .

Token ověření identity vygenerovaný službou Azure Attestation je podepsaný pomocí certifikátu podepsaného svým držitelem. Podpisové certifikáty jsou zveřejněné prostřednictvím koncového bodu metadat OpenID. Předávající strana může načíst podpisové certifikáty z tohoto koncového bodu a provést ověření podpisu tokenu ověření identity. Podpisový certifikát obsahuje také nabídku SGX TEE, ve které běží ověřování Azure. Pokud předávající strana také dává přednost kontrole, jestli je ověřování Azure spuštěné uvnitř platné enklávy SGX, je možné citaci SGX načíst z podpisového certifikátu a místně ověřit. Další informace najdete v ukázkách kódu.

Doba platnosti tokenu ověření identity je 8 hodin. V současné době není k dispozici žádné zřízení pro přizpůsobení hodnoty.

Několik certifikátů vystavených v koncovém bodu metadat OpenID odpovídá různým případům použití (například ověření identity SGX) podporovaným ověřením identity Azure. Podle standardů určených dokumentem RFC 7515 se certifikát s ID klíče (kid) odpovídající parametru tokenu ověření identity použije k ověření podpisu. Pokud se nenajde žádné odpovídající dítě , očekává se, že vyzkoušíte všechny certifikáty vystavené koncovým bodem metadat OpenID.

V době vytváření důkazů TEE může kód spuštěný uvnitř TEE obsahovat do důkazů libovolné informace. Například TEE může vytvořit jeden nebo více asymetrických párů klíčů, serializovat součásti veřejného klíče těchto párů klíčů jako řetězec JSON JWKS a zahrnout řetězec JWKS JSON do důkazu TEE jako RunTimeData { quote, JWKS JSON string }. Ověření identity Azure kontroluje, jestli hodnota hash SHA256 modulu RuntimeData odpovídá nižším 32 bajtům atributu "data sestavy" uvozovky. Po vyhodnocení důkazů TEE azure Attestation vygeneruje JWT s JWKS dostupným jako deklarace identity s názvem "keys" v rámci deklarace identity x-ms-runtime. RunTimeData může předávající strana dále používat k vytvoření zabezpečeného kanálu a bezpečnému přenosu dat do TEE.

Služba Azure Attestation ukládá neaktivní uložená data zákazníků během zpracování a replikace pro účely BCDR v rámci geografické oblasti, ve které zákazník nasadí instanci služby.