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

Dieser Inhalt wurde zuletzt im April 2025 aktualisiert und stellt den Status quo zum Zeitpunkt der Erstellung dar. Die Sicherheitsrichtlinien und -systeme von Google Cloud können sich aber in Zukunft ändern, da wir den Schutz unserer Kundinnen und Kunden kontinuierlich verbessern.

Unsere Sicherheitskontrollen tragen zum Schutz Ihrer Daten bei. Dies gilt sowohl für die Übertragung über das Internet als auch für die Übertragung in der Google-Infrastruktur oder die Speicherung auf unseren Servern. 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 Artikel 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, die über Interconnect-Verbindungen zwischen den Netzwerken der Kundenrechenzentren und den Netzwerken der Rechenzentren von Google übertragen werden.

Bei der Verschlüsselung während der Übertragung kommen verschiedene Technologien zum Schutz der Daten zum Einsatz, 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, verwaltete TLS-Zertifikate und Cloud Service Mesh weiter schützen.

Dieses Dokument richtet sich an CISOs und Security Operations-Teams, die Google Cloudverwenden oder berücksichtigen. In diesem Dokument werden grundlegende Kenntnisse zu Verschlüsselung und kryptografischen Primitiven vorausgesetzt.

Authentifizierung, Integrität und Verschlüsselung

Google setzt die folgenden Sicherheitsmaßnahmen ein, 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 eines Menschen oder eines Prozesses) in einer Verbindung überprüft.
  • Die 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 eingesetzt, um Ihre Daten während der Übertragung unlesbar zu machen und sie vertraulich zu behandeln.

Die Verschlüsselung während der Übertragung trägt zum Schutz Ihrer Daten bei, wenn die Kommunikation abgefangen wird, während Daten zwischen dem Endnutzer und Google Cloud oder zwischen zwei Diensten übertragen werden. Bei der Verschlüsselung während der Übertragung werden die Endpunkte authentifiziert und die Daten vor der Übertragung verschlüsselt. Bei Eingang entschlüsselt der Empfänger die Daten und bestätigt, dass sie während der Übertragung nicht 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 Google, Google Cloud -Kunden oder Endnutzern nicht mehr notwendig, den unteren Ebenen des Netzwerks zu vertrauen.

Weiterleitung des Traffics

In diesem Abschnitt wird beschrieben, wie Anfragen von einem Endnutzer zum entsprechendenGoogle Cloud -Dienst oder zur entsprechenden Kundenanwendung gelangen und wie Traffic zwischen Diensten weitergeleitet wird.

Ein Google Cloud -Dienst ist ein modularer Cloud-Dienst, den wir unseren Kunden anbieten. Zu diesen Diensten gehören Computing, Datenspeicherung, Datenanalyse und maschinelles Lernen. Cloud Storage ist beispielsweise ein Google Cloud -Dienst.

Eine Kundenanwendung ist eine auf Google Cloud gehostete Anwendung, die Sie als Google-Kunde mithilfe von Google Cloud-Diensten erstellen und bereitstellen können. Kundenanwendungen oder Partnerlösungen, die aufGoogle Cloud gehostet werden, gelten nicht als Google Cloud -Dienste. Eine Kundenanwendung ist beispielsweise eine Anwendung, die Sie mit Cloud Run, Google Kubernetes Engine oder einer VM in Compute Engine erstellen.

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

  • 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)
  • Von virtueller Maschine zu Google Front End (GFE) (im Diagramm mit D gekennzeichnet)
  • GFE zu Google APIs und Google-Diensten (im Diagramm mit E bezeichnet)
  • Google Cloud Dienst zu Google Cloud Dienst (im Diagramm mit F gekennzeichnet)

Zugriffspfade für Google.

Verschlüsselung bei der Übertragung zwischen dem Endnutzer und Google

In den folgenden Abschnitten finden Sie weitere Informationen zu den Routinganfragen für Endnutzer, die im vorherigen Diagramm dargestellt werden.

Endnutzer an einen Google Cloud Dienst

Google Cloud Dienste wie Cloud Storage oder Compute Engine sind Cloud-Dienste, die wir Kunden anbieten und in unserer Produktionsumgebung ausführen.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, leitet den Traffic an dieGoogle Cloud -Dienste selbst weiter und sorgt für ein Load-Balancing. GFE-Points-of-Presence gibt es weltweit mit Pfaden, die mit Unicast oder Anycast beworben werden.

