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, 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 Funktionen:

  • 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 Dienst konto.

    • Ziel: Wohin geht die Anfrage, z. B. 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 durch klare, strukturierte Definitionen verschiedene Sicherheitsstandards in Ihrer Organisation erzwingen.

Regeln für den Hostabgleich

Secure Web Proxy verwendet den Hostnamenabgleich, um die Zieldomain zu überprüfen. Der Überprüfungsprozess variiert je nach Bereitstellung des Proxys, wie in der folgenden Tabelle dargestellt.

Bereitstellungsmodus Hostüberprüfungsprozess
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.
Modus für den nächsten Hop Bei verschlüsseltem Traffic prüft der Proxy den Ziel hostnamen anhand des Felds „Server Name Indication“ (SNI) in der ausgehenden Anfrage. Dieses Feld ist auch bei sicheren Verbindungen sichtbar.

Regeln für den Hostabgleich für den expliziten Proxymodus konfigurieren

Wenn Sie Secure Web Proxy als expliziten Proxy bereitstellen, konfigurieren Sie Regeln für den Hostabgleich, um zu überprüfen, ob die vom Client gesendeten Hostinformationen korrekt extrahiert und anhand Ihrer definierten Sicherheitsregeln geprüft werden. Im expliziten Proxymodus werden 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 Abgleichsmechanismus Regelkonfiguration
Unverschlüsseltes HTTP Secure Web Proxy prüft den Zielhostnamen anhand des host Felds im Standard CONNECT Headers der HTTP-Anfrage. Verwenden Sie im Feld sessionMatcher die Option host() == "example.com".
Verschlüsseltes HTTPS (ohne Transport Layer Security (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 destination.ip Attribut 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, verwenden Sie entweder den Abgleich der Quell identität wie Dienstkonten oder aktivieren Sie die TLS-Prüfung.
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 Host Regel hinzu, z. B. request.host() == "example.com".

Regeln für den Hostabgleich für den Modus für den nächsten 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. Regeln für den Hostabgleich 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 Modus für den nächsten Hop funktioniert für verschiedene Arten von Webtraffic so:

Traffictyp Abgleichsmechanismus Regelkonfiguration
Unverschlüsseltes HTTP Secure Web Proxy prüft den Zielhostnamen anhand des host Felds im Standard HTTP-Anfrageheaders. Verwenden Sie im Feld sessionMatcher die Option host() == "example.com".
Verschlüsseltes HTTPS (ohne TLS-Prüfung) Secure Web Proxy prüft den Hostnamen anhand des SNI-Headers in der ausgehenden Anfrage, der auch dann sichtbar ist, wenn der restliche Traffic verschlüsselt ist. Verwenden Sie im Feld sessionMatcher die Option 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-Proxyregeln

Mit TCP-Proxyregeln (Transmission Control Protocol) können Sie Traffic steuern, der kein Standard-Webtraffic 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 Ihre Arbeitslast (z. B. Ihre Anwendungen und Dienste) Secure Web Proxy als nächsten Hop verwendet, ist die Anwendung von TCP-Proxyregeln von Vorteil. Die routenbasierte Weiterleitung leitet Nicht-HTTP(S)- und Nicht-Webtraffic an Ihre Secure Web Proxy-Instanz weiter. So können Sie verhindern, dass ausgehender Traffic schädliche externe Websites erreicht, und die externen Dienste verwalten, mit denen sich Ihre Netzwerk-Arbeitslasten verbinden können.

TCP-Proxyregeln konfigurieren

Sie können TCP-Proxyregeln für Ihre Anwendung konfigurieren, um Nicht-Webtraffic 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. Dies ist besonders nützlich, wenn Ihre Arbeitslasten Secure Web Proxy als nächsten Hop für Nicht-Webprotokolle verwenden.

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 Regel zum Zulassen oder Blockieren zu verfeinern.

Die folgende Tabelle enthält weitere Informationen zu den verschiedenen Attributen, die Sie in einer TCP-Proxyregel verwenden können:

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

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) Boolesch 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)		 Boolesch 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-Proxyregel

In diesem Beispiel wird gezeigt, wie Sie eine Secure Web Proxy gatewaySecurityPolicyRule definieren, indem Sie einen CEL-Ausdruck verwenden, 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 Sie eine TCP-Proxyregel definieren:

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 Ihrer 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 von Ihnen konfigurierten TCP-Proxyregeln müssen eine höhere Priorität (niedrigere Zahl) als HTTP/S-Regeln haben, damit sie zuerst ausgewertet und ausgeführt werden. Weitere Informationen finden Sie unter Regelauswertungsreihenfolge.

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

  • TCP-Proxyregeln filtern Webtraffic nur anhand des Zielports. Um die Sicherheit Ihres Netzwerks zu erhöhen, empfehlen wir, weitere Bedingungen mit logischen Operatoren, dem logischen AND-Operator (&&) und dem logischen OR-Operator (||) sowie unterstützten Attributen wie source.ip hinzuzufügen. Hier ein Beispiel dafür, wie Sie eine spezifischere TCP-Proxyregel definieren:

      // 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 Proxy regeln für UDP-Anwendungen (User Datagram Protocol). Daher blockiert Secure Web Proxy den Traffic von UDP-basierten Anwendungen.

Sicherheitsregel erstellen

Bevor Sie eine Gateway-Sicherheitsregel erstellen, führen Sie die folgenden Schritte aus:

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

  2. Richtlinie erstellen

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

Console

  1. Öffnen Sie in der Google Cloud Console die Seite SWP-Richtlinien.

    Zu den SWP-Richtlinien

  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 zulassen, die der Regel entsprechen.
      • Ablehnen: Verbindungsanfragen ablehnen, die der Regel entsprechen.

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

      • Aktiviert: Die Regel für Ihre Secure Web Proxy Instanz erzwingen.
      • Deaktiviert: Die Regel für Ihre Secure Web Proxy Instanz nicht erzwingen.

    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 unter CEL-Matcher-Sprachreferenz.

    7. Geben Sie im Abschnitt Anwendungsabgleich die Kriterien für den Abgleich der Anfrage an.

      Weitere Informationen zum Abgleich von TCP-Traffic finden Sie unter TCP-Proxyregeln 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 unter 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 alternativ eine Regel mit aktivierter TLS Prüfung erstellen möchten, erstellen Sie die rule.yaml Datei 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-Proxyregeln 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