Diese Seite wurde von der Cloud Translation API übersetzt.

Verschlüsselung vom Load-Balancer zu den Back-Ends
Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Verschlüsselung in allen Google Cloud -Regionen

Der gesamte VM-zu-VM-Traffic in einem VPC-Netzwerk und Peering-VPC-Netzwerken wird verschlüsselt.

Verschlüsselung zwischen Proxy-Load-Balancern und -Back-Ends

Bei einigen Proxy-Load Balancern (siehe Tabelle 1) verschlüsselt Google automatisch Traffic an die Back-Ends, die sich in VPC-Netzwerken befinden. Google Cloud Dieser Vorgang wird als automatische Verschlüsselung auf Netzwerkebene bezeichnet. Die automatische Verschlüsselung auf Netzwerkebene gilt nur für die Kommunikation mit diesen Backend-Typen:

Instanzgruppen
Zonale NEGs (GCE_VM_IP_PORT-Endpunkte)

Darüber hinaus bietet Google Cloud sichere Protokolloptionen zum Verschlüsseln der Kommunikation mit dem Backend-Dienst.

Einige Google Cloud Load Balancer verwenden Google Front Ends (GFEs) als Client für die Back-Ends, andere den Open-Source-Envoy-Proxy. In allen Fällen unterstützt der Load Balancer die in RFC 8446, Abschnitt 9.1 für TLS 1.3 aufgeführten Chiffresammlungen. Für TLS 1.2 und niedriger unterstützt der Load Balancer die Cipher Suites, die mit dem SSL-Richtlinienprofil KOMPATIBEL verknüpft sind.

In der folgenden Tabelle sind die Proxy-Load Balancer zusammengefasst, die den Traffic zu den Backends verschlüsseln.

**Tabelle 1.** Kommunikation zwischen Load Balancern und Back-Ends
Proxy-Load-Balancer	Proxy (Client zum Backend)	Protokolloptionen für Backend-Dienste
Globaler externer Application Load Balancer	GFE (mit Envoy-Software für erweiterte Routingfeatures)	HTTP, HTTPS und HTTP/2 Wählen Sie HTTPS oder HTTP/2 aus, wenn Sie bei der Übertragung zu den Back-Ends eine prüfbare Verschlüsselung benötigen.
Klassischer Application Load Balancer	GFE	HTTP, HTTPS und HTTP/2 Wählen Sie HTTPS oder HTTP/2 aus, wenn Sie bei der Übertragung zu den Back-Ends eine prüfbare Verschlüsselung benötigen.
Regionaler externer Application Load Balancer	Envoy-Proxy	HTTP, HTTPS und HTTP/2 Wählen Sie HTTPS oder HTTP/2 aus, wenn Sie bei der Übertragung zu den Back-Ends eine prüfbare Verschlüsselung benötigen.
Regionaler interner Application Load Balancer	Envoy-Proxy	HTTP, HTTPS und HTTP/2 Wählen Sie HTTPS oder HTTP/2 aus, wenn Sie bei der Übertragung zu den Back-Ends eine prüfbare Verschlüsselung benötigen.
Regionsübergreifender interner Application Load Balancer	Envoy-Proxy	HTTP, HTTPS und HTTP/2 Wählen Sie HTTPS oder HTTP/2 aus, wenn Sie bei der Übertragung zu den Back-Ends eine prüfbare Verschlüsselung benötigen.
Globaler externer Proxy-Network Load Balancer	GFE (mit Envoy-Software für erweiterte Routingfeatures)	SSL oder TCP Wählen Sie SSL für das Backend-Dienstprotokoll aus, wenn Sie bei der Übertragung zu den Back-Ends eine prüfbare Verschlüsselung benötigen.
Klassischer Proxy-Network Load Balancer	GFE	SSL oder TCP Wählen Sie SSL für das Backend-Dienstprotokoll aus, wenn Sie bei der Übertragung zu den Back-Ends eine prüfbare Verschlüsselung benötigen.
Regionaler externer Proxy-Network Load Balancer	Envoy-Proxy	TCP
Regionaler interner Proxy-Network Load Balancer	Envoy-Proxy	TCP
Regionsübergreifender interner Proxy-Network Load Balancer	Envoy-Proxy	TCP
Cloud Service Mesh	Clientseitiger Proxy	HTTPS und HTTP/2

