Sicherheit

Dieses Dokument bietet einen Überblick über die wichtigsten Konzepte, Ebenen und Betriebsrollen für die Aufrechterhaltung der Sicherheit in Google Distributed Cloud (GDC) mit Air Gap. GDC ist für hochsichere, nicht verbundene Umgebungen und für die Einhaltung strenger Anforderungen an die Datenhoheit konzipiert.

Dieses Dokument richtet sich an Zielgruppen innerhalb der Gruppe der Infrastrukturoperatoren, der Gruppe der Plattformadministratoren und der Gruppe der Anwendungsoperatoren, die die Sicherheit für ihre Organisation verwalten. Weitere Informationen finden Sie unter Zielgruppen für die Dokumentation zu GDC mit Air Gap.

In diesem Dokument werden die wichtigsten Sicherheitsattribute in den folgenden Kategorien erläutert:

Sicherheitsstrategie

GDC verfolgt einen sicherheitsorientierten Ansatz mit mehreren Sicherheitsebenen, um maximale Kontrolle zu bieten, gesetzliche Vorschriften 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 gemeinsames Sicherheitsmodell zum Sichern des gesamten Anwendungsstacks. 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 Sicherung 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.

Ein Histogramm, das die gemeinsame Verantwortung von Cloud, Betreiber und Kunden für jede Sicherheitsebene veranschaulicht.

Aus Sicherheitsperspektive wird GDC von den folgenden Zielgruppen betrieben:

  • Infrastrukturbetreibergruppe: Verwaltet den täglichen Betrieb der Systeminfrastruktur und hat keinen Zugriff auf Kundendaten. Diese Persona ist der Administrator der höchsten Ebene des Systems und kann je nach Art der Souveränitätseinschränkungen Google, ein beauftragter Drittanbieter oder der Kunde sein.

  • Plattformadministratorgruppe: Eine Kundenidentität, die Ressourcen und Berechtigungen für Projekte verwaltet. Dies ist die höchste Ebene der Administratorberechtigungen, die dem Kunden gewährt wird, und die einzige Administratorebene, die Zugriff auf Kundendaten gewähren kann.

  • Anwendungsoperatorgruppe: Entwickelt Anwendungen für die Bereitstellung und Ausführung und konfiguriert detaillierte Ressourcen und Berechtigungen in GDC. Diese Persona arbeitet im Rahmen der vom Plattformadministrator (PA) festgelegten Richtlinien, 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 Rechenzentren mit Air Gap bereitstellen. Die standortspezifische physische Sicherheit variiert je nach den individuellen Kundenanforderungen. Zur Einhaltung lokaler Vorschriften benötigen Rechenzentren möglicherweise eine Akkreditierung, z. B. ISO 27001. Das Rechenzentrum muss mehrere Sicherheitsmaßnahmen ergreifen, z. B. sichere Perimeter-Abwehrsysteme, um unbefugten Zugriff auf das Rechenzentrum zu verhindern, umfassende Kameraabdeckung, 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 an allen sieben Tagen patrouilliert und auf Sicherheitsvorfälle reagiert, strenge Zugriffs- und Sicherheitsrichtlinien, um zu regeln, wie Personal auf das Rechenzentrum zugreift und es nutzt. Diese Sicherheitsmaßnahmen sind eine wichtige erste Schutzebene, 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 erworben und zusammengestellt, 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 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. Dies sind Einrichtungen, die von Google für den Umgang mit sensibler Hardware zugelassen wurden. Alle Mitarbeiter, die mit GDC-Hardware umgehen, werden einer Zuverlässigkeitsüberprüfung unterzogen. So wird sichergestellt, dass nur autorisiertes Personal Zugriff auf die Hardware hat. Darüber hinaus wird die tatsächliche Implementierung ausgewählter Hardware- und Firmwarekomponenten mit hohem Risiko von einem dedizierten Team auf Sicherheit überprüft. Dabei werden Bedrohungen wie Angriffe auf die Lieferkette, physische Angriffe und Angriffe auf die lokale Ausführung von Hardware- und Firmwarekomponenten berücksichtigt, einschließlich persistenter Bedrohungen. Diese Prüfungen liefern Erkenntnisse, die direkt in unsere Anforderungen an die Hardwaresicherheit 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 erstklassige Sicherheitsfunktionen bereitgestellt werden. Das bedeutet, dass Google ständig mit seinen Partnern zusammenarbeitet, um die Hardware so sicher wie möglich zu machen. Google setzt neue Maßstäbe, indem es die Hardware- und Sicherheitsanforderungen verbessert, interaktive Sicherheitsprüfungen durchführt und mit Produktteams zusammenarbeitet, um neue Sicherheitsfunktionen zu implementieren, die speziell für die GDC entwickelt wurden und nicht nur tief in die eigentliche Hardware und Firmware, sondern auch in andere Produktfunktionen integriert sind.

