Dieses Dokument enthält Details zur Verschlüsselung während der Übertragung in Google Distributed Cloud (GDC) mit Air Gap.
Zusammenfassung für CIOs
- GDC setzt verschiedene Sicherheitsmaßnahmen ein, um die Authentizität, Integrität und Vertraulichkeit von Daten bei der Übertragung zu gewährleisten.
- Je nach hergestellter Verbindung wendet GDC standardmäßige Schutzmaßnahmen auf Daten bei der Übertragung für GDC-Komponenten an. 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 über Ihr Netzwerk übertragen werden, sich innerhalb der Infrastruktur von Google bewegen 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 während der Übertragung. In diesem Dokument wird unser Ansatz zur Verschlüsselung während der Übertragung für Google Distributed Cloud mit Air Gap (GDC) beschrieben.
Informationen zu ruhenden Daten finden Sie unter Verschlüsselung ruhender 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 SecOps-Teams, die GDC verwenden oder in Betracht 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 setzt verschiedene Sicherheitsmaßnahmen ein, 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 Netzwerkschicht. Die Quelle wird durch den von GDC verwalteten AIS authentifiziert.
- Integrität: Wir gewährleisten, dass die von Ihnen gesendeten Daten unverändert ihr Ziel erreichen, d. h. 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, aber der zum Entschlüsseln des Geheimtextes erforderliche Schlüssel ist privat. Bei der Verschlüsselung während der Übertragung wird häufig ein asymmetrischer Schlüsselaustausch verwendet, z. B. Diffie-Hellman auf Basis elliptischer Kurven, um einen gemeinsam genutzten symmetrischen Schlüssel für die Datenverschlüsselung zu erstellen. Weitere Informationen zur Verschlüsselung finden Sie unter Einführung in die moderne Kryptografie.
Die Verschlüsselung kann zum Schutz von Daten in mehreren Zuständen verwendet werden:
- Verschlüsselung ruhender 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 vor potenziellen Angreifern durch:
- Die Notwendigkeit, den unteren Schichten des Netzwerks zu vertrauen, die häufig von Drittanbietern bereitgestellt werden, entfällt.
- Reduzierung der potenziellen Angriffsfläche
- Blockierung des Zugriffs von Angreifern auf Daten, wenn die Kommunikation abgefangen wird
Mit ausreichender Authentifizierung, Integrität und Verschlüsselung können Daten, die zwischen Nutzern, Geräten oder Prozessen übertragen werden, in einer feindlichen Umgebung geschützt werden. Im weiteren Verlauf dieses Dokuments wird der GDC-Ansatz zur Verschlüsselung von Daten bei der Übertragung und deren Anwendung 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 von GDC überschreitet, verwenden wir eine starke Authentifizierung und Verschlüsselung, um Daten bei der Übertragung zu schützen.
Weiterleitung des Traffics
Um zu verstehen, wie die Verschlüsselung während der Übertragung in GDC funktioniert, muss erklärt werden, wie Traffic an und durch GDC weitergeleitet wird. In diesem Abschnitt wird beschrieben, wie Anfragen von einem Endnutzer an den entsprechenden GDC-Dienst oder die entsprechende Kundenanwendung gelangen und wie Traffic zwischen standortübergreifenden Diensten weitergeleitet wird.
Ein von GDC verwalteter Dienst ist ein modularer privater Cloud-Dienst. Zu den 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 auf GDC gehostet werden, gelten nicht als von GDC verwaltete Dienste. Eine Kundenanwendung ist beispielsweise eine Anwendung, die Sie mit GDC-VMs, dem Datenbankdienst und Vertex AI erstellen.
Abbildung 1 zeigt verschiedene Arten von Routinganfragen. Abbildung 1 zeigt die Interaktionen zwischen den verschiedenen Netzwerkkomponenten und die Sicherheit für jede Verbindung.
Abbildung 1: Infrastruktur für die standortübergreifende Konnektivität
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 eingehenden HTTP(S)-Traffic weiter und führt ein Load-Balancing für den Traffic zu den von GDC verwalteten Diensten aus. Eine weitere Firewall-Ebene bietet Gegenmaßnahmen bei DDoS-Angriffen mit Einbruchserkennung und -prävention. Diese Verbindung wird vom Cloud Service Mesh-Ingress-Gateway zum Frontend des von GDC verwalteten Dienstes 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 mithilfe von 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 mehrere Möglichkeiten, Traffic vom Kundennetzwerk an eine auf GDC gehostete Kundenanwendung weiterzuleiten. Die Art und Weise der Weiterleitung Ihres Traffics hängt von Ihrer Konfiguration ab.
Kundenanwendungen über das Kunden-API-Gateway 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 einen externen Kunden-Load-Balancer verfügbar machen
GDC unterstützt das Bereitstellen von containerisierten Arbeitslasten, die vom Kunden über einen externen Load Balancer verwaltet werden. GDC bietet die Möglichkeit, Richtlinien für eingehenden und ausgehenden Traffic für die entsprechenden Mitarbeiter zu konfigurieren. Abbildung 1 zeigt diese Interaktion als Verbindung E.
VM-Arbeitslasten freigeben
GDC unterstützt die Bereitstellung von vom Kunden erstellten virtuellen Maschinen für Endnutzer. GDC bietet die Möglichkeit, Richtlinien für ein- und ausgehenden Traffic für das entsprechende Personal zu konfigurieren. Abbildung 1 zeigt diese Interaktion als Verbindung F.
GDC-Cross-Site Interconnect-Dienst
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 Sicherungen, werden Daten außerhalb der physischen Grenzen von GDC weitergeleitet. In diesem Fall werden Daten sowohl auf der Anwendungsebene (z. B. TLS) als auch auf der Netzwerkschicht verschlüsselt. Abbildung 1 zeigt diese Interaktion als Verbindung G.
Virtuelle Maschine zu virtueller Maschine
VM-zu-VM-Verbindungen innerhalb von GDC werden nicht auf Netzwerkebene verschlüsselt. Kunden sind dafür verantwortlich, Daten mit geeigneten verschlüsselten Protokollen oder bestimmten Technologien wie IPSec-Tunneln zu verschlüsseln.
Standardmäßige Verschlüsselung von Daten bei der Übertragung
GDC verwendet verschiedene Methoden zur Verschlüsselung von Daten bei der Übertragung, sowohl standardmäßige als auch vom Nutzer konfigurierbare. Die Art der Verschlüsselung hängt von der OSI-Schicht, dem Diensttyp 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 Rest dieses Abschnitts werden die Standardschutzmaßnahmen beschrieben, 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 Sicherheit durch eine TLS-Verbindung, die die Authentizität, Integrität und Vertraulichkeit von Anfragen und Antworten gewährleistet. Damit HTTPS-Anfragen angenommen werden können, benötigt der Empfänger ein Schlüsselpaar, das aus einem öffentlichen und einem privaten Schlüssel besteht, sowie ein X.509-Zertifikat für die Serverauthentifizierung von einer Zertifizierungsstelle. Das Schlüsselpaar und das Zertifikat helfen bei der Authentifizierung der Anfragen eines Nutzers auf der Anwendungsebene (Ebene 7), indem sie 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 Verschlüsselung für Traffic von Nutzer zu Cloud Service Mesh Ingress Gateway erläutert: TLS, BoringSSL und die konfigurierbare Zertifizierungsstelle von GDC.
Transport Layer Security (TLS)
Wenn Sie eine Anfrage an einen GDC-Dienst senden, werden die Daten bei der Übertragung gesichert. Dabei werden Authentifizierung, Integrität und Verschlüsselung über HTTPS mit einem Zertifikat einer vertrauenswürdigen Zertifizierungsstelle bereitgestellt. 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 je nach den Möglichkeiten des Clients ein bestimmtes Verschlüsselungsprotokoll mit dem Client aus. Das GDC Cloud Service Mesh Ingress-Gateway erzwingt nur FIPS-genehmigte Algorithmen, um eine höhere Sicherheit zu bieten.
BoringSSL
BoringSSL ist eine von Google verwaltete Open-Source-Implementierung des TLS-Protokolls, die von OpenSSL geforkt wurde und größtenteils mit OpenSSL kompatibel ist. Google hat BoringSSL von OpenSSL geforkt, um OpenSSL sowohl für die interne Verwendung als auch zur besseren Unterstützung der Chromium- und Android-Open-Source-Projekte zu vereinfachen. BoringCrypto, der Kern von BoringSSL, wurde gemäß 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
Konfigurierbare Zertifizierungsstelle von GDC
Im Rahmen von TLS muss ein Server seine Identität gegenüber dem Nutzer nachweisen, wenn er eine Verbindungsanfrage erhält. Diese Identitätsüberprüfung wird im TLS-Protokoll dadurch erreicht, dass der Server ein Zertifikat mit seiner behaupteten Identität vorlegt. 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 der Server überall zugänglich sein soll, muss die Stamm-Zertifizierungsstelle jedem potenziellen Clientgerät bekannt sein. Clientbrowser und -geräte sind mit einer Reihe von Stammzertifizierungsstellen konfiguriert, denen sie vertrauen, basierend auf der Umgebung, in der der Client ausgeführt wird.
Die Stamm-CA 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 zu Anwendungs-Frontends
Zwei Fälle:
- 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 und verschlüsselt TLS mit einer konfigurierten Zertifizierungsstelle für einen anderen Server neu.
Netzwerkverschlüsselung des Speichertraffics
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 spontan generiert und sicher in GDC gespeichert wird. Sobald die IPSec-SAs eingerichtet sind, werden Informationen über den IPSec-Tunnel ausgetauscht. Pakete werden mit der FIPS-konformen Verschlüsselung verschlüsselt und entschlüsselt, die in der IPSec-SA angegeben ist.
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ät und Verschlüsselung von RPC-Aufrufen vom Cloud Service Mesh Ingress Gateway an einen Dienst und von einem GDC-Dienst an einen anderen GDC-Dienst. Jeder Dienst, der in GDC ausgeführt wird, wird als Dienstkontoidentität mit zugehörigen kryptografischen Anmeldedaten ausgeführt. Bei der Kommunikation über mTLS über Cloud Service Mesh verwenden GDC-Dienste Clientzertifikate, um sich bei anderen Diensten zu authentifizieren. 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, um sich bei Diensten zu authentifizieren. Kubernetes-Dienstkontotokens werden mit den öffentlichen Schlüsseln des Tokenausstellers des Kubernetes API-Servers verifiziert.