Schützen Sie geistiges Eigentum auf Azure-VMs mit per Attestierung gesteuertem Secure Key Release

In diesem Artikel wird ein wiederverwendbares Muster zum Schutz einer vertraulichen Ressource beschrieben, z. B. proprietäre Machine Learning-Modellgewichtungen, ein lizenziertes Dataset oder eine geheime Konfiguration, die auf einem virtuellen Computer (VM) innerhalb des Azure-Abonnements einer anderen Person ausgeführt werden muss. Die Partei, die die Ressource (den Herausgeber) besitzt, unterscheidet sich von der Partei, die das Abonnement besitzt, in dem die VM ausgeführt wird (der Verbraucher). Der Kunde verfügt über vollständigen Azure-Zugriff auf die Kontrollebene dieser VM, darf jedoch nicht in der Lage sein, das Asset zu extrahieren.

Das Muster kombiniert mehrere dokumentierte Azure Features in Verteidigungsebenen. Sein kryptografischer Kern ist die durch Attestierung abgesicherte Secure Key Release (SKR) aus Azure Key Vault, gebunden an die vTPM-Attestierung von Trusted Launch. Es erfordert kein Confidential Computing, obwohl Confidential Computing als optionale Ebene hinzugefügt werden kann, wenn das Bedrohungsmodell dies erfordert.

Note

Secure Key Release ist ein Feature der Datenebene von Azure Key Vault Premium und Managed HSM. Es überprüft ein signiertes Microsoft Azure Attestation (MAA)-Token anhand der Freigaberichtlinie eines Schlüssels, unabhängig vom Computetyp. Vertrauliche VMs sind eine häufige Quelle dieser Token, aber sie sind nicht erforderlich – Vertrauenswürdige Start-VMs erzeugen auch MAA-Token. Informationen zu den Tokenanforderungen finden Sie unter Azure Key Vault Grammatik für sichere Schlüsselfreigaberichtlinien.

Szenario- und Bedrohungsmodell

Ein Anbieter stellt eine VM-basierte Arbeitslast in einem Kundenabonnement bereit (z. B. über den Azure Marketplace als Lösungsvorlage oder als freigegebenes Image). Die Workload benötigt einen Entschlüsselungsschlüssel, um das Asset des Herausgebers zur Laufzeit zu entsperren. Der Schlüssel darf nur für das originale, unveränderte Bild des Herausgebers freigegeben werden – niemals direkt für den Verbraucher und nie für ein manipuliertes oder ersetztes Bild.

Das Muster schützt gegen zwei unterschiedliche Bedrohungsrichtungen. Sie explizit zu benennen, macht die Layering-Entscheidungen deutlich.

Bedrohungsrichtung	Gegner	Fähigkeiten	Verteidigt von
A – der Verbraucher (VM/Abonnementbesitzer)	Der Besitzer des Abonnements mit vollständigen Azure-RBAC-Berechtigungen für die bereitgestellten Ressourcen	az vm run-command, benutzerdefinierte Skripterweiterungen, Snapshot und Austausch des Betriebssystemdatenträgers, serielle Konsole, Diebstahl von verwalteten Identitätstoken über IMDS – alles ohne SSH	Ebenen 1 bis 3
B – Der Cloudanbieter (Host/ Hypervisor)	Ein Operator mit Zugriff auf Host-Ebene auf VM-Arbeitsspeicher	Lesen des Gastspeichers von außerhalb des virtuellen Computers	Ebene 4 (optional)

Bedrohungsvektor A ist die primäre Bedrohung und prägt die Architektur maßgeblich. Im Basismuster ist die Bedrohungsrichtung B ein explizit akzeptiertes Risiko: Die Plattform ist vertrauenswürdig und entspricht der gemeinsamen Haltung, dem Hypervisor des Cloudanbieters zu vertrauen. Fügen Sie Layer 4 nur hinzu, wenn dem Hypervisor selbst misstraut werden muss (z. B. eine regulierte Arbeitslast, bei der eine Speicherverschlüsselung vorgeschrieben ist).

Wann Confidential Computing hinzugefügt werden sollte (Ebene 4)

