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 CRI-Profileinstellungen |
|
| 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 | Is |
| Wert |
|
| Typ | Boolesch |
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| 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 CRI-Profileinstellungen |
|
| 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 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 CRI-Profileinstellungen |
|
| 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 CRI-Profileinstellungen |
|
| 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 CRI-Profileinstellungen |
|
| 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 CRI-Profileinstellungen |
|
| 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. Bei 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 |
|
| 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 |
|
| 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 vorhandenen Verfahren zur Verwaltung von Nutzerkonten einbinden, z. B. den Zugriff widerrufen, wenn jemand Ihre Organisation verlässt. Google Groups for RBAC ermöglicht eine effiziente Verwaltung des Clusterzugriffs mit Identity and Access Management (IAM) und Google Groups, was für die meisten Organisationen, die Google Groups verwenden, geeignet ist. |
| Entsprechende Produkte |
|
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| 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 |
|
| 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 Kubernetes Container Runtime Interface (CRI) bereitzustellen. Sie ist wesentlich weniger komplex als der vollständige Docker-Daemon und bietet so nur eine reduzierte Angriffsfläche. |
| Entsprechende Produkte |
|
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| Weitere Informationen |
Workload Identity Federation für GKE verwenden
| Google-Einstellungs-ID | GKE-CO-1.6 |
|---|---|
| Implementierung | Erforderlich |
| Beschreibung | Mit Workload Identity Federation für GKE können Sie sich sicher bei Google Cloud APIs über Google Kubernetes Engine-Arbeitslasten (GKE) authentifizieren. Workload Identity Federation für GKE ist eine einfachere und sicherere Alternative zur Verwendung von Dienstkontoschlüsseln. |
| Entsprechende Produkte |
|
| 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 |
|
| Zugehörige NIST-800-53-Kontrollen |
|
| Zugehörige CRI-Profileinstellungen |
|
| 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 |
|
| 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 |
|
| 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 |
|
| 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. Gewähren Sie Arbeitslasten nicht standardmäßig die Berechtigung, sich selbst zu ändern. Wenn eine Selbständerung erforderlich ist, schränken Sie die Berechtigungen ein, 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 |
|
| 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 |