Verschlüsselung während der Übertragung für Google Cloud

Dieser Artikel wurde zuletzt im April 2025 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.

Bei Google tragen unsere Sicherheitskontrollen zum Schutz Ihrer Daten bei – 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 ruhende Daten als auch für Daten bei der Übertragung. In diesem Dokument wird beschrieben, wie wirGoogle Cloud entwickelt haben, um Daten bei der Übertragung aus dem Internet und Daten bei der Übertragung in den Netzwerken von Google zu verschlüsseln. Dieses Dokument gilt nicht für Daten bei der Übertragung über Interconnects zwischen den Netzwerken von Kundendatenzentren und den Netzwerken von Google-Rechenzentren.

Bei der Verschlüsselung während der Übertragung werden verschiedene Technologien zum Schutz von Daten verwendet, darunter Transport Layer Security (TLS), BoringSSL, Application Layer Transport Security (ALTS) und das PSP-Sicherheitsprotokoll. Zusätzlich zum Standardschutz von Google können Sie Daten durch Hinzufügen von Verschlüsselungsoptionen wie IPsec, verwalteten TLS-Zertifikaten und Cloud Service Mesh weiter schützen.

Dieses Dokument richtet sich an CISOs und Sicherheitsbetriebsteams, die Google Cloudverwenden oder deren Verwendung in Erwägung ziehen. In diesem Dokument werden Grundkenntnisse in der Verschlüsselung und der kryptografischen Primitive vorausgesetzt.

Authentifizierung, Integrität und Verschlüsselung

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

  • Bei der Authentifizierung wird die Identität eines Peers (entweder ein Mensch oder ein Prozess) in einer Verbindung überprüft.
  • Integrität verhindert, dass die von Ihnen gesendeten Daten während der Übertragung zwischen Quelle und Ziel geändert werden.
  • Bei der Verschlüsselung wird Kryptografie verwendet, um Ihre Daten während der Übertragung unleserlich zu machen und vertraulich zu halten.

Die Verschlüsselung bei der Übertragung schützt Ihre Daten, falls die Kommunikation zwischen dem Endnutzer und Google Cloud oder zwischen zwei Diensten abgefangen werden sollte. Bei der Verschlüsselung während der Übertragung werden die Endpunkte authentifiziert und die Daten vor der Übertragung verschlüsselt. Nach der Ankunft entschlüsselt der Empfänger die Daten und prüft, ob sie während der Übertragung geändert wurden.

Die Verschlüsselung ist nur ein Bestandteil einer umfassenden Sicherheitsstrategie. Die Verschlüsselung während der Übertragung schützt Ihre Daten vor potenziellen Angreifern und macht es überflüssig,dass Google, Google Cloud Kunden oder Endnutzer den unteren Ebenen des Netzwerks vertrauen.

Weiterleitung des Traffics

In diesem Abschnitt wird beschrieben, wie Anfragen eines Endnutzers den entsprechendenGoogle 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 inGoogle Cloud gehostet werden, gelten nicht als Google Cloud -Dienste. Eine Kundenanwendung ist beispielsweise eine Anwendung, die Sie mit Cloud Run, Google Kubernetes Engine oder mit einer VM in Compute Engine erstellen.

Das folgende Diagramm zeigt Traffic-Pfade vom Endnutzer zu Google, Pfade innerhalb des Google-Netzwerks und die Sicherheit für jede Verbindung. Die folgenden Trafficpfade werden angezeigt:

  • Endnutzer im Internet zu einem Google Cloud -Dienst (im Diagramm mit A gekennzeichnet)
  • Endnutzer im Internet zu einer Kundenanwendung, die aufGoogle Cloud gehostet wird(im Diagramm mit B gekennzeichnet)
  • Virtuelle Maschine zu virtueller Maschine (im Diagramm mit C gekennzeichnet)
  • Virtuelle Maschine zu Google Front End (GFE) (im Diagramm mit D gekennzeichnet)
  • GFE zu Google APIs und Google-Diensten (im Diagramm mit E gekennzeichnet)
  • Google Cloud Dienst zu Google Cloud Dienst (im Diagramm mit „F“ gekennzeichnet)

Traffic-Pfade für Google.

