Ordre d'évaluation des règles

L'évaluation des règles détermine si une requête Web doit être autorisée ou refusée à l'aide des règles que vous définissez dans votre stratégie. Pour prendre ses décisions, il prend en compte les attributs suivants :

  • Priorité d'une règle:les nombres entiers les plus faibles indiquent les priorités les plus élevées.
  • SessionMatcher::établit une correspondance avec les attributs au niveau de la session suivants:
    • Adresse IP de la machine source
    • Compte de service de la machine source
    • Tag sécurisé de la machine source
    • Nom d'hôte de la machine cible
  • ApplicationMatcher:établit une correspondance avec les attributs de requête HTTP suivants:
    • URL
    • Chemin d'accès
    • En-têtes de requête

Pour obtenir la liste de tous les attributs SessionMatcher et ApplicationMatcher, consultez la section Attributs disponibles dans SessionMatcher et ApplicationMatcher.

Fonctionnement de l'évaluation des règles

Les règles sont évaluées dans l'ordre suivant :

  1. Les règles à priorité élevée sont évaluées en premier.
  2. La règle ayant la priorité la plus élevée qui correspond aux SessionMatcher et Les attributs ApplicationMatcher déterminent l'action à effectuer le trafic.
  3. Si la requête ne correspond pas aux attributs SessionMatcher et ApplicationMatcher de cette règle, la règle suivante ayant la priorité la plus élevée est évaluée.
  4. Ce processus se poursuit jusqu'à ce qu'une règle correspondant à la requête soit trouvée ou que toutes les règles aient été évaluées. Si aucune correspondance n'est trouvée, la demande est refusée.

Avant de configurer l'inspection TLS

Vous devez comprendre les scénarios d'évaluation des règles suivants avant de configurer l'inspection TLS :

  • Un client peut envoyer une requête HTTP au serveur proxy. La demande est ensuite évalué en utilisant toutes les données disponibles, y compris le nom d’hôte, l'identité de la source, les en-têtes HTTP et le chemin d'accès.

    Si la requête est autorisée, le trafic HTTP est envoyé à la destination. Toutefois, si la requête est refusée, le trafic HTTP n'est pas autorisé à être transmis.

  • Un client peut envoyer au proxy une requête HTTP CONNECT pour établir un tunnel TCP vers la destination. Cela se produit lorsque le client souhaite envoyer du trafic TCP arbitraire ou établir une connexion TLS de bout en bout avec la destination via le proxy, comme avec HTTPS.

  • Si une règle possède un attribut SessionMatcher correspondant et ne contient pas un attribut ApplicationMatcher, et l'évaluation de la règle aboutit autorisant le trafic, un tunnel vers la destination est établi et le trafic est acheminé par proxy TCP. Cela s'applique au trafic HTTPS et TCP.

  • Si les règles de priorité supérieure ne permettent pas de déterminer l'action à entreprendre sur une requête, l'évaluation de la règle se poursuit. Si l'évaluation passe à une règle avec un attribut ApplicationMatcher, alors le trafic acheminé par tunnel est interprété comme HTTP ou HTTPS.

    Si les données sous-jacentes ne sont pas de type HTTP ou HTTPS, la connexion échoue.

    Si les données sous-jacentes sont HTTP, les requêtes sont évaluées, y compris le nom d'hôte, l'identité source, les en-têtes HTTP et le chemin d'accès. En fonction du résultat de l'évaluation, le trafic est autorisé ou refusé.

  • Pour le trafic HTTPS, une règle n'est évaluée que si elle dispose de l'inspection TLS est activé. sinon elle est ignorée.

  • Pour le trafic HTTPS, une règle n'est inspectée que si les conditions suivantes sont remplies:

    • L'indicateur d'inspection TLS est activé.
    • Le trafic correspond aux attributs SessionMatcher.

Recommandations pour la configuration des règles d'inspection TLS

  • Si vous souhaitez autoriser le trafic TCP, la règle qui autorise le trafic TCP doivent avoir une priorité plus élevée que les règles qui autorisent le trafic HTTP.
  • Les règles avec l'attribut ApplicationMatcher doivent être étroitement définies à l'aide de l'attribut SessionMatcher afin de minimiser l'interprétation des flux sans rapport comme HTTP.
  • Les règles qui autorisent le trafic TLS (y compris HTTPS), mais qui n'effectuent pas d'inspection TLS, peuvent être interprétées comme des règles de proxy TCP.
  • Pour éviter une inspection TLS inutile du trafic, les règles d'inspection TLS doivent avoir une priorité inférieure aux règles d'inspection non TLS. Pour échouer rapidement en cas de trafic non correspondant, les règles d'inspection TLS doivent être étroitement définies à l'aide de l'attribut SessionMatcher.

