Best Practices für die VMware Engine-Sicherheit
In diesem Dokument werden die empfohlenen Sicherheits-Best Practices für die Verwaltung und Konfiguration von Google Cloud VMware Engine beschrieben. Es richtet sich an Nutzer, die bereits mit VMware Engine vertraut sind. Wenn Sie Anfänger sind, sollten Sie sich zuerst mit den Voraussetzungen und der Sicherheit von 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 die Vernetzung in einer VMware Engine-Umgebung vorgestellt.
Alle Traffic-Flüsse Ihrer Umgebung identifizieren und nachvollziehen
VMware Engine nutzt VMware Engine-Netzwerke und VPC-Peerings, um eine private Netzwerkverbindung von einem VMware Engine-Netzwerk für private Clouds zu Ihrem VPC-Netzwerk herzustellen. Eingehender Traffic aus einer VPC in IhrerGoogle Cloud -Umgebung oder aus einem lokalen Netzwerk durchläuft ein von Google verwaltetes Netzwerk für Mandanteneinheiten.
Ö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 Internet-Traffic über einen öffentlichen Load Balancer auf Google Cloudeingehen. In diesem Fall wird der Traffic wie jeder andere eingehende Traffic weitergeleitet. Diese Optionen schließen sich gegenseitig aus. Wenn benutzerdefinierte Steuerelemente für Internet-Traffic erforderlich sind, z. B. URL-Filterung, IPS/IDS oder Traffic-Prüfung durch eine zentrale Instanz oder einen zentralen Dienst in Ihrer Google Cloud Umgebung, sollten Sie Internet-Traffic über das VPC-Netzwerk weiterleiten.
Wenn dies nicht auf Sie zutrifft oder Sie die Steuerelemente in Ihrer privaten Cloud implementiert haben, empfehlen wir, den Dienst für externe IP-Adressen in VMware Engine einzubinden. Außerdem empfehlen wir, Regeln für den externen Zugriff zu verwenden, um Trafficmuster aus dem Internet zu blockieren, 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
Konfigurieren Sie die Distributed Firewall (DFW) in NSX 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-Netzwerk-Traffic zwischen Segmenten konzipiert und ermöglicht Firewallregeln, die Traffic zwischen einzelnen Instanzen innerhalb eines Segments zulassen und ablehnen.
Für eine detaillierte Netzwerkzugriffssteuerung sollten Sie eine eingeschränkte Standardrichtlinie für die verteilte Firewall anwenden, um Netzwerkverkehr zwischen Instanzen standardmäßig zu verweigern. Mit der DFW können Sie Traffic zwischen Anwendungen und zwischen Diensten in Ihrer Anwendung gezielt zulassen.
Konfigurieren Sie die NSX-Gateway-Firewall, um den Nord-Süd-Traffic zu steuern, der in die private Cloud gelangt und sie verlässt.
Die NSX-Gateway-Firewall wurde entwickelt, um Nord-Süd-Traffic zu steuern, und wird für Anwendungsfälle wie Steuern 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üssen, konfigurieren Sie die Gateway-Firewall auf dem Tier-0-Router. Wenn Sie den Nord-Süd-Traffic für jedes einzelne NSX-Segment konfigurieren müssen, konfigurieren Sie die Gateway-Firewall auf dem Tier-1-Router.
Zusätzlich zu NSX-Firewalls empfehlen wir, die VPC-Firewall zu verwenden, um Ost-West-Traffic zwischen Arbeitslasten in der privaten VMware Engine-Cloud und Arbeitslasten in VPCs zuzulassen und zu blockieren. Die eingehende Datenübertragung zu Compute Engine-Instanzen von VMware Engine-Arbeitslasten sollte standardmäßig eingeschränkt sein und nur bewusst geöffneten Traffic zulassen.
Der ausgehende Datentransfer zu Verwaltungsgeräten sowie zum vSphere-/vSAN-CIDR-Bereich sollte ebenfalls über die VPC-Firewall blockiert werden. Erlauben Sie die ausgehende Datenübertragung zu Management Appliances nur von vertrauenswürdigen Hosts und IP-Adressen in Ihrem Netzwerk. Wichtig: Management-Appliances befinden sich nicht in einem NSX-Segment. Daher gelten DFW-Regeln nicht, um den Zugriff einzuschränken.
Zero-Trust-Sicherheitsprinzipien und Mikrosegmentierung in NSX anwenden
Mit der NSX DFW können Sie die Traffic-Steuerung für Sicherheitssegmente so detailliert wie für einzelne VMs implementieren. Dieses Prinzip, den Traffic zwischen einzelnen VMs zu schützen, der standardmäßig abgelehnt wird, wird oft auch als Mikrosegmentierung bezeichnet. Dies ist ein detaillierterer Ansatz für Firewalls 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 zum Zulassen von Traffic zu und von VMs können definiert werden, indem die VMs in Richtliniengruppen organisiert werden, die flexible Mitgliedschaftskriterien wie VM-Tag- oder Namensabgleich haben können.
Mit der Mikrosegmentierung können Sie ein Netzwerk mit detaillierter Trafficsteuerung implementieren, in dem ein Trafficmuster explizit zugelassen werden muss. Das Sicherheitskonzept, bei dem alle Netzwerkflüsse durch Identitäts- und Geräteüberprüfungsverfahren und nicht durch implizites Vertrauen gesteuert werden, wird oft auch als Zero-Trust-Sicherheit bezeichnet.
Drittanbieter-Firewall-Appliance über das Cloud Marketplace-Portal für IPS/IDS-Funktionen bereitstellen
Wenn Sie erweiterte Layer 7-Sicherheitsfunktionen benötigen, einschließlich IDS/IPS-Funktionen für eingehenden Traffic in die private Cloud aus dem Rest Ihres Netzwerks oder zwischen Ihren NSX-Netzwerksegmenten, sollten Sie eine Firewall-Appliance eines Drittanbieters bereitstellen. Die Drittanbieter-Appliance kann entweder als Multi-NIC-Appliance zwischen zwei VPCs in Ihrem Google Cloud Netzwerk oder in der privaten Cloud mit einer Integration in NSX bereitgestellt werden.
Eine detaillierte Beschreibung der VMware Engine-Architekturen mit zentralisierten Appliances, die für eine Vielzahl von erweiterten Sicherheitsanwendungsfällen wie IPS/IDS, DDoS, SSL-Offloading und mehr verwendet werden können, finden Sie im Dokument „Netzwerksicherheit mit zentralisierten Appliances“ im Cloud Architecture Center.
Google Cloud Armor zum Schutz von Webservices in VMware Engine vor DDoS-Angriffen verwenden
Wenn Sie eingehenden Traffic zu Arbeitslasten in VMware Engine über das VPC-Netzwerk des Kunden weiterleiten, empfehlen wir, VMware Engine-Arbeitslasten in hybriden Netzwerk-Endpunktgruppen hinter Cloud Service Mesh zu platzieren und den externen HTTP(S)-Load-Balancer zu verwenden. Mit beiden Setups können Sie Google Cloud Armor für öffentlich zugängliche Anwendungen einbinden und so DDoS-Angriffe und häufige Sicherheitslücken wie SQL-Injection oder Cross-Site-Scripting abwehren.
Wenn Sie Service Mesh-Funktionen wie die erweiterte Traffic-Verwaltung mit dem Envoy-Proxy oder die Integration von Certificate Authority Service benötigen, empfehlen wir Cloud Service Mesh. In allen anderen Fällen empfehlen wir den externen HTTP(S)-Load-Balancer.
In der Dokumentation finden Sie Informationen dazu, wie VMware Engine-Arbeitslasten in einer der folgenden Konfigurationen zu Hybrid-NEGs hinzugefügt werden können:
- Regionaler externer HTTP(S)-Lastausgleich mit Hybridkonnektivität
- Globaler externer HTTP(S)-Load-Balancer mit Hybridkonnektivität
Private Verbindungen zu Google Cloud Diensten ohne Internetzugriff herstellen
Arbeitslasten in privaten VMware Engine-Clouds können über den privater Google-Zugriff auf Google CloudAPIs wie die Cloud Storage API zugreifen. Wir empfehlen, privater Google-Zugriff zu verwenden, um auf Google-Dienste zuzugreifen, ohne Traffic über das Internet zu senden. Dadurch werden die Kosten für ausgehende Datenübertragungen und die Latenz reduziert. Dadurch entfällt auch die Notwendigkeit eines Netzwerkpfads zum Internet für Arbeitslasten, die nur Google API-Zugriff benötigen. Weitere technische Details und Konfigurationsschritte finden Sie im Deep Dive zum privater Google-Zugriff.
VMware Engine-Arbeitslasten, die aufGoogle Cloud -Ressourcen aus einem Dienstersteller-Netzwerk wie Cloud SQL- oder Memorystore-Instanzen zugreifen müssen, sollten ebenfalls über PSA eine private Verbindung herstellen. Weitere Informationen finden Sie im Abschnitt zu PSA für 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 des integrierten IPsec für VLAN-Anhänge des Interconnect verschlüsselt werden. Außerdem sollte die Verschlüsselung der Anwendungsschicht zwischen Anwendungskomponenten mit TLS aktiviert werden.
Mit VPC Service Controls Daten 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 einfügen. Arbeitslasten, die auf Daten innerhalb eines Perimeters zugreifen müssen, müssen ebenfalls in den Perimeter platziert werden. Das Google Cloud -Projekt, in dem sich die private Cloud befindet, muss 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 den eingehenden und ausgehenden Datentransfer in Ihrer VPC Service Controls-Konfiguration konfigurieren, damit die VMware Engine-Producer-Dienst-APIs in den Perimeter gelangen können. Eine detaillierte Anleitung zur Einrichtung finden Sie auf unseren Dokumentationsseiten zu VPC Service Controls mit VMware Engine.
IAM 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, dass Sie sich um die Berechtigungen in der VMware Engine-Umgebung und im Google Cloud -Projekt kümmern, in dem die private Cloud bereitgestellt wird.
Zugriff mit vordefinierten oder benutzerdefinierten Rollen gewähren
Der VMware Engine-Ansatz zur Verwaltung von vSphere-Rollen und -Berechtigungen kann auf dieselbe Weise genutzt werden wie in anderen VMware Engine-Umgebungen. Für Aktivitäten wie das Bereitstellen eines Clusters sind jedoch Berechtigungen in Identity and Access Management (IAM) erforderlich. In der folgenden Tabelle sind die relevanten Zugriffsmanager, die Identitätsquellen, für die sie Berechtigungen gewähren, und Beispielaktivitä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 | Bereitstellung und Kündigung von Private Clouds und Clustern |
| VMware Engine | vCenter | LDAP | Hosts und Cluster, VMs und Ordner, Datenspeicher in der vCenter-Benutzeroberfläche | Erstellen von VMs, Erstellen von VM-Ordnern, Erstellen und Löschen von Datenspeicherobjekten |
| NSX | LDAP | „Users and Roles“ (Nutzer und Rollen) in der NSX Manager-Benutzeroberfläche | Dazu gehören beispielsweise die Erstellung von NSX-Segmenten, die Firewallkonfiguration und die Load-Balancer-Konfiguration. | |
| vCenter | VM-Gastbetriebssystem | 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 Service Admin: Bietet vollständigen Zugriff auf den VMware Engine-Dienst auf Google Cloud.
- VMware Engine-Dienstbetrachter: Bietet Lesezugriff auf den VMware Engine-Dienst auf Google Cloud.
Diese Berechtigungen beziehen sich auf Aktionen im VMware Engine-Portal und nicht auf Aktionen in der API oder CLI. Beachten Sie, dass auch die einfachen Rollen die Möglichkeit umfassen, den VMware Engine-Dienst zu verwalten (Inhaber, Bearbeiter) oder die Dienstdetails anzusehen (Betrachter). Im Allgemeinen empfehlen wir, vordefinierte Rollen anstelle von einfachen Rollen zu verwenden, da sie detailliertere Berechtigungen bieten.
Der programmgesteuerte Zugriff auf VMware Engine über Dienstkonten mit der API oder CLI sollte mit vordefinierten Rollen oder benutzerdefinierten Rollen eingeschränkt werden, da diese detailliertere Berechtigungen enthalten, die nur für VMware Engine gelten. Wenn der programmgesteuerte Zugriff nur für eine Aufgabe verwendet wird, für die nur eine bestimmte Teilmenge der Berechtigungen der vordefinierten Rollen erforderlich ist, empfehlen wir, eine benutzerdefinierte Rolle zu erstellen.
Wählen Sie einen geeigneten Ort für die Zuweisung der IAM-Rolle 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 sich Ihre privaten Clouds in separaten Projekten befinden, definieren Sie die erforderlichen Rollen in einem Ordner, der für die Projekte, die für Ihre privaten Clouds verwendet werden, freigegeben ist.
Für Aktivitäten, die nur in vCenter, NSX oder HCX ausgeführt werden müssen, sind keine Cloud IAM-Berechtigungen erforderlich. Mitarbeiter, die diese Umgebungen nur betreiben müssen, benötigen die oben aufgeführten IAM-Rollen nicht. Stattdessen sollten sie LDAP-Identitäten mit in vCenter und NSX konfigurierten Berechtigungen verwenden. 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 Administratornutzerkonto für NSX 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 Service Admin“ ist sehr leistungsstark und sollte nur Nutzern zugewiesen werden, die den Lebenszyklus der privaten VMware Engine-Cloud und ihrer Cluster verwalten müssen. Das manuelle Hinzufügen oder Löschen von Clustern und Knoten ist in der Regel eine Aktion, die nicht häufig vorkommt und erhebliche Auswirkungen auf die Abrechnung oder die Verfügbarkeit des Clusters haben kann. 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 für das Projekt, das für VMware Engine verwendet wird, oder auf einer der übergeordneten Ebenen der Ressourcenhierarchie. Diese Überprüfung sollte auch andere Rollen wie die einfachen Rollen „Bearbeiter“ und „Inhaber“ umfassen, die wichtige Berechtigungen im Zusammenhang mit VMware Engine enthalten. Mit Diensten wie dem IAM-Rollenempfehler 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 konfiguriert werden, um die Nutzerauthentifizierung für vCenter und NSX Manager zu aktivieren. Dies ist eine empfohlene Vorgehensweise für die zentrale Verwaltung des Identitätslebenszyklus, der Gruppen, der Passwörter und mehr. Das direkte Verknüpfen von vCenter und NSX mit Active Directory für die integrierte Windows-Authentifizierung wird nicht unterstützt.
Passwörter von integrierten Dienstkonten rotieren
VMware Engine generiert Anmeldedaten für den Zugriff auf Management Appliances in der privaten Cloud (z. B. vCenter, NSX und HCX). Wir empfehlen, einen Prozess zum Rotieren der Passwörter des Standard-vCenter-Dienstkontos CloudOwner@gve.local und des Standard-NSX-Dienstkontos „administrator“ einzurichten. Beide Nutzerkonten sollten nur für die Erstkonfiguration und Notfallverfahren verwendet werden. Die Passwörter sollten regelmäßig geändert werden (z. B. alle 60 oder 90 Tage). Alternativ können Sie die Passwörter von Lösungsnutzerkonten, die häufig für die Integration von Drittanbietertools verwendet werden, regelmäßig ändern. Je häufiger Sie Dienstkontopasswörter rotieren, desto weniger wahrscheinlich ist es, dass das Passwort noch gültig ist, wenn ein böswilliger Akteur es findet.
Logging und Monitoring in VMware Engine
In den folgenden Abschnitten werden Best Practices für das Logging und Monitoring von VM-Arbeitslasten und der VMware Engine-Infrastruktur vorgestellt, die die von Arbeitslasten genutzten Ressourcen bereitstellt.
VMware Engine-Logs und -Messwerte aufnehmen
Viele Organisationen möchten Logs zentral in einem „Single Pane of Glass“ erfassen und analysieren. In Google Cloudbieten die Produkte Cloud Logging und Cloud Monitoring Dienste, die für die zentrale Verwaltung von Logs und Messwerten verwendet werden können. VMware Engine kann mithilfe eines eigenständigen Agenten in Cloud Monitoring eingebunden werden. In dieser Konfiguration leitet vCenter Messwerte wie die ESXi-CPU- und Arbeitsspeicherauslastung an Cloud Monitoring weiter. Wir empfehlen, Dashboards auf 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 Plattformlogs können VMware Engine Private Clouds Syslog-Logs an einen zentralen Log-Aggregator weiterleiten. Dies kann sowohl für vCenter- als auch für NSX-Syslog-Nachrichten erfolgen. Das Erfassen, Aufbewahren und Analysieren von Syslog-Meldungen von vCenter hat wichtige Sicherheitsanwendungsfälle, z. B. Echtzeitbenachrichtigungen basierend auf Anmeldungen von Administratornutzern (oder Notfallnutzern), die nur in Ausnahmefällen erfolgen sollten. Zum Analysieren von Syslog-Nachrichten muss ein Syslog-Aggregator wie Fluentd oder der eigenständige Agent so konfiguriert werden, dass die Nachrichten an Cloud Logging weitergeleitet werden.
Wir empfehlen, Logs aus der VMware Engine in einem zentralen Dashboard in einem einzelnen Projekt zu analysieren. Wenn sich Ihre VMware Engine-Umgebung über mehrere Projekte erstreckt, müssen Sie Ihre Projekte zusätzlich zusammenfassen, indem Sie Logsinks und Monitoring-Bereiche konfigurieren.
Cloud Logging-Agent für das Logging von Arbeitslast-VMs verwenden
VMware Engine-Arbeitslast-VMs 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 Logs für Arbeitslast-VMs in VMware Engine an den Ansatz für Compute Engine-Instanzen und Ihre lokale Umgebung (falls zutreffend) anzupassen. Die Verwendung des Logging-Agent in VMware Engine entspricht dem Ansatz, der für VMs in Compute Engine verwendet wird. Arbeitslasten auf beiden Plattformen senden ihre Logs an Cloud Logging.
Gleichwertige Funktionen der Richtlinien für Access Transparency und Zugriffsgenehmigung anwenden
VMware Engine unterstützt zwar keine Zugriffstransparenz (Access Transparency, AxT) und Zugriffsbestätigung (Access Approval, AxA) in Google Cloud, aber wir haben Prozesse mit entsprechenden Funktionen implementiert, die auf Anfrage aktiviert werden können.
Für die Access Transparency-Äquivalenz müssen Sie mehrere Logquellen berücksichtigen, darunter:
- vCenter-Logs – können mit der Konfiguration eines Remote-Syslog-Servers exportiert werden.
- ESXi-Logs: Diese können über die Remote-Syslog-Konfiguration erfasst werden. Sie müssen jedoch eine Supportanfrage bei Google Cloud einreichen, um die ESXi-Syslog-Weiterleitung zu konfigurieren.
Wenn Sie strengen gesetzlichen Anforderungen unterliegen, implementieren wir eine Richtlinie, um gleichwertige Funktionen für die Genehmigung des Zugriffs bereitzustellen. Gemäß dieser Richtlinie ist für Standarddienstvorgänge ein Support-Ticket mit einer Begründung erforderlich, warum Dienstbetreiber Zugriff benötigen.
Es geltenGoogle Cloud Zugriffsgenehmigungs-Ausschlüsse.
VMware Engine-Verschlüsselung
In den folgenden Abschnitten werden Best Practices für die Verschlüsselung von Speicher in der privaten Cloud sowie wichtige Faktoren vorgestellt, die bei der Auswahl eines Schlüsselanbieters für Ihre private Cloud zu berücksichtigen sind.
Verwenden Sie einen Google-owned and managed key -Anbieter, der für die vSAN-Verschlüsselung ruhender Daten aktiviert ist.
Die Verschlüsselung inaktiver Daten erfolgt mit der vSAN-Softwareverschlüsselung. Standardmäßig aktiviert VMware Engine die vSAN-Verschlüsselung in jedem ESXi-Cluster und konfiguriert einen Standardschlüsselanbieter in vCenter. Google verlangt, dass Kunden die vSAN-Verschlüsselung in ihren ESXi-Clustern aktiviert lassen. Das Deaktivieren der vSAN-Verschlüsselung ist ein Verstoß gegen die Nutzungsbedingungen für VMware Engine. Viele Organisationen benötigen die Verschlüsselung ruhender Daten als Teil ihrer Unternehmensrichtlinien oder sind durch 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 unterschiedlichen, 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 der Festplatte gespeichert. Auf dem vCenter-Server wird nur die ID des KEK gespeichert, nicht der KEK selbst. Dieser wird in einem Cloud Key Management Service (KMS) gespeichert. Sie können den Standort von Cloud KMS auswählen, an dem Ihr KEK gespeichert wird.
Wir empfehlen, den von Google verwalteten Standardschlüsselanbieter zu verwenden. Wenn Sie Cloud KMS jedoch selbst verwalten müssen, können Sie ein KMIP 1.1-kompatibles Cloud KMS eines der unterstützten Anbieter verwenden. In beiden Fällen kann der Schlüsselanbieter verwendet werden, um inaktive Daten und vMotion-Traffic bei 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 |
|---|---|---|
| Standardanbieter Google-owned and managed key |
|
|
| Drittanbieter von Cloud KMS-Schlüsseln |
|
|
Wir empfehlen, die VM-Verschlüsselung nicht zusammen mit der vSAN-Datenspeicherverschlüsselung zu aktivieren, da die Effizienz der Deduplizierung für verschlüsselte VMs gegen null geht.
Rotation von Verschlüsselungsschlüsseln gemäß den Standards Ihrer Organisation automatisieren
Sie sind für die KEK-Rotation mit VMware Engine vSphere verantwortlich. Das ist sowohl beim Standardschlüsselanbieter als auch bei einem externen Cloud KMS der Fall. Die KEK-Rotation kann über vCenter oder über die zugehörige API initiiert werden. Sie können die KEK-Rotation entsprechend den Anforderungen Ihrer Organisation automatisieren. Ein Beispiel für ein PowerCLI-Skript finden Sie auf GitHub.
Sicherung und Notfallwiederherstellung in VMware Engine
Es ist wichtig, Ihre Daten vor Bedrohungen wie Ransomware, Beschädigung und menschlichem Fehlverhalten zu schützen. Außerdem sind geschäftskritische Anwendungen darauf angewiesen, dass Ihre Daten praktisch jederzeit verfügbar sind. Sie haben also nur wenig Zeit, Daten nach plötzlichen Ausfällen wiederherzustellen. Dieser Abschnitt enthält keine vollständige Abdeckung aller Aspekte der Sicherung und Notfallwiederherstellung, die für die effektive Gestaltung einer Sicherungs- und DR-Strategie zum Schutz und zur 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 Backup- und DR-Dienst sichern
Mit dem Backup- und DR-Dienst Google Cloud wird eine zentral verwaltete, integrierte Sicherungslösung angeboten, die für eine Vielzahl von Anwendungsfällen verwendet werden kann, einschließlich der Sicherung von Arbeitslasten in Compute Engine und Google Cloud VMware Engine. Der Backup and DR Service ist die von Google empfohlene Einzellösung für Workload-Back-ups, da er Vorteile wie eine breite Palette von Workload-Unterstützung, speichereffiziente, inkrementelle Back-ups und flexible Speicheroptionen bietet.
Google Cloud VMware Engine unterstützt auch die Verwendung von agentbasierten Sicherungslösungen von Drittanbietern. Diese Optionen sind möglicherweise besser geeignet, wenn Sie bereits Lizenzen für ein Drittanbieterprodukt zur Sicherung haben. Voraussetzungen für diese Art von Tools sind unter anderem:
- 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 und kostengünstiger Objektspeicher. Cloud Storage-Buckets können so konfiguriert werden, dass Speicherobjekte automatisch in mehreren Regionen repliziert werden. Das ist ideal für multiregionale Cloud-Topologien.
Cloud Storage eignet sich auch ideal für die Langzeitarchivierung, da es Lebenszyklusrichtlinien bietet, mit denen Speicherobjekte automatisch in eine andere Speicherebene verschoben werden, sobald ihre Lebensdauer einen vordefinierten Wert überschreitet. Verwenden Sie diese Option für einen kostengünstigen Sicherungsspeicherort und ein kostengünstiges Sicherungsmedium mit mittleren bis hohen RPOs, insbesondere wenn die Kosten ein wichtiger Faktor sind.
Alternativ können Sie auch vSAN-Speicher auswählen, um den 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. Vermeiden Sie diese Option für die langfristige Archivierung, da das Risiko besteht, dass die VMware Engine-Clustergrößen speichergebunden werden.
Notfallwiederherstellung mit dem Backup- und DR-Dienst implementieren
Wir empfehlen, Anwendungen in VMware Engine mit dem Backup- und DR-Dienst wiederherzustellen. Um Ihre Produktionsarbeitslasten vor Ausfällen einer einzelnen Zone in einer Region zu schützen, empfehlen wir, eine private Cloud in einer sekundären Zone in der Region bereitzustellen und zu betreiben, wenn VMware Engine in mehr als einer Zone dieser Region verfügbar ist. Wenn dies nicht der Fall ist, empfehlen wir, Ihre Anwendungen in einer sekundären Region wiederherzustellen.
Zusätzlich zu Google Cloud Backup and DR ist VMware Engine mit anderen Optionen für die Notfallwiederherstellung kompatibel, z. B. VMware Engine SRM und Zerto. Sowohl VMware Engine SRM als auch Zerto basieren auf der vSphere-Replikation für die Notfallwiederherstellung, die in der Regel niedrigere RPO-Ziele unterstützt. Wenn Ihr RPO-Ziel in Minuten statt in Stunden angegeben ist, sollten Sie DR-Lösungen in Betracht ziehen, die auf der vSphere-Replikation basieren.
Zusammenfassung der Checkliste
In der folgenden Checkliste sind die Best Practices für die Sicherheit bei der Verwendung von VMware Engine zusammengefasst.
| Aufgabe | Thema |
|---|---|
| VMware Engine-Netzwerk |
|
| IAM und Berechtigungen für VMware Engine | |
| Logging und Monitoring in VMware Engine | |
| VMware Engine-Verschlüsselung | |
| VMware Engine-Sicherung und ‑Notfallwiederherstellung |
Nächste Schritte
- Google Cloud VMware Engine selbst ausprobieren Weitere Informationen finden Sie unter Funktionen, Vorteile und Anwendungsfälle.
- Sicherheitskonzepte für VMware Engine
- Referenzarchitekturen, Diagramme, Anleitungen und Best Practices zu Google Cloudkennenlernen. Weitere Informationen finden Sie im Cloud Architecture Center.