Verschlüsselung während der Übertragung zwischen dem Endnutzer und Google

In den folgenden Abschnitten finden Sie weitere Informationen zu den Routinganfragen von Endnutzern, die im vorherigen Diagramm dargestellt sind.

Endnutzer zu einem Google Cloud -Dienst

Google Cloud -Dienste wie Cloud Storage oder Compute Engine sind Cloud-Dienste, die wir Kunden anbieten und die in unserer Produktionsumgebung ausgeführt werden. Google Cloud -Dienste akzeptieren Anfragen aus der ganzen Welt über ein global verteiltes System namens Google Front End (GFE). GFE beendet den Traffic für eingehende HTTP(S)-, TCP- und TLS-Verbindungen, bietet Gegenmaßnahmen bei DDoS-Angriffen und leitet den Traffic nach Durchführung eines Load-Balancing an dieGoogle Cloud -Dienste selbst weiter. Es gibt weltweit GFE-Points-of-Presence mit Routen, die über Unicast oder Anycast beworben werden.

Das GFE leitet Traffic von einem Endnutzer über das Google-Netzwerk an einenGoogle Cloud -Dienst und von einem Endnutzer an eine Kundenanwendung weiter, die auf Google Cloud gehostet wird und Cloud Load Balancing verwendet.

Anfragen, die Clients über HTTPS, HTTP/2 oder HTTP/3 an einen Google Cloud -Dienst senden, werden mit TLS gesichert. TLS ist im GFE mit BoringSSL implementiert, einer von Google gepflegten Open-Source-Implementierung des TLS-Protokolls. BoringCrypto, der Kern von BoringSSL, ist gemäß FIPS 140-3, Stufe 1 validiert.

Die GFE handelt mit dem Client kryptografische Parameter nach Branchenstandard aus, einschließlich der Schlüsselvereinbarung mit Forward Secrecy. Für ältere, weniger leistungsfähige Clients wählt die GFE die stärksten Legacy-Kryptografie-Primitiven aus, die der Client anbietet.

Endnutzer zu einer Kundenanwendung, die auf Google Cloudgehostet wird

Sie können Endnutzertraffic aus dem Internet über eine direkte Verbindung oder einen Load Balancer an Ihre Kundenanwendungen weiterleiten, die auf Google Cloud gehostet werden. Wenn der Traffic direkt weitergeleitet wird, wird er an die externe IP-Adresse des VM-Servers weitergeleitet, auf dem die Anwendung gehostet wird.

Sie können TLS mit dem externen Application Load Balancer oder dem externen Proxy Network Load Balancer verwenden, um eine Verbindung zu Ihrer Anwendung herzustellen, die auf Google Cloudausgeführt wird. Wenn Sie einen Layer 7-Load-Balancer verwenden, wird die Verbindung zwischen dem Endnutzer und dem Load-Balancer standardmäßig mit TLS verschlüsselt, sofern die Clientanwendung des Endnutzers TLS unterstützt. GFE beendet die TLS-Verbindungen Ihrer Endnutzer mithilfe von TLS-Zertifikaten, die selbstverwaltet oder von Google verwaltet werden. Weitere Informationen zum Anpassen Ihres Zertifikats finden Sie unter SSL-Zertifikate. Informationen zum Aktivieren der Verschlüsselung zwischen dem Load Balancer und der VM, auf der die Kundenanwendung gehostet wird, finden Sie unter Verschlüsselung vom Load Balancer zu den Back-Ends.

Informationen zum Konfigurieren von gegenseitigem TLS (mTLS) finden Sie unter Übersicht über gegenseitiges TLS. Prüfen Sie für Arbeitslasten in GKE und Compute Engine Cloud Service Mesh, damit Sie mTLS für die gegenseitige Authentifizierung (Client und Server) verwenden und die Kommunikation während der Übertragung mit von Ihnen verwalteten Zertifikaten verschlüsseln können.

Für Firebase Hosting und benutzerdefinierte Cloud Run-Domains sollten Sie unsere kostenlosen und automatisierten TLS-Zertifikate in Betracht ziehen. Mit benutzerdefinierten Cloud Run-Domains können Sie auch Ihre eigenen SSL-Zertifikate bereitstellen und einen HSTS-Header (HTTP Strict Transport Security) verwenden.

