Übersicht über das Sicherheitsdesign der Infrastruktur von Google

Der Inhalt dieses Dokuments wurde im Juni 2023 zum letzten Mal aktualisiert und stellt den Stand zum Zeitpunkt der Erstellung dar. Die Sicherheitsrichtlinien und -systeme von Google Cloud können sich aber in Zukunft ändern, da wir den Schutz unserer Kundinnen und Kunden kontinuierlich verbessern.

Einführung

In diesem Dokument finden Sie eine Übersicht über die Sicherheitsfunktionen in der technischen Infrastruktur von Google. Es richtet sich an Sicherheits-Führungskräfte, Sicherheitsarchitekten und Prüfer.

In diesem Dokument wird Folgendes beschrieben:

  • Die globale technische Infrastruktur von Google schützt den gesamten Lebenszyklus der Informationsverarbeitung bei Google. Diese Infrastruktur bietet Folgendes:
    • Sichere Bereitstellung von Diensten
    • Sichere Datenspeicherung mit Absicherung des Datenschutzes für Endnutzer
    • Sichere Kommunikation zwischen Diensten
    • Sichere, private Kommunikation mit Kunden über das Internet
    • Sicheren Betrieb durch Google-Ingenieure
  • Wie wir diese Infrastruktur verwenden, um Internetdienste zu erstellen, darunter Nutzerdienste wie Google Suche, Gmail und Google Fotos sowie Unternehmensdienste wie Google Workspace und Google Cloud.
  • Dass Sie von Unseren Investitionen in die Sicherung unserer Infrastruktur und unseres laufenden Betriebs profitieren Wir haben viele Entwickler, die für die Sicherheit und den Datenschutz bei Google zuständig sind, darunter viele anerkannte Branchenexperten.
  • Die Sicherheitsprodukte und -dienste, die das Ergebnis von Innovationen sind, die wir intern implementiert haben, um unsere Sicherheitsanforderungen zu erfüllen. Beispielsweise ist BeyondCorp das direkte Ergebnis unserer internen Implementierung des Zero-Trust-Sicherheitsmodells.

  • Wie die Sicherheit der Infrastruktur in Form von progressiven Schichten aufgebaut ist. Diese Schichten umfassen Folgendes:

In den verbleibenden Abschnitten dieses Dokuments werden die Sicherheitsschichten beschrieben.

Sichere Infrastruktur auf der untersten Ebene

In diesem Abschnitt wird beschrieben, wie wir die physischen Räumlichkeiten unserer Rechenzentren, die Hardware in unseren Rechenzentren und den auf der Hardware ausgeführten Softwarestack sichern.

Sicherheit der physischen Räumlichkeiten

Wir entwerfen und bauen unsere eigenen Rechenzentren mit mehreren physischen Sicherheitsebenen. Der Zugang zu diesen Rechenzentren wird streng kontrolliert. Unsere Rechenzentren werden durch mehrere physische Sicherheitsebenen geschützt. Wir nutzen biometrische Identifikation, Metalldetektoren, Kameras, Fahrzeugschranken und laserbasierte Intrusion Detection Systems. Weitere Informationen finden Sie unter Sicherheit des Rechenzentrums.

Außerdem hosten wir einige Server in Rechenzentren von Drittanbietern. In diesen Rechenzentren sorgen wir dafür, dass neben den Sicherheitsebenen, die der Betreiber des Rechenzentrums bereitstellt, zusätzlich von Google kontrollierte physische Sicherheitsvorkehrungen getroffen werden. Beispielsweise betreiben wir biometrische Identifikationssysteme, Kameras und Metalldetektoren, die unabhängig von den Sicherheitsebenen des Rechenzentrumsbetreibers sind.

Hardwaredesign und -herkunft

Die Rechenzentren von Google umfassen Tausende von Servern, die mit einem lokalen Netzwerk verbunden sind. Wir entwerfen die Server-Boards und die Netzwerkgeräte. Wir überprüfen sämtliche Komponentenanbieter, mit denen wir zusammenarbeiten, und wählen die Komponenten sorgfältig aus. Wir arbeiten mit Anbietern zusammen, um die von den Komponenten bereitgestellten Sicherheitseigenschaften zu prüfen und zu validieren. Darüber hinaus entwickeln wir spezielle Chips, darunter einen Hardware-Sicherheitschip mit dem Namen Titan, den wir auf Servern, Geräten und Peripheriegeräten einsetzen. Mit diesen Chips können wir legitime Google-Geräte auf Hardwareebene identifizieren und authentifizieren. Sie dienen außerdem als Root of Trust für die Hardware.

Sicherer Boot Stack und Maschinenidentität

