Verschlüsselung inaktiver Daten auf der Google Cloud Platform

Der Inhalt dieses Dokuments entspricht dem Stand vom April 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.

Wiedergabeschaltfläche

Google Cloud – Verschlüsselung inaktiver Daten

Zusammenfassung für CIOs

  • Google nutzt verschiedene Verschlüsselungsebenen, um inaktive Kundendaten in Google Cloud Platform-Produkten zu schützen.
  • Die Google Cloud Platform verschlüsselt alle gespeicherten inaktiven Kundeninhalte mit einem oder mehreren Verschlüsselungsverfahren, ohne dass der Kunde selbst etwas tun muss. Es gibt einige wenige Ausnahmen, die weiter unten in diesem Dokument ausführlicher behandelt werden.
  • Zu speichernde Daten werden in Blöcke unterteilt, wobei jeder Block mit einem einmaligen Schlüssel verschlüsselt wird. Diese Datenverschlüsselungsschlüssel (Data Encryption Keys, DEKs) werden zusammen mit den Daten gespeichert und wiederum mit Schlüsselverschlüsselungsschlüsseln (Key Encryption Keys, KEKs) verschlüsselt ("verpackt"). KEKs werden ausschließlich im zentralen Key Management Service von Google gespeichert und verwendet. Der Key Management Service von Google ist redundant und global verteilt.
  • In der Google Cloud Platform gespeicherte Daten werden auf Speicherebene mit AES256 oder AES128 verschlüsselt.
  • Google nutzt die verbreitete kryptografische Bibliothek Tink, um die Verschlüsselung in nahezu allen Google Cloud Platform-Produkten einheitlich zu implementieren. Da diese Bibliothek allgemein zugänglich ist, muss dieser streng kontrollierte und geprüfte Code nur von einem kleinen Team von Kryptografen ordnungsgemäß implementiert und gepflegt werden.

Einführung

Für viele Personen und Unternehmen ist Sicherheit ein entscheidender Faktor bei der Auswahl eines öffentlichen Cloud-Anbieters. Für Google ist Sicherheit von allerhöchster Bedeutung. Wir nehmen Sicherheit und Datenschutz sehr ernst und arbeiten unermüdlich daran, Ihre Daten zu schützen – ob sie das Internet durchqueren, zwischen Rechenzentren übertragen werden oder auf unseren Servern gespeichert sind.

Ein zentraler Bestandteil unserer Sicherheitsstrategie ist die Verschlüsselung während der Übertragung und im inaktiven Zustand. Wir sorgen dafür, dass Ihre Daten nur von autorisierten Rollen und Diensten mit überwachtem Zugriff auf die Verschlüsselungsschlüssel abrufbar sind. In diesem Dokument wird der Ansatz von Google für die Verschlüsselung inaktiver Daten in der Google Cloud Platform und dessen Umsetzung für die Sicherheit Ihrer Daten beschrieben.

Dieses Dokument richtet sich an CISOs (Chief Information Security Officers) und Security-Operations-Teams, die die Google Cloud Platform derzeit verwenden bzw. dies beabsichtigen. Mit Ausnahme der Einführung werden zum Verständnis dieses Dokuments grundlegende Kenntnisse von Verschlüsselung und kryptografischen Primitiven vorausgesetzt.

Was ist Verschlüsselung?

Verschlüsselung ist die Umwandlung von lesbaren Daten (auch "Klartext" genannt) in einen "Geheimtext" (auch "Chiffrat" genannt), der nur wenige oder keine Informationen über den Klartext offenbart. Hierfür wird zwar ein öffentlicher Verschlüsselungsalgorithmus verwendet, z. B. der Advanced Encryption Standard (AES), jedoch hängt die Ausführung des Algorithmus von einem Schlüssel ab, der geheim gehalten wird. Dieser geheime Schlüssel ist erforderlich, um das Chiffrat zurück in das ursprüngliche Format zu entschlüsseln. Bei Google wird die Verschlüsselung in der Regel mit Integritätsschutz kombiniert, um die Vertraulichkeit von Daten zu schützen. Ohne diesen Schlüssel ist es nicht möglich, das Chiffrat zu verstehen oder zu ändern. Weitere Informationen zu Kryptografie finden Sie im Whitepaper zur Einführung in die moderne Kryptografie.

Der Schwerpunkt dieses Whitepapers liegt auf der Verschlüsselung inaktiver Daten. Mit der Verschlüsselung inaktiver Daten meinen wir den Schutz von Daten, die auf einem Laufwerk (z. B. SSD) oder auf Sicherungsmedien gespeichert sind.

Warum hilft Verschlüsselung beim Sichern von Kundendaten?

Die Verschlüsselung ist nur ein Teil einer umfassenden Sicherheitsstrategie. Durch die Verschlüsselung werden die Daten zusätzlich geschützt. Wenn verschlüsselte Daten in die Hände von Angreifern fallen, sind sie nur mithilfe der jeweiligen Verschlüsselungsschlüssel zugänglich. Selbst wenn der Angreifer Zugriff auf die Speichergeräte hat, auf denen die Daten enthalten sind, kann er diese weder verstehen noch entschlüsseln.

