Google Distributed Cloud (GDC) mit Air Gap schützt Hardware-Racks, Host-Betriebssysteme, mehrmandantenfähige Grenzen, Software-Lieferketten und Netzwerkverkehr, die in akkreditierten Rechenzentren bereitgestellt werden.
Gebäudesicherheit
GDC-Hardware wird in akkreditierten Rechenzentren bereitgestellt, die von Ihnen oder Ihrem designierten Betreiber kontrolliert werden. Ihre Organisation und der Infrastrukturbetreiber sind für die Durchsetzung von physischen Zugriffssteuerungen, Umweltschutzmaßnahmen und Verfahren zur Medienhandhabung für die Einrichtung verantwortlich, in der die GDC-Racks gehostet werden.
Zu den empfohlenen physischen Sicherheitskontrollen gehören:
- Zugriffssteuerung für Perimeter und Racks: Der physische Zugang zum Rechenzentrum und zu den GDC-Racks wird durch Ausweisleser, biometrische Authentifizierung, Besucherbegleitprotokolle, rund um die Uhr verfügbare Sicherheitskräfte und verschlossene Racktüren eingeschränkt.
- Überwachung und Manipulationserkennung: Die Rackgänge werden kontinuierlich mit Videoüberwachung und physischen Einbruchsalarmen überwacht.
- Isolierung von Strom, Kühlung und Verkabelung: Bereitstellung redundanter Stromversorgungen, Umgebungsüberwachung und geschützter Verkabelungswege, die Ihren regulatorischen und Akkreditierungsanforderungen (z. B. ISO/IEC 27001 oder ICD 705) entsprechen.
Hardwaresicherheit
GDC wird auf vorintegrierten, modularen Hardware-Racks ausgeführt, die mit handelsüblichen Komponenten von geprüften Erstausrüstern (Original Equipment Manufacturers, OEMs) hergestellt werden. Die Hardware-Racks werden in zertifizierten regionalen Einrichtungen von Mitarbeitern integriert, die einer Zuverlässigkeitsüberprüfung unterzogen wurden. Hardware- und Firmwarekomponenten mit hohem Risiko werden außerdem speziellen Sicherheitsüberprüfungen unterzogen, um Bedrohungen durch die Lieferkette und physische Manipulationen zu erkennen.
Zu den wichtigsten Hardwaresicherheitskontrollen gehören:
- Compute-Server: Bare-Metal-Server verwenden Hardware-Roots of Trust, Trusted Platform Modules (TPM 2.0) und signierte BMC-Firmware (Baseboard Management Controller), um die Hardware- und Boot-Integrität zu prüfen, bevor das Betriebssystem geladen wird.
- Netzwerk-Switches und Perimeter-Firewalls: Top-of-Rack- und Management-Switches erzwingen Zugriffssteuerungen auf Portebene und MACsec-Verschlüsselung. Redundante Perimeter-Firewalls bieten zustandsorientierte Prüfung und Einbruchsprävention an der Zonengrenze.
- Speicher-Appliances: Block-, Datei- und Objektspeicher-Appliances für Unternehmen erzwingen die hardwarebeschleunigte AES-256-Verschlüsselung ruhender Daten auf selbstverschlüsselnden Laufwerken (SEDs) und die logische Mandantenisolation über dedizierte virtuelle Speichermaschinen (SVMs).
- Hardwaresicherheitsmodule (HSMs): Dedizierte, mit dem Netzwerk verbundene HSM-Appliances (gemäß FIPS 140-2 Level 3 und FIPS 140-3 validiert) generieren, speichern und schützen kryptografische Root-Schlüssel in manipulationssicherer Hardware.
Weitere Informationen erhalten Sie in dieser Dokumentation:
| Thema | Dokumentation und Konfigurationsanleitungen |
|---|---|
| Hardware- und HSM-Verwaltung | Steuerungsebene-HSM-Schlüssel und Clusterknotenmaschinen |
Host- und Knotensicherheit
Auf jedem Bare-Metal-Host und Kubernetes-Clusterknoten in GDC wird ein gehärtetes Betriebssystem-Image ausgeführt, das so konfiguriert ist, dass die Angriffsfläche minimiert und eine nicht autorisierte Rechteausweitung verhindert wird.
- STIG-gehärtetes Betriebssystem: Auf Knoten wird Linux ausgeführt, das gemäß den Security Technical Implementation Guides (STIGs) der Defense Information Systems Agency (DISA) und den Benchmarks des Center for Internet Security (CIS) gehärtet wurde. Nicht benötigte Pakete, Compiler und Netzwerkdienste werden aus dem Basis-Image entfernt.
- UEFI Secure Boot: Sowohl Bare-Metal-Hosts als auch Nutzer-VMs unterstützen UEFI Secure Boot, um zu prüfen, ob beim Start nur kryptografisch signierte Bootloader und Kernel-Images ausgeführt werden.
- Kernel und obligatorische Zugriffssteuerungen: Knoten erzwingen SELinux im Erzwingungsmodus, seccomp-Systemaufruffilterung, Linux-Namespaces und cgroups-Ressourcenlimits, um Container vom zugrunde liegenden Hostkernel zu isolieren.
- Hostintegrität und Endpunktschutz: Das File Integrity Monitoring (FIM) prüft kritische Systemdateien auf nicht autorisierte Änderungen. Endpoint Detection and Response (EDR) und Anti-Malware-Kontrollen überwachen die Prozessausführung und Host-Telemetrie.
Weitere Informationen erhalten Sie in dieser Dokumentation:
| Thema | Dokumentation und Konfigurationsanleitungen |
|---|---|
| Knotenisolation und Benchmarks | Übersicht über die Knotenisolation und CIS-Kubernetes-Benchmark |
| VM Secure Boot und Betriebssystemverwaltung | VM sicher starten und Betriebssystempakete verwalten |
Mandanten
GDC bietet eine hierarchische Mehrmandantenfähigkeit mit strikter physischer und Netzwerkisolation zwischen Organisationen sowie logischer Namespace-Isolation zwischen Projekten innerhalb einer Organisation.
Logische Isolation über Organisationen, Cluster und Projekte hinweg
Das folgende Diagramm zeigt, wie der Root-Administratorcluster, die Organisationsinfrastrukturcluster und die Arbeitslastcluster über Verwaltungs- und Mandantengrenzen hinweg isoliert sind:
- Root-Administratorcluster: Dediziert für das Bootstrapping von Organisationen, die Verwaltung des Hardwareinventars und die Ausführung von Diensten für Infrastruktursicherheit und Beobachtbarkeit.
- Organisation: die oberste Mandantengrenze. Jede Organisation hat einen eigenen dedizierten Organisationsinfrastrukturcluster, eine eigene Identitätsanbieterkonfiguration, eine eigene KMS-Hierarchie (Key Management System) und eine eigene VRF-Instanz (Virtual Routing and Forwarding).
- Kubernetes-Cluster: Sie können freigegebene Cluster auf Organisationsebene bereitstellen, die mehrere Projekte hosten, oder Standardcluster auf Projektebene, die einem einzelnen Projekt für eine bessere Trennung von Arbeitslasten zugeordnet sind.
- Projekt: Eine logische Mandanteneinheit innerhalb einer Organisation, in der Sie VMs, Container, Datenbanken und Speicherressourcen bereitstellen. Projekte erzwingen die Gleichheit von Kubernetes-Namespaces, Grenzen für die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) und projektbezogene Netzwerkrichtlinien für alle Cluster.
Physische und VRF-Isolation über Racks hinweg
In physischen 42U-Racks isoliert GDC Organisationen auf separaten Rechenservern, virtuellen Speichermaschinen (SVMs) und Netzwerk-VRFs, sodass keine physischen Rechenserver zwischen Organisationen geteilt werden:
Weitere Informationen erhalten Sie in dieser Dokumentation:
| Thema | Dokumentation und Konfigurationsanleitungen |
|---|---|
| Ressourcenhierarchie und Projekte | Ressourcenhierarchie und Projekte verwalten |
| Kubernetes-Cluster | Kubernetes-Cluster in GDC und Clusterkonfigurationen |
| Grenz- und Arbeitslastdesign | Zugriffsgrenzen entwerfen und Arbeitslasttrennung entwerfen |
Anwendungssicherheit
GDC schützt sowohl die Plattformsoftware, die über den Air Gap bereitgestellt wird, als auch die Kundenanwendungen, die in Ihrer Organisation bereitgestellt werden.
Software-Lieferkette und SLSA-Validierung
Alle GDC-Plattformkomponenten, Erstanbieterdienste und verwalteten Drittanbieterdienste werden in isolierten, hermetischen Build-Umgebungen erstellt und auf Sicherheitslücken gescannt. Artefakte werden auf der verbundenen Seite („Low Side“) gemäß den Anforderungen der Supply Chain Levels for Software Artifacts (SLSA) signiert, bevor sie über den Air Gap („High Side“) übertragen werden.
Jeder Release enthält eine Software-Materialliste (Software Bill of Materials, SBOM) mit Details zu Softwarekomponenten, Abhängigkeiten und Bibliotheken. Artefakte werden vor der Bereitstellung mithilfe kryptografischer Signaturen und SHA-256-Prüfsummen verifiziert.
Artifact Registry und Richtlinienerzwingung
GDC erzwingt vor der Bereitstellung Container-Image- und Policy Controller-Kontrollen:
- Lokale Artifact Registry (Harbor): Container-Images und Helm-Diagramme werden in einer lokalen Harbor-Registry in der Air-Gap-Umgebung gespeichert. Dies ermöglicht das Signieren von Images und das Scannen auf Sicherheitslücken ohne externen Internetzugriff.
- Zugangssteuerung und Organisationsrichtlinien: Open Policy Agent (OPA) Gatekeeper erzwingt Organisationsrichtlinien für Kubernetes-Cluster und verhindert, dass Pods mit Rechteausweitung, Host-Netzwerkzugriff oder nicht vertrauenswürdigen Container-Images ausgeführt werden.
Weitere Informationen erhalten Sie in dieser Dokumentation:
| Thema | Dokumentation und Konfigurationsanleitungen |
|---|---|
| Richtlinien und Artifact Registry | Organisationsrichtlinien konfigurieren und Harbor-Ressourcen erstellen und verwalten |
| Arbeitslasten und Dienste | Containerarbeitslasten in GDC und Marketplace-Dienste bereitstellen |
Netzwerksicherheit
GDC erzwingt eine mehrschichtige Netzwerksegmentierung von physischen Switch-Ports bis hin zu Layer-7-Service-Mesh-Richtlinien.
VRF- und VXLAN-Segmentierung auf Datenebene
Die Datenebenen-Fabric verwendet Multiprotokoll-BGP (MP-BGP) Ethernet VPN (EVPN) mit Virtual Extensible LAN (VXLAN)-Kapselung, um den Traffic zwischen dem Root-Administratorcluster und jeder Mandantenorganisation zu isolieren.
- Out-of-Band-Verwaltungsnetzwerk (OOB): Hardwareverwaltungsschnittstellen werden in einem physisch separaten Verwaltungsnetzwerk ausgeführt, das vom Mandanten-Traffic isoliert und nur über den Root-Administratorcluster zugänglich ist.
- VRF- und VXLAN-Isolierung: Jeder Organisation werden dedizierte Layer-3-VNIs (Virtual Network Identifiers), externe und interne VRFs sowie isolierte Storage Virtual Machines (SVMs) zugewiesen, sodass der Mandanten-Traffic ohne explizite Firewall-Durchquerung nicht die Organisationsgrenzen überschreiten kann.
- Firewall der nächsten Generation, IDPS und DoS-Schutz (Denial of Service): Perimeter-Firewalls und Intrusion Detection and Prevention Systems (IDPS) erzwingen eine Standard-Deny-Haltung, prüfen eingehenden und ausgehenden Traffic auf Bedrohungssignaturen und arbeiten mit Load Balancern zusammen, um Sitzungsfluten zu drosseln. Firewall- und IDPS-Logs werden in den Beobachtbarkeits-Stack und das Infrastruktur-Sicherheitsmonitoring der Organisation eingebunden.
- Projekt- und Kubernetes-Netzwerkrichtlinien: Innerhalb einer Organisation können Sie mit
ProjectNetworkPolicy,OrganizationNetworkPolicyund Cilium-gestützten Kubernetes-NetworkPolicy-Ressourcen eine Standard-Ablehnungs-Mikrosegmentierung zwischen Projekten und Pods erzwingen.
Weitere Informationen erhalten Sie in dieser Dokumentation:
| Thema | Dokumentation und Konfigurationsanleitungen |
|---|---|
| Perimeter- und Bedrohungsprävention | Netzwerkübersicht, Anfrage-Bedrohungsabwehr und Kontrolle des ausgehenden Traffics |
| Netzwerkrichtlinien und Flusslogs | Netzwerkrichtlinien für Organisationen, Netzwerkrichtlinien für Projekte, Kubernetes-Netzwerkrichtlinien konfigurieren und Flusslogs verwalten |
| Externe Verbindung | GDC-VPN konfigurieren und Verbindung mit Interconnects herstellen |