Host- und Knotensicherheit

GDC sorgt dafür, dass standardmäßig nur unser benutzerdefiniertes, sicheres Knotenbetriebssystem auf die Systeme geladen werden kann. Gehärtete Images und Konfigurationen reduzieren die Angriffsfläche erheblich. Kryptografische Module, die ruhende Daten und Daten während der Übertragung schützen, sind gemäß FIPS 140-2/3 validiert. Das bedeutet, dass sie von einem unabhängigen, akkreditierten Labor streng 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. Sie sind in den regulären Systemupdates enthalten, die der IO im Rahmen des GDC-Upgradevorgangs anwendet. Erkennungswarnungen werden an den IO gesendet. GDC bietet außerdem Tools für das Integritätsmonitoring und die 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 mehrmandantenfähige verwaltete Cloud-Plattform, die derGoogle Cloud -Plattform ähnelt. Die Architektur ist so konzipiert, dass sie eine starke Isolation zwischen Mandanten bietet, eine starke Schutzebene zwischen Nutzern der Cloud bietet und es Nutzern ermöglicht, strenge Akkreditierungsstandards für Arbeitslasten zu erfüllen. GDC bietet zwei Stufen der Mandantenisolation. Die erste Ebene, „Organisationen“, bietet eine starke physische Rechenisolation. Die zweite Ebene, „Projekte“, bietet durch logische Trennung detailliertere Optionen für die Ressourcenzuweisung.

Ein Diagramm eines GDC-Root-Administratorclusters mit zwei Organisationsclustern und Nutzerclustern.

Es werden keine physischen Rechenserver zwischen Organisationen geteilt und die Mandantenfähigkeit wird auch auf den Operatorebenen beibehalten. IOs dürfen nicht auf die PA-Ebenen zugreifen. Ebenso können die AOs nicht auf die PA-Ebenen zugreifen.

Die Ebenen des GDC Storage Appliance-Operators.

Anwendungssicherheit

Zum Schutz vor Angriffen auf die Softwarelieferkette wird die gesamte GDC-Software gemäß den Supply Chain Levels for Software Artifacts (SLSA) entwickelt. Dies ist ein Sicherheitsframework für die 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 sichern. 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 Versionsverwaltungssystem von Google gespeichert, das in sicheren Google-Rechenzentren isoliert und verschlüsselt ist. Der gesamte Code hat einen verifizierten Verlauf und erfordert, dass eine zweite Person Codeänderungen prüft, bevor diese Änderungen in das Versionsverwaltungssystem übernommen werden.

Builds werden über ein Google-Release-Orchestrierungssystem bereitgestellt, dasGoogle Cloud Build und automatisierte 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 Build-as-Code-Prinzip definiert. Keine Einzelperson hat einseitigen Zugriff auf den Softwarebereitstellungsprozess.