Google-Server verwenden verschiedene Technologien, um sicherzustellen, dass sie den richtigen Softwarestack booten. Für Komponenten auf niedriger Ebene wie den Baseboard Management Controller (BMC), das BIOS, den Bootloader, den Kernel und das grundlegende Betriebssystem-Image verwenden wir kryptografische Signaturen. Diese können bei jedem Boot-Vorgang oder Aktualisierungszyklus validiert werden. Die erste Integritätsprüfung für Google-Server verwendet einen Hardware-Root-of-Trust. Die Komponenten werden von Google gesteuert, hergestellt und mit Integritätsattestierung gehärtet. Mit jeder neuen Hardwaregeneration streben wir danach, die Sicherheit weiter zu verbessern. Je nach Serverdesigngeneration ist der Root of Trust der Boot-Kette beispielsweise eine der folgenden Komponenten:

  • Der Titan-Hardware-Chip
  • Ein geschützter Firmware-Chip
  • Ein Mikrocontroller, der unseren eigenen Sicherheitscode ausführt

Jeder Server im Rechenzentrum hat eine eigene eindeutige Identität. Diese Identität kann an den Hardware-Root-of-Trust und die Software gebunden werden, mit der die Maschine gebootet wird. Diese Identität wird für die Authentifizierung von API-Aufrufen verwendet, die von Verwaltungsdiensten der niederen Ebene auf der Maschine ausgehen oder an die Dienste gerichtet sind. Diese Identität wird auch für die gegenseitige Serverauthentifizierung und die Transportverschlüsselung verwendet. Wir haben das ALTS-System (Application Layer Transport Security) zur Sicherung der RPC-Kommunikation (Remote Procedure Call) in unserer Infrastruktur entwickelt. Diese Maschinenidentitäten können zentral widerrufen werden, um auf einen Sicherheitsvorfall zu reagieren. Darüber hinaus werden ihre Zertifikate und Schlüssel regelmäßig rotiert und alte werden widerrufen.

Wir haben automatisierte Systeme für folgende Zwecke entwickelt:

  • Es wird dafür gesorgt, dass Server aktuelle Versionen ihrer Softwarestacks (einschließlich Sicherheitspatches) ausführen.
  • Um Hardware- und Softwareprobleme zu erkennen und zu diagnostizieren.
  • Zum Sicherstellen der Integrität der Maschinen und Peripheriegeräte mit verifiziertem Bootmodus und impliziter Attestierung.
  • Um darauf zu achten, dass nur Maschinen, auf denen die vorgesehene Software und Firmware ausgeführt wird, auf Anmeldedaten zugreifen können, die eine Kommunikation im Produktionsnetzwerk ermöglichen.
  • Um Maschinen abzuschalten oder neu zuzuweisen, wenn sie nicht mehr benötigt werden.

Sichere Dienstbereitstellung

Google-Dienste sind die Binärdateien der Anwendung, die unsere Entwickler in unserer Infrastruktur schreiben und ausführen. Beispiele für Google-Dienste sind Gmail-Server, Spanner-Datenbanken, Cloud Storage-Server, YouTube-Video-Transcoder und Compute Engine-VMs, auf denen Kundenanwendungen ausgeführt werden. Zur Verarbeitung der erforderlichen Skalierung der Arbeitslast können Tausende von Maschinen Binärdateien desselben Dienstes ausführen. Ein Clusterorchestrierungsdienst namens Borg steuert die Dienste, die direkt in der Infrastruktur ausgeführt werden.

Die Infrastruktur geht nicht von einer Vertrauensstellung zwischen den Diensten aus, die in der Infrastruktur ausgeführt werden. Dieses Vertrauensmodell wird als Zero-Trust-Sicherheitsmodell bezeichnet. Ein Zero-Trust-Sicherheitsmodell bedeutet, dass keine Geräte oder Nutzer standardmäßig vertrauenswürdig sind, unabhängig davon, ob sie sich innerhalb oder außerhalb des Netzwerks befinden.

Da die Infrastruktur mehrmandantenfähig ist, werden Daten von unseren Kunden (Verbraucher und Unternehmen) und sogar unsere eigenen Daten über eine gemeinsam genutzte Infrastruktur verteilt. Diese Infrastruktur besteht aus Zehntausenden von homogenen Maschinen. Die Infrastruktur konzentriert keine Kundendaten auf einer einzelnen Maschine oder auf einer Gruppe von Maschinen, außer unter bestimmten Umständen, z. B. wenn Sie Google Cloud zur Bereitstellung von VMs auf Knoten für einzelne Mandanten für Compute Engine verwenden.

Google Cloud und Google Workspace unterstützen regulatorische Anforderungen in Bezug auf den Datenstandort. Weitere Informationen zum Datenstandort und zu Google Cloud finden Sie unter Anforderungen an den Datenstandort und die Datenhoheit umsetzen. Weitere Informationen zum Datenstandort und zu Google Workspace finden Sie unter Speicherorte für Daten: Standort für Ihre Daten auswählen.

Identität, Integrität und Isolierung der Dienste

Anwendungen ermöglichen die kryptografische Authentifizierung und Autorisierung, um die Kommunikation zwischen Diensten zu ermöglichen. Authentifizierung und Autorisierung bieten eine starke Zugriffssteuerung auf Abstraktionsebene und eine Granularität, die für Administratoren und Dienste verständlich ist.

