Freigeben über

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. Entfernte vertrauende Parteien können sich dann sicher sein, dass nur die beabsichtigte Software auf vertrauenswürdiger Hardware läuft. 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. Der Dienst erhält Nachweise von Computeentitäten, wandelt sie in eine Reihe von Ansprüchen um, überprüft sie anhand konfigurierbarer Richtlinien und erzeugt kryptografische Nachweise für anspruchsbasierte Anwendungen (z. B. vertrauende Parteien und Prüfstellen).

Azure Attestation unterstützt sowohl die Plattform- als auch die Gastattestierung von auf AMD SEV-SNP basierenden 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 ein CVM gestartet wird, wird ein SNP-Bericht mit den Firmware-Messungen der Gastvirtuellen Maschine 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 Confidential Containers 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 nach Bedarf auch 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. Eine Attestierungsfehlfunktion weist auf potenzielle Schadsoftware hin, die Kund*innen durch Microsoft Defender für Cloud über Warnungen und Empfehlungen angezeigt wird.

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 nachzuprüfen, dass die Startintegrität nicht beeinträchtigt ist, und mithilfe der Feststellungen 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-Enklavenachweis

Intel® Software Guard Extensions (SGX) bezieht sich auf hardwarebasierte Isolation, die bei 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 spezifische Anforderungen für die Überprüfung eines Enklavenachweises. Das qualifiziert OE als einen sehr geeigneten Nutzer 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 Enclave-Nachweis gültig ist.
  • Wertet den Enklavenachweis 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

So bauen Sie Vertrauen mit Azure Attestation auf

  1. Ü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. Eine vertrauende Seite kann das Signaturzertifikat abrufen und die Signaturüberprüfung des Nachweistokens durchführen. Weitere Informationen finden Sie in Codebeispielen .
  2. Überprüfen Sie, ob der Azure-Nachweis innerhalb eines SGX-Enklaven- oder SEV-SNP-Containers ausgeführt wird – Die Tokensignaturzertifikate enthalten Informationen über den TEE, in dem der Azure-Nachweis ausgeführt wird. Dieses TEE-Begleitmaterial kann ein SGX-Angebot oder ein SEV-SNP-Bericht sein. Die vertrauende Seite kann überprüfen, ob Azure Attestation in einer gültigen TEE ausgeführt wird, indem das Angebot oder der Bericht lokal geprüft wird. Weitere Informationen finden Sie unter Codebeispiele – SGX, SEV-SNP
  3. Überprüfen Sie die Bindung des Azure Attestation TEE-Berichts mit dem Schlüssel, der das Nachweistoken signiert hat– Die vertrauende Seite kann überprüfen, ob der Hash des öffentlichen Schlüssels, der das Nachweistoken signiert hat, mit dem Berichtsdatenfeld des Azure Attestation TEE-Berichts übereinstimmt. Weitere Informationen finden Sie hier .
  4. Überprüfen, ob Azure Attestation-Codemessungen mit den veröffentlichten Azure-Werten übereinstimmen – Die in den Zertifikatsignaturzertifikaten des Nachweistokens eingebetteten TEE-Codemessungen umfassen TEE-Codemessungen des Azure-Nachweises. Eine vertrauende Partei kann validieren, dass das Angebot oder der Bericht zu Azure Attestation gehört, indem sie konkrete Werte, die aus dem TEE-Begleitmaterial im Tokensignaturzertifikat des Nachweises abgerufen werden, mit den vom Azure Attestation-Team bereitgestellten Werten vergleicht. Für SGX sollte MRSIGNER überprüft werden. Bei SEV-SNP sollte HOST_DATA validiert werden. Weitere Informationen finden Sie hier . Wenn Sie an dieser Überprüfung interessiert sind, senden Sie eine Anforderung auf der Azure-Supportseite. Das Azure Attestation-Team wendet sich an Sie, wenn diese spezifischen Werte zur Rotation geplant sind.

Die Werte, die gültige Azure-Nachweisinstanzen identifizieren, werden voraussichtlich geändert, wenn Codesignaturzertifikate gedreht werden oder wenn Sicherheitsupdates neue Richtlinienversionen erfordern. Das Azure Attestation-Team hält sich bei jeder geplanten Rotation an den folgenden Rolloutzeitplan:

i. Das Azure Attestation-Team benachrichtigt Verbraucher über die neuen Werte mit einer zweimonatigen Nachfrist, um relevante Codeänderungen zu implementieren.

ii. Nach Ablauf der zweimonatigen Karenzzeit beginnt Azure Attestation mit der Verwendung der neuen Werte.

iii. Drei Monate nach dem Benachrichtigungsdatum beendet der Azure-Nachweis die Verwendung der alten Werte.

Bei ungeplanten Rotationen, darunter diejenigen, die durch Sicherheitsupdates erforderlich werden, teilt das Azure Attestation-Team neue Werte mit einer einmonatigen Toleranzperiode mit.

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.
  • Der Azure Traffic Manager für die Region erkennt, dass der Integritätstest beeinträchtigt ist, 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 der Steuerungsebene werden blockiert. Kunden können in der primären Region keine Nachweisanbieter erstellen.
  • Alle Vorgänge auf Datenebene, darunter die Nachweisaufrufe und die 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.

Nächste Schritte