Verschlüsselung bei der Übertragung in Google-Netzwerken

Google Cloud verschlüsselt Kundendaten bei der Übertragung in den Netzwerken von Google, sofern in diesem Abschnitt nichts anderes beschrieben ist.

Spezialisierte Ultra-Hochleistungsverbindungen, die TPUs oder GPUs in den KI-Supercomputern von Google verbinden, sind von den in diesem Dokument beschriebenen Netzwerken getrennt. In Google Cloudsind diese Ultra-Hochleistungsverbindungen ICI für TPUs und NVLink für GPUs. Weitere Informationen finden Sie unter TPU-Architektur und GPU-Maschinentypen.

Traffic über Verbindungen zu VMs mit externen IP-Adressen verlässt die Netzwerke von Google. Sie sind für die Konfiguration Ihrer eigenen Verschlüsselung für diese Verbindungen verantwortlich.

Google Cloud Authentifizierung und Verschlüsselung virtueller Netzwerke

Das virtuelle Netzwerk vonGoogle Cloudverschlüsselt, schützt und authentifiziert den Traffic zwischen VMs.

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

Jedes Paar kommunizierender Hosts richtet einen Sitzungsschlüssel über einen von ALTS geschützten Kontrollkanal für eine authentifizierte, integritätsgeschützte und verschlüsselte Kommunikation ein. Der Sitzungsschlüssel wird zum Verschlüsseln der VM-zu-VM-Kommunikation zwischen diesen Hosts verwendet. Sitzungsschlüssel werden außerdem regelmäßig rotiert.

VM-zu-VM-Verbindungen in VPC-Netzwerken und Peering-VPC-Netzwerken innerhalb des Produktionsnetzwerks von Google werden durch Integritätsschutz und Verschlüsselung geschützt. Dazu gehören Verbindungen zwischen Kunden-VMs und zwischen Kunden-VMs und von Google verwalteten VMs wie Cloud SQL. Das Diagramm unter Weiterleitung von Traffic zeigt diese Interaktion (Verbindung C). Beachten Sie, dass Verbindungen zwischen VMs, die externe IP-Adressen verwenden, nicht automatisch verschlüsselt werden, da Google die automatische Verschlüsselung basierend auf der Verwendung interner IP-Adressen aktiviert.

Das virtuelle Netzwerk vonGoogle Cloudauthentifiziert den gesamten Traffic zwischen VMs. Diese Authentifizierung, die über Sicherheitstokens erfolgt, schützt einen angegriffenen Host vor Spoofing-Paketen im Netzwerk.

Sicherheitstokens werden in einen Tunnel-Header eingekapselt, der Authentifizierungsinformationen über den Sender und den Empfänger enthält. Auf der Steuerungsebene des sendenden Hosts wird das Token festgelegt, das der empfangende Host validiert. Sicherheitstokens werden für jeden Datenfluss vorab generiert und bestehen aus einem Token (das die Informationen des Senders enthält) und dem geheimen Hostschlüssel.

Konnektivität zu Google APIs und Google-Diensten

Die Trafficverarbeitung hängt davon ab, wo der Google Cloud -Dienst gehostet wird.

Die meisten Google APIs und Dienste werden auf GFEs gehostet. Bei Traffic von einer VM zum GFE werden externe IP-Adressen verwendet, um Google Cloud -Dienste zu erreichen. Sie können jedoch privaten Zugriff konfigurieren, um die Verwendung externer IP-Adressen zu vermeiden. Die Verbindung vom GFE zum Dienst wird authentifiziert und verschlüsselt.

Einige Dienste wie Cloud SQL werden auf von Google verwalteten VM-Instanzen gehostet. Wenn Kunden-VMs über externe IP-Adressen auf die Dienste zugreifen, die auf von Google verwalteten VM-Instanzen gehostet werden, verbleibt der Traffic im Produktionsnetzwerk von Google, wird aber aufgrund der Verwendung der externen IP-Adressen nicht automatisch verschlüsselt. Weitere Informationen finden Sie unter Google Cloud Authentifizierung und Verschlüsselung virtueller Netzwerke.

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 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.

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

