Best Practices für die VMware Engine-Sicherheit
In diesem Dokument werden die empfohlenen Sicherheits-Best Practices für die Verwaltung und Konfiguration der Google Cloud VMware Engine und richtet sich an Nutzer, die bereits mit mit VMware Engine. Wenn Sie ein Neueinsteiger sind, mit dem Wissen über die Voraussetzungen und VMware Engine Sicherheit.
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 Networking in einem VMware Engine-Umgebung
Alle Traffic-Flü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 einer VPC in Ihrem oder ein lokales Netzwerk durchläuft Von Google verwaltetes Netzwerk der Mandanteneinheit.
Öffentlichen IP-Dienst von VMware Engine für die Internetdatenübertragung verwenden
Der Internettraffic kann über den öffentlichen IP-Dienst direkt in eine private Cloud eintreten von VMware Engine. Alternativ kann der Internetverkehr über eine öffentlichen Load-Balancer in Google Cloud. In diesem Fall wird der Traffic wie jeder andere eingehende Traffic weitergeleitet. Beachten Sie, dass diese Optionen schließen sich gegenseitig aus. Wenn für den Internettraffic 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 Traffic-Muster aus dem Internet zu verweigern, die für Ihr Anwendungen.
Nord-Süd- und Ost-West-Firewallregeln für Gateway und verteilte Firewall in VMware Engine NSX-T trennen
Die verteilte Firewall (DFW) in NSX-T auf dem logischen Router „tier-1“ konfigurieren um den internen Traffic zwischen Ihren virtuellen Layer-2-Domains zu segmentieren. Die NSX DFW ist die für die Verarbeitung des (internen) Ost-West-Netzwerkverkehrs zwischen Segmenten und lässt Firewallregeln zu, die Traffic zwischen einzelnen Instanzen zulassen oder ablehnen. innerhalb eines Segments.
Für eine detaillierte Netzwerkzugriffssteuerung müssen Sie eine eingeschränkte Standardeinstellung anwenden Richtlinie für die DFW, um Netzwerktraffic zwischen Instanzen standardmäßig abzulehnen. Verwenden Sie die DFW, um den Traffic zwischen Anwendungen und Diensten innerhalb Ihrer Anwendung speziell zuzulassen.
Gateway-Firewall von NSX konfigurieren um Nord-Süd-Traffic zu steuern, der in die private Cloud ein- und ausgeht.
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 in der privaten Cloud konsequent an und konfigurieren Sie dann die Gateway-Firewall auf Tier-0. Router. Wenn Sie den Nord-Süd-Traffic für jede einzelne NSX-T-Segment und konfigurieren Sie dann 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. Offene Datenübertragung auf von vertrauenswürdigen Hosts und IP-Adressen in Ihrem Netzwerk verwalten. 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. Dieser Grundsatz des Schutzes Traffic zwischen einzelnen VMs, der standardmäßig abgelehnt wird, wird häufig auch auf „Mikrosegmentierung“, Dies ist ein detaillierterer Firewallansatz als die herkömmliche Implementierung von Firewalls zwischen Layer-3-Domains.
DFW ist im Hypervisor-Kernel in allen VMware Engine aktiviert. vSphere-Hosts in Ihrer privaten Cloud und können den Trafficfluss zwischen Arbeitslasten, 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. 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 Ebene-7-Sicherheit benötigen, einschließlich IDS/IPS-Funktionen für in die private Cloud eingehenden Traffic aus dem Rest Ihres Netzwerks oder zwischen Ihrer NSX-T-Netzwerksegmente erwägen, eine Drittanbieter-Firewall bereitzustellen Gerät. Die Drittanbieter-Appliance kann entweder als Multi-NIC bereitgestellt werden zwischen zwei VPCs in Ihrem Google Cloud-Netzwerk oder im private Cloud mit einer Integration in NSX-T.
Für einen tieferen Einblick in VMware Engine-Architekturen mit zentralisierter Geräte, die für eine Vielzahl erweiterter Sicherheitsanwendungsfälle eingesetzt werden können, z. B. Informationen zu IPS/IDS, DDoS, SSL-Offloading und weiteren Informationen finden Sie im Dokument zur Netzwerksicherheit. zentralisierte Appliances in der Cloud-Architektur .
Webdienste in der VMware Engine mit Google Cloud Armor vor DDoS-Angriffen schützen
Wenn Sie eingehenden Traffic über die VMware Engine an Arbeitslasten in VMware Engine weiterleiten der Kunden-VPC, dann empfehlen wir, VMware Engine-Arbeitslasten in hybriden Netzwerk-Endpunktgruppen hinter Cloud Service Mesh externen HTTP(S)-Load-Balancer. Bei beiden Konfigurationen können Sie Google Cloud Armor für öffentliche Anwendungen zur Abwehr von DDoS-Angriffen und gängige Schwachstellen wie SQL-Injections oder Cross-Site-Scripting.
Wenn Sie Service-Mesh-Features wie die erweiterte Trafficverwaltung mit Envoy-Proxy oder die Integration von Certificate Authority Service, 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 herstellen
Arbeitslasten in privaten VMware Engine-Clouds können über den privaten Google-Zugriff auf Google Cloud APIs wie die Cloud Storage API zugreifen. Wir empfehlen, Sie privater Google-Zugriff nutzen, um auf Google-Dienste zuzugreifen, Traffic über das Internet, da dies die Kosten für die ausgehende Datenübertragung und die Latenz reduziert. Dies gilt auch für macht es keinen Netzwerkpfad zum Internet für Arbeitslasten mehr erforderlich, Zugriff auf die Google API Weitere Informationen zum privater Google-Zugriff technische Details und Konfigurationsschritte.
Ähnlich sollten VMware Engine-Arbeitslasten, die über ein Service-Producer-Netzwerk auf Google Cloud-Ressourcen zugreifen müssen, 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.
Kommunikation zwischen Ihrer lokalen Umgebung und Google Cloud verschlüsseln
Arbeitslasten in VMware Engine, die mit lokalen Systemen kommunizieren müssen, sollten über einen verschlüsselten Kanal verbunden werden. Wir empfehlen eine mehrschichtige für die Verschlüsselung während der Übertragung zwischen lokalen Rechenzentren und Google Cloud Die Verbindung zwischen lokalen Systemen und Google Cloud kann 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 mithilfe von VPC Service Controls zu minimieren, indem Sie Ihre sensiblen Ressourcen wie Cloud Storage-Buckets und BigQuery-Datasets in einem VPC Service Controls-Perimeter platzieren. 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 eingehende und ausgehende Datenübertragungen in VPC Service Controls konfigurieren um die APIs des VMware Engine Producer-Dienstes in des Perimeters. Eine ausführliche 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, auf Berechtigungen zu achten in der VMware Engine-Umgebung und im Google Cloud-Projekt 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 | Wo werden Berechtigungen konfiguriert? | Beispielaktivitäten |
|---|---|---|---|---|
| Google Cloud | VMware Engine-Portal | Cloud Identity | Identity and Access Management | Zum Beispiel die Bereitstellung und Beendigung der privaten Cloud oder die Bereitstellung und Beendigung von Clustern. |
| 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, z. B. |
In Google Cloud IAM gibt es zwei vordefinierte Rollen mit Berechtigungen für das VMware Engine-Portal:
- VMware Engine Service Admin: gewährt uneingeschränkten Zugriff auf die VMware Engine-Dienst in Google Cloud
- VMware Engine-Dienstbetrachter – gewährt Lesezugriff auf die 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. Die einfachen Rollen die Verwaltung des VMware Engine-Dienstes (Owner, Bearbeiter) oder um die Dienstdetails aufzurufen (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, nur eine bestimmte Teilmenge der Berechtigungen der vordefinierten Rollen benötigt, 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 Private VMware Engine-Clouds in einem Projekt können nur die Rollen sein die auf Projektebene zugewiesen wurden. 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, 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 für die Arbeit Für diese Umgebungen ist das zuvor aufgeführte IAM nicht erforderlich Rollen. Stattdessen sollten sie LDAP-Identitäten mit Berechtigungen verwenden, die in vCenter und NSX-T. 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 Service Admin“ ist sehr leistungsfähig und sollte werden Nutzern zugewiesen, die den Lebenszyklus der Die private VMware Engine-Cloud und ihre Cluster In der Regel enthält das Handbuch Das Hinzufügen oder Löschen von Clustern und Knoten erfolgt nicht häufig und kann sich stark auf die Abrechnung oder die Verfügbarkeit der Cluster. 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. Dies ist eine empfohlene Vorgehensweise, um einen zentralen Identitätslebenszyklus zu haben Gruppenverwaltung, Passwortverwaltung und mehr. Beachten Sie, dass dies Verknüpfung von vCenter und NSX-T mit Active Directory für integrierte Windows-Anwendungen -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 „CloudOwner@gve.local“ 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. Entsprechend sollten Sie die Passwörter von Lösungsnutzerkonten, die die häufig für die Integration von Drittanbieter-Tools 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.
VMware Engine-Logging und -Monitoring
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-Logs und -Messwerte aufnehmen
Viele Organisationen möchten Logs zentral in einer einzigen Ansicht erfassen und analysieren. In Google Cloud bieten die Produkte Cloud Logging und Cloud Monitoring 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 Messwerte wie ESXi-CPU- und Arbeitsspeicherauslastung an Cloud Monitoring weiter. Es wird empfohlen, Dashboards auf der Grundlage von Metriken zu erstellen, die von oder um mit einigen Beispiel-Dashboards zu beginnen, die bereits veröffentlicht wurden, auf GitHub.
Zum Erfassen von Plattformprotokollen können VMware Engine Private Clouds Syslog-Protokolle an einen zentralen Protokoll-Aggregator weiterleiten. Dies kann sowohl für vCenter und NSX-T-Syslog-Nachrichten. Das Erfassen, Speichern und Analysieren von Syslog-Nachrichten aus vCenter hat wichtige Sicherheitsanwendungsfälle, z. B. Echtzeitwarnungen basierend auf Anmeldeaktivitäten von Administratoren (oder Notfallnutzern), die nur in Ausnahmefällen ausgefü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 aus gängigen Anwendungen und Systemen von Drittanbietern zu Cloud Logging hinzufügen. 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 VMware Engine entspricht der der für VMs in Compute Engine verwendet wird, sodass Arbeitslasten auf beiden Plattformen senden ihre Logs an Cloud Logging.
Äquivalente Funktionen der Richtlinien für Access Transparency und Zugriffsgenehmigung anwenden
VMware Engine unterstützt zwar keine Access Transparency (AxT) und keine Zugriffsgenehmigung (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-Logs können über die 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. In dieser Richtlinie werden Es muss ein Support-Ticket mit einem Grund für den Zugriff erstellt werden. und Dienstbetreiber benötigen Zugriff.
Google Cloud-Zugriffsgenehmigung Ausschlüsse angewendet werden.
VMware Engine-Verschlüsselung
In den folgenden Abschnitten werden Best Practices für die Verschlüsselung von Speichermedien in der privaten Cloud und die Faktoren, die bei der Auswahl eines Schlüsselanbieters zu berücksichtigen sind für Ihre private Cloud.
Von Google verwalteten Schlüsselanbieter verwenden, der für die vSAN-Verschlüsselung ruhender Daten aktiviert ist
Die Verschlüsselung ruhender Daten wird mithilfe 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 Unternehmen verlangen, dass ruhende Daten verschlüsselt werden. Richtlinien einhalten oder aufgrund von Vorschriften zur Verschlüsselung von Daten verpflichtet sind (z. B. NIST, FIPS).
Jeder ESXi-Host verschlüsselt Daten mit dem standardmäßigen AES-256 XTS-Modus mit verschiedenen, Zufällig generierte Datenverschlüsselungsschlüssel (Data Encryption Keys, DEKs) Der DEK wird mit einem Schlüssel verschlüsselt Verschlüsselungsschlüssel (Encryption Key, KEK) und nur verschlüsselt 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 jedoch Sie Ihren Cloud KMS selbst verwalten müssen, können Sie KMIP 1.1-konformer Cloud KMS eines Drittanbieters durch einen der Zulieferunternehmen. In beiden Fällen kann der Schlüsselanbieter zur Verschlüsselung ruhender Daten vMotion-Traffic während der Übertragung.
In der folgenden Tabelle sind die wichtigsten Unterschiede zwischen dem Standardschlüsselanbieter aufgeführt und Cloud KMS-Integrationen von Drittanbietern:
| Schlüsselanbieter | Vorteile | Nachteile |
|---|---|---|
| Standardmäßiger von Google verwalteter Schlüsselanbieter |
|
|
| Cloud KMS-Schlüsselanbieter von Drittanbietern |
|
|
Es wird nicht empfohlen, die Verschlüsselung auf VM-Ebene zusammen mit vSAN zu aktivieren. Datenspeicherverschlüsselung, da die Deduplizierungseffizienz annähernd null ist für verschlüsselte VMs.
Die Rotation von Verschlüsselungsschlüsseln gemäß den Standards Ihrer Organisation automatisieren
Sie sind für die KEK-Rotation mithilfe von VMware Engine vSphere verantwortlich. Das gilt sowohl für den Standardschlüsselanbieter als auch für einen externen Cloud KMS. Die KEK-Rotation kann die von vCenter oder über die zugehörige API initiiert 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 enthält keine vollständige Abdeckung aller Sicherungs- und Aspekte der Notfallwiederherstellung, die für die effektive Designentwicklung einer Sicherung und DR-Strategie, um Ihre Daten sicher und verfügbar zu halten, aber Schlüssel enthalten bei der Auswahl der richtigen Strategie VMware Engine-Umgebung
Arbeitslasten mit dem Sicherungs- und Notfallwiederherstellungsdienst sichern
Mit dem Sicherungs- und Notfallwiederherstellungsdienst bietet Google Cloud 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 der 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 VMware Engine unterstützt auch die Verwendung von Drittanbieter-, Agent-basierten Back-up-Lösungen. Diese Option ist möglicherweise die beste, wenn Sie bereits Lizenzen für ein Sicherungsprodukt eines Drittanbieters haben. Zu den Voraussetzungen für diese Art von 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 ausgewählten Sicherungslösung empfehlen wir Cloud Storage als kostengünstige Speicheroption für die langfristige Aufbewahrung von Sicherungen. Cloud Storage ist ein sehr 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. Mit dieser Option können Sie Back-up-Speicherort und mittlere bis hohe RPOs, besonders wenn die Kosten Faktor.
Alternativ können Sie vSAN-Speicher auswählen, um den RPO-Wert zu minimieren. Verwenden wenn höhere Kosten für den Sicherungsspeicher akzeptabel sind und nicht mit Cloud Storage 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 Backup- und DR-Dienst implementieren
Wir empfehlen, Anwendungen in VMware Engine mit Dienst für Sicherung und Notfallwiederherstellung. Zum Schutz Ihrer Produktionsarbeitslasten vor Ausfällen einer in einer einzelnen Zone eines privaten Bereichs erstellt, Cloud in einer sekundären Zone innerhalb der Region, wenn VMware Engine in mehr als einer Zone dieser Region verfügbar sind. Andernfalls empfehlen wir, Ihre Anwendungen in einer sekundären Region wiederherzustellen.
Neben Google Cloud-Sicherung und -Notfallwiederherstellung Die VMware Engine ist mit anderen Optionen für die Notfallwiederherstellung kompatibel, z. B. VMware Engine SRM und Zerto 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 bei Minuten statt Stunden liegt, sollten Sie die Notfallwiederherstellung in Betracht ziehen. auf der Grundlage von vSphere-Replikation.
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 |
|
| VMware Engine-IAM und -Berechtigungen | |
| Logging und Monitoring der VMware Engine | |
| VMware Engine-Verschlüsselung | |
| VMware Engine – Sicherung und Notfallwiederherstellung |
Nächste Schritte
- Probieren Sie Google Cloud VMware Engine selbst aus. Unter Funktionen, Vorteile und Nutzung Cases.
- Sicherheitskonzepte der VMware Engine
- Referenzarchitekturen, Diagramme, Anleitungen und Best Practices zu Google Cloud kennenlernen. Weitere Informationen finden Sie im Cloud Architecture Center.