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 entiers les plus bas indiquent les priorités les plus élevées.
  • SessionMatcher:correspond aux attributs de niveau de 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:correspond aux 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 de priorité élevée sont évaluées en premier.
  2. La règle de priorité la plus élevée qui correspond aux attributs SessionMatcher et ApplicationMatcher détermine l'action à effectuer sur 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 requête 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 requête est ensuite évaluée à l'aide de 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é à passer.

  • 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 comporte un attribut SessionMatcher correspondant et ne contient pas d'attribut ApplicationMatcher, et que l'évaluation de la règle autorise le trafic, un tunnel vers la destination est établi et le trafic est mis en proxy TCP. Cela s'applique au trafic HTTPS et TCP.

  • Si les règles de priorité supérieure ne parviennent pas à déterminer l'action à effectuer pour une requête, l'évaluation des règles se poursuit. Si l'évaluation passe à une règle avec un attribut ApplicationMatcher, le trafic en tunnel est interprété comme HTTP ou HTTPS.

    Si les données sous-jacentes ne sont pas 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 l'indicateur d'inspection TLS est activé. Sinon, cette règle 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 configurer des règles d'inspection TLS

  • Si vous souhaitez autoriser le trafic TCP, la règle qui autorise le trafic TCP doit 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 de règles d'inspection TLS

Prenons les deux règles des exemples suivants.

Exemple 1

Dans cet exemple, nous supposons la présence 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, le proxy Web sécurisé interprète les deux règles comme suit:

  • Autoriser le trafic TCP, mais refuser un type spécifique de requête HTTP est mutuellement exclusif, 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).

    • Délimitez la règle 1 pour éviter que le trafic autorisé ne chevauche son attribut SessionMatcher:

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

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

Exemple 2

Prenons 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, le proxy Web sécurisé interprète les deux règles comme suit:

  • Tout le trafic, y compris celui destiné à bankofamerica.com, est inspecté pour que TLS corresponde à la 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 solutions suivantes:

    • 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 l'évaluation de la règle 1, et le trafic provenant de bankofamerica.com est autorisé sans être inspecté par TLS.

    • Recommandation: Réduisez 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 la 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 recevez des certificats mis en cache signés par cette autorité de certification pendant une durée maximale de 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é est contraint de générer de nouveaux certificats.