Dieses Dokument enthält Details zur Verschlüsselung von Daten bei der Übertragung in Google Distributed Cloud (GDC) Air Gapped.
Zusammenfassung für CIOs
- GDC hat verschiedene Sicherheitsmaßnahmen etabliert, um die Authentizität, Integrität und Vertraulichkeit von Daten bei der Übertragung zu gewährleisten.
- Je nach hergestellter Verbindung wendet GDC standardmäßig Schutzmaßnahmen für die Daten an, die für GDC-Komponenten übertragen werden. Beispielsweise sichern wir die Kommunikation zwischen dem Nutzer und dem GDC Cloud Service Mesh-Ingress-Gateway mithilfe von TLS.
Einführung
Sicherheit ist oft ein entscheidender Faktor bei der Wahl eines Cloud-Anbieters. Bei Google steht die Sicherheit an erster Stelle. Wir arbeiten unermüdlich daran, Ihre Daten zu schützen – ob sie das Netzwerk 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 für Google Distributed Cloud Air-Gapped (GDC) beschrieben.
Weitere Informationen zur Verschlüsselung inaktiver Daten finden Sie unter Verschlüsselung inaktiver Daten. 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 GDC 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
GDC hat verschiedene Sicherheitsmaßnahmen etabliert, um die Authentizität, Integrität und Vertraulichkeit von Daten bei der Übertragung zu gewährleisten.
- Authentifizierung:Wir authentifizieren das Ziel der Daten auf der Netzwerkebene. Die Quelle wird durch AIS authentifiziert, das von GDC verwaltet wird.
- Integrität:Wir gewährleisten, dass die von Ihnen gesendeten Daten unverändert ihr Ziel erreichen und vor unbefugten Änderungen geschützt sind.
- 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 mehreren Zuständen geschützt werden:
- Die 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.
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 GDC zur Verschlüsselung von Daten bei der Übertragung und seine typischen Einsatzsituationen erläutert.
GDC-Netzwerkinfrastruktur
Physische Grenzen
Eine physische Grenze ist der Übergang zu einem physischen Bereich, der von Google oder in Abstimmung mit 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 und geprüft. Nur wenige autorisierte Mitarbeiter haben Zugriff auf Hardware. Werden Daten innerhalb dieser physischen Grenzen übertragen, werden sie in der Regel authentifiziert und verschlüsselt.
Für die Kommunikation, die die physische Grenze des GDC über- oder unterschreitet, setzen wir auf starke Authentifizierung und Verschlüsselung, um Daten während der Übertragung zu schützen.
Weiterleitung des Traffics
Damit Sie die Funktionsweise der Verschlüsselung bei der Übertragung in GDC besser verstehen, erklären wir zuerst, wie der Traffic zu und durch GDC geleitet wird. In diesem Abschnitt wird erläutert, wie Anfragen eines Endnutzers den entsprechenden GDC-Dienst oder die entsprechende Kundenanwendung erreichen und wie der Traffic zwischen standortübergreifenden Diensten weitergeleitet wird.
Ein von GDC verwalteter Dienst ist ein modularer Private Cloud-Dienst. Zu diesen Diensten gehören Computing, Speicher und maschinelles Lernen. Der GDC-Objektspeicher ist beispielsweise ein von GDC verwalteter Dienst. Eine Kundenanwendung ist eine in GDC gehostete Anwendung, die Sie als GDC-Kunde mithilfe von GDC-Diensten erstellen und bereitstellen können. Kundenanwendungen oder Partnerlösungen, die in GDC gehostet werden, gelten nicht als von GDC verwaltete Dienste. Eine Kundenanwendung ist beispielsweise eine Anwendung, die Sie mit GDC-VMs, dem Database Service und Vertex AI erstellen.
Abbildung 1 zeigt verschiedene Arten von Routinganfragen. Abbildung 1 zeigt die Interaktionen zwischen den verschiedenen Netzwerkkomponenten und die Sicherheitsfunktionen für jede Verbindung.
Abbildung 1: Infrastruktur für die standortübergreifende Verbindung
Endnutzer (Kundennetzwerk) zu GDC API und verwaltetem Dienst
Verwaltete Dienste, die auf Cloud Service Mesh-Ingress-Gateways gehostet werden, akzeptieren Anfragen aus dem Kundennetzwerk über das Cloud Service Mesh-Ingress-Gateway. Das Cloud Service Mesh Ingress Gateway leitet Traffic für eingehenden HTTP(S)-Traffic weiter und leitet den Traffic an die von GDC verwalteten Dienste selbst weiter und sorgt für das Load-Balancing. Eine weitere Firewall-Ebene bietet Gegenmaßnahmen bei DDoS-Angriffen mit Einbruchserkennung und ‑prävention. Diese Verbindung vom Cloud Service Mesh-Ingress-Gateway zum Frontend des von GDC verwalteten Dienstes wird authentifiziert und verschlüsselt. Abbildung 1 zeigt diese Interaktion als Verbindung A.
Die meisten GDC-APIs und verwalteten Dienste werden auf Cloud Service Mesh-Ingress-Gateways gehostet. Einige Dienste werden jedoch direkt auf dem von GDC verwalteten Layer 4-Load Balancer gehostet. DBS-Datenbanken werden beispielsweise auf einem externen GDC-Load-Balancer gehostet. Diese Dienste sind so konfiguriert, dass Verbindungen auf der Anwendungsebene mit TLS authentifiziert und verschlüsselt werden. Abbildung 1 zeigt diese Interaktion als Verbindung B.
Endnutzer (Kundennetzwerk) zu einer Kundenanwendung, die in GDC gehostet wird
Es gibt verschiedene Möglichkeiten, Traffic aus dem Kundennetzwerk zu einer Kundenanwendung weiterzuleiten, die auf GDC gehostet wird. Die Art und Weise der Weiterleitung Ihres Traffics hängt von Ihrer Konfiguration ab.
Kundenanwendungen über das API-Gateway des Kunden verfügbar machen
GDC unterstützt die Bereitstellung von Kundenanwendungen über das Kunden-API-Gateway. Mit dem API Gateway-Dienst können Nutzer die API nach Bedarf entwickeln, bereitstellen, schützen, verwalten und skalieren. Abbildung 1 zeigt diese Interaktion als Verbindung C.
Containerisierte Kundenarbeitslasten über den externen Load-Balancer des Kunden verfügbar machen
GDC unterstützt die Bereitstellung von containerisierten Arbeitslasten, die vom Kunden über einen externen Load Balancer verwaltet werden. Mit GDC können Sie Richtlinien für ein- und ausgehenden Traffic für das entsprechende Personal konfigurieren. Abbildung 1 zeigt diese Interaktion als Verbindung E.
Arbeitslasten virtueller Maschinen freigeben
GDC unterstützt die Bereitstellung von vom Kunden erstellten VMs für Endnutzer. Mit GDC können Sie Richtlinien für ein- und ausgehenden Traffic für das entsprechende Personal konfigurieren. Abbildung 1 zeigt diese Interaktion als Verbindung F.
Standortübergreifender Interconnect-Dienst von GDC
Das Routing von einem verwalteten Dienst zu einem anderen erfolgt in der Regel vollständig innerhalb der physischen Grenzen von GDC. In einigen Fällen, z. B. bei standortübergreifenden Back-ups, werden Daten außerhalb der physischen Grenzen des GDC weitergeleitet. In diesem Fall werden Daten sowohl auf der Anwendungsebene (z. B. TLS) als auch auf der Netzwerkebene verschlüsselt. Abbildung 1 zeigt diese Interaktion als Verbindung G.
Virtuelle Maschine zu virtueller Maschine
VM-zu-VM-Verbindungen innerhalb von GDC werden auf Netzwerkebene nicht verschlüsselt. Kunden sind dafür verantwortlich, Daten mithilfe geeigneter verschlüsselter Protokolle oder bestimmter Technologien wie IPSec-Tunnel zu verschlüsseln.
Standardmäßige Verschlüsselung von Daten bei der Übertragung
GDC 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. In diesem Abschnitt werden die Standardschutzmaßnahmen beschrieben, die Google zum Schutz von Daten bei der Übertragung verwendet.
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 zum Cloud Service Mesh-Ingress-Gateway
Heute verwenden viele Systeme das HTTPS-Protokoll 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) authentifiziert. 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-Cloud Service Mesh-Ingress-Gateway-Verschlüsselung beschrieben: TLS, BoringSSL und die konfigurierbare Zertifizierungsstelle von GDC.
Transport Layer Security (TLS)
Wenn Sie eine Anfrage an einen GDC-Dienst senden, sichern wir die Daten bei der Übertragung. Wir nutzen HTTPS mit einem Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle, um Authentifizierung, Integrität und Verschlüsselung zu bieten. Alle Daten, die der Nutzer an das Cloud Service Mesh-Ingress-Gateway für den von GDC verwalteten Dienst sendet, werden bei der Übertragung mit Transport Layer Security (TLS) verschlüsselt. Das Cloud Service Mesh-Ingress-Gateway handelt mit dem Client ein bestimmtes Verschlüsselungsprotokoll aus, je nachdem, welches Protokoll der Client unterstützt. Das GDC Cloud Service Mesh Ingress Gateway erzwingt nur FIPS-genehmigte Algorithmen, um die Sicherheit zu erhöhen.
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 Level 1 validiert.
TLS im Cloud Service Mesh-Ingress-Gateway wird mit BoringSSL implementiert. In Tabelle 1 sind die Verschlüsselungsprotokolle aufgeführt, die GDC 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 |
Tabelle 1: Implementierte Verschlüsselung im Cloud Service Mesh-Ingress-Gateway für GDC-Dienste und in der BoringSSL Cryptographic Library
Von GDC konfigurierbare Zertifizierungsstelle
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. 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 jedem potenziellen Clientgerät bekannt sein. Clientbrowser und ‑geräte sind mit einer Reihe von Stamm-CAs konfiguriert, denen sie je nach Umgebung, in der der Client ausgeführt wird, vertrauen.
Die Root-Zertifizierungsstelle für GDC hängt von der Umgebung ab, in der sie bereitgestellt wird, und von den Anforderungen der Kunden in dieser Umgebung.
Cloud Service Mesh-Ingress-Gateway für Anwendungs-Frontends
Es gibt zwei Fälle:
- Das Cloud Service Mesh-Ingress-Gateway beendet TLS und verschlüsselt mTLS mit Cloud Service Mesh-Istio-Zertifikaten neu.
- mTLS vom Ingress-Gateway zum Istio-Sidecar-Anwendungs-Frontend
- Das Cloud Service Mesh Ingress-Gateway beendet TLS, verschlüsselt TLS mit der konfigurierten Zertifizierungsstelle neu für einen anderen Server.
Netzwerkverschlüsselung von Speichertraffic
Im GDC-Datei- und Blockspeichersystem wird der Traffic zwischen der Anwendung, die den Speicher verwendet, und dem Speicherdienst weitergeleitet. Diese Daten werden bei der Übertragung mit IPSec authentifiziert und verschlüsselt. Die clientseitige Verschlüsselung für den Speichertraffic ist bald verfügbar. Der IPSec-Transportmodus wird für den Datei- und Block-Traffic zum Host verwendet, der auf den Speicher zugreifen muss. Die Authentifizierung erfolgt über einen vorinstallierten Schlüssel, der während der Übertragung generiert und sicher in GDC gespeichert wird. Sobald IPSec-SAs eingerichtet sind, werden Informationen über den IPSec-Tunnel ausgetauscht. Pakete werden mit der in der IPSec SA angegebenen FIPS-konformen Verschlüsselung verschlüsselt und entschlüsselt.
Authentifizierung, Integrität und Verschlüsselung von Dienst zu Dienst
In der GDC-Infrastruktur verwenden wir auf der Anwendungsebene (Ebene 7) mTLS oder TLS für die Authentifizierung, Integritätsprüfung und Verschlüsselung von RPC-Aufrufen vom Cloud Service Mesh Ingress Gateway zu einem Dienst und von einem GDC-Dienst zu einem anderen GDC-Dienst. Jeder in GDC ausgeführte Dienst wird als Dienstkontoidentität mit den zugehörigen kryptografischen Anmeldedaten ausgeführt. Bei der Kommunikation über mTLS über Cloud Service Mesh verwenden GDC-Dienste Clientzertifikate zur Authentifizierung bei anderen Diensten. Cloud Service Mesh überprüft diese Zertifikate mithilfe einer internen Zertifizierungsstelle. Bei der Kommunikation über TLS, z. B. mit einem GDC Kubernetes API-Server, verwenden GDC-Dienste Kubernetes-Dienstkonto-Tokens zur Authentifizierung bei Diensten. Kubernetes-Dienstkonto-Tokens werden mit den öffentlichen Schlüsseln des Tokenausstellers des Kubernetes API-Servers überprüft.