Alle Images werden mit mehreren Anwendungssicherheitsscannern auf Sicherheitslücken geprüft und an mehreren Stellen mit einer Kombination aus kryptografischen Signaturen und SHA256-Prüfsummen validiert. Jeder Release enthält eine Software-Materialliste (Software Bill of Materials, SBOM) mit Details zu den Softwarekomponenten, Abhängigkeiten und Bibliotheken sowie den bereitgestellten Daten.

Netzwerksicherheit

In diesem Abschnitt erhalten Sie einen Überblick über die GDC-Netzwerksicherheit.

Physisches Netzwerk

GDC ist für die Verwendung in Umgebungen ohne Internetverbindung 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, aber weiterhin vom öffentlichen Internet getrennt ist.

Der gesamte Netzwerkverkehr zwischen dem privaten Netzwerk des Kunden und den GDC-Systemen wird über Firewalls und Intrusion Detection & Prevention-Systeme (IDS/IPS) geleitet. Die Firewall ist die erste Verteidigungslinie, um den Zugriff auf das System zu kontrollieren. Die Firewall und das IDS/IPS steuern den eingehenden und ausgehenden Traffic anhand konfigurierbarer Sicherheitsrichtlinien und analysieren den Traffic mithilfe von maschinellem Lernen automatisch, um unbefugten Zugriff zu blockieren. Das IDS/IPS-System prüft standardmäßig die gesamte eingehende und ausgehende Kommunikation für die Infrastruktur. PAs können das IDS/IPS-System auch für die eigene Prüfung des Arbeitslast-Traffics 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 eingebunden, um zusätzliche Sicherheitsanalysen und Forensik zu ermöglichen.

Firewalls erzwingen standardmäßige Ablehnungsregeln als anfänglichen Sicherheitsstatus, um unbeabsichtigten Zugriff und Datenlecks zu verhindern. Die IO und PA haben Methoden, um bei Bedarf weitere Zugriffsregeln zu definieren. In GDC gibt es zwei physisch getrennte Netzwerke, um die Verwaltungs- und Steuerungsfunktionen von den Arbeitslastdaten der Kunden zu isolieren.

Das Out-of-Bound-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 die Server im Root-Administratorcluster, die die IO steuern, Zugriff auf dieses Netzwerk haben. Das Netzwerk der Datenebene verbindet die Arbeitslastserver miteinander und ist für den PA und die AOs zugänglich.

Softwarebasiertes Netzwerk

Das Netzwerk der Datenebene ist ein Overlay-Netzwerk, das auf Virtual Routing and Forwarding (VRF) zur Isolierung des Mandanten-Traffics basiert. Jede Mandantenorganisation hat ein externes und ein internes VRF-Netzwerk. Die externen Dienste, z. B. der externe Load Balancer und die ausgehende NAT, befinden sich in der externen Domain. Kundenarbeitslasten befinden sich in der internen VRF.

Das interne Netzwerk wird für die Kommunikation innerhalb des Mandanten verwendet, z. B. für 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. Der Traffic für die Mandantenverwaltung für den Zugriff auf Zugriffssteuerungsfunktionen oder der Kundentraffic für den Zugriff auf Projekte muss über das externe Netzwerk geleitet werden. Für jede Kundenarbeitslast müssen Load Balancer und NAT-Gateways für eingehenden und ausgehenden Traffic konfiguriert werden.

Virtuelles Netzwerk

Das GDC Virtual-Netzwerk ist eine Netzwerkschicht auf Organisationsebene, die auf dem Overlay-Netzwerk aufbaut. Sie wird vom CNI-Treiber (Container Network Interface) von GDC Managed – Anthos-Netzwerkdatenebene – unterstützt.

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

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

Die Projektnetzwerk- und Organisationsnetzwerkrichtlinien haben als Ausgangspunkt eine Standardkonfiguration, die den Zugriff verweigert, um vor unbeabsichtigtem Zugriff und Datenlecks zu schützen.

Schutz vor Denial-of-Service-Angriffen

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

