Verschlüsselung während der Übertragung

Dies ist das dritte Whitepaper zur Anwendung der Verschlüsselung bei Google zum Schutz Ihrer Daten. In diesem Whitepaper finden Sie ausführliche Informationen zur Verschlüsselung bei der Übertragung in Google Cloud und Google Workspace.

Der Schutz von Kundendaten und eine transparente Vorgehensweise zur Sicherung der Daten hat bei allen Google-Produkten oberste Priorität.

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

Zusammenfassung für CIOs

  • Google hat verschiedene Sicherheitsmaßnahmen etabliert, um die Authentizität, Integrität und Vertraulichkeit von Daten bei der Übertragung zu gewährleisten.
  • Für die in diesem Whitepaper beschriebenen Anwendungsfälle verschlüsselt und authentifiziert Google Daten bei der Übertragung in einer oder mehreren Netzwerkebenen, wenn sie außerhalb der von Google oder im Auftrag von Google kontrollierten physischen Grenzen übertragen werden. Der gesamte VM-zu-VM-Traffic in einem VPC-Netzwerk und Peering-VPC-Netzwerken ist verschlüsselt.
  • Je nach hergestellter Verbindung wendet Google standardmäßige Schutzmaßnahmen für die Daten an, die übertragen werden. Beispielsweise sichern wir die Kommunikation zwischen dem Nutzer und dem Google Front End (GFE) mithilfe von TLS.
  • Google Cloud-Kunden mit zusätzlichen Anforderungen an die Verschlüsselung von Daten über WAN können weitere Schutzfunktionen für Daten implementieren, die von einem Nutzer zu einer Anwendung oder von einer virtuellen Maschine zu einer anderen virtuellen Maschine übertragen werden. Zu diesen Schutzfunktionen gehören IPsec-Tunnel, Gmail S/MIME, verwaltete SSL-Zertifikate und Istio.
  • Google arbeitet aktiv mit der Branche zusammen, um die Verschlüsselung bei der Übertragung überall und für alle nutzbar zu machen. Wir haben mehrere Open-Source-Projekte, die die Verwendung von Verschlüsselung bei der Datenübertragung sowie die Datensicherheit im Internet insgesamt fördern. Dazu gehören Certificate Transparency, Chrome APIs und sicheres SMTP.
  • Google möchte seine führende Position im Bereich "Verschlüsselung bei der Übertragung" weiter ausbauen. Dazu haben wir Ressourcen zur Entwicklung und Verbesserung der Verschlüsselungstechnologie bereitgestellt. Zu unserer Tätigkeit auf diesem Gebiet gehören Innovationen in den Bereichen "Key Transparency" und "Post-Quanten-Kryptografie".

Einführung

Sicherheit ist oft ein entscheidender Faktor bei der Wahl eines öffentlichen Cloud-Anbieters. Für Google ist Sicherheit von allerhöchster Bedeutung. Wir arbeiten unermüdlich daran, Ihre Daten zu schützen – ob sie das Internet durchqueren, in der Google-Infrastruktur übertragen werden oder auf unseren Servern gespeichert sind.

Im Mittelpunkt der Sicherheitsstrategie von Google stehen Authentifizierung, Integrität und Verschlüsselung, sowohl für inaktive Daten als auch für Daten bei der Übertragung. In diesem Whitepaper wird unser Ansatz für die Verschlüsselung bei der Übertragung in Google Cloud dargestellt.

Weitere Informationen zur Verschlüsselung inaktiver Daten finden Sie im Whitepaper Inaktive Daten in der Google Cloud Platform verschlüsseln. Eine Übersicht aller Google-Sicherheitsfunktionen erhalten Sie im Dokument Übersicht über das Sicherheitsdesign der Infrastruktur von Google.

Zielgruppe: Dieses Dokument richtet sich an CISOs und Sicherheitsbetriebsteams, die Google Cloud verwenden bzw. deren Verwendung in Erwägung ziehen.

Voraussetzungen: Zusätzlich zu dieser Einführung werden grundlegende Kenntnisse zu Verschlüsselung und kryptografischen Primitiven vorausgesetzt.

Authentifizierung, Integrität und Verschlüsselung

Google hat verschiedene Sicherheitsmaßnahmen etabliert, um die Authentizität, Integrität und Vertraulichkeit von Daten bei der Übertragung zu gewährleisten.

  • Authentifizierung: Wir überprüfen die Datenquelle (ein Mensch oder ein Prozess) und das Ziel.
  • Integrität: Wir gewährleisten, dass die von Ihnen gesendeten Daten unverändert ihr Ziel erreichen.
  • Verschlüsselung: Wir machen Ihre Daten während der Übertragung unleserlich, damit sie vertraulich bleiben. Bei der Verschlüsselung werden lesbare Daten (Klartext) unleserlich gemacht (Geheimtext), damit der Klartext nur den vom Inhaber der Daten autorisierten Parteien zugänglich ist. Die im Verschlüsselungsprozess verwendeten Algorithmen sind öffentlich, der Schlüssel, der für die Entschlüsselung des Geheimtexts benötigt wird, ist aber privat. Zur Verschlüsselung bei der Übertragung wird häufig ein asymmetrischer Schlüsselaustausch wie der Diffie-Hellman-Schlüsselaustausch auf Basis elliptischer Kurven (Elliptic Curve Diffie-Hellman, ECDH) verwendet, um einen gemeinsam genutzten symmetrischen Schlüssel für die Datenverschlüsselung festzulegen. Weitere Informationen zur Verschlüsselung finden Sie unter Introduction to Modern Cryptography.

