Übersicht über das Sicherheitsdesign der Infrastruktur von Google

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Der Inhalt dieses Dokuments wurde im März 2022 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 und private Kommunikation mit Kunden über das Internet
    • Sicherer Betrieb durch Google-Entwickler
  • 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 aus Innovationen hervorgehen, 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 den physischen Standort unserer Rechenzentren, die Hardware in unseren Rechenzentren und den Software-Stack, der auf der Hardware ausgeführt wird, schützen.

Sicherheit der physischen Räumlichkeiten

Wir entwerfen und bauen unsere eigenen Rechenzentren mit mehreren Ebenen physischer Sicherheit. Der Zugriff auf diese Rechenzentren ist streng kontrolliert. Unsere Rechenzentren werden durch mehrere Stufen physischer Sicherheitstechnologien geschützt. Wir verwenden biometrische Identifikation, Metallerkennung, Kameras, Fahrzeugschranken und laserbasiertes Intrusion Detection System. Weitere Informationen finden Sie unter Sicherheit von Rechenzentren.

Wir hosten auch 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 gesteuerte physische Sicherheitsvorkehrungen getroffen werden. Beispielsweise betreiben wir biometrische Identifikationssysteme, Kameras und Metalldetektoren, die unabhängig von den vom Rechenzentrumsoperator bereitgestellten Sicherheitsebenen 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 die 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 überprüfen und zu validieren. Darüber hinaus entwickeln wir maßgeschneiderte Chips für die Server, Geräte und Peripheriegeräte, einschließlich des Titan-Chips für die Hardwaresicherheit. Damit können wir legitime Google-Geräte auf Hardwareebene identifizieren und authentifizieren und diese Chips dienen als Hardware-Roots of Trust.

Sicherer Boot Stack und Maschinenidentität

Google-Server verwenden verschiedene Technologien, um sicherzustellen, dass der richtige Softwarestack gestartet wird. Wir verwenden kryptografische Signaturen für Komponenten auf niedriger Ebene wie den Baseboard Management Controller (BMC), BIOS, Bootloader, Kernel und das grundlegende Betriebssystem-Image. Diese können bei jedem Startvorgang oder jedem Aktualisierungszyklus validiert werden. Die erste Integritätsprüfung für Google-Server verwendet einen Hardware-Root of Trust. Die Komponenten werden von Google gesteuert, erstellt und mit Integritätsprüfung gehärtet. Mit jeder neuen Hardwaregeneration streben wir danach, die Sicherheit kontinuierlich zu verbessern. Je nach Serverdesigngeneration befindet sich der Root of Trust der Bootkette beispielsweise in einer der folgenden Optionen:

  • Der Titan-Hardwarechip
  • 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 mit dem Hardware-Root of Trust und der Software verknüpft werden, mit der der Computer gestartet 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 System Application Layer Transport Security (ALTS) zum Sichern der RPC-Kommunikation (Remote Procedure Call) in unserer Infrastruktur entwickelt. Diese Maschinenidentitäten können zentral widerrufen werden, um auf einen Sicherheitsvorfall zu reagieren. Außerdem werden ihre Zertifikate und Schlüssel regelmäßig rotiert und alte Zertifikate widerrufen.

Wir haben automatisierte Systeme für die folgenden Aufgaben entwickelt:

  • Es wird dafür gesorgt, dass Server aktuelle Versionen ihrer Softwarestacks (einschließlich Sicherheitspatches) ausführen.
  • Hardware- und Softwareprobleme erkennen und 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 Anwendungen, 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 des erforderlichen Umfangs der Arbeitslast führen Tausende Maschinen möglicherweise Binärdateien desselben Dienstes aus. Ein Cluster-Orchestrierungsdienst namens Borg steuert die Dienste, die direkt auf der Infrastruktur ausgeführt werden.

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

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

Google Cloud und Google Workspace unterstützen gesetzliche Anforderungen für den Datenstandort. Weitere Informationen zum Datenstandort und zu Google Cloud finden Sie unter Anforderungen an den Datenstandort und die Datenhoheit implementieren. Weitere Informationen zum Datenstandort und zu Google Workspace finden Sie unter Speicherorte für Daten: Geografischen Standort für Daten auswählen.

Identität, Integrität und Isolierung der Dienste

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

