Sicherheitsregeln

Auf dieser Seite werden Gateway-Sicherheitsregeln und ihre Erstellung erläutert.

Mit Secure Web Proxy können Sie verschiedene Arten von Sicherheitsregeln in Ihren Gateway-Sicherheitsrichtlinien definieren, um ausgehenden Webtraffic zu schützen. Mit diesen Regeln können Sie die Sicherheit Ihres Traffics präzise steuern. Dazu verwenden Sie bestimmte Anfragedetails wie Header und URL-Muster, um sicherzustellen, dass nur genehmigter HTTP/S-Traffic Ihr Netzwerk verlässt.

Gateway-Sicherheitsregeln haben die folgenden Funktionen:

  • Jede Regel ist eine if-then-Anweisung, mit der eine Webanfrage anhand der folgenden Parameter geprüft wird:

    • Quellidentität: Wer stellt die Anfrage, z. B. eine bestimmte VM oder ein Dienstkonto.

    • Ziel: Wohin die Anfrage gesendet wird, z. B. an eine Ziel-URL oder eine Domain wie trusted-partner.com.

    • Aktion: Die Entscheidung, den Traffic zuzulassen oder abzulehnen.

  • Gateway-Sicherheitsregeln ermöglichen eine detaillierte Steuerung. Mit diesen Regeln können Sie in Ihrer gesamten Organisation unterschiedliche Sicherheitsstandards durchsetzen, indem Sie klare, strukturierte Definitionen verwenden.

Regeln für den Hostabgleich

Secure Web Proxy verwendet den Hostnamenabgleich, um die Zieldomain zu bestätigen. Der Bestätigungsprozess hängt davon ab, wie Ihr Proxy bereitgestellt wird, wie in der folgenden Tabelle dargestellt.

