Inaktive Daten in Google Cloud verschlüsseln

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

Wiedergabeschaltfläche

Google Cloud – Inaktive Daten verschlüsseln

Zusammenfassung für CIOs

  • Google nutzt verschiedene Verschlüsselungsebenen, um inaktive Kundendaten in Google Cloud-Produkten zu schützen.
  • Google Cloud verschlüsselt alle gespeicherten inaktiven Kundeninhalte mit einem oder mehreren Verschlüsselungsverfahren, ohne dass der Kunde selbst etwas tun muss.
  • 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.
  • Alle in der Google Cloud Platform gespeicherten Daten werden auf Speicherebene mit AES256 verschlüsselt. Eine Ausnahme bilden einige wenige nichtflüchtige Speicher, die vor 2015 erstellt wurden und mit AES128 verschlüsselt werden.
  • Google nutzt die verbreitete kryptografische Bibliothek Tink, die unser gemäß FIPS 140-2 validiertes Modul BoringCrypto beinhaltet, um die Verschlüsselung in nahezu allen Google Cloud-Produkten einheitlich zu implementieren. Dank der konsistenten Nutzung einer allgemeinen Bibliothek muss dieser streng kontrollierte und geprüfte Code nur von einem kleinen Team von Kryptografen implementiert und gepflegt werden.

Einführung

Für viele Personen und Unternehmen ist Sicherheit ein entscheidender Faktor bei der Auswahl eines öffentlichen Cloud-Anbieters. Bei Google steht die Sicherheit an erster Stelle. 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 im Transit und im Ruhezustand. Wir sorgen dafür, dass Ihre Daten nur von autorisierten Rollen und Diensten mit überwachtem Zugriff auf die Schlüssel abrufbar sind. Dieser Artikel erläutert den Ansatz, nach dem Google inaktive Daten in Google Cloud verschlüsselt. Außerdem zeigt er, wie Google diesen Ansatz einsetzt, um Ihre Informationen noch besser zu schützen.

Dieses Dokument richtet sich an CISOs (Chief Information Security Officers) und Security-Operations-Teams, welche Google Cloud derzeit verwenden bzw. dies beabsichtigen. Abgesehen von der Einführung werden zum Verstehen 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, den Geheimtext 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. Informationen zur Verschlüsselung von Daten bei der Übertragung finden Sie in unserem Whitepaper Verschlüsselung bei der Übertragung in Google Cloud.

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 hat gleichzeitig die Rolle eines "Nadelöhrs", da zentral verwaltete Verschlüsselungsschlüssel einen zentralen Punkt darstellen, über den der Zugriff auf die Daten laufen muss und dieser so überprüft werden kann.

Verschlüsselung ist für Google ein wichtiger Mechanismus, um den Schutz 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 Google Cloud-Nutzungsbedingungen definiert, bezieht sich der Begriff Kundendaten ("customer data") auf Inhalte, die für Google von einem Google Cloud-Kunden (oder in dessen Namen) direkt oder indirekt über Google Cloud-Dienste bereitgestellt werden, die vom Konto des jeweiligen Kunden genutzt werden. Kundendaten beziehen sich auch auf Kundeninhalte und Kundenmetadaten.

Kundeninhalte ("customer content") sind solche Daten, die Google Cloud-Kunden selbst erstellen oder Google bereitstellen. Dazu gehören in Cloud Storage gespeicherte Daten, von Compute Engine verwendete Laufwerk-Snapshots sowie Richtlinien zur Identitäts- und Zugriffsverwaltung. 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 Cloud Storage oder der Maschinentyp in Compute Engine. Metadaten sind in dem Maße geschützt, dass eine kontinuierliche Leistung und ein kontinuierlicher Betrieb gewährleistet sind.

Standardverschlüsselung von Google

Verschlüsselung inaktiver Daten

Google Cloud verschlüsselt alle gespeicherten inaktiven Kundeninhalte mit einem oder mehreren Verschlüsselungsverfahren, ohne dass der Kunde selbst etwas tun muss.

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: Verschlüsselungsebenen

Abbildung 1: In Google Cloud 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 Verschlüsselung bei Cloud Storage 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 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.

Bei Google werden Daten schon verschlüsselt, bevor sie überhaupt 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 mehrere 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: In verschlüsselten Blöcken gespeicherte Daten

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

Google nutzt den AES-Algorithmus (Advanced Encryption Standard) zur Verschlüsselung inaktiver Daten Alle Daten auf Speicherebene werden standardmäßig mit AES256 verschlüsselt. Eine Ausnahme bilden einige wenige nichtflüchtige Speicher, die vor 2015 erstellt wurden und mit AES128 verschlüsselt werden. AES ist weit verbreitet, da (1) sowohl AES256 als auch AES128 vom National Institute of Standards and Technology (NIST) zur Langzeitspeicherung empfohlen werden (Stand: März 2019) und (2) AES oft Teil der Complianceanforderungen der Kunden ist.

In Cloud Storage gespeicherte Daten werden fast immer auf der Speicherebene mit AES im Galois/Counter Mode (GCM) verschlüsselt. In bestimmten Fällen wird AES im CBC-Modus (Cipher Block Chaining) mit einem HMAC (Hashed Message Authentication Code) zur Authentifizierung verwendet. 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-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 mit AES256 für Festplatten (HDD) und SSD-Laufwerke (Solid State Drive) verschlüsselt. Hierfür wird ein separater Schlüssel auf Geräteebene verwendet. Dieser unterscheidet sich von dem Schlüssel, der zum Verschlüsseln auf Speicherebene verwendet wird. Eine geringe Anzahl von Legacy-HDDs nutzt noch AES128. Nutzerdaten, die auf von Google Cloud verwendeten SSDs gespeichert sind, werden ausschließlich mit AES256 verschlüsselt.

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.

