Best Practices für die Sicherheit von VMware Engine

Dieses Dokument beschreibt die empfohlenen Best Practices für die Sicherheit bei der Verwaltung und Konfiguration der Google Cloud VMware Engine. Es richtet sich an Nutzer, die bereits mit der VMware Engine vertraut sind. Wenn Sie Anfänger sind, sollten Sie sich zuerst mit den Voraussetzungen und der Sicherheit der VMware Engine vertraut machen.

VMware Engine hat ein Modell der geteilten Verantwortung für die Sicherheit. Vertrauenswürdige Sicherheit in der Cloud wird durch die gemeinsamen Verantwortlichkeiten von Kunden und Google als Dienstanbieter erzielt. Wenn Sie diese Best Practices befolgen, können Sie Zeit sparen, Fehler vermeiden und die Auswirkungen von Fehlerquellen mindern.

VMware Engine-Netzwerk

In den folgenden Abschnitten werden Best Practices für das Netzwerk in einer VMware Engine-Umgebung vorgestellt.

Alle Trafficflüsse in Ihrer Umgebung identifizieren und verstehen

VMware Engine nutzt VMware Engine-Netzwerke und VPC-Peering, um eine private Netzwerkverbindung von einem VMware Engine-Private-Cloud-Netzwerk mit Ihrem VPC-Netzwerk herzustellen. Eingehender Traffic von einem VPC in IhrerGoogle Cloud -Umgebung oder von einem lokalen Netzwerk durchläuft ein von Google verwaltetes Netzwerk der Mieteinheit.

Öffentlichen IP-Dienst von VMware Engine für die Internetdatenübertragung verwenden

Internet-Traffic kann über den öffentlichen IP-Dienst von VMware Engine direkt in eine private Cloud gelangen. Alternativ kann der Internetverkehr über einen öffentlichen Load Balancer in Google Cloudeintreten. In diesem Fall wird der Traffic wie jeder andere eingehende Traffic weitergeleitet. Diese Optionen schließen sich gegenseitig aus. Wenn für den Internetverkehr benutzerdefinierte Steuerelemente erforderlich sind, z. B. URL-Filterung, IPS/IDS oder Traffic-Inspection, die von einer zentralen Instanz oder einem Dienst in Ihrer Google Cloud -Umgebung bereitgestellt werden, sollten Sie Internet-Traffic über das VPC-Netzwerk leiten.

Wenn dies nicht auf Sie zutrifft oder Sie die Einstellungen in Ihrer privaten Cloud implementiert haben, empfehlen wir Ihnen, den Dienst für externe IP-Adressen in VMware Engine einzubinden. Außerdem empfehlen wir die Verwendung von Regeln für den externen Zugriff, um Traffic-Muster aus dem Internet abzulehnen, die nicht für Ihre Anwendungen gelten.

Separate Nord-Süd- und Ost-West-Firewallregeln für Gateway und verteilte Firewall in VMware Engine NSX-T

Konfigurieren Sie die Distributed Firewall (DFW) in NSX-T auf dem logischen Tier-1-Router, um den internen Traffic zwischen Ihren virtuellen Layer 2-Domains zu segmentieren. Die NSX-DFW ist für die Verarbeitung von (internem) East-West-Netzwerkverkehr zwischen Segmenten konzipiert und ermöglicht Firewallregeln, die den Traffic zwischen einzelnen Instanzen innerhalb eines Segments zulassen oder ablehnen.

Für eine detaillierte Netzwerkzugriffssteuerung müssen Sie eine eingeschränkte Standardrichtlinie auf die DFW anwenden, um den Netzwerkverkehr zwischen Instanzen standardmäßig zu verweigern. Verwenden Sie die DFW, um den Traffic zwischen Anwendungen und Diensten innerhalb Ihrer Anwendung speziell zuzulassen.

Konfigurieren Sie die NSX-Gateway-Firewall, um den Nord-Süd-Traffic zu steuern, der die private Cloud betritt und verlässt.

Die NSX-Gateway-Firewall wurde für die Steuerung von Nord-Süd-Traffic entwickelt und wird für Anwendungsfälle wie die Steuerung des Traffics an einem Perimeter zu einer anderen Sicherheitszone empfohlen. Wenn Sie den Nord-Süd-Traffic für die gesamte private Cloud einheitlich konfigurieren möchten, konfigurieren Sie die Gateway-Firewall auf dem Tier-0-Router. Wenn Sie den Nord-Süd-Traffic für jedes einzelne NSX-T-Segment konfigurieren müssen, konfigurieren Sie die Gateway-Firewall auf dem Tier-1-Router.