Bereitstellungsmodus Bestätigungsprozess für Hosts
Expliziter Proxymodus Bei unverschlüsseltem Traffic vergleicht der Proxy den Hostnamen mit dem HTTP-Verbindungsheader. Wenn Sie [Application Matcher-Attribute](/secure-web-proxy/docs/cel-matcher-language-reference#attributes-available-only-to-applicationmatcher) für die TLS-Prüfung verwenden, prüft der Proxy den Hostnamen zuerst auf Verbindungsebene und dann auf Anwendungsebene.
Modus für den nächsten Hop Bei verschlüsseltem Traffic vergleicht der Proxy den Zielhostnamen mit dem SNI-Feld (Server Name Indication) in der ausgehenden Anfrage. Dieses Feld ist auch bei sicheren Verbindungen sichtbar.

Host-Abgleichsregeln für den expliziten Proxymodus konfigurieren

Wenn Sie Secure Web Proxy als expliziten Proxy bereitstellen, konfigurieren Sie Regeln für den Hostabgleich, um zu prüfen, ob die vom Client gesendeten Hostinformationen korrekt extrahiert und mit Ihren definierten Sicherheitsregeln abgeglichen werden. Im expliziten Proxymodus werden Clients aktiv konfiguriert, ihren Traffic direkt an die Secure Web Proxy-Instanz zu senden.

Der Hostabgleich im expliziten Proxymodus funktioniert für verschiedene Arten von Web-Traffic so:

Traffictyp Abgleichsverfahren Regelkonfiguration
Unverschlüsseltes HTTP Secure Web Proxy vergleicht den Zielhostnamen mit dem Feld host im Standardheader CONNECT der HTTP-Anfrage. Verwenden Sie im Feld sessionMatcher den Wert host() == "example.com".
Verschlüsseltes HTTPS (ohne TLS-Prüfung) Der Hostabgleich ist weder auf Anwendungsebene noch auf Sitzungsebene möglich. Das liegt daran, dass die Anfragedetails verschlüsselt sind und das Attribut destination.ip nicht unterstützt wird. Sie müssen entweder umfassendere Richtlinienkontrollen wie den Abgleich der Quellidentität verwenden oder die TLS-Prüfung für die hostbasierte Filterung aktivieren. Wenn Sie den Application Matcher verwenden möchten, müssen Sie entweder den Abgleich der Quellidentität wie Dienstkonten verwenden oder die TLS-Prüfung aktivieren.
Verschlüsseltes HTTPS (mit TLS-Prüfung) Wenn Sie die vollständige Anfrage prüfen möchten, müssen Sie sowohl den Session Matcher als auch den Application Matcher verwenden. 1. Legen Sie eine allgemeine Session Matcher-Regel fest, die entweder true zurückgibt oder mit dem Zielhost übereinstimmt, z. B. host() == "example.com".

2. Fügen Sie im Feld applicationMatcher eine bestimmte Hostregel wie request.host() == "example.com" hinzu.

Host-Abgleichsregeln für den Modus „Nächster Hop“ konfigurieren

Wenn Sie Secure Web Proxy als nächsten Hop bereitstellen, müssen Sie Regeln für den Hostabgleich konfigurieren. Der Traffic wird über eine VPC-Route (Virtual Private Cloud) basierend auf von Ihnen definierten IP-Adressbereichen an den Proxy weitergeleitet. Hostabgleichsregeln sorgen dafür, dass der Proxy den Zielhost korrekt identifiziert, indem er verschiedene Felder des Traffics prüft, z. B. den SNI-Header (Server Name Indication).

Der Host-Abgleich im Modus „Nächster Hop“ funktioniert für verschiedene Arten von Web-Traffic so:

Traffictyp Abgleichsverfahren Regelkonfiguration
Unverschlüsseltes HTTP Secure Web Proxy vergleicht den Zielhostnamen mit dem Feld host im Standard-HTTP-Anfrageheader. Verwenden Sie im Feld sessionMatcher den Wert host() == "example.com".
Verschlüsseltes HTTPS (ohne TLS-Prüfung) Secure Web Proxy vergleicht den Hostnamen mit dem SNI-Header in der ausgehenden Anfrage, der auch dann sichtbar ist, wenn der restliche Traffic verschlüsselt ist. Verwenden Sie im Feld sessionMatcher den Wert host() == "example.com".
Verschlüsseltes HTTPS (mit TLS-Prüfung) Wenn Sie die vollständige Anfrage prüfen möchten, müssen Sie sowohl den Session Matcher als auch den Application Matcher verwenden. 1. Legen Sie eine allgemeine Session Matcher-Regel fest, die entweder true zurückgibt oder mit dem Zielhost übereinstimmt, z. B. host() == "example.com".

2. Fügen Sie im Feld applicationMatcher eine bestimmte Hostregel wie request.host() == "example.com" hinzu.

TCP-Proxyregeln

Mit Transmission Control Protocol (TCP)-Proxyregeln können Sie Traffic steuern, der kein Standard-Web-Traffic ist, z. B. HTTP (Port 80) oder HTTPS (Port 443). Durch das Konfigurieren von TCP-Proxyregeln können Sie Traffic an jedem anderen TCP-Port zulassen oder blockieren. Mit diesen Regeln können Sie schädlichen Traffic blockieren und Nicht-Webanwendungen verwalten, die TCP verwenden.

Wenn für Ihre Arbeitslast (z. B. Ihre Anwendungen und Dienste) Secure Web Proxy als nächster Hop verwendet wird, ist es sinnvoll, TCP-Proxyregeln anzuwenden. Bei der routenbasierten Weiterleitung wird Nicht-HTTP(S)- und Nicht-Web-Traffic an Ihre Secure Web Proxy-Instanz weitergeleitet. So können Sie verhindern, dass ausgehender Traffic schädliche externe Websites erreicht, und die externen Dienste verwalten, mit denen Ihre Netzwerk-Arbeitslasten eine Verbindung herstellen können.

TCP-Proxyregeln konfigurieren

Sie können TCP-Proxyregeln für Ihre Anwendung konfigurieren, um Nicht-Web-Traffic zu schützen und Sicherheitsrichtlinien für Anwendungen zu erzwingen, die kein Standard-HTTP/S verwenden, z. B. für die Ports 80 und 443.

Durch die Anwendung dieser Regeln können Sie die unbefugte Verwendung anderer TCP-Ports für die Datenübertragung oder schädliche Aktivitäten verhindern. Das ist besonders nützlich, wenn für Ihre Arbeitslasten Secure Web Proxy als nächster Hop für Nicht-Webprotokolle verwendet wird.

Wenn Sie TCP-Proxyregeln implementieren und eine Regel zum Zulassen oder Blockieren von Traffic für Ihre Anwendung erstellen möchten, müssen Sie den Zielport angeben. Optional können Sie eines der folgenden Session Matcher-Attribute einfügen, um die Kriterien der Zulassungs- oder Sperrregel zu verfeinern.

In der folgenden Tabelle finden Sie weitere Informationen zu den verschiedenen Attributen, die Sie in einer TCP-Proxyregel verwenden können:

Attribut Attributtyp Beschreibung
source.ip String Die IP-Adresse des Clients, der die Anfrage gesendet hat.
source.port String Clientport, über den die Anfrage gesendet wurde.
destination.port String Upstream-Port, an den Ihre Secure Web Proxy-Instanz den Traffic sendet.
source.matchTag(SECURE_TAG) boolean

True, wenn die Quelle mit SECURE_TAG verknüpft ist.

Das Argument ist die permanente ID des sicheren Tags, z. B. source.matchTag('tagValues/123456').

source.matchServiceAccount(SERVICE_ACCOUNT) boolean True, wenn die Quelle mit SERVICE_ACCOUNT verknüpft ist, z. B. source.matchServiceAccount('x@my-project.iam.gserviceaccount.com').
inIpRange(IP_ADDRESS,
IP_RANGE)
boolean True, wenn IP_ADDRESS in IP_RANGE enthalten ist, z. B. inIpRange(source.ip, '1.2.3.0/24'). Subnetzmasken für IPv6-Adressen dürfen nicht größer als `/64` sein.

Beispiel für eine TCP-Proxy-Regel

In diesem Beispiel wird gezeigt, wie Sie einen Secure Web Proxy gatewaySecurityPolicyRule mithilfe eines CEL-Ausdrucks definieren, um den gesamten TCP-Traffic an Port 22 zuzulassen. Sie können diese Konfiguration verwenden, wenn Sie die TCP-Proxyfunktionen von Secure Web Proxy anwenden.

Das folgende Codebeispiel zeigt, wie eine TCP-Proxyregel definiert wird:

name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/POLICY_NAME/rules/RULE_NAME
enabled: true
priority: 100 # Lower numbers have higher priority
description: "Allow TCP proxy traffic to port 22 - such as, for SSH"
basicProfile: ALLOW
sessionMatcher: "destination.port == 22"

Ersetzen Sie Folgendes:

  • PROJECT_ID: ID Ihres Projekts
  • REGION: Region Ihrer Richtlinie
  • POLICY_NAME: Name der Richtlinie
  • RULE_NAME: Name der TCP-Proxyregel. In diesem Beispiel können wir den Wert als allow-ssh-tcp-proxy betrachten.

Was Sie bedenken sollten

  • Alle TCP-Proxyregeln, die Sie konfigurieren, müssen eine höhere Priorität (niedrigere Zahl) als HTTP/S-Regeln haben, damit sie zuerst ausgewertet und angewendet werden. Weitere Informationen finden Sie unter Regelauswertungsreihenfolge.

  • Bei der Konfiguration von TCP-Proxyregeln wird das Attribut host-Sitzungsabgleich nicht unterstützt, da auf der TCP-Ebene keine Hostinformationen verfügbar sind.

  • TCP-Proxyregeln filtern Web-Traffic nur anhand des Zielports. Um die Sicherheit Ihres Netzwerks zu erhöhen, empfehlen wir, weitere Bedingungen hinzuzufügen. Verwenden Sie dazu die logischen Operatoren AND (&&) und OR (||) sowie unterstützte Attribute wie source.ip. Hier ein Beispiel für eine spezifischere TCP-Proxyregel:

      // Allow port 22 from only a specific source IP range
      sessionMatcher: "destination.port == 22 && inIpRange(source.ip, '10.0.0.0/24')"
    
  • Secure Web Proxy unterstützt nicht die Konfiguration von Proxyregeln für User Datagram Protocol (UDP)-Anwendungen. Daher blockiert Secure Web Proxy den Traffic von UDP-basierten Anwendungen.

Sicherheitsregel erstellen

Bevor Sie eine Gateway-Sicherheitsregel erstellen, müssen Sie Folgendes tun:

  1. Führen Sie alle Schritte zur Ersteinrichtung aus.

  2. Richtlinie erstellen

Nachdem Sie eine Regel erstellt und mit einer Richtlinie verknüpft haben, können Sie sie beim Bereitstellen von Secure Web Proxy verwenden.

Console

  1. Rufen Sie in der Google Cloud Console die Seite SWP-Richtlinien auf.

    Zu den Richtlinien zum Löschen von Dienstdaten

  2. Klicken Sie auf den Namen Ihrer Richtlinie, z. B. policy1.

  3. Klicken Sie auf Regel hinzufügen.

  4. Führen Sie für jede Regel folgende Schritte aus:

    1. Geben Sie unter Priorität eine numerische Auswertungsreihenfolge für die Regel ein. Die Regeln werden von der höchsten bis zur niedrigsten Priorität ausgewertet, wobei 0 die höchste Priorität ist.

    2. Geben Sie im Feld Name einen Namen für die Regel ein.

    3. Geben Sie im Feld Beschreibung eine Beschreibung für die Regel ein.

    4. Wählen Sie für Aktion eine der folgenden Optionen aus:

      • Zulassen: Damit werden Verbindungsanfragen zugelassen, die der Regel entsprechen.
      • Ablehnen: Verbindungsanfragen, die der Regel entsprechen, werden abgelehnt.
    5. Wählen Sie für das Feld Status eine der folgenden Optionen für die Durchsetzung der Regel aus:

      • Aktiviert: Die Regel wird für Ihre Secure Web Proxy-Instanz erzwungen.
      • Deaktiviert: Die Regel wird nicht für Ihre Secure Web Proxy-Instanz erzwungen.
    6. Geben Sie im Abschnitt Sitzungsabgleich die Kriterien für den Abgleich der Sitzung an, z. B. host() == "www.wikipedia.org".

      Weitere Informationen zur Syntax für SessionMatcher finden Sie in der CEL-Matcher-Sprachreferenz.

    7. Geben Sie im Bereich Application Match (Anwendungsabgleich) die Kriterien für den Abgleich der Anfrage an.

      Weitere Informationen zum Abgleichen von TCP-Traffic finden Sie unter TCP-Proxy-Regeln konfigurieren.

    8. Klicken Sie auf Regel hinzufügen.

Cloud Shell

  1. Erstellen Sie mit Ihrem bevorzugten Texteditor eine rule.yaml-Datei. Weitere Informationen zur Syntax für sessionMatcher finden Sie in der CEL-Matcher-Sprachreferenz.

    name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/policy1/rules/RULE_NAME
    description: Allow wikipedia.org
    enabled: true
    priority: 1
    basicProfile: ALLOW
    sessionMatcher: host() == 'www.wikipedia.org'
    

    Ersetzen Sie Folgendes:

    • PROJECT_ID: ID Ihres Projekts
    • REGION: Region Ihrer Richtlinie
    • RULE_NAME: Name der Regel. In diesem Beispiel können wir den Wert als allow-wikipedia-org betrachten.

    Optional: Wenn Sie stattdessen eine Regel mit aktivierter TLS-Prüfung erstellen möchten, erstellen Sie die Datei rule.yaml wie hier gezeigt. Weitere Informationen finden Sie unter TLS-Prüfung und TLS-Prüfung aktivieren.

      name: projects/PROJECT_ID/locations/REGION/gatewaySecurityPolicies/policy1/rules/RULE_NAME
      description: Allow wikipedia.org
      enabled: true
      priority: 1
      basicProfile: ALLOW
      sessionMatcher: host() == 'www.wikipedia.org'
      applicationMatcher: request.path.contains('index.html')
      tlsInspectionEnabled: true
    

    Weitere Informationen zum Abgleichen von TCP-Traffic finden Sie unter TCP-Proxy-Regeln konfigurieren.

  2. Erstellen Sie die Regel für die Sicherheitsrichtlinie.

    gcloud network-security gateway-security-policies rules import allow-wikipedia-org \
        --source=rule.yaml \
        --location=REGION \
        --gateway-security-policy=policy1
    

Beschränkungen

Nächste Schritte