Vertrauliches Computing ist keine Alternative zu diesem Muster – es ist die optionale Ebene 4 , die Sie darüber hinzufügen. Das Basismuster (Ebenen 1–3) macht die Schlüsselfreigabe bereits von der Attestierung abhängig, schützt das Asset vor dem Consumer und läuft auf jeder Gen2-Trusted-Launch-SKU zu den Standardkosten. Das Hinzufügen vertraulicher Datenverarbeitung ändert nicht die Funktionsweise des Musters: SKR, das gehärtete Image und die Netzwerkisolation bleiben unverändert, und der Freigabefluss ist identisch. Die einzigen Unterschiede bestehen darin, dass sich die Freigaberichtlinie auf Hardware-TEE-Nachweise anstelle von vTPM-Nachweisen zum gemessenen Start stützt und die Workload auf einer SKU für vertrauliche VMs ausgeführt wird. Sie erhalten Schutz vor Bedrohungsrichtung B (host/Hypervisor) und handeln SKU, GPU und Region zu Premiumkosten.

Die folgende Tabelle zeigt, was Layer 4 hinzufügt und was sie kostet – keine Wahl zwischen zwei Mustern:

Consideration	Basismuster (Layer 1–3, vertrauenswürdiger Start)	Mit hinzugefügter Ebene 4 (Vertraulicher Computer)
Schützt das Asset vor dem Konsumenten (Bedrohung A)	Ja	Ja (unverändert)
Schützt die Ressource vor dem Host / Hypervisor (Bedrohung B)	Nein (akzeptiertes Risiko)	Ja (Speicherverschlüsselung)
Attestierungsbasierte Schlüsselfreigabe	vTPM-Nachweise für den gemessenen Start	Hardware-TEE-Ansprüche
GPU-SKU-Verfügbarkeit	Alle Gen2-SKUs	Beschränkt auf vertrauliche GPU-SKUs und Kontingente
Region und SKU-Breite	Umfassend	Schmaler
Relative Kosten	Standard-VM-Preise	Premium

Beginnen Sie mit dem Basismuster. Fügen Sie Layer 4 nur hinzu, wenn Sie dem Hypervisor misstrauen müssen – beispielsweise bei einer regulierten Workload, die Speicherverschlüsselung vorschreibt – und dabei die eingeschränktere Verfügbarkeit von SKUs, GPUs und Regionen sowie die höheren Kosten in Kauf nehmen.

Die Elemente des Musters

Das Muster ist ein „Defense-in-Depth“-Stapel. Jede Ebene schützt eine bestimmte Bedrohungsrichtung: Layer 1 bis 3 verteidigen gegen den Verbraucher (Bedrohungsrichtung A) und die optionale Ebene 4 schützt gegen den Host (Bedrohungsrichtung B). Das geschützte Objekt befindet sich im Kern, erreichbar nur über jede umschließende Ebene.

Das geschützte Objekt befindet sich im Kern. Vier konzentrische Schichten umschließen es, von innen nach außen: Schicht 1, eine durch Attestierung geschützte sichere Schlüsselfreigabe (Attestation-gated Secure Key Release), bei der die Freigabe des Schlüssels von „Measured-Boot“-Nachweisen des vTPM abhängt; Schicht 2, ein gehärtetes Image mit dm-verity, einem schreibgeschützten Root-Dateisystem sowie ohne SSH oder Agent; Schicht 3, Netzwerkisolierung mit privaten Endpunkten, ohne öffentlichen ausgehenden Datenverkehr und mit „Deny“-Zuweisungen; sowie Schicht 4 (optional, mit gestricheltem Rand dargestellt): Confidential Computing, das eine Verschlüsselung des Host-Speichers bietet. Die Ebenen 1 bis 3 schützen vor Bedrohungsrichtung A: dem Benutzer bzw. der VM sowie dem Abonnementbesitzer, der Run-Command, Datenträger-Snapshots und -Austausch, die serielle Konsole und den Diebstahl verwalteter Identitäten nutzt. Layer 4 schützt vor Bedrohungsrichtung B, dem Host oder Hypervisor, der Gastspeicher liest.

Die Ebenen schützen die Ressource im Ruhezustand und während der Nutzung. Zur Laufzeit interagieren die VM des Verbrauchers und die Vertrauensanker des Herausgebers wie folgt:

Der Consumer-Mandant (nicht vertrauenswürdiger Betreiber) enthält die Trusted Launch-VM mit Secure Boot, einem vTPM und einem gehärteten Image. Der Herausgebermandant (der die Vertrauensanker enthält) umfasst Microsoft Azure Attestation sowie ein Key Vault Premium oder ein Managed HSM, in dem der exportierbare Schlüssel und die Freigaberichtlinie gespeichert sind. Der Ablauf umfasst vier Schritte: (1) Der virtuelle Computer sendet eine Nachweisanforderung mit vTPM-Nachweisen an Microsoft Azure Attestation; (2) Microsoft Azure Attestation gibt ein signiertes MAA-Token zurück, das die Ansprüche "secureboot" und "PCR" an die VM enthält; (3) Der virtuelle Computer sendet "POST /keys/{key}/release" mit dem MAA-Token an Key Vault; (4) Key Vault gibt den Schlüssel zurück, der in den kurzlebigen vTPM-Schlüssel oder "AccessDenied" eingeschlossen ist, wenn die Richtlinie nicht erfüllt ist.

Layer 1: Attestierungsgesteuerte sichere Schlüsselfreigabe (die kryptografische Schranke)

Diese Ebene ist die Grundlage. Eine VM mit vertrauenswürdigem Start wird mit Secure Boot und einem virtuellen TPM (vTPM) gestartet. Die vTPM erfasst die Bootkette in den Platform Configuration Registers (PCRs) und erstellt so einen kryptografischen Fingerabdruck dessen, was genau gestartet wurde. Der Gast fordert ein MAA-Token an, das diese Messwerte enthält, z. B. den x-ms-azurevm-attested-pcr-values.pcr0-Anspruch sowie secureboot bis pcr7. Anschließend ruft es den Endpunkt von Key Vault /release auf und legt das Token vor. Key Vault überprüft die Signatur des Tokens und evaluiert das Token anhand der Freigaberichtlinie des Schlüssels. Wenn die Angaben der Richtlinie übereinstimmen, gibt Key Vault den Schlüssel frei, der mit dem ephemeren Schlüssel des vTPM umschlossen ist, sodass nur diese attestierte VM ihn entschlüsseln kann. Wenn sie nicht übereinstimmen, gibt das Release AccessDenied zurück.

Was sie blockiert (Bedrohung A): Eine manipulierte, umimaged oder ausgetauschte VM misst verschiedene PCRs und kann den Schlüssel nicht abrufen. Ein Snapshot des Betriebssystemdatenträgers, der auf einer anderen VM eingebunden ist, schlägt auch fehl.

Eine repräsentative Freigaberichtlinie für einen virtuellen vertrauenswürdigen Startcomputer:

{
  "version": "1.0.0",
  "anyOf": [
    {
      "authority": "https://<MAA_PROVIDER>.<region>.attest.azure.net",
      "allOf": [
        { "claim": "secureboot", "equals": true },
        { "claim": "x-ms-azurevm-attested-pcr-values.pcr4", "equals": "<BASE64_PCR4>" },
        { "claim": "x-ms-azurevm-attested-pcr-values.pcr7", "equals": "<BASE64_PCR7>" }
      ]
    }
  ]
}

Ebene 2: Gehärtetes Image (zum Schutz der entschlüsselten Ressource)

Layer 1 steuert, ob der Schlüssel freigegeben wird; den Wert schützt es nicht, sobald er im laufenden Gastsystem entschlüsselt ist. Härtung des Bilds zum Verkleinern der Angriffsfläche in Gast- und Steuerungsebene: Dateisystemintegrität (z. B. dm-verity), ein schreibgeschütztes Stammdateisystem, kein SSH-Daemon, keine interaktive Anmeldung und kein In-Guest-Agent, der vom Operator bereitgestellte Befehle ausführen kann.

Was sie blockiert (Bedrohung A): In-Guest-Ausbeutung einer ausgeführten, bestätigten VM – nicht autorisierte Prozesse, Berechtigungseskalation, Extrahieren der entschlüsselten Ressource aus dem Prozessspeicher über eine Sicherheitslücke auf Betriebssystemebene.

Ebene 3: Netzwerkisolation (Verkleinern der Oberfläche)