Zusätzlich zu NSX-T-Firewalls wird empfohlen, die VPC-Firewall zu verwenden, um East-West-Traffic zwischen Arbeitslasten in der privaten VMware Engine-Cloud und Arbeitslasten in VPCs zuzulassen und zu blockieren. Die eingehende Datenübertragung an Compute Engine-Instanzen von VMware Engine-Arbeitslasten sollte standardmäßig auf bewusst geöffneten Traffic beschränkt sein.

Die ausgehende Datenübertragung an Verwaltungsgeräte sowie an den vSphere/vSAN-CIDR-Bereich sollte auch über die VPC-Firewall blockiert werden. Erlauben Sie die ausgehende Datenübertragung an Management-Appliances nur von vertrauenswürdigen Hosts und IP-Adressen innerhalb Ihres Netzwerks. Beachten Sie, dass sich Verwaltungs-Appliances nicht in einem NSX-T-Segment befinden. Daher gelten keine DFW-Regeln, um den Zugriff einzuschränken.

Zero-Trust-Sicherheitsgrundsätze und Mikrosegmentierung in NSX-T anwenden

Mit der NSX-T DFW können Sie Traffic-Kontrollen für Sicherheitssegmente implementieren, die so detailliert sind wie für einzelne virtuelle Maschinen. Dieses Prinzip zum Schutz des Traffics zwischen einzelnen VMs, der standardmäßig abgelehnt wird, wird oft auch als „Mikrosegmentierung“ bezeichnet. Dies ist ein detaillierterer Ansatz für die Firewall als die herkömmliche Implementierung von Firewalls zwischen Layer-3-Domains.

Die DFW ist im Hypervisor-Kernel auf allen VMware Engine-vSphere-Hosts in Ihrer privaten Cloud aktiviert und kann den Trafficfluss zwischen Arbeitslasten steuern, die sich entweder im selben oder in separaten NSX-Segmenten befinden. Firewallregeln, die den Traffic zu und von VMs zulassen, können definiert werden, indem die VMs in Richtliniengruppen organisiert werden. Diese können flexible Mitgliedschaftskriterien wie VM-Tag oder Namensabgleich haben.

Mit der Mikrosegmentierung können Sie ein Netzwerk mit einer detaillierten Traffic-Steuerung implementieren, bei der ein Traffic-Muster ausdrücklich zugelassen werden muss. Das Sicherheitskonzept, bei dem alle Netzwerkflüsse durch Identitäts- und Geräteüberprüfungsprozesse und nicht durch implizites Vertrauen gesteuert werden, wird oft auch als Zero-Trust-Sicherheit bezeichnet.

Firewall-Appliance eines Drittanbieters über das Cloud Marketplace-Portal für IPS-/IDS-Funktionen bereitstellen

Wenn Sie erweiterte Layer 7-Sicherheit benötigen, einschließlich IDS-/IPS-Funktionen für eingehenden Traffic in die Private Cloud aus dem Rest Ihres Netzwerks oder zwischen Ihren NSX-T-Netzwerksegmenten, sollten Sie eine Firewall-Appliance eines Drittanbieters bereitstellen. Die Appliance des Drittanbieters kann entweder als Multi-NIC-Appliance zwischen zwei VPCs in Ihrem Google Cloud -Netzwerk oder innerhalb der privaten Cloud mit einer Integration in NSX-T bereitgestellt werden.

Eine detaillierte Übersicht über VMware Engine-Architekturen mit zentralen Appliances, die für eine Vielzahl von erweiterten Sicherheitsanwendungsfällen wie IPS/IDS, DDoS und SSL-Offloading verwendet werden können, finden Sie im Cloud Architecture Center im Dokument „Netzwerksicherheit unter Verwendung von zentralen Appliances“.

Webdienste in der VMware Engine mit Google Cloud Armor vor DDoS-Angriffen schützen

Wenn Sie eingehenden Traffic an Arbeitslasten in VMware Engine über das VPC des Kunden weiterleiten, empfehlen wir, VMware Engine-Arbeitslasten in Hybrid-Netzwerkendpunktgruppen hinter Cloud Service Mesh zu platzieren und den externen HTTP(S)-Load Balancer zu verwenden. Bei beiden Konfigurationen können Sie Google Cloud Armor für öffentlich zugängliche Anwendungen verwenden, um DDoS-Angriffe und gängige Sicherheitslücken wie SQL-Injections oder Cross-Site-Scripting abzuwehren.

Wenn Sie Service Mesh-Funktionen wie eine erweiterte Traffic-Verwaltung mit dem Envoy-Proxy oder die Integration des Certificate Authority Service benötigen, empfehlen wir Cloud Service Mesh. In allen anderen Fällen empfehlen wir den externen HTTP(S)-Load Balancer.

