Verschlüsselung bei der Übertragung in Google Cloud

Dies ist das dritte Whitepaper zur Anwendung der Verschlüsselung bei Google zum Schutz Ihrer Daten. Zuvor wurden bereits die Whitepapers Verschlüsselung inaktiver Daten in der Google Cloud Platform undG Suite-Verschlüsselung veröffentlicht. Auch diese Dokumente bieten nützliche Informationen zur Anwendung der Verschlüsselung bei Google. Im vorliegenden Whitepaper finden Sie ausführliche Informationen zur Verschlüsselung bei der Übertragung für Google Cloud, einschließlich der Google Cloud Platform und G Suite.

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

Der Inhalt basiert auf den im Dezember 2017 vorliegenden Informationen. Das Whitepaper gibt damit den Status quo zum Zeitpunkt der Verfassung des Textes wieder. Die Sicherheitsrichtlinien und -systeme von Google Cloud können sich aber nachfolgend ändern, da wir den Schutz unserer Kunden kontinuierlich verbessern.

Wiedergabeschaltfläche

Google Cloud-Verschlüsselung bei der Übertragung

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.
  • Google verschlüsselt und authentifiziert diese auf einer oder mehreren Netzwerkebenen, wenn Daten außerhalb der physischen Grenzen übertragen werden, die von Google oder im Auftrag von Google kontrolliert werden. Daten bei der Übertragung, die innerhalb einer physischen Grenze übertragen werden, die von Google oder im Auftrag von Google kontrolliert wird, werden in der Regel zwar authentifiziert, aber nicht notwendigerweise verschlüsselt.
  • Je nach hergestellter Verbindung wendet Google standardmäßige Schutzmaßnahmen für Daten bei der Übertragung an. So sichern wir beispielsweise 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 zur Förderung der Verwendung von Verschlüsselung bei der Übertragung und der Datensicherheit im Internet insgesamt. Dazu gehören Zertifikatstransparenz, 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 von 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 Cloudanbieters. Für Google ist Sicherheit von allerhöchster Bedeutung. Wir arbeiten ohne Unterlass daran, Ihre Daten zu schützen – ob sie nun im Internet übertragen, in der Google-Infrastruktur gesendet oder auf unseren Servern gespeichert werden.

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 eine Verschlüsselung bei der Übertragung für Google Cloud dargestellt.

Informationen zur Verschlüsselung inaktiver Daten finden Sie unter Inaktive Daten in der Google Cloud Platform verschlüsseln. Eine Übersicht aller Google-Sicherheitsfunktionen erhalten Sie unter Ü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 (Chiffretext), 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 Chiffretexts benötigt wird, ist aber privat. Beim Verschlüsseln 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 zu Verschlüsselung finden Sie unter Introduction to Modern Cryptography (Einführung in die moderne Kryptografie).

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

  • Verschlüsselung inaktiver Daten: Diese schützt Ihre Daten vor einem Missbrauch des Systems oder vor einer Datenweitergabe, 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: Diese schützt Ihre Daten, wenn die Kommunikation abgefangen wird, während Daten zwischen Ihrem Standort und dem Cloudanbieter oder zwischen zwei Diensten übertragen werden. Dieser Schutz wird durch Verschlüsselung der Daten vor der Übertragung, durch Authentifizierung der Endpunkte und durch Entschlüsselung sowie Überprüfung der Daten bei Empfang erreicht. So wird etwa zum Verschlüsseln von Daten bei der Übertragung häufig TLS (Transport Layer Security) verwendet, um die Sicherheit bei der Übertragung zu gewährleisten. S/MIME (Secure/Multipurpose Internet Mail Extensions) kommt zudem häufig für die Sicherheit von E-Mail-Nachrichten zum Einsatz.
  • Verschlüsselung bei der Verwendung: Diese schützt Ihre Daten, wenn sie von Servern zur Ausführung von Berechnungen verwendet werden, z. B. homomorphe Verschlüsselung.

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 des Google-Netzwerks

Google wendet verschiedene Schutzmaßnahmen für übertragene Daten an, wenn sie außerhalb einer von Google oder im Auftrag von Google kontrollierten physischen Grenze übertragen werden. 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 ein kleiner Prozentsatz der Google-Mitarbeiter hat Zugriff auf Hardware. Werden Daten innerhalb dieser physischen Grenzen übertragen, werden sie in der Regel authentifiziert, jedoch möglicherweise nicht standardmäßig verschlüsselt. Sie können wählen, welche zusätzlichen Sicherheitsmaßnahmen auf der Grundlage Ihres Bedrohungsmodells angewendet werden sollen.

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 übertragenen Daten.

Weiterleitung des Traffics