Dienste verlassen sich nicht auf die interne Netzwerksegmentierung oder auf Firewalls als primären Sicherheitsmechanismus. Durch das Filtern von eingehendem und ausgehendem Traffic an verschiedenen Stellen in unserem Netzwerk wird IP-Spoofing verhindert. Dieser Ansatz trägt auch dazu bei, die Leistungsfähigkeit und Verfügbarkeit unseres Netzwerks zu maximieren. Für Google Cloud können Sie zusätzliche Sicherheitsmechanismen wie VPC Service Controls und Cloud Interconnect hinzufügen.

Jeder auf der Infrastruktur ausgeführte Dienst hat eine eigene Dienstkontoidentität. Ein Dienst wird mit kryptografischen Anmeldedaten bereitgestellt, mit denen er beim Erstellen oder Empfangen von RPCs seine Identität gegenüber anderen Diensten nachweisen kann. Diese Identitäten werden in Sicherheitsrichtlinien verwendet. Mit den Sicherheitsrichtlinien wird sichergestellt, dass Clients mit dem gewünschten Server kommunizieren und dass die Server die Methoden und Daten einschränken, auf die bestimmte Clients zugreifen können.

Wir verwenden verschiedene Isolations- und Sandbox-Techniken, um einen Dienst vor anderen Diensten zu schützen, die auf derselben Maschine ausgeführt werden. Diese Techniken umfassen die Linux-Nutzertrennung, sprachbasierte (z. B.Sandboxed API) und kernel-basierte Sandboxen, Anwendungs-Kernel für Container (z. B.gVisor) und Hardwarevirtualisierung. Im Allgemeinen verwenden wir mehr Isolationsebenen für riskantere Arbeitslasten. Riskantere Arbeitslasten umfassen vom Nutzer bereitgestellte Elemente, die eine zusätzliche Verarbeitung erfordern. Zu den riskanteren Arbeitslasten gehören beispielsweise die Ausführung komplexer Dateikonverter für von Nutzern bereitgestellte Daten oder die Ausführung von vom Nutzer bereitgestelltem Code für Produkte wie App Engine oder Compute Engine.

Für zusätzliche Sicherheit sorgen wir dafür, dass sensible Dienste wie der Cluster-Orchestrierungsdienst sowie einige wichtige Verwaltungsdienste ausschließlich auf dedizierten Maschinen laufen.

In Google Cloud unterstützen wir Confidential Computing-Dienste für Compute Engine-VMs und Google Kubernetes Engine (GKE), um eine stärkere kryptografische Isolation für Ihre Arbeitslasten zu ermöglichen und die aktiven Daten zu schützen.

Zugriffsverwaltung zwischen Diensten

Der Inhaber eines Dienstes kann von der Infrastruktur bereitgestellte Features für die Zugriffsverwaltung nutzen, um genau festzulegen, welche anderen Dienste mit dem eigenen kommunizieren dürfen. Ein Dienst kann beispielsweise eingehende RPCs auf eine Liste zugelassener anderer Dienste beschränken. Dieser Dienst kann mit der Liste der zugelassenen Dienstidentitäten konfiguriert werden und die Infrastruktur erzwingt diese Zugriffsbeschränkung automatisch. Die Erzwingung umfasst Audit-Logging, Zugriffsbegründungen und einseitige Zugriffsbeschränkungen (z. B. für Ingenieursanfragen).

Google-Ingenieure, die Zugriff auf Dienste benötigen, erhalten ebenfalls individuelle Identitäten. Dienste können so konfiguriert werden, dass ihr Zugriff anhand ihrer Identitäten zugelassen oder verweigert wird. Alle diese Identitäten (Maschine, Dienst und Mitarbeiter) befinden sich in einem globalen Namespace, der von der Infrastruktur verwaltet wird.

Zum Verwalten dieser Identitäten stellt die Infrastruktur ein Workflowsystem bereit, das Genehmigungsketten, Logging und Benachrichtigungen enthält. Beispielsweise kann die Sicherheitsrichtlinie die Autorisierung durch mehrere Parteien erzwingen. Dieses System verwendet die zwei Personen-Regel, um sicherzustellen, dass ein allein agierender Entwickler keine vertraulichen Vorgänge ausführen kann, ohne zuvor die Genehmigung eines anderen autorisierten Entwicklers erhalten zu haben. Mit diesem System können sichere Zugriffsverwaltungsprozesse auf Tausende auf der Infrastruktur ausgeführte Dienste skaliert werden.

Die Infrastruktur bietet außerdem Diensten den kanonischen Dienst für die Nutzer-, Gruppen- und Mitgliedschaftsverwaltung, sodass sie bei Bedarf eine benutzerdefinierte, detailgenaue Zugriffssteuerung implementieren können.

Endnutzeridentitäten werden separat verwaltet, wie unter Zugriffsverwaltung für Endnutzerdaten in Google Workspace beschrieben.

