Sicherheit

Auf dieser Seite finden Sie einen Überblick über die wichtigsten Konzepte, Ebenen und Betriebsrollen für die Aufrechterhaltung der Sicherheit in Google Distributed Cloud (GDC) Air-Gapped. GDC ist für hochsichere, getrennte Umgebungen und für die Einhaltung strenger Anforderungen an die Datenhoheit konzipiert.

Diese Seite richtet sich an Zielgruppen wie IT-Administratoren in der Gruppe der Infrastrukturbetreiber oder Sicherheitsingenieure in der Gruppe der Anwendungsbetreiber, die die Sicherheit für ihre Organisation verwalten möchten. Weitere Informationen finden Sie unter Zielgruppen für die GDC-Dokumentation für Air-Gap-Umgebungen.

Auf dieser Seite werden die wichtigsten Sicherheitsattribute in den folgenden Kategorien erläutert:

• Compliance
• Sicherheitsvorgänge
• Zuverlässigkeitsvorgänge
• Kryptografie
• Identitäts- und Zugriffsverwaltung
• Netzwerksicherheit
• Anwendungssicherheit
• Host- und Knotensicherheit
• Hardwaresicherheit
• Gebäudesicherheit

Sicherheitsstrategie

GDC verfolgt einen sicherheitsorientierten Ansatz mit mehreren Sicherheitsebenen, um maximale Kontrolle zu bieten, gesetzliche Bestimmungen einzuhalten und vertrauliche Daten zu schützen. Sie ist für die Ausführung auf dedizierter und gesicherter Hardware in einem lokalen Rechenzentrum konzipiert, um eine strikte Mandantenisolation zu gewährleisten.

Die von GDC bereitgestellten Sicherheitsebenen umfassen Hardwaresicherheit, Host- und Knotensicherheit, Anwendungssicherheit, Netzwerksicherheit, Kryptografie, Identity and Access Management (IAM), Sicherheits- und Zuverlässigkeitsvorgänge, Compliance und Sicherheitsangebote.

GDC hat ein Modell der geteilten Verantwortung für die Sicherheit, um den gesamten Anwendungsstack zu schützen. GDC bietet Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS). In allen Konfigurationen von GDC sind Google und der Betreiber für die Sicherheit der Infrastrukturebenen verantwortlich. Der Kunde ist für die Sicherung der Projekteinrichtung und der Anwendungsebene verantwortlich, einschließlich der Anwendungscontainer, Basis-Images und Abhängigkeiten.

Aus Sicherheitssicht sind die folgenden Zielgruppen für GDC zuständig:

• Infrastrukturbetreibergruppe: verwaltet den täglichen Betrieb der Systeminfrastruktur und hat keinen Zugriff auf Kundendaten. Diese Rolle ist der Administrator mit der höchsten Berechtigungsstufe im System. Je nach Art der Souveränitätseinschränkungen kann es sich dabei um Google, einen beauftragten Dritten oder den Kunden handeln.

• Plattformadministratorgruppe: Eine Kundenrolle, die Ressourcen und Berechtigungen für Projekte verwaltet. Dies ist die höchste Ebene der administrativen Berechtigungen, die dem Kunden gewährt werden, und die einzige administrative Ebene, mit der Zugriff auf Kundendaten gewährt werden kann.

• Anwendungsbetreibergruppe: Entwickelt Anwendungen für die Bereitstellung und Ausführung und konfiguriert detaillierte Ressourcen und Berechtigungen in GDC. Diese Rolle arbeitet gemäß den Richtlinien, die vom Plattformadministrator (PA) festgelegt wurden, um sicherzustellen, dass die Systeme den Sicherheits- und Compliance-Anforderungen des Kunden entsprechen.

Weitere Informationen finden Sie unter Zielgruppen für die Dokumentation.

Gebäudesicherheit

