La logique ACL classique des ADC et pare-feux a longtemps été construite sur l'IP, le sous-réseau, le port et le protocole. Ce modèle est suffisant pour un contrôle d'accès réseau simple, mais le trafic web, API, bot et WAAP moderne n'est pas aussi simple.
Aujourd'hui, se demander uniquement « quelle est l'IP source ? » ne suffit plus. De quel pays vient la requête ? De quel ASN ? Vers quel chemin va-t-elle ? Quel cookie est présent ? Quel rôle est écrit dans le JWT ? L'ensemble de headers ressemble-t-il à un vrai navigateur ? L'empreinte TLS est-elle suspecte ? Combien de points de score WAAP cette requête a-t-elle reçus ? Comment le moteur bot a-t-il classifié cet utilisateur ?
Dans la plupart des produits, ces signaux vivent à des endroits séparés. La règle de routage est à un endroit, le score WAAP à un autre, la décision bot ailleurs, la réécriture de headers ailleurs encore, et la limitation de débit encore ailleurs. Cela complique les opérations et produit des décisions incohérentes.
Le plus grand problème est que les conditions complexes nécessitent généralement du code. Écrire une règle telle que « si ce header est présent, ce cookie est absent, le chemin commence par /api/, le score WAAP est supérieur à 5, mais la source n'est pas un bot connu » nécessite des scripts, des langages de politique propriétaires ou une programmation spécifique au fournisseur dans la plupart des produits.
La couche Smart ACL Conditions de TR7 ADC résout ce problème : les décisions de trafic sont définies depuis l'interface en utilisant plus de 60 critères, des chaînes de Smart Functions et des groupes AND/OR/NOT. La règle n'est plus seulement une liste IP mais une structure de décision qui lit le sens du trafic.
TR7 traite les conditions ACL comme l'unité fondamentale des décisions applicatives et de sécurité — pas un filtre d'adresses réseau.
Le moteur Smart ACL va bien au-delà de l'IP et du port. L'IP source, le pays, la ville, l'IP destination, le port destination, la méthode HTTP, l'URL, le chemin, la requête, le header, le cookie, le corps de requête, le corps de réponse, le SNI TLS, le cipher TLS, le protocole TLS, l'empreinte JA3, l'ID d'attaque WAAP, le groupe d'attaque WAAP, la classe bot, la catégorie de liste noire et l'état du cache peuvent tous être utilisés comme conditions. Cela permet de prendre des décisions de sécurité et de routage dans un contexte applicatif complet.
Une ACL peut être utilisée seule ou combinée avec d'autres ACL dans des groupes logiques. Un groupe interne fonctionne avec AND ou OR ; une condition peut être inversée pour donner un comportement NOT. Par exemple : « Le chemin commence par /login » ET « Le pays source n'est pas dans la liste d'autorisation » ET « Le score bot est élevé » MAIS « Ce n'est pas un bot connu » — cette structure rend les politiques de sécurité complexes lisibles.
Les Smart Functions de TR7 transforment les valeurs de trafic brutes en entrées exploitables. Les opérations de décodage Base64, de requête JSON path, d'analyse JWT header/payload, de requête XML, de correspondance regex, de remplacement de chaîne, de mise en minuscules/majuscules, de digest, de masque IP, d'IP vers pays et de recherche map/liste peuvent toutes être chaînées. L'ACL ne demande plus seulement « cette valeur de header correspond-elle ? » ; elle analyse le JSON à l'intérieur du header, extrait un JWT claim ou interroge un champ à l'intérieur du corps.
Les conditions fréquemment utilisées sont définies une fois et réutilisées dans différentes règles. Les ACL intégrées ou personnalisées telles que « est-ce une extension de fichier statique ? », « un cookie d'auth est-il présent ? », « est-ce un cache hit ? » ou « a-t-il été bloqué par le WAAP ? » peuvent être partagées entre de nombreuses règles. Ce pattern réduit la duplication des règles, centralise les changements et diminue le risque d'erreur opérationnelle.
Les Conditions ACL Intelligentes transforment les signaux de trafic en conditions lisibles et actions applicables sur plus de 60 critères.
TR7 peut écrire des conditions sur le chemin, chemin+requête, URL complète et méthode HTTP. Les types de correspondance peuvent être préfixe, suffixe, sous-chaîne ou regex. Les requêtes commençant par /api/, le chemin /admin, la méthode POST ou des patterns d'URL spécifiques contenant une query string sont tous exprimés dans une seule définition ACL.
Les headers de requête, les headers de réponse, les cookies utilisateur et les cookies provenant du backend peuvent tous être utilisés à l'intérieur d'une ACL. La sélection de route basée sur le header X-Tenant-ID, la redirection vers la connexion lorsque le cookie session_id est absent, la vérification bot basée sur le contenu User-Agent et le comportement de sécurité personnalisé basé sur un cookie de réponse sont tous écrits à cette couche.
Les critères ACL ne se limitent pas à l'IP source ou au CIDR. Des conditions basées sur le pays, la ville et l'ASN peuvent également être définies. Restreindre l'accès à des pays spécifiques, un routage personnalisé pour les utilisateurs de villes spécifiques, une vérification supplémentaire pour le trafic d'ASN spécifiques ou une politique bot plus agressive pour les ASN de datacenters sont tous pris en charge.
Les signaux TLS SNI, cipher TLS, protocole TLS, présence SNI et empreinte JA3 peuvent être inclus dans les conditions. Attribuer un score de confiance plus bas aux clients utilisant TLS 1.0, rejeter les connexions sans SNI, envoyer le trafic correspondant à une liste d'empreintes JA3 connues malveillantes vers CAPTCHA, ou placer les clients utilisant des ciphers faibles en mode surveillance sont tous exprimables.
L'ACL peut opérer sur du contenu échantillonné du corps de requête ou de réponse. La correspondance de chaîne ou regex à l'intérieur du corps est prise en charge. La vérification de transactions à valeur élevée à l'intérieur d'un corps JSON, la capture d'un pattern spécifique dans un champ de formulaire, l'ajout d'un header lorsqu'un marqueur spécifique est présent dans le corps de réponse ou l'application d'une limitation de débit basée sur le contenu du payload API sont tous possibles.
Avec les Smart Functions, le contenu JSON, XML et JWT peut être transformé en conditions ACL. JWT payload.role == "admin", transaction.amount > 10000 dans un corps JSON, vérifier si un chemin spécifique existe en XML ou vérifier l'algorithme dans un header JWT sont des conditions qui offrent une flexibilité significative pour la sécurité API et la politique d'accès.
Le moteur Smart ACL peut également utiliser les décisions WAAP comme conditions : ID d'attaque WAAP, groupe d'attaque WAAP, score WAAP, si le WAAP a bloqué la requête, si elle a été signalée comme attaque WAAP. Afficher CAPTCHA lorsque le score WAAP est ≥ 5, router les requêtes du groupe SQL injection vers un format de log spécial ou envoyer les résultats WAAP en mode surveillance vers un backend séparé sont des scénarios types.
Les classifications navigateur, mobile, bot et agent utilisateur peuvent être utilisées dans une ACL. Envoyer les utilisateurs mobiles vers un backend mobile, appliquer une limite de débit plus faible au trafic signalé comme bot, accorder des exceptions aux moteurs de recherche connus et appliquer un profil de sécurité différent aux clients non-navigateur peuvent tous être définis.
Le moteur ACL peut utiliser des signaux de volume de trafic et de taille : taille de requête, taille de réponse, nombre de connexions frontend, débit de requêtes, débit de sessions, temps de réponse, nombre de serveurs backend actifs et code de statut HTTP. Déplacer le nouveau trafic vers un pool de secours lorsque le nombre de backends actifs tombe à 1, ou mettre en cache un endpoint spécifique lorsque le temps de réponse augmente, sont exprimables via ces critères.
La correspondance basée sur les maps et listes est prise en charge. Elle est utilisée pour les grandes listes IP, les listes de domaines, les listes d'URL, les listes d'ID clients ou les tables clé-valeur personnalisées. Un routage différent basé sur une liste de clients VIP, le blocage d'IP sur une liste de blocage ou l'application d'une politique CORS basée sur une liste de domaines partenaires sont tous gérés avec ce pattern.
La réputation IP ou les catégories de liste noire peuvent être incluses dans les conditions. Les catégories botnet, proxy, Tor, malware ou spam peuvent être liées à des comportements différents. Servir CAPTCHA à une IP de catégorie proxy ouvert, placer les nœuds de sortie Tor en mode surveillance ou rejeter directement les IP de la catégorie malware sont des utilisations types.
TR7 fournit plusieurs ACL courantes prêtes à l'emploi : est-ce une extension de fichier statique, un cookie d'auth est-il présent, est-ce un cache hit, a-t-il été bloqué par le WAAP. Ces ACL intégrées évitent aux opérateurs de réécrire leurs conditions les plus fréquemment nécessaires et gardent les jeux de règles plus concis.
Dans les cas limites où les critères d'interface standard sont insuffisants, un utilisateur expert peut écrire une condition manuelle. Cela préserve le moteur de règles visuel de TR7 tout en offrant une flexibilité de trappe d'échappement. Ce mode n'est pas pour un usage quotidien — il est destiné aux opérations avancées et aux intégrations personnalisées.
Les valeurs de débit de requêtes, de débit de connexions et de taux d'erreurs par utilisateur peuvent être utilisées dans une ACL. Lorsqu'elles sont combinées avec un JWT claim, un cookie, un header ou un ID utilisateur, des politiques de limitation de débit au niveau du tenant ou de l'utilisateur peuvent être construites.
Des comportements différents peuvent être déclenchés selon qu'une requête ou une réponse est un cache hit. La présence d'un cookie d'auth ou les valeurs d'auth HTTP peuvent également être utilisées dans le moteur ACL. Cela unifie les comportements AAM et ADC sous la même logique de règles.
Les Conditions ACL Intelligentes ne se résument pas à la syntaxe des règles — elles couvrent la structure des groupes de conditions, les types de correspondance, le modèle de mise à jour et les limites d'échantillonnage du corps.
Les conditions Smart ACL sont définies en groupes. Les conditions au sein d'un groupe sont combinées avec AND ou OR. Une condition peut être inversée pour donner un comportement NOT. Les groupes externes forment une structure logique plus large. Cette approche décompose les politiques complexes en petites pièces lisibles.
Chaque ACL est identifiée par un ID unique. Les règles référencent cet ID. La même ACL peut être réutilisée dans différentes règles de trafic, politiques de limitation de débit, règles de redirection ou actions de sécurité. Lorsque l'ACL change, la mise à jour se propage automatiquement à toutes les règles liées.
Différents types de correspondance sont pris en charge pour les conditions textuelles : correspondance par préfixe, correspondance par suffixe, correspondance par sous-chaîne, correspondance regex, et correspondance sensible ou insensible à la casse. Cette flexibilité couvre à la fois les structures de règles simples et complexes.
Les Smart Functions peuvent être utilisées individuellement ou chaînées. Par exemple : analyser le payload JWT, extraire le champ de rôle, convertir en minuscules, comparer avec une liste spécifique. Cela transforme les données de trafic brutes en entrées de décision significatives.
L'inspection du corps de requête et de réponse opère sur une taille de contenu échantillonnée. Cela fournit un modèle équilibré entre performance et conscience du contenu. Pour les corps très volumineux, des capacités dédiées de modification ou de masquage du corps sont utilisées séparément.
Les conditions Smart ACL peuvent être utilisées à différentes couches. Les règles côté L7 peuvent nécessiter un soft-reload lors d'un changement de configuration. Les règles côté pare-feu L3 sont appliquées via leur propre cycle de synchronisation. Tous les changements ne sont pas appliqués via le même mécanisme — un modèle de mise à jour par couche s'applique.
Les extensions courantes pour la détection de contenu statique sont fournies par défaut : .css, .js, .jpg, .png, .svg, .woff, .pdf, .mp4, .webp, .docx, .xlsx et types de fichiers similaires. Cela est fréquemment utilisé dans les scénarios de cache, de réduction des journaux et d'exception de limitation de débit.
Certaines Smart Functions fonctionnent directement avec le moteur de trafic intégré ; certaines fonctions spécialisées s'exécutent via une couche de convertisseur supplémentaire. Cela donne aux opérations JSON, XML, JWT et de chaînes personnalisées une surface d'expression plus large.
Dans une couche API, les utilisateurs admin reçoivent une limite plus élevée et les utilisateurs normaux une limite plus faible. Smart ACL lit le champ de rôle depuis le payload JWT et sélectionne la politique de limitation de débit en conséquence. JWTPAYLOAD(role) == admin → limite de débit élevée ; sinon → limite de débit standard.
Une requête est signalée comme suspecte par le WAAP mais pas suffisamment clairement pour être bloquée directement. Smart ACL évalue le score WAAP et la classe bot ensemble. Lorsque wafScore >= 5 ET NON knownBot, CAPTCHA est présenté.
Les utilisateurs mobiles sont routés vers un backend et les utilisateurs desktop vers un autre. Smart ACL utilise l'agent utilisateur et le signal de classification mobile. mobile == true → backend mobile ; mobile == false → backend desktop.
Une map personnalisée d'empreintes de clients malveillants connus est définie comme ACL. Lorsque l'empreinte TLS entrante correspond à cette liste, le trafic est bloqué ou envoyé vers CAPTCHA. ja3 in bad_fingerprint_list → deny / captcha.
Dans une API financière, le montant du virement est lu depuis l'intérieur du corps JSON. Lorsque le montant dépasse un seuil défini, un MFA supplémentaire est déclenché côté AAM ou la transaction est routée vers un backend séparé. JSONQUERY(transaction.amount) > 10000 → MFA progressif.
Le trafic de certains pays est normalement autorisé, mais lorsque ce même trafic arrive d'un ASN d'hébergement et que le score WAAP est élevé, un challenge supplémentaire est appliqué. country in allowedCountries AND asn in hostingProviders AND wafScore >= 4 → challenge.
Sécurité, routage et limitation de débit dans un seul moteur de règles — sur plus de 60 critères, des chaînes de Smart Functions et des groupes AND/OR/NOT. Laissez-nous parcourir une mise en place en direct dans votre propre environnement.