Durch die Verschlüsselung inaktiver Daten wird die Angriffsfläche reduziert, da die unteren Ebenen der Hardware- und Softwarestacks praktisch herausfallen. Selbst wenn diese niedrigeren Ebenen kompromittiert werden (z. B. aufgrund eines physischen Zugriffs auf die Geräte), werden die Daten selbst nicht beeinträchtigt, sofern sie in geeigneter Weise verschlüsselt wurden. Die Verschlüsselung fungiert auch als "Nadelöhr", da zentral verwaltete Verschlüsselungsschlüssel einen zentralen Punkt darstellen, über den der Zugriff auf die Daten zwingend eingeschränkt und überwacht werden kann.

Verschlüsselung ist für Google ein wichtiger Mechanismus, um die Vertraulichkeit von Kundendaten zu gewährleisten. Verschlüsselte Daten können von Systemen zwar gehandhabt werden, um beispielsweise Sicherungen zu erstellen, und Entwickler können diese Daten zur Unterstützung der Infrastruktur verarbeiten, doch bleibt der Zugriff auf die Inhalte geschützt.

Welche Daten betrachten wir als Kundendaten?

Wie in den Nutzungsbedingungen der Google Cloud Platform definiert, bezieht sich der Begriff Kundendaten ("customer data") auf Inhalte, die für Google von einem Google Cloud Platform-Kunden (oder in dessen Namen) direkt oder indirekt über Google Cloud Platform-Dienste bereitgestellt werden, die vom Konto des jeweiligen Kunden genutzt werden. Kundendaten beziehen sich auch auf Kundeninhalte und Kundenmetadaten.

Kundeninhalte ("customer content") sind Daten, die Google Cloud Platform-Kunden selbst generieren oder Google bereitstellen, wie z. B. in Google Cloud Storage gespeicherte Daten, von Google Compute Engine verwendete Laufwerk-Snapshots und Cloud IAM-Richtlinien. Die Verschlüsselung inaktiver Kundeninhalte steht im Mittelpunkt dieses Whitepapers.

Kundenmetadaten ("customer metadata") beziehen sich auf alle anderen Kundendaten, die nicht als Kundeninhalte eingestuft werden können. Hierzu zählen sowohl automatisch generierte Projektnummern, Zeitstempel und IP-Adressen als auch die Bytegröße eines Objekts in Google Cloud Storage oder der Maschinentyp in Google Compute Engine. Metadaten sind so geschützt, dass trotz Schutz noch eine kontinuierliche Leistung und ein kontinuierlicher Betrieb gewährleistet sind.

Standardverschlüsselung von Google

Verschlüsselung inaktiver Daten

Verschlüsselungsebenen

Google nutzt verschiedene Verschlüsselungsebenen, um den Schutz von Daten sicherzustellen. Die Verwendung mehrerer Verschlüsselungsebenen bietet zusätzlichen redundanten Datenschutz und gibt uns die Möglichkeit, basierend auf den Anwendungsanforderungen den jeweils optimalen Ansatz zu bestimmen.

Diagramm der Verschlüsselungsebenen

Abbildung 1: In der Google Cloud Platform gespeicherte Daten werden auf mehreren Verschlüsselungsebenen geschützt. Fast alle Dateien sind entweder durch die verteilte Dateisystemverschlüsselung oder die Datenbank- und Dateispeicherverschlüsselung geschützt.

Verschlüsselung auf Speichersystemebene

Damit Sie nachvollziehen können, wie die Google Cloud Storage-Verschlüsselung genau funktioniert, sollten Sie sich erst vor Augen führen, wie Kundendaten bei Google gespeichert werden. Daten werden zur Speicherung in Unterdateiblöcke zerlegt. Jeder Block kann eine Größe von mehreren GB haben. Jeder Block wird auf Speicherebene mit einem individuellen Verschlüsselungsschlüssel verschlüsselt. Zwei Blöcke haben auch dann nicht den gleichen Verschlüsselungsschlüssel, wenn sie Teil desselben Google Cloud Storage-Objekts sind, demselben Kunden gehören oder auf demselben Gerät gespeichert sind.1 Nach einer Aktualisierung eines Datenblocks wird dieser mit einem neuen Schlüssel verschlüsselt; der vorhandene Schlüssel wird nicht wiederverwendet. Da bei dieser Aufteilung der Daten pro Block ein eigener Schlüssel verwendet wird, ist das Ausmaß des potenziellen Schadens durch einen kompromittierten Datenverschlüsselungsschlüssel auf diesen einen Datenblock beschränkt.

Google verschlüsselt Daten, bevor sie auf das Laufwerk geschrieben werden. Die Verschlüsselung ist von vornherein Bestandteil aller Speichersysteme von Google, wird also nicht nachträglich hinzugefügt.

Jeder Datenblock hat eine eindeutige Kennung. Mithilfe von ACLs (Access Control Lists) wird sichergestellt, dass jeder Block nur von Google-Diensten entschlüsselt werden kann, die unter autorisierten Rollen betrieben werden, die ihrerseits zum betreffenden Zeitpunkt Zugriff erhalten. Dies verhindert den unberechtigten Zugriff auf die Daten und verbessert damit sowohl den Datenschutz als auch die Datensicherheit.