Sie können GDC in vom Kunden festgelegten, air-gapped Data Centers bereitstellen. Die standortspezifische physische Sicherheit variiert je nach den individuellen Kundenanforderungen. Zur Einhaltung lokaler Vorschriften benötigen Rechenzentren möglicherweise eine Akkreditierung, z. B. nach ISO 27001. Das Rechenzentrum muss über mehrere Sicherheitsmaßnahmen verfügen, z. B. sichere Perimeterschutzsysteme, um unbefugten Zugriff auf das Rechenzentrum zu verhindern, flächendeckende Kameraüberwachung, um alle Aktivitäten im Rechenzentrum zu überwachen, physische Authentifizierung, um sicherzustellen, dass nur autorisiertes Personal auf das Rechenzentrum zugreifen kann, Wachpersonal, das das Rechenzentrum rund um die Uhr patrouilliert und auf Sicherheitsvorfälle reagiert, sowie strenge Zugangs- und Sicherheitsrichtlinien, um zu regeln, wie Personal auf das Rechenzentrum zugreift und es nutzt. Diese Sicherheitsmaßnahmen sind eine wichtige erste Schutzschicht, um die im Rechenzentrum gespeicherten Daten vor unbefugtem Zugriff sowie unbefugter Nutzung, Offenlegung, Veränderung und Löschung oder Störungen zu schützen.

Hardwaresicherheit

Google hat ein strenges Verfahren, um die Sicherheit seiner Hardware zu gewährleisten. Die gesamte GDC-Hardware wird von Partnern gekauft und zusammengebaut, die geprüft und zertifiziert wurden, um kundenspezifische Anforderungen an Souveränität und Lieferkette zu erfüllen. Die Hardware wird getestet und genehmigt, um die strengen internen Standards von Google und die Anforderungen der meisten sicherheitsbewussten Kunden zu erfüllen. Alle Unterkomponenten in der GDC-Hardware stammen von vertrauenswürdigen Anbietern, die geprüft wurden und als zuverlässig gelten. Die Hardwareintegration in GDC-Racks erfolgt in regionalen zertifizierten Zentren, die von Google für die Verarbeitung sensibler Hardware zugelassen sind. Alle Mitarbeiter, die GDC-Hardware handhaben, werden einer Hintergrundüberprüfung unterzogen. So wird sichergestellt, dass nur autorisiertes Personal Zugriff auf die Hardware hat. Außerdem wird die tatsächliche Implementierung ausgewählter Hardware- und Firmwarekomponenten mit hohem Risiko von einem speziellen Team auf Sicherheit geprüft. Bei diesen Überprüfungen werden Bedrohungen wie Lieferkettenangriffe, physische Angriffe und lokale Ausführungsangriffe auf Hardware- und Firmwarekomponenten berücksichtigt, einschließlich persistenter Bedrohungen. Diese Prüfungen liefern Informationen, die direkt in unsere Hardware-Sicherheitsanforderungen einfließen, einschließlich sicherer Firmware und Firmware-Updates, Firmware-Integrität, Secure Boot, sicherer Verwaltung und Wartung. Google pflegt enge Beziehungen zu allen Anbietern und Teams, die die Hardware verwenden, um sicherzustellen, dass Sicherheitsfunktionen auf höchstem Niveau bereitgestellt werden. Das bedeutet, dass Google ständig mit seinen Partnern zusammenarbeitet, um sicherzustellen, dass die Hardware so sicher wie möglich ist. Google setzt neue Maßstäbe, indem es die Hardware- und Sicherheitsanforderungen verbessert, interaktive Sicherheitsüberprüfungen durchführt und mit Produktteams zusammenarbeitet, um neue Sicherheitsfunktionen zu implementieren, die speziell für GDC entwickelt und nicht nur in die Hardware und Firmware, sondern auch in andere Produktfunktionen integriert sind.

Sicherheit von Host und Knoten

GDC sorgt dafür, dass standardmäßig nur unser speziell verpacktes sicheres Node-Betriebssystem auf die Systeme geladen werden kann. Gehärtete Images und Konfigurationen reduzieren die Angriffsfläche erheblich. Kryptografische Module, die ruhende Daten und Daten bei der Übertragung schützen, sind gemäß FIPS 140-2/3 validiert. Das bedeutet, dass sie von einem unabhängigen, akkreditierten Labor gründlich auf Sicherheit geprüft wurden. GDC bietet Anti-Malware-Software für das Betriebssystem, das auf den Bare-Metal-Knoten ausgeführt wird, und eine Lösung zum Scannen der Speichersysteme. Google stellt Updates für diese Scanner bereit, die in den regulären Systemupdates enthalten sind, die das IO über den GDC-Aktualisierungsprozess anwendet. Erkennungswarnungen werden an den IO gesendet. GDC bietet außerdem Tools zur Integritätsüberwachung und zur Erkennung von Verstößen, um das System vor unbeabsichtigten Änderungen zu schützen. Insgesamt tragen diese Sicherheitsmaßnahmen dazu bei, das System vor einer Vielzahl von Angriffen zu schützen. Die Sicherheitsmaßnahmen erschweren es Angreifern, auf das System zuzugreifen, Sicherheitslücken auszunutzen und Malware zu installieren.

