Microsoft Azure-Nachweis

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 Plattformen, die von Trusted Platform Modules (TPMs) unterstützt werden, zusammen mit der Möglichkeit, den Status von Trusted Execution Environments (TEEs) wie Intel® Software Guard Extensions (SGX)-Enklaven, Virtualisierungsbasierte Sicherheit (VBS) Enklaven, Trusted Platform Modules (TPMs), Vertrauenswürdiger Start für Azure VMs und Azure vertraulichen VMs zu bestätigen.

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 den 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 auf Azure Container Instances und auf Azure Kubernetes Service (in der Vorschau) gehostet werden, bieten die Möglichkeit, Gruppen von Containern in einer SEV-SNP geschützten vertrauenswürdigen Ausführungsumgebung auszuführen, die diese Gruppe von Containern aus der Containerverwaltungssteuerungsebene und anderen ausgeführten Containern isoliert. Der Nachweis in vertraulichen Containern umfasst das Abrufen des AMD-Hardwarenachweisberichts direkt vom Prozessor. Sie können diese Aufgabe mit dem SKR-Sidecar-Container erledigen oder direkt in Ihre Anwendungslogik kompilieren. Der Hardwarebericht kann dann mit Azure Attestation und verwalteten 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.

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 die Quote-Validierung, Tokengenerierung, Richtlinienauswertung und Tokensignierung in vertrauliche Container auf Basis von AMD SEV-SNP verlagert.

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 zum Nachweis mehrerer Umgebungen wie TPMs, SGX-Enklaven und VBS-Enklaven.
• 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 Nutzung durch die Implementierung in einer TEE.
• Hoch verfügbarer Service.

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 unter Codebeispiele.
2. Überprüfen Sie, ob Azure Attestation in einem SEV-SNP-Container ausgeführt wird – Die Tokensignaturzertifikate enthalten Informationen zum TEE, in dem Azure Attestation ausgeführt wird. Bei diesem TEE-Begleitmaterial handelt es sich um einen SEV-SNP-Bericht. Die vertrauende Seite kann überprüfen, ob Azure Attestation in einem gültigen TEE ausgeführt wird, indem der Bericht lokal überprüft wird. Codebeispiele finden Sie unter SEV-SNP.
3. Überprüfen Sie die Bindung 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 im Codebeispiel.
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 überprüfen, ob der Bericht von Azure Attestation stammt, indem sie bestimmte Werte, die aus dem TEE-Collateral im Signaturzertifikat des Nachweistokens abgerufen wurden, mit den vom Azure Attestation-Team bereitgestellten Werten vergleicht. Bei SEV-SNP sollte HOST_DATA validiert werden. Weitere Informationen finden Sie im Codebeispiel. Wenn Sie an dieser Überprüfung interessiert sind, senden Sie eine Anforderung auf der Azure-Support-Seite. Das Azure Attestation-Team wendet sich an Sie, wenn diese spezifischen Werte zur Rotation geplant sind.
5. Schaffen Sie Vertrauen in die Build-Herkunft - Azure Attestation ist in Microsofts Signing Transparency (MST) integriert. MST zeichnet Codesignaturen in einem unveränderlichen, manipulationssicheren Register auf. Der MST-Dienst liefert kryptografisch überprüfbare, SCITT-konforme Bestätigungen, die klare Einblicke in die Bereitstellungen Azure Attestation bieten – stärkung von Vertrauen, Auditierbarkeit und Einhaltung gesetzlicher Vorschriften. Weitere Informationen zu MST und zum Validieren von Buildartefakten finden Sie unter Informationen zum Microsoft Signing Transparency-Ledger.

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

1. Das Azure Attestation Team benachrichtigt Verbraucher über die neuen Werte mit einer zweimonatigen Nachfrist, um relevante Codeänderungen zu implementieren.
2. Nach Ablauf der zweimonatigen Karenzzeit beginnt Azure Attestation mit der Verwendung der neuen Werte.
3. 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 Geschäftskontinuität und Notfallwiederherstellung (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 die gekoppelte Region um.
• Vorhandene Verbindungen funktionieren nicht und erhalten interne Serverfehler oder Timeoutprobleme.
• Alle Vorgänge auf Steuerungsebene sind blockiert. Kunden können in der primären Region keine Nachweisanbieter erstellen.
• Alle Vorgänge auf der Datenebene, einschließlich Nachweisanrufe und Richtlinienkonfiguration, werden von der sekundären Region bereitgestellt. Kunden können weiterhin an Datenebenenvorgängen mit dem ursprünglichen URI arbeiten, der der primären Region entspricht.

Nächste Schritte

• Erfahren Sie mehr über die Grundkonzepte von Azure Attestation.
• So erstellen und signieren Sie eine Attestierungsrichtlinie
• Richten Sie Azure Attestation mithilfe von PowerShell ein.