Durch Verschlüsselung können Daten in drei Zuständen geschützt werden:

  • Verschlüsselung inaktiver Daten: Schützt Ihre Daten vor einem Missbrauch des Systems oder vor Daten-Exfiltration, indem diese für die Speicherung verschlüsselt werden. Zum Verschlüsseln von inaktiven Daten wird häufig AES (Advanced Encryption Standard) verwendet.
  • Verschlüsselung bei der Übertragung: Schützt Ihre Daten, wenn die Kommunikation abgefangen wird, während Daten zwischen Ihrem Standort und dem Cloud-Anbieter oder zwischen zwei Diensten übertragen werden. Erreicht wird dieser Schutz durch Verschlüsselung der Daten vor der Übertragung, Authentifizierung der Endpunkte und beim Entschlüsseln und Prüfen, ob die Daten geändert wurden. So wird für den sicheren Datentransport zum Beispiel häufig TLS (Transport Layer Security) zum Verschlüsseln von Daten bei der Übertragung verwendet. S/MIME (Secure/Multipurpose Internet Mail Extensions) kommt außerdem häufig für die Verschlüsselung von E-Mail-Nachrichten zum Einsatz.
  • Verschlüsselung bei der Verwendung: Schützt Ihre Daten im Arbeitsspeicher vor Manipulationen und Daten-Exfiltration, indem diese für die Verarbeitung verschlüsselt werden. Weitere Informationen finden Sie unter Confidential Computing.

Die Verschlüsselung ist nur ein Bestandteil einer umfassenden Sicherheitsstrategie. Die Verschlüsselung während der Übertragung schützt Ihre Daten nach dem Herstellen und Authentifizieren einer Verbindung gegen potenzielle Angreifer durch:

  • Wegfall der Notwendigkeit, den unteren Ebenen des Netzwerks vertrauen zu müssen, die in der Regel von Dritten bereitgestellt werden
  • Reduzierung der potenziellen Angriffsfläche
  • Blockierung des Zugriffs von Angreifern auf Daten, wenn die Kommunikation abgefangen wird

Mit einer ausreichenden Authentifizierung, Integrität und Verschlüsselung können Daten geschützt werden, die zwischen Nutzern, Geräten oder Prozessen in einer feindlichen Umgebung übertragen werden. Im Folgenden werden der Ansatz von Google zur Verschlüsselung von Daten bei der Übertragung und seine typischen Einsatzsituationen erläutert.

Netzwerkinfrastruktur von Google

Physische Grenzen

Eine physische Grenze ist der Übergang zu einem physischen Bereich, der von Google oder im Auftrag von Google kontrolliert wird. In diesem Bereich können wir strenge Sicherheitsmaßnahmen garantieren. Der physische Zugang zu diesen Standorten ist eingeschränkt und wird streng überwacht. Nur wenige Google-Mitarbeiter haben Zugriff auf Hardware. Werden Daten innerhalb dieser physischen Grenzen übertragen, werden sie in der Regel authentifiziert, jedoch möglicherweise nicht standardmäßig verschlüsselt.

Wegen der Größenordnung des globalen Internets können wir für die Glasfaserverbindungen in unserem WAN oder außerhalb der physischen Grenzen, die von Google oder im Auftrag von Google kontrolliert werden, nicht die gleichen physischen Sicherheitskontrollen vornehmen. Deshalb etablieren wir außerhalb unserer physischen Vertrauensgrenze automatisch zusätzliche Schutzmaßnahmen. Zu diesen Maßnahmen gehört die Verschlüsselung von Daten bei der Übertragung für alle Zugriffe außerhalb unserer physischen Grenzen.

Weiterleitung des Traffics

Damit Sie die Funktionsweise der Google-Verschlüsselung bei der Übertragung besser verstehen, erklären wir außerdem, wie der Traffic über das Internet geleitet wird. In diesem Abschnitt wird nun erläutert, wie Anfragen eines Endnutzers den entsprechenden Google Cloud-Dienst oder die entsprechende Kundenanwendung erreichen und wie der Traffic zwischen Diensten weitergeleitet wird.

Ein Google Cloud-Dienst ist ein modularer Cloud-Dienst, den wir unseren Kunden anbieten. Zu den Modulen gehören Computing, Datenspeicherung, Datenanalyse und maschinelles Lernen. Cloud Storage ist beispielsweise ein Google Cloud-Dienst. Eine Kundenanwendung ist eine in Google Cloud gehostete Anwendung, die Sie als Google-Kunde mithilfe von Google Cloud-Diensten erstellen und bereitstellen können. Kundenanwendungen oder Partnerlösungen, die in Google Cloud gehostet werden, gelten nicht als Google Cloud-Dienste1. Eine Kundenanwendung ist beispielsweise eine Anwendung, die Sie mit Google App Engine, Google Kubernetes Engine oder mit einer virtuellen Maschine (VM) in Google Compute Engine erstellen.

Die fünf nachfolgend beschriebenen Arten von Routinganfragen sind in Abbildung 1 dargestellt. Diese Abbildung zeigt die Interaktionen zwischen den verschiedenen Netzwerkkomponenten und die Sicherheitsfunktionen für jede Verbindung.

Endnutzer (Internet) zu Google Cloud-Dienst

Google Cloud-Dienste akzeptieren Anfragen aus der ganzen Welt mithilfe eines global verteilten Systems namens „Google Front End“ (GFE). GFE beendet den Traffic für den eingehenden HTTP(S)-, TCP- und TLS-Proxy-Traffic, bietet Gegenmaßnahmen bei DDoS-Angriffen, leitet den Traffic an die Google Cloud-Dienste selbst weiter und sorgt für das Load-Balancing. Es sind weltweit GFE-Points-of-Presence mit Routen vorhanden, die über Unicast oder Anycast beworben werden.