Mandanten

GDC ist eine mandantenfähige, verwaltete Cloud-Plattform, die derGoogle Cloud -Plattform ähnelt. Die Architektur ist so konzipiert, dass eine starke Isolation zwischen Mandanten erreicht wird. Dies bietet eine starke Schutzschicht zwischen Nutzern der Cloud und ermöglicht es Nutzern, strenge Akkreditierungsstandards für Arbeitslasten zu erfüllen. GDC bietet zwei Stufen der Mandantenisolation. Die erste Ebene, „Organizations“, bietet eine starke physische Rechenisolierung. Die zweite Ebene, „Projects“, bietet durch logische Trennung detailliertere Optionen für die Ressourcenbereitstellung.

Es werden keine physischen Rechenserver zwischen Organisationen geteilt und auch die Betreiberebenen sind mandantenfähig. IOs dürfen nicht auf die PA-Ebenen zugreifen. Ebenso können die AOs nicht auf die PA-Ebenen zugreifen.

Anwendungssicherheit

Um sich vor Angriffen auf die Softwarelieferkette zu schützen, wird die gesamte GDC-Software gemäß den Supply Chain Levels for Software Artifacts (SLSA) entwickelt. SLSA ist ein Framework für die Sicherheit der Lieferkette, das Google in Zusammenarbeit mit Organisationen wie der CNCF und der Linux Foundation entwickelt hat.

SLSA ist eine Checkliste mit Standards und Kontrollen, um Manipulationen zu verhindern, die Integrität zu verbessern und Pakete in der Softwarelieferkette zu schützen. Diese Checkliste soll Exploits verhindern, die Quellcode-Repositories, Build-Systeme und Pakete von Drittanbieterabhängigkeiten angreifen.

Der gesamte GDC-Quellcode und alle Abhängigkeiten werden in einem Google-Versionsverwaltungssystem gespeichert, das in sicheren Google-Rechenzentren isoliert und verschlüsselt ist. Der gesamte Code hat einen überprüften Verlauf und erfordert, dass eine zweite Person Codeänderungen überprüft, bevor diese in das Versionskontrollsystem aufgenommen werden.

Builds werden über ein Google-System zur Release-Orchestrierung bereitgestellt, dasGoogle Cloud Build und die automatischen Testtools von Google für einen vollständig automatisierten Build, Test und Release von Container-Images und Binärdateien nutzt. Alle Builds sind isoliert, hermetisch und werden nach dem Prinzip „Build-as-Code“ definiert. Niemand hat einseitigen Zugriff auf den Softwarebereitstellungsprozess.

Alle Bilder werden mit mehreren Scannern für Anwendungssicherheit auf Schwachstellen gescannt und an mehreren Stellen mit einer Kombination aus kryptografischen Signaturen und SHA256-Prüfsummen validiert. Jedes Release enthält eine Software Bill of Materials (SBOM), die Details zu den Softwarekomponenten, Abhängigkeiten und Bibliotheken sowie zu den bereitgestellten Daten enthält.

Netzwerksicherheit

Dieser Abschnitt bietet einen Überblick über die Netzwerksicherheit von GDC.

Physisches Netzwerk

GDC ist zwar für die Verwendung in Umgebungen ohne Verbindung konzipiert, in der Praxis sind GDC-Systeme jedoch wahrscheinlich mit einer größeren geschützten Umgebung verbunden, die über das interne private Netzwerk eines Kunden verbunden ist, während sie weiterhin vom öffentlichen Internet getrennt bleiben.

Der gesamte Netzwerkverkehr zwischen dem privaten Netzwerk des Kunden und den GDC-Systemen wird über Firewalls und IDS/IPS-Systeme (Intrusion Detection & Prevention) geleitet. Die Firewall ist die erste Verteidigungslinie, um den Zugriff auf das System zu steuern. Die Firewall und das IDS/IPS steuern den ein- und ausgehenden Traffic anhand konfigurierbarer Sicherheitsrichtlinien und verwenden maschinelles Lernen, um Traffic automatisch zu analysieren und unbefugten Zugriff zu blockieren. Das IDS/IPS-System prüft standardmäßig die gesamte ein- und ausgehende Kommunikation für die Infrastruktur. PAs können das IDS/IPS-System auch für die Überprüfung des Traffics ihrer eigenen Arbeitslasten verwenden. Sowohl Firewalls als auch IDS/IPS sind in den Observability-Stack der Organisation für Kundenarbeitslasten und den SIEM-Stack des IO für die Infrastruktur integriert, um zusätzliche Sicherheitsanalysen und Forensik zu ermöglichen.