Jeder Datenblock wird über die Speichersysteme von Google verteilt und in verschlüsselter Form für die Sicherung und Notfallwiederherstellung repliziert. Eine Person, die unberechtigt auf Kundendaten zugreifen möchte, müsste in der Lage sein, (1) auf alle Speicherblöcke zuzugreifen, in denen die betreffenden Daten gespeichert sind, und (2) auf alle Verschlüsselungsschlüssel für diese Blöcke zuzugreifen. Nur so würde sie Zugriff auf die Daten erhalten.

Diagramm von in verschlüsselten Blöcken gespeicherten Daten

Abbildung 2: Google unterteilt Daten zur Speicherung in verschlüsselte Blöcke.

Google verwendet den AES-Algorithmus (Advanced Encryption Standard), um inaktive Daten zu verschlüsseln. AES wird allgemein verwendet, da (1) sowohl AES256 als auch AES128 vom National Institute of Standards and Technology (NIST) für die Langzeitspeicherung empfohlen werden (Stand März 2019) und (2) AES häufig Bestandteil der Complianceanforderungen des Kunden ist.

In Google Cloud Storage gespeicherte Daten werden fast immer auf der Speicherebene mit AES im Galois/Counter Mode (GCM) verschlüsselt. Dies ist in der von Google gepflegten BoringSSL-Bibliothek implementiert. Diese Bibliothek wurde von OpenSSL zur internen Verwendung abgespalten, nachdem viele Schwachstellen in OpenSSL bekannt geworden waren. In bestimmten Fällen wird AES im CBC-Modus (Cipher Block Chaining) mit einem HMAC (Hashed Message Authentication Code) zur Authentifizierung verwendet. Und für einige replizierte Dateien wird AES im Counter Mode (CTR) mit HMAC verwendet. Weitere Informationen zu Algorithmen finden Sie weiter unten in diesem Dokument. In anderen Google Cloud Platform-Produkten wird AES in einer Vielzahl von Modi verwendet.

Verschlüsselung auf Speichergeräteebene

Zusätzlich zur oben beschriebenen Verschlüsselung auf Speichersystemebene werden Daten in den meisten Fällen auch auf Speichergeräteebene verschlüsselt, mit mindestens AES128 für Festplatten (HDD) und AES256 für neue SSD-Laufwerke. Hierfür wird ein separater Schlüssel auf Geräteebene verwendet. Dieser Schlüssel unterscheidet sich von dem Schlüssel, der zum Verschlüsseln auf Speicherebene verwendet wird. Da ältere Geräte ausgetauscht werden, wird künftig nur noch AES256 zur Verschlüsselung auf Geräteebene eingesetzt.

Verschlüsselung von Sicherungen

Das Sicherungssystem von Google sorgt dafür, dass die Daten während des Sicherungsvorgangs verschlüsselt bleiben. Mit diesem Ansatz wird die unnötige Freigabe von Klartextdaten vermieden.

Darüber hinaus wird jede Sicherungsdatei einzeln mit einem eigenen DEK (Data Encryption Key) verschlüsselt, der von einem im Google-KMS (Key Management Service) gespeicherten Schlüssel abgeleitet wird. Außerdem wird zum Zeitpunkt der Sicherung pro Datei ein zufällig generierter Seed erstellt. Ein weiterer DEK wird für alle Metadaten in Sicherungen verwendet. Dieser DEK wird ebenfalls im KMS von Google gespeichert. Weitere Informationen zur Schlüsselverwaltung finden Sie weiter unten in diesem Dokument.

Gibt es Fälle, in denen inaktive Dateien nicht verschlüsselt werden?

Die Google Cloud Platform verschlüsselt inaktive Kundeninhalte mit einem oder mehreren Verschlüsselungsmechanismen, ohne dass der Kunde aktiv werden muss. Hierbei gibt es folgende Ausnahmen:

  • Logs von seriellen Konsolen virtueller Maschinen in Google Compute Engine; diese Ausnahme wird derzeit korrigiert
  • Core Dumps auf lokalen Laufwerken, wenn ein Prozess plötzlich fehlschlägt; wird derzeit korrigiert
  • Debugging-Logs auf lokalen Laufwerken; wird derzeit korrigiert
  • Von Speichersystemen verwendete temporäre Dateien; wird derzeit korrigiert
  • Bestimmte Logs, die Kundeninhalte und Kundenmetadaten enthalten können; Korrektur ist geplant

Diese Daten sind jedoch weiterhin durch die restliche Sicherheitsinfrastruktur von Google und in den meisten Fällen auch durch die Verschlüsselung auf Speicherebene geschützt.

Schlüsselverwaltung

Datenverschlüsselungsschlüssel, Schlüsselverschlüsselungsschlüssel und Key Management Service von Google