Kryptografie

In diesem Abschnitt erhalten 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 verfügt GDC über private Stamm-CAs pro Installation sowie über Zwischen- und Blattzertifikate, die von diesen verteilt werden. Darüber hinaus kann GDC die Installation von vom Kunden ausgestellten Zertifikaten an kundenorientierten Endpunkten unterstützen, was die Flexibilität bei der Verwendung von Zertifikaten erhöht. GDC koordiniert die Verteilung von Trust Stores zentral, was die Authentifizierung und Verschlüsselung des Anwendungstraffics für Arbeitslasten und Systemdienste vereinfacht. Insgesamt bietet GDC eine leistungsstarke PKI-Lösung zum Sichern einer Vielzahl von Infrastrukturdiensten für eine bequeme, aber streng kontrollierte Vertrauensverwaltung.

Key Management Service

GDC bietet einen Key Management Service (KMS), der von Hardwaresicherheitsmodulen (HSMs) unterstützt wird. Der KMS ist ein eigener Dienst. Das Schlüsselmaterial verbleibt im KMS, der wiederum durch HSMs gesichert ist. Benutzerdefinierte Ressourcendefinitionen (CRDs) enthalten verschlüsseltes Schlüsselmaterial. Nur der KMS hat Zugriff auf das Rohschlüsselmaterial im Arbeitsspeicher. Pro Organisation gibt es ein KMS. 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 von FIPS genehmigte Algorithmen und von FIPS validierte Module. Das KMS unterstützt den sicheren Import und Export von Schlüsseln für die treuhänderische Schlüsselaufbewahrung, das Löschen von Schlüsseln oder die Notfallwiederherstellung. Diese Funktionen machen KMS zu einer sicheren und zuverlässigen Methode zur Verwaltung kryptografischer Schlüssel.

GDC bietet auch kundenverwaltete Verschlüsselungsschlüssel (CMEK) an. Mit CMEK haben Kunden die Kontrolle über die Schlüssel, die ihre ruhenden Daten in GDC schützen. Einer der Hauptgründe für die Einführung von CMEK ist die kryptografische Löschung, eine Methode zur Datenvernichtung mit hoher Sicherheit für die Behebung von Datenlecks und das Offboarding. Schlüssel können unabhängig von den Daten, die sie schützen, gelöscht werden. Alle Daten in Ihrer Organisation werden durch einen Satz von CMEKs geschützt, die Ihre Plattformoperatoren 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. Mit CMEK können die Daten für Blockspeicher, Laufwerke virtueller Maschinen, Datenbankdienste und Nutzercontainer-Arbeitslasten verschlüsselt werden.

Verschlüsselung

In diesem Abschnitt erhalten Sie einen Überblick über die GDC-Verschlüsselung.

Ruhende Daten