Folgen Sie der Dokumentation, um VMware Engine-Arbeitslasten in einer der folgenden Konfigurationen zu Hybrid-NEGs hinzuzufügen:

• Regionale externe HTTP(S)-Lastverteilung mit Hybridkonnektivität
• Globaler externer HTTP(S)-Load Balancer mit Hybridkonnektivität

Private Verbindung zu Google Cloud Diensten ohne Internetzugriff

Arbeitslasten in privaten VMware Engine-Clouds können über den privater Google-Zugriff auf Google Cloud-APIs wie die Cloud Storage API zugreifen. Wir empfehlen, den privater Google-Zugriff zu verwenden, um auf Google-Dienste zuzugreifen, ohne Traffic über das Internet zu senden. Dadurch werden die Kosten und die Latenz der ausgehenden Datenübertragung reduziert. Außerdem ist für Arbeitslasten, die nur Zugriff auf die Google API benötigen, kein Netzwerkpfad zum Internet mehr erforderlich. Weitere technische Details und Konfigurationsschritte finden Sie im Artikel zum privater Google-Zugriff.

Ähnlich sollten VMware Engine-Arbeitslasten, die von einem Service-Produzentennetzwerk aus aufGoogle Cloud -Ressourcen zugreifen müssen, wie z. B. Cloud SQL- oder Memorystore-Instanzen, eine private Verbindung über PSA herstellen. Weitere Informationen finden Sie im Abschnitt zur PSA für die VMware Engine.

Verschlüsseln Sie die Kommunikation zwischen Ihrer lokalen Umgebung und Google Cloud

Arbeitslasten in VMware Engine, die mit lokalen Systemen kommunizieren müssen, sollten über einen verschlüsselten Kanal verbunden werden. Wir empfehlen einen mehrschichtigen Ansatz für die Verschlüsselung bei der Übertragung zwischen Ihren lokalen Rechenzentren undGoogle Cloud. Die Verbindung zwischen lokalen Systemen und Google Cloudkann entweder durch Einrichten von Cloud VPN mit einem IPsec-Tunnel oder durch Verwendung der integrierten IPsec-Funktion auf VLAN-Anhängen des Interconnects verschlüsselt werden. Außerdem sollte die Verschlüsselung auf Anwendungsebene zwischen Anwendungskomponenten mit TLS aktiviert sein.

Daten mit VPC Service Controls vor Exfiltration schützen

Wir empfehlen, das Risiko einer Daten-Exfiltration mit VPC Service Controls zu minimieren, indem Sie Ihre sensiblen Ressourcen wie Cloud Storage-Buckets und BigQuery-Datasets in einen VPC Service Controls-Perimeter einbetten. Arbeitslasten, die auf Daten innerhalb eines Perimeter zugreifen müssen, müssen sich ebenfalls innerhalb des Perimeter befinden. Insbesondere muss das Google Cloud -Projekt, in dem die private Cloud gehostet wird, Teil des VPC Service Controls-Perimeters sein, um auf Ressourcen zuzugreifen, die durch VPC Service Controls geschützt sind.

Sie müssen Richtlinien für die Ein- und Ausgehende Datenübertragung in Ihrer VPC Service Controls-Konfiguration konfigurieren, damit die APIs des VMware Engine-Produzentendienstes in den Perimeter gelangen können. Eine ausführliche Anleitung zur Einrichtung finden Sie auf den Dokumentationsseiten zu VPC Service Controls mit VMware Engine.

IAM-Rollen und -Berechtigungen für VMware Engine

In den folgenden Abschnitten werden Best Practices für Nutzerberechtigungen in einer VMware Engine-Umgebung vorgestellt. Es ist wichtig, die Berechtigungen in der VMware Engine-Umgebung und im Google Cloud -Projekt zu verwalten, in dem die private Cloud bereitgestellt wird.

Vordefinierte oder benutzerdefinierte Rollen verwenden, um Zugriff zu gewähren

Die Verwaltung von vSphere-Rollen und ‑Berechtigungen in VMware Engine funktioniert genauso wie in anderen VMware Engine-Umgebungen. Für Aktivitäten wie die Bereitstellung eines Clusters sind jedoch Berechtigungen in Identity and Access Management (IAM) erforderlich. In der folgenden Tabelle sind relevante Zugriffsmanager, die Identitätsquellen, für die sie Berechtigungen gewähren, und Beispiele für Aktivitäten aufgeführt, die sie ermöglichen.