Verschlüsselung der Kommunikation zwischen Diensten

Die Infrastruktur bietet Vertraulichkeit und Integrität für RPC-Daten im Netzwerk. Der gesamte virtuelle Google Cloud-Netzwerk-Traffic ist verschlüsselt. Die gesamte Kommunikation zwischen Infrastrukturdiensten wird authentifiziert und die meisten Kommunikation zwischen Diensten wird verschlüsselt. Dies sorgt für eine zusätzliche Sicherheitsebene, die die Kommunikation schützt, selbst wenn das Netzwerk abgehört wird oder ein Netzwerkgerät gehackt wurde. Ausnahmen von der Verschlüsselungsanforderung für die Kommunikation zwischen Diensten werden nur für Traffic gewährt, der Anforderungen mit niedriger Latenz hat und der auch kein einzelnes Netzwerk-Fabric in den verschiedenen physischen Sicherheitsebenen in unserem Rechenzentrum hinterlässt.

Die Infrastruktur ermöglicht automatisch und effizient (mithilfe von Hardware-Offloading) eine Ende-zu-Ende-Verschlüsselung für den RPC-Traffic der Infrastruktur, der das Netzwerk zwischen Rechenzentren durchläuft.

Zugriffsverwaltung für Endnutzerdaten in Google Workspace

Ein typischer Google Workspace-Dienst wird geschrieben, um etwas für einen Endnutzer zu tun. Ein Endnutzer kann z. B. seine E-Mails in Gmail speichern. Die Interaktion des Endnutzers mit einer Anwendung wie Gmail kann jedoch noch weitere Dienste in der Infrastruktur umfassen. Gmail kann beispielsweise eine People API aufrufen, um auf das Adressbuch des Endnutzers zuzugreifen.

Im Abschnitt Verschlüsselung der Kommunikation zwischen Diensten wird beschrieben, wie ein Dienst wie Google Kontakte zum Schutz von RPC-Anfragen vor einem anderen Dienst wie Gmail konzipiert ist. Diese Zugriffsebene umfasst jedoch immer noch ein breites Spektrum von Berechtigungen, da Gmail jederzeit die Kontakte jedes Nutzers anfordern kann.

Wenn Gmail im Namen eines Endnutzers eine RPC-Anfrage an Google Kontakte sendet, gestattet die Infrastruktur Gmail, in der RPC-Anfrage ein Endnutzer-Berechtigungsticket anzugeben. Dieses Ticket belegt, dass Gmail die RPC-Anfrage im Namen dieses Endnutzers stellt. Durch das Ticket kann Google Kontakte eine Sicherheitsmaßnahme implementieren, sodass nur Daten für den im Ticket genannten Endnutzer zurückgegeben werden.

Die Infrastruktur bietet einen zentralen Nutzeridentitätsdienst, der diese Endnutzer-Kontexttickets ausgibt. Der Identitätsdienst prüft die Anmeldung des Endnutzers und gibt dann Nutzeranmeldedaten wie ein Cookie oder OAuth-Token an das Gerät des Nutzers aus. Jede weitere Anfrage vom Gerät an unsere Infrastruktur muss die Anmeldedaten des Endnutzers enthalten.

Wenn ein Dienst Anmeldedaten von Endnutzern empfängt, übergibt der Dienst die Anmeldedaten zur Überprüfung an den Identitätsdienst. Wenn die Endnutzeranmeldedaten geprüft werden, gibt der Identitätsdienst ein kurzlebiges Endnutzer-Kontextticket zurück, das für RPCs im Zusammenhang mit der Anfrage des Nutzers verwendet werden kann. In unserem Beispiel ist Gmail der Dienst, der das Endnutzer-Kontextticket erhält. Gmail übergibt das Ticket dann an Google Kontakte. Von dort aus kann der aufrufende Dienst bei kaskadierenden Aufrufen das Endnutzer-Kontextticket als Teil des RPC an den Aufgerufenen senden.

Das folgende Diagramm zeigt die Kommunikation von Dienst A und Dienst B. Die Infrastruktur bietet Dienstidentität, automatische gegenseitige Authentifizierung, verschlüsselte Kommunikation zwischen Diensten sowie die Durchsetzung der vom Dienstinhaber definierten Zugriffsrichtlinien. Jeder Dienst hat eine Dienstkonfiguration, die der Dienstinhaber erstellt. Für die verschlüsselte Kommunikation zwischen Diensten verwendet die automatische gegenseitige Authentifizierung Aufrufer- und Aufgerufenen-Identitäten. Die Kommunikation ist nur möglich, wenn eine Konfiguration für Zugriffsregeln dies zulässt.

Diagramm, das zeigt, wie Dienst A und Dienst B kommunizieren.

Informationen zur Zugriffsverwaltung in Google Cloud finden Sie in der IAM-Übersicht.

Zugriffsverwaltung für Endnutzerdaten in Google Cloud

