FAQ zu Confidential Virtual Machines in Azure

Vertrauliche VMs sind eine IaaS-Lösung für Mandanten mit hohen Sicherheits- und Vertraulichkeitsanforderungen. Vertrauliche VMs bieten:

• Verschlüsselung für „Daten in Gebrauch“, einschließlich des Prozessorstatus und des Arbeitsspeichers des VMs. Die Schlüssel werden vom Prozessor generiert und verlassen ihn niemals.
• Die Hostattestierung unterstützt Sie dabei, den vollständigen Zustand und die Konformität des Servers zu überprüfen, bevor die Datenverarbeitung beginnt.
• Ein Hardwaresicherheitsmodul (HSM) kann angefügt werden, um die Schlüssel der vertraulichen VM-Laufwerke zu schützen, die der Mandant ausschließlich besitzt.
• Neue UEFI-Startarchitektur, die das Gastbetriebssystem unterstützt, um die Sicherheitseinstellungen und -funktionen zu verbessern.
• Ein dediziertes virtuelles Trusted Platform Module (TPM) zertifiziert die Integrität der VM, stellt eine verstärkte Schlüsselverwaltung bereit und unterstützt Anwendungsfälle wie BitLocker.

Confidential-VMs gehen auf Kundenbedenken beim Verschieben vertraulicher Workloads aus der lokalen Umgebung in die Cloud ein. Vertrauliche VMs bieten einen erhöhten Schutz für Kundendaten aus der zugrunde liegenden Infrastruktur und den Cloudbetreibern. Im Gegensatz zu anderen Ansätzen und Lösungen müssen Sie Ihre vorhandenen Workloads nicht an die technischen Anforderungen der Plattform anpassen.

SEV-SNP steht für „Secure Encrypted Virtualization-Secure Nested Paging“. Dabei handelt es sich um eine Trusted Execution Environment-Technologie (TEE), die von AMD bereitgestellt wird und mehrere Schutzmaßnahmen bietet, z. B. Speicherverschlüsselung, eindeutige CPU-Schlüssel, Verschlüsselung für den Prozessorregisterstatus, Integritätsschutz, Verhinderung von Firmware-Rollbacks, Seitenkanalabsicherung und Einschränkungen beim Interrupt- und Ausnahmeverhalten. Insgesamt sichern die AMD SEV-Technologien den Gastschutz, um dem Hypervisor und anderen Host-Management-Codes den Zugriff auf VM-Speicher und -Status zu verweigern. Vertrauliche VMs nutzen AMD SEV-SNP mit Azure-Technologien wie der vollständigen Datenträgerverschlüsselung (Full Disk Encryption) und Azure Key Vault Managed HSM. Sie können Daten während der Nutzung, während der Übertragung und im Ruhezustand mit von Ihnen gesteuerten Schlüsseln verschlüsseln. Mit integrierter Azure Attestation können Sie unabhängig voneinander Vertrauen in die Sicherheit, Integrität und die zugrunde liegende Infrastruktur Ihrer vertraulichen VMs aufbauen.

Intel TDX steht für Intel Trust Domain Extensions (Intel TDX). Dabei handelt es sich um eine Trusted Execution Environment-Technologie (TEE) von Intel, die mehrere Schutzmaßnahmen bietet: Intel TDX verwendet Hardwareerweiterungen zum Verwalten und Verschlüsseln des Speichers und schützt sowohl die Vertraulichkeit als auch die Integrität des CPU-Zustands. Darüber hinaus trägt Intel TDX zur Verstärkung der Sicherheit der virtualisierten Umgebung bei, indem es dem Hypervisor, anderem Hostverwaltungscode und Administratoren den Zugriff auf den VM-Speicher und -Zustand verweigert. Vertrauliche VMs kombinieren Intel TDX mit Azure-Technologien wie der vollständigen Datenträgerverschlüsselung (Full-Disk Encryption) und Azure Key Vault Managed HSM. Sie können Daten während der Nutzung, während der Übertragung und im Ruhezustand mit von Ihnen gesteuerten Schlüsseln verschlüsseln.

