Verschlüsselung vom Load-Balancer zu den Back-Ends

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

Für einige Proxy-Load-Balancer (siehe Tabelle 1) verschlüsselt Google automatisch Traffic an die Back-Ends, die sich in Google Cloud VPC Netzwerken befinden. 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 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 früher unterstützt der Load-Balancer die Chiffresammlungen, die mit dem SSL-Richtlinienprofil COMPATIBLE verknüpft sind.

In der folgenden Tabelle finden Sie eine Zusammenfassung der Proxy-Load-Balancer, die Traffic an die Back-Ends verschlüsseln.

Tabelle 1. Kommunikation zwischen Load-Balancern und Back-Ends
Proxy-Load-Balancer Proxy (Client zum Backend) Automatische Verschlüsselung auf Netzwerkebene 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 von Google Cloud herstellt Google Cloud (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 Validierungs anforderungen 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 HTTP2 ist, müssen Ihre Back-Ends TLS verwenden. Anweisungen zur Konfiguration finden Sie in der Dokumentation der Software, die auf Ihren Backend-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 in Google Cloud herstellt Google Cloud, 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.

    Bei RSA-Zertifikaten akzeptiert der Load-Balancer ab dem 28. April 2025 nur RSA-Zertifikate, die die X509v3-Erweiterung für die Schlüsselverwendung enthalten und sowohl die Parameter für die digitale Signatur als auch für die Schlüsselverschlüsselung enthalten. 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, Google Cloud verwendet Google 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 wurden.