Alle GDC-Daten, die im Datei-, Block- und Objektspeicher gespeichert sind, werden im Ruhezustand mit mehreren Verschlüsselungsebenen verschlüsselt. In mandantenfähigen 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) auf mandantenspezifischer Compute-Hardware mit HSM-gestützten Schlüsseln pro Volume, die vom Kunden verwaltet werden.
    • Appliance-Ebene: Verschlüsselung auf Volume-Aggregat-Ebene (NVE/NAE) innerhalb der Storage Appliance mit mandantenspezifischen, HSM-gestützten Schlüsseln, die vom Kunden verwaltet werden.
    • Laufwerksebene: Selbstverschlüsselnde Laufwerke (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 der mandantenspezifischen Compute-Hardware mit HSM-gestützten Schlüsseln pro Bucket koordiniert, die vom Kunden verwaltet werden.
    • Laufwerksebene: SEDs mit HSM-gestützten Schlüsseln pro Laufwerk, die vom IO verwaltet werden.
  • Serverlaufwerkspeicher, die Systemkonfigurationsdaten für einen einzelnen Mandanten, werden auf einer Ebene verschlüsselt:
    • Laufwerksebene: SEDs mit HSM-gestützten Schlüsseln pro Laufwerk, die vom Kunden verwaltet werden.

Daten bei der Übertragung

Der gesamte GDC-Traffic wird standardmäßig mit gemäß FIPS 140-2 zertifizierten kryptografischen Modulen und Branchenstandardprotokollen wie TLS 1.2+, HTTPS und IPSec-Tunneln verschlüsselt. Kunden müssen außerdem gemäß dem Modell der gemeinsamen Verantwortung Verschlüsselungsalgorithmen auf der Anwendungsebene verwenden, um sicherzustellen, dass die Verschlüsselungsanforderungen für alle auf GDC bereitgestellten Anwendungen erfüllt 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. Darüber hinaus erzwingt das System eine Aufgabentrennung, z. B. keinen einseitigen Zugriff. Keine einzelne Person hat die vollständige Kontrolle über ein System oder einen Prozess. Dieser Prozess hilft, Betrug und Fehler zu vermeiden. GDC kann in den vorhandenen Identitätsanbieter des Kunden eingebunden werden. Das System unterstützt SAML 2.0 und OIDC für die IDP-Föderation. So können Nutzer im System mit ihrem vorhandenen Identitätsanbieter authentifiziert werden, um Nutzer an einem Ort zu verwalten. Alle Nutzer und Arbeitslasten werden authentifiziert, bevor sie auf das System zugreifen. RBAC und ABAC werden verwendet, um den gesamten Zugriff auf die Steuerungsebene und die Daten zu autorisieren. Nutzer dürfen nur dann auf Ressourcen zugreifen und Aktionen ausführen, wenn sie authentifiziert und autorisiert sind. Alle Zugriffe werden in einem Audit-Log protokolliert. So können Administratoren nachvollziehen, wer wann auf eine Ressource zugegriffen hat. So lassen sich unbefugter Zugriff und Missbrauch erkennen.

Security Operations

GDC Security Operations (SecOps) bietet Informationssicherheit für Entitäten mit strengen Sicherheits-, Compliance- und Souveränitätsanforderungen, um maximale Vertraulichkeit, Integrität und Verfügbarkeit von regulierten Kundenarbeitslasten mit Air Gap zu gewährleisten. Diese Sicherheitsarchitektur soll die folgenden Ziele erreichen:

  • Korrelieren Sie das Logging der GDC-Plattform für Sicherheitsanalysen und -reaktionen.
  • Sicherheitslücken umgehend erkennen, melden und verfolgen.
  • Schützen Sie alle OIC- und GDC-Assets mit Endpoint Detection & Response (EDR).
  • Stellen Sie Tools, Prozesse und Runbooks bereit, damit das SecOps-Operations-Center kontinuierlich überwachen kann, um Cybersicherheitsvorfälle zu identifizieren, einzudämmen, zu beseitigen und wiederherzustellen.
Funktion Beschreibung
Security Information and Event Management Elastic Security ist eine SIEM-Plattform (Security Information and Event Management), die Sicherheitsdaten aus verschiedenen Quellen erfasst, indexiert und analysiert, um Unternehmen bei der Erkennung von und Reaktion auf Bedrohungen zu unterstützen.
Verwaltung von Sicherheitslücken Tenable Security Center ist eine Plattform zur Verwaltung von Sicherheitslücken, mit der Unternehmen Sicherheitslücken identifizieren und beheben können.
Endpoint Detection and Response (EDR) Elastic Security, Windows Defender und ClamAV. Einheitliche Sicherheitsplattformen, die Unternehmen einen umfassenden Überblick über ihren Sicherheitsstatus bieten, damit sie Bedrohungen effektiver erkennen und darauf reagieren können.
Sichere Fallverwaltung Eine Softwarelösung, mit der Unternehmen den Lebenszyklus von Sicherheitsvorfällen verwalten können.

Diagramm zu GDC-SecOps, in dem die Softwarekomponenten und die Personenprozesse beschrieben werden.

Mit GDC SecOps können IOs Security Operations-Funktionen bereitstellen. Das GDC SecOps-Team bietet personengestützte Prozesse, einschließlich Incident Response, Verwaltung von Sicherheitslücken, Security Engineering und Risikomanagement für die Lieferkette. Mit GDC SecOps kann ein Security Operations Center (SOC) Folgendes erreichen:

Funktion Beschreibung
Erkennung Unsere Sicherheitsinfrastruktur überwacht potenzielle Bedrohungen und Sicherheitslücken kontinuierlich. Wenn eine Bedrohung oder Sicherheitslücke erkannt wird, erhält das SecOps-Team sofort einen Bericht.
Triage Das Security Operations-Team priorisiert jeden Vorfall, um den Schweregrad der Bedrohung und die angemessene Reaktion zu bestimmen.
Eindämmung Das SecOps-Team ergreift Maßnahmen, um die Bedrohung einzudämmen und ihre Ausbreitung zu verhindern.
Prüfung Das SecOps-Team untersucht den Vorfall, um die Ursache zu ermitteln und Schwachstellen in unserem Sicherheitsstatus zu identifizieren.
Antwort Das SecOps-Team ergreift Maßnahmen, um auf den Vorfall zu reagieren und den verursachten Schaden zu minimieren.
Wiederherstellung Das SecOps-Team ergreift Maßnahmen, um den Vorfall zu beheben und unsere Systeme und Netzwerke wieder in den Normalzustand zu versetzen.

Verwaltung von Sicherheitslücken

GDC führt vor jedem Release mehrere Prozesse zur Identifizierung von Sicherheitslücken in der Vorproduktionsumgebung aus, um potenzielle Common Vulnerabilities and Exposures (CVEs) im Blick zu behalten. GDC bietet auch Scans auf Sicherheitslücken in der Produktionsumgebung für routinemäßiges Monitoring und Berichterstellung. Alle Ergebnisse in der Produktionsumgebung werden in die Security Operations-Prozesse eingebunden, um Bedrohungen zu verfolgen und zu minimieren.

Incident Response bei Sicherheitsvorfällen

Wenn Sicherheitslücken im in GDC bereitgestellten Code entdeckt werden oder ein Vorfall im System auftritt, stehen eine Reihe von Incident-Response-Prozessen zur Verfügung, die vom IO und dem GDC-Sicherheitsteam ausgeführt werden, um die Auswirkungen zu minimieren, Sicherheitspatches zu erstellen und anzuwenden und betroffene Parteien zu informieren. Dieser Vorfallmanagement-Prozess entspricht dem Standard-Vorfallmanagement-Prozess von Google, wobei Änderungen für die getrennte Natur von GDC vorgenommen wurden.

Für jede entdeckte CVE oder jeden Vorfall wird ein Incident Commander (IC) zugewiesen, der den Reaktionsprozess ausführt. Der IC ist für die Verwaltung des Prozesses verantwortlich. Dazu gehören die Überprüfung und Validierung des Vorfalls, die Zuweisung eines CVSS-Werts (Common Vulnerability Scoring System) für die Sicherheitslücke, die Verwaltung des Prozesses zur Erstellung und Bereitstellung eines Patches sowie die Erstellung der entsprechenden Mitteilungen.

Zuverlässigkeitsvorgänge

In diesem Abschnitt erhalten Sie einen Überblick über die Zuverlässigkeitsvorgänge in GDC.

Logging und Monitoring

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

Das Logging-Subsystem nimmt Logs von allen GDC-Kernplattformen und ‑Diensten sowie von Kundenarbeitslasten auf und aggregiert sie in einer Zeitreihendatenbank. Diese Daten werden über eine interaktive Benutzeroberfläche und APIs bereitgestellt.

Kritische Audit-Log-Ereignisse umfassen die folgenden Bereiche:

  • Anfragen zur Nutzerauthentifizierung und -autorisierung.
  • Das Erzeugen und Widerrufen von Authentifizierungstokens.
  • Alle Administratorzugriffe und -änderungen.
  • Alle API-Aktionen der Steuerungsebene.
  • Alle Sicherheitsereignisse, einschließlich IDS, IPS, Firewall, Virenschutz.

Break-Glass-Zugriff

Der IO hat keinen Zugriff auf Kundendaten. In Notfällen kann es jedoch vorkommen, dass der IO Zugriff auf Kundendaten benötigt. In diesen Fällen gibt es in GDC eine Reihe von Notfallzugriffsverfahren, mit denen ein PA dem IO explizit Zugriff zur Fehlerbehebung gewährt.

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

Wenn beispielsweise die IAM-Konfiguration beschädigt ist und den Nutzerzugriff verhindert, verwendet der IO eine SSH-zertifikatbasierte Authentifizierung über sichere Workstations und benötigt die Genehmigung mehrerer Parteien, um den Zugriff zu ermöglichen. Alle ausgeführten Aktionen werden erfasst und können geprüft werden. Die SSH-Schlüssel ändern sich nach einem Notfallzugriffsvorfall.

Notfallwiederherstellung

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

System aktualisieren und upgraden

Da GDC eine Umgebung mit Air Gap ist, verarbeitet der Infrastrukturoperator alle Updates für Kundensysteme. Google signiert und veröffentlicht Binärupdates an einem sicheren Ort, von dem der 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 Malwaredefinitionen und -signaturen, Speicher- und Netzwerk-Appliances, Geräteupdates und alle anderen Binärdateiupdates.

Änderungsmanagement – Infrastruktur als Code

GDC verwendet Infrastructure as Code (IAC), um die Bereitstellung und das Deployment von GDC-Konfigurationen zu automatisieren. IAC verteilt die Verantwortlichkeiten im Infrastruktur-Operations-Team. Beispielsweise kann das Vorschlagen einer Konfigurationsänderung im Vergleich zur Autorisierung der Änderung den gesamten Prozess sicherer 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 Konfigurationsabweichungen.

Compliance-Prozesse

GDC ist compliancefähig für gängige Standards wie NIST 800-53 und SOC 2 und unterstützt Zertifizierungen wie FIPS 140-2 und 3. GDC durchläuft außerdem verschiedene Zertifizierungsprozesse und erfüllt die Sicherheitsstandards von Google. Compliance ist ein fortlaufender Prozess. Um Kunden und Betreiber bei diesem Prozess zu unterstützen, bietet GDC kontinuierliches Monitoring und Tests. Im Rahmen der Sicherheitspraktiken für den kontinuierlichen Monitoringprozess verfolgt GDC Inventaränderungen, z. B. unbekannte Software und Hardware oder das Hinzufügen neuer Software oder Hardware. GDC führt regelmäßig Penetrationstests durch, indem Angriffe von böswilligen Akteuren simuliert werden. GDC scannt die Systeme regelmäßig auf Malware und benachrichtigt GDC über Infektionen. Beim Notfallwiederherstellungstest wird die Fähigkeit von GDC getestet, sich von einer Notfallsituation zu erholen. Diese Prozesse sorgen dafür, dass GDC-Daten und ‑Systeme sicher sind.

Compliance mit dem Security Technical Implementation Guide (STIG)

Gemäß der STIG-Regel RHEL-08-040320 ist das Paket xorg-x11-server-common eine genehmigte Systemabhängigkeit, die für NVIDIA-GPU-Treiber und Hardwarebeschleunigungsbibliotheken (wie Vulkan und Mesa) erforderlich ist. Der Dienst für die grafische Anzeige ist auf Knotenbetriebssystem-Images deaktiviert und inaktiv.