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 avez définies dans votre stratégie. Il tient compte des attributs suivants pour prendre ses décisions:

  • Priorité d'une règle:plus la valeur de l'entier est faible, plus la priorité est élevée.
  • SessionMatcher:établit une correspondance avec les 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:é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 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 de priorité la plus élevée correspondant 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 en utilisant toutes les données disponibles, y compris le nom d'hôte, l'identité source, les en-têtes HTTP et le chemin d'accès.

    Si la requête est autorisée, le trafic HTTP est envoyé vers 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 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 transmis par 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 sur une requête, l'évaluation des règles se poursuit. Si l'évaluation passe à une règle avec un attribut ApplicationMatcher, le trafic tunnelisé est interprété comme HTTP ou HTTPS.

    Si les données sous-jacentes ne sont ni HTTP, ni HTTPS, la connexion échoue.

    Si les données sous-jacentes sont au format 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'option d'inspection TLS est activée.
    • 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 doit avoir une priorité plus élevée que les règles qui autorisent le trafic HTTP.
  • Les règles comportant l'attribut ApplicationMatcher doivent avoir un champ d'application restreint à l'aide de l'attribut SessionMatcher afin de minimiser l'interprétation des flux non liés 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é plus faible que les règles d'inspection non TLS. Sinon, pour échouer rapidement pour le trafic qui ne correspond pas, vous devez également définir un champ d'application restreint pour les règles d'inspection TLS à l'aide de l'attribut SessionMatcher.

Exemples de configurations de règles d'inspection TLS

Examinez les deux règles des exemples suivants.

Exemple 1

Dans cet exemple, nous partons du principe qu'il existe d'autres règles de priorité inférieure. Considérez 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 interdire un type spécifique de requête HTTP, s'exclut mutuellement, car le trafic TCP peut contenir une requête POST.
  • Le trafic dans la règle 2 n'est jamais autorisé. Elle est refusée, car le trafic de la balise 12345 vers example.com est intercepté et interprété comme HTTP afin d'évaluer la méthode HTTP.

  • Pour que la règle 2 s'applique, vous pouvez utiliser l'une des solutions suivantes:

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

    • Appliquez la règle de champ d'application 1 pour éviter le chevauchement du trafic autorisé avec 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

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, 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 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 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 inspection TLS.

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

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

Limites

Vous devez tenir compte des limites suivantes 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 de Mozilla. Le comportement de la vérification des certificats est susceptible d'être modifié et correspond à la façon dont les navigateurs Web vérifient les certificats.

    La vérification du backend n'étant pas possible 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érification des listes de révocation de certificats (LRC).

  • Pour que l'inspection TLS fonctionne, les clients doivent actuellement envoyer l'indication du nom du serveur (SNI). 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 le service ECH (Encrypted Client Hello) (anciennement SNI chiffré).

    ECH est un brouillon de norme IETF qui permet aux clients de chiffrer le début du handshake TLS à l'aide d'une clé de serveur préétablie. Étant donné que l'inspection TLS agit en tant que proxy d'interception, il 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é, vous recevez des certificats mis en cache signés par cette autorité de certification pendant 28 heures maximum. Pour empêcher l'utilisation des 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 obligé de générer de nouveaux certificats.