Im vorherigen Abschnitt wurden die physische Grenze des Google-Netzwerks und die Anwendung verschiedener Schutzverfahren für Daten außerhalb dieser Grenze dargestellt. Zum Verständnis der Funktionsweise der Google-Verschlüsselung bei der Übertragung gehört auch die Art und Weise, wie der Traffic über das Internet geleitet wird. In diesem Abschnitt wird 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 Clouddienst, den wir unseren Kunden anbieten. Zu den Modulen gehören Computing, Datenspeicherung, Datenanalyse und maschinelles Lernen. Google Cloud Storage und Gmail sind beispielsweise beides Google Cloud-Dienste. 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 nimmt dabei einen Lastenausgleich vor. 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 von GFEs die Anfrage des Nutzers über unseren Netzwerk-Backbone an einen Google Cloud-Dienst übertragen. Diese Verbindung zum Front-End 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 stellt diese Interaktion dar (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).

  • Verwendung eines Google Cloud-HTTP(S)- oder -TCP/SSL-Proxy-Load-Balancers – externer Load-Balancer: Eine auf Google Compute Engine-VMs gehostete Kundenanwendung kann mit einem Google Cloud Load Balancer (GCLB) HTTP(S)-, TLS- oder TCP-Verbindungen beenden und diesen Traffic zu den entsprechenden VMs weiterleiten und verteilen. Diese Load-Balancing-Dienste werden von den GFEs implementiert, wenn GFEs den Traffic für Google Cloud-Dienste beenden und weiterleiten. Wenn der GCLB den Traffic zwischen GFEs weiterleitet, werden die Verbindungen authentifiziert und verschlüsselt, wenn der Traffic eine physische Grenze überschreitet, die von Google oder im Auftrag von Google kontrolliert wird. Leitet der GCLB den Traffic zwischen einem GFE und einem physischen Computer weiter, der die VM eines Kunden hostet, wird dieser Traffic authentifiziert und verschlüsselt, wenn er eine physische Grenze überschreitet, die von Google oder im Auftrag von Google kontrolliert wird. Bei HTTPS-Load-Balancern werden Verbindungen zwischen Endnutzern und dem GFE mithilfe von Zertifikaten, die Kunden dem Load-Balancer bereitstellen, mit TLS oder QUIC verschlüsselt und authentifiziert. Bei HTTP-Load-Balancern werden Verbindungen zwischen Endnutzern und GFE nicht verschlüsselt und nicht authentifiziert. Bei SSL-Load-Balancern werden Verbindungen zwischen Endnutzern und dem GFE mit TLS verschlüsselt, wobei ebenfalls von Kunden bereitgestellte Zertifikate verwendet werden. Bei TCP-Load-Balancern wird die Verbindung zwischen dem Endnutzer und dem GFE nicht verschlüsselt. Die Kundenanwendung kann jedoch eine eigene Verschlüsselung zwischen dem Endnutzer und den VMs verwenden.
  • Verwendung einer direkten Verbindung zu einer VM mit externer IP oder IP für den Netzwerk-Load-Balancer: Wenn Sie eine Verbindung über die externe IP-Adresse der VM oder über eine IP-Adresse für das Netzwerk-Load-Balancing herstellen, erfolgt die Verbindung nicht über das GFE. Diese Verbindung ist standardmäßig nicht verschlüsselt und entsprechende Sicherheitsmaßnahmen müssen vom Nutzer festgelegt werden.
  • Verwendung eines Cloud-VPN: Wenn Sie eine Verbindung von einem lokalen Host mit einer Google Cloud-VM über ein VPN herstellen, verläuft die Verbindung von/zu Ihrem lokalen Host zum lokalen VPN, zum Google-VPN und zur Google Cloud-VM nicht über das GFE. Der Schutz der Verbindung über das lokale VPN zum Google-VPN erfolgt mit IPsec. Die Verbindung vom Google-VPN zur Google Cloud-VM wird authentifiziert und verschlüsselt, wenn diese Kommunikation eine physische Grenze überschreitet, die von Google oder im Auftrag von Google kontrolliert wird.
  • Verwendung von Cloud Dedicated Interconnect: Wenn Sie eine Verbindung über Dedicated Interconnect herstellen, erfolgt diese direkt vom/zum lokalen Host. Die Verbindung verläuft nicht über das GFE. Sie ist standardmäßig nicht verschlüsselt und entsprechende Sicherheitsmaßnahmen müssen vom Nutzer festgelegt werden. Sie können das Verschlüsselungsprotokoll Transport Layer Security (TLS) der Ebene 7 zur Verschlüsselung von Traffic von Anwendungen über Dedicated Interconnect verwenden.

Virtuelle Maschine zu virtueller Maschine

Für das Routing von VM zu VM, das in unserem Netzwerk-Backbone unter Verwendung privater RFC1918-IP-Adressen erfolgt, ist möglicherweise die Weiterleitung von Traffic außerhalb der physischen Grenzen, die von Google oder im Auftrag von Google kontrolliert werden, erforderlich. Beispiele für ein VM-zu-VM-Routing:

  • Compute Engine-VMs senden wechselseitig Anfragen
  • Eine Kunden-VM, die eine Verbindung mit einer von Google verwalteten VM wie Cloud SQL herstellt