Ähnlich wie bei der Zugriffsverwaltung für Endnutzerdaten in Google Workspace bietet die Infrastruktur einen zentralen Nutzeridentitätsdienst, der Dienstkonten authentifiziert und Endnutzer-Kontexttickets ausgibt, nachdem ein Dienstkonto authentifiziert wurde. Die Zugriffsverwaltung zwischen Google Cloud-Diensten erfolgt meist mit Dienst-Agents statt mit Endnutzer-Kontexttickets.

Google Cloud verwendet Identity and Access Management (IAM) und kontextsensitive Produkte wie Identity-Aware Proxy, mit denen Sie den Zugriff auf die Ressourcen in Ihrer Google Cloud-Organisation verwalten können. Alle Anfragen an Google Cloud-Dienste werden über IAM geprüft, um die Berechtigungen zu prüfen.

Der Prozess für die Zugriffsverwaltung sieht so aus:

  1. Eine Anfrage geht über den Google Front End-Dienst oder den Cloud Front End-Dienst für Kunden-VMs ein.
  2. Die Anfrage wird an den zentralen Nutzeridentitätsdienst weitergeleitet, der die Authentifizierungsprüfung durchführt und die Endnutzer-Kontexttickets ausgibt.
  3. Die Anfrage wird auch weitergeleitet, um nach Elementen wie den folgenden zu suchen:
  4. Nachdem alle diese Prüfungen bestanden wurden, werden die Google Cloud-Backend-Dienste aufgerufen.

Informationen zur Zugriffsverwaltung in Google Cloud finden Sie in der IAM-Übersicht.

Sichere Datenspeicherung

In diesem Abschnitt wird beschrieben, wie wir die Sicherheit für Daten implementieren, die in der Infrastruktur gespeichert sind.

Verschlüsselung inaktiver Daten

Die Infrastruktur von Google bietet verschiedene Speicherdienste und verteilte Dateisysteme (z. B. Spanner und Colossus) sowie einen zentralen Key Management Service. Anwendungen bei Google greifen über die Speicherinfrastruktur auf den physischen Speicher zu. Wir verwenden verschiedene Verschlüsselungsebenen, um ruhende Daten zu schützen. Standardmäßig verschlüsselt die Speicherinfrastruktur alle Nutzerdaten, bevor sie in den physischen Speicher geschrieben werden.

Die Infrastruktur führt die Verschlüsselung auf der Anwendungs- oder Speicherinfrastrukturebene durch. Durch die Verschlüsselung kann sich die Infrastruktur von potenziellen Bedrohungen auf den unteren Speicherebenen, z. B. von schädlicher Firmware, isolieren. Gegebenenfalls aktivieren wir auch die Hardwareverschlüsselung auf unseren Festplatten und SSDs. Außerdem verfolgen wir jedes Laufwerk sorgfältig während seines Lebenszyklus. Bevor ein außer Betrieb genommenes, verschlüsseltes Speichergerät die physische Aufbewahrung durch uns verlässt, wird das Gerät mit einem mehrstufigen Prozess bereinigt, der zwei unabhängige Überprüfungen umfasst. Geräte, die diesen Bereinigungsprozess nicht bestehen, werden vor Ort physisch zerstört (zerkleinert).

Zusätzlich zur Verschlüsselung durch die Infrastruktur bieten Google Cloud und Google Workspace Key Management Services. Für Google Cloud ist Cloud KMS ein Cloud-Dienst, mit dem Kunden kryptografische Schlüssel verwalten können. Für Google Workspace können Sie die clientseitige Verschlüsselung verwenden. Weitere Informationen finden Sie unter Clientseitige Verschlüsselung und neue Funktionen für die Zusammenarbeit in Google Workspace.

Daten löschen

Das Löschen von Daten beginnt in der Regel mit dem Markieren bestimmter Daten zum Löschen, anstatt die Daten tatsächlich zu löschen. Mit diesem Ansatz können wir unbeabsichtigte Löschungen wiederherstellen, unabhängig davon, ob sie vom Kunden initiiert wurden, ob sie aufgrund eines Programmfehlers verursacht wurden oder ob sie das Ergebnis eines internen Prozessfehlers sind. Nachdem die Daten zum Löschen vorgemerkt wurden, werden sie gemäß den dienstspezifischen Richtlinien gelöscht.

Wenn ein Endnutzer sein Konto löscht, benachrichtigt die Infrastruktur die Dienste, die die Endnutzerdaten verarbeiten, dass das Konto gelöscht wurde. Die Dienste können dann die mit dem gelöschten Endnutzerkonto verknüpften Daten zum Löschen vormerken. Mit diesem Feature hat ein Endnutzer Kontrolle über seine eigenen Daten.

Weitere Informationen finden Sie unter Datenlöschung auf der Google Cloud.

Sichere Internetkommunikation

In diesem Abschnitt wird beschrieben, wie wir die Kommunikation zwischen dem Internet und den Diensten schützen, die in der Google-Infrastruktur ausgeführt werden.