GFE leitet Traffic von einem Endnutzer über das Netzwerk von Google 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, sind mit TLS gesichert. TLS ist im GFE mit BoringSSL implementiert, einer von Google verwalteten Open-Source-Implementierung des TLS-Protokolls. BoringCrypto, der Kern von BoringSSL, ist gemäß FIPS 140-3 Level 1 validiert.

Das GFE verhandelt mit dem Client branchenübliche kryptografische Parameter, einschließlich vorwärtssicherer Schlüsselverhandlung. Bei älteren, weniger leistungsfähigen Clients wählt das GFE die stärksten Legacy-kryptografischen Primitive aus, die der Client bietet.

Endnutzer zu einer Kundenanwendung, die auf Google Cloudgehostet wird

Sie können Endnutzertraffic vom Internet über eine direkte Verbindung oder über einen Load-Balancer zu Ihren 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 Proxynetzwerk-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 (vorausgesetzt, die Clientanwendung des Endnutzers unterstützt TLS). GFE beendet die TLS-Verbindungen Ihrer Endnutzer mithilfe von selbstverwalteten oder von Google verwalteten TLS-Zertifikaten. Weitere Informationen zum Anpassen Ihres Zertifikats finden Sie in der Übersicht zu SSL-Zertifikaten. 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 Gegenseitige TLS – Übersicht. Erwägen 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 eigene SSL-Zertifikate bereitstellen und einen HSTS-Header (HTTP Strikte Transportsicherheit) verwenden.

Verschlüsselung bei der Übertragung in Google-Netzwerken

Google Cloud verschlüsselt Kundendaten bei der Übertragung innerhalb der Google-Netzwerke, sofern in diesem Abschnitt nicht anders beschrieben.

Spezialisierte Ultra-Hochleistungs-Interconnect-Verbindungen, 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-Hochleistungs-Interconnect-Verbindungen 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 dafür verantwortlich, Ihre eigene Verschlüsselung für diese Verbindungen zu konfigurieren.

Google Cloud Authentifizierung und Verschlüsselung eines virtuellen Netzwerks

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

Die Verschlüsselung von privatem IP-Traffic innerhalb derselben VPC oder zwischen Peering-VPC-Netzwerken innerhalb des virtuellen Netzwerks von Google Clouderfolgt auf Netzwerkebene.

Jedes Paar kommunizierender Hosts richtet einen Sitzungsschlüssel mithilfe eines Kontrollkanals ein, der von ALTS für eine authentifizierte, integritätsgeschützte und verschlüsselte Kommunikation geschützt ist. Der Sitzungsschlüssel wird verwendet, um die VM-zu-VM-Kommunikation zwischen diesen Hosts zu verschlüsseln. Sitzungsschlüssel werden regelmäßig rotiert.

VM-zu-VM-Verbindungen innerhalb von VPC-Netzwerken und Peering-VPC-Netzwerken innerhalb des Produktionsnetzwerks von Google sind integritätsgeschützt und verschlüsselt. Diese Verbindungen umfassen Verbindungen zwischen Kunden-VMs sowie zwischen vom Kunden und von Google verwalteten VMs wie Cloud SQL. Das Diagramm unter Weiterleitung des Traffics zeigt diese Interaktion (Verbindung C). Da Google die automatische Verschlüsselung basierend auf der Verwendung interner IP-Adressen aktiviert, werden Verbindungen zwischen VMs mit externen IP-Adressen nicht automatisch verschlüsselt.

Das virtuelle Netzwerk vonGoogle Cloudauthentifiziert den gesamten Traffic zwischen VMs. Diese Authentifizierung mithilfe von Sicherheitstokens verhindert Spoofing-Pakete im Netzwerk durch einen angegriffenen Host.

Sicherheitstokens werden in einem Tunnelheader gekapselt, der Authentifizierungsinformationen über den Absender und den Empfänger enthält. Die Steuerungsebene auf dem Absenderhost legt das Token fest und der empfangende Host validiert das Token. Sicherheitstokens werden für jeden Datenfluss vorab generiert und bestehen aus einem Token (mit den Informationen des Absenders) und dem Host-Secret.

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 Google-Dienste werden auf GFEs gehostet. Beim VM-zu-GFE-Traffic werden externe IP-Adressen verwendet, um Google Cloud -Dienste zu erreichen. Sie können jedoch den 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 Dienste zugreifen, die auf von Google verwalteten VM-Instanzen gehostet werden, verbleibt der Traffic im Produktionsnetzwerk von Google, wird jedoch aufgrund der Verwendung der externen IP-Adressen nicht automatisch verschlüsselt. Weitere Informationen finden Sie unter Google Cloud Authentifizierung und Verschlüsselung von virtuellen Netzwerken.