VM-zu-VM-Verbindungen werden verschlüsselt, wenn sie eine physische Grenze überschreiten, und innerhalb der physischen Grenze authentifiziert. VM-zu-VM-Traffic, der öffentliche IP-Adressen verwendet, ist standardmäßig nicht verschlüsselt. Entsprechende Sicherheitsmaßnahmen müssen vom Nutzer festgelegt werden. Abbildung 1 zeigt diese Interaktion (Verbindung C).

Virtuelle Maschine zu Google Cloud-Dienst

Wenn eine VM eine Anfrage an einen Google Cloud-Dienst übergibt, wird diese an ein GFE weitergeleitet (außer in Fällen, in denen der Google Cloud-Dienst auf einer von Google verwalteten VM wie oben erläutert ausgeführt wird). Das GFE empfängt die Anfrage und leitet diese wie eine Anfrage aus dem Internet weiter: Traffic von einer VM zu einem Google Cloud-Dienst wird über private Google-Pfade an die gleichen öffentlichen IPs für die GFEs weitergeleitet. Mit dem privaten Google-Zugriff können VMs ohne öffentliche IP-Adressen auf einige Google Cloud-Dienste und Kundenanwendungen zugreifen, die in Google App Engine gehostet werden. Beachten Sie dabei Folgendes: Wenn eine VM eine Verbindung mit einer Kundenanwendung herstellt, die in Google Compute Engine oder Google Kubernetes Engine gehostet wird, wird dieser Traffic auf die gleiche Weise über externe Pfade wie bei Anfragen aus dem Internet weitergeleitet. Abbildung 1 zeigt diese Interaktion (Verbindung D). Ein Beispiel für diese Art von Routinganfrage ist eine Anfrage von einer Compute Engine-VM an Google Cloud Storage oder an eine Machine Learning API. Google Cloud-Dienste unterstützen standardmäßig den Schutz dieser Verbindungen mit TLS2. Dieser Schutz ist auch von der VM zum GFE vorhanden. Die Verbindung wird vom GFE zum Dienst authentifiziert und wird verschlüsselt, wenn die Verbindung eine physische Grenze überschreitet.

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.

Abbildung 1: Standardmäßiger Schutz und Optionen im Google-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.

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

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

Heutzutage verwenden viele Systeme das HTTPS-Protokoll für die Kommunikation über das Internet. Für sichere Übertragungen leitet HTTPS das Protokoll über eine TLS-Verbindung. Dies gewährleistet die Authentizität, Integrität und Vertraulichkeit von Anfragen und Antworten. 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 Domain-Namens 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 Google-Zertifizierungsstelle (CA). 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 und stellen eine Authentifizierung, Integrität und Verschlüsselung unter Verwendung des HTTPS-Protokolls mit einem Zertifikat einer (öffentlichen) Web-Zertifizierungsstelle bereit. 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 der 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.34 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 SHA18
TLS 1.05     AES-256-CBC MD59
QUIC6     ChaCha20-Poly1305  
      3DES7  

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

Google-Zertifizierungsstelle

Eine Sicherheitsfunktion von TLS besteht darin, dass ein Server seine Identität gegenüber einem Nutzer nachweisen muss, wenn er eine Verbindungsanfrage erhält. Diese Identitätsbestätigung erfolgt mit dem TLS-Protokoll über ein Zertifikat, das die behauptete Identität des Servers enthält. Das Zertifikat enthält sowohl den DNS-Hostnamen des Servers als auch seinen öffentlichen Schlüssel. Das vorgelegte Zertifikat wird von einer ausstellenden Zertifizierungsstelle (Certification Authority, CA) signiert, die von dem Nutzer anerkannt wird, der die Verbindung anfordert10. 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. Heutzutage werden unsere CA-Zertifikate von mehreren Stamm-CAs signiert, die flächendeckend verbreitet sind, einschließlich Symantec ("GeoTrust") 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 einer neuen Stamm-CA 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, um ein Set von Schlüsseln und Zertifikaten zu generieren. 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 Offline-Status 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 zusätzlich 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üssel11 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 Sicherheitsverletzungen von TLS Crypto-Verknüpfungen messen.

Google Front End zu Anwendungs-Front-Ends

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-Front-End verbunden. In diesem Fall wird 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 standardmäßig mithilfe von ALTS geschützt. Bei Kundenanwendungen, die in Google Cloud gehostet werden, wird, wenn der Traffic über das Google Front End weitergeleitet wird (etwa bei Verwendung von Google Cloud Load Balancer), der Traffic zur VM 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 virtuelle Netzwerkinfrastruktur von Google Cloud ermöglicht eine Verschlüsselung für Traffic außerhalb unserer physischen Grenzen. Die Verschlüsselung wird auf Netzwerkebene ausgeführt und gilt für privaten IP-Traffic innerhalb derselben Virtual Private Cloud (VPC) oder für Peer-VPC-Netzwerke.