Wie unter Hardwaredesign und -herkunft erläutert, besteht die Infrastruktur aus vielen physischen Maschinen, die über LAN und WAN miteinander verbunden sind. Die Sicherheit der dienstübergreifenden Kommunikation hängt nicht von der Sicherheit des Netzwerks ab. Dennoch isolieren wir unsere Infrastruktur vom Internet in einem privaten IP-Adressbereich. Nur ein Teil der Maschinen wird direkt für externen Internet-Traffic zugänglich gemacht, sodass wir zusätzliche Schutzmaßnahmen beispielsweise zur Abwehr von Denial-of-Service-Angriffen (DoS) implementieren können.

Google Front End-Dienst

Wenn ein Dienst im Internet verfügbar sein muss, kann er bei dem Infrastrukturdienst Google Front End (GFE) registriert werden. Das GFE stellt sicher, dass alle TLS-Verbindungen mit korrekten Zertifikaten und gemäß Best Practices wie Perfect Forward Secrecy beendet werden. Das GFE wendet auch Schutzmaßnahmen gegen DoS-Angriffen an. Es leitet Anfragen für den Dienst mithilfe des RPC-Sicherheitsprotokolls weiter, das unter Zugriffsverwaltung für Endnutzerdaten in Google Workspace beschrieben wird.

Tatsächlich nutzt jeder interne Dienst, der extern veröffentlicht werden muss, den GFE-Dienst als intelligentes Reverse-Proxy-Frontend. Das GFE bietet öffentliches IP-Adresshosting für seinen öffentlichen DNS-Namen, den Schutz vor DoS-Angriffen und die Beendigung von TLS-Verbindungen. GFEs werden wie jeder andere Dienst auf der Infrastruktur ausgeführt und können daher an die Menge eingehender Anfragen angepasst werden.

Kunden-VMs in Google Cloud registrieren sich nicht bei GFE. Stattdessen registrieren sie sich beim Cloud Front End, einer speziellen Konfiguration von GFE, die den Compute Engine-Netzwerkstack verwendet. Mit Cloud Front End können Kunden-VMs über ihre öffentliche oder private IP-Adresse direkt auf einen Google-Dienst zugreifen. (Private IP-Adressen sind nur verfügbar, wenn privater Google-Zugriff aktiviert ist.)

DoS-Schutz

Durch den Umfang unserer Infrastruktur lassen sich viele DoS-Angriffe bewältigen. Um das Risiko für Dienste durch DoS-Angriffe zu verringern, haben wir mehrstufige, mehrschichtige DoS-Schutzmaßnahmen implementiert.

Wenn unser Glasfaser-Backbone-Netzwerk eine externe Verbindung zu einem unserer Rechenzentren herstellt, durchläuft die Verbindung mehrere Ebenen von Hardware- und Software-Load-Balancern. Die Lastenausgleichsmodule melden Informationen über den eingehenden Traffic an einen zentralen DoS-Dienst, der auf der Infrastruktur ausgeführt wird. Falls dieser Dienst einen DoS-Angriff bemerkt, kann er die Load-Balancers so konfigurieren, dass sie den mit dem Angriff verbundenen Traffic unterbinden oder drosseln.

Die GFE-Instanzen melden ebenfalls Informationen über die Anfragen, die sie empfangen, an den zentralen DoS-Dienst. Dazu zählen Informationen aus der Anwendungsebene, über die die Load-Balancers nicht verfügen. Der zentrale DoS-Dienst kann dann die GFE-Instanzen so konfigurieren, dass sie den Traffic des DoS-Angriffs unterbinden oder drosseln.

Nutzerauthentifizierung

Nach dem Schutz vor DoS-Angriffen bildet der zentrale Identitätsdienst die nächste Verteidigungsschicht für eine sichere Kommunikation. Endnutzer interagieren mit diesem Dienst über die Google-Anmeldeseite. Der Dienst fordert einen Nutzernamen und ein Passwort an und kann Nutzer basierend auf Risikofaktoren auch nach zusätzlichen Informationen fragen. Beispiele für Risikofaktoren sind, dass sich Nutzer nicht vom selben Gerät oder von einem ähnlichen Standort wie in der Vergangenheit anmelden. Nach der Authentifizierung des Nutzers gibt der Identitätsdienst Anmeldedaten wie Cookies und OAuth-Tokens aus, die für nachfolgende Aufrufe verwendet werden können.

Wenn sich Nutzer anmelden, können sie zweite Faktoren wie OTPs oder vor Phishing geschützte Sicherheitsschlüssel wie den Titan-Sicherheitsschlüssel verwenden. Der Titan-Sicherheitsschlüssel ist ein physisches Token, das den FIDO Universal 2nd Factor (U2F) unterstützt. Wir haben gemeinsam mit der FIDO Alliance den offenen U2F-Standard entwickelt. Die meisten Webplattformen und Browser haben diesen offenen Authentifizierungsstandard übernommen.