GFEs leiten den Traffic zu Google Cloud-Diensten weiter. Dabei wird die Anfrage des Nutzers über unseren Netzwerk-Backbone an einen Google Cloud-Dienst übertragen. Diese Verbindung zum Frontend des Google Cloud-Dienstes oder der Kundenanwendung wird von GFE authentifiziert und verschlüsselt, wenn diese Kommunikation eine physische Grenze überschreitet, die von Google oder im Auftrag von Google kontrolliert wird. Abbildung 1 zeigt diese Interaktion (Verbindung A).

Endnutzer (Internet) zu einer Kundenanwendung, die in Google Cloud gehostet wird

Es gibt verschiedene Möglichkeiten, wie Traffic aus dem Internet zu einer Kundenanwendung weitergeleitet werden kann, die Sie in Google Cloud hosten. Die Art und Weise der Weiterleitung Ihres Traffics hängt wie im Folgenden beschrieben von Ihrer Konfiguration ab. Abbildung 1 zeigt diese Interaktion (Verbindung B).

Wenn Sie einen externen Application Load Balancer oder einen externen Proxy Network Load Balancer (mit einem SSL-Proxy) verwenden, finden Sie weitere Informationen unter Verschlüsselung vom Load-Balancer zu den Back-Ends.

Virtuelle Maschine zu virtueller Maschine

VM-zu-VM-Verbindungen in VPC-Netzwerken und Peering-VPC-Netzwerken innerhalb des Produktionsnetzwerks von Google werden authentifiziert und verschlüsselt. Dazu gehören Verbindungen zwischen Kunden-VMs und zwischen kundenseitigen und von Google verwalteten VMs wie Cloud SQL. Abbildung 1 zeigt diese Interaktion (Verbindung C). Beachten Sie, dass VM-zu-VM-Verbindungen, die externe IP-Adressen verwenden, nicht verschlüsselt sind.

Konnektivität zu Google APIs und Google-Diensten

Die Trafficverarbeitung hängt vom Standort des Google Cloud-Dienstes ab:

  • Die meisten Google APIs und Dienste werden auf Google Front Ends (GFEs) gehostet. Einige Dienste werden jedoch auf von Google verwalteten Instanzen gehostet. Beispiel: Der Zugriff auf private Dienste und die GKE-Master für private Cluster werden auf von Google verwalteten Instanzen gehostet.

    Mit dem privaten Google-Zugriff können VMs ohne externe IP-Adresse auf unterstützte Google APIs und Google-Dienste zugreifen, einschließlich Kundenanwendungen, die auf App Engine gehostet werden. Weitere Informationen zum Zugriff auf Google APIs und Google-Dienste finden Sie unter Private Zugriffsoptionen für Dienste.

  • Wenn eine Compute Engine-VM-Instanz eine Verbindung zur externen IP-Adresse einer anderen Compute Engine-VM-Instanz herstellt, verbleibt der Traffic im Produktionsnetzwerk von Google, wird aber aufgrund der Verwendung der externen IP-Adresse nicht verschlüsselt. Für Systeme außerhalb des Produktionsnetzwerks von Google, die mit einer externen IP-Adresse einer Compute Engine-VM-Instanz verbunden sind, wird Traffic über das Internet geleitet.

    Abbildung 1 zeigt einen externen Pfad (Verbindung D). Typische Beispiele für diese Art von Routinganfrage sind:

    • Von einer Compute Engine-VM zu Google Cloud Storage
    • Von einer Compute Engine-VM zu einer Machine Learning API

Von der VM zum GFE unterstützen Google Cloud-Dienste diese Verbindungen standardmäßig mit TLS.2 Die Verbindung wird vom GFE zum Dienst authentifiziert und wird verschlüsselt, wenn die Verbindung eine physische Grenze überschreitet. Zusätzlich zu diesen Standardschutzmaßnahmen können Sie die Umschlagverschlüsselung anwenden. Weitere Informationen finden Sie unter Daten verschlüsseln.

Google Cloud-Dienst zu Google Cloud-Dienst

Das Routing von einem Produktionsdienst zu einem anderen findet in unserem Netzwerk-Backbone statt und erfordert möglicherweise die Weiterleitung von Traffic außerhalb der physischen Grenzen, die von Google oder im Auftrag von Google kontrolliert werden. Abbildung 1 zeigt diese Interaktion (Verbindung E). Ein Beispiel für diese Art von Traffic ist ein Google Cloud Storage-Ereignis, das Google Cloud-Funktionen auslöst. Verbindungen zwischen Produktionsdiensten werden verschlüsselt, wenn sie eine physische Grenze überschreiten, und innerhalb der physischen Grenze authentifiziert.

Der Nutzer wird mithilfe der ALTS-Verschlüsselung an physische Google Cloud-Dienste weitergeleitet.

Abbildung 1: Standardmäßiger Schutz und Optionen in einem VPC-Netzwerk

Standardmäßige Verschlüsselung von Daten bei der Übertragung

Google verwendet für die Übertragung von Daten sowohl verschiedene standardisierte als auch vom Nutzer konfigurierbare Verschlüsselungsmethoden. Die Art der verwendeten Verschlüsselung hängt von der OSI-Schicht, der Art des Dienstes und der physischen Komponente der Infrastruktur ab. Die nachfolgenden Abbildungen 2 und 3 stellen die optionalen und standardmäßigen Schutzfunktionen dar, die Google Cloud für die Ebenen 3, 4 und 7 anwendet.

Verschlüsselungsoptionen für die Ebenen 3 und 4 umfassen Datentraffic zur VM und über Grenzen.

Abbildung 2: Standardmäßiger Schutz und Optionen auf den Ebenen 3 und 4 in Google Cloud

