Übersicht über das Sicherheitsdesign der Infrastruktur von Google

Der Inhalt dieses Dokuments entspricht dem Stand vom Januar 2017 und stellt den Status quo zum Zeitpunkt der Erstellung dar. Die Sicherheitsrichtlinien und -systeme von Google können sich in Zukunft ändern, da wir den Schutz unserer Kunden kontinuierlich verbessern.

Zusammenfassung für CIOs

  • Google verfügt über eine umfassende technische Infrastruktur, die den gesamten Lebenszyklus der Informationsverarbeitung bei Google schützt. Diese Infrastruktur ermöglicht eine sichere Bereitstellung von Diensten, eine sichere Speicherung von Daten mit Absicherungen des Datenschutzes für Endnutzer, eine sichere Kommunikation zwischen Diensten, eine sichere und private Kommunikation mit Kunden über das Internet sowie einen sicheren Betrieb durch Administratoren.
  • Google nutzt diese Infrastruktur für die Erstellung seiner Internetdienste für Nutzer wie die Google-Suche, Gmail und Google Fotos sowie seiner Internetdienste für Unternehmen wie G Suite und Google Cloud Platform.
  • Die Sicherheit der Infrastruktur ist in Schichten aufgebaut – angefangen bei der physischen Sicherheit der Rechenzentren über die Sicherheit der Hardware und Software, die der Infrastruktur zugrunde liegen, bis zu den technischen Einschränkungen und Prozessen, die zur Unterstützung der Betriebssicherheit dienen.
  • Google investiert große Summen in die Sicherung seiner Infrastruktur und verfügt über Hunderte von Entwicklern, die für die Sicherheit und den Datenschutz bei Google zuständig sind, darunter viele anerkannte Branchenexperten.

Einführung

Dieses Dokument gibt einen Überblick darüber, wie Sicherheit in die technische Infrastruktur von Google integriert ist. Diese umfassende Infrastruktur schützt den gesamten Lebenszyklus der Informationsverarbeitung bei Google. Sie ermöglicht eine sichere Bereitstellung von Diensten, eine sichere Speicherung von Daten mit Absicherungen des Datenschutzes für Endnutzer, eine sichere Kommunikation zwischen Diensten, eine sichere und private Kommunikation mit Kunden über das Internet sowie einen sicheren Betrieb durch Administratoren.

Google nutzt diese Infrastruktur für die Erstellung seiner Internetdienste für Nutzer wie die Google-Suche, Gmail und Google Fotos sowie seiner Internetdienste für Unternehmen wie G Suite und Google Cloud Platform.

Die Sicherheit der Infrastruktur lässt sich in Schichten darstellen – angefangen bei der physischen Sicherheit der Rechenzentren über die Sicherheit der Hardware und Software, die der Infrastruktur zugrunde liegen, bis zu den technischen Einschränkungen und Prozessen, die zur Unterstützung der Betriebssicherheit dienen.

Ebenen der Infrastruktursicherheit von Google: Die verschiedenen Schichten reichen von der Hardwareinfrastruktur auf der untersten Ebene bis zur Betriebssicherheit auf der obersten Ebene. Die einzelnen Ebenen werden in diesem Dokument ausführlich beschrieben.

Sichere Infrastruktur auf der untersten Ebene

In diesem Abschnitt wird erläutert, wie die untersten Ebenen unserer Infrastruktur gesichert werden – von den physischen Räumlichkeiten über die maßgeschneiderte Hardware in unseren Rechenzentren bis zum einfachen Softwarestack, der auf jedem Computer ausgeführt wird.

Sicherheit der physischen Räumlichkeiten

Google entwirft und baut seine eigenen Rechenzentren mit mehreren Ebenen physischer Sicherheitsvorkehrungen. Nur ein sehr kleiner Teil der Mitarbeiter von Google hat Zugang zu diesen Rechenzentren. Unsere Rechenzentren werden durch diverse physische Sicherheitstechnologien geschützt, darunter biometrische Identifikation, Metalldetektoren, Kameras, Fahrzeugschranken und laserbasierte Intrusion Detection-Systeme. Darüber hinaus hostet Google einige Server in externen Rechenzentren. Hier stellen wir sicher, dass neben den Schutzmechanismen, die der Betreiber des Rechenzentrums bereitstellt, zusätzlich von Google gesteuerte physische Sicherheitsvorkehrungen getroffen werden. An solchen Standorten betreiben wir beispielsweise unabhängige biometrische Identifikationssysteme, Kameras und Metalldetektoren.