Plattform	Komponente	Identitätsquelle	Berechtigungen konfigurieren	Beispielaktivitäten
Google Cloud	VMware Engine-Portal	Cloud Identity	Identity and Access Management	Beispiel: Bereitstellung und Kündigung einer Private Cloud oder eines Clusters.
VMware Engine	vCenter	LDAP	Hosts und Cluster, VMs und Ordner, Datenspeicher in der vCenter-Benutzeroberfläche	z. B. VM-Erstellung, VM-Ordnererstellung, Erstellung und Löschen von Datenspeicherobjekten
	NSX-T	LDAP	„Nutzer und Rollen“ auf der NSX-T Manager-Benutzeroberfläche	Beispielsweise Erstellung von NSX-Segmenten, Firewallkonfiguration oder Load Balancer-Konfiguration.
vCenter	VM-Gastbetriebssystem	Beispiel: Active Directory, LDAP, lokale Nutzer	Gastbetriebssystem	SSH- oder RDP-Anmeldung, Dateivorgänge

In Google Cloud IAM gibt es zwei vordefinierte Rollen mit Berechtigungen für das VMware Engine-Portal:

• VMware Engine-Dienstadministrator: Bietet vollständigen Zugriff auf den VMware Engine-Dienst in Google Cloud.
• VMware Engine-Dienstbetrachter: Bietet Lesezugriff auf den VMware Engine-Dienst in Google Cloud.

Diese Berechtigungen beziehen sich auf Aktionen im VMware Engine-Portal und nicht auf Aktionen in der API oder Befehlszeile. Beachten Sie, dass auch die einfachen Rollen die Möglichkeit bieten, den VMware Engine-Dienst zu verwalten (Inhaber, Bearbeiter) oder sich die Dienstdetails anzusehen (Betrachter). Im Allgemeinen wird empfohlen, vordefinierte Rollen anstelle von einfachen Rollen zu verwenden, da sie detailliertere Berechtigungen bieten.

Der programmatische Zugriff auf die VMware Engine über Dienstkonten mit der API oder der Befehlszeile sollte mit vordefinierten oder benutzerdefinierten Rollen eingeschränkt werden, da sie detailliertere Berechtigungen enthalten, die nur für die VMware Engine gelten. Wenn der programmatische Zugriff nur für eine Aufgabe verwendet wird, für die nur eine bestimmte Teilmenge der Berechtigungen der vordefinierten Rollen erforderlich ist, wird empfohlen, eine benutzerdefinierte Rolle zu erstellen.

Wählen Sie einen geeigneten Ort für die IAM-Rollenzuweisung in der Ressourcenhierarchie Ihrer Organisation aus. Wenn Sie alle Ihre privaten VMware Engine-Clouds in einem Projekt ausführen, können die Rollen nur auf Projektebene zugewiesen werden. Wenn es technische oder organisatorische Anforderungen gibt, die dazu führen, dass Ihre privaten Clouds in separaten Projekten gespeichert werden, definieren Sie die erforderlichen Rollen in einem Ordner, der für die Projekte, die für Ihre privaten Clouds verwendet werden, gemeinsam ist.

Cloud IAM-Berechtigungen sind für Aktivitäten nicht erforderlich, die nur in vCenter, NSX-T oder HCX ausgeführt werden müssen. Mitarbeiter, die nur diese Umgebungen nutzen müssen, benötigen keine der oben aufgeführten IAM-Rollen. Stattdessen sollten sie LDAP-Identitäten mit Berechtigungen verwenden, die in vCenter und NSX-T konfiguriert sind. Wir empfehlen, die Rollen „VMware Engine-Dienstadministrator“ oder „VMware Engine-Dienstbetrachter“ nur einer sehr begrenzten Anzahl von Nutzern zuzuweisen, da diese Rollen Zugriff auf das leistungsstarke CloudOwner-Nutzerkonto für vCenter und das Administrator-Nutzerkonto für NSX-T gewähren. Diese Nutzerkonten sollten nur für die Ersteinrichtung oder Notfallmaßnahmen verwendet werden.

Administratorzugriff einschränken und aktiv prüfen

Die Rolle „VMware Engine-Dienstadministrator“ ist sehr leistungsstark und sollte nur Nutzern zugewiesen werden, die den Lebenszyklus der privaten VMware Engine-Cloud und ihrer Cluster verwalten müssen. In der Regel werden Cluster und Knoten nicht häufig manuell hinzugefügt oder gelöscht. Dies kann jedoch erhebliche Auswirkungen auf die Abrechnung oder die Verfügbarkeit des Clusters haben. Weisen Sie diese Rolle nur sehr wenigen Personen in Ihrer Organisation zu.

