Dieses Dokument enthält die Best Practices und Richtlinien für Google Cloud-Dienste wie Compute Engine, Google Kubernetes Engine (GKE), Pub/Sub, Dataflow und Cloud Run-Funktionen beim Ausführen von Arbeitslasten aufGoogle Cloud.
Compute-Einstellungen
Diese Einstellungen gelten für Rechenressourcendienste.
VM-Instanzen definieren, die die IP-Weiterleitung aktivieren können
| Google-Einstellungs-ID | VPC-CO-6.3 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Mit der Einschränkung
compute.vmCanIpForward werden die VM-Instanzen definiert, die die IP-Weiterleitung aktivieren können. Standardmäßig kann jede VM die IP-Weiterleitung in jedem virtuellen Netzwerk aktivieren. Geben Sie VM-Instanzen in einem der folgenden Formate an:
|
| Entsprechende Produkte |
|
| Pfad | constraints/compute.vmCanIpForward |
| Operator | = |
| Wert |
|
| Typ | Liste |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Verschachtelte Virtualisierung für VM deaktivieren
| Google-Einstellungs-ID | VPC-CO-6.6 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Die boolesche Einschränkung
compute.disableNestedVirtualization deaktiviert die hardwarebeschleunigte verschachtelte Virtualisierung für Compute Engine-VMs. |
| Entsprechende Produkte |
|
| Pfad | constraints/compute.disableNestedVirtualization |
| Operator | Ist |
| Wert |
|
| Typ | Boolesch |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Externe IP-Adressen auf VMs einschränken
| Google-Einstellungs-ID | VPC-CO-6.2 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Verhindern Sie, sofern nicht erforderlich, das Erstellen von Compute Engine-Instanzen mit öffentlichen IP-Adressen. Die Listeneinschränkung Verhindern Sie, dass Compute Engine-Instanzen externe IP-Adressen haben, um ihre Gefährdung durch das Internet drastisch zu reduzieren. Jede Instanz mit einer externen IP-Adresse ist sofort auffindbar und wird zu einem direkten Ziel für automatisierte Scans, Brute-Force-Angriffe und Versuche, Sicherheitslücken auszunutzen. Stattdessen sollten Sie festlegen, dass Instanzen private IP-Adressen verwenden müssen, und den Zugriff über kontrollierte, authentifizierte und protokollierte Pfade wie den Identity-Aware Proxy (IAP)-Tunnel oder einen Bastion-Host verwalten. Diese Standardeinstellung ist eine grundlegende Best Practice für die Sicherheit, mit der Sie die Angriffsfläche minimieren und einen Zero-Trust-Ansatz für Ihr Netzwerk erzwingen können. Diese Einschränkung ist nicht rückwirkend. |
| Entsprechende Produkte |
|
| Pfad | constraints/compute.vmExternalIpAccess |
| Operator | = |
| Wert |
|
| Typ | Liste |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Zulässige externe IP-Adressen für VM-Instanzen definieren
| Google-Einstellungs-ID | CBD-CO-6.3 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Mit der Listeneinschränkung |
| Entsprechende Produkte |
|
| Pfad | compute.vmExternalIpAccess |
| Operator | = |
| Wert |
|
| Typ | Liste |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Zugriff auf serielle Ports der VM deaktivieren
| Implementierung | Erforderlich |
|---|---|
| Beschreibung | Deaktivieren Sie den Zugriff auf den seriellen Port, indem Sie die Einschränkung der Organisationsrichtlinie Durch das Deaktivieren des seriellen Portzugriffs wird eine umfassende Sicherheitsstrategie erzwungen, da der gesamte administrative Zugriff über standardmäßige, geprüfte Pfade wie SSH erfolgt. Diese können Sie schützen, indem Sie IAM (Identity and Access Management) und IAP (Identity-Aware Proxy) aktivieren. |
| Entsprechende Produkte |
Compute Engine |
| Pfad | constraints/compute.disableSerialPortAccess |
| Operator | = |
| Wert |
|
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
VPC-Connector für Cloud Run Functions erforderlich
| Google-Einstellungs-ID | CF-CO-4.4 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Die boolesche Einschränkung |
| Entsprechende Produkte |
|
| Pfad | constraints/cloudfunctions.requireVPCConnector |
| Operator | = |
| Wert |
|
| Typ | Boolesch |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Shielded VM-Funktionen aktivieren
| Implementierung | Erforderlich |
|---|---|
| Beschreibung | Aktivieren Sie die Attribute „Virtual Trusted Platform Module“ (vTPM) und „Integritätsüberwachung“ von Shielded VM für Ihre Instanzen. vTPM- und Integritätsüberwachungsattribute sind Teil des standardmäßigen Prozesses zum Erstellen von VM-Instanzen. Mit den vTPM- und Integritätsüberwachungsattributen von Shielded VM können Sie dafür sorgen, dass Ihre VMs nur mit vertrauenswürdigem, unverändertem Code gebootet werden. Das vTPM bietet einen sicheren, virtuellen Kryptoprozessor, der kryptografische Messungen der gesamten Bootsequenz von der UEFI-Firmware bis zu den Kerneltreibern generiert und speichert. Die Integritätsüberwachung vergleicht diese Laufzeitmessungen dann kontinuierlich mit einer bekannten Referenz, die beim ersten Erstellen der VM festgelegt wurde. Diese Funktionen bieten eine überprüfbare Vertrauenskette und benachrichtigen Sie automatisch oder ergreifen Maßnahmen, wenn sie schädliche Änderungen erkennen, z. B. durch ein Bootkit oder Rootkit. Shielded VM-Funktionen tragen dazu bei, die Integrität Ihrer Arbeitslast ab dem Moment des Einschaltens der Instanz aufrechtzuerhalten. |
| Entsprechende Produkte |
Compute Engine |
| Pfad | compute.instances/shieldedInstanceConfig.enableVtpm |
| Operator | Ist |
| Wert |
|
| Typ | Boolesch |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
OS Login für VMs erzwingen
| Implementierung | Erforderlich |
|---|---|
| Beschreibung | Wenn Sie Entwicklern den Zugriff auf Compute Engine-Ressourcen über SSH gewähren, konfigurieren Sie OS Login mit Bestätigung in zwei Schritten. Mit OS Login können Sie SSH-Schlüssel mit IAM-Richtlinien (Identity and Access Management) verwalten, indem Sie die Organisationsrichtlinieneinschränkung Die Verknüpfung von SSH-Berechtigungen mit der Identität eines Nutzers ist aus Sicherheitsgründen von entscheidender Bedeutung, da durch das Entfernen der IAM-Rolle eines Nutzers der Zugriff auf alle Instanzen sofort widerrufen wird. So wird unbefugter Zugriff über inaktive Konten verhindert. Das System vereinfacht die Schlüsselverwaltung, um die Schlüsselvermehrung zu verhindern, und bietet einen klaren, zentralen Audit-Trail für alle Anmeldeereignisse in Cloud-Audit-Logs. Mit OS Login können Sie auch die 2‑Faktor-Authentifizierung erzwingen und so eine wichtige Schutzebene gegen gestohlene SSH-Schlüssel und Anmeldedaten hinzufügen. Ein Angreifer, der manipulierte OAuth-Tokens, aber kein Passwort oder Sicherheitsschlüssel verwendet, wird durch diese Funktion blockiert. Der Remote Desktop Protocol (RDP)-Zugriff auf Windows-Instanzen in Compute Engine unterstützt den OS Login-Dienst nicht, sodass die Bestätigung in zwei Schritten nicht differenziert für RDP-Sitzungen erzwungen werden kann. Wenn Sie IAP Desktop oder Google Chrome-basierte RDP-Plug-ins verwenden, legen Sie grobe Steuerelemente wie die Sitzungslänge für Google-Dienste und Einstellungen für die Bestätigung in zwei Schritten für die Websitzungen des Nutzers fest und deaktivieren Sie die Einstellung Nutzer dürfen dem Gerät vertrauen unter „Bestätigung in zwei Schritten“. |
| Entsprechende Produkte |
Compute Engine |
| Pfad | compute.projects/commonInstanceMetadata.items |
| Operator | Ist |
| Wert |
|
| Typ | Boolesch |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Richtlinien für den Nachrichtenspeicher konfigurieren
| Google-Einstellungs-ID | PS-CO-4.1 |
|---|---|
| Implementierung | Optional |
| Beschreibung | Wenn Sie Nachrichten im globalen Pub/Sub-Endpunkt veröffentlichen, speichert Pub/Sub die Nachrichten automatisch in der nächstgelegenen Google Cloud -Region. Wenn Sie steuern möchten, in welchen Regionen Ihre Nachrichten gespeichert werden, konfigurieren Sie eine Richtlinie für die Speicherung von Nachrichten in Ihrem Thema.
Sie haben folgende Möglichkeiten, Richtlinien für die Speicherung von Nachrichten für Themen zu konfigurieren:
|
| Entsprechende Produkte |
|
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Externe IP-Adressen für Dataflow-Jobs deaktivieren
| Google-Einstellungs-ID | DF-CO-6.1 |
|---|---|
| Implementierung | Optional |
| Beschreibung | Deaktivieren Sie externe IP-Adressen für Verwaltungs- und Monitoringaufgaben, die mit Dataflow-Jobs zusammenhängen. Konfigurieren Sie stattdessen den Zugriff auf Ihre Dataflow-Worker-VMs über SSH. Aktivieren Sie den privaten Google-Zugriff und geben Sie eine der folgenden Optionen in Ihrem Dataflow-Job an:
Wobei:
|
| Entsprechende Produkte |
|
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Netzwerktags für Firewallregeln verwenden
| Google-Einstellungs-ID | DF-CO-6.2 |
|---|---|
| Implementierung | Optional |
| Beschreibung | Netzwerk-Tags sind Textattribute, die an Compute Engine-VMs wie Dataflow-Worker-VMs angehängt werden. Mit Netzwerk-Tags können Sie VPC-Netzwerk-Firewallregeln und bestimmte benutzerdefinierte statische Routen für bestimmte VM-Instanzen festlegen. Dataflow unterstützt das Hinzufügen von Netzwerk-Tags zu allen Worker-VMs, die einen bestimmten Dataflow-Job ausführen. |
| Entsprechende Produkte |
|
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Container-Steuerelemente
Diese Einstellungen gelten für Container in GKE.
Zugriff auf die Steuerungsebene einschränken
| Google-Einstellungs-ID | GKE-CO-1.1 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Standardmäßig haben die Steuerungsebene und Knoten des Google Kubernetes Engine-Clusters routingfähige Internetadressen, auf die von jeder IP-Adresse aus zugegriffen werden kann. Beschränken Sie den Netzwerkzugriff auf die Steuerungsebene, indem Sie einen DNS-basierten Endpunkt verwenden und private Cluster erstellen. Die Steuerungsebene ist das Verwaltungszentrum für einen Kubernetes-Cluster. Wenn sie dem Internet ausgesetzt ist, ist sie ein ideales Ziel für Angreifer. In dieser Konfiguration ist die Steuerungsebene privat und nicht über das Internet erreichbar. Durch die Einschränkung des Zugriffs auf die Steuerungsebene wird sichergestellt, dass nur vertrauenswürdige Geräte im privaten Netzwerk Ihrer Organisation den Cluster verwalten können. Dadurch wird das Risiko eines externen Angriffs erheblich verringert. |
| Entsprechende Produkte |
GKE |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
Firewallregeln mit geringsten Berechtigungen verwenden
| Google-Einstellungs-ID | GKE-CO-1.2 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Wenn Sie Firewallregeln erstellen, verwenden Sie das Prinzip der geringsten Berechtigung, um Zugriff nur für den erforderlichen Zweck zu gewähren. Achten Sie darauf, dass Ihre Firewallregeln nicht mit den GKE-Standardfirewallregeln in Konflikt stehen. |
| Entsprechende Produkte |
GKE |
| Zugehörige NIST-800-53-Kontrollen |
|
| Weitere Informationen |
Google Groups for RBAC verwenden
| Google-Einstellungs-ID | GKE-CO-1.3 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Verwenden Sie Google Groups für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC). So können Sie auch Ihre bestehenden Methoden zur Verwaltung von Nutzerkonten einbinden, z. B. zum Sperren des Zugriffs für Personen, die Ihre Organisation verlassen. Google Groups for RBAC ermöglicht eine effiziente Verwaltung des Clusterzugriffs mit Identity and Access Management (IAM) und Google Groups. Das ist für die meisten Organisationen, die Google Groups verwenden, geeignet. |
| Entsprechende Produkte |
Google Kubernetes Engine (GKE) |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Shielded GKE-Knoten aktivieren
| Google-Einstellungs-ID | GKE-CO-1.4 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Aktivieren Sie Shielded GKE-Knoten für die kryptografische Überprüfung der Knoten in Ihrem Cluster. Shielded GKE-Knoten bieten eine starke, überprüfbare Knotenidentität und -integrität. Aktivieren Sie Shielded GKE-Knoten beim Erstellen oder Aktualisieren von Clustern. Verwenden Sie nach Möglichkeit Shielded GKE Nodes mit Secure Boot, um auch die Boot-Komponenten Ihrer Knoten-VMs während des Bootvorgangs zu authentifizieren. Verwenden Sie Secure Boot nicht, wenn Sie unsignierte Kernelmodule von Drittanbietern benötigen. Shielded GKE Nodes ist standardmäßig aktiviert, wenn Sie einen Cluster erstellen. |
| Entsprechende Produkte |
GKE |
| Zugehörige NIST-800-53-Kontrollen |
|
| Weitere Informationen |
Container-Optimized OS mit containerd-Laufzeit verwenden
| Google-Einstellungs-ID | GKE-CO-1.5 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Verwenden Sie Container-Optimized OS, um ein gehärtetes und verwaltetes Container-Betriebssystem zu implementieren. Betriebssysteme für allgemeine Zwecke enthalten viele zusätzliche Programme, die für die Ausführung von Containern nicht erforderlich sind und daher ein größeres, unnötiges Ziel für Angreifer darstellen. Container-Optimized OS ist ein minimales, gesperrtes Betriebssystem, das diese Angriffsfläche erheblich reduziert, da es nur die erforderlichen Komponenten enthält. Als verwaltetes Betriebssystem verfügt Container-Optimized OS auch über Sicherheitspatches, die automatisch von Google angewendet werden. So werden kritische Sicherheitslücken geschlossen und Ihr Betriebsaufwand reduziert. Ein Image, das Container-Optimized OS mit containerd (cos_containerd) enthält, hat containerd als Haupt-Containerlaufzeit, die direkt in Kubernetes eingebunden ist. containerd ist die zentrale Laufzeitkomponente von Docker und wurde entwickelt, um Kerncontainerfunktionen für das Container Runtime Interface (CRI) von Kubernetes bereitzustellen. Sie ist wesentlich weniger komplex als der vollständige Docker-Daemon und bietet so nur eine reduzierte Angriffsfläche. |
| Entsprechende Produkte |
Container-Optimized OS |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Workload Identity Federation für GKE verwenden
| Google-Einstellungs-ID | GKE-CO-1.6 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Mit Workload Identity Federation for GKE können Sie sich sicher bei Google Cloud APIs über Google Kubernetes Engine-Arbeitslasten (GKE) authentifizieren. Die Workload Identity-Föderation für GKE bietet eine einfachere und sicherere Alternative zur Verwendung von Dienstkontoschlüsseln. |
| Entsprechende Produkte |
GKE |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
GKE Sandbox aktivieren
| Google-Einstellungs-ID | GKE-CO-1.7 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Verwenden Sie GKE Sandbox, um eine zusätzliche Sicherheitsebene bereitzustellen, die nicht vertrauenswürdigen Code daran hindert, den Hostkernel auf Ihren Google Kubernetes Engine-Clusterknoten (GKE) zu beeinträchtigen. GKE Sandbox verbessert die Isolierung von Arbeitslasten für nicht vertrauenswürdige oder sensible Arbeitslasten und bietet eine zusätzliche Schutzschicht gegen Container-Escape-Angriffe. |
| Entsprechende Produkte |
GKE |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Schreibgeschützten Port für Kubelet deaktivieren
| Google-Einstellungs-ID | GKE-CO-1.9 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Deaktivieren Sie den schreibgeschützten Kubelet-Port 10255 und verwenden Sie stattdessen den sichereren Port 10250. Kubernetes führt an diesem Port keine Authentifizierungs- oder Autorisierungsprüfungen durch. Das Kubelet stellt dieselben Endpunkte auf dem sichereren, authentifizierten Port 10250 bereit. Sie können den unsicheren schreibgeschützten Kubelet-Port nur in GKE-Version 1.26.4-gke.500 oder höher deaktivieren. |
| Entsprechende Produkte |
GKE |
| Zugehörige NIST-800-53-Kontrollen |
|
| Weitere Informationen |
Mit Namespaces und RBAC den Zugriff auf Clusterressourcen einschränken
| Google-Einstellungs-ID | GKE-CO-1.10 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Erstellen Sie separate Namespaces oder Cluster für jedes Team und jede Umgebung, um den Zugriff auf Kubernetes nach dem Prinzip der geringsten Berechtigung zu implementieren. Weisen Sie jedem Namespace Kostenstellen und entsprechende Labels für Rechnungslegung und Rückbuchungen zu. Gewähren Sie Entwicklern nur Zugriff auf die Namespaces, die sie benötigen, um ihre Anwendung bereitzustellen und zu verwalten, insbesondere in der Produktion. Legen Sie die Aufgaben fest, die Ihre Nutzer für den Cluster ausführen müssen, und definieren Sie die Berechtigungen, die für die jeweilige Aufgabe erforderlich sind. Weisen Sie Gruppen und Nutzern die entsprechenden IAM-Rollen für Google Kubernetes Engine (GKE) zu, um Berechtigungen auf Projektebene bereitzustellen. Verwenden Sie RBAC, um Berechtigungen auf Cluster- und Namespace-Ebene zu gewähren. |
| Entsprechende Produkte |
|
| Zugehörige NIST-800-53-Kontrollen |
|
| Weitere Informationen |
Traffic zwischen Pods einschränken
| Google-Einstellungs-ID | GKE-CO-1.11 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Standardmäßig können alle Pods in einem Cluster miteinander kommunizieren. Steuern Sie die Pod-zu-Pod-Kommunikation je nach Bedarf für Ihre Arbeitslasten. Die Beschränkung des Netzwerkzugriffs auf Dienste erschwert es Angreifern, sich innerhalb des Clusters seitlich zu bewegen. Sie bietet Diensten außerdem einen gewissen Schutz vor versehentlichen oder absichtlichen Denial-of-Service-Angriffen. Es gibt zwei Möglichkeiten, den Traffic zu steuern:
|
| Entsprechende Produkte |
GKE |
| Zugehörige NIST-800-53-Kontrollen |
|
| Weitere Informationen |
Richtlinien mithilfe von Zulassungs-Controllern erzwingen
| Google-Einstellungs-ID | GKE-CO-1.12 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Zugangs-Controller sind Plug-ins, die die Art der Verwendung des Clusters steuern und erzwingen. Sie müssen aktiviert sein, damit Sie einige der erweiterten Sicherheitsfunktionen von Kubernetes verwenden können. Sie sind außerdem ein wichtiger Bestandteil des Defense-in-Depth-Konzepts zur Härtung des Clusters. Standardmäßig können Pods in Kubernetes mit Funktionen arbeiten, die über ihre Anforderungen hinausgehen. Verwenden Sie Zulassungskontrollen, um die Funktionen des Pods auf die für diese Arbeitslast erforderlichen Funktionen zu beschränken. GKE unterstützt zahlreiche Steuerelemente, mit denen Sie Ihre Pods so einschränken können, dass sie nur mit den explizit zugewiesenen Funktionen ausgeführt werden. Policy Controller ist beispielsweise für Cluster in Flotten verfügbar. Kubernetes verfügt auch über den integrierten PodSecurity-Admission-Controller, mit dem Sie die Pod-Sicherheitsstandards in einzelnen Clustern erzwingen können. Policy Controller ist ein Feature von GKE, mit dem Sie die Sicherheit in GKE-Clustern mithilfe von deklarativen Richtlinien erzwingen und validieren können. |
| Entsprechende Produkte |
GKE |
| Zugehörige NIST-800-53-Kontrollen |
|
| Weitere Informationen |
Möglichkeit einschränken, dass sich Arbeitslasten selbst ändern
| Google-Einstellungs-ID | GKE-CO-1.13 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Bestimmte Kubernetes-Arbeitslasten, insbesondere Systemarbeitslasten, haben die Berechtigung, sich selbst zu ändern. Beispielsweise werden einige Arbeitslasten automatisch vertikal skaliert. Dies ist zwar praktisch, kann einem Angreifer, der bereits einen Knoten manipuliert hat, aber auch die Möglichkeit bieten, im Cluster weiter zu eskalieren. Ein Angreifer kann beispielsweise dafür sorgen, dass sich eine Arbeitslast auf dem Knoten selbst ändert, um als ein privilegierteres Dienstkonto ausgeführt zu werden, das im selben Namespace vorhanden ist. Arbeitslasten sollten nicht standardmäßig die Berechtigung erhalten, sich selbst zu ändern. Wenn eine Selbständerung erforderlich ist, können Sie die Berechtigungen einschränken, indem Sie Gatekeeper- oder Policy Controller-Einschränkungen anwenden, z. B. „NoUpdateServiceAccount“ aus der Open-Source-Gatekeeper-Bibliothek, die mehrere nützliche Sicherheitsrichtlinien bietet. Wenn Sie Richtlinien bereitstellen, müssen die Controller, die den Clusterlebenszyklus verwalten, die Möglichkeit haben, die Richtlinien zu umgehen. Controller müssen Änderungen am Cluster vornehmen, z. B. Clusterupgrades anwenden. Wenn Sie beispielsweise die Richtlinie „NoUpdateServiceAccount“ in GKE bereitstellen, müssen Sie die folgenden Parameter in der Einschränkung festlegen: parameters: allowedGroups: - system:masters allowedUsers: - system:addon-manager |
| Entsprechende Produkte |
GKE |
| Zugehörige NIST-800-53-Kontrollen |
|
| Weitere Informationen |
Clusterkonfigurationen überwachen
| Google-Einstellungs-ID | GKE-CO-1.14 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Prüfen Sie Ihre Clusterkonfigurationen auf Abweichungen von Ihren definierten Einstellungen. Die in diesen Best Practices behandelten Einstellungen sowie andere häufige Fehlkonfigurationen können mit Security Command Center automatisch überprüft werden. |
| Entsprechende Produkte |
|
| Zugehörige NIST-800-53-Kontrollen |
|
| Weitere Informationen |
Binärautorisierung erzwingen
| Google-Einstellungs-ID | BIN-CO-1.1 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Mit der Binärautorisierung können Sie dafür sorgen, dass vertrauenswürdige Images in Google Kubernetes Engine (GKE) und Cloud Run bereitgestellt werden. Die Binärautorisierung trägt dazu bei, dass nur verifizierte und vertrauenswürdige Container-Images in Ihren Clustern bereitgestellt werden können, wodurch die Sicherheit der Softwarelieferkette erhöht wird. |
| Entsprechende Produkte |
|
| Pfad | constraints/binaryauthorization.requireBinauthz |
| Operator | == |
| Wert |
|
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
GKE Autopilot verwenden
| Implementierung | Erforderlich |
|---|---|
| Beschreibung | Google Kubernetes Engine (GKE) Autopilot-Cluster verwenden Autopilot-Cluster bieten robuste Sicherheitsmaßnahmen, wobei viele Best Practices für die Sicherheit von Containern oder GKE standardmäßig aktiviert sind. |
| Entsprechende Produkte |
GKE |
| Pfad | container.clusters/autopilot.enabled |
| Operator | Ist |
| Wert |
|
| Typ | Boolesch |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Konten mit geringster Berechtigung für GKE-Cluster und -Knoten verwenden
| Implementierung | Erforderlich |
|---|---|
| Beschreibung | Verwenden Sie IAM-Dienstkonten (Identity and Access Management) mit minimalen Berechtigungen für Google Kubernetes Engine-Cluster (GKE) und -Knoten. Der Zugriff auf die GKE-Steuerungsebene ist auf einen einzelnen DNS-basierten Endpunkt beschränkt. Durch die Implementierung des Prinzips der geringsten Berechtigung wird die Angriffsfläche erheblich reduziert, ohne dass zusätzliche Firewallregeln oder Bastion-Hosts erforderlich sind. |
| Entsprechende Produkte |
GKE |
| Pfad | container.clusters/nodeConfig.serviceAccount |
| Operator | != |
| Wert |
|
| Typ | String |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
Private GKE-Knoten verwenden
| Implementierung | Erforderlich |
|---|---|
| Beschreibung | Erstellen Sie private Knoten, um die Angriffsfläche im Internet zu verringern. Private Google Kubernetes Engine-Knoten (GKE) tragen dazu bei, die Internetpräsenz zu verringern, da GKE-Knoten keine öffentliche IP-Adresse haben. |
| Entsprechende Produkte |
GKE |
| Pfad | container.clusters/networkConfig.defaultEnablePrivateNodes |
| Operator | Ist |
| Wert |
|
| Typ | Boolesch |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
Confidential Google Kubernetes Engine-Knoten verwenden
| Implementierung | Erforderlich |
|---|---|
| Beschreibung | Mit Confidential GKE Nodes können Sie die Verschlüsselung aktiver Daten in Ihren Knoten und Arbeitslasten erzwingen. Confidential GKE Nodes tragen dazu bei, hochsensible Arbeitslasten zu schützen, indem sie aktive Daten durch Confidential Computing verschlüsseln. |
| Entsprechende Produkte |
Google Kubernetes Engine (GKE) |
| Pfad | container.clusters/confidentialNodes.enabled |
| Operator | Ist |
| Wert |
|
| Typ | Boolesch |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
Benutzerdefinierte Zertifizierungsstelle in GKE ausführen
| Implementierung | Erforderlich |
|---|---|
| Beschreibung | Sie können Ihre eigenen Zertifizierungsstellen verwenden, um Schlüssel in Google Kubernetes Engine (GKE) zu verwalten. Die Verwendung eigener Zertifizierungsstellen bietet mehr Kontrolle über kryptografische Vorgänge. Wenn Sie Zugriff auf diese Funktion anfordern möchten, wenden Sie sich an Ihr Google Cloud Account-Management-Team. |
| Entsprechende Produkte |
GKE |
| Pfad | container.clusters/userManagedKeysConfig.clusterCa |
| Operator | Ist festgelegt |
| Typ | String |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Kubernetes-Secrets mit Cloud KMS verschlüsseln
| Implementierung | Erforderlich |
|---|---|
| Beschreibung | Kubernetes-Secrets im Ruhezustand mit von Cloud Key Management Service (Cloud KMS) verwalteten Schlüsseln verschlüsseln. Cloud KMS bietet eine zusätzliche Sicherheitsebene für etcd-Daten, da Sie Kubernetes-Secrets mit einem Schlüssel verschlüsseln können, der Ihnen gehört und den Sie verwalten. |
| Entsprechende Produkte |
|
| Pfad | container.clusters/databaseEncryption.keyName |
| Operator | Ist festgelegt |
| Typ | String |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
CMEK für Bootlaufwerke von Knoten verwenden
| Implementierung | Erforderlich |
|---|---|
| Beschreibung | Verwenden Sie kundenverwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) für die Verschlüsselung von Knoten-Bootlaufwerken. Mit CMEK können Sie das Bootlaufwerk eines Kubernetes-Knotens mit einem Schlüssel verschlüsseln, den Sie besitzen und verwalten. |
| Entsprechende Produkte |
|
| Pfad | container.clusters/nodeConfig.bootDiskKmsKey |
| Operator | Ist festgelegt |
| Typ | String |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
VMware Engine-Steuerelemente
Zuweisungen von Administratorrollen für VMware Engine einschränken
| Google-Einstellungs-ID | GCVE-CO-3.1 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Gewähren Sie Administratorrollen nur den Dienstkonten, die private Google Cloud VMware Engine-Clouds bereitstellen und konfigurieren, und einer begrenzten Anzahl von Administratoren. 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. 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. Dieses Audit 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-Rollen-Recommender können Sie Rollen mit zu vielen Berechtigungen ermitteln. |
| Entsprechende Produkte |
|
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
Rolle „VMware Engine Service Viewer“ für geringste Berechtigungen verwenden
| Google-Einstellungs-ID | GCVE-CO-3.3 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Weisen Sie Nutzern standardmäßig und nur bei Bedarf die Rolle „VMware Engine-Dienstbetrachter“ zu. Die Rolle „VMware Engine Service Viewer“ bietet schreibgeschützten Zugriff auf Google Cloud VMware Engine auf Google Cloud und ist für die meisten Aufgaben ausreichend. |
| Entsprechende Produkte |
|
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
RBAC und das Prinzip der geringsten Berechtigung für vCenter Server Appliance-Rollen verwenden
| Google-Einstellungs-ID | GCVE-CO-3.4 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Verwenden Sie beim Zuweisen von VMware-Rollen in der vCenter Server Appliance die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) und das Prinzip der geringsten Berechtigung. |
| Entsprechende Produkte |
VMware Engine |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
Identitätsföderation für VMware-Nutzer verwenden
| Google-Einstellungs-ID | GCVE-CO-3.5 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Sie verwalten eine einzelne Identitätslösung, in der Sie Nutzerkonten bereitstellen und verwalten können. Mit dieser empfohlenen Vorgehensweise können Sie Aktivitäten wie die Verwaltung des Identitätslebenszyklus, die Gruppenverwaltung und die Passwortverwaltung zentralisieren. Vermeiden Sie eine fragmentierte Identitätsstrategie. |
| Entsprechende Produkte |
VMware Engine |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Gruppen statt Einzelpersonen Rollen für die vCenter Server Appliance zuweisen
| Google-Einstellungs-ID | GCVE-CO-3.6 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Wenn Sie Rollen auf VMware-Ebene in der vCenter Server Appliance zuweisen, weisen Sie Rollen den Gruppen zu, die Sie in Ihrem Identitätsanbieter erstellen. Keine fragmentierte Identitätsstrategie erstellen |
| Entsprechende Produkte |
VMware Engine |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Nutzergruppen in vSphere nicht die Cloud-Owner-Rolle zuweisen
| Google-Einstellungs-ID | GCVE-CO-3.7 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Weisen Sie beim Erstellen von Nutzergruppen in vSphere nicht die Cloud-Inhaber-Rolle zu. Mit dieser Rolle erhalten Sie die administrative Kontrolle über die vCenter-Umgebung Ihrer privaten Cloud, während bestimmte zugrunde liegende globale Infrastrukturberechtigungen eingeschränkt werden. Nutzergruppen mit Berechtigungen, die höher als die Rolle „Cloud-Inhaber“ sind, werden automatisch auf die Rolle „Cloud-Inhaber“ zurückgesetzt. |
| Entsprechende Produkte |
VMware Engine |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
Verwendung von Standarddienstkonten für vCenter und NSX-T vermeiden
| Google-Einstellungs-ID | GCVE-CO-3.8 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Verwenden Sie das Standarddienstkonto für vCenter (CloudOwner@gve.local) und das Standarddienstkonto für NSX-T-Administrator (admin) nur für die Erstkonfiguration und Notfallverfahren. Diese Standarddienstkonten enthalten leistungsstarke Berechtigungen wie die Rolle „Cloud-Inhaber“ und „Enterprise-Administrator“. Speichern Sie die Anmeldedaten für diese Dienstkonten in Secret Manager. |
| Entsprechende Produkte |
VMware Engine |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Passwörter für Standarddienstkonten für vCenter und NSX-T alle 90 Tage rotieren
| Google-Einstellungs-ID | GCVE-CO-3.9 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Um die unbefugte Offenlegung der Anmeldedaten für das Standard-Dienstkonto für vCenter (CloudOwner@gve.local) und den Standard-Dienstkonto-Administrator für NSX-T (admin) zu verhindern und zu minimieren, sollten Sie die Passwörter alle 90 Tage ändern. |
| Entsprechende Produkte |
VMware Engine |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
NSX Gateway Firewall zum Segmentieren des Nord-Süd-Traffics verwenden
| Google-Einstellungs-ID | GCVE-CO-1.2 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Steuern Sie den Nord-Süd-Netzwerkverkehr, der über die NSX Gateway Firewall in Ihre privaten Clouds ein- und ausgeht. NSX Gateway-Firewalls sind Nord-Süd-Firewalls, die zum Schutz der Peripherie beitragen. |
| Entsprechende Produkte |
VMware Engine |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Verteilte NSX-Firewall zum Segmentieren des Ost-West-Traffics verwenden
| Google-Einstellungs-ID | GCVE-CO-1.3 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Mit der verteilten NSX-Firewall (Distributed Firewall, DFW) können Sie den Ost-West-Netzwerkverkehr in Ihrer privaten Cloud steuern. Standardmäßig können alle Subnetze miteinander kommunizieren. Mit DFW können Sie zulässigen Traffic zwischen Anwendungen und Diensten in Ihrer Anwendung definieren. |
| Entsprechende Produkte |
VMware Engine |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Separate Subnetze für Arbeitslasten mit unterschiedlichen Sicherheitsanforderungen erstellen
| Google-Einstellungs-ID | GCVE-CO-1.4 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Wenn Sie Arbeitslasten mit unterschiedlichen Sicherheitsanforderungen oder Datenklassifizierungen ausführen, erstellen Sie Arbeitslast-Subnetze, um sie zu trennen. Mit Subnetzen können Sie den potenziellen Blast Radius verringern, indem Sie Arbeitslasten mit unterschiedlichen Sicherheitsanforderungen und ‑konfigurationen nicht mischen. |
| Entsprechende Produkte |
VMware Engine |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Logsink zum Speichern von VMware Engine-Audit-Logs erstellen
| Google-Einstellungs-ID | GCVE-CO-4.1 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Verwenden Sie ein Log-Sink, um Google Cloud VMware Engine API-Audit-Logs zu speichern. Sie können Audit-Logs nach Bedarf an verschiedene Ziele weiterleiten. |
| Entsprechende Produkte |
VMware Engine |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
Plattformlogs auf VMware-Ebene erfassen
| Google-Einstellungs-ID | GCVE-CO-4.2 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Wenn Sie Plattformlogs auf VMware-Ebene (z. B. Syslog-Nachrichten von vCenter und NSX-T) erfassen möchten, konfigurieren Sie private Google Cloud VMware Engine-Clouds so, dass Syslog-Logs an einen zentralen Log-Aggregator weitergeleitet werden. Diese Logs werden nicht in VMware Engine-Audit-Logs erfasst und müssen separat erfasst werden. |
| Entsprechende Produkte |
VMware Engine |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
Anwendungen mit Logging und Monitoring überwachen
| Google-Einstellungs-ID | GCVE-CO-4.3 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Installieren Sie den eigenständigen Agenten, um Cloud Logging und Cloud Monitoring von der VMware vSphere-Plattform aus zu aktivieren. Mit dem eigenständigen Agenten können Sie Logs auf Arbeitslast-Ebene erfassen und zur Analyse und Speicherung an Logging und Monitoring senden. |
| Entsprechende Produkte |
|
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
Private Clouds in Regionen erstellen, die Ihren Anforderungen an den Datenstandort entsprechen
| Google-Einstellungs-ID | GCVE-CO-2.1 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Erstellen Sie private Google Cloud VMware Engine-Clouds in Regionen, die den Anforderungen Ihrer Organisation an den Datenstandort entsprechen. Private Clouds sind langlebige bereitgestellte Ressourcen, die nicht einfach bereitzustellen und zu verlagern sind. |
| Entsprechende Produkte |
VMware Engine |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
Strategie für Sicherung und Notfallwiederherstellung implementieren
| Google-Einstellungs-ID | GCVE-CO-5.1 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Implementieren Sie den Backup- und DR-Dienst oder eine Drittanbieter-Sicherungslösung für Arbeitslasten. Standardmäßig werden in Google Cloud VMware Engine nur vCenter- und NSX-Konfigurationen automatisch gesichert. Mit Backup and DR wird die Sicherung und Wiederherstellung von VMs vereinfacht. |
| Entsprechende Produkte |
|
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
Verschlüsselung auf Anwendungsebene für VMware-Arbeitslasten implementieren
| Google-Einstellungs-ID | GCVE-CO-1.1 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Achten Sie darauf, dass Anwendungen, die in Google Cloud VMware Engine ausgeführt werden, ihren Traffic verschlüsseln. VMware Engine verschlüsselt Arbeitslast-Traffic während der Übertragung nicht. |
| Entsprechende Produkte |
VMware Engine |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
Verschlüsselung von Daten während der Übertragung in VMware vSAN-Clustern aktivieren
| Google-Einstellungs-ID | GCVE-CO-2.3 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Aktivieren Sie die Verschlüsselung von Daten bei der Übertragung in VMware vSAN-Clustern, um Daten, Metadaten und Dateidienst-Traffic zu verschlüsseln. |
| Entsprechende Produkte |
VMware Engine |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |
VSAN-Verschlüsselung inaktiver Daten für die Verwendung von CMEK konfigurieren
| Google-Einstellungs-ID | GCVE-CO-2.2 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Wenn dies durch Ihre regulatorische Umgebung erforderlich ist, konfigurieren Sie die vSAN-Verschlüsselung ruhender Daten so, dass kundenverwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEKs) verwendet werden. |
| Entsprechende Produkte |
|
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
Schlüssel für die vSAN-Verschlüsselung ruhender Daten rotieren
| Google-Einstellungs-ID | GCVE-CO-2.4 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Verwalten Sie den Lebenszyklus der Schlüsselverschlüsselungsschlüssel (Key Encryption Keys, KEKs), die Sie für die Verschlüsselung inaktiver vSAN-Daten verwenden. Implementieren Sie ein Schlüsselrotationsverfahren, das den Anforderungen Ihrer Organisation entspricht. |
| Entsprechende Produkte |
|
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige Einstellungen für das CRI-Profil |
|
| Weitere Informationen |