Hardwaredesign und -herkunft

Die Rechenzentren von Google umfassen Tausende von Servermaschinen, die mit einem lokalen Netzwerk verbunden sind. Sowohl die Server-Boards als auch die Netzwerkgeräte wurden von Google speziell entwickelt. Wir überprüfen sämtliche Komponentenanbieter, mit denen wir zusammenarbeiten, und wählen die Komponenten sorgfältig aus. Außerdem prüfen und validieren wir mit den Anbietern gemeinsam die Sicherheitseigenschaften der Komponenten. Darüber hinaus entwickeln wir maßgeschneiderte Chips, darunter einen für die Hardwaresicherheit, der derzeit auf Servern und Peripheriegeräten bereitgestellt wird. Damit können wir legitime Google-Geräte auf Hardwareebene sicher identifizieren und authentifizieren.

Sicherer Boot Stack und Maschinenidentität

Die Servermaschinen von Google nutzen verschiedene Technologien, um sicherzustellen, dass der richtige Softwarestack gestartet wird. Für Komponenten auf niedriger Ebene wie BIOS, Bootloader, Kernel und dem grundlegenden Betriebssystem-Image verwenden wir kryptografische Signaturen. Diese können bei jedem Startvorgang oder jeder Aktualisierung validiert werden. Die Komponenten werden alle von Google gesteuert, gebaut und getestet. Mit jeder neuen Hardwaregeneration streben wir danach, die Sicherheit kontinuierlich zu verbessern: Je nach Serverdesigngeneration verwenden wir als Basis für die zuverlässige Boot-Kette beispielsweise einen geschützten Firmware-Chip, einen Mikrocontroller mit von Google geschriebenem Sicherheitscode oder den oben erwähnten Google-eigenen Sicherheitschip.

Jede Servermaschine im Rechenzentrum hat eine eigene Identität, die mit dem Hardwarevertrauensanker ("Root of Trust") und der Software, mit der sie gestartet wurde, verknüpft werden kann. Diese Identität wird für die Authentifizierung von API-Aufrufen von Verwaltungsdiensten der niederen Ebene auf der Maschine verwendet.

Google hat automatisierte Systeme entwickelt, um sicherzustellen, dass Server aktuelle Versionen ihrer Softwarestacks (einschließlich Sicherheitspatches) ausführen. So lassen sich Hardware- und Softwareprobleme erkennen und diagnostizieren sowie ggf. Maschinen abschalten.

Sichere Dienstbereitstellung

Als Nächstes wird erläutert, wie ausgehend von der grundlegenden Hard- und Software sichergestellt wird, dass Dienste auf unserer Infrastruktur sicher bereitgestellt werden. "Dienste" sind Anwendungsbinärprogramme, die von Entwicklern geschrieben wurden und auf unserer Infrastruktur ausgeführt werden sollen. Dies kann ein Gmail-SMTP-Server, ein BigTable-Storage-Server, ein YouTube-Video-Transcoder oder eine App Engine-Sandbox für eine Kundenanwendung sein. Unter Umständen werden auf Tausenden von Computern Kopien desselben Dienstes ausgeführt, um die erforderliche Arbeitslast zu bewältigen. Dienste, die auf der Infrastruktur laufen, werden von einem Cluster-Orchestrierungsdienst namens Borg gesteuert.

Wie wir im folgenden Abschnitt sehen werden, wird in der Infrastruktur nicht davon ausgegangen, dass zwischen den darauf ausgeführten Diensten Vertrauen besteht. Die Infrastruktur ist also grundsätzlich als Multi-Tenant-System ausgelegt.

Identität, Integrität und Isolierung der Dienste

Wir verwenden eine kryptografische Authentifizierung und Autorisierung auf der Anwendungsebene für die Kommunikation zwischen Diensten. Dies sorgt für eine starke Zugriffskontrolle auf Abstraktionsebene und eine Granularität, die für Administratoren und Dienste gleichermaßen verständlich ist.

