Regelauswertungsreihenfolge

Die Regelauswertung bestimmt anhand der Regeln, die Sie in Ihrer Richtlinie festgelegt haben, ob eine Webanfrage zugelassen oder abgelehnt werden soll. Für seine Entscheidungen werden die folgenden Attribute berücksichtigt:

  • Priorität einer Regel:Niedrigere Ganzzahlen weisen auf eine höhere Priorität hin.
  • SessionMatcher:Vergleicht die folgenden Attribute auf Sitzungsebene:
    • IP-Adresse der Quellmaschine
    • Dienstkonto der Quellmaschine
    • Sicheres Tag der Quellmaschine
    • Hostname der Zielmaschine
  • ApplicationMatcher:Gleicht mit den folgenden HTTP-Anfrageattributen ab:
    • URL
    • Pfad
    • Anfrageheader

Eine Liste aller SessionMatcher- und ApplicationMatcher-Attribute finden Sie unter Verfügbare Attribute in SessionMatcher und ApplicationMatcher.

Funktionsweise der Regelauswertung

Die Regeln werden in der folgenden Reihenfolge ausgewertet:

  1. Regeln mit hoher Priorität werden zuerst ausgewertet.
  2. Die Regel mit der höchsten Priorität, die mit den Attributen SessionMatcher und ApplicationMatcher übereinstimmt, bestimmt die für den Traffic auszuführende Aktion.
  3. Wenn die Anfrage nicht mit den Attributen SessionMatcher und ApplicationMatcher dieser Regel übereinstimmt, wird die nächste Regel mit der höchsten Priorität ausgewertet.
  4. Dieser Prozess wird fortgesetzt, bis eine Regel gefunden wird, die der Anfrage entspricht, oder alle Regeln ausgewertet wurden. Wenn keine Übereinstimmung gefunden wird, wird die Anfrage abgelehnt.

Vor der Konfiguration der TLS-Prüfung

Machen Sie sich mit den folgenden Szenarien der Regelauswertung vertraut, bevor Sie die TLS-Prüfung konfigurieren:

  • Ein Client kann eine HTTP-Anfrage an den Proxyserver senden. Die Anfrage wird dann anhand aller verfügbaren Daten ausgewertet, einschließlich Hostname, Quellidentität, HTTP-Header und Pfad.

    Wenn die Anfrage zulässig ist, wird der HTTP-Traffic an das Ziel gesendet. Wird die Anfrage jedoch abgelehnt, wird der HTTP-Traffic nicht weitergeleitet.

  • Ein Client kann dem Proxy eine HTTP CONNECT-Anfrage senden, um einen TCP-Tunnel zum Ziel einzurichten. Dies geschieht, wenn der Client beliebigen TCP-Traffic senden oder wie bei HTTPS über den Proxy eine Ende-zu-Ende-TLS-Verbindung mit dem Ziel herstellen möchte.

  • Wenn eine Regel ein übereinstimmendes SessionMatcher-Attribut und kein ApplicationMatcher-Attribut enthält und die Regelauswertung den Traffic zulässt, wird ein Tunnel zum Ziel eingerichtet und der Traffic wird über TCP weitergeleitet. Dies gilt für HTTPS- und TCP-Traffic.

  • Wenn Regeln mit höherer Priorität die für eine Anfrage auszuführende Aktion nicht ermitteln können, wird die Regelauswertung fortgesetzt. Wenn die Auswertung mit einer Regel mit einem ApplicationMatcher-Attribut fortfährt, wird der getunnelte Traffic als HTTP oder HTTPS interpretiert.

    Wenn die zugrunde liegenden Daten nicht HTTP oder HTTPS sind, schlägt die Verbindung fehl.

    Wenn die zugrunde liegenden Daten HTTP sind, werden die Anfragen ausgewertet, einschließlich Hostname, Quellidentität, HTTP-Header und Pfad. Basierend auf dem Bewertungsergebnis wird der Traffic entweder zugelassen oder abgelehnt.

  • Bei HTTPS-Traffic wird eine Regel nur ausgewertet, wenn das TLS-Prüfungs-Flag aktiviert ist. Andernfalls wird diese Regel übersprungen.

  • Bei HTTPS-Traffic wird eine Regel nur geprüft, wenn die folgenden Bedingungen erfüllt sind:

    • Das Flag für die TLS-Prüfung ist aktiviert.
    • Traffic entspricht den SessionMatcher-Attributen.

Empfehlungen zum Konfigurieren von TLS-Prüfregeln

  • Wenn Sie TCP-Traffic zulassen möchten, muss die Regel, die TCP-Traffic zulässt, eine höhere Priorität haben als die Regeln, die HTTP-Traffic zulassen.
  • Regeln mit dem Attribut ApplicationMatcher sollten eng gefasst sein. Verwenden Sie dazu das Attribut SessionMatcher, um die Interpretation irrelevanter Datenflüsse als HTTP so gering wie möglich zu halten.
  • Regeln, die TLS-Traffic (einschließlich HTTPS) zulassen, aber keine TLS-Prüfung durchführen, können als TCP-Proxy-Regeln interpretiert werden.
  • Um eine unnötige TLS-Prüfung des Traffics zu vermeiden, sollten TLS-Prüfungsregeln eine niedrigere Priorität haben als Nicht-TLS-Prüfungsregeln. Um bei nicht übereinstimmendem Traffic schnell scheitern, sollten die TLS-Prüfungsregeln über das Attribut SessionMatcher genau festgelegt werden.

Beispiele für Konfigurationen von TLS-Prüfregeln

Betrachten Sie die beiden Regeln in den folgenden Beispielen.