Zum Verschlüsseln von Daten in einem Block verwendete Schlüssel werden als Datenverschlüsselungsschlüssel (DEKs, Data Encryption Keys) bezeichnet. Aufgrund der hohen Anzahl von Schlüsseln bei Google und der Notwendigkeit einer geringen Latenz und hohen Verfügbarkeit werden diese Schlüssel in der Nähe der Daten gespeichert, die sie verschlüsseln. Die DEKs werden mit einem Schlüsselverschlüsselungsschlüssel (KEK, Key Encryption Key) verschlüsselt (bzw. "verpackt"). Für jeden Google Cloud Platform-Dienst ist mindestens ein KEK vorhanden. KEKs werden zentral im Key Management Service (KMS) von Google gespeichert, einem Repository, das speziell zum Speichern von Schlüsseln erstellt wurde. Mit weniger KEKs als DEKs und dem zentralen Key Management Service können Daten im Google-Maßstab gespeichert und verschlüsselt sowie Datenzugriffe von einem zentralen Punkt aus verfolgt und gesteuert werden.

Für jeden Google Cloud Platform-Kunden werden nicht freigegebene Ressourcen2 in Datenblöcke unterteilt und mit Schlüsseln verschlüsselt, die nicht für andere Kunden verwendet werden3. Diese DEKs unterscheiden sich auch von den Schlüsseln, die andere Teile derselben Daten desselben Kunden schützen.

DEKs werden vom Speichersystem unter Verwendung der allgemeinen kryptografischen Bibliothek von Google generiert. Anschließend werden die DEKs an KMS gesendet, um mit dem KEK dieses Speichersystems verpackt zu werden. Die verpackten DEKs werden dann zurück an das Speichersystem gesendet und zusammen mit den Datenblöcken aufbewahrt. Wenn ein Speichersystem verschlüsselte Daten abrufen muss, ruft es den verpackten DEK ab und sendet ihn an KMS. KMS überprüft dann, ob dieser Dienst zur Verwendung des KEK berechtigt ist. Ist dies der Fall, wird der Klartext-DEK entpackt und an den Dienst zurückgegeben. Der Dienst verwendet dann den DEK, um den Datenblock in Klartext zu entschlüsseln und seine Integrität zu überprüfen.

Die meisten KEKs für die Verschlüsselung von Datenblöcken werden in KMS generiert. Die verbleibenden KEKs werden innerhalb der Speicherdienste generiert. Aus Konsistenzgründen werden alle KEKs mit der kryptografischen Bibliothek und einem von Google entwickelten Zufallszahlengenerator (Random Number Generator, RNG) generiert. Der RNG basiert auf NIST 800-90Ar1 CTR-DRBG und generiert einen KEK auf Basis von AES2564. Dieser RNG wird aus dem RNG des Linux-Kernels geseedet, der wiederum aus mehreren unabhängigen Entropiequellen geseedet wird. Hierzu zählen entropische Ereignisse aus der Rechenzentrumsumgebung, wie z. B. engmaschige Messungen der Zugriffszeiten bei Festplatten und der Eingangszeiten zwischen Paketen sowie je nach Verfügbarkeit der RDRAND-Befehl von Intel (auf CPUs ab der Ivy Bridge-Generation).

In der Google Cloud Platform gespeicherte Daten werden mit DEKs unter Verwendung von AES256 oder AES128 verschlüsselt (siehe Beschreibung oben). Alle neuen verschlüsselten Daten auf persistenten Laufwerken in Google Compute Engine werden unter Verwendung von AES256 verschlüsselt. DEKs werden mit KEKs und (abhängig vom Google Cloud Platform-Dienst) AES256 oder AES128 verpackt. Derzeit wird für alle KEKs für Cloud-Dienste ein Upgrade auf AES256 durchgeführt.

KEKs werden im KMS von Google verwaltet, das ausschließlich zu diesem Zweck entwickelt wurde. KMS wurde im Hinblick auf Sicherheit konzipiert. KEKs können nicht aus dem Google-KMS exportiert werden. Alle Ver- und Entschlüsselungen mit diesen Schlüsseln müssen innerhalb von KMS erfolgen. Auf diese Weise werden Sicherheitslücken und Missbrauch vermieden. Darüber hinaus wird KMS in die Lage versetzt, bei der Verwendung von Schlüsseln Audit-Trails auszugeben.

KMS ist in der Lage, KEKs in regelmäßigen Zeitintervallen mit der kryptografischen Bibliothek von Google automatisch zu rotieren, um neue Schlüssel zu erzeugen. Auch wenn häufig von einem einzigen Schlüssel die Rede ist, meinen wir tatsächlich einen Satz Schlüssel, mit dem die Daten geschützt werden: ein Schlüssel für die Verschlüsselung und ein Satz historischer Schlüssel für die Entschlüsselung, wobei die Anzahl vom Schlüsselrotationsplan bestimmt wird. Der Standardrotationsplan beträgt 90 Tage, auch wenn der tatsächliche Rotationsplan für einen KEK je nach Dienst variieren kann. Google Cloud Storage rotiert KEKs alle 90 Tage und kann bis zu 20 Versionen aufbewahren, wobei eine erneute Verschlüsselung der Daten mindestens alle fünf Jahre erforderlich ist. In der Praxis erfolgt die Neuverschlüsselung jedoch wesentlich häufiger. In KMS aufbewahrte Schlüssel werden zum Zweck der Notfallwiederherstellung gesichert und können beliebig oft wiederhergestellt werden.