Wir setzen keine interne Netzwerksegmentierung oder Firewalls als primäre Schutzmechanismen ein, aber wir verwenden als zusätzliche Sicherheitsebene Ingress- und Egress-Filter an verschiedenen Punkten im Netzwerk zur Verhinderung von IP-Spoofing. Dieser Ansatz trägt auch dazu bei, die Leistungsfähigkeit und Verfügbarkeit unseres Netzwerks zu maximieren.

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 Durchführen von Remoteprozeduraufrufen (Remote Procedure Call – RPC) an andere Dienste oder dem Empfangen solcher Aufrufe seine Identität nachweisen kann. Diese Identitäten werden von Clients verwendet, um sicherzustellen, dass sie mit dem korrekten Server kommunizieren, und von Servern, um den Zugriff auf Methoden und Daten auf bestimmte Clients zu beschränken.

Der Quellcode von Google ist in einem zentralen Repository gespeichert, in dem aktuelle und vergangene Versionen der Dienste geprüft werden können. Die Infrastruktur kann außerdem so konfiguriert werden, dass es erforderlich ist, die Binärprogramme eines Dienstes aus einem bestimmten geprüften, eingecheckten und getesteten Quellcode zu erstellen. Solche Codeprüfungen beinhalten eine Untersuchung und Genehmigung durch mindestens einen weiteren Entwickler neben dem Autor. Zudem verlangt das System, dass Codeänderungen an einem System von den Inhabern dieses Systems genehmigt werden müssen. Dadurch werden die Möglichkeiten eingeschränkt, böswillige Änderungen an Quellcode vorzunehmen, und es gibt eine forensische Spur von einem Dienst zu seiner Quelle.

Wir setzen verschiedene Isolations- und Sandbox-Techniken ein, um Dienste, die auf derselben Maschine laufen, voreinander zu schützen. Dazu zählen die übliche Linux-Nutzertrennung, Sprach- und Kernel-basierte Sandboxen sowie Hardwarevirtualisierung. Allgemein verwenden wir für riskantere Arbeitslasten mehr Isolationsebenen, z. B. beim Ausführen komplexer Dateiformat-Konverter für von Nutzern angegebene Daten oder beim Ausführen von Nutzern bereitgestelltem Code für Produkte wie Google App Engine oder Google Compute Engine. Als zusätzliche Sicherheitsgrenze sorgen wir dafür, dass sehr sensible Dienste wie der Cluster-Orchestrierungsdienst sowie einige wichtige Verwaltungsdienste ausschließlich auf dedizierten Maschinen laufen.

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 eigenen kommunizieren dürfen. Ein Dienst kann beispielsweise einige APIs nur einer bestimmten weißen Liste anderer Dienste anbieten. Der Dienst kann mit der weißen Liste der erlaubten Dienstkontoidentitäten konfiguriert werden und diese Zugriffsbeschränkung wird dann automatisch von der Infrastruktur durchgesetzt.

Auch den Entwicklern von Google, die auf Dienste zugreifen, werden Identitäten ausgestellt, damit die Dienste entsprechend für die Zugriffsverwaltung konfiguriert werden können. Alle Arten von Identitäten (für Maschinen, Dienste und Mitarbeiter) befinden sich in einem globalen Namensraum, der von der Infrastruktur verwaltet wird. Wie später in diesem Dokument erläutert wird, werden Endnutzeridentitäten separat behandelt.

Die Infrastruktur bietet ein umfangreiches Identitätsverwaltungs-Workflow-System für diese internen Identitäten einschließlich Genehmigungsketten, Protokollierung und Benachrichtigungen. Die Identitäten können z. B. über ein System, das eine Kontrolle durch zwei Beteiligte vorsieht, Zugriffskontrollgruppen zugewiesen werden. Dabei kann ein Entwickler eine Änderung an einer Gruppe vorschlagen, die ein anderer Entwickler (der auch ein Administrator der Gruppe ist) genehmigen muss. Mit diesem System können sichere Zugriffsverwaltungsprozesse auf Tausende auf der Infrastruktur ausgeführte Dienste skaliert werden.

Neben dem automatischen Zugriffskontrollmechanismus auf API-Ebene ermöglicht die Infrastruktur Diensten auch, Daten aus zentralen ACL- und Gruppendatenbanken zu lesen, um ggf. eine eigene benutzerdefinierte, detailgenaue Zugriffskontrolle zu implementieren.

Verschlüsselung der Kommunikation zwischen Diensten