Azure-VMs bieten bereits branchenweit führende Sicherheit und Schutz vor anderen Mandanten und böswilligen Eindringlingen. Vertrauliche Azure-VMs erweitern diese Schutzfunktionen mithilfe von hardwarebasierten TEEs wie SEV-SNP von AMD und Intel TDX, um die Vertraulichkeit und Integrität Ihrer Daten kryptografisch zu isolieren und zu schützen. Kein Hostadministrator oder -dienst (einschließlich des Azure-Hypervisors) kann den Arbeitsspeicher oder den CPU-Status Ihrer vertraulichen VM direkt anzeigen oder ändern. Darüber hinaus ist der persistente Statusdank der vollständigen Nachweisfunktion, der Verschlüsselung des gesamten Betriebssystemdatenträgers und der hardwareseitig geschützten virtuellen TPMs so geschützt, dass Ihre privaten Schlüssel und der Inhalt Ihres Arbeitsspeichers nicht unverschlüsselt für die Hostingumgebung sichtbar sind.

Derzeit können Betriebssystemdatenträger für vertrauliche VMs verschlüsselt und gesichert werden. Für zusätzliche Sicherheit können Sie die Verschlüsselung auf Gastebene (z. B. BitLocker oder dm-crypt) für alle Datenlaufwerke aktivieren.

Ja, aber nur, wenn sich die Datei „pagefile.sys“ auf dem verschlüsselten Betriebssystemdatenträger befindet. Auf vertraulichen VMs mit einem temporären Datenträger kann die pagefile.sys-Datei auf das verschlüsselte Betriebssystemlaufwerk verschoben werden. Tipps zum Verschieben von pagefile.sys auf das Laufwerk C:\.

Nein, diese Funktion existiert für vertrauliche VMs nicht.

Hier sind einige Möglichkeiten, wie Sie einen vertraulichen virtuellen Computer bereitstellen können:

• Bereitstellen über das Azure-Portal
• Bereitstellen über die Azure-Befehlszeilenschnittstelle (Azure-CLI)
• Bereitstellen mit einer ARM-Vorlage
• Bereitstellen mithilfe von VMSS und vertraulicher Datenträgerverschlüsselung

Azure Confidential VMs auf AMD SEV-SNP werden im Rahmen ihrer Startphase attestiert. Dieser Prozess ist für den Benutzer nicht transparent und wird im Cloudbetriebssystem mithilfe des Microsoft Azure Attestation- und Azure Key Vault-Dienstes durchgeführt. Vertrauliche VMs ermöglichen Benutzern außerdem die Durchführung von unabhängigen Attestierungen für vertrauliche VMs. Dieser Nachweis erfolgt mithilfe eines neuen Tools namens Azure confidential VM Guest Attestation. Mithilfe der Gastattestierung können Kunden nachweisen, dass ihre vertraulichen VMs auf AMD-Prozessoren ausgeführt werden und dass SEV-SNP aktiviert ist.

Vertrauliche Azure-VMs, die auf Intel TDX zurückgreifen, können als Teil des Startflusses transparent attestiert werden, sodass sichergestellt werden kann, dass die Plattform konform und auf dem neuesten Stand ist. Der Prozess ist für den Benutzer nicht transparent und erfolgt mithilfe von Microsoft Azure Attestation und Azure Key Vault. Wenn Sie auch nach dem Booten Überprüfungen vornehmen möchten, steht Ihnen die Plattformattestierung im Gast zur Verfügung. Auf diese Weise können Sie überprüfen, ob Ihre VM auf echtem Intel TDX ausgeführt wird. Um auf diese Funktion zuzugreifen, besuchen Sie unseren Preview-Branch. Darüber hinaus unterstützen wir Intel® Trust Authority für Unternehmen, die eine betreiberunabhängige Attestierung wünschen. Die Unterstützung für eine vollständige In-Guest-Attestierung, ähnlich wie AMD SEV-SNP, wird in Kürze verfügbar sein. Auf diese Weise können Organisationen tiefer einsteigen und weitere Aspekte, sogar bis auf die Ebene der Gastanwendung, überprüfen.

Für die Ausführung auf einer Confidential VM müssen Betriebssystem-Images bestimmte Sicherheits- und Kompatibilitätsanforderungen erfüllen. Dies ermöglicht es, vertrauliche VMs sicher einzubinden, zu attestieren und von der zugrunde liegenden Cloud-Infrastruktur zu isolieren. In Zukunft möchten wir Anleitungen dazu bereitstellen, wie Sie einen benutzerdefinierten Linux-Build verwenden und eine Reihe von Open-Source-Patches anwenden, um ihn als vertrauliches VM-Image zu qualifizieren.