Verschlüsselungsoptionen für Ebene 7 beziehen sich auf die Übertragung von Daten zwischen VMs und zum Google Front End.

Abbildung 3: Standardmäßiger Schutz und Optionen auf Ebene 7 in Google Cloud3

Im weiteren Verlauf dieses Abschnitts werden die Standardschutzmaßnahmen dargestellt, die Google zum Schutz von Daten bei der Übertragung verwendet.

Verschlüsselung für Traffic vom Nutzer zu Google Front End

Heute verwenden viele Systeme HTTPS für die Kommunikation über das Internet. HTTPS bietet eine TLS-Verbindung, um die Authentifizierung, Integrität und Vertraulichkeit von Anfragen und Antworten zu garantieren. Zum Akzeptieren von HTTPS-Anfragen benötigt der Empfänger ein öffentlich-privates Schlüsselpaar und ein X.509-Zertifikat für die Serverauthentifizierung von einer Zertifizierungsstelle (Certificate Authority, CA). Mit dem Schlüsselpaar und dem Zertifikat werden Nutzeranfragen auf der Anwendungsebene (Ebene 7) geschützt. Diese Elemente sollen belegen, dass der Empfänger der Inhaber des Domainnamens ist, für den die Anfragen bestimmt sind. In den folgenden Unterabschnitten werden die Komponenten der Nutzer-zu-GFE-Verschlüsselung dargestellt: TLS, BoringSSL und die Zertifizierungsstelle (Certificate Authority, CA) von Google. Beachten Sie, dass nicht alle Kundenpfade über das GFE verlaufen. Das GFE wird insbesondere für den Traffic von einem Nutzer zu einem Google Cloud-Dienst und von einem Nutzer zu einer Kundenanwendung verwendet, die in Google Cloud mit Google Cloud Load Balancing gehostet wird.

Transport Layer Security (TLS)

Wenn ein Nutzer eine Anfrage an einen Google Cloud-Dienst sendet, sichern wir die Daten bei der Übertragung. Wir nutzen HTTPS mit einem Zertifikat von einer öffentlichen Web-Zertifizierungsstelle, um Authentifizierung, Integrität und Verschlüsselung zu bieten. Alle Daten, die der Nutzer an das GFE sendet, werden bei der Übertragung mit TLS (Transport Layer Security) oder QUIC verschlüsselt. GFE handelt mit dem Client ein bestimmtes Verschlüsselungsprotokoll aus, je nachdem, welches Protokoll der Client unterstützt. GFE versucht, so aktuelle Verschlüsselungsprotokolle wie möglich auszuhandeln.

Die skalierte TLS-Verschlüsselung von GFE wird nicht nur für Endnutzerinteraktionen mit Google verwendet. Damit werden auch API-Interaktionen mit Google über TLS, einschließlich Google Cloud, vereinfacht. Darüber hinaus wird unsere TLS-Verschlüsselung in Gmail für den Austausch von E-Mails mit externen E-Mail-Servern verwendet. Ausführliche Informationen dazu finden Sie unter TLS in Gmail festlegen.

Google ist sowohl bei der Anwendung von TLS als auch bei seiner verstärkten Implementierung Branchenführer. Dafür haben wir standardmäßig viele Sicherheitsfunktionen von TLS aktiviert. Beispielsweise verwenden wir seit 2011 Forward Secrecy in unserer TLS-Implementierung. Mit Forward Secrecy ist gewährleistet, dass der Schlüssel, der eine Verbindung schützt, nicht beibehalten wird. Ein Angreifer, der eine Nachricht abfängt und liest, kann deshalb vorherige Nachrichten nicht lesen.

BoringSSL

BoringSSL ist eine von Google gepflegte Open-Source-Implementierung des TLS-Protokolls, die von OpenSSL abgeleitet wurde und weitgehend schnittstellenkompatibel mit OpenSSL ist. BoringSSL wurde von Google aus OpenSSL abgeleitet, um OpenSSL zu vereinfachen, sowohl für den internen Einsatz als auch für eine verbesserte Unterstützung der Open-Source-Projekte Chromium und Android. BoringCrypto, der Kern von BoringSSL, wurde mit FIPS 140-2 Ebene 1 validiert.

TLS ist im GFE mit BoringSSL implementiert. Tabelle 1 zeigt die Verschlüsselungsprotokolle, die GFE bei der Kommunikation mit Clients unterstützt.

Protokolle Authentifizierung Schlüsselaustausch Verschlüsselung Hash-Funktionen
TLS 1.3 RSA-2048 Curve25519 AES-128-GCM SHA384
TLS 1.2 ECDSA P-256 P-256 (NIST secp256r1) AES-256-GCM SHA256
TLS 1.1     AES-128-CBC SHA17
TLS 1.04     AES-256-CBC MD58
QUIC5     ChaCha20-Poly1305  
      3DES6  

Tabelle 1: Implementierte Verschlüsselung im Google Front End für Google Cloud-Dienste und in der BoringSSL Cryptographic Library

Zertifizierungsstelle von Google

Als Teil von TLS muss ein Server dem Nutzer seine Identität nachweisen, wenn er eine Verbindungsanfrage erhält. Diese Identitätsbestätigung erfolgt im TLS-Protokoll durch Vorlage eines Zertifikats, in dem die vermeintliche Identität des Servers angegeben wird. Das Zertifikat enthält sowohl den DNS-Hostnamen des Servers als auch seinen öffentlichen Schlüssel. Das vorgelegte Zertifikat wird von einer ausstellenden Zertifizierungsstelle (Certificate Authority, CA) signiert, die von dem Nutzer anerkannt wird, der die Verbindung anfordert.9 Nutzer, die Verbindungen zum Server anfordern, müssen deshalb nur der Stamm-CA vertrauen. Wenn auf den Server flächendeckend zugegriffen werden soll, muss die Stamm-CA den Clientgeräten weltweit bekannt sein. Heutzutage haben die meisten Browser und andere Implementierungen von TLS-Clients jeweils eigene Stamm-CAs, die in ihrem "Stammspeicher" als vertrauenswürdig konfiguriert sind.