Die Verwendung von KEKs wird durch Access Control Lists (ACLs) in KMS für jeden Schlüssel mit einer Per-Key-Richtlinie verwaltet. Nur autorisierte Google-Dienste und Nutzer haben Zugriff auf die Schlüssel. Die Verwendung der einzelnen Schlüssel wird auf der Ebene des jeweiligen Vorgangs verfolgt, der diesen Schlüssel erfordert. Jeder Zugriff auf einen Schlüssel wird authentifiziert und protokolliert. Alle von Nutzern durchgeführten Datenzugriffe sind im Rahmen der allgemeinen Sicherheits- und Datenschutzrichtlinien von Google prüfbar.

Wenn ein Google Cloud Platform-Dienst auf einen verschlüsselten Datenblock zugreift, geschieht Folgendes:

  1. Der Dienst fordert die benötigten Daten vom Speichersystem an.
  2. Das Speichersystem ermittelt die Blöcke, in denen die Daten gespeichert sind (die Block-IDs), sowie den genauen Speicherort.
  3. Für jeden Block ruft das Speichersystem den verpackten DEK ab, der zusammen mit diesem Block aufbewahrt wird, und sendet ihn zum Entpacken an KMS. In einigen Fällen wird dieser Vorgang vom Dienst durchgeführt.
  4. Das Speichersystem überprüft basierend auf einer Jobkennung und anhand der Block-ID, ob der ermittelte Job berechtigt ist, diesen Datenblock abzurufen. KMS überprüft, ob das Speichersystem berechtigt ist, den mit dem Dienst verknüpften KEK zu verwenden und den jeweiligen DEK zu entpacken.
  5. KMS führt eine der folgenden Aufgaben aus:
    • Senden des entpackten DEK zurück an das Speichersystem, das den Datenblock entschlüsselt und an den Dienst übergibt. Oder in seltenen Fällen:
    • Senden des entpackten DEK an den Dienst. Das Speichersystem übergibt den verschlüsselten Datenblock an den Dienst, der ihn entschlüsselt und verwendet.

Dieser Prozess unterscheidet sich von dem auf dedizierten Speichergeräten, wie z. B. SSDs, auf denen das Gerät den DEK auf Geräteebene verwaltet und schützt.

Diagramm der Datenblockentschlüsselung

Abbildung 3: Zum Entschlüsseln eines Datenblocks ruft der Speicherdienst den Key Management Service (KMS) von Google auf, um den entpackten Data Encryption Key (DEK) für diesen Datenblock abzurufen.

Schlüsselhierarchie und Root of Trust

Das KMS von Google wird durch einen Root-Schlüssel mit dem Namen KMS-Masterschlüssel geschützt, der alle KEKs im KMS verpackt. Dieser KMS-Masterschlüssel entspricht AES2564. Er wird in einem anderen Key Management Service aufbewahrt, dem sogenannten Root KMS. In Root KMS werden wesentlich weniger Schlüssel aufbewahrt, nämlich nur ungefähr ein Dutzend. Für noch mehr Sicherheit wird Root KMS nicht auf allgemeinen Produktionsmaschinen ausgeführt, sondern nur auf dedizierten Maschinen in den Google-Rechenzentren.

Root KMS hat wiederum einen eigenen Root-Schlüssel, der als Root KMS-Masterschlüssel bezeichnet wird. Dieser entspricht ebenfalls AES2564 und ist in einer Peer-to-Peer-Infrastruktur gespeichert, im sogenannten Root KMS-Masterschlüsselverteiler, der diese Schlüssel global repliziert. Der Root KMS-Masterschlüsselverteiler speichert die Schlüssel lediglich im RAM auf denselben dedizierten Maschinen, auf denen Root KMS läuft, und loggt sämtliche Zugriffe, damit eine ordnungsgemäße Verwendung sichergestellt werden kann. Für jede Instanz von Root KMS wird eine Instanz des Root KMS-Masterschlüsselverteilers ausgeführt. Der Root KMS-Masterschlüsselverteiler befindet sich noch in der Einführungsphase. Er wird ein System ersetzen, das in ähnlicher Weise betrieben wurde, aber nicht Peer-to-Peer-Technik verwendete.

Neu gestartete Instanzen des Root KMS-Masterschlüsselverteilers werden mit einer Liste von Hostnamen konfiguriert, die bereits Verteilerinstanzen ausführen. Verteilerinstanzen können dann den Root KMS-Masterschlüssel von anderen ausgeführten Instanzen abrufen. Anders als die unten beschriebenen Mechanismen zur Notfallwiederherstellung ist der Root KMS-Masterschlüssel nur im RAM einer begrenzten Anzahl von speziell gesicherten Maschinen enthalten.

Für den Fall, dass alle Instanzen des Root KMS-Masterschlüsselverteilers gleichzeitig neu gestartet werden, ist der Root KMS-Masterschlüssel auch auf sicheren Hardwaregeräten gespeichert, die in physischen Tresoren in hoch gesicherten Bereichen an zwei physisch getrennten Google-Standorten irgendwo auf der Welt aufbewahrt werden. Diese Sicherung würde nur dann benötigt, wenn alle Verteilerinstanzen gleichzeitig ausfallen würden, beispielsweise bei einem globalen Neustart. Weniger als 20 Google-Mitarbeiter haben Zugriff auf diese Tresore.