Prüfen Sie regelmäßig, wem die Rolle „VMware Engine-Dienstadministrator“ zugewiesen wurde, entweder direkt im Projekt, das für VMware Engine verwendet wird, oder auf einer der übergeordneten Ebenen der Ressourcenhierarchie. Diese Prüfung sollte auch andere Rollen umfassen, z. B. die einfachen Rollen „Bearbeiter“ und „Inhaber“, die wichtige Berechtigungen im Zusammenhang mit der VMware Engine enthalten. Mit Diensten wie dem IAM-Rollen-Empfehlungstool können Sie Rollen mit zu vielen Berechtigungen identifizieren.

LDAP- oder Active Directory-Identitätsquelle konfigurieren

Ein Identitätsanbieter, der die LDAP-Authentifizierung unterstützt, z. B. Active Directory, sollte so konfiguriert werden, dass die Nutzerauthentifizierung für vCenter und NSX Manager aktiviert wird. Es wird empfohlen, eine zentrale Verwaltung des Identitätslebenszyklus, der Gruppenverwaltung und der Passwortverwaltung zu haben. Die direkte Verknüpfung von vCenter und NSX-T mit Active Directory für die integrierte Windows-Authentifizierung wird nicht unterstützt.

Passwörter für integrierte Dienstkonten rotieren

VMware Engine generiert Anmeldedaten für den Zugriff auf Management Appliances in der privaten Cloud (z. B. vCenter, NSX-T und HCX). Es wird empfohlen, einen Prozess einzurichten, mit dem die Passwörter des Standard-vCenter-Dienstkontos „[e-mail]“ und des Standard-NSX-T-Dienstkontos für Administratoren rotiert werden. Beide Nutzerkonten sollten nur für die Erstkonfiguration und Notfallprozeduren verwendet werden. Die Passwörter sollten regelmäßig gewechselt werden, z. B. alle 60 oder 90 Tage. Wechseln Sie auch regelmäßig die Passwörter von Lösungsnutzerkonten, die häufig für die Integration von Drittanbietertools verwendet werden. Je häufiger Sie Dienstkontopasswörter rotieren, desto unwahrscheinlicher ist es, dass das Passwort noch gültig ist, wenn ein böswilliger Akteur es findet.

Logging und Monitoring von VMware Engine

In den folgenden Abschnitten werden Best Practices für die Protokollierung und Überwachung von VM-Arbeitslasten und der VMware Engine-Infrastruktur vorgestellt, die die von Arbeitslasten verbrauchten Ressourcen bereitstellt.

VMware Engine-Protokolle und -Messwerte aufnehmen

Viele Organisationen möchten Logs zentral in einer einzigen Ansicht erfassen und analysieren. In Google Cloudbieten die Cloud Logging- und Cloud Monitoring-Produkte Dienste, die für die zentrale Verwaltung von Protokollen und Messwerten verwendet werden können. VMware Engine kann mit Cloud Monitoring über einen eigenständigen Agenten eingebunden werden. In dieser Konfiguration leitet vCenter Messwerte wie die ESXi-CPU- und Arbeitsspeicherauslastung an Cloud Monitoring weiter. Es wird empfohlen, Dashboards auf der Grundlage von Messwerten zu erstellen, die von vCenter weitergeleitet werden, oder mit einigen Beispiel-Dashboards zu beginnen, die auf GitHub veröffentlicht wurden.

Zum Erfassen von Plattformprotokollen können VMware Engine Private Clouds Syslog-Protokolle an einen zentralen Protokoll-Aggregator weiterleiten. Dies ist sowohl für vCenter- als auch für NSX-T-Syslog-Nachrichten möglich. Das Erfassen, Speichern und Analysieren von Syslog-Nachrichten aus vCenter hat wichtige Sicherheitsanwendungsfälle, z. B. Echtzeitwarnungen basierend auf Anmeldungen von Administratoren (oder Notfallnutzern), die nur in Ausnahmefällen durchgeführt werden sollten. Um Syslog-Nachrichten zu analysieren, muss ein Syslog-Aggregator wie Fluentd oder der eigenständige Agent so konfiguriert werden, dass die Nachrichten an Cloud Logging weitergeleitet werden.

Es wird empfohlen, Logs aus der VMware Engine in einem zentralen Dashboard in einem einzelnen Projekt zu analysieren. Wenn Ihre VMware Engine-Umgebung mehrere Projekte umfasst, müssen Sie Ihre Projekte zusätzlich zusammenfassen, indem Sie Log-Sinks und Monitoring-Bereiche konfigurieren.

Cloud Logging-Agent für die Protokollierung von Arbeitslast-VMs verwenden