Wir gehen davon aus, dass jedes Netzwerk, das eine physische Grenze überschreitet, die von Google oder im Auftrag von Google kontrolliert wird, von einem aktiven Eindringling gefährdet werden kann, der den Traffic bei der Übertragung überwachen, injizieren oder ändern kann. Wir gewährleisten die Integrität und Vertraulichkeit der Kommunikation durch Verschlüsselung, wenn sich Daten außerhalb der physischen Grenzen, die wir kontrollieren, also in einem physischen Bereich befinden, den wir nicht kontrollieren.

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 Kontrollebene12 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 Sicherheitstoken erstellt werden.

Abbildung 4: Sicherheitstoken

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.

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

In der Google-Infrastruktur verwenden wir auf der Anwendungsebene (Ebene 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 kryptographischen 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-Front-End verwendet. Dieser Schutz isoliert die Anwendungsebene und macht diese von der Sicherheit des Netzwerkpfads unabhängig.

Dienste 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 der interne Schlüsselverwaltungsdienst von Google, der die Verschlüsselungsschlüssel zum Schutz von inaktiven Daten speichert und verwaltet, die in der Google-Infrastruktur gespeichert sind.

ALTS-Protokoll

ALTS verfügt über 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.

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

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 kryptographischen 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 (Certificate Authority, CA) 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-GCM13. 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. Beispiele:

  • 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)14.
  • Einige Dienste, die ein anderes Übertragungsprotokoll als TCP verwenden, setzen innerhalb der von Google oder im Auftrag von Google kontrollierten physischen Grenzen andere kryptographische Protokolle oder Schutzfunktionen auf Netzwerkebene ein.

Für die Kommunikation 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.

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 Google-Zugriff so konfigurieren, dass ausschließlich Google-IP-Adressen für die Anfragen verwendet werden.

Wie bei Anfragen eines externen Nutzers an Google unterstützen wir standardmäßig 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).

Vom Nutzer konfigurierbare Optionen für die Verschlüsselung bei der Übertragung

Im Abschnitt Verschlüsselung bei der Übertragung werden die standardmäßigen Schutzverfahren erläutert, die Google für die Übertragung von Daten eingerichtet hat. Im folgenden Abschnitt werden die Konfigurationen beschrieben, die unsere Nutzer für diese Standardschutzmaßnahmen vornehmen können.

Lokales Rechenzentrum in Google Cloud

TLS mit externen GCLB-Lastenausgleichsdiensten

Wenn Ihr Clouddienst einen externen Lastenausgleichsdienst von Google HTTPS oder SSL Proxy verwendet, beendet GFE die TLS-Verbindungen Ihrer Nutzer mithilfe von SSL-Zertifikaten, die Sie bereitstellen und kontrollieren. Weitere Informationen zur Anpassung Ihres Zertifikats finden Sie in unserer Dokumentation zu SSL-Zertifikaten.

IPsec-Tunnel mithilfe von Google Cloud VPN

Als Google Cloud-Kunde können Sie mit dem Google Cloud VPN Ihr lokales Netzwerk über eine IPsec-VPN-Verbindung (Ebene 3) sicher mit Ihrem VPC-Netzwerk (Virtual Private Cloud) der Google Cloud Platform verbinden. Der Traffic zwischen den beiden Netzwerken wird von dem einen VPN-Gateway verschlüsselt und vom anderen VPN-Gateway entschlüsselt. Dies schützt Ihre Daten bei der Übertragung über das Internet. Darüber hinaus können Sie mehrere Tunnel mit Lastenausgleich über mehrere VPN-Gateways einrichten. Ein Google Cloud VPN schützt Ihre Daten auf folgende Weise:

  • Pakete von Ihren VMs zum Cloud-VPN verbleiben im Google-Netzwerk. Diese werden vom virtuellen Google Cloud-Netzwerk verschlüsselt, wenn sie außerhalb der von Google oder im Auftrag von Google kontrollierten physischen Grenzen übertragen werden.
  • Pakete vom Cloud-VPN zu Ihrem lokalen VPN werden mithilfe eines IPsec-Tunnels verschlüsselt und authentifiziert.
  • Pakete von Ihrem lokalen VPN zu Ihren lokalen Hosts werden durch die von Ihnen implementierten Kontrollen in Ihrem Netzwerk geschützt.

Erstellen Sie ein Cloud-VPN-Gateway und einen Cloud-VPN-Tunnel im VPC-Netzwerk des gehosteten Dienstes und erlauben Sie dann den Traffic zwischen den Netzwerken, um ein VPN einzurichten. Sie haben auch die Möglichkeit, ein VPN zwischen zwei VPCs einzurichten.