In der Vergangenheit hat Google eine eigene ausstellende CA betrieben, mit der wir Zertifikate für Google-Domains signiert haben. Allerdings hatten wir keine eigene Stamm-CA. Heute werden unsere CA-Zertifikate von mehreren Stamm-CAs signiert, die flächendeckend verbreitet sind, einschließlich DigiCert und Stamm-CAs, die bisher von GlobalSign betrieben wurden („GS Root R2” und „GS Root R4”).

Im Juni 2017 haben wir den Übergang zur Verwendung von Google-Stamm-CAs bekanntgegeben. Für die Zukunft planen wir den Betrieb einer flächendeckend verteilten Stamm-CA, die die Zertifikate für Google-Domains und für unsere Kunden ausstellt.

Migration von Stammschlüsseln und Schlüsselrotation

Stamm-CA-Schlüssel werden selten geändert, da bei der Migration zu einer neuen Stamm-CA alle Browser und Geräte die Vertrauensstellung dieses Zertifikats übernehmen müssen. Diese dauert eine gewisse Zeit. Deshalb werden wir, obwohl wir nun eigene Stamm-CAs betreiben, für eine Übergangszeit weiterhin auf mehrere Drittanbieter-Stamm-CAs zurückgreifen, um ältere Geräte berücksichtigen zu können, während wir zu unseren eigenen Stamm-CAs migrieren.

Für das Erstellen eines neuen Stamm-CA-Schlüssels ist eine Schlüsselzeremonie erforderlich. Bei Google müssen für eine Zeremonie mindestens drei der sechs möglichen autorisierten Personen vor Ort zusammenkommen, um die Hardwareschlüssel in Empfang zu nehmen, die in einem Safe aufbewahrt werden. Diese Personen treffen sich in einem speziell dafür vorgesehenen, von elektromagnetischen Störungen abgeschirmten Raum mit einem Hardwaresicherheitsmodul (HSM) mit Luftspalt. Dort generieren sie dann ein Set von Schlüsseln und Zertifikaten. Der entsprechende Raum befindet sich an einem sicheren Ort in Google-Rechenzentren. Zusätzliche Kontrollen durch physische Sicherheitsmaßnahmen, Kameras und weitere Aufsichtspersonen sollen gewährleisten, dass der Prozess wie geplant abläuft. Wenn die Zeremonie erfolgreich verläuft, entspricht das generierte Zertifikat einem Beispielzertifikat, mit Ausnahme des Ausstellernamens, des öffentlichen Schlüssels und der Signatur. Das generierte Stamm-CA-Zertifikat wird dann Browser- und Geräte-Root-Programmen zur Integration übergeben. Dieser Vorgang soll dafür sorgen, dass ein ausreichendes Verständnis der Vertraulichkeit und der Sicherheit der zugehörigen privaten Schlüssel vorhanden ist, damit die Schlüssel für mindestens ein Jahrzehnt sicher verwendet werden können.

Wie weiter oben dargestellt verwenden Zertifizierungsstellen (Certificate Authorities, CAs) ihre privaten Schlüssel zum Signieren von Zertifikaten. Diese Zertifikate sollen Identitäten bestätigen, wenn ein TLS-Handshake im Rahmen einer Nutzersitzung initiiert wird. Serverzertifikate werden mit Zwischen-CAs signiert, die wie Stamm-CAs erstellt werden. Die Zertifikate von Zwischen-CAs werden im Rahmen der TLS-Sitzung verteilt, um die Migration auf eine neue Zwischen-CA zu vereinfachen. Mit dieser Verteilungsmethode kann der CA-Betreiber das Stamm-CA-Schlüsselmaterial auch im Offlinestatus belassen.

Die Sicherheit einer TLS-Sitzung hängt davon ab, wie gut der Schlüssel des Servers geschützt ist. Die Lebensdauer eines Google-TLS-Zertifikats ist auf ungefähr drei Monate begrenzt, um das Risiko eines Schlüsselmissbrauchs weiter zu verringern. Außerdem werden die Zertifikate etwa alle zwei Wochen rotiert.

Ein Client, der zuvor eine Verbindung zu einem Server hergestellt hat, kann mit einem privaten Ticketschlüssel10 eine vorherige Sitzung mit einem verkürzten TLS-Handshake fortsetzen. Dadurch werden diese Tickets zu einem sehr beliebten Ziel für Angreifer. Google rotiert die Ticket-Schlüssel mindestens einmal am Tag. Außerdem verfallen diese Schlüssel alle drei Tage für alle Attribute. Weitere Informationen zur Rotation von Sitzungsschlüssel-Tickets finden Sie unter Measuring the Security Harm of TLS Crypto Shortcuts.

Google Front End zu Anwendungs-Frontends

In einigen Fällen wird, wie in Weiterleitung des Traffics dargestellt, der Nutzer mit einem GFE innerhalb eines anderen physischen Bereichs als dem gewünschten Dienst und dem zugehörigen Anwendungs-Frontend verbunden. In diesem Fall werden die Anfrage des Nutzers und jedes andere Protokoll der Ebene 7 (z. B. HTTP) entweder durch TLS geschützt oder in einem RPC gekapselt, der mit ALTS (Application Layer Transport Security) geschützt ist, wie unter Authentifizierung, Integrität und Verschlüsselung von Dienst zu Dienst dargestellt. Diese RPCs werden authentifiziert und verschlüsselt.

