Que sont les Shadowed Rules ?
Les Shadowed Rules (règles masquées) sont des règles qui ne s'appliquent jamais, parce qu'une règle évaluée plus tôt couvre entièrement leur champ d'application. Les pare-feu et les passerelles web traitent les bases de règles dans un ordre fixe : la première règle correspondante l'emporte. Si une règle large, plus haut, couvre tous les cas d'une règle plus spécifique plus bas, cette dernière est de fait sans effet, bien qu'elle paraisse correcte dans la base de règles. Le cas d'actions différentes est particulièrement critique : si une règle d'autorisation masque une règle de blocage, une mesure de protection voulue est hors service sans que personne ne le remarque. Les Shadowed Rules sont ainsi un cas particulier du conflit de policy.
Les Shadowed Rules en détail
L'analyse distingue le shadowing complet et le shadowing partiel. Dans le shadowing complet, la règle antérieure couvre tous les cas de la règle ultérieure ; celle-ci ne s'applique jamais. Dans le shadowing partiel, les champs d'application ne se recoupent qu'en partie ; la règle ultérieure s'applique alors plus rarement ou autrement que prévu. Apparentée mais plus anodine est la redondance : deux règles avec la même action se recoupent, le comportement reste correct, seule la base de règles devient inutilement grande.
Les Shadowed Rules naissent presque toujours de la routine de travail : de nouvelles règles sont ajoutées à la fin sans vérifier l'ordre d'évaluation, ou une autorisation large pensée comme solution transitoire reste tout en haut de la base de règles. Dans l'exploitation Zscaler, cela concerne toutes les politiques évaluées dans un ordre donné, par exemple les règles URL Filtering et Cloud Firewall dans ZIA, ainsi que les politiques d'accès dans ZPA. Plus les administrateurs travaillent en parallèle, plus les règles risquent de se masquer sans que personne ne le remarque.
Pourquoi les Shadowed Rules comptent-elles dans l'exploitation Zscaler ?
Ce qui rend les Shadowed Rules insidieuses, c'est leur invisibilité au quotidien. La manière de confronter directement deux règles qui se recouvrent est présentée dans notre vidéo d'environ deux minutes consacrée à Policy Conflict Review. La base de règles paraît complète, la documentation semble correcte, mais le comportement réel diffère. Pour le helpdesk, cela crée des tickets difficiles à expliquer : un blocage ne s'applique pas alors que la règle existe, ou un accès échoue alors qu'il a été autorisé. Sans analyse systématique, le diagnostic se termine par une comparaison manuelle de bases de règles comptant parfois des centaines d'entrées.
Pour la sécurité et la preuve, le cas des actions différentes pèse le plus lourd : une règle de blocage masquée signifie qu'une mesure de protection décidée ne produit aucun effet. Quiconque doit démontrer, au titre de NIS2 ou de DORA, l'application cohérente des politiques a donc besoin d'une revue qui détecte le shadowing de façon systématique et documente sa résolution. La correction doit rester entre des mains humaines : décidée, validée et consignée individuellement.
Sources d'erreur courantes
- Ajouter de nouvelles règles à la fin sans vérification : sans regard sur l'ordre d'évaluation, le shadowing apparaît dès l'entrée suivante.
- Ne vérifier que des règles isolées : le shadowing n'apparaît que dans une comparaison par paires des champs d'application, pas sur une règle prise seule.
- Supprimer systématiquement les règles masquées : souvent, c'est la règle masquée qui est correcte sur le fond ; il faut alors résoudre le conflit, pas faire disparaître la règle.
- Réorganisation massive comme raccourci : modifier l'ordre en bloc change le comportement de toute la base de règles et crée de nouveaux conflits.
Les Shadowed Rules en pratique : ce qu'apporte CentaurNexus
Policy Conflict Review de CentaurNexus analyse la base de règles Zscaler en lecture seule via l'OneAPI officielle et signale les constats de shadowing avec les deux règles concernées et leur emplacement. Il n'existe volontairement aucun bouton qui réorganiserait automatiquement la base de règles : chaque résolution reste une modification individuelle décidée par une personne, validée en option selon le principe des quatre yeux, puis consignée dans l'audit trail tenu en mode ajout seul. Il reste ainsi possible de prouver à tout moment quels constats ont été détectés, tranchés et corrigés. L'article suivant montre comment nettoyer de façon maîtrisée les règles masquées : Nettoyer les règles Zscaler inutilisées.
Termes associés
Questions fréquentes sur les Shadowed Rules
Le plus souvent par routine : de nouvelles règles sont ajoutées à la fin de la base de règles sans vérifier si une règle antérieure, plus large, couvre déjà le même cas. Des autorisations groupées, insérées tout en haut comme solution transitoire, masquent elles aussi des règles spécifiques ultérieures. Chaque changement effectué par plusieurs intervenants augmente la probabilité d'occultations passant inaperçues.
Par une comparaison par paires de toutes les règles : le champ d'application d'une règle évaluée plus tôt couvre-t-il, entièrement ou en partie, une règle ultérieure ? En manuel, cela devient quasiment infaisable au-delà de quelques dizaines de règles. Une analyse outillée et en lecture seule via l'API Zscaler, qui nomme les deux règles concernées avec leur emplacement et documente les constats, est la voie praticable.
Potentiellement, oui. Si une règle d'autorisation masque une règle de blocage, une mesure de protection décidée est de fait désactivée, sans que la base de règles ne le montre. À l'inverse, des autorisations voulues restent sans effet et génèrent des cas de support. Même des cas d'apparence anodine donnent l'illusion d'un état des règles qui n'existe pas réellement, ce qui affaiblit toute démonstration de conformité.
Dans la redondance, des règles avec la même action se recoupent : le comportement reste correct, la base de règles est seulement inutilement grande. Dans le shadowing, une règle ne s'applique plus du tout ; si les deux règles prévoient des actions différentes, le comportement réel s'écarte du comportement documenté. Le shadowing est donc le constat nettement plus critique.
Ce n'est pas recommandé. L'ordre fait partie de la logique des règles : réorganiser automatiquement change le comportement de toute la base de règles et risque de créer de nouveaux conflits. Une détection en lecture seule associée à des corrections individuelles vérifiées par une personne, avec validation selon le principe des quatre yeux et audit trail, a fait ses preuves. Chaque changement reste ainsi traçable et réversible.
- NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy - csrc.nist.gov
- Portail d'aide Zscaler : documentation officielle sur les règles ZIA (URL Filtering, Cloud Firewall) - help.zscaler.com
- BSI IT-Grundschutz, module NET.3.2 Firewall (exigences relatives à la maintenance de la base de règles) - bsi.bund.de/.../NET_3_2_Firewall
Remarque : CentaurNexus est un produit indépendant de SourcingBlox GmbH et non une offre de Zscaler, Inc. Les noms de produits et de marques appartiennent à leurs détenteurs respectifs.