Arbeitslast-VMs der VMware Engine können Logs mithilfe des Logging-Agents direkt an die Cloud Logging API senden. Der Logging-Agent basiert auf fluentd und streamt Logs von gängigen Drittanbieteranwendungen und Systemsoftware an Cloud Logging. Es empfiehlt sich, den Ansatz zum Erfassen und Analysieren von Protokollen für Arbeitslast-VMs in der VMware Engine mit dem Ansatz für Compute Engine-Instanzen und Ihre lokale Infrastruktur (falls zutreffend) abzugleichen. Die Verwendung des Logging-Agent in der VMware Engine entspricht dem Ansatz, der für VMs in der Compute Engine verwendet wird. So werden die Protokolle von Arbeitslasten auf beiden Plattformen an Cloud Logging gesendet.

Entsprechend der Richtlinien „Access Transparency“ und „Zugriffsgenehmigung“ anwenden

Die VMware Engine unterstützt zwar keine Zugriffstransparenz (Access Transparency, AxT) und keine Zugriffsgenehmigung (Access Approval, AxA) in Google Cloud, wir haben jedoch Prozesse mit vergleichbaren Funktionen implementiert, die auf Anfrage aktiviert werden können.

Für die Gleichwertigkeit der Zugriffstransparenz müssen Sie mehrere Protokollquellen berücksichtigen, darunter:

• vCenter-Protokolle – können mithilfe der Remote-Syslog-Serverkonfiguration exportiert werden.
• ESXi-Protokolle: Diese können mithilfe der Remote-Syslog-Konfiguration erfasst werden. Sie müssen jedoch einen Supportanfrage an Google Cloud senden, um die ESXi-Syslog-Weiterleitung zu konfigurieren.

Wenn Sie strenge behördliche Auflagen haben, implementieren wir eine Richtlinie, um Ihnen entsprechende Funktionen für die Zugriffsberechtigung zur Verfügung zu stellen. Gemäß dieser Richtlinie muss für Standarddienstvorgänge ein Support-Ticket mit dem Grund erstellt werden, warum der Zugriffsanbieter Zugriff benötigt.

FürGoogle Cloud Zugriffsberechtigungen gilt Folgendes: Ausschlüsse

VMware Engine-Verschlüsselung

In den folgenden Abschnitten werden Best Practices für die Verschlüsselung von Speicherplatz in der privaten Cloud und wichtige Faktoren für die Auswahl eines Schlüsselanbieters für Ihre private Cloud vorgestellt.

Verwenden Sie einen Schlüsselanbieter, der auf Google Cloud basiert und für die vSAN-Datenträgerverschlüsselung aktiviert ist.

Die Verschlüsselung inaktiver Daten wird mit der softwarebasierten vSAN-Verschlüsselung implementiert. Standardmäßig aktiviert VMware Engine die vSAN-Verschlüsselung in jedem ESXi-Cluster und konfiguriert einen Standardschlüsselanbieter in vCenter. Google verlangt von Kunden, die vSAN-Verschlüsselung in ihren ESXi-Clustern aktiviert zu lassen. Das Deaktivieren der vSAN-Verschlüsselung verstößt gegen die Nutzungsbedingungen für VMware Engine. Viele Organisationen verlangen im Rahmen ihrer Unternehmensrichtlinien die Ruhedatenverschlüsselung oder sind aufgrund von Vorschriften zur Verschlüsselung von Daten verpflichtet (z. B. NIST, FIPS).

Jeder ESXi-Host verschlüsselt Daten mit dem Standard-AES-256-XTS-Modus mit verschiedenen, zufällig generierten Datenverschlüsselungsschlüsseln (Data Encryption Keys, DEK). Der DEK wird mit einem Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK) verschlüsselt und nur in verschlüsselter Form auf dem Laufwerk gespeichert. Der vCenter-Server speichert nur die ID des KEK, nicht den KEK selbst, der in einem Cloud Key Management Service (KMS) gespeichert ist. Sie können den Standort des Cloud KMS-Speichers auswählen, an dem Ihr KEK aufbewahrt wird.

Wir empfehlen, den von Google verwalteten Standardschlüsselanbieter zu verwenden. Wenn Sie Ihr Cloud KMS jedoch selbst verwalten müssen, können Sie ein KMIP 1.1-konformes Cloud KMS eines Drittanbieters von einem der unterstützten Anbieter verwenden. In beiden Fällen kann der Schlüsselanbieter verwendet werden, um ruhende Daten und vMotion-Traffic während der Übertragung zu verschlüsseln.

In der folgenden Tabelle werden die wichtigsten Unterschiede zwischen dem Standardschlüsselanbieter und Cloud KMS-Integrationen von Drittanbietern aufgeführt:

Schlüsselanbieter	Vorteile	Nachteile
Standard zu Google gehörender und von Google verwalteter Schlüsselanbieter	Einfachheit: „Out-of-the-Box“-Bereitstellung ohne Anbieterverwaltung und ohne operative Belastung End-to-End-Support von Google Die einfachste Methode zum Rotieren von DEKs/KEKs ist die wichtigste Anforderung Keine zusätzlichen Kosten Integrierte Zonenredundanz für Hochverfügbarkeit	Es ist nicht möglich, eigenes Schlüsselmaterial zu verwenden (BYOK). Die KEKs werden in der Google-Infrastruktur gespeichert und verwaltet. Externe Schlüsselmanager (EKM) werden nicht unterstützt.
Cloud KMS-Schlüsselanbieter von Drittanbietern	Volle Kontrolle über die verschlüsselten Daten und den Verschlüsselungsschlüssel Hardwarebasierte Schlüssel können in einer HSM-Anwendung gespeichert werden	Zusätzliche Komplexität und operativer Aufwand Zusätzliche Kosten Mögliche zusätzliche Latenz, insbesondere bei SaaS-KMS Möglicherweise geringere Verfügbarkeit

Es wird nicht empfohlen, die Verschlüsselung auf VM-Ebene zusammen mit der vSAN-Datenspeicher-Verschlüsselung zu aktivieren, da die Effizienz der Deduplizierung bei verschlüsselten VMs gegen Null geht.

Die Rotation von Verschlüsselungsschlüsseln gemäß den Standards Ihrer Organisation automatisieren

Sie sind für die KEK-Rotation mit VMware Engine vSphere verantwortlich. Das gilt sowohl für den Standardschlüsselanbieter als auch für einen externen Cloud KMS. Die KEK-Rotation kann über vCenter oder über die vCenter API gestartet werden. Sie können die KEK-Rotation gemäß den Anforderungen Ihrer Organisation automatisieren. Ein Beispiel-PowerCLI-Script finden Sie auf GitHub.

Sicherung und Notfallwiederherstellung der VMware Engine

Es ist wichtig, Ihre Daten vor Bedrohungen wie Ransomware, Beschädigungen und menschlichem Fehlverhalten zu schützen. Außerdem sind geschäftskritische Anwendungen darauf angewiesen, dass Ihre Daten praktisch jederzeit verfügbar sind. Daher bleibt Ihnen wenig Zeit, Daten nach plötzlichen Ausfällen wiederherzustellen. Dieser Abschnitt deckt nicht alle Aspekte der Sicherung und Notfallwiederherstellung ab, die für die effektive Entwicklung einer Sicherungs- und Notfallwiederherstellungsstrategie zur Sicherung und Verfügbarkeit Ihrer Daten relevant sind. Er enthält jedoch wichtige Überlegungen bei der Auswahl der richtigen Strategie für Ihre VMware Engine-Umgebung.

Arbeitslasten mit dem Sicherungs- und Notfallwiederherstellungsdienst sichern

Der Backup- und Notfallwiederherstellungsdienst Google Cloud bietet eine zentral verwaltete, integrierte Sicherungslösung, die für eine Vielzahl von Anwendungsfällen verwendet werden kann, einschließlich der Sicherung von Arbeitslasten in der Compute Engine und in Google Cloud VMware Engine. Der Sicherungs- und Notfallwiederherstellungsdienst ist die von Google empfohlene Lösung für Sicherungen von Arbeitslasten, da er Vorteile wie einen umfassenden Support für Arbeitslasten, platzsparende, fortlaufende inkrementelle Sicherungen und flexible Speicheroptionen bietet.

Google Cloud Die VMware Engine unterstützt auch die Verwendung von agentbasierten Sicherungslösungen von Drittanbietern. Diese Option ist möglicherweise die beste, wenn Sie bereits Lizenzen für ein Sicherungsprodukt eines Drittanbieters haben. Zu den Voraussetzungen für diese Tools gehören:

• Sie bieten Sicherungen auf Anwendungsebene.
• Sie werden von den Anwendungsanbietern zertifiziert.
• Sie sind von VMware Engine für vSAN zertifiziert.
• Sie unterstützen den Protokollstandard VMware Engine vStorage API for Data Protection (VADP) oder erstellen Sicherungen auf Anwendungsebene.

Unabhängig von der von Ihnen gewählten Sicherungslösung empfehlen wir Cloud Storage als kostengünstige Speicheroption für die langfristige Aufbewahrung von Sicherungen. Cloud Storage ist ein langlebiger, kostengünstiger Objektspeicher. Cloud Storage-Buckets können so konfiguriert werden, dass Speicherobjekte automatisch über mehrere Regionen hinweg repliziert werden. Das ist ideal für multiregionale Cloud-Topologien.

Cloud Storage eignet sich auch ideal für die langfristige Archivierung, da es Lebenszyklusrichtlinien gibt, mit denen Storage-Objekte automatisch in eine andere Speicherebene verschoben werden, sobald ihre Lebensdauer einen vordefinierten Wert überschreitet. Verwenden Sie diese Option für einen kostengünstigen Speicherort für Sicherungen und mittlere bis hohe RPO-Werte, insbesondere wenn Kosten ein wichtiger Faktor sind.