FIPS-Compliance bei inaktiven Daten

Google Cloud verwendet ein gemäß FIPS 140-2 validiertes Verschlüsselungsmodul (Zertifikat 3318) in der Produktionsumgebung.

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 (Data Encryption Keys, DEKs) 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 (Key Encryption Key, KEK) verschlüsselt (bzw. "verpackt"). Für jeden Google Cloud-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.

Bei jedem Google Cloud-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 mithilfe 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 AES256-KEK.4 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 Google Cloud gespeicherte Daten werden mit DEKs unter Verwendung von AES256 oder AES128 verschlüsselt (siehe Beschreibung oben). Alle neuen verschlüsselten Daten auf nichtflüchtigen Speichern in Google Compute Engine werden unter Verwendung von AES256 verschlüsselt. DEKs werden mit KEKs mit AES256 oder AES128 (je nach Google Cloud-Dienst) 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 extra zu diesem Zweck entwickelt wurde. Das Ziel dabei: Sicherheit von Grund auf. 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. 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-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 Ablauf auf dedizierten Speichergeräten, wie z. B. SSDs, auf denen das Gerät den DEK auf Geräteebene verwaltet und schützt.

Diagramm: 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"

Der KMS von Google wird durch einen Root-Schlüssel mit dem Namen KMS-Masterschlüssel geschützt, der alle KEKs im KMS umfasst. 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 im RAM auf denselben dedizierten Maschinen wie Root KMS 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: 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 von 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 von Google Cloud 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 zu einem festen Zeitintervall 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. Sie beinhaltet unser gemäß FIPS 140-2 validiertes Modul BoringCrypto6.

Tink steht allen Google-Entwicklern zur Verfügung. Dank der konsistenten Nutzung einer allgemeinen Bibliothek muss dieser streng kontrollierte und geprüfte Code nur von einem kleinen Team von Kryptografen implementiert und gepflegt 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-Produkten

Je nach Google Cloud-Dienst werden die Daten mit unterschiedlichen Granularitätsstufen für die Verschlüsselung unterteilt.

  Google Cloud-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)
Datastore Pro Datenblock9
Firestore Pro Datenblock9
Cloud Spanner Pro Datenblock (mehrere pro Tabelle)
Cloud SQL
  • Zweite Generation: pro Instanz, wie in Compute Engine (jede Instanz kann mehrere Datenbanken enthalten)
  • Erste Generation: pro Instanz
Cloud Storage Pro Datenblock (in der Regel 256 KB bis 8 MB)
Compute 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
Google Kubernetes Engine Mehrere pro Laufwerk, für nichtflüchtige Speicher
Container Registry Gespeichert in Cloud Storage, pro Datenblock
Big Data BigQuery Mehrere pro Dataset
Dataflow Gespeichert in Cloud Storage, pro Datenblock
Datalab Gespeichert in Cloud Bigtable, pro Notebook-Datei
Dataproc Gespeichert in Cloud Storage, pro Datenblock
Pub/Sub Rotiert alle 30 Tage9

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

Zusätzlich zur standardmäßigen Verschlüsselung in Google Cloud bieten wir Kunden weitere Optionen für die Verschlüsselung und Schlüsselverwaltung. Damit diese in puncto Sicherheit und Schutz besser selbst bestimmen können.

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

  • Die endgültige Aufsicht über Ihre Daten in die eigene Hand zu nehmen sowie den Zugriff auf die Daten und deren Verwendung bis ins Detail zu steuern, damit Datensicherheit und Datenschutz noch besser gewährleistet sind
  • 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, die sie mit Google Cloud verwalten, als vom Kunden bereitgestellte Schlüssel verwenden. Dieses Feature ist für Cloud Storage und Compute Engine zur Verschlüsselung auf Speicherebene verfügbar.

Kunden können ihre Verschlüsselungsschlüssel in Google Cloud auch mit dem Cloud Key Management Service 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 Cloud-Dienste aufrechterhalten. Bei der Forschung und Entwicklung sowie der Umsetzung neuer kryptografischer Techniken arbeiten unsere Teams an folgenden Themen:

  • Teilweise homomorphe Kryptografie, welche 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 von Google Cloud

Allgemeine Informationen zur Sicherheit von Google Cloud finden Sie im Abschnitt "Sicherheit" auf der Google Cloud-Website.

Google Cloud-Compliance

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

G Suite-Sicherheit

Weitere Informationen zur Verschlüsselung und Schlüsselverwaltung in der 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 von G Suite.

Fußnoten

1 Ein Datenblock in Datastore, App Engine und 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 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 Datastore, App Engine oder Pub/Sub gespeichert sind, wo Daten mehrerer Kunden mit demselben DEK verschlüsselt werden können. Weitere Informationen finden Sie im 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 bietet genauso wie Tink neueren Kryptografiecode, 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 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 Google Cloud primär verwendeten Protokolle.
8 Bezieht sich auf die Granularität der Verschlüsselung für Kundeninhalte. Dazu gehören keine Kundenmetadaten wie Ressourcennamen. Bei einigen Diensten werden alle Metadaten mit einem einzigen DEK verschlüsselt.
9 Nicht einzigartig für einen einzelnen Kunden.
10 Enthält Anwendungscode und Anwendungseinstellungen. Die in App Engine verwendeten Daten werden je nach Kundenkonfiguration in Datastore, Cloud SQL oder Cloud Storage gespeichert.
11 Umfasst Funktionscode, Einstellungen und Ereignisdaten. Ereignisdaten werden in Pub/Sub gespeichert.