Zusätzlich zu den im vorherigen Abschnitt vorgestellten RPC-Authentifizierungs- und -Autorisierungsfunktionen bietet die Infrastruktur auch kryptografischen Datenschutz und Integrität für RPC-Daten im Netzwerk. Um diese Sicherheitsvorteile auch anderen Protokollen auf Anwendungsebene wie HTTP bereitzustellen, kapseln wir diese in unseren Infrastruktur-RPC-Mechanismen. Dies sorgt im Wesentlichen für eine Isolierung der Anwendungsebene und verhindert jegliche Abhängigkeit von der Sicherheit des Netzwerkpfads. Die verschlüsselte Kommunikation zwischen Diensten bleibt auch dann sicher, wenn das Netzwerk abgehört wird oder ein Netzwerkgerät manipuliert wurde.

Dienste können für jeden Remoteprozeduraufruf in der Infrastruktur eine eigene kryptografische Schutzebene konfigurieren (z. B. nur Schutz auf Integritätsebene für geringwertige Daten in Rechenzentren). Zum Schutz vor raffinierten Hackern, die versuchen könnten, unsere privaten WAN-Links abzuhören, verschlüsselt die Infrastruktur automatisch sämtlichen Infrastruktur-RPC-Traffic, der über das WAN zwischen Rechenzentren läuft, ohne dass eine explizite Konfiguration durch den Dienst erforderlich ist. Wir haben mit der Bereitstellung kryptografischer Hardwarebeschleuniger begonnen, mit denen wir diese Standardverschlüsselung auf den gesamten Infrastruktur-RPC-Traffic in unseren Rechenzentren ausdehnen können.

Zugriffsverwaltung für Endnutzerdaten

Ein typischer Google-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 umfasst jedoch noch weitere Dienste in der Infrastruktur. Der Gmail-Dienst kann beispielsweise eine API aufrufen, die vom Kontakte-Dienst zur Verfügung gestellt wird, um auf das Adressbuch des Endnutzers zuzugreifen.

Wie wir im vorherigen Abschnitt gesehen haben, kann der Kontakte-Dienst so konfiguriert werden, dass nur RPC-Anfragen vom Gmail-Dienst zulässig sind (oder von anderen Diensten, die der Kontakte-Dienst zulassen möchte).

Dies ist jedoch immer noch ein sehr breites Spektrum von Berechtigungen. Damit könnte der Gmail-Dienst immer sämtliche Kontakte jedes Nutzers anfordern.

Da der Gmail-Dienst die RPC-Anfrage im Namen eines bestimmten Endnutzers an den Kontakte-Dienst sendet, ermöglicht es die Infrastruktur dem Gmail-Dienst, zusammen mit dem Remoteprozeduraufruf ein "Endnutzer-Berechtigungsticket" zu übermitteln. Dieses Ticket beweist, dass der Gmail-Dienst gerade eine Anfrage im Namen dieses Endnutzers durchführt. So kann der Kontakte-Dienst eine Absicherung implementieren und 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 zentrale Identitätsdienst prüft den Log-in eines Endnutzers und stellt dann Anmeldedaten wie ein Cookie oder ein OAuth-Token für das Clientgerät des Nutzers aus. Jede weitere Anfrage vom Clientgerät an Google muss diese Nutzeranmeldedaten enthalten.

Wenn ein Dienst die Anmeldedaten eines Endnutzers empfängt, leitet er sie zur Prüfung an den zentralen Identitätsdienst weiter. Sind die Anmeldedaten korrekt, gibt der Identitätsdienst ein nur kurze Zeit gültiges "Endnutzer-Berechtigungsticket" zurück, das für Remoteprozeduraufrufe mit Bezug zu der Anfrage verwendet werden kann. In unserem Beispiel erhält der Gmail-Dienst das "Endnutzer-Berechtigungsticket" und leitet es dann an den Kontakte-Dienst weiter. Von dort aus kann das "Endnutzer-Berechtigungsticket" für nachfolgende Aufrufe vom aufrufenden Dienst als Teil des RPC-Aufrufs an den aufgerufenen Dienst weitergegeben werden.

Identitäts- und Zugriffsverwaltung für Dienste: Die Infrastruktur bietet Dienstidentitäten, automatische gegenseitige Authentifizierung, verschlüsselte Kommunikation zwischen Diensten sowie die Durchsetzung von vom Dienstinhaber festgelegten Zugriffsrichtlinien.

Sichere Datenspeicherung

Bisher wurde erläutert, wie wir Dienste sicher bereitstellen. Im nächsten Abschnitt geht es um die Implementierung einer sicheren Datenspeicherung in der Infrastruktur.

Verschlüsselung inaktiver Daten