In der Infrastruktur von Google wird ALTS zur Authentifizierung, Integritätsprüfung und Verschlüsselung von Verbindungen vom GFE zu einem Google Cloud Dienst und von einem Google Cloud Dienst zu einem anderen Google Cloud Dienst verwendet.

ALTS verwendet dienstbasierte Identitäten für die Authentifizierung. Für Dienste, die in der Produktionsumgebung von Google ausgeführt werden, werden Anmeldedaten ausgestellt, die ihre dienstbasierten Identitäten bestätigen. Beim Erstellen oder Empfangen von RPCs von anderen Diensten werden von einem Dienst dessen Anmeldedaten zur Authentifizierung verwendet. ALTS überprüft, ob diese Anmeldedaten von der internen Zertifizierungsstelle von Google ausgestellt wurden. Die interne CA von Google ist unabhängig vom Certificate Authority Service.

ALTS verwendet Verschlüsselung und kryptografischen Integritätsschutz für Traffic, der Google Cloud Daten vom GFE zu einem Dienst und zwischen Diensten überträgt, die in der Produktionsumgebung von Google ausgeführt werden.

ALTS wird auch zum Kapseln anderer Ebene-7-Protokolle, z. B. HTTP, in RPC-Verfahren für den Traffic zwischen GFEs und Google Cloud-Diensten verwendet. Dieser Schutz isoliert die Anwendungsebene und macht diese von der Sicherheit des Netzwerkpfads unabhängig.

Methoden zur Verschlüsselung während der Übertragung

In den folgenden Abschnitten werden einige der Technologien beschrieben, die Google zum Verschlüsseln von Daten bei der Übertragung verwendet.

Netzwerkverschlüsselung mit PSP

PSP ist ein transportunabhängiges Protokoll, das die Sicherheit pro Verbindung ermöglicht und die Auslagerung der Verschlüsselung auf Hardware der Smart Network Interface Card (SmartNIC) unterstützt. Wenn SmartNICs verfügbar sind, verwendet ALTS 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. In der Google-Infrastruktur wird PSP verwendet, um den Traffic innerhalb und zwischen unseren Rechenzentren zu verschlüsseln. PSP unterstützt auch Nicht-TCP-Protokolle wie UDP und verwendet für jede Verbindung einen eindeutigen Verschlüsselungsschlüssel.

Application Layer Transport Security

ALTS ist ein von Google entwickeltes System zur gegenseitigen Authentifizierung und Verschlüsselung. ALTS bietet Authentifizierung, Vertraulichkeit und Integrität für Daten bei der Übertragung zwischen Diensten, die in der Produktionsumgebung von Google ausgeführt werden. ALTS besteht aus den folgenden Protokollen:

  • Handshake-Protokoll:Der Client initiiert einen kombinierten Austausch von Schlüsseln für elliptische Kurven und quantensichere Schlüssel. Am Ende des Handshakes authentifizieren die beteiligten Dienste die Identitäten des jeweils anderen, indem sie signierte Zertifikate austauschen und überprüfen und einen gemeinsamen Trafficschlüssel berechnen. Zu den Algorithmen, die zum Ableiten des gemeinsamen Trafficschlüssels unterstützt werden, gehört der NIST-Post-Quanten-Algorithmus ML-KEM (FIPS 203). Weitere Informationen finden Sie unter Post-Quanten-Kryptografie.

  • Aufzeichnungsprotokoll:Daten zwischen Diensten werden bei der Übertragung mit dem gemeinsamen Trafficschlüssel verschlüsselt. Standardmäßig verwendet ALTS die AES-128-GCM-Verschlüsselung für den gesamten Traffic. Daten bei der Übertragung im untersten Speichersystem von Google werden mit AES‑256 verschlüsselt. ALTS bietet AES‑Nachrichtenauthentifizierung. Die Verschlüsselung in ALTS wird von BoringSSL oder PSP bereitgestellt. Diese Verschlüsselung ist gemäß FIPS 140‑2 Level 1 oder FIPS 140‑3 Level 1 validiert.

Die Stammsignaturschlüssel für ALTS-Zertifikate werden in der internen CA von Google gespeichert.

Nächste Schritte