Beispiel 1

In diesem Beispiel wird davon ausgegangen, dass andere Regeln mit niedrigerer Priorität vorhanden sind. Berücksichtigen Sie dabei die beiden folgenden Regeln:

  • Regel 1

    description: do not allow POST requests
priority: 10
basicProfile: DENY
sessionMatcher: true
tlsInspectionEnabled: true
applicationMatcher: request.method == 'POST'

  • Regel 2

    description: allow TCP proxying from tag 12345 to example.com
priority: 20
basicProfile: ALLOW
sessionMatcher: source.matchTag('tagValues/12345') && host() == 'example.com'

In diesem Beispiel interpretiert Secure Web Proxy die beiden Regeln so:

  • Wenn TCP-Traffic zugelassen, aber eine bestimmte Art von HTTP-Anfrage nicht zugelassen wird, schließt sich dies gegenseitig aus, da der TCP-Traffic eine POST-Anfrage enthalten kann.
  • Traffic in Regel 2 ist nie zulässig. Sie wird abgelehnt, da der Traffic vom Tag 12345 zu example.com abgefangen und als HTTP interpretiert wird, um die HTTP-Methode auszuwerten.

  • Damit Regel 2 wirksam wird, können Sie eine der folgenden Lösungen verwenden:

    • Empfohlen: Erhöhen Sie die Priorität von Regel 2 auf eine höhere Priorität (Priorität: 5).

    • Legen Sie Regel 1 fest, um eine Überschneidung des zulässigen Traffics mit dem Attribut SessionMatcher zu vermeiden:

      sessionMatcher: !(source.matchTag('tagValues/12345') && host() == 'example.com')

      Wir raten von dieser Lösung ab, da sich viele sich überschneidende Regeln nur schwer verwalten lassen.

Beispiel 2

Berücksichtigen Sie dabei die beiden folgenden Regeln:

  • Regel 1

    description: allow to specific GitHub repository (TLS inspect to match specific path)
priority: 10
basicProfile: ALLOW
sessionMatcher: true
tlsInspectionEnabled: true
applicationMatcher: request.url().startsWith('github.com/grpc/grpc')

  • Regel 2

    description: allow TCP proxying from tag 12345 to example.com
priority: 20
basicProfile: ALLOW
sessionMatcher: host() == 'bankofamerica.com'

In diesem Beispiel interpretiert Secure Web Proxy die beiden Regeln so:

  • Der gesamte Traffic, einschließlich des für bankofamerica.com bestimmten Traffics, wird darauf geprüft, ob TLS dem request.url() der Regel 1 mit hoher Priorität entspricht.

  • Wenn Sie die TLS-Prüfung in Regel 2 vermeiden möchten, können Sie eine der folgenden Lösungen verwenden:

    • Erhöhen Sie die Priorität von Regel 2 auf eine höhere Priorität (Priorität: 5). Daher wird Regel 2 vor der Auswertung von Regel 1 angewendet und Traffic von bankofamerica.com ist ohne TLS-Prüfung zulässig.

    • Empfohlen: Schränken Sie den Umfang von Regel 1 ein, um die TLS-Prüfung speziell für die Domain github.com zuzulassen. Wenn Sie den Umfang eingrenzen möchten, fügen Sie ein sessionMatcher-Attribut für die Ausrichtung hinzu:

      sessionMatcher: host() == 'github.com'

Beschränkungen

Beachten Sie die folgenden Einschränkungen, bevor Sie die TLS-Prüfung konfigurieren:

  • Server werden nur mit öffentlichen Root-Zertifikaten überprüft. Die Root-Zertifizierungsstelle basiert auf dem Mozilla Root Program. Das Verhalten der Zertifikatsprüfung kann sich ändern und entspricht der Überprüfung von Zertifikaten durch Webbrowser.

    Da die Back-End-Überprüfung derzeit nicht möglich ist, kann Traffic an Server mit privaten oder selbst signierten Zertifikaten nicht abgefangen werden.

  • Secure Web Proxy führt keine Prüfungen der Zertifikatssperrliste (Certificate Revocation List, CRL) aus.

  • Damit die TLS-Prüfung funktioniert, müssen Clients derzeit Server Name Indication (SNI) senden. SNI ist eine optionale Erweiterung für die TLS-Spezifikation, die jedoch von den meisten Clients standardmäßig aktiviert wird.

  • Die TLS-Prüfung funktioniert nicht, wenn der Client Encrypted Client Hello (ECH) (früher als verschlüsseltes SNI bezeichnet) benötigt.

    ECH ist ein IETF-Standardentwurf, mit dem Clients den Anfang des TLS-Handshakes mithilfe eines vordefinierten Serverschlüssels verschlüsseln können. Da die TLS-Prüfung als abfangender Proxy fungiert, hat sie keinen Zugriff auf diesen vordefinierten Serverschlüssel. Daher funktioniert ECH nicht.

  • Clients müssen so konfiguriert sein, dass sie Ihrem privaten Root-Zertifikat vertrauen.

  • Wenn Sie CAs aus Ihrem privaten CA-Pool entfernen, erhalten Sie bis zu 28 Stunden lang im Cache gespeicherte Zertifikate, die von dieser Zertifizierungsstelle signiert wurden. Wenn Sie verhindern möchten, dass die im Cache gespeicherten Zertifikate verwendet werden, können Sie Ihre TLS-Prüfungsrichtlinie so aktualisieren, dass sie auf einen neuen CA-Pool verweist. Infolgedessen ist Secure Web Proxy gezwungen, neue Zertifikate zu generieren.