Die Infrastruktur von Google bietet eine Vielzahl von Speicherdiensten wie BigTable und Spanner sowie einen zentralen Schlüsselverwaltungsdienst. Die meisten Anwendungen bei Google greifen indirekt über diese Speicherdienste auf physischen Speicher zu. Die Speicherdienste können so konfiguriert werden, dass sie Schlüssel aus dem zentralen Schlüsselverwaltungsdienst verwenden, um Daten zu verschlüsseln, bevor sie in den physischen Speicher geschrieben werden. Dieser Schlüsselverwaltungsdienst unterstützt die automatische Schlüsselrotation, bietet umfangreiche Audit-Logs und ist in die zuvor erwähnten Endnutzer-Berechtigungstickets integriert, um Schlüssel mit bestimmten Endnutzern zu verknüpfen.

Durch die Verschlüsselung auf Anwendungsebene kann die Infrastruktur von möglichen Bedrohungen auf den unteren Speicherebenen wie schädlicher Festplattenfirmware isoliert werden. Darüber hinaus werden in der Infrastruktur jedoch noch weitere Schutzebenen implementiert. Wir nutzen die Hardwareverschlüsselung in unseren Festplatten und SSDs und verfolgen jede Festplatte sorgfältig während ihres gesamten Lebenszyklus. Bevor ein außer Betrieb genommenes verschlüsseltes Speichergerät physisch unseren Gewahrsam verlässt, wird es in einem mehrstufigen Prozess gelöscht, der zwei unabhängige Überprüfungen beinhaltet. Geräte, die diesen Löschvorgang nicht korrekt durchlaufen, werden vor Ort physisch zerstört (z. B. zerkleinert).

Löschen von Daten

Das Löschen von Daten beginnt bei Google meist damit, dass bestimmte Daten als "zum Löschen vorgemerkt" gekennzeichnet werden, anstatt sie sofort vollständig zu entfernen. Dies ermöglicht es uns, versehentlich gelöschte Daten – sei es durch einen Kunden oder aufgrund eines internen Programm- oder Prozessfehlers – wiederherzustellen. Nachdem die Daten als "zum Löschen vorgemerkt" markiert wurden, werden sie in Übereinstimmung mit dienstspezifischen Richtlinien gelöscht.

Wenn ein Endnutzer sein gesamtes Konto löscht, benachrichtigt die Infrastruktur Dienste, die Endnutzerdaten verarbeiten, dass das Konto gelöscht wurde. Die Dienste können dann mit dem gelöschten Endnutzerkonto verknüpfte Daten zum Löschen vormerken. Diese Funktion ermöglicht es dem Entwickler eines Dienstes, die Endnutzersteuerung einfach zu implementieren.

Sichere Internetkommunikation

Bisher ging es darum, wie wir Dienste in unserer Infrastruktur schützen. Im nächsten Abschnitt wird die Sicherung der Kommunikation zwischen dem Internet und diesen Diensten erklärt.

Wie bereits erwähnt, besteht die Infrastruktur aus einer großen Zahl an physischen Maschinen, die über LAN und WAN miteinander verbunden sind. Die Sicherheit der Kommunikation zwischen den Diensten hängt nicht von der Sicherheit des Netzwerks ab. Dennoch isolieren wir unsere Infrastruktur vom Internet in einem privaten IP-Bereich, sodass wir leichter zusätzliche Schutzmaßnahmen beispielsweise zur Abwehr von Denial-of-Service (DoS)-Angriffen implementieren können, indem wir nur einen Teil der Maschinen direkt dem externen Internetverkehr aussetzen.

Google Front End-Dienst

Wenn ein Dienst im Internet verfügbar sein soll, 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. Außerdem bietet das GFE Schutz vor Denial-of-Service-Angriffen, wie später noch genauer erklärt wird. Es leitet Anfragen für einen Dienst mithilfe des bereits vorgestellten RPC-Sicherheitsprotokolls weiter.

Tatsächlich nutzt jeder interne Dienst, der extern veröffentlicht werden soll, den GFE-Dienst als intelligentes Reverse-Proxy-Front-End. Dieses Front-End bietet öffentliches IP-Hosting des öffentlichen DNS-Namens, 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.

Schutz vor Denial-of-Service (DoS)-Angriffen

Dank der schieren Größe unserer Infrastruktur kann Google viele DoS-Angriffe einfach neutralisieren. Außerdem verfügen wir jedoch über mehrstufige DoS-Schutzmechanismen auf verschiedenen Ebenen, um die Auswirkungen von DoS-Angriffen auf einen Dienst, der hinter einem GFE ausgeführt wird, weiter zu reduzieren.

