Grundlegende Konzepte
Im Folgenden finden Sie einige grundlegende Konzepte zu Microsoft Azure Attestation.
JSON Web Token (JWT)
JSON Web Token (JWT) ist eine offene RFC7519-Standardmethode zum sicheren Übertragen von Informationen zwischen Parteien als JavaScript Object Notation-Objekt (JSON). Diese Informationen können überprüft werden und sind vertrauenswürdig, da sie digital signiert sind. JWTs können mithilfe eines Geheimnisses oder eines öffentlichen/privaten Schlüsselpaars signiert werden.
JSON Web Key (JWK)
JSON Web Key (JWK) ist eine JSON-Datenstruktur, die einen kryptografischen Schlüssel darstellt. Diese Spezifikation definiert auch eine JSON-Datenstruktur für einen Satz von JWKs.
Nachweisanbieter
Der Nachweisanbieter gehört zum Azure-Ressourcenanbieter mit dem Namen „Microsoft.Attestation“. Der Ressourcenanbieter ist ein Dienstendpunkt, der den Azure Attestation-REST-Vertrag bereitstellt und mithilfe von Azure Resource Manager bereitgestellt wird. Jeder Nachweisanbieter berücksichtigt eine bestimmte erkennbare Richtlinie. Nachweisanbieter werden mit einer Standardrichtlinie für jeden Nachweistyp erstellt. (Beachten Sie, dass die VBS-Enclave über keine Standardrichtlinie verfügt.) Weitere Informationen zur Standardrichtlinie für SGX finden Sie unter Beispiele einer Nachweisrichtlinie.
Nachweisanforderung
Bei der Nachweisanforderung handelt es sich um ein serialisiertes JSON-Objekt, das von der Clientanwendung an den Nachweisanbieter gesendet wird. Das Anforderungsobjekt für eine SGX-Enclave verfügt über zwei Eigenschaften:
- „Quote“ – der Wert der Eigenschaft „Quote“ ist eine Zeichenfolge, die eine Base64URL-codierte Darstellung des Nachweisangebots enthält.
- „EnclaveHeldData“ – der Wert der Eigenschaft „EnclaveHeldData“ ist eine Zeichenfolge, die eine Base64URL-codierte Darstellung der Enclave Held Data enthält.
Azure Attestation überprüft die angegebene Eigenschaft „Quote“ und stellt anschließend sicher, dass der SHA256-Hash der angegebenen Enclave Held Data in den ersten 32 Bytes des Felds „reportData“ im Angebot ausgedrückt ist.
Nachweisrichtlinie
Eine Nachweisrichtlinie wird zum Verarbeiten der Nachweisbeweise verwendet und kann von den Kunden konfiguriert werden. Der Kern von Azure Attestation ist ein Richtlinienmodul, das Ansprüche verarbeitet, die den Beweis darstellen. Mithilfe von Richtlinien können Sie feststellen, ob Azure Attestation ein Nachweistoken auf Grundlage von Beweisen ausstellen soll (oder nicht) und somit den Attester unterstützt (oder nicht). Entsprechend führt ein Fehler beim Übergeben aller Richtlinien dazu, dass kein JWT-Token ausgegeben wird.
Falls die Standardrichtlinie im Nachweisanbieter die Anforderungen nicht erfüllt, können Kunden benutzerdefinierte Richtlinien in allen Regionen erstellen, die von Azure Attestation unterstützt werden. Die Richtlinienverwaltung ist ein wichtiges Feature, das Azure Attestation den Kunden bereitstellt. Richtlinien sind nachweistypspezifisch und können zum Identifizieren von Enclaves oder zum Hinzufügen von Ansprüchen zum Ausgabetoken bzw. zum Ändern von Ansprüchen in einem Ausgabetoken verwendet werden.
Beispiele für eine Nachweisrichtlinie finden Sie hier.
Vorteile der Richtliniensignatur
Eine Nachweisrichtlinie bestimmt letztendlich, ob Azure Attestation ein Nachweistoken ausstellt. Die Richtlinie bestimmt auch die Ansprüche, die im Nachweistoken generiert werden sollen. Daher ist es von größter Wichtigkeit, dass die vom Dienst ausgewertete Richtlinie tatsächlich die vom Administrator geschriebene Richtlinie ist und nicht von externen Entitäten manipuliert oder geändert wurde.
Das Vertrauensmodell definiert das Autorisierungsmodell des Nachweisanbieters, um die Richtlinie zu definieren und zu aktualisieren. Zwei Modelle werden unterstützt – eines basierend auf der Microsoft Entra-Autorisierung und eines basierend auf dem Besitz von kundenseitig verwalteten kryptografischen Schlüsseln (als isoliertes Modell bezeichnet). Das isolierte Modell ermöglicht es Azure Attestation, sicherzustellen, dass die vom Kunden übermittelte Richtlinie nicht manipuliert wird.
Im isolierten Modell erstellt der Administrator einen Nachweisanbieter, der einen Satz von X.509-Zertifikaten mit vertrauenswürdiger Signatur in einer Datei angibt. Der Administrator kann anschließend dem Nachweisanbieter eine signierte Richtlinie hinzufügen. Bei der Verarbeitung der Nachweisanforderung überprüft Azure Attestation die Signatur der Richtlinie mithilfe des öffentlichen Schlüssels, der entweder durch den Parameter „jwk“ oder den Parameter „x5c“ im Header dargestellt wird. Azure Attestation überprüft auch, ob der öffentliche Schlüssel im Anforderungsheader in der Liste der vertrauenswürdigen Signaturzertifikate enthalten ist, 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 sie kennt.
Beispiele finden Sie unter Beispiele für Richtliniensignaturgeber-Zertifikate.
Nachweistoken
Die Antwort von Azure Attestation ist eine JSON-Zeichenfolge, deren Wert JWT enthält. Azure Attestation verpackt die Ansprüche und generiert ein signiertes JWT. Der Signaturvorgang wird mit einem selbstsignierten Zertifikat ausgeführt, dessen Antragstellername mit dem AttestUri-Element des Nachweisanbieters übereinstimmt.
Die Get OpenID Metadata-API gibt eine OpenID Configuration-Antwort zurück, wie vom OpenID Connect Discovery-Protokoll festgelegt. Die API ruft Metadaten zu den Signaturzertifikaten ab, die von Azure Attestation verwendet werden.
Beispiele für ein Nachweistoken finden Sie hier.
Verschlüsselung für ruhende Daten
Zum Schutz von Kundendaten werden die Daten von Azure Attestation in Azure Storage gespeichert. Azure Storage verschlüsselt ruhende Daten, wenn diese in Rechenzentren geschrieben werden, und entschlüsselt sie für Kunden, damit diese darauf zugreifen können. Diese Verschlüsselung erfolgt mithilfe eines von Microsoft verwalteten Verschlüsselungsschlüssels.
Zusätzlich zum Schutz von Daten in Azure Storage wird von Azure Attestation auch Azure Disk Encryption (ADE) genutzt, um virtuelle Dienstcomputer zu verschlüsseln. Wenn Azure Attestation in einer Enclave in Azure Confidential Computing-Umgebungen ausgeführt wird, wird die ADE-Erweiterung derzeit nicht unterstützt. In solchen Szenarien ist die Auslagerungsdatei deaktiviert, um zu verhindern, dass Daten im Arbeitsspeicher gespeichert werden.
Auf den lokalen Festplattenlaufwerken der Azure Attestation-Instanz werden keine Kundendaten dauerhaft gespeichert.