Dienste nutzen keine interne Netzwerksegmentierung oder Firewalls als primären Sicherheitsmechanismus. Die Filterung eingehenden und ausgehenden Traffics an verschiedenen Punkten im Netzwerk trägt dazu bei, IP-Spoofing zu verhindern. 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. Dem Dienst werden kryptografische Anmeldedaten zur Verfügung gestellt, mit denen er beim Erstellen oder Empfangen von RPCs gegenüber anderen Diensten seine Identität nachweisen kann. Diese Identitäten werden in Sicherheitsrichtlinien verwendet. Die Sicherheitsrichtlinien sorgen dafür, dass Clients mit dem gewünschten Server kommunizieren und dass 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. Dazu zählen die Linux-Nutzertrennung, sprachbasierte (z. B. Sandboxed API) und Kernel-basierte Sandboxen sowie der Anwendungs-Kernel für Container (wie gVisor) und die Hardwarevirtualisierung. Allgemein verwenden wir für riskantere Arbeitslasten mehr Isolationsebenen. Zu riskanten Arbeitslasten zählen vom Nutzer bereitgestellte Artikel, die eine zusätzliche Verarbeitung erfordern. Beispielsweise können riskante Arbeitslasten komplexe Dateikonverter für von Nutzern angegebene Daten oder vom Nutzer bereitgestellten Code für Produkte wie App Engine oder Compute Engine ausführen.

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 Funktionen für die Zugriffsverwaltung nutzen, um genau festzulegen, welche anderen Dienste mit dem Dienst kommunizieren dürfen. Beispielsweise kann ein Dienst eingehende RPCs ausschließlich auf eine zulässige Liste anderer Dienste beschränken. Dieser Dienst kann mit der zulässigen Liste der Dienstidentitäten konfiguriert werden und die Infrastruktur erzwingt diese Zugriffsbeschränkung automatisch. Die Erzwingung umfasst Audit-Logging, Begründungen und einseitige Zugriffsbeschränkungen (z. B. für Entwickleranfragen).

Google-Entwickler, die Zugriff auf Dienste benötigen, erhalten auch individuelle Identitäten. Dienste können so konfiguriert werden, dass sie den Zugriff anhand ihrer Identitäten zulassen oder verweigern. 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-Netzwerktraffic wird verschlüsselt. Die gesamte Kommunikation zwischen den Infrastrukturdiensten wird authentifiziert und die meisten Kommunikationsvorgänge zwischen den Diensten werden verschlüsselt. Dadurch wird eine zusätzliche Sicherheitsebene hinzugefügt, um die Kommunikation zu schützen, auch wenn das Netzwerk abgehört oder ein Netzwerkgerät manipuliert wird. Ausnahmen zur Verschlüsselungsanforderung für die Kommunikation zwischen Diensten werden nur für Traffic gewährt, der niedrige Latenzanforderungen hat und auch nicht ein einzelnes Netzwerk-Fabric in den mehreren Ebenen der physischen Sicherheit in unseren Rechenzentrum hinterlässt.

Die Infrastruktur bietet mithilfe der Hardwareauslagerung automatisch und effizient eine Ende-zu-Ende-Verschlüsselung für den RPC-Traffic der Infrastruktur, der über das Netzwerk zwischen Rechenzentren übertragen wird.

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 andere Dienste innerhalb der Infrastruktur umfassen. Beispielsweise kann Gmail eine People API aufrufen, um auf das Adressbuch des Endnutzers zuzugreifen.

Im Abschnitt Verschlüsselung der dienstübergreifenden Kommunikation wird beschrieben, wie ein Dienst (z. B. Google Kontakte) auf den Schutz von RPC-Anfragen von einem anderen Dienst (z. B. Gmail) ausgelegt ist. Diese Zugriffssteuerungsebene ist jedoch immer noch ein breites Spektrum von Berechtigungen, da Gmail die Kontakte jedes Nutzers jederzeit anfordern kann.

Wenn Gmail eine RPC-Anfrage im Namen eines Endnutzers an Google Kontakte sendet, kann Gmail über die Infrastruktur ein Endnutzer-Berechtigungsticket in der RPC-Anfrage bereitstellen. Dieses Ticket belegt, dass Gmail die RPC-Anfrage im Namen dieses Endnutzers stellt. Mit dem Ticket kann Google Kontakte eine Absicherung implementieren und so nur Daten für den im Ticket genannten Endnutzer zurückgeben.