Firewalls erzwingen standardmäßig Ablehnungsregeln als anfängliche Sicherheitsmaßnahme, um unbeabsichtigten Zugriff und Datenlecks zu verhindern. Das IO und das PA haben Methoden, um bei Bedarf weitere Zugriffsregeln zu definieren. Im GDC gibt es zwei physisch getrennte Netzwerke, um die Verwaltungs- und Steuerungsfunktionen von den Arbeitslastdaten der Kunden zu isolieren.

Das Out-of-Band-Management-Netzwerk (OOB) wird ausschließlich für administrative Funktionen wie Konfigurationsänderungen der Netzwerkgeräte, Speicher-Appliances und anderer Hardwarekomponenten verwendet. Nur der IO hat Zugriff auf das OOB-Netzwerk und nur in Ausnahmefällen. Netzwerk-ACLs sind so konfiguriert, dass nur Server im Administrator-Root-Cluster, für die die E/A-Steuerelemente aktiviert sind, Zugriff auf dieses Netzwerk haben. Das Datenebenennetzwerk verbindet die Arbeitslastserver und ist für die PA und die AOs zugänglich.

Softwarebasiertes Netzwerk

Das Datenebenennetzwerk ist ein Overlay-Netzwerk, das auf Virtual Routing and Forwarding (VRF) basiert und den Tenant-Traffic isoliert. Jede Mandantenorganisation hat ein externes und ein internes VRF-Netzwerk. Die nach außen gerichteten Dienste, z. B. der externe Load-Balancer und das Egress-NAT, befinden sich in der externen Domain. Kundenarbeitslasten befinden sich im internen VRF.

Das interne Netzwerk wird für die Kommunikation innerhalb des Mandanten verwendet, z. B. für den Arbeitslast-Traffic zwischen Knoten und zu Datei- und Blockspeicher innerhalb der Organisation. Das externe Netzwerk wird für die Kommunikation außerhalb einer Organisation verwendet. Tenant-Verwaltungstraffic für den Zugriff auf Zugriffssteuerungsfunktionen oder Kundentraffic für den Zugriff auf Projekte muss über das externe Netzwerk erfolgen. Für jede Kundenarbeitslast müssen Load-Balancer und NAT-Gateways für eingehenden und ausgehenden Traffic konfiguriert werden.

Virtuelles Netzwerk

Das virtuelle Netzwerk von GDC ist eine Netzwerkebene auf Organisationsebene, die auf dem Overlay-Netzwerk basiert. Es basiert auf dem von GDC verwalteten CNI-Treiber (Container Network Interface) – der Anthos-Netzwerkdatenebene.

Die virtuelle Netzwerkschicht in GDC bietet eine Soft-Isolation innerhalb der Organisation, die als „Projekt“ bezeichnet wird. Diese Ebene bietet die folgenden Netzwerksicherheitsfunktionen:

• Projektnetzwerkrichtlinie: zum Schutz der Projektgrenzen.
• Netzwerkrichtlinie für Organisationen: zum Schutz der Organisationsgrenzen.

Die Netzwerkrichtlinien für Projekte und Organisationen haben standardmäßig die Konfiguration „Standardmäßig ablehnen“, um vor unbeabsichtigtem Zugriff und Datenlecks zu schützen.

Schutz vor DoS-Angriffen

Der gesamte Traffic, der in GDC eingeht, wird über das IDS/IPS und eine Reihe von Load-Balancern geleitet. Das IDS/IPS erkennt und blockiert nicht autorisierten Traffic und schützt Ressourcen vor Session-Floods. Die Load-Balancer können den Traffic entsprechend drosseln, um einen Dienstausfall zu vermeiden. Da alle externen Verbindungen über das private Netzwerk des Kunden abgewickelt werden, kann der Kunde eine zusätzliche Schutzebene vor Denial-of-Service-Angriffen für verteilte Angriffe bereitstellen.

Kryptografie

In diesem Abschnitt finden Sie einen Überblick über die GDC-Kryptografie.

PKI

