Dieser Artikel bietet Antworten auf einige der häufigsten Fragen zu Azure Attestation.
Wenn Ihr Azure-Problem in diesem Artikel nicht behandelt wird, können Sie auf der Azure-Supportseite auch eine Azure-Supportanfrage einreichen.
Bedeutung von THIM (Trusted Hardware Identity Management) und der Rolle im Enclave-Nachweis
Trusted Hardware Identity Management (THIM) ruft die Azure-Sicherheitsbaseline für die ACC-Knoten (Azure Confidential Computing) von Intel ab und speichert die Daten zwischen. Die zwischengespeicherten Informationen werden außerdem von Azure Attestation bei der Validierung von TEEs (Trusted Execution Environments) verwendet.
THIM empfiehlt sich aus den folgenden Gründen:
- Bietet Hochverfügbarkeit
- Reduziert Abhängigkeiten von extern gehosteten Diensten und Internetkonnektivität.
- Die neueren Versionen von Intel-Zertifikaten, -Zertifikatsperrlisten, TCB-Informationen (Trusted Computing Base) und die Quoting Enclave-Identität der ACC-Knoten werden regelmäßig von Intel abgerufen. Der Dienst bestätigt daher bei der Überprüfung der TEEs die Azure-Sicherheitsbaseline, auf die Azure Attestation verweisen soll, und reduziert so die Nachweisfehler aufgrund von Invalidierung oder Sperrung von Intel-Zertifikaten erheblich.
Wird der SGX-Nachweis von Azure Attestation in Nicht-Azure-Umgebungen unterstützt?
Nein Azure Attestation ist von der Sicherheitsbaseline abhängig, die von Trusted Hardware Identity Management (THIM) angegeben wird, um die TEEs zu überprüfen. THIM ist zurzeit nur für die Unterstützung von Azure Confidential-Computeknoten konzipiert.
Welche Überprüfungen werden von Azure Attestation als Nachweis von SGX-Enklaven durchgeführt?
Während des SGX-Nachweisprozesses führt Azure Attestation die folgenden Überprüfungen aus:
- Überprüft, ob der vertrauenswürdige Stamm eines signierten Enclave-Quote zu Intel gehört.
- Überprüft, ob das TEE-Quote wie von Trusted Hardware Identity Management (THIM) definiert der Azure-Sicherheitsbaseline entspricht.
- Wenn der Kunde zusätzlich zu den obigen Überprüfungen einen Nachweisanbieter erstellt und eine benutzerdefinierte Richtlinie konfiguriert hat, wertet Azure Attestation das TEE-Quote gemäß der Nachweisrichtlinie aus. Mithilfe von Nachweisrichtlinien können Kunden Autorisierungsregeln für das TEE definieren und zudem Ausstellungsregeln zum Generieren des Nachweistokens vorgeben.
Wie kann ein Verifizierer die Sicherheiten für den durch Azure Attestation unterstützten SGX-Nachweis abrufen?
Bei den Nachweismodellen, bei denen Intel der Stamm der Vertrauensstellung ist, kommuniziert der Nachweisclient im Allgemeinen mit Enklaven-APIs, um die Enklavennachweise abzurufen. Enklaven-APIs rufen den Intel PCK-Cachedienst intern auf, um Intel-Zertifikate des nachzuweisenden Knotens abzurufen. Die Zertifikate werden verwendet, um den Enklavennachweis zu signieren und so eine remote nachweisbare Sicherheit zu generieren.
Der gleiche Prozess kann für Azure Attestation implementiert werden. Wenn Sie jedoch die Vorteile nutzen möchten, die Trusted Hardware Identity Management (THIM) bietet, empfiehlt es sich, nach der Installation des virtuellen ACC-Computers die Azure DCAP-Bibliothek zu installieren. Basierend auf der Vereinbarung mit Intel werden bei der Installation der Azure DCAP-Bibliothek die Anforderungen zum Erstellen von Enklavennachweisen vom Intel PCK-Cachedienst an THIM umgeleitet. Die Azure DCAP-Bibliothek wird in Windows- und Linux-basierten Umgebungen unterstützt.
Vorgehensweise beim Verlagern von anderen SGX-Nachweismodellen zu Azure Attestation
- Installieren Sie nach der Installation des virtuellen Azure Confidential-Computers die Azure DCAP-Bibliothek (Windows/Linux), um die Vorteile von Trusted Hardware Identity Management (THIM) zu nutzen.
- Der Remotenachweisclient muss erstellt werden, mit dem die Enklavennachweise abgerufen und Anforderungen an Azure Attestation gesendet werden können. Weitere Informationen finden Sie unter Codebeispiele.
- Nachweisanforderungen können an den REST-API-Endpunkt von Standardanbietern oder benutzerdefinierten Nachweisanbietern gesendet werden.
- In der 2018-09-01-Vorschau API-Version muss der Client Microsoft Entra-Zugriffstoken zusammen mit dem Nachweis an den SGX-Nachweis-API-Endpunkt senden. Das Microsoft Entra-Zugriffstoken ist kein erforderlicher Parameter zum Ausführen des SGX-Nachweises in der API-Version 2020-10-01
Wie kann die vertrauende Seite die Integrität des Nachweistokens überprüfen und bestätigen, dass Azure Attestation innerhalb einer Enclave ausgeführt wird?
Das von Azure Attestation generierte Nachweistoken wird mit einem selbstsignierten Zertifikat signiert. Die Signaturzertifikate werden über einen OpenID-Metadatenendpunkt verfügbar gemacht. Die vertrauende Seite kann die Signaturzertifikate von diesem Endpunkt abrufen und die Signaturüberprüfung des Nachweistokens durchführen. Das Signaturzertifikat enthält auch eine SGX-Quote der TEE, in der Azure Attestation ausgeführt wird. Wenn die vertrauende Seite auch bevorzugt prüft, ob Azure Attestation in einer gültigen SGX-Enclave ausgeführt wird, kann die SGX-Quote aus dem Signaturzertifikat abgerufen und lokal überprüft werden. Weitere Informationen finden Sie unter Codebeispielen.
Wie lange ist ein Nachweistoken gültig?
Die Gültigkeitsdauer des Nachweistokens beträgt 8 Stunden. Es gibt derzeit keine Bestimmung zum Anpassen des Werts.
Identifizieren des Zertifikats, das für die Signaturüberprüfung vom OpenID-Metadatenendpunkt verwendet werden soll
Mehrere Zertifikate, die im OpenID-Metadatenendpunkt verfügbar gemacht werden, entsprechen verschiedenen Anwendungsfällen (z. B. SGX-Nachweis), die von Azure Attestation unterstützt werden. Gemäß den Standards, die durch RFC 7515 angegeben werden, muss das Zertifikat mit der Schlüssel-ID (kid), die mit dem kid-Parameter im Header des Nachweistokens übereinstimmt, für die Signaturüberprüfung verwendet werden. Wenn keine übereinstimmende kid gefunden wird, wird erwartet, dass alle Zertifikate ausprobiert werden, die vom OpenID-Metadatenendpunkt bereitgestellt werden.
Ist es möglich, dass die vertrauende Seite geheime Schlüssel mit den überprüften TEEs (Trusted Execution Environments) gemeinsam nutzt?
Bei der Erstellung von TEE-Beweisen kann Code, der innerhalb des TEE ausgeführt wird, beliebige Informationen im Beweis enthalten. Beispiel: Das TEE kann asymmetrische Schlüsselpaare erstellen, die Komponente für den öffentlichen Schlüssel dieser Schlüsselpaare als JWKS JSON-Zeichenfolge serialisieren und die JWKS JSON-Zeichenfolge in den TEE-Beweis als „RunTimeData {quote, JWKS JSON string }“ aufnehmen. Azure Attestation überprüft, ob der SHA256-Hash von RuntimeData mit den unteren 32 Bytes des Attributs „report data“ des Quote übereinstimmt. Nach der Auswertung des TEE-Beweises generiert Azure Attestation JWT. mit den JWKS, die als Anspruch namens „keys“ unter dem Anspruch „x-ms-runtime“ verfügbar sind. RunTimeData kann durch die vertrauende Partei weiter verwendet werden, um sichere Kanäle einzurichten und Daten sicher an das TEE zu übertragen.
Wo speichert Azure Attestation Kundendaten?
Azure Attestation speichert ruhende Daten von Kunden während der Verarbeitung und Replikation für BCDR-Zwecke innerhalb des Gebiets, in dem der Kunde die Dienstinstanz bereitstellt.