Diagramm der Verschlüsselungshierarchie von Google

Abbildung 4: Die Verschlüsselungshierarchie schützt einen Block Daten mit einem DEK. Dieser DEK ist mit einem KEK in KMS verpackt, der wiederum vom Root KMS und dem Root KMS-Masterschlüsselverteiler geschützt wird.

Zusammenfassung:

  • Daten werden in Blöcke unterteilt und mit DEKs verschlüsselt.
  • DEKs werden mit KEKs verschlüsselt.
  • KEKs werden in KMS gespeichert.
  • KMS wird auf mehreren Maschinen in Rechenzentren weltweit ausgeführt.
    • KMS-Schlüssel werden mit dem KMS-Masterschlüssel verpackt, der wiederum in Root KMS gespeichert wird.
  • Root KMS ist wesentlich kleiner als KMS und wird nur auf dedizierten Maschinen eines Rechenzentrums ausgeführt.
    • Root KMS-Schlüssel werden mit dem Root KMS-Masterschlüssel verpackt, der im Root KMS-Masterschlüsselverteiler gespeichert wird.
  • Der Root KMS-Masterschlüsselverteiler ist eine Peer-to-Peer-Infrastruktur, die auf dedizierten Maschinen weltweit gleichzeitig im RAM ausgeführt wird. Jede erhält ihr Schlüsselmaterial von anderen ausgeführten Instanzen.
    • Sollten alle Instanzen des Verteilers heruntergefahren werden (Totalabschaltung), stünde ein Masterschlüssel zur Verfügung, der auf (mehrfach vorhandener) sicherer Hardware in (physischen) Tresoren an einigen wenigen Google-Standorten aufbewahrt wird.
    • Der Root KMS-Masterschlüsselverteiler befindet sich noch in der Einführungsphase. Er wird ein System ersetzen, das in ähnlicher Weise betrieben wurde, aber nicht Peer-to-Peer-Technik verwendete.

Globale Verfügbarkeit und Replikation

Eine hohe Verfügbarkeit und niedrige Latenz sowie ein globaler Zugriff auf Schlüssel sind kritische Voraussetzungen auf jeder Ebene. Diese Voraussetzungen müssen gegeben sein, damit Schlüsselverwaltungsdienste in Google verwendet werden können.

Dies ist der Grund, weshalb KMS hochgradig skalierbar ist und in den Rechenzentren von Google weltweit repliziert wird. KMS wird auf regulären Maschinen in der Produktionsflotte von Google ausgeführt. Instanzen von KMS werden global ausgeführt, um den Betrieb der Google Cloud Platform zu unterstützen. Somit ist die Latenz eines jeden Schlüsselvorgangs sehr niedrig.

Root KMS wird in den einzelnen Rechenzentren auf mehreren Maschinen ausgeführt, die jeweils für Sicherheitsvorgänge vorgesehen sind. Der Root KMS-Masterschlüsselverteiler wird auf denselben Maschinen ausgeführt, eins zu eins mit Root KMS. Der Root KMS-Masterschlüsselverteiler stellt einen Verteilungsmechanismus über ein Gossip-Protokoll anhand eines festen Zeitintervalls bereit. Jede Instanz des Verteilers wählt eine zufällige andere Instanz aus, um die Schlüssel zu vergleichen. Mögliche Differenzen werden anschließend abgeglichen. Bei diesem Modell gibt es keinen zentralen Knoten, von dem die gesamte Google-Infrastruktur abhängt. Somit hat Google die Möglichkeit, Schlüsselmaterial mit hoher Verfügbarkeit zu verwalten und zu schützen.

Allgemeine kryptografische Bibliothek von Google

Die allgemeine kryptografische Bibliothek von Google ist Tink5. Mit ihr werden kryptografische Algorithmen mithilfe von BoringSSL6 implementiert. Tink steht allen Google-Entwicklern zur Verfügung. Da diese Bibliothek allgemein zugänglich ist, muss dieser streng kontrollierte und geprüfte Code nur von einem kleinen Team von Kryptografen ordnungsgemäß implementiert werden. Nicht jedes Team bei Google muss eine eigene Kryptografie haben. Ein spezielles Google-Sicherheitsteam ist für die Wartung dieser allgemeinen kryptografischen Bibliothek für alle Produkte zuständig.

Die Tink-Verschlüsselungsbibliothek unterstützt eine Vielzahl von Verschlüsselungsschlüsseltypen und -modi. Diese werden regelmäßig überprüft, um sicherzugehen, dass sie auch gegen die neuesten Angriffe immun sind.

Zum Zeitpunkt der Veröffentlichung dieses Dokuments verwendete Google die folgenden Verschlüsselungsalgorithmen für die Verschlüsselung inaktiver Daten für DEKs und KEKs. Diese unterliegen Änderungen, da wir unsere Funktionen und Sicherheit kontinuierlich verbessern.

Kryptografische Primitive Bevorzugte Protokolle Sonstige unterstützte Protokolle7
Symmetrische Verschlüsselung
  • AES-GCM (256 Bit)
  • AES-CBC und AES-CTR (128 und 256 Bit)
  • AES-EAX (128 und 256 Bit)