Nachdem unser Backbone eine externe Verbindung zu einem unserer Rechenzentren hergestellt hat, durchläuft diese mehrere Ebenen des Hardware- und Software-Lastenausgleichs. 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 Lastenausgleichsmodule so konfigurieren, dass sie den mit dem Angriff verbundenen Traffic unterbinden oder drosseln.

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

Nutzerauthentifizierung

Nach dem Schutz vor DoS-Angriffen bildet unser zentraler Identitätsdienst die nächste Verteidigungslinie. Dieser Dienst präsentiert sich den Endnutzern in der Regel als Google-Anmeldeseite. Über die Abfrage eines einfachen Nutzernamens und Passworts hinaus fordert der Dienst basierend auf gewissen Risikofaktoren wie der Tatsache, ob sich ein Nutzer bereits früher vom selben Gerät oder einem ähnlichen Ort angemeldet hat, intelligent weitere Informationen an. 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.

Nutzer können für die Anmeldung auch zweite Faktoren wie OTPs oder vor Phishing geschützte Sicherheitsschlüssel verwenden. Um sicherzustellen, dass von den Vorteilen nicht nur Google profitiert, haben wir in der FIDO Alliance mit mehreren Geräteanbietern an der Entwicklung des offenen Standards Universal 2nd Factor (U2F) gearbeitet. Die Geräte sind mittlerweile erhältlich und andere wichtige Webdienste haben die U2F-Unterstützung ebenfalls implementiert.

Betriebssicherheit

Bisher haben wir dargelegt, über welche Schutzmechanismen unsere Infrastruktur verfügt, und einige der Verfahren für den sicheren Betrieb wie die Zugriffskontrolle bei Remoteprozeduraufrufen erklärt.

Im Folgenden erfahren Sie, wie wir die Infrastruktur sicher betreiben. Wir erstellen die Infrastruktursoftware sicher, schützen die Computer und Anmeldedaten unserer Mitarbeiter und bewahren die Infrastruktur vor Angriffen von innen und außen.

Sichere Softwareentwicklung

Neben den zuvor beschriebenen Funktionen für die zentrale Versionsverwaltung und die doppelte Prüfung bieten wir auch 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 verfügen wir über Tools zur automatischen Erkennung von Sicherheitslücken wie Fuzzers, statische Analysetools und Websicherheitsscanner.

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. Diese Prüfungen werden von einem Team durchgeführt, das Experten für Websicherheit, Kryptographie und Betriebssystemsicherheit umfasst. Aus den Prüfungen können sich auch neue Funktionen für die Sicherheitsbibliotheken sowie neue Fuzzers ergeben, die dann auf andere zukünftige Produkte angewendet werden 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, Prämien bezahlen. Es wurden bereits mehrere Millionen Dollar an Belohnungen ausgezahlt.

Google beschäftigt sich auch intensiv mit der Aufdeckung und Weiterleitung von Zero-Day-Exploits und anderen Sicherheitsproblemen in der von uns verwendeten Open Source-Software. Der Programmfehler OpenSSL Heartbleed wurde beispielsweise bei Google gefunden und wir liefern die meisten CVEs und Fehlerkorrekturen für den Linux KVM-Hypervisor.

Schutz der Geräte und Anmeldedaten von Mitarbeitern

Wir investieren viel in den Schutz der Geräte und Anmeldedaten unserer Mitarbeiter vor Kompromittierung sowie in die Überwachung von Aktivitäten, um potenzielle Gefahren oder verbotene Insideraktivitäten aufzudecken. Dies spielt bei unseren Bemühungen, einen sicheren Betrieb unserer Infrastruktur zu gewährleisten, eine wichtige Rolle.

Unsere Mitarbeiter sind immer wieder das Ziel raffinierter Phishing-Versuche. Um vor dieser Bedrohung geschützt zu sein, haben wir Phishing-anfällige Einmalpasswörter als zweiten Faktor durch Sicherheitsschlüssel ersetzt, die für die Konten unserer Mitarbeiter verpflichtend sind.