Ja. Sie können Azure Compute Gallery verwenden, um ein Image für vertrauliche VMs zu ändern, z. B. durch Installieren von Anwendungen. Anschließend können Sie vertrauliche VMs basierend auf Ihrem geänderten Image bereitstellen.

Das optionale Full-Disk-Verschlüsselungsschema ist das sicherste von Azure und erfüllt die Confidential Computing-Prinzipien. Sie können jedoch auch andere Datenträgerverschlüsselungsschemas zusammen mit oder anstelle der vollständigen Datenträgerverschlüsselung verwenden. Wenn Sie mehrere Datenträgerverschlüsselungsschemas verwenden, kann sich die doppelte Verschlüsselung negativ auf die Leistung auswirken.

Jede Azure Confidential VM verfügt über ein eigenes virtuelles TPM, in dem Kunden ihre Geheimnisse/Schlüssel versiegeln können. Es wird empfohlen, dass Kunden den vTPM-Status (für Windows-VMs über TPM.msc) überprüfen. Wenn der Status nicht einsatzbereit ist, empfehlen wir Ihnen, Ihre VMs neu zu starten, bevor Sie Geheimnisse/Schlüssel für vTPM versiegeln.

Nr. Nachdem Sie einen vertraulichen virtuellen Computer erstellt haben, können Sie die Verschlüsselung auf vollständigem Datenträger nicht mehr deaktivieren oder erneut aktivieren. Erstellen Sie stattdessen eine neue vertrauliche VM.

Nein, die Auswahl der Schlüsselverwaltung (plattformverwaltet oder kundenseitig verwaltet) ist nur während der VM-Erstellung möglich und kann danach nicht mehr geändert werden.

Nein, wenn eine vertrauliche VM ohne vollständige Datenträgerverschlüsselung des Betriebssystemdatenträgers erstellt wird, kann kein kundenseitig verwalteter Schlüssel verwendet werden. In diesem Fall wird der VMGS-Datenträger, der immer verschlüsselt ist, mit einem plattformverwalteten Schlüssel (Platform Managed Key, PMK) verschlüsselt.

Fachkräfte in der Entwicklung, die eine weitergehende „Aufgabentrennung“ für TCB-Dienste vom Clouddienstanbieter möchten, sollten den Sicherheitstyp „NonPersistedTPM“ verwenden.

• Diese Erfahrung ist nur als Teil der öffentlichen Vorschau für Intel TDX verfügbar. Organisationen, die sie verwenden oder damit Dienste anbieten, haben die Kontrolle über das TCB und die damit verbundenen Verantwortlichkeiten.
• Diese Funktion umgeht die nativen Azure-Dienste, sodass Sie eine eigene Datenträgerverschlüsselung, Schlüsselverwaltung und Attestierungslösung bereitstellen können.
• Jede VM verfügt immer noch über ein vTPM, das zum Abrufen von Hardwarenachweisen verwendet werden sollte. Der vTPM-Zustand wird jedoch nicht über Neustarts hinweg beibehalten, sodass sich diese Lösung hervorragend für kurzlebige Workloads und Organisationen eignet, die eine weitergehende Entkoppelung vom Clouddienstanbieter anstreben.

Nr. Aus Sicherheitsgründen müssen Sie von Anfang an eine vertrauliche VM als solche erstellen.

Ja, das Konvertieren von einer vertraulichen VM in eine andere vertrauliche VM ist sowohl auf DCasv5/ECasv5 als auch auf DCesv5/ECesv5 in den gemeinsamen Regionen zulässig. Wenn Sie ein Windows-Image verwenden, stellen Sie sicher, dass Sie über alle neuesten Updates verfügen. Wenn Sie ein Ubuntu Linux-Image verwenden, stellen Sie sicher, dass Sie das vertrauliche Ubuntu 22.04 LTS-Image mit der minimalen Kernelversion 6.2.0-1011-azure verwenden.

Stellen Sie sicher, dass Sie eine verfügbare Region für vertrauliche VMs ausgewählt haben. Stellen Sie außerdem sicher, dass Sie in der Größenauswahl Alle Filter löschen ausgewählt haben.

Nr. Vertrauliche VMs unterstützen Accelerated Networking nicht. Sie können den beschleunigten Netzwerkbetrieb nicht für eine vertrauliche VM-Bereitstellung oder eine Azure Kubernetes Service Clusterbereitstellung aktivieren, die unter Confidential Computing ausgeführt wird.