Symmetrische Signaturen (wenn mit AES-CBC und AES-CTR oben für Authentifizierung verwendet)
  • HMAC-SHA256
  • HMAC-SHA512
  • HMAC-SHA1

Granularität der Verschlüsselung in den einzelnen Google Cloud Platform-Produkten

Von den einzelnen Google Cloud Platform-Diensten werden die Daten mit unterschiedlichen Granularitätsstufen für die Verschlüsselung unterteilt.

  Google Cloud Platform-Dienst Granularität der Verschlüsselung von Kundendaten8 (Größe der mit einem einzigen DEK verschlüsselten Daten)
Speicherung Cloud Bigtable Pro Datenblock (mehrere pro Tabelle)
Cloud Datastore Pro Datenblock9
Cloud Firestore Pro Datenblock9
Cloud Spanner Pro Datenblock (mehrere pro Tabelle)
Cloud SQL
  • Zweite Generation: pro Instanz, wie in Google Compute Engine (jede Instanz kann mehrere Datenbanken enthalten)
  • Erste Generation: pro Instanz
Cloud Storage Pro Datenblock (in der Regel 256 KB bis 8 MB)
Computing App Engine10 Pro Datenblock9
Cloud Functions11 Pro Datenblock9
Compute Engine
  • Mehrere pro Laufwerk
  • Pro Snapshot-Gruppe mit einzelnen Snapshot-Bereichen, die aus dem Masterschlüssel der Snapshot-Gruppe abgeleitet sind
  • Pro Image
Kubernetes Engine Mehrere pro Laufwerk, für nichtflüchtige Speicher
Container Registry Gespeichert in Google Cloud Storage, pro Datenblock
Big Data BigQuery Mehrere pro Dataset
Cloud Dataflow Gespeichert in Google Cloud Storage, pro Datenblock
Cloud Datalab Gespeichert in Cloud Bigtable, pro Notebook-Datei
Cloud Dataproc Gespeichert in Google Cloud Storage, pro Datenblock
Cloud Pub/Sub Rotiert alle 30 Tage9

Zusätzliche Verschlüsselungsoptionen für Cloud-Kunden

Zusätzlich zur standardmäßigen Verschlüsselung in der Google Cloud Platform bieten wir Kunden weitere Optionen für die Verschlüsselung und Schlüsselverwaltung, um das Niveau der Kontrolle durch den Kunden noch weiter zu erhöhen.

Wir wollen, dass die Kunden der Google Cloud Platform zu Folgendem in der Lage sind:

  • Die Aufsichtsfunktion für Ihre Daten in Eigenverantwortung zu übernehmen sowie den Zugriff auf die Daten sowie deren Verwendung bis ins Detail zu steuern, um sowohl die Datensicherheit als auch den Datenschutz zu gewährleisten
  • Die Verschlüsselung für ihre in der Cloud gespeicherten Daten zu verwalten – mindestens im gleichen Maße wie für lokal gespeicherte Daten
  • Einen nachweisbaren und prüfbaren Root of Trust für ihre Ressourcen zu haben
  • Über den Einsatz von ACLs hinaus den Zugriff auf ihre Daten weiter aufzuteilen und zu trennen

Kunden können vorhandene Verschlüsselungsschlüssel einsetzen, die sie mithilfe der Google Cloud Platform verwalten, indem sie die Funktion der "vom Kunden bereitgestellten Verschlüsselungsschlüssel" verwenden. Dieses Feature ist für Google Cloud Storage und Google Compute Engine zur Verschlüsselung auf Speicherebene verfügbar.

Kunden können ihre Verschlüsselungsschlüssel auch auf der Google Cloud Platform mit dem Google Cloud Key Management Service (Cloud KMS) verwalten. Dieses Produkt ermöglicht eine Verschlüsselung auf Anwendungsebene, die vom Kunden selbst verwaltet wird.

Forschung und Innovation in der Kryptografie

Wir beschäftigen ein Team erstklassiger Sicherheitsexperten, die mit der Verfolgung, Entwicklung und Verbesserung bestehender Verschlüsselungstechnologien beauftragt sind, damit Google immer auf dem neuesten Stand der Entwicklung im Bereich der Verschlüsselung bleibt. Unsere Entwickler beteiligen sich an Standardisierungsprozessen und der Pflege weit verbreiteter Verschlüsselungssoftware. Wir veröffentlichen unsere Forschungsergebnisse im Bereich der Verschlüsselungstechnologie regelmäßig, damit jeder in der Branche – auch die Öffentlichkeit – von unserem Wissen profitieren kann. Im Jahr 2014 haben wir beispielsweise eine erhebliche Sicherheitslücke in der SSL 3.0-Verschlüsselung (bekannt als POODLE) und im Jahr 2015 eine hochriskante Sicherheitslücke in OpenSSL aufgedeckt.