Sie können Ihr Netzwerk zusätzlich durch Festlegung der IKE-Version (Internet Key Exchange15) für Ihren VPN-Tunnel anpassen. Es gibt zwei Versionen von IKE zur Auswahl: IKEv1 und IKEv2. Jede Version unterstützt unterschiedliche Verschlüsselungen. Wenn Sie IKEv1 festlegen, verschlüsselt Google die Pakete mit AES-128-CBC und bietet eine Integritätsprüfung über SHA-1 HMAC16. Für IKEv2 sind verschiedene unterstützte Verschlüsselungsmethoden verfügbar. In allen Fällen handelt das Google Cloud VPN das sicherste allgemeine Protokoll aus, das von den Peer-Geräten unterstützt wird. Ausführliche Anleitungen zum Einrichten eines VPN finden Sie in unserer Dokumentation VPN-Routing-Option auswählen.

Eine Alternative zu einem IPsec-Tunnel bietet Google Cloud Dedicated Interconnect. Dedicated Interconnect stellt direkte physische Verbindungen und RFC-1918-Kommunikation zwischen Ihrem lokalen Netzwerk und dem Netzwerk von Google bereit. Die Daten, die über diese Verbindung übertragen werden, sind standardmäßig NICHT verschlüsselt und müssen daher auf der Anwendungsebene z. B. mit TLS gesichert werden. Google Cloud VPN und Google Cloud Interconnect verwenden den gleichen Verbindungspunkt, sodass Sie die IPsec-VPN-Verschlüsselung mit Dedicated Interconnect nutzen können. Dazu müssen Sie aber eine Drittanbieterlösung verwenden. MACsec (Ebene-2-Schutz) wird derzeit nicht unterstützt.

Nutzer zu Google Front End

Verwaltete SSL-Zertifikate: Kostenlose und automatisierte Zertifikate

Wenn Sie eine Anwendung in Google Cloud erstellen, können Sie das vom GFE unterstützte TLS durch Konfiguration des von Ihnen verwendeten SSL-Zertifikats nutzen. Beispielsweise haben Sie die Möglichkeit, die TLS-Sitzung in Ihrer Anwendung zu beenden. Diese Beendigung unterscheidet sich von der TLS-Beendigung, wie sie unter TLS mit externen GCLB-Lastenausgleichdiensten erläutert wird.

Google stellt außerdem kostenlose und automatisierte SSL-Zertifikate für die benutzerdefinierten Domains sowohl in Firebase Hosting als auch in Google App Engine bereit. Diese Zertifikate sind nur für von Google gehostete Attribute verfügbar. Mit benutzerdefinierten Google App Engine-Domains können Sie auch eigene SSL-Zertifikate bereitstellen und einen Header des HTTPS Strict Transport Protocol (HSTS) verwenden.

Sobald Ihre Domain auf die Google-Infrastruktur verweist, erhalten wir auf Anforderung ein Zertifikat für diese Domain, um eine sichere Kommunikation zu gewährleisten. Wir verwalten die privaten Schlüssel des TLS-Servers (entweder 2048-Bit-RSA oder secp256r1 ECC) und erneuern Zertifikate im Auftrag unserer Kunden.

TLS in Gmail festlegen

Wie unter Transport Layer Security dargestellt, verwendet Gmail standardmäßig TLS. Gmail ermittelt, ob der letzte Hop einer E-Mail über eine TLS-Sitzung durchgeführt wurde, und zeigt dies an17. Wenn ein Gmail-Nutzer eine E-Mail mit einem anderen Gmail-Nutzer austauscht, werden die E-Mails durch TLS geschützt oder in einigen Fällen direkt in der Anwendung gesendet. In diesen Fällen sind die von der Gmail-Anwendung verwendeten RPCs wie unter Authentifizierung, Integrität und Verschlüsselung von Dienst zu Dienst dargestellt mit ALTS geschützt. Bei eingehenden Nachrichten von anderen E-Mail-Anbietern wird TLS nicht automatisch in Gmail verwendet. Gmail-Administratoren können Gmail aber so konfigurieren, dass für alle eingehenden und ausgehenden E-Mails eine sichere TLS-Verbindung erforderlich ist.

Gmail S/MIME

Secure/Multipurpose Internet Mail Extensions (S/MIME) ist ein E-Mail-Sicherheitsstandard, der Authentifizierung, Integrität und Verschlüsselung bietet. Für die Implementierung des S/MIME-Standards müssen Zertifikate, die mit Nutzern verknüpft sind, die E-Mails senden, in einer öffentlichen CA gehostet werden.

Als Administrator können Sie durch die Konfiguration von Gmail S/MIME für ausgehende E-Mails aktivieren, Richtlinien für die Compliance von Inhalten und Anhängen festlegen sowie Routingregeln für eingehende und ausgehende E-Mails erstellen. Nach Abschluss der Konfiguration müssen Sie die öffentlichen Zertifikate der Nutzer mithilfe der Gmail API in Gmail hochladen. Für Nutzer außerhalb von Gmail muss eine initiale S/MIME-signierte Nachricht ausgetauscht werden, um S/MIME als Standard festzulegen.

