Que sont les Stale Rules ?

Les Stale Rules en détail

Dans la pratique, on distingue plusieurs types. Les règles inutilisées n'obtiennent plus aucun résultat sur une période d'observation prolongée, par exemple parce que l'application ciblée n'existe plus. Les règles orphelines pointent vers des objets qui n'existent plus : groupes supprimés, sites désactivés, serveurs retirés. Les exceptions expirées étaient pensées comme solution transitoire, mais n'ont jamais été retirées. Toutes ont un point commun : elles ne modifient presque plus le comportement de la base de règles, mais elles mobilisent de l'attention à chaque évaluation, chaque revue et chaque diagnostic.

Dans l'exploitation Zscaler, cela concerne surtout les règles URL Filtering et Cloud Firewall dans ZIA, ainsi que les politiques d'accès et les App Segments dans ZPA. Savoir si une règle est vraiment inutilisée ne peut s'évaluer qu'avec des données d'usage sur une période suffisamment longue : une règle liée à la clôture trimestrielle n'obtient des résultats que quatre fois par an. C'est précisément pour cela qu'une analyse solide et en lecture seule doit précéder tout nettoyage.

Pourquoi les Stale Rules comptent-elles dans l'exploitation Zscaler ?

Plus la base de règles est grande, plus chaque changement coûte cher. La manière dont les règles inutilisées entrent, comme un élément parmi d'autres, dans un score de santé unique, est présentée dans notre vidéo consacrée au score de configuration. Quiconque ajoute une nouvelle règle doit comprendre quelles règles existantes s'appliquent avant elle ; chaque Stale Rule rend cette vérification plus longue et plus sujette aux erreurs. Pour le helpdesk, une base de règles laissée à l'abandon signifie des délais de traitement de tickets plus longs, car chaque cas de blocage a davantage de candidats possibles. Et côté sécurité : des autorisations oubliées issues d'anciens projets maintiennent ouverts des accès que plus personne ne surveille.

S'ajoute à cela la question de la preuve. Quiconque doit démontrer, au titre de NIS2 ou de DORA, que les politiques d'accès et de filtrage suivent le principe du moindre privilège peut difficilement justifier des règles sans finalité identifiable. Un processus de nettoyage documenté, avec une justification par règle, constitue donc aussi un argument d'audit. L'ordre compte : d'abord étayer le constat par des données, puis mettre en œuvre chaque suppression ou désactivation comme un changement individuel et validé, jamais comme une action groupée générale.

Sources d'erreur courantes

• Supprimer sans preuve : une règle sans résultat le mois dernier peut couvrir un processus trimestriel ou annuel ; la période d'observation doit être assez longue.
• Nettoyage groupé en une fois : retirer des dizaines de règles d'un coup rend les erreurs difficiles à identifier ; mieux vaut modifier et valider une par une.
• Supprimer directement au lieu de désactiver d'abord : une phase de désactivation avec observation est l'étape intermédiaire sûre.
• Confondre stale et shadowed : une règle sans résultat peut aussi être masquée par une règle antérieure ; la cause est alors différente.

Les Stale Rules en pratique : ce qu'apporte CentaurNexus

Policy Hygiene Desk de CentaurNexus analyse la base de règles Zscaler en lecture seule via l'OneAPI officielle, et rend visibles les règles inutilisées, orphelines et en conflit, avec leur emplacement exact. Il n'existe volontairement aucun automatisme qui remodèle la base de règles : chaque constat reste une proposition, et chaque nettoyage se fait comme un changement individuel et traçable, validé en option selon le principe des quatre yeux, puis consigné dans l'audit trail tenu en mode ajout seul. Un passif diffus devient ainsi un processus documenté, que l'on peut traiter étape par étape. La manière dont se déroule une telle revue des règles, étape par étape, est présentée dans le guide Trouver et nettoyer les règles Zscaler inutilisées.

Termes associés