Microsoft Azure Attestation
Microsoft Azure Attestation ist eine einheitliche Lösung zur Remoteüberprüfung der Vertrauenswürdigkeit einer Plattform und der Integrität der darin ausgeführten Binärdateien. Der Dienst unterstützt den Nachweis der TPM-basierten (Trusted Platform Module) Plattformen sowie den Nachweis des Zustands vertrauenswürdiger Ausführungsumgebungen (Trusted Execution Environments, TEEs), wozu beispielsweise SGX-Enclaves (Intel® Software Guard Extensions), VBS-Enclaves (virtualisierungsbasierte Sicherheit), Vertrauenswürdige Plattformmodule (TPMs), vertrauenswürdiger Start für Azure-VMs und vertrauenswürdige Azure-VMs zählen.
Der Nachweis ist ein Prozess, um zu veranschaulichen, dass Softwarebinärdateien auf einer vertrauenswürdigen Plattform ordnungsgemäß instanziiert wurden. Vertrauende Remoteseiten können dann sicher sein, dass nur die vorgesehene Software auf vertrauenswürdiger Hardware ausgeführt wird. Azure Attestation ist ein einheitlicher Service für die Kunden und ein Framework für den Nachweis.
Azure Attestation ermöglicht innovative Sicherheitsparadigmen wie Confidential Computing unter Azure und Intelligent Edge-Schutz. Kunden haben die Möglichkeit angefordert, den Standort eines Computers, die Stellung eines virtuellen Computers (VM) auf diesem Computer und die Umgebung, in der die Enclaves auf diesem virtuellen Computer ausgeführt werden, einzeln zu überprüfen. Azure Attestation ermöglicht diese und viele zusätzliche Kundenanforderungen.
Azure Attestation erhält Beweise von Compute-Entitäten, wandelt sie in einen Satz von Ansprüchen um, überprüft sie anhand konfigurierbarer Richtlinien und erzeugt kryptografische Nachweise für anspruchsbasierte Anwendungen (z. B. vertrauende Seiten und Überwachungsbehörden).
Azure Attestation unterstützt sowohl den Plattform- als auch den Gastnachweis von AMD SEV-SNP-basierten vertraulichen VMs (CVMs). Azure Attestation-basierter Plattformnachweis erfolgt automatisch während des kritischen Startpfads von CVMs, ohne dass eine Kundenaktion erforderlich ist. Weitere Informationen zum Gastnachweis finden Sie unter Announcing general availability of guest attestation for confidential VMs (Ankündigung der allgemeinen Verfügbarkeit von Gastnachweisen für vertrauliche VMs).
Anwendungsfälle
Azure Attestation bietet umfassende Nachweisdienste für mehrere Umgebungen und unterschiedliche Anwendungsfälle.
AMD SEV-SNP-Nachweis auf vertraulichen VMs
Azure Confidential VM (CVM) basiert auf AMD-Prozessoren mit SEV-SNP-Technologie. CVM bietet die VM-Datenträgerverschlüsselungsoption für das Betriebssystem mit plattformverwalteten oder benutzerverwalteten Schlüsseln und bindet die Verschlüsselungsschlüssel an das TPM des virtuellen Computers. Wenn eine CVM gestartet wird, wird der SNP-Bericht mit den Firmwaremessungen der Gast-VM an Azure Attestation gesendet. Der Dienst überprüft die Messungen und gibt ein Nachweistoken aus, mit dem Schlüssel aus Managed-HSM oder Azure Key Vault freigegeben werden. Diese Schlüssel werden verwendet, um den vTPM-Zustand der Gast-VM zu entschlüsseln, den Betriebssystemdatenträger zu entsperren und die CVM zu starten. Der Nachweis- und Schlüsselfreigabeprozess wird automatisch bei jedem CVM-Start ausgeführt. Hierdurch wird sichergestellt, dass die CVM erst nach erfolgreichem Nachweis der Hardware gestartet wird.
AMD SEV-SNP-Nachweis auf vertraulichen Containern
Azure für vertrauliche Container basiert auf AMD-Prozessoren mit SEV-SNP-Technologie. Vertrauliche Container, die in Azure Container Instances und Azure Kubernetes Service (in der Vorschau) gehostet werden, bieten die Möglichkeit, Containergruppen in einer SEV-SNP-geschützten vertrauenswürdigen Ausführungsumgebung auszuführen, die diese Gruppe von Containern von der Containerverwaltungssteuerungsebene und anderen ausgeführten Containern isoliert. Der Nachweis in vertraulichen Containern umfasst das Abrufen des AMD-Hardwarenachweisberichts direkt vom Prozessor. Dies kann mit unserem SKR Sidecar-Container erreicht oder direkt in Ihrer Anwendungslogik kompiliert werden. Der Hardwarebericht kann dann mit Azure Attestation und managed-HSM oder Premium Azure Key Vault (AKV) ausgetauscht werden, um geheime Schlüssel abzurufen. Sie können den Hardwarebericht auch nach Bedarf für Ihr eigenes Schlüsseltresorsystem bereitstellen.
Nachweis des vertrauenswürdigen Starts
Azure-Kunden können Infektionen mit Bootkits und Rootkits verhindern, indem sie den vertrauenswürdigen Start für ihre VMs aktivieren. Wenn auf einer VM der sichere Start und vTPM mit installierter Gastnachweiserweiterung aktiviert sind, werden vTPM-Messungen regelmäßig an Azure Attestation gesendet, um die Startintegrität zu überwachen. Ein Nachweisfehler weist auf potenzielle Schadsoftware hin, die Kund*innen durch Microsoft Defender für Cloud über Warnungen und Empfehlungen übermittelt werden.
TPM-Nachweis
Eine auf TPM (Trusted Platform Module) basierende Zertifizierung ist entscheidend für den Nachweis des Zustands einer Plattform. Ein TPM fungiert als Vertrauensanker und Sicherheits-Coprozessor, um die kryptografische Gültigkeit der Messungen zu bestätigen (Beweis). Geräte mit einem TPM können sich auf den Nachweis verlassen, um zu beweisen, dass die Startintegrität nicht beeinträchtigt ist, und mithilfe der Ansprüche die Aktivierung des Featurezustands während des Starts zu erkennen.
Clientanwendungen können so entworfen werden, dass sie den TPM-Nachweis nutzen, indem sicherheitsrelevante Aufgaben delegiert und somit nur ausgeführt werden, nachdem die Sicherheit einer Plattform überprüft wurde. Solche Anwendungen können Azure Attestation nutzen, um routinemäßig eine Vertrauensstellung auf der Plattform herzustellen und auf sensible Daten zuzugreifen.
SGX-Enclave-Nachweis-URL
Intel® Software Guard Extensions (SGX) bietet Isolation für Hardware, die auf bestimmten Intel CPU-Modellen unterstützt wird. SGX ermöglicht das Ausführen von Code in bereinigten Depots, die als SGX-Enclaves bezeichnet werden. Zugriffs- und Speicherberechtigungen werden dann von der Hardware verwaltet, um eine minimale Angriffsfläche mit entsprechender Isolation zu gewährleisten.
Clientanwendungen können so entworfen werden, dass sie die Vorteile von SGX-Enclaves nutzen, indem sicherheitsrelevante Aufgaben in diese Enclaves delegiert werden. Solche Anwendungen können Azure Attestation nutzen, um routinemäßig eine Vertrauensstellung in der Enclave herzustellen und auf sensible Daten zuzugreifen.
Intel® Xeon® Scalable Processors unterstützen nur ECDSA-basierte Nachweislösungen für den Remotenachweis von SGX-Enklaven. Mithilfe des ECDSA-basierten Nachweismodells unterstützt Azure Attestation die Überprüfung von Intel® Xeon® E3-Prozessoren und auf Intel® Xeon® Scalable Processors basierenden Serverplattformen.
Hinweis
Zum Nachweis von auf Intel® Xeon® Scalable Processors basierenden Serverplattformen mithilfe von Azure Attestation wird von Benutzern erwartet, dass sie Azure DCAP-Version 1.10.0 oder höher installieren.
Open Enclave-Nachweis
Open Enclave (OE) ist eine Sammlung von Bibliotheken, die auf das Erstellen einer einzelnen vereinheitlichten Enclave-Abstraktion abzielen, damit Entwickler TEE-basierte Anwendungen erstellen können. Sie bietet ein universelles, sicheres App-Modell, das Plattformbesonderheiten minimiert. Für Microsoft ist sie eine Grundlage hin zur Demokratisierung hardwarebasierter Enclavetechnologien wie SGX und zur Steigerung der Akzeptanz in Azure.
OE standardisiert bestimmte Anforderungen für die Überprüfung eines Enclavenachweises. Das qualifiziert OE als einen passenden Nachweisconsumer von Azure Attestation.
Azure Attestation wird in einer TEE ausgeführt
Azure Attestation ist für vertrauliche Computing-Szenarien von entscheidender Bedeutung, da es die folgenden Aktionen durchführt:
- Überprüft, ob der Enclavenachweis gültig ist
- Wertet den Enclavenachweis anhand einer vom Kunden definierten Richtlinie aus
- Verwaltet und speichert mandantenspezifische Richtlinien
- Generiert und signiert ein Token, das von den vertrauenden Seiten verwendet wird, um mit der Enclave zu interagieren
Um Microsoft operativ aus der Trusted Computing Base (TCB) herauszuhalten, werden kritische Vorgänge von Azure Attestation wie Angebotsvalidierung, Token-Generierung, Richtlinienbewertung und Token-Signierung in eine SGX-Enklave verschoben.
Gründe für die Verwendung von Azure Attestation
Azure Attestation ist die bevorzugte Wahl für den Nachweis von TEEs, da es die folgenden Vorteile bietet:
- Einheitliches Framework für den Nachweis mehrerer Umgebungen (beispielsweise TPMs, SGC-Enclaves und VBS-Enclaves).
- Ermöglicht die Erstellung von benutzerdefinierten Nachweisanbietern und die Konfiguration von Richtlinien, um die Generierung von Token einzuschränken.
- Schützt seine Daten während der Verwendung mit der Implementierung in einer SGX-Enclave oder einer vertraulichen VM basierend auf AMD SEV-SNP.
- Hochverfügbarer Dienst
Einrichten einer Vertrauensstellung mit Azure Attestation
- Überprüfen Sie, ob das Nachweistoken von Azure Attestation generiert wird: Ein von Azure Attestation generiertes Nachweistoken wird mit einem selbstsignierten Zertifikat signiert. Die Signaturzertifikat-URL wird über einen OpenID-Metadatenendpunkt verfügbar gemacht. Die vertrauende Seite kann das Signaturzertifikat abrufen und die Signaturüberprüfung des Nachweistokens durchführen. Weitere Informationen finden Sie unter Codebeispielen.
- Überprüfen Sie, ob Azure Attestation in einer SGX-Enclave ausgeführt wird: Die Tokensignaturzertifikate enthalten ein SGX-Quote der TEE, in der Azure Attestation ausgeführt wird. Wenn die vertrauende Seite bevorzugt prüft, ob Azure Attestation in einer gültigen SGX-Enclave ausgeführt wird, kann das SGX-Quote aus dem Signaturzertifikat abgerufen und lokal überprüft werden. Weitere Informationen finden Sie unter Codebeispielen.
- Überprüfen Sie die Bindung des Azure Attestation-SGX-Quote mit dem Schlüssel, mit dem das Nachweistoken signiert wurde: Die vertrauende Seite kann überprüfen, ob der Hash des öffentlichen Schlüssels, mit dem das Nachweistoken signiert wurde, mit dem Berichtsdatenfeld des Azure Attestation-SGX-Quote übereinstimmt. Weitere Informationen finden Sie unter Codebeispielen.
- Überprüfen Sie, ob Azure Attestation-Codemessungen mit den von Azure veröffentlichten Werten übereinstimmen: Das SGX-Quote, das in Signaturzertifikate für Nachweistoken eingebettet ist, enthält Codemessungen von Azure Attestation, z. B. MRSIGNER. Wenn die vertrauende Seite überprüfen möchte, ob das SGX-Quote zu der in Azure ausgeführten Azure Attestation-Instanz gehört, kann der MRSIGNER-Wert aus dem SGX-Quote im Signaturzertifikat für Nachweistoken abgerufen und mit dem vom Azure Attestation-Team bereitgestellten Wert verglichen werden. Wenn Sie diese Überprüfung ausführen möchten, senden Sie eine Anfrage über die Azure-Supportseite. Das Azure Attestation-Team wird sich mit Ihnen in Verbindung setzen, wenn die Rotation von MRSIGNER geplant ist.
mrsigner von Azure Attestation wird sich voraussichtlich ändern, wenn Codesignaturzertifikate rotiert werden. Das Azure Attestation-Team hält sich bei jeder mrsigner-Rotation an den folgenden Rolloutzeitplan:
i. Das Azure Attestation-Team teilt den bevorstehenden MRSIGNER-Wert mit einer Karenzzeit von zwei Monaten mit, damit relevante Codeänderungen vorgenommen werden können
ii. Nach Ablauf der zweimonatigen Karenzzeit beginnt Azure Attestation mit der Verwendung des neuen MRSIGNER-Werts
iii. Drei Monate nach dem Mitteilungsdatum verwendet Azure Attestation den alten MRSIGNER-Wert nicht mehr
Unterstützung für Business Continuity & Disaster Recovery (BCDR)
Business Continuity & Disaster Recovery (BCDR) für Azure Attestation ermöglicht Ihnen das Verringern von Dienstunterbrechungen, die durch erhebliche Verfügbarkeitsproblemen oder Notfallereignisse in einer Region entstehen.
Cluster, die in zwei Regionen bereitgestellt werden, werden unter normalen Umständen unabhängig voneinander betrieben. Bei einem Fehler oder einem Ausfall einer Region geschieht Folgendes:
- Azure Attestation BCDR bietet ein nahtloses Failover, bei dem Kunden keine zusätzlichen Schritte zur Wiederherstellung ausführen müssen.
- Die Azure Traffic Manager-Instanz für die Region erkennt, dass der Integritätstest beeinträchtigt wird, und schaltet den Endpunkt in eine gekoppelte Region um.
- Vorhandene Verbindungen können nicht verwendet werden, und interne Serverfehler oder Timeoutprobleme werden empfangen.
- Alle Vorgänge auf Steuerungsebene werden blockiert. Kunden können keine Nachweisanbieter in der primären Region erstellen.
- Alle Vorgänge auf Datenebene, einschließlich der Nachweisaufrufe und der Richtlinienkonfiguration, werden von der sekundären Region behandelt. Kunden können Vorgänge auf Datenebene weiterhin ausführen. Der ursprüngliche URI entspricht dabei der primären Region.