Verschlüsselung für Traffic von Dienst zu Dienst und VM zu VM

Istio ist ein von Google, IBM, Lyft und anderen entwickeltes Open-Source-Servicenetz, das die Erkennung und Konnektivität von Diensten vereinfachen soll. Die Istio-Authentifizierung bietet eine automatische Verschlüsselung von Daten bei der Übertragung zwischen Diensten sowie die Verwaltung zugehöriger Schlüssel und Zertifikate. Istio kann in Google Kubernetes Engine und Google Compute Engine verwendet werden.

Zur Implementierung der wechselseitigen Authentifizierung und Verschlüsselung für Arbeitslasten verwenden Sie istio auth. Mit "istio auth" kann eine CA auf Clusterebene spezielle Zertifikate für eine Kubernetes-Arbeitslast generieren und verteilen, die dann für die Mutual Transport Layer Security (MTLS) zwischen Pods verwendet werden.

Google-Unterstützung für die Verschlüsselung von Daten bei der Übertragung im Internet

In den Abschnitten Standardmäßige Verschlüsselung von Daten bei der Übertragung und Vom Nutzer konfigurierbare Optionen für die Verschlüsselung bei der Übertragung wurden die standardmäßigen und anpassbaren Schutzmaßnahmen erläutert, die Google Cloud für Kundendaten bei der Übertragung bereitstellt. Darüber hinaus gibt es bei Google mehrere Open-Source-Projekte sowie weitere Aktivitäten, die die Verwendung der Verschlüsselung bei der Übertragung und die Datensicherheit im Internet insgesamt fördern sollen.

Certificate Transparency

Wie im Abschnitt Verschlüsselung für Traffic von Nutzer zu Google Front End erläutert, muss eine Website für HTTPS zuerst ein Zertifikat von einer vertrauenswürdigen (öffentlichen) Webzertifizierungsstelle (Web-CA) anfordern. Die CA hat die Aufgabe, zu prüfen, ob der anfordernde Antragsteller vom Domain-Inhaber autorisiert wurde und ob alle anderen im Zertifikat enthaltenen Informationen korrekt sind. Mit diesem Zertifikat wird die Website, auf die der Nutzer zugreifen möchte, dann im Browser authentifiziert. Zur Gewährleistung, dass HTTPS ordnungsgemäß authentifiziert ist, muss sicher sein, dass CAs nur Zertifikate ausstellen, die der Domain-Inhaber autorisiert hat.

Certificate Transparency (CT) ist eine von Google im März 2013 gestartete Initiative, mit der Website-Betreiber und Domain-Inhaber feststellen können, ob eine CA nicht autorisierte oder fehlerhafte Zertifikate ausgestellt hat. Diese Initiative bietet Domain-Inhabern, CAs und der Öffentlichkeit ein Verfahren, mit dem sie die angezeigten vertrauenswürdigen Zertifikate oder die von CAs ausgestellten Zertifikate in öffentlich überprüfbaren und manipulationssicheren Logs, für die nur Anfügungen zulässig sind, protokollieren können. Die Zertifikate in diesen Logs können von allen daraufhin überprüft werden, ob die Informationen korrekt, exakt und autorisiert sind.

Die erste Version von Certificate Transparency wurde in einem experimentellen IETF-RFC, RFC 6962, spezifiziert. Bei der Entwicklung von Certificate Transparency hat Google eine Reihe von Open-Source-Tools erstellt, darunter einen Open-Source-Log-Server, der Zertifikate aufzeichnet, sowie Tools zum Erstellen von Certificate Transparency-Logs. Für Google Chrome ist es außerdem erforderlich, dass einige Zertifikate offengelegt werden, z. B. Extended Validation(EV)-Zertifikate oder Zertifikate von CAs, die in der Vergangenheit nicht ordnungsgemäße Zertifikate ausgestellt haben. Ab 2018 müssen für Chrome alle neuen öffentlich vertrauenswürdigen Zertifikate offengelegt werden.

Als Website-Betreiber können Sie mithilfe von Certificate Transparency feststellen, ob nicht autorisierte Zertifikate für Ihre Website ausgestellt wurden. Dafür steht eine Reihe von kostenlosen Tools zur Verfügung, z. B. Certificate Transparency Report und Certificate Search von Google oder Tools von Facebook. Auch wenn Sie Certificate Transparency nicht verwenden, wird es laufend von einer Reihe von Browsern ausgewertet. Damit wird gewährleistet, dass die CAs, denen Ihre Nutzer für den Zugriff auf Ihre Website vertrauen, Branchenanforderungen genügen und Best Practices verwenden, um das Risiko der Ausstellung betrügerischer Zertifikate zu reduzieren.

Steigerung der Nutzung von HTTPS