Exemples de configurations des règles d'inspection TLS

Examinons les deux règles présentées dans les exemples suivants.

Exemple 1

Dans cet exemple, nous supposons qu'il existe d'autres règles de priorité inférieure. Prenons les deux règles suivantes :

  • Règle 1

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

  • Règle 2

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

Dans cet exemple, Secure Web Proxy interprète les deux règles comme suit :

  • Autoriser le trafic TCP, mais interdire un type spécifique de requête HTTP s’excluent mutuellement car le trafic TCP peut contenir une requête POST.
  • Le trafic de la règle 2 n'est jamais autorisé. Il est refusé, car le trafic de la balise 12345 vers example.com est intercepté et interprété comme HTTP pour évaluer la méthode HTTP.

  • Pour que la règle 2 soit appliquée, vous pouvez utiliser l'une des solutions suivantes :

    • Recommandation : Augmentez la priorité de la règle 2 à un niveau supérieur (priorité : 5).

    • Règle de champ d'application 1 pour éviter de chevaucher le trafic autorisé avec sa SessionMatcher attribut:

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

      Nous déconseillons cette solution, car il devient difficile de maintiennent de nombreuses règles qui se chevauchent.

Exemple 2

Considérez les deux règles suivantes:

  • Règle 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')

  • Règle 2

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

Dans cet exemple, Secure Web Proxy interprète les deux règles comme suit :

  • L'ensemble du trafic, y compris celui à destination de bankofamerica.com, est inspecté pour vérifier que TLS correspond au request.url() de la règle de priorité élevée 1.

  • Pour éviter l'inspection TLS dans la règle 2, vous pouvez utiliser l'une des méthodes suivantes : solutions:

    • Augmentez la priorité de la règle 2 à un niveau supérieur (priorité: 5). Par conséquent, la règle 2 est appliquée avant d'évaluer la règle 1, et le trafic provenant de bankofamerica.com est autorisé sans être inspecté par TLS.

    • Recommandation: limitez le champ d'application de la règle 1 pour autoriser l'inspection TLS spécifiquement pour le domaine github.com. Pour affiner la portée, ajoutez un attribut sessionMatcher ciblé :

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

Limites

Vous devez tenir compte de ces limites avant de configurer l'inspection TLS :

  • Les serveurs ne sont validés qu'à l'aide de certificats racine publics. L'ensemble d'autorités de certification racine est basé sur le programme racine Mozilla. Le comportement de la validation des certificats est susceptible d'évoluer et correspond à la façon dont les navigateurs Web valident les certificats.

    Étant donné qu'il n'est pas possible de valider le backend pour le moment, le trafic vers les serveurs avec des certificats privés ou autosignés ne peut pas être intercepté.

  • Le proxy Web sécurisé n'exécute pas de vérifications des listes de révocation de certificats (LRC).

  • Pour que l'inspection TLS fonctionne, les clients doivent actuellement envoyer l'extension SNI (Server Name Indication). SNI est une extension de spécification TLS facultative, mais la plupart des clients l'activent par défaut.

  • L'inspection TLS ne fonctionne pas si le client nécessite Encrypted Client Hello (ECH) (anciennement appelé SNI chiffré).

    L'ECH est un projet de norme IETF qui permet aux clients de chiffrer le début du handshake TLS à l'aide d'une clé de serveur prédéfinie. Étant donné que l'inspection TLS agit en tant que proxy intercepteur, elle n'a pas accès à cette clé de serveur préétablie. Par conséquent, ECH ne fonctionne pas.

  • Les clients doivent être configurés pour approuver votre certificat racine privé.

  • Si vous supprimez des autorités de certification de votre pool d'autorités de certification privées, vous êtes mis en cache de certificats signés par cette autorité de certification pendant 28 heures. Pour éviter d'utiliser les certificats mis en cache, vous pouvez mettre à jour votre règle d'inspection TLS pour qu'elle pointe vers un nouveau pool d'autorités de certification. Par conséquent, le proxy Web sécurisé doit obligatoirement générer de nouveaux certificats.