Anwendungsfälle für das sichere Backend-Protokoll

In den folgenden Fällen wird ein sicheres Protokoll für die Verbindung mit Backend-Instanzen empfohlen:

Wenn Sie eine prüfbare, verschlüsselte Verbindung vom Load Balancer (oder Cloud Service Mesh) zu den Backend-Instanzen benötigen.
Wenn der Load Balancer eine Verbindung zu einer Back-End-Instanz außerhalb vonGoogle Cloud herstellt(mit einer Internet-NEG). Die Kommunikation mit einem Internet-NEG-Backend kann das öffentliche Internet übertragen. Wenn der Load Balancer eine Verbindung zu einer Internet-NEG herstellt, muss das von der Zertifizierungsstelle signierte Zertifikat die Validierungsanforderungen erfüllen.

Überlegungen zum sicheren Back-End-Protokoll

Wenn Sie ein sicheres Back-End-Dienstprotokoll verwenden, beachten Sie Folgendes:

Die Back-End-Instanzen oder Endpunkte Ihres Load-Balancers müssen mit demselben Protokoll wie der Back-End-Dienst bereitgestellt werden. Wenn das Back-End-Dienstprotokoll beispielsweise HTTPS ist, müssen die Back-Ends HTTPS-Server sein.
Wenn das Back-End-Dienstprotokoll HTTP/2 ist, müssen Ihre Back-Ends TLS verwenden. Anweisungen zur Konfiguration finden Sie in der Dokumentation der Software, die auf Ihren Back-End-Instanzen oder Endpunkten ausgeführt wird.
Sie müssen private Schlüssel und Zertifikate auf Ihren Back-End-Instanzen oder -Endpunkten installieren, damit sie als HTTPS- oder SSL-Server funktionieren. Diese Zertifikate müssen nicht mit den Frontend-SSL-Zertifikaten des Load-Balancers übereinstimmen. Anweisungen zur Installation finden Sie in der Dokumentation der Software, die auf Ihren Backend-Instanzen oder Endpunkten ausgeführt wird.
Mit Ausnahme von HTTPS-Load-Balancern mit Internet-NEG-Backends verwenden Load Balancer die Erweiterung „Server Name Indication“ (SNI) nicht für Verbindungen zum Backend.
Wenn ein Load Balancer eine Verbindung zu Back-Ends innerhalb von Google Cloudherstellt, akzeptiert der Load Balancer jedes Zertifikat, das von Ihren Back-Ends vorhanden ist. In diesem Fall führt der Load Balancer nur eine minimale Zertifikatsprüfung durch.

Beispielsweise werden Zertifikate auch in folgenden Fällen als gültig erachtet:
- Das Zertifikat ist selbst signiert.
- Wenn das Zertifikat von einer unbekannten Zertifizierungsstelle signiert wurde.
- Wenn das Zertifikat abgelaufen oder noch nicht gültig ist.
- Wenn die Attribute CN und subjectAlternativeName nicht mit einem Host-Header oder DNS-PTR-Eintrag übereinstimmen.
Ab dem 28. April 2025 akzeptiert der Load Balancer nur noch RSA-Zertifikate mit der X509v3-Schlüsselverwendungserweiterung und den Parametern „Digital Signature“ und „Key Encipherment“. Weitere Informationen finden Sie im zugehörigen Versionshinweis vom 24. Januar 2025.

Sichere Frontend-Protokolle

Wenn Sie in Ihrer Konfiguration einen Ziel-HTTPS- oder Ziel-SSL-Proxy verwenden, verwendetGoogle Cloud ein sicheres Frontend-Protokoll.

Externe Application Load Balancer und externe Proxy-Network-Load-Balancer verwenden die BoringCrypto-Bibliothek von Google. Details zu FIPS 140-2 finden Sie unter NIST Cryptographic Module Validation Certificate #3678.

Interne Application Load Balancer verwenden die BoringSSL-Bibliothek von Google. Details zu FIPS 140-2 finden Sie in der Envoy-Dokumentation. Google erstellt Envoy-Proxys für interne Application Load Balancer im FIPS-konformen Modus.

Cloud Service Mesh unterstützt Envoy-Proxys, die im FIPS-konformen Modus erstellt sind.

Verschlüsselung vom Load-Balancer zu den Back-Ends Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.