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

Automatische Verschlüsselung zwischen GFEs und Back-Ends

Für die folgenden Load-Balancer-Typen verschlüsselt Google automatisch Traffic zwischen Google Front Ends (GFEs) und Ihren Back-Ends, die sich in Google Cloud VPC-Netzwerken befinden:

  • HTTP(S)-Load-Balancing
  • TCP-Proxy-Load-Balancing
  • SSL-Proxy-Load-Balancing

Optionen für sicheres Back-End-Protokoll

Beim Erstellen eines Back-End-Dienstes wählen Sie ein Back-End-Dienstprotokoll aus. Die folgenden Back-End-Dienstprotokolle bieten eine sichere Verbindung zu Back-Ends:

  • Für HTTP(S)-Load-Balancing: HTTPS und HTTP/2
  • Für internes HTTP(S)-Load-Balancing: HTTPS und HTTP/2
  • Für SSL-Proxy-Load-Balancing: SSL
  • Für Traffic Director: HTTPS und HTTP/2

Wenn HTTP(S)-Load-Balancing oder SSL-Proxy-Load-Balancing über ein sicheres Protokoll eine Verbindung zu einem Back-End herstellen, ist das GFE der HTTPS- oder SSL-Client. Wenn das interne HTTP(S)-Load-Balancing über ein sicheres Protokoll eine Verbindung zu einem Back-End herstellt, ist der Envoy-Proxy der HTTPS-Client.

Wenn ein mit Traffic Director konfigurierter clientseitiger Proxy über ein sicheres Back-End-Dienstprotokoll eine Verbindung zu einem Back-End herstellt, ist der clientseitige Proxy der SSL- oder HTTPS-Client.

Anwendungsfälle für das sichere Back-End-Protokoll

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

  • Wenn Sie eine prüfbare, verschlüsselte Verbindung vom Load-Balancer (oder Traffic Director) zu den Back-End-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-Back-End 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 Front-End-SSL-Zertifikaten des Load-Balancers übereinstimmen. Anweisungen zur Installation finden Sie in der Dokumentation der Software, die auf Ihren Back-End-Instanzen oder Endpunkten ausgeführt wird.

  • Wenn ein GFE eine TLS-Sitzung für Back-Ends startet, verwendet das GFE nicht die Erweiterung "Server Name Indication" (SNI).

  • 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 Front-End-Protokolle

Wenn Sie in Ihrer Konfiguration einen Ziel-HTTPS- oder Ziel-SSL-Proxy verwenden, verwendet Google Cloud ein sicheres Front-End-Protokoll.

HTTP(S)-Load-Balancing und SSL-Proxy-Load-Balancing verwenden die BoringCrypto-Bibliothek von Google. Details zu FIPS 140-2 finden Sie unter NIST Cryptographic Module Validation Certificate #3678.

Das interne HTTP(S)-Load-Balancing verwendet die BoringSSL-Bibliothek von Google. Details zu FIPS 140-2 finden Sie in der Envoy-Dokumentation. Google erstellt Envoy-Proxys für das interne HTTP(S)-Load-Balancing im FIPS-konformen Modus.

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