Sie erhalten möglicherweise den Fehler Der Vorgang konnte nicht abgeschlossen werden, weil er zu einer Überschreitung des genehmigten Kontingents für Kerne der Standard DCasv5/ECasv5-Familie führt. Dieser Fehler in der Azure Resource Manager-Vorlage (ARM-Vorlage) bedeutet, dass die Bereitstellung aufgrund fehlender Azure-Computekerne fehlgeschlagen ist. Kostenlose Azure-Testabonnements verfügen nicht über ein ausreichend großes Kernkontingent für vertrauliche VMs. Erstellen Sie eine Supportanfrage zur Erhöhung Ihres Kontingents.

Bei der ECasv5-Serie und der ECesv5-Serie handelt es sich um speicheroptimierte VM-Größen, die ein höheres Arbeitsspeicher-zu-CPU-Verhältnis bieten. Diese Größen eignen sich besonders gut für relationale Datenbankserver, mittlere bis große Caches und In-Memory-Analysen.

Nein. Diese virtuellen Computer sind zurzeit nur in ausgewählten Regionen verfügbar. Eine aktuelle Liste der verfügbaren Regionen finden Sie unter VM-Produkte nach Region.

Azure bietet keine Betriebsverfahren zum Gewähren von vertraulichem VM-Zugriff für seine Mitarbeiter, auch wenn ein Kunde den Zugriff autorisiert. Daher sind verschiedene Wiederherstellungs- und Supportszenarien für vertrauliche VMs nicht verfügbar.

Nein, vertrauliche VMs unterstützen derzeit keine geschachtelte Virtualisierung, z. B. die Möglichkeit, einen Hypervisor innerhalb einer VM auszuführen.

Die Abrechnung für vertrauliche VMs hängt von Ihrer Nutzung und Ihrem Speicher sowie von der Größe und Region des virtuellen Computers ab. Vertrauliche VMs verwenden einen kleinen verschlüsselten VMGS-Datenträger (Virtual Machine Guest State), der mehrere Megabyte groß ist. VMGS umfasst den VM-Sicherheitsstatus von Komponenten wie vTPM und UEFI-Bootloader. Dieser Datenträger kann zu einer monatlichen Speichergebühr führen. Wenn Sie sich für die optionale Verschlüsselung des gesamten Datenträgers entscheiden, fallen für verschlüsselte Betriebssystem-Datenträger höhere Kosten an. Weitere Informationen zu Speichergebühren finden Sie im Preisleitfaden für verwaltete Datenträger. Schließlich können Sie für einige Einstellungen für hohe Sicherheit und Datenschutz verknüpfte Ressourcen erstellen, z. B. einen Managed HSM Pool. Azure berechnet solche Ressourcen getrennt von den Kosten für vertrauliche VMs.

Selten können einige Ubuntu Linux-VMs der DCesv6/ECesv6-Serie eine geringe Zeitabweichung gegenüber UTC aufweisen. Ein langfristiger Fix ist in Kürze verfügbar. In der Zwischenzeit sind hier die Problemumgehungen:

Führen Sie für Ubuntu Linux-Images die folgenden Schritte aus:

1. Führen Sie diesen Befehl aus, um die chronyd-Datei zu aktualisieren, um die Verwendung des IC-Zeitsynchronisierungsdiensts zu deaktivieren.

sed -i '/^refclock PHC \/dev\/ptp_hyperv poll 3 dpoll -2 offset 0/s/^/#/' /etc/chrony/chrony.conf

2. Aktivieren Sie stattdessen für die Linux-VM die Verwendung von Network Time Protocol (NTP).

sed -i '/^#pool.*ntp/s/^#//' /etc/chrony/chrony.conf

3. Starten Sie den chronyd-Dienst neu, um mit der aktuellen Zeit zu synchronisieren.

systemctl restart chronyd.service

Nr. Die Azure-Plattform-Metriken Available Memory Percentage und Available Memory Bytes geben für vertrauliche VM-Instanzen null an. Dieses Verhalten ist eine erwartete Plattformbeschränkung, daher können diese Metriken nicht als Autoskalierungssignale für vertrauliche VM-Knotentypen verwendet werden. Nutze stattdessen CPU-basierte Autoscale-Regeln.