Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel werden einige grundlegende Konzepte für den Microsoft Azure-Nachweis definiert.
JSON-Webtoken (JWTs)
JSON Web Token (JWT) ist eine offene Standard-RFC7519 Methode zum sicheren Übertragen von Informationen zwischen Parteien als JavaScript Object Notation (JSON)-Objekt. Diese Informationen können überprüft und als vertrauenswürdig eingestuft werden, da sie digital signiert sind. JWTs können mithilfe eines Geheimnisses oder eines öffentlichen/privaten Schlüsselpaars signiert werden.
JSON-Webschlüssel (JWK)
JSON Web Key (JWK) ist eine JSON-Datenstruktur, die einen kryptografischen Schlüssel darstellt. Diese Spezifikation definiert auch eine JWK Set JSON-Datenstruktur, die einen Satz von JWKs darstellt.
Nachweisanbieter
Der Nachweisanbieter gehört zum Azure-Ressourcenanbieter "Microsoft.Attestation". Der Ressourcenanbieter ist ein Dienstendpunkt, der azure Attestation REST-Vertrag bereitstellt und mit Azure Resource Manager bereitgestellt wird. Jeder Nachweisanbieter berücksichtigt eine bestimmte, auffindbare Richtlinie. Nachweisanbieter werden mit einer Standardrichtlinie für jeden Nachweistyp erstellt (beachten Sie, dass VBS-Enklave keine Standardrichtlinie hat). Weitere Informationen zur Standardrichtlinie für SGX finden Sie in den Beispielen einer Nachweisrichtlinie .
Nachweisanforderung
Die Nachweisanforderung ist ein serialisiertes JSON-Objekt, das von der Clientanwendung an den Nachweisanbieter gesendet wird. Das Anforderungsobjekt für SGX-Enklave verfügt über zwei Eigenschaften:
- "Quote" – Der Wert der Eigenschaft "Quote" ist eine Zeichenfolge, die eine base64URL-codierte Darstellung des Nachweiszitats enthält.
- "EnclaveHeldData" – Der Wert der Eigenschaft "EnclaveHeldData" ist eine Zeichenfolge, die eine Base64URL-codierte Darstellung der Enklave Held Data enthält.
Azure Attestation überprüft die angegebene Eigenschaft „Quote“, um sicherzustellen, dass der SHA256-Hash der angegebenen Enclave Held Data in den ersten 32 Bytes des Felds „reportData“ im Angebot ausgedrückt ist.
Nachweisrichtlinie
Die Attestierungsrichtlinie wird verwendet, um die Attestierungsnachweise zu verarbeiten und kann von Kunden konfiguriert werden. Der Kern von Azure Attestation ist ein Richtlinienmodul, das Behauptungen verarbeitet, die die Beweise darstellen. Richtlinien werden verwendet, um zu bestimmen, ob der Azure Attestation-Dienst basierend auf Nachweisen ein Attestation-Token ausstellt (oder nicht) und damit den Attester bestätigt (oder nicht). Entsprechend führt ein Fehler beim Übergeben aller Richtlinien dazu, dass kein JWT-Token ausgegeben wird.
Wenn die Standardrichtlinie im Nachweisanbieter die Anforderungen nicht erfüllt, können Kunden benutzerdefinierte Richtlinien in einer der Regionen erstellen, die vom Azure-Nachweis unterstützt werden. Die Richtlinienverwaltung ist ein wichtiges Feature, das Kunden von Azure Attestation bereitgestellt wird. Richtlinien sind spezifisch für den Nachweistyp und können verwendet werden, um Enklaven zu identifizieren oder Dem Ausgabetoken Ansprüche hinzuzufügen oder Ansprüche in einem Ausgabetoken zu ändern.
Beispiele für eine Nachweisrichtlinie finden Sie hier.
Vorteile der Richtliniensignierung
Eine Bestätigungsrichtlinie bestimmt letztendlich, ob ein Nachweistoken von Azure Attestation ausgestellt wird. Die Richtlinie bestimmt auch die Ansprüche, die im Nachweistoken generiert werden sollen. Es ist von entscheidender Bedeutung, dass die vom Dienst bewertete Richtlinie die vom Administrator geschriebene Richtlinie ist und dass sie von externen Entitäten nicht manipuliert oder geändert wurde.
Das Vertrauensmodell definiert das Autorisierungsmodell des Nachweisanbieters zum Definieren und Aktualisieren der Richtlinie. Zwei Modelle werden unterstützt – eine basierend auf der Microsoft Entra-Autorisierung und eine basierend auf dem Besitz von vom Kunden verwalteten kryptografischen Schlüsseln (als isoliertes Modell bezeichnet). Das isolierte Modell ermöglicht es Azure Attestation, sicherzustellen, dass die vom Kunden eingereichte Richtlinie nicht manipuliert wird.
Im isolierten Modell erstellt der Administrator einen Nachweisanbieter, der eine Gruppe von vertrauenswürdigen X.509-Zertifikaten in einer Datei angibt. Der Administrator kann dann dem Nachweisanbieter eine signierte Richtlinie hinzufügen. Der Azure-Nachweis überprüft bei der Verarbeitung der Nachweisanforderung die Signatur der Richtlinie mithilfe des öffentlichen Schlüssels, der durch den Parameter "jwk" oder "x5c" im Header dargestellt wird. Der Azure-Nachweis überprüft, ob sich der öffentliche Schlüssel im Anforderungsheader in der Liste der vertrauenswürdigen Signaturzertifikate befindet, die dem Nachweisanbieter zugeordnet sind. Auf diese Weise kann die vertrauende Seite (Azure Attestation) einer richtlinie vertrauen, die mit den X.509-Zertifikaten signiert ist, die es kennt.
Beispiele von Richtlinien-Signierzertifikaten finden Sie unten.
Nachweistoken
Die Antwort auf den Azure-Nachweis ist eine JSON-Zeichenfolge, deren Wert JWT enthält. Azure Attestation verpackt die Claims und generiert ein signiertes JWT. Der Signaturvorgang wird mithilfe eines selbstsignierten Zertifikats mit dem Subjektnamen ausgeführt, das dem AttestUri-Element des Attestierungsanbieters entspricht.
Die OpenID-Metadaten-API gibt eine OpenID-Konfigurationsantwort zurück, wie im OpenID Connect Discovery-Protokoll angegeben. Die API ruft Metadaten zu den von Azure Attestation verwendeten Signaturzertifikaten ab.
Siehe Beispiele für Attestationstoken.
Verschlüsselung für ruhende Daten
Um Kundendaten zu schützen, speichert Azure Attestation seine Daten in Azure Storage. Azure Storage bietet die Verschlüsselung von Daten im Ruhezustand, während die Daten in Rechenzentren geschrieben werden, und entschlüsselt sie, damit Kunden darauf zugreifen können. Diese Verschlüsselung erfolgt mithilfe eines von Microsoft verwalteten Verschlüsselungsschlüssels.
Neben dem Schutz von Daten im Azure-Speicher nutzt der Azure-Nachweis auch die Azure Disk Encryption (ADE) zum Verschlüsseln von Dienst-VMs. Für Azure Attestation, das in einer Enklave in vertraulichen Azure-Computing-Umgebungen ausgeführt wird, wird die ADE-Erweiterung derzeit nicht unterstützt. In solchen Szenarien wird die Seitendatei deaktiviert, um zu verhindern, dass Daten im Arbeitsspeicher gespeichert werden.
Auf lokalen Festplattenlaufwerken der Azure-Nachweisinstanz werden keine Kundendaten gespeichert.