Die Infrastruktur stellt einen zentralen Nutzeridentitätsdienst bereit, der diese Endnutzer-Berechtigungstickets ausstellt. Der Identitätsdienst überprüft die Anmeldung des Endnutzers und gibt dann Nutzeranmeldedaten wie ein Cookie oder ein OAuth-Token für das Gerät des Nutzers aus. Jede weitere Anfrage vom Gerät an unsere Infrastruktur muss diese Endnutzeranmeldedaten enthalten.

Wenn ein Dienst die Anmeldedaten eines Endnutzers empfängt, übergibt er sie zur Prüfung an den Identitätsdienst. Wenn die Anmeldedaten des Endnutzers verifiziert werden, gibt der Identitätsdienst ein kurzlebiges Endnutzer-Berechtigungsticket zurück, das für RPCs im Zusammenhang mit der Anfrage des Nutzers verwendet werden kann. In unserem Beispiel ist der Dienst, der das Endnutzer-Berechtigungsticket erhält Gmail, der das Ticket an Google Kontakte weiterleitet. Von dort aus kann der aufrufende Dienst für nachfolgende Aufrufe das Endnutzer-Berechtigungsticket als Teil des RPC an den Aufgerufenen senden.

Das folgende Diagramm zeigt, wie Dienst A und Dienst B kommunizieren. Die Infrastruktur bietet Dienstidentitäten, 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 die Identitäten des Aufrufers und des Aufgerufenen. Die Kommunikation ist nur möglich, wenn eine Konfiguration einer Zugriffsregel 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.

Sichere Datenspeicherung

In diesem Abschnitt wird beschrieben, wie wir 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 Schlüsselverwaltungsdienst. Anwendungen bei Google greifen über die Speicherinfrastruktur auf physischen Speicher zu. Wir verwenden mehrere 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 eine Verschlüsselung auf der Anwendungs- oder Speicherinfrastrukturebene durch. Durch die Verschlüsselung kann die Infrastruktur von möglichen Bedrohungen auf den unteren Speicherebenen wie z. B. schädlicher Festplattenfirmware isoliert werden. Gegebenenfalls aktivieren wir auch die Hardwareverschlüsselung in unseren Festplatten und SSDs und wir verfolgen jede Festplatte sorgfältig während ihres Lebenszyklus. Bevor ein außer Betrieb genommenes verschlüsseltes Speichergerät physisch unseren Gewahrsam verlässt, wird das Gerät mithilfe eines mehrstufigen Prozesses gelöscht, der zwei unabhängige Überprüfungen beinhaltet. Geräte, die diesen Löschvorgang nicht korrekt durchlaufen, werden vor Ort physisch zerstört (d. h. zerkleinert).

Zusätzlich zur Verschlüsselung durch die Infrastruktur bieten Google Cloud und Google Workspace wichtige Verwaltungsdienste. 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 verstärkte Zusammenarbeit in Google Workspace.

Daten löschen

Das Löschen von Daten beginnt in der Regel damit, dass bestimmte Daten als „zum Löschen vorgemerkt” gekennzeichnet werden, anstatt sie zu entfernen. Dieser Ansatz ermöglicht es uns, versehentlich gelöschte Daten – sei es durch einen Kunden oder durch einen Programmfehler oder als Ergebnis eines internen Prozessfehlers – wiederherzustellen. Nachdem Daten als zum Löschen vorgemerkt markiert wurden, werden sie in Übereinstimmung mit 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 planen. Mit diesem Feature können Endnutzer ihre eigenen Daten steuern.

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 Kommunikation zwischen Diensten hängt nicht von der Sicherheit des Netzwerks ab. Dennoch isolieren wir unsere Infrastruktur vom Internet in einem privaten IP-Adressbereich. Wir stellen nur einen Teil der Maschinen direkt für externen Internetverkehr zur Verfügung, damit wir zusätzliche Schutzmaßnahmen beispielsweise zur Abwehr von Denial-of-Service (DoS)-Angriffen 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-Front-End. 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 können viele DoS-Angriffe neutralisiert werden. Um das Risiko von DoS-Angriffen auf Dienste weiter zu reduzieren, bieten wir mehrstufige DoS-Schutzmechanismen auf verschiedenen Ebenen.

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 Verteidigungslinie für eine sichere Kommunikation. Endnutzer interagieren mit diesem Dienst über die Google-Anmeldeseite. Der Dienst fordert einen Nutzernamen und ein Passwort an. Außerdem kann er basierend auf Risikofaktoren weitere Informationen anfordern. Beispiele für Risikofaktoren sind, ob sich Nutzer vom selben Gerät oder von einem ähnlichen Ort in der Vergangenheit angemeldet haben. 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 Phishing-resistente 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 bei der Entwicklung des offenen U2F-Standards mit der FIDO Alliance geholfen. Die meisten Webplattformen und Browser haben diesen offenen Authentifizierungsstandard eingeführt.

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 dem zuvor beschriebenen Schutz vor Quellcodekontrollen und dem Überprüfungsprozess von zwei Drittanbietern verwenden wir Bibliotheken, die Entwickler daran hindern, bestimmte Arten sicherheitsrelevanter Programmfehler einzubauen. Wir haben zum Beispiel Bibliotheken und Frameworks, die XSS-Schwachstellen in Web-Apps beseitigen. Außerdem verwenden wir automatisierte Tools wie Fuzzers, statische Analysetools und Websicherheitsscanner, um Sicherheitslücken automatisch zu erkennen.

