Frontend-mTLS mit Secure Web Proxy verwenden

Sie können die gegenseitige TLS-Authentifizierung (Mutual TLS, mTLS) für das Frontend in Secure Web Proxy konfigurieren, um die Sicherheit Ihrer Arbeitslasten wie KI-Agents zu erhöhen. Secure Web Proxy verwendet mTLS für das Frontend, um Clientidentitäten über Zertifikate zu prüfen.

Mit dieser Integration können Sie validierte Clientidentitäten in Secure Web Proxy Autorisierungs richtlinien verwenden, um eine detaillierte Zugriffssteuerung für ausgehenden Traffic zu erzwingen.

Funktionsweise

In den folgenden Schritten wird erläutert, wie Secure Web Proxy mTLS für das Frontend verwendet, um ausgehenden Traffic zu sichern:

  • Explizite Proxyverbindung: Sie können den Client so konfigurieren, dass er Secure Web Proxy als expliziten Proxy verwendet. Der Client initiiert eine HTTPS-CONNECT-Anfrage an das Secure Web Proxy-Frontend, anstatt sich direkt mit dem Internet zu verbinden.

  • Gegenseitiger TLS-Handshake: Während der Verbindungsherstellung führen Secure Web Proxy und der Client einen mTLS-Handshake am Proxy-Frontend durch. Der Proxy verwendet eine konfigurierte TrustConfig-Ressource, um das Zertifikat des Clients zu validieren, während der Client das Serverzertifikat des Proxys validiert.

  • Identitätsextraktion: Nach einem erfolgreichen Handshake extrahiert Secure Web Proxy eindeutige Identitätsattribute wie URI_SAN, direkt aus dem validierten Clientzertifikat.

  • Identitätsbasierte Autorisierung: Secure Web Proxy wertet die ausgehende Anfrage anhand Ihrer konfigurierten Autorisierungsrichtlinien aus. Um zu ermitteln, ob die Anfrage autorisiert ist, verwendet der Proxy die Identität des Clients, die während des mTLS-Handshakes kryptografisch überprüft wurde.

  • Sicherer ausgehender Traffic: Wenn die Anfrage autorisiert ist und eine übereinstimmende Regel für ein externes Ziel vorhanden ist, erfüllt Secure Web Proxy die Anfrage an das Ziel.

Hauptvorteile

Die Konfiguration von mTLS für das Frontend in Secure Web Proxy bietet die folgenden Sicherheits- und betrieblichen Vorteile:

  • Erweiterte Sicherheitsfunktionen: Erzielen Sie Zero-Trust-Zugriff, indem Sie für den gesamten ausgehenden Traffic eine mTLS-Authentifizierung für das Frontend erzwingen. So können nur Arbeitslasten mit einer bestätigten Identität eine Verbindung mit dem Proxy herstellen, um auf externe Dienste zuzugreifen.

  • Vereinfachte Arbeitslastkonfiguration: Verwenden Sie den expliziten Proxy-Routingmodus für Secure Web Proxy, um die Möglichkeit des Proxys zu nutzen, Anfragen abzufangen und zu authentifizieren requests.

  • Detaillierte Steuerung: Erzwingen Sie detaillierte, identitätsbasierte Richtlinien, um festzulegen, auf welche externen Dienste die einzelnen Arbeitslasten zugreifen können.

Beispielanwendungsfall: Identität Ihrer Arbeitslasten validieren

In stark regulierten Branchen wie dem Bankensektor reicht es nicht aus, den Netzwerkstandort einer Anfrage zu überprüfen, um unbefugten Datenzugriff zu verhindern. Durch die Konfiguration von mTLS für das Frontend in Secure Web Proxy können Unternehmen zu einem kryptografisch überprüften Identitätsmodell wechseln. So muss jede Arbeitslast, unabhängig davon, ob es sich um eine VM-Instanz oder einen KI-Agenten handelt, ihre spezifische Identität mit einem vertrauenswürdigen Zertifikat nachweisen.

Mit diesem Ansatz können Administratoren identitätsbasierte Schutzmaßnahmen erzwingen, die sensible ausgehende Pfade schützen. Eine Bank kann beispielsweise dafür sorgen, dass nur eine bestimmte authentifizierte Arbeitslast zur Zahlungsverarbeitung ein externes Finanzgateway erreichen kann.