Wie im Abschnitt Verschlüsselung für Traffic von Nutzer zu Google Front End dargestellt, sind wir intensiv bestrebt, unsere Websites und Dienste standardmäßig mit modernem HTTPS auszustatten. Das Ziel ist eine 100%ige Verschlüsselung unserer Produkte und Dienste. Dazu veröffentlichen wir jährlich einen HTTPS-Transparenzbericht, in dem wir den Stand unserer Zielerreichung für alle Attribute, einschließlich Google Cloud, dokumentieren. Wir arbeiten kontinuierlich daran, technische Hindernisse zu überwinden, die die Verschlüsselung in einigen unserer Produkte erschweren. Zu diesen Produkten gehören z. B. Lösungen für Browser oder andere Clients, die das HTTPS Strict Transport Protocol (HSTS) nicht unterstützen18. Wir verwenden HSTS für einige unserer Websites, einschließlich der google.com-Startseite, damit Nutzer nur über HTTPS eine Verbindung mit einem Server herstellen können.

Uns ist bewusst, dass im Internet intensiv an der Umstellung auf HTTPS gearbeitet wird. Wir versuchen dies auf folgende Weise zu unterstützen:

Seit 2016 veröffentlichen wir Messwerte zur "HTTPS-Nutzung im Internet" für die Top-100-Websites anderer Anbieter im Internet. Mit diesen Messwerten wollen wir das Sicherheitsbewusstsein erhöhen und dazu beitragen, dass das Internet für alle Nutzer sicherer wird. Im Oktober 2017 hat Chrome offiziell seine finanzielle Unterstützung von "Let's Encrypt" als Platinum-Sponsor verlängert.

Steigerung der Nutzung von sicherem SMTP: Gmail-Indikatoren

Die meisten E-Mails werden mithilfe des SMTP-Protokolls (Simple Mail Transfer Protocol) ausgetauscht, das E-Mails standardmäßig ohne Verschlüsselung sendet. Der E-Mail-Anbieter muss deshalb Sicherheitskontrollen wie TLS implementieren, um eine E-Mail zu verschlüsseln.

Wie im Abschnitt Verschlüsselung für Traffic von Nutzer zu Google Front End dargestellt, verwendet Gmail standardmäßig TLS. In TLS in Gmail festlegen wird außerdem gezeigt, wie Gmail-Administratoren die Verwendung des TLS-Schutzes für ein- und ausgehende E-Mails verbindlich festlegen können. Wie bei der HTTPS-Transparenz bietet Google auch Daten zur Nutzung von TLS für in Gmail eingehende E-Mails. Diese Daten können in unserem Transparenzbericht für sichere E-Mails eingesehen werden.

Google leitet in Zusammenarbeit mit IETF und anderen Branchenführern die Entwicklung von SMTP STS. SMTP STS entspricht HSTS für HTTPS und legt die ausschließliche Verwendung von SMTP über verschlüsselte Kanäle verbindlich fest.

Chrome APIs

Im Februar 2015 hat Chrome bekannt gegeben, dass leistungsstarke neue Funktionen nur noch für sichere Ursprünge verfügbar sind19. Zu diesen Funktionen gehören die Handhabung vertraulicher Informationen und der Zugriff auf Sensoren eines Nutzergeräts. Bei der Standortbestimmung in Chrome 50 wurde damit begonnen, diese Funktionen für nicht sichere Ursprünge zu verwerfen.

Kontinuierliche Innovation in der Verschlüsselung bei der Übertragung

Benutzerfreundliche Chrome-Sicherheitsfunktionen

Google Chrome ist ein Branchenführer für die benutzerfreundliche Anzeige von Sicherheitsinformationen in der Benutzeroberfläche, mit der Nutzer schnell den Sicherheitsstandard ihrer Verbindung mit einer Website feststellen können. Mit diesen Informationen können Nutzer sachgerechte Entscheidungen darüber treffen, wann und wie sie ihre Daten teilen. Chrome führt umfangreiche Nutzungsstudien durch, deren Ergebnisse in Begutachtungsartikeln zur Verfügung stehen.

Zum weiteren Schutz seiner Nutzer hat Chrome bekanntgegeben, bis Ende 2017 alle HTTP-Verbindungen als nicht sicher zu kennzeichnen. Ab Chrome 56 wird Nutzern standardmäßig eine Warnung angezeigt, wenn eine HTTP-Seite ein Formular mit Passwort- oder Kreditkartenfeldern enthält. Ab Chrome 62 wird eine Warnung angezeigt, wenn ein Nutzer Daten auf einer HTTP-Seite eingibt und wenn HTTP-Seiten im Inkognitomodus besucht wurden. Eventuell wird in Chrome auch eine Warnung für alle Seiten angezeigt, die über HTTP bereitgestellt werden.

Mit dem BadSSL-Tool können Sie feststellen, wie einzelne Konfigurationen für Nutzer in Chrome angezeigt werden.

Key Transparency