Die Überwachung der Clientgeräte, die unsere Mitarbeiter für den Betrieb der Infrastruktur von Google verwenden, ist für uns sehr wichtig. Daher sorgen wir dafür, dass die Betriebssystem-Images dieser Clientgeräte über die neuesten Sicherheitspatches verfügen, und steuern, welche Anwendungen installiert werden dürfen. Außerdem haben wir Systeme zum Scannen der von Nutzern installierten Apps, Downloads, Browsererweiterungen und im Internet aufgerufenen Inhalte hinsichtlich der Eignung für Unternehmensclients.

Zugriffsrechte werden nicht aufgrund der Tatsache, dass sich ein Gerät im LAN des Unternehmens befindet, gewährt. Wir verwenden stattdessen Zugriffsverwaltungskontrollen auf Anwendungsebene, mit denen wir interne Anwendungen nur bestimmten Nutzern bereitstellen können, die ein korrekt verwaltetes Gerät in einem erwarteten Netzwerk und an einem entsprechenden geografischen Standort nutzen. (Weitere Informationen finden Sie im unten genannten Artikel zu BeyondCorp.)

Verringerung von Insiderrisiken

Die Aktivitäten von Mitarbeitern, denen Administratorzugriff auf die Infrastruktur gewährt wurde, sind drastisch eingeschränkt und werden aktiv überwacht. Zudem 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. Daher ist für manche Aktionen eine Genehmigung von zwei Personen erforderlich und es gibt beschränkte APIs, die eine Fehlerbehebung ohne die Weitergabe vertraulicher Informationen ermöglichen.

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

Angriffserkennung

Google verfügt über komplexe Datenverarbeitungspipelines, die Host-basierte Signale auf einzelnen Geräten, netzwerkbasierte Signale von verschiedenen Monitoring-Punkten in der Infrastruktur sowie Signale von Infrastrukturdiensten 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.

Schutz der Google Cloud Platform (GCP)

In diesem Abschnitt wird dargelegt, wie unsere öffentliche Cloud-Infrastruktur GCP von der Sicherheit der zugrunde liegenden Infrastruktur profitiert. Hierbei nehmen wir Google Compute Engine als Beispiel, um die dienstspezifischen Sicherheitsverbesserungen, die wir auf der Grundlage der Infrastruktur umsetzen, detailliert zu beschreiben.

Mit Compute Engine können Kunden ihre eigenen virtuellen Maschinen auf der Infrastruktur von Google ausführen. Die Compute Engine-Implementierung besteht aus mehreren logischen Komponenten, insbesondere der Verwaltungssteuerungsebene und den virtuellen Maschinen selbst.

Die Verwaltungssteuerungsebene stellt die externe API-Oberfläche bereit und orchestriert Aufgaben wie die Erstellung und Migration virtueller Maschinen. Sie wird als Vielzahl von Diensten auf der Infrastruktur ausgeführt und profitiert so automatisch von grundlegenden Integritätsfunktionen wie der sicheren Boot-Kette. Die einzelnen Dienste laufen unter verschiedenen internen Dienstkonten, sodass jedem Dienst nur die Berechtigungen gewährt werden können, die er für Remoteprozeduraufrufe an den Rest der Steuerungsebene benötigt. Wie bereits erwähnt, wird der Code für alle diese Dienste im zentralen Quellcode-Repository von Google gespeichert und es gibt einen Audit-Trail zwischen diesem Code und den Binärprogrammen, die letztendlich bereitgestellt werden.

Die Compute Engine-Steuerungsebene stellt ihre API über das GFE bereit und nutzt so die Sicherheitsfunktionen der Infrastruktur wie den Schutz vor Denial-of-Service-Angriffen und die zentral verwaltete SSL/TLS-Unterstützung. Kunden können ähnliche Schutzmaßnahmen für Anwendungen erhalten, die auf ihren Compute Engine-VMs laufen, indem sie den optionalen Google Cloud-Lastenausgleichsdienst nutzen, der auf dem GFE aufgebaut ist und viele Arten von DoS-Angriffen bewältigen kann.

Die Endnutzerauthentifizierung für die Compute Engine-Steuerungsebenen-API erfolgt über den zentralen Identitätsdienst von Google, der Sicherheitsfunktionen wie die Missbrauchserkennung bietet. Für die Autorisierung wird der zentrale Cloud IAM-Dienst verwendet.