Als Letztes setzen wir manuelle Sicherheitsüberprüfungen ein, die von schnellen Auswertungen für weniger riskante Funktionen bis hin zu ausführlichen Design- und Implementierungsprüfungen für die riskantesten Funktionen reichen. Das Team, das diese Prüfungen ausführt, umfasst Experten in den Bereichen Websicherheit, Kryptografie und Betriebssystemsicherheit. Die Prüfungen können zur Entwicklung neuer Sicherheitsbibliotheksfunktionen 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 integrierter Quellintegrität und -verwaltung gespeichert, wobei sowohl aktuelle als auch frühere Versionen des Dienstes geprüft werden können. Die Infrastruktur erfordert, dass die Binärdateien eines Dienstes aus einem bestimmten Quellcode erstellt werden, nachdem er geprüft, angesehen und getestet wurde. Die Binärautorisierung für Borg (BAB) ist eine interne Erzwingungsprüfung, die bei der Bereitstellung eines Dienstes ausgeführt wird. BAB führt Folgendes aus:

  • 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 Kompromittierung zu schützen. Zum Schutz unserer Mitarbeiter vor komplexen Phishing-Angriffen haben wir die OTP-Zwei-Faktor-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. Daher sorgen wir dafür, dass die Betriebssystem-Images dieser Geräte über die neuesten Sicherheitspatches verfügen, und steuern, welche Anwendungen die Mitarbeiter auf ihren Geräten installieren können. Außerdem haben wir Systeme, die von Nutzern installierte Anwendungen, Downloads, Browsererweiterungen und Webbrowserinhalte scannen, um zu bestimmen, ob sie für Unternehmensgeräte geeignet sind.

Zugriffsrechte werden nicht aufgrund der Verbindung zum Unternehmens-LAN gewährt. Stattdessen verwenden wir Zero-Trust-Sicherheit, um den Zugriff unserer Mitarbeiter auf unsere Ressourcen zu schützen. Durch Zugriffssteuerungen auf Anwendungsebene werden Mitarbeitern nur interne Anwendungen zur Verfügung gestellt, wenn die Mitarbeiter ein verwaltetes Gerät verwenden und eine Verbindung von erwarteten Netzwerken und geografischen Standorten aus herstellen. Ein Clientgerät ist vertrauenswürdig, basierend auf einem Zertifikat, das auf dem einzelnen Computer ausgestellt wird, und auf Assertions für die Konfiguration (z. B. aktuelle Software). Weitere Informationen finden Sie unter BeyondCorp.

Verringerung von Insiderrisiken

Die Aktivitäten von Mitarbeitern, denen Administratorzugriff auf die Infrastruktur gewährt wurde, sind eingeschränkt und werden aktiv überwacht. 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. Für einige Aktionen sind beispielsweise Genehmigungen von zwei Personen erforderlich und wir verwenden beschränkte APIs, die ein Debugging ohne die Weitergabe vertraulicher Informationen ermöglichen.

Der Zugriff von Google-Mitarbeitern auf Endnutzerdaten kann über einfache Infrastruktur-Hooks protokolliert werden. Unser Sicherheitsteam überwacht Zugriffsmuster und untersucht ungewöhnliche Ereignisse.

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 Chronicle und VirusTotal verwenden, um viele Malware-Typen zu überwachen und darauf zu reagieren. Google Cloud Threat Intelligence for Chronicle ist ein Team von Bedrohungsforschern, die für die Verwendung mit Chronicle 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 komplexe Datenverarbeitungspipelines, um Host-basierte 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 Technikern 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