Ein wesentliches Hindernis für die verbreitete Einführung der Nachrichtenverschlüsselung ist die Schwierigkeit, öffentliche Schlüssel auszutauschen: Wie finde ich verlässlich den öffentlichen Schlüssel für einen neuen Nutzer, mit dem ich kommuniziere? Zur Lösung dieses Problems hat Google im Januar 2017 die Verwendung von Key Transparency bekanntgegeben. Dabei handelt es sich um ein offenes Framework, das ein allgemeines, sicheres und überprüfbares Instrument zur Verteilung öffentlicher Schlüssel darstellt. Mit diesem Framework müssen Nutzer keine manuelle Schlüsselüberprüfung mehr durchführen. Primäres Ziel von Key Transparency ist die Verteilung der öffentlichen Schlüssel von Nutzern für die Kommunikation, z. B. die E2E- und OpenPGP-E-Mail-Verschlüsselung. Das Design von Key Transparency bietet einen neuen Ansatz für die Schlüsselwiederherstellung und -verteilung. Es basiert auf Erkenntnissen aus den Projekten Certificate Transparency und CONIKS.

Key Transparency ist eine Open Source-Entwicklung und wird mit einem umfangreichen Merkle-Baum implementiert. Mit Key Transparency Verification können Kontoinhaber feststellen, welche Schlüssel mit ihren Konten verknüpft wurden und wie lange ein Konto aktiv bzw. dauerhaft zugänglich war. Das langfristige Ziel der Key Transparency-Entwicklung von Google ist, allen die Möglichkeit zu geben, einen Key-Transparency-Server zu betreiben und die Integration in beliebig viele Anwendungen zu vereinfachen.

Post-Quanten-Kryptographie

Google möchte seine führende Position im Bereich "Verschlüsselung bei der Übertragung" weiter ausbauen. Zu diesem Zweck arbeiten wir nun an Entwicklungen im Bereich "Post-Quanten-Kryptographie". Mit dieser Art von Kryptographie können wir vorhandene kryptographische Primitive, die für effiziente Quantenangriffe anfällig sind, durch Post-Quanten-Kandidaten ersetzen, die als robuster gelten. Im Juli 2016 hat Google bekannt gegeben, dass mit der Entwicklerversion von Chrome die Bereitstellung eines solchen Algorithmus unter Verwendung des Post-Quanten-Kryptoalgorithmus New Hope getestet wird. Darüber hinaus haben Google-Forscher Artikel zu anderen geeigneten Post-Quanten-Schlüsselaustauschprotokollen veröffentlicht.

Anhang

Weitere Informationen zur Sicherheit der Google Cloud, einschließlich der Übersicht über das Sicherheitsdesign der Infrastruktur von Google, sowie zur Google Cloud-Compliance, einschließlich des öffentlichen SOC 3-Prüfberichts.

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 Die Entwicklung von TLS 1.3 ist noch nicht abgeschlossen. Die Entwurfsversion ist nur für bestimmte Google-Domains wie Gmail zu Testzwecken implementiert.
5 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.
6 Ausführliche Informationen zu QUIC finden Sie auf [https://www.chromium.org/quic](https://www.chromium.org/quic).
7, 8, 9 Für die Abwärtskompatibilität mit einigen älteren Betriebssystemen unterstützen wir 3DES, SHA1 und MD5.
10 Bei verketteten Zertifikaten ist die CA vorübergehend vertrauenswürdig.
11 Dies kann entweder ein Sitzungs-Ticket ([RFC 5077] (https://tools.ietf.org/html/rfc5077)) oder eine Sitzungs-ID ([RFC 5246] (https://tools.ietf.org/html/rfc5246)) sein.
12 Die Steuerungsebene ist jener Teil des Netzwerks, der Signalisierungstraffic überträgt und für das Routing verantwortlich ist.
13 Bisher wurden andere Protokolle verwendet, die jetzt verworfen wurden. Weniger als 1 % der Jobs nutzen diese älteren Protokolle.
14 Datagram TLS (DTLS) bietet Sicherheitsfunktionen für Datagram-basierte Anwendungen, damit diese ohne Abhören und Manipulation kommunizieren können.
15 Internet Key Exchange (IKE) ist das Protokoll zur Einrichtung einer Sicherheitsverknüpfung in der IPsec-Protokollsuite.
16 HMAC-SHA-1 wird durch eine [SHA-1-Kollision] (https://shattered.io/) wie die von Google-Forschern entdeckte SHAttered-Kollision nicht wirkungslos.
17 Bei G Suite Enterprise wird dies nicht in der UI angezeigt. Domainadministratoren können Daten für ihre Domain mithilfe der [E-Mail-Log-Suche] (https://support.google.com/a/answer/2604578) auswerten.
18 HTTPS Strict Transport Protocol ist ein Verfahren, mit dem Websites nur über sichere Verbindungen und/oder nur für Nutzer zugänglich gemacht werden, die ihren User-Agent zur Interaktion mit bestimmten Websites über sichere Verbindungen leiten.
19 Sichere Ursprünge sind Verbindungen, die bestimmten Schema-, Host- oder [Portmustern] (https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features) entsprechen.
Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...