Bei Google Cloud-Diensten sind RPCs mit ALTS geschützt. Bei Kundenanwendungen, die in Google Cloud gehostet werden, wird der Traffic zur VM, wenn er über das Google Front End weitergeleitet wird (etwa bei Verwendung von Google Cloud Load Balancer), mit der virtuellen Netzwerkverschlüsselung von Google Cloud geschützt. Diese wird im folgenden Abschnitt erläutert.

Virtuelle Netzwerkverschlüsselung und -authentifizierung von Google Cloud

Die Verschlüsselung des privaten IP-Traffics innerhalb derselben VPC oder über Peering-VPC-Netzwerke innerhalb des virtuellen Netzwerks von Google Cloud erfolgt auf Netzwerkebene.

Wir verwenden für die Implementierung der Verschlüsselung auf der Netzwerkebene den Advanced Encryption Standard (AES) im Galois/Counter-Modus (GCM) mit einem 128-Bit-Schlüssel (AES-128-GCM). Jedes Paar kommunizierender Hosts richtet einen Sitzungsschlüssel über einen von ALTS geschützten Kontrollkanal für eine authentifizierte und verschlüsselte Kommunikation ein. Der Sitzungsschlüssel wird zum Verschlüsseln der gesamten VM-zu-VM-Kommunikation zwischen diesen Hosts verwendet. Sitzungsschlüssel werden außerdem regelmäßig rotiert.

Auf der Netzwerkebene (Ebene 3) authentifiziert das virtuelle Netzwerk von Google Cloud den gesamten Traffic zwischen VMs. Diese Authentifizierung, die über Sicherheitstoken erfolgt, schützt einen angegriffenen Host vor Spoofing-Paketen im Netzwerk.

Bei der Authentifizierung werden Sicherheitstokens in einen Tunnel-Header eingekapselt, der Authentifizierungsinformationen über den Sender und den Empfänger enthält. Auf der Kontrollebene11 des Senders wird das Token festgelegt, das der empfangende Host validiert. Sicherheitstokens werden für jeden Datenfluss vorab generiert und bestehen aus einem Tokenschlüssel (der die Informationen des Senders enthält) und dem geheimen Hostschlüssel. Für jedes Quell-/Empfängerpaar in physischen Grenzen, die von Google oder im Auftrag von Google kontrolliert werden, ist ein geheimer Schlüssel vorhanden.

Abbildung 4 zeigt, wie Tokenschlüssel, geheime Hostschlüssel und Sicherheitstokens erstellt werden.

Grafik: Die Komponenten der Sicherheitstokens können einen Tokenschlüssel und ein Host-Secret sowie deren Abhängigkeiten enthalten.

Abbildung 4: Sicherheitstokens

Der geheime Schlüssel für eine physische Grenze ist eine 128-Bit-Pseudozufallszahl, aus der geheime Hostschlüssel durch Aufnahme eines HMAC-SHA1 abgeleitet werden. Der geheime Schlüssel der physischen Grenze wird durch einen Handshake zwischen den Netzkontrollebenen eines Paares physischer Grenzen alle paar Stunden neu ausgehandelt. Die Sicherheitstokens, die für die individuelle VM-zu-VM-Authentifizierung verwendet und von diesen und anderen Eingaben abgeleitet werden, sind HMACs, die für ein bestimmtes Sender- und Empfängerpaar ausgehandelt werden.

Verschlüsselung für Traffic von virtueller Maschine zu Google Front End

Bei Traffic von einer VM zum GFE werden externe IP-Adressen verwendet, um Google-Dienste zu erreichen. Sie können jedoch die Funktion Privater Zugriff so konfigurieren, dass ausschließlich Google-IP-Adressen für die Anfragen verwendet werden.

Standardmäßig unterstützen wir TLS-Traffic von einer VM zum GFE. Die Verbindung wird wie jede andere externe Verbindung hergestellt. Weitere Informationen zu TLS finden Sie unter Transport Layer Security (TLS).

Authentifizierung, Integrität und Verschlüsselung von Dienst zu Dienst

In der Google-Infrastruktur verwenden wir in der Anwendungsschicht (Schicht 7) unser Protokoll Application Layer Transport Security (ALTS) zur Authentifizierung, Integritätsprüfung und Verschlüsselung von Google-RPC-Aufrufen vom GFE zu einem Dienst und von Dienst zu Dienst.

ALTS nutzt Dienstkonten zur Authentifizierung. Jeder in der Google-Infrastruktur ausgeführte Dienst wird als Dienstkontoidentität mit den zugehörigen kryptografischen Anmeldedaten ausgeführt. Beim Erstellen oder Empfangen von RPCs von anderen Diensten werden von einem Dienst dessen Anmeldedaten zur Authentifizierung verwendet. ALTS überprüft diese Anmeldedaten mithilfe einer internen Zertifizierungsstelle (Certificate Authority, CA).

Innerhalb einer physischen Grenze, die von Google oder im Auftrag von Google kontrolliert wird, bietet ALTS sowohl Authentifizierung als auch Integritätsprüfung für RPCs im Modus "Authentifizierung und Integrität". Für den Traffic über das WAN außerhalb der physischen Grenzen, die von Google oder im Auftrag von Google kontrolliert werden, erzwingt ALTS die Verschlüsselung für den RPC-Traffic der Infrastruktur automatisch im Modus "Authentifizierung, Integrität und Datenschutz". Derzeit profitiert jeder Traffic zu Google-Diensten, einschließlich Google Cloud-Diensten, von diesen Schutzmaßnahmen.

