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

Verschlüsselung in allen Cloud de Confiance 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 Cloud de Confiance 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 Cloud de Confiance sichere Protokolloptionen zum Verschlüsseln der Kommunikation mit dem Backend Dienst.

Die regionalen Load-Balancer verwenden den Open-Source-Envoy Proxy als Client für die Back-Ends. Die Load Balancer unterstützen 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 Chiffre sammlungen, die mit dem SSL-Richtlinien profil 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
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.
Regionaler externer Proxy-Network Load Balancer Envoy-Proxy TCP
Regionaler interner Proxy-Network Load Balancer Envoy-Proxy TCP

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 Cloud de Confiance (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 Cloud de Confiance, 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, Cloud de Confiance 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.