Betriebssicherheit

In diesem Abschnitt wird beschrieben, wie wir Infrastruktursoftware entwickeln, die Computer und Anmeldedaten unserer Mitarbeiter schützen und wie wir unsere Infrastruktur vor Angriffen von innen und außen schützen.

Sichere Softwareentwicklung

Neben den zuvor beschriebenen Quellcode-Schutzmaßnahmen und der Prüfung durch zwei Personen verwenden wir Bibliotheken, die Entwickler daran hindern, bestimmte Arten sicherheitsrelevanter Programmfehler einzubauen. Wir haben zum Beispiel Bibliotheken und Frameworks, die dabei helfen, XSS-Schwachstellen in Web-Apps zu beseitigen. Außerdem nutzen wir automatisierte Tools wie Fuzzers, statische Analysetools und Websicherheitsscanner, um sicherheitsrelevante Programmfehler automatisch zu erkennen.

Als Letztes setzen wir manuelle Sicherheitsüberprüfungen ein, die von schnellen Auswertungen für weniger riskante Features bis hin zu ausführlichen Design- und Implementierungsprüfungen für die riskantesten Features reichen. Das Team, das diese Prüfungen durchführt, umfasst Experten für Websicherheit, Kryptographie und Betriebssystemsicherheit. Die Prüfungen können zur Entwicklung neuer Sicherheitsbibliotheks-Features und neuer Fuzzers führen, die wir für zukünftige Produkte verwenden können.

Außerdem haben wir das Vulnerability Rewards Program, in dessen Rahmen wir Personen, die uns über Programmfehler in unserer Infrastruktur oder unseren Anwendungen informieren, belohnen. Weitere Informationen zu diesem Programm, einschließlich der von uns ausgegebenen Prämien, finden Sie unter Wichtige Statistiken zu Programmfehlersuchern.

Wir investieren auch in die Suche nach Zero-Day-Exploits und andere Sicherheitsprobleme in der von uns verwendeten Open Source-Software. Wir leiten Projekt Zero, bei dem es sich um ein Team von Google-Forschern handelt, die zu Zero-Day-Sicherheitslücken forschen, darunter auch Spectre und Meltdown. Darüber hinaus liefern wir die meisten CVEs und Fehlerkorrekturen für den Linux KVM-Hypervisor.

Quellcodeschutz

Unser Quellcode wird in Repositories mit standardmäßiger Quellintegrität und Governance gespeichert, wobei sowohl aktuelle als auch frühere Versionen des Dienstes geprüft werden können. Für die Infrastruktur müssen die Binärprogramme eines Dienstes aus einem bestimmten Quellcode erstellt werden, nachdem dieser überprüft, eingecheckt und getestet wurde. Die Binärautorisierung für Borg (BAB) ist eine interne Erzwingungsprüfung, die beim Bereitstellen eines Dienstes erfolgt. BAB tut Folgendes:

  • Es sorgt dafür, dass die bei Google bereitgestellte Produktionssoftware und -konfiguration überprüft und autorisiert wird, insbesondere wenn deren Code auf Nutzerdaten zugreifen kann.
  • Sie sorgt dafür, dass Code- und Konfigurationsbereitstellungen bestimmte Mindeststandards erfüllen.
  • Sie beschränkt die Möglichkeit eines Insiders oder Angreifers, böswillige Änderungen am Quellcode vorzunehmen, und bietet auch einen forensischen Pfad von einem Dienst zu seiner Quelle.

Schutz der Geräte und Anmeldedaten von Mitarbeitern

Wir implementieren Sicherheitsmaßnahmen, um die Geräte und Anmeldedaten unserer Mitarbeiter vor Hacking zu schützen. Zum Schutz unserer Mitarbeiter vor ausgeklügelten Phishing-Versuchen haben wir die Zwei-Faktor-OTP-Authentifizierung durch die obligatorische Verwendung von U2F-kompatiblen Sicherheitsschlüsseln ersetzt.

Wir überwachen die Clientgeräte, die unsere Mitarbeiter für den Betrieb unserer Infrastruktur verwenden. Wir sorgen dafür, dass die Betriebssystem-Images dieser Geräte auf dem neuesten Stand der Sicherheitspatches sind. Außerdem legen wir fest, welche Anwendungen Mitarbeiter auf ihren Geräten installieren können. Außerdem haben wir Systeme, die von Nutzern installierte Anwendungen, Downloads, Browsererweiterungen und Webbrowserinhalte scannen, um festzustellen, ob sie für Unternehmensgeräte geeignet sind.