ALTS wird auch zum Kapseln anderer Ebene-7-Protokolle, z. B. HTTP, in Infrastruktur-RPC-Verfahren für den Traffic von Google Front End zum Anwendungs-Frontend verwendet. Dieser Schutz isoliert die Anwendungsschicht und macht sie von der Sicherheit des Netzwerkpfads unabhängig.

Sicherheitsinfrastrukturdienste können so konfiguriert werden, dass sie die ALTS-Kommunikation nur im Modus "Authentifizierung, Integrität und Datenschutz" akzeptieren und senden. Dies gilt auch innerhalb der physischen Grenzen, die von Google oder im Auftrag von Google kontrolliert werden. Ein Beispiel ist Keystore, in dem die Verschlüsselungsschlüssel zum Schutz inaktiver Daten gespeichert und verwaltet werden, die in der Google-Infrastruktur gespeichert sind.

Netzwerkverschlüsselung mit PSP

Das PSP-Sicherheitsprotokoll (PSP) ist unabhängig vom Transport, ermöglicht die Sicherheit pro Verbindung und unterstützt die Auslagerung der Verschlüsselung auf Hardware der Smart Network Interface Card (SmartNIC). Wenn SmartNICs verfügbar sind, verwenden wir PSP, um Daten bei der Übertragung in unserem Netzwerk zu verschlüsseln.

Der PSP wurde so konzipiert, dass er die Anforderungen großer Traffic von Rechenzentren erfüllt. Wir verwenden PSP, um den Traffic in und zwischen unseren Rechenzentren zu verschlüsseln. PSP unterstützt Nicht-TCP-Protokolle wie UDP und verwendet für jede Ebene-4-Verbindung einen Verschlüsselungsschlüssel.

Weitere Informationen zur Verwendung von PSP finden Sie unter Bekanntgabe von kryptografischer Hardwareauslagerung von PSP für Open-Source-Lösungen.

ALTS-Protokoll

ALTS hat ein sicheres Handshakeprotokoll, das weitgehend der wechselseitigen TLS-Authentifizierung entspricht. Wenn zwei Dienste unter Verwendung von ALTS kommunizieren möchten, verwenden sie dieses Handshakeprotokoll zur Authentifizierung und Aushandlung von Kommunikationsparametern, bevor sie vertrauliche Informationen senden. Das Protokoll löst einen zweistufigen Prozess aus:

  • Schritt 1: Handshake. Der Client initiiert einen ECDH-Handshake (Elliptic Curve Diffie-Hellman) mit dem Server mithilfe von Curve25519. Der Client und der Server haben jeweils zertifizierte öffentliche ECDH-Parameter im Rahmen ihres Zertifikats, das während eines Diffie-Hellman-Schlüsselaustauschs verwendet wird. Durch den Handshake wird ein allgemeiner Traffic-Schlüssel erzeugt, der auf dem Client und dem Server verfügbar ist. Die Peer-Identitäten aus den Zertifikaten werden auf die Anwendungsebene übertragen, um sie bei Autorisierungsentscheidungen einzusetzen.
  • Schritt 2: Verschlüsselung mit Aufzeichnungsprotokoll. Hier werden Daten mithilfe des gemeinsamen Schlüssels für Traffic aus Schritt 1 sicher vom Client zum Server übertragen. Die Verschlüsselung in ALTS wird mithilfe von BoringSSL und anderen Verschlüsselungsbibliotheken implementiert. Sie erfolgt in der Regel mit AES-128-GCM. Die Integritätsprüfung wird durch GMAC von AES-GCM gewährleistet.

Das folgende Diagramm zeigt den ALTS-Handshake im Detail. In neueren Implementierungen führt ein Prozesshelfer den Handshake aus. Es gibt aber noch Fälle, in denen dies direkt durch die Anwendungen erfolgt.

Die Clientanwendung interagiert über einen Prozessaustausch mit einem Handshakedienst und mit der Serveranwendung über einen Schlüsselaustausch.

Abbildung 5: ALTS-Handshake

Wie zu Beginn des Abschnitts Authentifizierung, Integrität und Verschlüsselung von Dienst zu Dienst dargestellt, verwendet ALTS Dienstkonten zur Authentifizierung. Dabei wird jeder Dienst, der in der Infrastruktur von Google ausgeführt wird, als Dienstidentität mit den zugehörigen kryptografischen Anmeldedaten ausgeführt. Beim ALTS-Handshake greift der Prozesshelfer auf die privaten Schlüssel und die entsprechenden Zertifikate zu, die jedes Client-/Server-Paar für seine Kommunikation verwendet. Der private Schlüssel und das entsprechende Zertifikat (signierter Protokollpuffer) wurden für die Dienstkontoidentität des Dienstes bereitgestellt.

ALTS-Zertifikate Es gibt mehrere Arten von ALTS-Zertifikaten:

  • Computerzertifikate: Diese geben eine Identität für Hauptdienste auf einem bestimmten Computer an. Sie werden etwa alle sechs Stunden rotiert.
  • Nutzerzertifikate: Diese Zertifikate geben eine Endnutzeridentität für einen Google-Code-Entwickler an. Sie werden etwa alle 20 Stunden rotiert.
  • Borg-Jobzertifikate: Diese Zertifikate geben eine Identität für Jobs an, die in der Google-Infrastruktur ausgeführt werden. Sie werden etwa alle 48 Stunden rotiert.

Der Signaturschlüssel für die Stammzertifizierung wird in der internen Google-Zertifizierungsstelle gespeichert, die unabhängig von unserer externen CA ist.

Verschlüsselung in ALTS

Die Verschlüsselung in ALTS kann je nach verwendeten Maschinen mithilfe einer Vielzahl von Algorithmen implementiert werden. Die meisten Dienste verwenden beispielsweise AES-128-GCM.12 Weitere Informationen zur ALTS-Verschlüsselung finden Sie in Tabelle 2.

