Regeln konfigurieren

Mit Secure Web Proxy können Sie verschiedene Arten von Regeln in Ihren Richtlinien 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.

Auf dieser Seite werden die verschiedenen Arten von Regeln und die Schritte zum Erstellen und Hinzufügen zu Ihrer Sicherheitsrichtlinie beschrieben.

Regeln für den Hostabgleich konfigurieren

Mit Regeln für den Hostabgleich wird der Zielhostname einer Webanfrage mit Ihren Listen zulässiger oder abgelehnter URL-Listen verglichen. Durch Prüfung der Zieldomain wie z. B. www.example.comstellen diese Regeln sicher, dass Ihr Traffic nur genehmigte Websites und Dienste erreicht.

In diesem Abschnitt wird erläutert, wie Sie Regeln für den Hostabgleich für die folgenden Bereitstellungsmodi von Secure Web Proxy konfigurieren:

Expliziter Proxymodus
Modus „Nächster Hop“

Expliziter Proxymodus

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 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 Web traffic so:

Traffictyp	Abgleichmechanismus	Regelkonfiguration
Nicht verschlüsseltes HTTP	Secure Web Proxy vergleicht den Zielhostname mit dem `host` Feld im Standard `CONNECT` Header der HTTP-Anfrage.	Verwenden Sie im Feld `sessionMatcher` die Option `host() == "example.com"`.
Verschlüsseltes HTTPS (ohne TLS-Prüfung (Transport Layer Security) )	Der Hostabgleich ist weder auf Anwendungs ebene noch auf Sitzungsebene möglich. Das liegt daran, dass die Anfragedetails verschlüsselt sind und das Attribut nicht unterstützt wird.`destination.ip` 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 den Zielhost abgleicht, z. B. `host() == "example.com"`. 2. Fügen Sie im Feld `applicationMatcher` eine bestimmte Host Regel hinzu, z. B. `request.host() == "example.com"`.

Modus „Nächster Hop“

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 „Nächster Hop“ funktioniert für verschiedene Arten von Web traffic so:

Traffictyp	Abgleichmechanismus	Regelkonfiguration
Nicht verschlüsseltes HTTP	Secure Web Proxy vergleicht den Zielhostname mit dem `host` Feld im Standard Header der HTTP-Anfrage.	Verwenden Sie im Feld `sessionMatcher` die Option `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` 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 den Zielhost abgleicht, z. B. `host() == "example.com"`. 2. Fügen Sie im Feld `applicationMatcher` eine bestimmte Hostregel hinzu, z. B. `request.host() == "example.com"`.

TCP-Proxyregeln konfigurieren

Sie können TCP-Proxyregeln (Transmission Control Protocol) 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 Anwenden dieser Regeln können Sie die unbefugte Verwendung 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-Web-Protokolle 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.

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	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 angewendet werden. Weitere Informationen finden Sie unter Regelauswertungsreihenfolge.
Beim Konfigurieren von TCP-Proxyregeln wird das host Session Matcher Attribut 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 Ihnen, weitere Bedingungen hinzuzufügen, indem Sie logische Operatoren verwenden: den logischen AND-Operator (&&) und den logischen OR-Operator (||) sowie unterstützte Attribute wiesource.ip. Hier ist ein Beispiel für die Definition einer spezifischeren 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 Proxy regeln für UDP-Anwendungen (User Datagram Protocol). Daher blockiert Secure Web Proxy den Traffic von UDP-basierten Anwendungen.

Secure Web Proxy-Regel erstellen

In diesem Abschnitt wird erläutert, wie Sie eine Secure Web Proxy-Regel erstellen.

Führen Sie die folgenden Schritte aus, bevor Sie eine Regel erstellen:

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

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

Console

Öffnen Sie in der Google Cloud Console die Seite Richtlinien zum Löschen von Dienstdaten.

Zu „Richtlinien zum Löschen von Dienstdaten“
Klicken Sie auf den Namen Ihrer Richtlinie, z. B. policy1.
Klicken Sie auf Regel hinzufügen.
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

Erstellen Sie die rule.yaml Datei wie hier gezeigt. 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 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.

Wichtig: Wenn Sie die TLS-Prüfung für jede von Ihnen erstellte Regel aktivieren möchten, legen Sie das Attribut tlsInspectionEnabled für jede Regel, die applicationMatcher verwendet, um HTTPS-Traffic abzugleichen, auf true fest. Die TLS Prüfung für die Regel ist auf den Traffic beschränkt, der mit dem sessionMatcher Attribut der Regel übereinstimmt. Weitere Informationen finden Sie unter Auswertung von TLS-Prüfungsregeln.

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