Wenn ein Nutzer eine Anfrage an einen Google Cloud -Dienst sendet, sichern wir die Daten bei der Übertragung (mit Authentifizierung, Integrität und Verschlüsselung) mithilfe von HTTPS mit einem Zertifikat einer (öffentlichen) Web-Zertifizierungsstelle. 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, was der Client unterstützen kann. GFE handelt, wenn möglich, modernere Verschlüsselungsprotokolle aus.

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

Die Infrastruktur von Google verwendet ALTS zur Authentifizierung, Integrität und Verschlüsselung von Verbindungen vom GFE zu einem Google Cloud Dienst und von einem Google Cloud Dienst zu einem anderen Google Cloud Dienst.

ALTS verwendet dienstbasierte Identitäten für die Authentifizierung. Für Dienste, die in der Produktionsumgebung von Google ausgeführt werden, werden Anmeldedaten ausgestellt, um ihre dienstbasierte Identität zu bestätigen. Beim Erstellen oder Empfangen von RPCs von anderen Diensten verwendet ein Dienst seine Anmeldedaten zur Authentifizierung. ALTS prüft, ob diese Anmeldedaten von der internen Zertifizierungsstelle von Google ausgegeben werden. Die interne Zertifizierungsstelle von Google ist unabhängig vom Certificate Authority Service.

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

ALTS wird auch zum Kapseln anderer Layer-7-Protokolle, z. B. HTTP, in RPC-Mechanismen für den Traffic zwischen GFEs und Google Cloud-Diensten verwendet. Dieser Schutz hilft dabei, die Anwendungsebene zu isolieren, und beseitigt jegliche Abhängigkeit von der Sicherheit des Netzwerkpfads.

Verschlüsselung bei 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 Transport-unabhängiges Protokoll, das die Sicherheit pro Verbindung ermöglicht und die Übertragung der Verschlüsselung auf SmartNIC-Hardware (Smart Network Interface Card) unterstützt. Wenn SmartNICs verfügbar sind, verschlüsselt ALTS die Daten bei der Übertragung durch unser Netzwerk mithilfe von PSP.

Der PSP wurde so konzipiert, dass er die Anforderungen großer Traffic von Rechenzentren erfüllt. Die Google-Infrastruktur nutzt PSP, 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:

  • Handshakeprotokoll:Der Client initiiert einen kombinierten Schlüsselaustausch mit elliptischer Kurve und quantensicherem Schlüssel. Am Ende des Handshakes authentifizieren sich die beteiligten Dienste gegenseitig ihre Identität, indem sie signierte Zertifikate austauschen und prüfen und einen gemeinsamen Trafficschlüssel berechnen. Zu den Algorithmen, die zum Ableiten des gemeinsamen Traffic-Schlüssels unterstützt werden, gehört der NIST-Post-Quanten-Algorithmus ML-KEM (FIPS 203). Weitere Informationen finden Sie unter Post-Quanten-Kryptografie.

  • Aufzeichnungsprotokoll: Dienst-zu-Dienst-Daten werden bei der Übertragung mit dem gemeinsamen Trafficschlüssel verschlüsselt. Standardmäßig verwendet ALTS für den gesamten Traffic die AES-128-GCM-Verschlüsselung. Daten, die innerhalb des Speichersystems der untersten Ebene von Google übertragen werden, verwenden die AES-256-Verschlüsselung und ALTS bietet eine AES-Nachrichtenauthentifizierung. Die Verschlüsselung in ALTS wird über BoringSSL oder PSP bereitgestellt. Diese Verschlüsselung wird auf Ebene 1 gemäß FIPS 140-2 oder Stufe 1 nach FIPS 140-3 validiert.

Die Stamm-Signaturschlüssel für ALTS-Zertifikate werden in der internen Zertifizierungsstelle von Google gespeichert.

Nächste Schritte