Maschinen Verwendete Nachrichtenverschlüsselung  
Häufigste Maschinen AES-128-GCM  
Sandy Bridge oder älter AES-128-VCM Verwendet einen VMAC anstelle eines GMAC und ist etwas effizienter auf diesen älteren Maschinen.

Tabelle 2: Verschlüsselung in ALTS

Die meisten Google-Dienste verwenden ALTS oder die RPC-Kapselung, die ALTS nutzt. Wenn ALTS nicht verwendet wird, sind andere Schutzmaßnahmen implementiert. Beispiel:

  • Einige Low-Level-Verwaltungs- und Bootstrapping-Dienste für Maschinen verwenden SSH.
  • Einige Low-Level-Logging-Dienste für die Infrastruktur verwenden TLS oder Datagram TLS (DTLS).13
  • Einige Dienste, die ein anderes Übertragungsprotokoll als TCP verwenden, setzen innerhalb der von Google oder im Auftrag von Google kontrollierten physischen Grenzen andere kryptografische Protokolle oder Schutzfunktionen auf Netzwerkebene ein.

Für den Austausch zwischen VMs und Google Cloud Platform-Diensten wird TLS und nicht ALTS zur Kommunikation mit Google Front End verwendet. Diese Kommunikation wird unter Verschlüsselung für Traffic von virtueller Maschine zu Google Front End erläutert.

Andere Verschlüsselung während der Übertragung konfigurieren

Sie können Schutzmaßnahmen für Ihre Daten konfigurieren, wenn sie zwischen Google Cloud und Ihren Rechenzentren oder bei der Übertragung zwischen Ihren Anwendungen übertragen werden, die in Google Cloud und auf Nutzergeräten gehostet werden.

Beachten Sie Folgendes, wenn Sie Ihr Rechenzentrum mit Google Cloud verbinden:

Wenn Sie Ihre Nutzergeräte mit Anwendungen verbinden, die in Google Cloud ausgeführt werden, beachten Sie Folgendes:

  • Verwenden Sie das GFE-Support für TLS, indem Sie das von Ihnen verwendete SSL-Zertifikat konfigurieren. Beispielsweise haben Sie die Möglichkeit, die TLS-Sitzung in Ihrer Anwendung zu beenden.
  • Beachten Sie unsere kostenlosen und automatisierten SSL-Zertifikate, die für benutzerdefinierte Domains wie Firebase Hosting und App Engine verfügbar sind. Mit benutzerdefinierten App Engine-Domains können Sie außerdem Ihre eigenen SSL-Zertifikate bereitstellen und einen HSTS-Header (HTTP Strict Transport Security) verwenden.
  • Prüfen Sie für Arbeitslasten in GKE und Compute Engine das GKE Enterprise Service Mesh, damit Sie mTLS für die Authentifizierung verwenden können. So wird die gesamte TCP-Kommunikation während der Übertragung verschlüsselt.

Wenn Sie Google Workspace verwenden, müssen Sie Gmail konfigurieren, um S/MIME für ausgehende E-Mails zu aktivieren. Außerdem müssen Sie Richtlinien für Inhalte einrichten und Complianceregeln für Anhänge und Routingregeln für eingehende und ausgehende E-Mails erstellen.

Forschung und Innovation bei der Verschlüsselung während der Übertragung

Im Laufe der Jahre haben wir uns an mehreren Open-Source-Projekten und anderen Maßnahmen beteiligt, die die Verwendung der Verschlüsselung bei der Übertragung im Internet fördern.

Dazu gehören:

Weitere Informationen zu unseren neuesten Beiträgen finden Sie unter Zusammenarbeit mit der Sicherheitsforschungs-Community.

Nächste Schritte

Fußnoten

1 Partnerlösungen umfassen sowohl Lösungen, die in Cloud Launcher angeboten werden, als auch Produkte wie Cloud Dataprep, die in Zusammenarbeit mit Partnern entstehen.
2 Sie können diese Verschlüsselung weiterhin deaktivieren, z. B. für den HTTP-Zugriff auf Google Cloud Storage-Buckets.
3 Die VM-zu-Dienst-Kommunikation, die auf Ebene 7 nicht geschützt ist, ist auf den Ebenen 3 und 4 weiterhin geschützt.
4 Google unterstützt TLS 1.0 für Browser, die diese Version des Protokolls weiterhin verwenden. Beachten Sie, dass für die Verarbeitung von Kreditkarteninformationen durch Google-Websites TLS 1.0 ab Juli 2018 nicht mehr unterstützt wird. Ab diesem Zeitpunkt ist die Einhaltung der Regeln der Payment Card Industry (PCI) obligatorisch.
5 Ausführliche Informationen zu QUIC finden Sie unter https://www.chromium.org/quic.
6, 7, 8 Für die Abwärtskompatibilität mit einigen älteren Betriebssystemen unterstützen wir 3DES, SHA1 und MD5.
9 Bei verketteten Zertifikaten ist die CA vorübergehend vertrauenswürdig.
10 Dies kann entweder ein Sitzungs-Ticket (RFC 5077) oder eine Sitzungs-ID (RFC 5246) sein.
11 Die Steuerungsebene ist jener Teil des Netzwerks, der Signalisierungstraffic überträgt und für das Routing verantwortlich ist.
12 Bisher wurden andere Protokolle verwendet, die jetzt verworfen wurden. Weniger als 1 % der Jobs nutzen diese älteren Protokolle.
13 Datagram TLS (DTLS) bietet Sicherheitsfunktionen für Datagram-basierte Anwendungen, damit diese ohne Abhören und Manipulation kommunizieren können.