Regelauswertungsreihenfolge

Bei der Regelauswertung wird anhand der in Ihrer Richtlinie festgelegten Regeln ermittelt, ob eine Webanfrage zugelassen oder abgelehnt werden soll. Dabei werden folgende Attribute berücksichtigt: um Entscheidungen zu treffen:

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

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

So funktioniert die 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 den SessionMatcher und ApplicationMatcher-Attribute bestimmen die auszuführende Aktion über den Verkehr.
  3. Wenn die Anfrage nicht mit SessionMatcher und ApplicationMatcher übereinstimmt dieser Regel enthält, 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. Wird keine Übereinstimmung gefunden, 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 passieren.

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

  • 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 Bewertung zu einer Regel mit einem ApplicationMatcher-Attribut führt, dann getunnelter Traffic als HTTP oder HTTPS interpretiert wird.

    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 TLS-Prüfungs-Flag ist aktiviert.
    • Traffic entspricht den SessionMatcher-Attributen.

Empfehlungen zum Konfigurieren von TLS-Prüfungsregeln

  • Wenn Sie TCP-Traffic zulassen möchten, dann ist die Regel, die TCP-Traffic zulässt, muss 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 kein TLS ausführen kann die Prüfung als TCP-Proxy-Regeln interpretiert werden.
  • Um eine unnötige TLS-Prüfung des Traffics zu vermeiden, sollte eine niedrigere Priorität haben als Prüfregeln ohne TLS. Alternativ können Sie bei nicht übereinstimmendem Traffic schnell ausfallen sollen, sollten die TLS-Prüfungsregeln mithilfe des Attributs SessionMatcher.

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. Beachten 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 interpretiert Secure Web Proxy die beiden Regeln so:

  • TCP-Traffic zulassen, aber einen bestimmten Typ von HTTP-Anfrage nicht zulassen schließen sich gegenseitig aus, da der TCP-Traffic eine POST-Anfrage enthalten kann.
  • Traffic in Regel 2 ist niemals zulässig. Sie wird abgelehnt, da der Traffic vom Tag 12345 zu example.com wird abgefangen und als HTTP interpretiert. um die HTTP-Methode auszuwerten.

  • 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).

    • Umfangsregel 1, um zu vermeiden, dass sich der zulässige Traffic mit seiner SessionMatcher überschneidet Attribut:

      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 für bankofamerica.com, wird Es wird auf TLS geprüft, damit es der request.url() der Regel 1 mit hoher Priorität entspricht.

  • 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 Ebene (Priorität: 5). Daher wird Regel 2 angewendet, bevor Regel 1 ausgewertet wird, und Traffic von bankofamerica.com wird zugelassen, ohne dass eine TLS-Prüfung erfolgt.

    • Empfohlen: Begrenzen Sie den Geltungsbereich von Regel 1, um die TLS-Prüfung speziell für die Domain github.com zuzulassen. Zur Eingrenzung des Umfangs Fügen Sie ein sessionMatcher-Zielattribut hinzu:

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

Beschränkungen

Sie müssen diese Einschränkungen berücksichtigen, bevor Sie die TLS-Prüfung konfigurieren:

  • Server werden nur mithilfe von öffentlichen Root-Zertifikaten verifiziert. Der Stamm Zertifizierungsstelle basiert auf dem Mozilla Root Program. Das Verhalten der Zertifikatsüberprüfung kann sich ändern und entspricht der Methode, mit der Webbrowser Zertifikate überprüfen.

    Da eine Back-End-Bestätigung derzeit nicht möglich ist, Traffic zu Servern mit privaten oder selbst signierten Zertifikaten kann nicht abgefangen.

  • 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 den Servernamen senden Indication (SNI): 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 Folgendes erfordert: Encrypted Client Hello (ECH) (früher „Encrypted SNI“).

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

  • Clients müssen so konfiguriert sein, dass sie Ihrem privaten Stammzertifikat 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 ist Secure Web Proxy gezwungen, neue Zertifikate zu generieren.