Alternativ können Sie vSAN-Speicher auswählen, um das RPO zu minimieren. Verwenden Sie diese Speicheroption, wenn höhere Kosten für den Sicherungsspeicher akzeptabel sind und die RPO-Anforderungen mit Cloud Storage nicht erfüllt werden können. Verwenden Sie diese Option nicht für die langfristige Archivierung, da die Größe von VMware Engine-Clustern sonst möglicherweise durch den Speicherplatz begrenzt wird.

Notfallwiederherstellung mit dem Sicherungs- und Notfallwiederherstellungsdienst implementieren

Wir empfehlen, Anwendungen in der VMware Engine mit dem Sicherungs- und Notfallwiederherstellungsdienst wiederherzustellen. Um Ihre Produktionsarbeitslasten vor Ausfällen einer einzelnen Zone innerhalb einer Region zu schützen, wird empfohlen, eine private Cloud in einer sekundären Zone innerhalb der Region bereitzustellen und zu betreiben, wenn die VMware Engine in mehr als einer Zone dieser Region verfügbar ist. Andernfalls empfehlen wir, Ihre Anwendungen in einer sekundären Region wiederherzustellen.

Neben der Google Cloud -Sicherung und Notfallwiederherstellung ist die VMware Engine mit anderen Optionen für die Notfallwiederherstellung wie VMware Engine SRM und Zerto kompatibel. Sowohl VMware Engine SRM als auch Zerto nutzen die vSphere-Replikation für die Notfallwiederherstellung, die im Allgemeinen niedrigere RPO-Ziele unterstützt. Wenn Ihr RPO-Ziel in Minuten statt in Stunden angegeben ist, sollten Sie sich für Notfallwiederherstellungslösungen auf der Grundlage der vSphere-Replikation entscheiden.

Zusammenfassung der Checkliste

In der folgenden Checkliste sind die Best Practices für die Sicherheit bei der Verwendung der VMware Engine zusammengefasst.

Aufgabe	Thema
VMware Engine-Netzwerk	Alle Trafficflüsse in Ihrer Umgebung identifizieren und verstehen Öffentlichen IP-Dienst von VMware Engine für die Internetdatenübertragung in Nord-Süd- und Ost-West-Firewallregeln für Gateway und verteilte Firewall in VMware Engine NSX-T trennen Zero-Trust-Sicherheitsprinzipien und Mikrosegmentierung in NSX-T anwenden Firewall-Appliance eines Drittanbieters über das Cloud Marketplace-Portal für IPS-/IDS-Funktionen bereitstellen Webdienste in der VMware Engine mit Google Cloud Armor vor DDoS-Angriffen schützen Verbindung zu Google Cloud Diensten privat ohne Internetzugriff herstellen Kommunikation zwischen Ihrer lokalen Umgebung und Google Cloud Daten mit VPC Service Controls vor Exfiltration schützen
IAM-Rollen und -Berechtigungen für VMware Engine	Vordefinierte oder benutzerdefinierte Rollen verwenden, um Zugriff auf VMware Engine zu gewähren Administratorzugriff auf die VMware Engine einschränken und aktiv prüfen LDAP- oder Active Directory-Identitätsquelle konfigurieren Passwörter für integrierte VMware Engine-Dienstkonten rotieren
Logging und Monitoring von VMware Engine	VMware Engine-Logs und ‑Messwerte aufnehmen Cloud Logging-Agent für die Protokollierung von Workload-VMs verwenden Äquivalente Funktionen der Richtlinien „Access Transparency“ und „Zugriffsgenehmigung“ anwenden
VMware Engine-Verschlüsselung	Von Google verwalteten Schlüsselanbieter verwenden, der für die vSAN-Verschlüsselung inaktiver Daten aktiviert ist Automatische Rotation von Verschlüsselungsschlüsseln gemäß den Standards Ihrer Organisation
Sicherung und Notfallwiederherstellung für VMware Engine	Arbeitslasten mit Sicherung und Notfallwiederherstellung sichern Notfallwiederherstellung mit Back-up und Notfallwiederherstellung implementieren

Nächste Schritte

• Probieren Sie Google Cloud VMware Engine selbst aus. Weitere Informationen finden Sie unter Funktionen, Vorteile und Anwendungsfälle.
• Sicherheitskonzepte der VMware Engine
• Referenzarchitekturen, Diagramme, Anleitungen und Best Practices zu Google CloudWeitere Informationen finden Sie im Cloud Architecture Center.