Der Netzwerkverkehr für die Steuerungsebene – sowohl von den GFEs zum ersten Dienst dahinter als auch zwischen anderen Steuerungsebenendiensten – wird automatisch von der Infrastruktur authentifiziert und verschlüsselt, wenn Daten von einem Rechenzentrum an ein anderes übermittelt werden. Darüber hinaus wurde die Infrastruktur so konfiguriert, dass sie auch innerhalb des Rechenzentrums einen Teil des Traffics auf der Steuerungsebene verschlüsselt.

Jede virtuelle Maschine (VM) wird mit einer zugehörigen Virtual Machine Manager (VMM)-Dienstinstanz ausgeführt. Die Infrastruktur stellt diesen Diensten zwei Identitäten bereit. Eine Identität wird von der VMM-Dienstinstanz für eigene Aufrufe verwendet und die andere wird für Aufrufe genutzt, die der VMM im Namen der VM des Kunden durchführt. Dies ermöglicht es uns, das Vertrauen in Aufrufe vom VMM weiter zu segmentieren.

Die persistenten Festplatten von Compute Engine werden inaktiv mit Schlüsseln verschlüsselt, die durch das zentrale Schlüsselverwaltungssystem der Infrastruktur geschützt sind. Dies ermöglicht eine automatische Rotation und eine zentrale Überwachung des Zugriffs auf diese Schlüssel.

Kunden haben heute die Wahl, Traffic von ihren VMs an andere VMs oder das Internet unverschlüsselt zu senden oder eine beliebige Verschlüsselung zu implementieren. Wir haben mit der Einführung der automatischen Verschlüsselung für den WAN-Durchlauf-Hop von Traffic zwischen Kunden-VMs begonnen. Wie bereits erwähnt, ist der gesamte Steuerebenen-WAN-Traffic innerhalb der Infrastruktur bereits verschlüsselt. In Zukunft möchten wir die bereits erwähnte Hardware-beschleunigte Netzwerkverschlüsselung nutzen, um auch den LAN-Traffic zwischen VMs innerhalb des Rechenzentrums zu verschlüsseln.

Die Isolierung für die VMs basiert auf einer Hardwarevirtualisierung mithilfe des Open Source-KVM-Stacks. Wir haben unsere KVM-Implementierung weiter stabilisiert, indem wir einen Teil des Steuerungs- und Hardwareemulations-Stacks in einen Prozess ohne Berechtigungen außerhalb des Kernels verlagert haben. Außerdem haben wir den KVM-Kern mithilfe von Techniken wie Fuzzing, statischer Analyse und manueller Codeüberprüfung umfangreich getestet. Wie bereits erwähnt, stammte die Mehrheit der kürzlich bekannt gemachten Schwachstellen, die zu KVM weitergeleitet wurden, von Google.

Schließlich spielen unsere betrieblichen Sicherheitskontrollen eine wichtige Rolle dabei sicherzustellen, dass der Zugriff auf Daten gemäß unseren Richtlinien erfolgt. Als Teil der Google Cloud Platform folgt die Nutzung von Kundendaten durch Compute Engine der GCP-Richtlinie zur Nutzung von Kundendaten. Diese sieht vor, dass Google nicht auf Kundendaten zugreift oder diese nutzt, außer soweit zur Bereitstellung von Diensten für Kunden notwendig.

Fazit

In diesem Dokument haben wir erklärt, wie die Infrastruktur von Google gestaltet ist, um Dienste im Internet sicher zu erstellen, bereitzustellen und zu betreiben. Dies betrifft sowohl Dienste für Nutzer wie Gmail als auch Dienste für Unternehmen. Auch unsere Google Cloud-Angebote sind auf dieser Infrastruktur aufgebaut.

Google investiert große Summen in die Sicherung seiner Infrastruktur. Wir haben Hunderte von Entwicklern, die für die Sicherheit und den Datenschutz bei Google zuständig sind, darunter viele anerkannte Branchenexperten.

Wie wir gesehen haben, ist die Sicherheit der Infrastruktur in Schichten aufgebaut – angefangen bei den physischen Komponenten und dem Rechenzentrum über die Herkunft der Hardware bis zum sicheren Boot Stack, der sicheren Kommunikation zwischen Diensten, dem Schutz inaktiver Daten, dem geschützten Zugriff auf Dienste aus dem Internet sowie den Technologien und Mitarbeiterprozessen für die betriebliche Sicherheit.

Weitere Informationen

In den folgenden Artikeln finden Sie weitere Informationen zu bestimmten Themen:

Ressourcen unterwegs überwachen

Projekte jetzt einfach in der Google Cloud Console App verwalten.

Feedback geben zu...