GDC bietet eine Public-Key-Infrastruktur (PKI) für die zentrale X.509-CA-Verwaltung für Infrastrukturdienste. Standardmäßig hat GDC private Stamm-CAs pro Installation und davon abgeleitete Zwischen- und Blattzertifikate. Außerdem können mit GDC kundeneigene Zertifikate an kundenorientierten Endpunkten installiert werden, was die Flexibilität bei der Verwendung von Zertifikaten erhöht. GDC koordiniert zentral die Verteilung von Trust Stores, was die Authentifizierung und Verschlüsselung des Anwendungs-Traffics für Arbeitslasten und Systemdienste erleichtert. Insgesamt bietet GDC eine leistungsstarke PKI-Lösung zur Sicherung einer Vielzahl von Infrastrukturdiensten für eine bequeme, aber streng kontrollierte Vertrauensverwaltung.

Key Management Service

GDC bietet einen Key Management Service (KMS), der durch Hardwaresicherheitsmodule (HSMs) gesichert wird. Der KMS ist ein Dienst von Google. Das Schlüsselmaterial verbleibt im KMS, das wiederum durch HSMs gesichert wird. Benutzerdefinierte Ressourcendefinitionen (CRDs) enthalten verschlüsseltes Schlüsselmaterial. Nur der KMS hat Zugriff auf das Rohschlüsselmaterial im Arbeitsspeicher. Es gibt einen KMS pro Organisation. Alle inaktiven Daten werden standardmäßig mit HSM-gestützten Schlüsseln verschlüsselt. Kunden können auch ihre eigenen kryptografischen Schlüssel verwalten. Das KMS unterstützt FIPS-genehmigte Algorithmen und FIPS-validierte Module. Der KMS unterstützt den sicheren Import und Export von Schlüsseln für die Hinterlegung, das Löschen oder die Notfallwiederherstellung. Diese Funktionen machen KMS zu einer sicheren und zuverlässigen Methode zum Verwalten kryptografischer Schlüssel.

GDC bietet auch vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK). Mit CMEK haben Kunden die Kontrolle über die Schlüssel, die ihre inaktiven Daten in GDC schützen. Einer der Hauptgründe für die Einführung von CMEK ist das kryptografische Löschen, eine Methode zum sicheren Vernichten von Daten zur Behebung von Datenlecks und zur Offboarding-Verwaltung. Schlüssel können unabhängig von den Daten gelöscht werden, die sie schützen. Alle Daten in Ihrer Organisation sind durch eine Reihe von CMEKs geschützt, die Ihre Plattformadministratoren nach Bedarf überwachen, prüfen und löschen können. CMEK-Schlüssel sind Verschlüsselungsschlüssel, die Sie mit HSM-APIs verwalten können. CMEK kann zum Verschlüsseln der Daten für Blockspeicher, VM-Laufwerke, Datenbankdienste und Nutzercontainer-Arbeitslasten verwendet werden.

Verschlüsselung

In diesem Abschnitt finden Sie eine Übersicht über die GDC-Verschlüsselung.

Ruhende Daten

Alle GDC-Daten, die in Datei-, Block- und Objektspeicher gespeichert werden, werden im inaktiven Zustand mit mehreren Verschlüsselungsebenen verschlüsselt. In Multi-Tenant-Umgebungen werden die Daten jedes Mandanten mit einem mandantenspezifischen Schlüssel verschlüsselt, bevor sie in Datei-, Block- und Objektspeicher geschrieben werden:

• Blockspeicher (Anwendungsvolumes, VM-Laufwerke, Datenbankspeicher) wird auf drei Ebenen verschlüsselt:
  • Softwareebene: LUKS-Verschlüsselung (Linux Unified Key Setup), die auf mandantenspezifischer Rechenhardware mit HSM-gestützten Schlüsseln pro Volume ausgeführt wird, die vom Kunden verwaltet werden.
  • Appliance-Ebene: Verschlüsselung auf Volume-Aggregate-Ebene (NVE/NAE), die in der Storage Appliance mit mandantenspezifischen, HSM-gestützten Schlüsseln durchgeführt wird, die vom Kunden verwaltet werden.
  • Festplattenebene: Selbstverschlüsselnde Laufwerke (Self-Encrypting Drives, SEDs) mit HSM-gestützten Schlüsseln pro Laufwerk, die vom IO verwaltet werden.