mTLS-Authentifizierung für das Frontend für Secure Web Proxy konfigurieren

In diesem Abschnitt werden die Schritte zum Konfigurieren der mTLS-Authentifizierung für das Frontend für Ihre Secure Web Proxy-Instanz beschrieben.

Hinweis

Root- und Zwischenzertifikate erstellen

In diesem Abschnitt wird gezeigt, wie Sie mit OpenSSL ein CA-Zertifikat der Root-Zertifizierungsstelle (Certificate Authority, CA) (den Trust-Anchor) und ein optionales Zertifikat der Zwischen-CA generieren. Secure Web Proxy verwendet diese Zertifikate, um die Clientzertifikate zu prüfen, die Arbeitslasten während des mTLS-Handshakes für das Frontend präsentieren. Dieser manuelle Prozess ist für Test- und Entwicklungsumgebungen vorgesehen, um den Trust-Anchor bereitzustellen, den Secure Web Proxy zum Prüfen von Clientzertifikaten benötigt.

Ein Root-Zertifikat befindet sich am Anfang der Zertifikatskette, während ein Zwischenzertifikat als Brücke in der Vertrauenskette zurück zum Root-Zertifikat dient. Das Zwischenzertifikat wird kryptografisch vom Root-Zertifikat signiert. Wenn Secure Web Proxy ein Clientzertifikat empfängt, wird die Identität validiert, indem eine Vertrauenskette vom Clientzertifikat zurück zum konfigurierten Trust-Anchor hergestellt wird.

Verwenden Sie die folgenden Befehle, um die Root- und Zwischenzertifikate zu erstellen. Obwohl das Zwischenzertifikat optional ist, wird es in dieser Konfiguration verwendet, um das Clientzertifikat zu signieren und eine mehrstufige Zertifikathierarchie zu zeigen.

  1. Erstellen Sie eine OpenSSL-Konfigurations datei.

    cat > example.cnf << EOF
[req]
distinguished_name = empty_distinguished_name

[empty_distinguished_name]
# Kept empty to allow setting via -subj command-line argument.

[ca_exts]
basicConstraints=critical,CA:TRUE
keyUsage=keyCertSign
extendedKeyUsage=clientAuth
EOF

  2. Erstellen Sie ein selbst signiertes X.509-Root-Zertifikat (root.cert) und einen privaten Schlüssel (root.key).

    openssl req -x509 \
    -new -sha256 -newkey rsa:2048 -nodes \
    -days 3650 -subj '/CN=root' \
    -config example.cnf \
    -extensions ca_exts \
    -keyout root.key -out root.cert

  3. Erstellen Sie die Zertifikatsignierungsanfrage (int.req) für das Zwischenzertifikat.

    openssl req -new \
    -sha256 -newkey rsa:2048 -nodes \
    -subj '/CN=int' \
    -config example.cnf \
    -extensions ca_exts \
    -keyout int.key -out int.req

  4. Signieren Sie die Zertifikatsignierungsanfrage (Certificate Signing Request, CSR), um das X.509-Zwischenzertifikat (int.cert) zu erstellen.

    openssl x509 -req \
    -CAkey root.key -CA root.cert \
    -set_serial 1 \
    -days 3650 \
    -extfile example.cnf \
    -extensions ca_exts \
    -in int.req -out int.cert

Clientzertifikat für Tests erstellen

Erstellen Sie ein Blattzertifikat und einen privaten Schlüssel für Ihre Testarbeitslast. Während des mTLS-Handshakes mit Ihrer Secure Web Proxy-Instanz stellt der Client dieses Blattzertifikat bereit, um seine Identität nachzuweisen.

Im folgenden Beispiel wird OpenSSL verwendet, um einen Clientschlüssel und eine CSR zu generieren. Anschließend wird die CSR mit dem Schlüssel der Zwischen-CA signiert, den Sie im Abschnitt Root- und Zwischen zertifikate erstellen erstellt haben.

  1. Führen Sie den folgenden OpenSSL-Befehl aus, um einen privaten RSA-Schlüssel mit dem Namen client.key zu generieren:

    openssl genpkey -algorithm RSA -out client.key

  2. Erstellen Sie eine Konfigurationsdatei mit dem Namen client.cnf, in der ein DNS-Name für den alternativen Antragstellernamen (Subject Alternative Name, SAN) angegeben ist. So ist sichergestellt, dass das Zertifikat mit modernen Sicherheitsanforderungen kompatibel ist.

    cat > client.cnf << EOF
