Regelauswertungsreihenfolge

Bei der Regelauswertung wird anhand der in Ihrer Richtlinie festgelegten Regeln ermittelt, ob eine Webanfrage zugelassen oder abgelehnt werden soll. Bei der Entscheidungsfindung werden die folgenden Attribute berücksichtigt:

  • Priorität einer Regel:Je niedriger die Zahl, desto höher die Priorität.
  • SessionMatcher:Übereinstimmung mit den folgenden Attributen auf Sitzungsebene:
    • IP-Adresse des Quellcomputers
    • Dienstkonto des Quellcomputers
    • Sicheres Tag der Quellmaschine
    • Hostname des Zielcomputers
  • ApplicationMatcher:Wird mit den folgenden HTTP-Anfrageattributen abgeglichen:
    • URL
    • Pfad
    • Anfrageheader

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

So funktioniert die Regelbewertung

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 Aktion, die für den Traffic ausgeführt werden soll.
  3. Wenn die Anfrage nicht mit den SessionMatcher- und ApplicationMatcher-Attributen dieser Regel übereinstimmt, wird die nächste Regel mit der höchsten Priorität ausgewertet.
  4. Dieser Vorgang wird fortgesetzt, bis eine Regel gefunden wird, die mit der Anfrage übereinstimmt, oder bis alle Regeln ausgewertet wurden. Wenn keine Übereinstimmung gefunden wird, wird die Anfrage abgelehnt.

Bevor Sie die TLS-Prüfung konfigurieren

Sie müssen die folgenden Szenarien für die Regelauswertung kennen, 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. Wenn die Anfrage jedoch abgelehnt wird, darf der HTTP-Traffic nicht weitergeleitet werden.

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

  • Wenn eine Regel ein übereinstimmendes SessionMatcher-Attribut hat, aber kein ApplicationMatcher-Attribut, und die Regelauswertung dazu führt, dass der Traffic zugelassen wird, wird ein Tunnel zum Ziel eingerichtet und der Traffic wird über einen TCP-Proxy geleitet. Dies gilt für HTTPS- und TCP-Traffic.

  • Wenn anhand von Regeln mit höherer Priorität nicht ermittelt werden kann, welche Aktion bei einer Anfrage ausgeführt werden soll, wird die Regelauswertung fortgesetzt. Wenn die Auswertung mit einer Regel mit einem ApplicationMatcher-Attribut fortgesetzt wird, 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 Ergebnis der Bewertung wird der Traffic entweder zugelassen oder abgelehnt.

  • Bei HTTPS-Traffic wird eine Regel nur ausgewertet, wenn das Flag „TLS-Prüfung“ aktiviert ist. Andernfalls wird sie ü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.
    • Der Traffic stimmt mit den SessionMatcher-Attributen überein.

Empfehlungen für die Konfiguration von TLS-Prüfungsregeln

  • 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 ApplicationMatcher-Attribut sollten mithilfe des SessionMatcher-Attributs genau eingegrenzt werden, um die Interpretation nicht zueinander gehörender Streams als HTTP zu minimieren.
  • Regeln, die TLS-Traffic (einschließlich HTTPS) zulassen, aber keine TLS-Prüfung durchführen, können als TCP-Proxyregeln interpretiert werden.
  • Um eine unnötige TLS-Prüfung des Traffics zu vermeiden, sollten TLS-Prüfungsregeln eine niedrigere Priorität als Nicht-TLS-Prüfungsregeln haben. Alternativ können Sie TLS-Prüfungsregeln mithilfe des Attributs SessionMatcher genau eingrenzen, um bei nicht übereinstimmendem Traffic schnell zu scheitern.

Beispiele für Konfigurationen von TLS-Prüfungsregeln

Betrachten Sie die beiden Regeln in den folgenden Beispielen.

Beispiel 1

In diesem Beispiel gehen wir davon aus, dass andere Regeln mit niedrigerer Priorität vorhanden sind. Betrachten Sie die folgenden beiden 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 werden die beiden Regeln von Secure Web Proxy so interpretiert:

  • Das Zulassen von TCP-Traffic, aber das Blockieren einer bestimmten Art von HTTP-Anfrage ist nicht möglich, da der TCP-Traffic eine POST-Anfrage enthalten kann.
  • Traffic in Regel 2 ist niemals zulässig. Der Zugriff wird abgelehnt, weil der Traffic von Tag 12345 zu beispiel.de abgefangen und als HTTP interpretiert wird, um die HTTP-Methode zu bewerten.

  • Damit Regel 2 wirksam wird, haben Sie folgende Möglichkeiten:

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

    • Begrenzen Sie Regel 1, um eine Überschneidung des zulässigen Traffics mit seinem SessionMatcher-Attribut zu vermeiden:

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

      Wir empfehlen diese Lösung nicht, da es schwierig wird, viele sich überschneidende Regeln zu verwalten.

Beispiel 2

Betrachten Sie die folgenden beiden 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 werden die beiden Regeln von Secure Web Proxy so interpretiert:

  • Der gesamte Traffic, einschließlich des Traffics, der an bankofamerica.com gesendet wird, wird auf TLS geprüft, um mit dem request.url() der Regel mit hoher Priorität 1 übereinzustimmen.

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

    • Erhöhen Sie die Priorität von Regel 2 auf eine höhere Stufe (Priorität: 5). Daher wird Regel 2 angewendet, bevor Regel 1 ausgewertet wird, und Traffic von bankofamerica.com wird zugelassen, ohne dass er TLS-geprüft wird.

    • Empfohlen: Begrenzen Sie den Geltungsbereich von Regel 1, um die TLS-Prüfung speziell für die Domain github.com zuzulassen. Wenn Sie den Umfang eingrenzen möchten, fügen Sie ein ausgerichtetes sessionMatcher-Attribut 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 Stammzertifikaten verifiziert. Die Stammzertifizierungsstellen basieren auf dem Mozilla Root Program. Das Verhalten der Zertifikatsüberprüfung kann sich ändern und entspricht der Überprüfung von Zertifikaten in Webbrowsern.

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

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

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

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

    ECH ist ein IETF-Entwurfsstandard, mit dem Clients den Beginn des TLS-Handshakes mit einem vorab eingerichteten Serverschlüssel verschlüsseln können. Da die TLS-Prüfung als Abfang-Proxy fungiert, hat sie keinen Zugriff auf diesen vorab eingerichteten Serverschlüssel. Daher funktioniert ECH nicht.

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

  • Wenn Sie Zertifizierungsstellen aus Ihrem privaten CA-Pool entfernen, werden Ihnen bis zu 28 Stunden lang von dieser Zertifizierungsstelle signierte Zertifikate aus dem Cache gesendet. Wenn Sie die Verwendung der im Cache gespeicherten Zertifikate verhindern möchten, können Sie Ihre TLS-Prüfungsrichtlinie so aktualisieren, dass sie auf einen neuen CA-Pool verweist. Daher muss der Secure Web Proxy neue Zertifikate generieren.