Die Verbindung mit dem Unternehmens-LAN ist nicht unser Hauptmechanismus, um Zugriffsberechtigungen zu gewähren. Stattdessen verwenden wir Zero-Trust-Sicherheit, um den Zugriff von Mitarbeitern auf unsere Ressourcen zu schützen. Zugriffssteuerungen auf Anwendungsebene stellen Mitarbeitern interne Anwendungen nur dann zur Verfügung, wenn die Mitarbeiter ein verwaltetes Gerät verwenden und eine Verbindung von erwarteten Netzwerken und geografischen Standorten aus herstellen. Ein Clientgerät wird anhand eines Zertifikats als vertrauenswürdig eingestuft, das für die konkrete Maschine ausgestellt wird, sowie anhand von Assertions für die Konfiguration (z. B. aktuelle Software). Weitere Informationen finden Sie unter BeyondCorp.

Verringerung von Insiderrisiken

Insiderrisiken beziehen sich auf das Risiko, dass ein aktueller oder ehemaliger Mitarbeiter, Auftragnehmer oder sonstiger Geschäftspartner, der Zugriff auf unser Netzwerk, unser System oder unsere Daten hat oder hatte, diesen Zugriff missbraucht, um die Vertraulichkeit, Integrität oder Verfügbarkeit unserer Informationen oder Informationssysteme zu beeinträchtigen.

Um Insiderrisiken zu reduzieren, begrenzen und überwachen wir die Aktivitäten von Mitarbeitern, denen Administratorzugriff auf die Infrastruktur gewährt wurde. Außerdem arbeiten wir weiter daran, den privilegierten Zugriff für bestimmte Aufgaben durch Automatisierung überflüssig zu machen, um dieselben Aufgaben sicher und kontrolliert zu erledigen. Wir stellen eingeschränkte APIs zur Verfügung, die das Debuggen ermöglichen, ohne vertrauliche Daten preiszugeben. Außerdem verlangen wir Genehmigungen von zwei Personen für bestimmte sensible Aktionen, die von menschlichen Operatoren ausgeführt werden.

Der Zugriff von Google-Mitarbeitern auf Endnutzerdaten kann über einfache Infrastruktur-Hooks protokolliert werden. Unser Sicherheitsteam überwacht die Zugriffsmuster und untersucht ungewöhnliche Ereignisse. Weitere Informationen finden Sie unter Privilegierte Zugriffsverwaltung in Google Cloud (PDF).

Wir verwenden die Binärautorisierung für Borg, um unsere Lieferkette vor Insiderrisiken zu schützen. Darüber hinaus trägt unsere Investition in BeyondProd dazu bei, Nutzerdaten in der Google-Infrastruktur zu schützen und Vertrauen in unsere Dienste zu schaffen.

In Google Cloud können Sie den Zugriff auf Ihre Daten mit Access Transparency überwachen. Mit Access Transparency-Logs können Sie sich vergewissern, dass die Google-Mitarbeiter nur aus legitimen geschäftlichen Gründen auf Ihre Inhalte zugreifen, z. B. um einen Ausfall zu beheben oder Ihre Supportanfragen zu bearbeiten. Durch die Zugriffsgenehmigung wird sichergestellt, dass Cloud Customer Care und Ingenieure immer Ihre explizite Genehmigung benötigen, wenn sie auf Ihre Daten zugreifen müssen. Die Genehmigung wird kryptografisch überprüft, um die Integrität der Zugriffsgenehmigung zu gewährleisten.

Bedrohungsüberwachung

Die Threat Analysis Group bei Google überwacht Bedrohungsurheber und die Entwicklung ihrer Taktiken und Techniken. Das Ziel dieser Gruppe ist es, die Sicherheit von Google-Produkten zu verbessern und diese Erkenntnisse für die Online-Community freizugeben.

Für Google Cloud können Sie Google Cloud Threat Intelligence für Google Security Operations und VirusTotal verwenden, um viele Typen zu überwachen und darauf zu reagieren. von Malware. Google Cloud Threat Intelligence for Google Security Operations ist ein Team von Bedrohungsforschern, die für die Verwendung mit Google Security Operations Bedrohungsinformationen erstellen. VirusTotal ist eine Malware-Datenbank- und Visualisierungslösung, die Ihnen einen besseren Überblick über die Funktionsweise von Malware in Ihrem Unternehmen bietet.

Weitere Informationen zu unseren Bedrohungsüberwachungsaktivitäten finden Sie im Threat Horizons-Bericht.

Einbruchserkennung

Wir verwenden leistungsfähige Datenverarbeitungspipelines, um hostbasierte Signale auf einzelnen Geräten, netzwerkbasierte Signale von verschiedenen Monitoring-Punkten in der Infrastruktur sowie Signale von Infrastrukturdiensten zu integrieren. Regeln und Maschinenintelligenz, die auf diesen Pipelines aufbauen, liefern den für die Betriebssicherheit zuständigen Ingenieuren Hinweise auf mögliche Vorfälle. Unsere Untersuchungs- und Notfallreaktionsteams sichten, untersuchen und bearbeiten potenzielle Vorfälle rund um die Uhr. Außerdem führen wir Red-Team-Übungen durch, um die Effektivität unserer Erkennungs- und Reaktionsmechanismen zu ermitteln und zu verbessern.

Nächste Schritte