• Objektspeicher wird auf zwei Ebenen verschlüsselt.
  • Bucket-Ebene: Die Verschlüsselung von Objektdaten wird innerhalb von mandantenspezifischer Rechenhardware mit HSM-gestützten Schlüsseln pro Bucket koordiniert, die vom Kunden verwaltet werden.
  • Festplattenebene: SEDs mit HSM-gesicherten Schlüsseln pro Laufwerk, die vom IO verwaltet werden.
• Der Festplattenspeicher des Servers, die Systemkonfigurationsdaten für einen einzelnen Mandanten, wird auf einer Ebene verschlüsselt:
  • Laufwerksebene: SEDs mit HSM-gestützten Schlüsseln pro Laufwerk, die vom Kunden verwaltet werden.

Daten während der Übertragung

Der gesamte GDC-Traffic wird standardmäßig mit FIPS 140-2-zertifizierten Verschlüsselungsmodulen und Branchenstandardprotokollen wie TLS 1.2+, HTTPS und IPSec-Tunneln verschlüsselt. Gemäß dem Modell der geteilten Verantwortung wird von Kunden auch erwartet, dass sie verschlüsselte Algorithmen auf der Anwendungsebene verwenden, um sicherzustellen, dass die Verschlüsselungsanforderungen für alle Anwendungen erfüllt werden, die auf GDC bereitgestellt werden.

Identity and Access Management (IAM)

Der Zugriff auf das System basiert auf dem Prinzip der geringsten Berechtigung. Nutzer erhalten nur Zugriff auf die Ressourcen, die sie benötigen. Dieser Prozess schützt das System vor unbefugtem Zugriff und Missbrauch. Außerdem wird die Funktionstrennung durch das System erzwungen, z. B. kein einseitiger Zugriff. Niemand hat die vollständige Kontrolle über ein einzelnes System oder einen einzelnen Prozess. So können wir Betrug und Fehler vermeiden. GDC kann in den vorhandenen Identitätsanbieter von Kunden eingebunden werden. Das System unterstützt SAML 2.0 und OIDC für die IdP-Föderation. So können Nutzer die Nutzer im System mit ihrem vorhandenen Identitätsanbieter authentifizieren und Nutzer an einem Ort verwalten. Alle Nutzer und Arbeitslasten werden authentifiziert, bevor sie auf das System zugreifen. RBAC und ABAC werden verwendet, um alle Zugriffe auf die Steuerungsebene und Daten zu autorisieren. Nutzer dürfen nur dann auf die Ressourcen zugreifen und Aktionen ausführen, wenn sie authentifiziert und autorisiert sind. Alle Zugriffe werden in Audit-Logs protokolliert, sodass Administratoren nachvollziehen können, wer wann auf eine Ressource zugegriffen hat. So lassen sich unbefugter Zugriff und Missbrauch erkennen.

Sicherheitsabläufe

GDC SecOps bietet Informationssicherheit für Organisationen mit strengen Sicherheits-, Compliance- und Souveränitätsanforderungen, um maximale betriebliche Vertraulichkeit, Integrität und Verfügbarkeit von regulierten, durch Air Gap geschützten Kundenarbeitslasten zu gewährleisten. Diese Sicherheitsarchitektur soll die folgenden Ziele erreichen:

• GDC-Plattform-Logging für Sicherheitsanalysen und ‑reaktionen korrelieren.
• Sicherheitslücken schnell erkennen, melden und nachverfolgen
• Alle OIC- und GDC-Assets mit Endpoint Detection & Response (EDR) schützen.
• Stellen Sie Tools, Prozesse und Runbooks bereit, damit das SecOps-Operationscenter kontinuierlich überwachen kann, um Cybersicherheitsvorfälle zu erkennen, einzudämmen, zu beseitigen und zu beheben.

Funktion	Beschreibung
Security Information & Event Management	Splunk Enterprise ist eine Plattform für die Informations- und Ereignisverwaltung (SIEM, Security Information and Event Management), die Sicherheitsdaten aus verschiedenen Quellen erfasst, indexiert und analysiert, um Organisationen bei der Erkennung und Reaktion auf Bedrohungen zu unterstützen.
Handhabung von Sicherheitslücken	Tenable Security Center ist eine Plattform für das Management von Sicherheitslücken, mit der Unternehmen Sicherheitslücken erkennen und beheben können.
Endpoint Detection & Response	Trellix HX, Windows Defender und ClamAV. Einheitliche Sicherheitsplattformen, die Unternehmen einen umfassenden Überblick über ihre Sicherheitslage bieten, um Bedrohungen effektiver zu erkennen und darauf zu reagieren.
Secure Case Management	Eine Softwarelösung, mit der Organisationen den Lebenszyklus von Sicherheitsvorfällen verwalten können.

