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 genau steuern, indem Sie bestimmte Anfragedetails wie Header und URL-Muster verwenden, um sicherzustellen, dass nur genehmigter HTTP/S-Traffic Ihr Netzwerk verlässt.

Gateway-Sicherheitsregeln haben die folgenden Features:

  • Jede Regel ist eine if-then-Anweisung, die eine Webanfrage anhand der folgenden Parameter prüft:

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

    • Ziel: Wohin die Anfrage gesendet wird, z. B. eine Ziel-URL oder 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 mithilfe klarer, strukturierter Definitionen verschiedene Sicherheitsstandards in Ihrer Organisation erzwingen.

Hostabgleichsregeln

Secure Web Proxy verwendet den Hostnamenabgleich, um die Zieldomain zu prüfen. Der Überprüfungsprozess variiert je nachdem, wie Ihr Proxy bereitgestellt wird, wie in der folgenden Tabelle gezeigt.

Bereitstellungsmodus Überprüfungsprozess für Gastgeber
Expliziter Proxymodus Bei unverschlüsseltem Traffic prüft der Proxy den Hostnamen anhand des HTTP-Verbindungsheaders. Wenn Sie Application Matcher-Attribute für die TLS-Prüfung verwenden, prüft der Proxy den Hostnamen zuerst auf Verbindungsebene und dann auf Anwendungsebene.
Nächster Hop-Modus Bei verschlüsseltem Traffic vergleicht der Proxy den Zielhostnamen mit dem Feld „Server Name Indication“ (SNI) in der ausgehenden Anfrage. Dieses Feld ist auch bei sicheren Verbindungen sichtbar.

Hostabgleichsregeln für den expliziten Proxymodus konfigurieren

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

Der Hostabgleich im expliziten Proxymodus funktioniert für verschiedene Arten von Webtraffic so:

Traffictyp Abgleichmechanismus Regelkonfiguration
Unverschlüsseltes HTTP Secure Web Proxy vergleicht den Zielhostnamen mit dem Feld host im Standard-CONNECT-Header der HTTP-Anfrage. Verwenden Sie im Feld sessionMatcher den Wert host() == "example.com".
Verschlüsseltes HTTPS (ohne TLS-Prüfung (Transport Layer Security)) 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 Richtlinieneinstellungen 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 von Quellidentitäten 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 hinzu, z. B. request.host() == "example.com".

Hostabgleichsregeln für den Next-Hop-Modus 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 Hostabgleich im Next-Hop-Modus funktioniert für verschiedene Arten von Webtraffic so:

Traffictyp Abgleichmechanismus 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 hinzu, z. B. request.host() == "example.com".

TCP-Proxy-Regeln

Mit TCP-Proxy-Regeln (Transmission Control Protocol) können Sie Traffic steuern, der kein Standard-Webtraffic ist, z. B. HTTP (Port 80) oder HTTPS (Port 443). Durch die Konfiguration von TCP-Proxy-Regeln können Sie Traffic auf 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 Ihre Arbeitslast (z. B. Ihre Anwendungen und Dienste) Secure Web Proxy als nächsten Hop verwendet, ist die Anwendung von TCP-Proxy-Regeln von Vorteil. 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 bösartige externe Websites erreicht, und die externen Dienste verwalten, mit denen Ihre Netzwerk-Arbeitslasten eine Verbindung herstellen können.

TCP-Proxy-Regeln konfigurieren

Sie können TCP-Proxy-Regeln 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 Nutzung anderer TCP-Ports für die Datenübertragung oder böswillige Aktivitäten verhindern. Das ist besonders nützlich, wenn Ihre Arbeitslasten Secure Web Proxy als nächsten Hop für Nicht-Webprotokolle verwenden.

Wenn Sie TCP-Proxy-Regeln 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-Proxy-Regel verwenden können:

Attribut Attributtyp Beschreibung
source.ip String IP-Adresse des Clients, der die Anfrage gesendet hat.
source.port String Clientport, der die Anfrage gesendet hat.
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 dauerhafte 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.').
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-Proxy-Funktionen von Secure Web Proxy anwenden.

Im folgenden Codebeispiel wird gezeigt, wie eine TCP-Proxy-Regel 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-Proxy-Regel. In diesem Beispiel können wir den Wert als allow-ssh-tcp-proxy betrachten.

Was Sie bedenken sollten

  • Alle von Ihnen konfigurierten TCP-Proxy-Regeln 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.

  • Beim Konfigurieren von TCP-Proxy-Regeln wird das Session Matcher-Attribut host nicht unterstützt, da Hostinformationen auf der TCP-Ebene nicht verfügbar sind.

  • TCP-Proxy-Regeln filtern Webtraffic nur anhand des Zielports. Zur Erhöhung der Sicherheit Ihres Netzwerks empfehlen wir, weitere Bedingungen mit logischen Operatoren wie dem logischen UND-Operator (&&) und dem logischen ODER-Operator (||) sowie unterstützten Attributen wie source.ip hinzuzufügen. Hier ein Beispiel für die Definition einer spezifischeren TCP-Proxy-Regel:

      // 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 Möglichkeit, Proxyregeln für User Datagram Protocol (UDP)-Anwendungen zu konfigurieren. Daher blockiert Secure Web Proxy den Traffic von UDP-basierten Anwendungen.

Sicherheitsregel erstellen

Führen Sie vor dem Erstellen einer Gateway-Sicherheitsregel die folgenden Aktionen aus:

  1. Führen Sie alle Schritte für die Ersteinrichtung aus.

  2. Richtlinie erstellen

Nachdem Sie eine Regel erstellt und mit einer Richtlinie verknüpft haben, können Sie die Regel 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 die folgenden 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 unter Aktion eine der folgenden Optionen aus:

      • Zulassen: Verbindungsanfragen, die der Regel entsprechen, werden zugelassen.
      • Ablehnen: Verbindungsanfragen, die der Regel entsprechen, werden abgelehnt.

    5. Wählen Sie im Feld Status eine der folgenden Optionen für die Regelerzwingung aus:

      • Aktiviert: Die Regel wird auf Ihrer Secure Web Proxy-Instanz erzwungen.
      • Deaktiviert: Die Regel wird nicht für Ihre Secure Web Proxy-Instanz erzwungen.

    6. Geben Sie im Abschnitt Sitzungsübereinstimmung die Kriterien für die Übereinstimmung 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 Abschnitt Anwendungsübereinstimmung die Kriterien für die Übereinstimmung mit der Anfrage an.

      Weitere Informationen zum Abgleich 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 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 Abgleich von TCP-Traffic finden Sie unter TCP-Proxy-Regeln konfigurieren.

  2. Erstellen Sie die Sicherheitsrichtlinienregel. 

    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