[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no

[req_distinguished_name]
CN = my-client.example.com

[v3_req]
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = my-client.example.com

EOF

    Sie können die Werte CN und DNS.1 nach Bedarf für Tests ändern.

  3. Führen Sie den OpenSSL-Anfragebefehl mit dem privaten Schlüssel und der Konfigurationsdatei aus, die Sie erstellt haben, um eine client.req-Datei zu generieren.

    openssl req -new -key client.key -out client.req -config client.cnf

  4. Verwenden Sie den OpenSSL-Befehl x509, um die Anfrage mit Ihrem Zwischenzertifikat (int.cert) und Schlüssel (int.key) zu signieren. Legen Sie einen Gültigkeitszeitraum fest, z. B. 365 Tage, und sorgen Sie dafür, dass die Erweiterungen aus Ihrer Konfigurationsdatei auf die generierte client.cert-Datei angewendet werden.

    openssl x509 -req -in client.req -CA int.cert -CAkey int.key \
  -set_serial 02 -days 365 -out client.cert \
  -extfile client.cnf -extensions v3_req

    Durch diesen Vorgang wird die Datei client.cert erstellt. Notieren Sie den im DNS-SAN verwendeten Wert (z. B. my-client.example.com) als Ihre Clientidentität. Sie können diesen Wert verwenden, um die Arbeitslast zu identifizieren, wenn Sie Ihre Autorisierungsrichtlinien für Secure Web Proxy erstellen.

Zertifikate formatieren

Formatieren Sie die Root- und Zwischenzertifikate in Umgebungsvariablen, die in der trust_config.yaml Datei verwendet werden sollen.

  export ROOT_CERT=$(cat root.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')
  export INTERMEDIATE_CERT=$(cat int.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

Vertrauenskonfigurationsressource erstellen

Eine Vertrauenskonfiguration stellt Ihre Public-Key-Infrastruktur (PKI) im Zertifikatmanager dar. Die Vertrauenskonfiguration gibt Ihrer Secure Web Proxy-Instanz an, welchen Zertifizierungsstellen (Certificate Authorities, CAs) vertraut werden soll, wenn Clientzertifikate geprüft werden, die während eines mTLS-Handshakes für das Frontend präsentiert werden.

Diese Beispielressource für die Vertrauenskonfiguration enthält einen Trust Store mit einem Trust-Anchor (Root-CA) und einer Zwischen-CA. Der Zertifikatsinhalt wird aus den Umgebungsvariablen gelesen, die Sie in dem vorherigen Abschnitt Zertifikate formatieren erstellt haben.

  1. Erstellen Sie eine trust_config.yaml-Datei.

    cat << EOF > trust_config.yaml
trustStores:
  TRUST_CONFIG_NAME:
    trustAnchors:
      - pemCertificate: |
        -----BEGIN CERTIFICATE-----
        <certificate content>
        -----END CERTIFICATE-----
    intermediateCAs:
      - pemCertificate: |
        -----BEGIN CERTIFICATE-----
        <certificate content>
        -----END CERTIFICATE-----

EOF

    Ersetzen Sie TRUST_CONFIG_NAME durch den Namen Ihrer Vertrauenskonfigurationsressource.

  2. Importieren Sie die Datei trust config.yaml mit dem gcloud certificate-manager trust-configs import Befehl.

    gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME\
  --source=trust_config.yaml \
  --location=LOCATION

    Ersetzen Sie Folgendes:

    • TRUST_CONFIG_NAME: Name Ihrer Vertrauenskonfigurationsressource

    • LOCATION: Region, in der Ihre Vertrauenskonfigurationsressource gespeichert ist

ServerTlsPolicy-Ressource erstellen

Eine ServerTlsPolicy-Ressource, auch als Ressource zur Clientauthentifizierung bezeichnet, definiert, wie Secure Web Proxy Clientzertifikate validiert. Hier können Sie den serverseitigen TLS-Modus und die Vertrauenskonfigurationsressource für die Zertifikatsprüfung angeben.

Das clientValidationMode Attribut bestimmt, wie die Verbindung verarbeitet wird wenn ein Client entweder ein ungültiges Zertifikat oder gar kein Zertifikat bereitstellt. Weitere Informationen finden Sie unter Clientvalidierungsmodi für mTLS für das Frontend.

Die Werte des Attributs clientValidationMode sind wie folgt:

  • REJECT_INVALID: Secure Web Proxy lässt nur Verbindungen von Clients zu, die ein gültiges Zertifikat präsentieren, das von einer Zertifizierungsstelle in Ihrer Vertrauenskonfiguration signiert wurde. Verbindungen mit ungültigen oder fehlenden Zertifikaten werden abgelehnt.

  • ALLOW_INVALID_OR_MISSING_CLIENT_CERT: Secure Web Proxy lässt die Verbindungsanfrage zu, auch wenn das Clientzertifikat ungültig ist, nicht anhand Ihrer Vertrauenskonfiguration validiert werden kann oder ganz fehlt.

So erstellen Sie eine ServerTlsPolicy-Ressource:

  1. Erstellen Sie eine server_tls_policy.yaml-Datei. Wählen Sie eine der folgenden Optionen für clientValidationMode aus:

    • Option 1: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
    name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
  clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
  clientValidationTrustConfig: projects/PROJECT_ID/locations/LOCATION/trustConfigs/TRUST_CONFIG_NAME
    • Option 2: REJECT_INVALID
    name: SERVER_TLS_POLICY_NAME
mtlsPolicy:
  clientValidationMode: REJECT_INVALID
  clientValidationTrustConfig: projects/PROJECT_ID/locations/LOCATION/trustConfigs/TRUST_CONFIG_NAME

    Ersetzen Sie Folgendes:

    • SERVER_TLS_POLICY_NAME: Name Ihrer ServerTlsPolicy-Ressource

    • PROJECT_ID: ID Ihres Google Cloud Projekts

    • TRUST_CONFIG_NAME: Name Ihrer Vertrauenskonfigurationsressource

    • LOCATION: Region, in der Ihre Secure Web Proxy-Instanz konfiguriert ist

  2. Importieren Sie die ServerTlsPolicy-Ressource mit dem gcloud network-security server-tls-policies import Befehl.

    gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME\
  --source=server_tls_policy.yaml \
  --location=LOCATION

    Ersetzen Sie Folgendes:

    • SERVER_TLS_POLICY_NAME: Name Ihrer ServerTlsPolicy-Ressource

    • LOCATION: Region, in der Ihre Secure Web Proxy-Instanz konfiguriert ist

  3. Optional: Verwenden Sie den gcloud network-security server-tls-policies list Befehl, um alle Ihre ServerTlsPolicies Ressourcen aufzulisten.

    gcloud network-security server-tls-policies list \
  --location=LOCATION

    Ersetzen Sie LOCATION durch die Region, in der Ihre Secure Web Proxy-Instanz konfiguriert ist.

ServerTlsPolicy-Ressource Ihrer Secure Web Proxy-Instanz zuordnen

  1. Hängen Sie die ServerTlsPolicy-Ressource an die Datei gateway.yaml Ihrer Secure Web Proxy-Instanz an.

    echo "serverTlsPolicy:
//networksecurity.googleapis.com/projects/PROJECT_ID/locations/
LOCATION/serverTlsPolicies/SERVER_TLS_POLICY_NAME"
>> gateway.yaml

    Ersetzen Sie Folgendes:

    • PROJECT_ID: ID Ihres Google Cloud Projekts

    • LOCATION: Region, in der Ihre Secure Web Proxy-Instanz konfiguriert ist

  2. Importieren Sie die Konfiguration Ihrer Secure Web Proxy-Instanz aus der gateway.yaml Datei mit dem gcloud network-services gateways import Befehl.

    gcloud network-services gateways import GATEWAY_NAME\
    --source=gateway.yaml \
    --location=LOCATION

    Ersetzen Sie Folgendes:

    • GATEWAY_NAME: Name Ihrer Secure Web Proxy-Instanz

    • LOCATION: Region, in der Ihre Secure Web Proxy-Instanz konfiguriert ist

Autorisierungsrichtlinien konfigurieren

Weitere Informationen finden Sie unter Autorisierungsrichtlinien für Secure Web Proxy einrichten.

Logging

Weitere Informationen finden Sie unter Fehlerbehandlung und Logging für mTLS für das Frontend.

Beschränkungen

Weitere Informationen finden Sie unter Beschränkungen für mTLS für das Frontend.

Nächste Schritte