GDC SecOps ermöglicht es IOs, Security Operations-Funktionen bereitzustellen. Das GDC SecOps-Team bietet menschenorientierte Prozesse, darunter Incident Response, Vulnerability Management, Security Engineering und Supply Chain Risk Management. GDC SecOps bietet einem Security Operations Center (SOC) folgende Möglichkeiten:

Leistungsvermögen	Beschreibung
Erkennung	Unsere Sicherheitsinfrastruktur überwacht ständig potenzielle Bedrohungen und Sicherheitslücken. Wenn eine Bedrohung oder Sicherheitslücke erkannt wird, erhält das Security Operations-Team sofort einen Bericht.
Triage	Das Security Operations-Team priorisiert jeden Vorfall, um den Schweregrad der Bedrohung und die angemessene Reaktion zu ermitteln.
Eindämmung	Das Security Operations-Team ergreift Maßnahmen, um die Bedrohung einzudämmen und eine Ausbreitung zu verhindern.
Prüfung	Das Sicherheitsteam untersucht den Vorfall, um die Ursache zu ermitteln und Schwachstellen in unserem Sicherheitsstatus zu identifizieren.
Antwort	Das Sicherheitsteam ergreift Maßnahmen, um auf den Vorfall zu reagieren und alle entstandenen Schäden zu beheben.
Wiederherstellung	Das Security Operations-Team ergreift Maßnahmen, um den Vorfall zu beheben und unsere Systeme und Netzwerke wieder in ihren normalen Zustand zu versetzen.

Sicherheitslückenverwaltung

GDC führt in der Vorproduktionsumgebung mehrere Prozesse zur Identifizierung von Sicherheitslücken durch, bevor eine Version veröffentlicht wird, um potenzielle Common Vulnerabilities and Exposures (CVEs) zu erkennen. GDC bietet auch das Scannen der Produktionsumgebung auf Sicherheitslücken für routinemäßige Monitoring- und Berichterstellungszwecke. Alle Ergebnisse in der Produktionsumgebung werden in Security Operations-Prozesse integriert, um Bedrohungen zu erkennen und zu minimieren.

Reaktion auf Sicherheitsvorfälle

Wenn in Code, der in GDC bereitgestellt wird, Sicherheitslücken entdeckt werden oder ein Vorfall im System auftritt, stehen eine Reihe von Prozessen zur Reaktion auf Vorfälle zur Verfügung, die vom IO und dem GDC-Sicherheitsteam ausgeführt werden, um Sicherheitslücken zu beheben, Sicherheitspatches zu erstellen und anzuwenden und betroffene Parteien zu informieren. Dieser Prozess für das Vorfallmanagement entspricht dem Standardprozess von Google für das Vorfallmanagement, wurde jedoch an die nicht verbundene Natur von GDC angepasst.

Für jedes entdeckte CVE oder jeden entdeckten Vorfall wird ein Incident Commander (IC) zugewiesen, der den Reaktionsprozess durchführt. Der IC ist für die Verwaltung des Prozesses verantwortlich, einschließlich der Überprüfung und Validierung des Vorfalls, der Zuweisung einer CVSS-Bewertung (Common Vulnerability Scoring System) für die Sicherheitslücke, der Verwaltung des Prozesses zur Erstellung und Bereitstellung eines Patches sowie der Erstellung der entsprechenden Mitteilungen.

Zuverlässigkeitsvorgänge

Dieser Abschnitt bietet einen Überblick über die Zuverlässigkeitsvorgänge von GDC.

Logging und Monitoring

GDC wird mit einer Observability-Plattform ausgeliefert, die Funktionen für Monitoring, Logging, Tracing und Berichterstellung für die GDC-Plattform, ‑Dienste und ‑Arbeitslasten bietet.

Das Logging-Subsystem erfasst und aggregiert Logs von allen wichtigen GDC-Plattformen und ‑Diensten sowie Kundenarbeitslasten in einer Zeitreihendatenbank und stellt diese Daten über eine interaktive Benutzeroberfläche und APIs zur Verfügung.

Kritische Audit-Log-Ereignisse umfassen die folgenden Bereiche:

• Anfragen zur Nutzerauthentifizierung und ‑autorisierung.
• Generierung und Widerruf von Authentifizierungstokens.
• Alle administrativen Zugriffe und Änderungen.
• Alle API-Aktionen der Steuerungsebene.
• Alle Sicherheitsereignisse, einschließlich IDS, IPS, Firewall und Antivirus.