Beschränken Sie, wie der virtuelle Computer mit den Vertrauensankern und -daten spricht. Verwenden Sie private Endpunkte für Key Vault, Speicher und alle Registrierungen; einen privaten Pfad zum Nachweisanbieter, privates DNS und keinen unnötigen öffentlichen Ausgang. Wenn der Bereitstellungsmechanismus dies unterstützt – zum Beispiel eine verwaltete Anwendung – können Verweigerungszuweisungen dem Verbraucher auch die RBAC-Berechtigungen für die Compute-Ressourcen entziehen und so Angriffe auf die Steuerungsebene (run-command, Datenträgervorgänge, serielle Konsole, Identitätsdiebstahl) direkt unterbinden. Bei einer Bereitstellung über eine Lösungsvorlage behält der Kunde die RBAC-Kontrolle über die bereitgestellten Ressourcen, sodass eine Härtung der Kontrollebene nicht verfügbar ist; dabei übernehmen Layer 1 und 2 die Abwehr gegen Bedrohung A: Ein Snapshot oder ein ausgetauschter Datenträger besteht die Attestierung nicht (Layer 1), und das gehärtete Image (Layer 2) verhindert die Extraktion des entschlüsselten Assets innerhalb des Gastsystems.

Was sie blockiert (Bedrohung A): Reduziert die verfügbar gemachte Oberfläche sowohl für Angriffe auf der Steuerebene als auch für Datenebenen und verhindert Exfiltrationspfade vom bestätigten Gast.

Ebene 4 (optional): Vertrauliches Computing (schützt Bedrohungsrichtung B)

Alles oben vertraut dem Host. Wenn Sie dem Hypervisor nicht vertrauen können, führen Sie die Workload auf einer vertraulichen VM (AMD SEV-SNP oder Intel TDX) aus. Die Speicherverschlüsselung verhindert, dass der Host den Gastspeicher liest, und SKR stuft in der Freigaberichtlinie von vTPM-Claims für den gemessenen Startvorgang auf Hardware-TEE-Claims hoch. Diese Ebene ist die einzige Ebene, die die Bedrohungsrichtung B schützt. Dies ist standardmäßig deaktiviert, da sie die Verfügbarkeit von SKU, GPU und Region einschränkt und Kosten hinzufügt.

Mandantenübergreifende Identität

Der Herausgeber verwaltet die Vertrauensanker – Key Vault (oder verwaltetes HSM) und den Bescheinigungsanbieter – im Mandanten des Herausgebers, außerhalb des RBAC des Verbrauchers. Die attestierte VM wird im Mandanten des Verbrauchers ausgeführt und muss Key Vault über diese Grenze hinweg aufrufen. Zwei Plattformeinschränkungen ausschließen die offensichtlichen Ansätze:

• Eine verwaltete Identität existiert in genau einem Mandanten. Der Mandant des Herausgebers erkennt oder gibt Token nicht an eine verwaltete Identität aus, die sich im Mandanten des Verbrauchers befindet.
• Eine Azure RBAC-Rollenzuweisung kann nur auf eine Identität im eigenen Mandanten der Ressource abzielen, sodass Sie der verwalteten Identität des Verbrauchers keine Rolle im Key Vault des Herausgebers gewähren können.

Eine Verbundidentitätsanmeldeinformation (FIC) kann diese Lücke ebenfalls nicht direkt überbrücken: Entra ID lässt nicht zu, dass eine FIC Token vertraut, die von einem anderen Entra-Mandanten ausgestellt werden, sodass eine Anwendung des Herausgebers die verwaltete Identität des Consumers nicht über diese Grenze hinweg föderieren kann.

Das Muster, das funktioniert, platziert die Überbrückungsidentität – eine mehrinstanzenfähige Anwendung – auf der Verbraucherseite:

1. Der Nutzer registriert in seinem Mandanten eine Anwendung mit mehreren Mandanten und konfiguriert dafür einen mandanteninternen FIC, der der verwalteten Identität der VM vertraut. Ein FIC, das einer Identität im selben Mandanten vertraut, ist zulässig.
2. Der Herausgeber integriert diese Anwendung in seinen eigenen Mandanten, indem er einen Dienstprinzipal für sie bereitstellt und diesem Prinzipal die rolle "Key Vault Crypto Service Release User" auf dem Schlüssel gewährt. Dieser absichtliche Onboarding-Schritt für jeden einzelnen Verbraucher ist der Schritt, in dem der Herausgeber einem externen Akteur Zugriff auf seinen Mandanten gewährt.
3. Zur Laufzeit ruft die verwaltete Identität des virtuellen Computers ein Token von IMDS ab, wechselt es über den FIC, um sich als mehrinstanzenfähige Anwendung zu authentifizieren, und ruft den Endpunkt Key Vault mit dem MAA-Token im Anforderungstext /release auf.

Important

Der Identitätsaustausch ist nicht die Sicherheitsgrenze. Da die Registrierung der Multi-Mandanten-Anwendung dem Konsumenten gehört, kann ein Administrator aufseiten des Konsumenten weitere Anmeldeinformationen (wie etwa ein Client Secret) hinzufügen und diesen Ablauf manuell auslösen – die Identitätsebene bietet dem Herausgeber also keinerlei Schutz vor einem böswilligen Konsumenten. Die tatsächliche Grenze ist SKR + Attestierung (Schicht 1): Selbst wenn ein gültiges Publisher-Mandanten-Token vorliegt, weigert sich Key Vault, den Schlüssel freizugeben, sofern nicht ein gültiges MAA-Token die Freigaberichtlinie erfüllt, und nur das echte, attestierte Image des Publishers kann ein solches Token erzeugen. Die Identitätsebene leitet die Anfrage nur an den richtigen Tresor weiter.

Walkthrough

1. Stellen Sie die Vertrauensanker bereit (Mandant des Herausgebers). Erstellen Sie ein Key Vault Premium oder verwaltetes HSM. Erstellen Sie einen exportierbaren RSA-HSM Schlüssel. Fügen Sie eine Releaserichtlinie an, die Ihre MAA-Autorität und die Ansprüche für vertrauenswürdigen Start festschreibt (secureboot, ausgewählt x-ms-azurevm-attested-pcr-values.pcrN).
2. Ermitteln Sie die erwarteten PCR-Werte. Attestieren Sie einmal eine nachweislich vertrauenswürdige Instanz Ihres Images und lesen Sie x-ms-azurevm-attested-pcr-values aus dem zurückgegebenen MAA-Token aus. Fixieren Sie die PCRs, die Ihre Bootkette misst – häufig pcr4 (Bootloader/Kernel) und pcr7 (Secure-Boot-Status).
3. Stellen Sie die Arbeitsauslastung (Consumermandant) bereit. Stellen Sie einen virtuellen Computer mit vertrauenswürdigem Start (Gen2) bereit, auf dem das gehärtete Image ausgeführt wird. Weisen Sie ihr eine verwaltete Identität zu und verbinden Sie diese Identität der in der mandantenübergreifenden Identität beschriebenen mehrinstanzenfähigen Anwendung, deren Dienstprinzipal der Herausgeber Key Vault Crypto Service Release User für den Schlüssel gewährt hat.
4. Attestieren und zur Laufzeit freigeben. Der Gast ruft ein MAA-Token ab und ruft dann auf POST /keys/{key-name}/release. Key Vault überprüft und gibt den umschlossenen Schlüssel zurück; der Gast entschlüsselt ihn innerhalb der VM.
5. Überprüfen Sie den negativen Fall. Ändern Sie einen in der Freigaberichtlinie fixierten PCR-Wert in einen nicht übereinstimmenden Wert (oder starten Sie ein modifiziertes Image), und bestätigen Sie, dass die Freigabe AccessDenied zurückgibt.

Beispiele für ausführbaren Code finden Sie unter Related content.

Verwandte Inhalte

• Secure Key Release-Richtliniengrammatik in Azure Key Vault
• Sichere Schlüsselfreigabe mit Azure Key Vault und Azure Confidential Computing
• Beispiele für Secure Key Release-Richtlinien
• Übersicht über Microsoft Azure Attestation
• Vertrauenswürdiger Start für virtuelle Azure-Computer
• Workload-Identitätsverbund
• Beispiel: cvm-securekey-release-app in Azure/confidential-computing-cvm-guest-attestation
• Beispiel: SKR-Beispiele in Azure-Samples/confidential-computing