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. Dazu gehört auch VM-zu-VM-Traffic innerhalb von physischen Grenzen (Traffic innerhalb von Clustern).

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 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 verwenden den Open-Source-Envoy-Proxy. In allen Fällen unterstützt der Load-Balancer die in RFC 8446, Abschnitt 9.1 aufgeführten Chiffresammlungen.

Die folgende Tabelle enthält eine Zusammenfassung.

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.
Externer 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 Backends eine prüfbare Verschlüsselung benötigen.
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 interner Proxy-Network-Load-Balancer Envoy-Proxy TCP
Traffic Director 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 Traffic Director) zu den Backend-Instanzen benötigen.

  • Wenn der Load-Balancer eine Verbindung zu einer Back-End-Instanz außerhalb von Google 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 GFEs die Erweiterung „Server Name Indication“ (SNI) nicht für Verbindungen zum Backend.

  • Wenn ein GFE eine Verbindung zu Back-Ends in Google Cloud herstellt, akzeptiert das GFE alle Zertifikate, die für Ihre Back-Ends vorhanden sind. Die GFEs führen keine Zertifikatsprüfung durch. Beispielsweise gilt das Zertifikat auch in folgenden Fällen als gültig:

    • Bei einem selbst signierten Zertifikat.
    • 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.

Sichere Frontend-Protokolle

Wenn Sie in Ihrer Konfiguration einen Ziel-HTTPS- oder Ziel-SSL-Proxy verwenden, 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.

Traffic Director unterstützt Envoy-Proxys, die im FIPS-konformen Modus erstellt sind.