Ausnahmezugriff

Die E/A hat keinen Zugriff auf Kundendaten. In Notsituationen kann es jedoch vorkommen, dass der IO Zugriff auf Kundendaten benötigt. In diesen Fällen hat GDC eine Reihe von Notfallzugriffsverfahren, mit denen ein PA den Zugriff auf die IO zur Fehlerbehebung explizit gewährt.

Alle Breakglass-Anmeldedaten werden entweder offline in einem Safe gespeichert oder mit Schlüsseln verschlüsselt, die im HSM verwurzelt sind. Der Zugriff auf diese Anmeldedaten ist ein prüfbares Ereignis, das Benachrichtigungen auslösen kann.

Wenn beispielsweise die IAM-Konfiguration beschädigt ist und den Nutzerzugriff verhindert, verwendet der IO eine auf SSH-Zertifikaten basierende Authentifizierung über sichere Arbeitsstationen und erfordert die Genehmigung mehrerer Parteien, um den Zugriff zu ermöglichen. Alle ergriffenen Maßnahmen werden nachverfolgt und können geprüft werden. Die SSH-Schlüssel ändern sich nach einem Notfallzugriff.

Notfallwiederherstellung

GDC wird mit einem Sicherungssystem ausgeliefert, mit dem PAs Sicherungsrichtlinien für Cluster, Namespaces oder VMs erstellen und verwalten können. Das Sicherungssystem umfasst die typischen Systeme für die Planung, Ausführung von Sicherungen, Wiederherstellung von Daten und Berichterstellung.

System aktualisieren und upgraden

Da GDC eine Air-Gap-Umgebung ist, verarbeitet der Infrastruktur-Operator alle Updates für Kundensysteme. Google signiert und veröffentlicht binäre Updates an einem sicheren Ort, damit das IO sie herunterladen kann. Der IO validiert die Binärdateien und verschiebt sie zur Verteilung und Bereitstellung in GDC.

Dieses System umfasst alle Software- und Firmware-Updates, einschließlich Updates für die GDC-Software, das Betriebssystem auf Knotenebene, Antiviren- und Antimalware-Definitionen und ‑Signaturen, Speicher- und Netzwerkgeräte, Geräteupdates und alle anderen binären Updates.

Change Management – Infrastruktur als Code

GDC verwendet Infrastructure as Code (IaC), um die Bereitstellung und das Deployment von GDC-Konfigurationen zu automatisieren. Mit IaC werden die Zuständigkeiten des Infrastruktur-Betriebsteams aufgeteilt. Beispielsweise kann eine Konfigurationsänderung vorgeschlagen, aber nicht autorisiert werden, um den gesamten Prozess sicherer zu machen. Mit GDC IAC werden alle Konfigurationsänderungen durch Prüf- und Genehmigungsprozesse durch mehrere Parteien validiert, um sicherzustellen, dass nur autorisierte Konfigurationen bereitgestellt werden. Diese Überprüfungen schaffen einen transparenten und prüfbaren Prozess, verbessern die Konsistenz von Änderungen und reduzieren die Konfigurationsabweichung.

Compliance-Prozesse

GDC ist für gängige Compliance-Anforderungen wie NIST 800-53 und SOC 2 vorbereitet und unterstützt Zertifizierungen wie FIPS 140-2 und 3. GDC durchläuft außerdem verschiedene Zertifizierungsverfahren und erfüllt die Sicherheitsstandards von Google. Compliance ist ein kontinuierlicher Prozess. Um Kunden und Betreibern auf diesem Weg zu helfen, bietet GDC kontinuierliche Überwachung und Tests. Im Rahmen der Sicherheitsverfahren für den Prozess der kontinuierlichen Überwachung verfolgt GDC Inventaränderungen wie unbekannte Software und Hardware oder das Hinzufügen neuer Software oder Hardware. GDC führt regelmäßig Penetrationstests durch, bei denen Angriffe von böswilligen Akteuren simuliert werden. GDC scannt die Systeme regelmäßig auf Malware und benachrichtigt GDC bei Infektionen. Beim Test zur Notfallwiederherstellung wird geprüft, ob GDC in der Lage ist, sich von einer Notsituation zu erholen. Diese Prozesse sorgen dafür, dass GDC-Daten und ‑Systeme sicher sind.