Google will auch in Zukunft seine führende Position im Bereich der Verschlüsselungstechnologien für Clouddienste aufrechterhalten. Bei der Entwicklung, Umsetzung und Erforschung neuer kryptografischer Techniken arbeiten unsere Teams an folgenden Themen:

  • Teilweise homomorphe Kryptografie, die die Durchführung bestimmter Vorgänge an Daten ermöglicht, während diese verschlüsselt sind. In der Cloud sind diese Daten niemals als Klartext zu sehen, auch nicht im Speicher. Diese Technologie wird beispielsweise im Rahmen unseres experimentellen verschlüsselten BigQuery-Clients verwendet, der öffentlich verfügbar ist.
  • Format- und ordnungserhaltende Kryptografie, die es uns ermöglicht, bestimmte Vergleichs- und Rankingvorgänge an Daten durchzuführen, während sie verschlüsselt sind.
  • Post-Quanten-Kryptografie, die es uns ermöglicht, bestehende kryptografische Primitive, die anfällig für effiziente Quantenangriffe sind, durch Post-Quanten-Kandidaten zu ersetzen, von denen angenommen wird, dass sie gegen solche Angriffe resistenter sind. Der Schwerpunkt liegt hierbei auf der Erforschung und dem Prototyping gitterbasierter Public-Key-Kryptografie, einschließlich NIST-Empfehlungen zu Post-Quanten-Algorithmen. Die gitterbasierte Kryptografie wird derzeit als eine der vielversprechendsten Verschlüsselungstechniken im Post-Quanten-Zeitalter angesehen. Allerdings stehen wir hinsichtlich optimaler Algorithmen, konkreter Parameter und der Kryptoanalyse zur Anwendung der gitterbasierten Kryptografie noch ganz am Anfang. Die symmetrische Schlüsselverschlüsselung und MACs werden zwar durch bekannte Quantenalgorithmen geschwächt, können jedoch durch die Verdoppelung der Schlüsselgrößen auf für die Post-Quanten-Kryptografie ausreichende Sicherheitsbits aufgerüstet werden.

Weitere Referenzen

Sicherheit der Google Cloud Platform

Weitere Informationen zur Sicherheit der Google Cloud Platform finden Sie im Abschnitt "Sicherheit" auf der Google Cloud Platform-Website.

Compliance der Google Cloud Platform

Informationen zur Compliance und zu Compliance-Zertifizierungen der Google Cloud Platform sind im Abschnitt zur Compliance auf der Google Cloud Platform-Website enthalten. Dort finden Sie auch den öffentlichen SOC3-Prüfbericht von Google.

G Suite-Sicherheit

Weitere Informationen zur Verschlüsselung und Schlüsselverwaltung in G Suite finden Sie im Whitepaper zur Verschlüsselung in der G Suite. Viele der hier behandelten Themen werden auch im oben genannten Whitepaper behandelt, jedoch nur im Hinblick auf die G Suite. Der Schutz von Kundendaten und eine transparente Vorgehensweise zur Sicherung der Daten hat bei allen G Suite-Lösungen oberste Priorität. Weitere Informationen zur allgemeinen G Suite-Sicherheit finden Sie im Whitepaper zur Sicherheit und Compliance der G Suite.

Fußnoten

1 Ein Datenblock in Cloud Datastore, App Engine und Cloud Pub/Sub kann Daten von mehreren Kunden enthalten. Weitere Informationen finden Sie im Abschnitt zur Granularität der Datenverschlüsselung nach Diensten.

2 Ein Beispiel für eine freigegebene Ressource (auf die diese Trennung nicht zutrifft) wäre ein gemeinsam genutztes Basis-Image in Google Compute Engine. Wenn hier von mehreren Kunden die Rede ist, bezieht sich dies natürlich auf eine einzelne Kopie, die mit einem einzigen DEK verschlüsselt ist.
3 Ausgenommen Daten, die in Cloud Datastore, App Engine oder Cloud Pub/Sub gespeichert sind, wo Daten mehrerer Kunden mit demselben DEK verschlüsselt werden können. Siehe Abschnitt zur Granularität der Datenverschlüsselung nach Diensten.
4 Früher war dies AES128. Einige dieser Schlüssel sind zum Entschlüsseln von Daten weiterhin aktiv.
5 Google nutzt außerdem zwei weitere Bibliotheken: Keymaster und CrunchyCrypt. Keymaster teilt neueren Kryptografiecode mit Tink, nutzt jedoch eine andere Schlüsselversionsverwaltung und unterstützt eine größere Anzahl älterer Algorithmen. CrunchyCrypt wird mit Tink zusammengeführt.
6 OpenSSL wird ebenfalls an einigen Stellen in Google Cloud Storage verwendet.
7 Die Bibliothek enthält weitere kryptografische Protokolle, die in der Vergangenheit unterstützt wurden. Die vorliegende Liste umfasst jedoch die in der Google Cloud Platform primär verwendeten Protokolle.
8 Bezieht sich auf die Granularität der Verschlüsselung von Kundeninhalten. Dazu gehören keine Kundenmetadaten, wie z. B Ressourcennamen. Bei einigen Diensten werden alle Metadaten mit einem einzigen DEK verschlüsselt.
9 Nicht einzigartig für einen einzelnen Kunden.
10 Umfasst Anwendungscode und Anwendungseinstellungen. Die in App Engine verwendeten Daten werden je nach Kundenkonfiguration in Cloud Datastore, Cloud SQL oder Cloud Storage gespeichert.
11 Umfasst Funktionscode, Einstellungen und Ereignisdaten. Ereignisdaten werden in Cloud Pub/Sub gespeichert.

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...