Trouver et nettoyer les règles Zscaler inutilisées (règles obsolètes)

Les ensembles de règles grandissent au fil des années, mais ils rétrécissent rarement. Comment rendre visibles les règles orphelines, conflictuelles et masquées de votre environnement Zscaler et les nettoyer de façon contrôlée, sans abandonner le contrôle de l'ensemble de règles.

Chaque environnement Zscaler raconte une histoire. Une exception pour un projet terminé depuis longtemps. Une autorisation pour un site qui a été migré. Une règle de test jamais retirée. Prise isolément, chacune de ces règles est compréhensible. Mais additionnées sur des mois et des années, elles forment un ensemble de règles que presque plus personne ne maîtrise entièrement. Ce n'est pas une faiblesse de Zscaler, mais une propriété de tout ensemble de règles vivant : il grandit à chaque changement, mais ne se nettoie pas de lui-même.

C'est exactement là qu'intervient l'hygiène des règles. Quiconque veut trouver et nettoyer les règles Zscaler inutilisées a besoin de deux choses : une visibilité fiable sur l'état réel de l'ensemble de règles et un processus qui garde les modifications contrôlées et auditables. Les deux peuvent être clairement séparés, et c'est précisément cette séparation qui rend le nettoyage sûr.

Pourquoi les ensembles de règles partent à l'abandon

Des règles sont ajoutées lorsqu'un besoin urgent se présente : un utilisateur a besoin d'un accès, une application doit être joignable, un incident exige une réaction rapide. Le cas inverse ne se produit presque jamais. Personne ne reçoit de ticket intitulé « Merci de supprimer cette règle, elle n'est plus nécessaire ». Supprimer des règles paraît risqué, car on ne sait pas clairement qui ou quoi en dépend encore. Elles restent donc en place. Ce déséquilibre entre ajout et suppression est le véritable moteur de cet abandon progressif.

En pratique, trois catégories de règles problématiques s'accumulent :

• Règles orphelines (obsolètes) : des règles qui ne génèrent plus aucun trafic depuis longtemps, parce que l'application, le site ou le groupe d'utilisateurs associé n'existe plus.
• Règles conflictuelles : des règles qui se contredisent, par exemple une autorisation et un blocage pour la même combinaison source-destination. Celle qui l'emporte dépend uniquement de l'ordre, ce qui devient difficile à suivre.
• Règles masquées (shadowed) : des règles qui ne sont jamais évaluées parce qu'une règle plus large, placée au-dessus, intercepte déjà le trafic. Elles suggèrent un contrôle qui, en réalité, ne s'applique jamais.

Ce que coûtent réellement les ensembles de règles à l'abandon

Un ensemble de règles surchargé est plus qu'un problème esthétique. Il a des effets concrets sur la sécurité, l'exploitation et la conformité.

Surface d'attaque. Chaque autorisation ouverte qui ne remplit plus aucun objectif est une voie potentielle qui reste ouverte alors qu'elle devrait être fermée. Les exceptions orphelines sont particulièrement traîtres, car elles ont un jour été définies délibérément et sont donc facilement validées comme « voulues » lors des revues.

Mauvaise configuration. Les règles conflictuelles et masquées font que le comportement réel de l'ensemble de règles s'écarte de ce qui était attendu. Un administrateur ajoute un blocage qui ne s'applique jamais parce qu'une autorisation plus ancienne le masque. Ces écarts silencieux sont à l'origine de nombreux incidents difficiles à diagnostiquer.

Traçabilité et audit. Lors de contrôles relevant de NIS2 ou de DORA, il doit être possible de prouver pourquoi une règle existe et qui en est responsable. Un ensemble de règles chargé d'un passif complique cette preuve et allonge chaque audit.

Exploitation et vue d'ensemble. Plus l'ensemble de règles est volumineux, plus chaque modification devient difficile. Les nouveaux collaborateurs mettent plus de temps à le comprendre, et chaque ajustement comporte le risque de toucher involontairement l'un de ces éléments hérités.

La visibilité d'abord : Policy Hygiene Desk et Policy Conflict Review

CentaurNexus est une console unique souveraine pour Zscaler, dont l'exploitation en production pour les clients européens se fait entièrement sur STACKIT dans l'UE et qui s'appuie sur l'OneAPI officielle de Zscaler. Pour l'hygiène des règles, il apporte deux fonctions complémentaires.

Le Policy Hygiene Desk analyse l'ensemble de règles à la recherche de règles orphelines et masquées. Il montre quelles règles ne s'appliquent plus sur la période observée et lesquelles ne sont en fait jamais évaluées à cause de règles plus larges situées au-dessus. Il en résulte une liste de candidats fiable pour un ensemble de règles allégé, sans qu'un collaborateur doive passer manuellement en revue l'ensemble complet.

Le Policy Conflict Review met au jour les contradictions : des paires de règles qui s'annulent ou se chevauchent, et les endroits où l'ordre détermine le comportement réel. Au lieu d'une longue liste plate, l'équipe obtient une vue priorisée des endroits où l'ensemble de règles ne fait pas ce qu'il semble prescrire.

Les deux fonctions travaillent en lecture seule. Elles lisent la configuration, l'évaluent et présentent des constats. La vidéo montre le Policy Conflict Review en action : comment deux règles qui se contredisent sont mises en regard et comment une nouvelle règle prévue est simulée au préalable. Elles ne modifient rien. Cette séparation stricte entre analyse et intervention est un choix délibéré et constitue le cœur de la démarche sûre.

Du constat à la mise en œuvre traçable

CentaurNexus relie le parc de règles analysé à l'utilisation, aux conflits et aux dépendances. On voit ainsi quel objectif remplit chaque modification et quels périmètres sont concernés.

Chaque nettoyage se déroule comme une étape clairement délimitée :

Les modifications individuelles validées restent traçables à tout moment et peuvent, en cas de doute, être annulées de façon ciblée.

Un rythme de nettoyage adapté à la pratique

L'hygiène des règles n'est pas un grand projet ponctuel, mais une routine récurrente. En pratique, un rythme simple fait ses preuves :

• Analyser régulièrement. Faire tourner Policy Hygiene Desk et Policy Conflict Review à intervalle fixe et traiter les constats comme une liste de candidats, pas comme un ordre de travail.
• Prioriser selon l'impact. Traiter d'abord les constats qui concernent la plus grande surface d'attaque ou les contradictions les plus claires.
• Décider au cas par cas. Évaluer chaque candidat dans son contexte. Certaines règles apparemment orphelines sont en réalité une autorisation d'urgence délibérée et restent en place.
• Valider et documenter. Faire passer chaque modification par la validation selon la politique du tenant et consigner le motif. Le journal sert alors de base à la revue suivante.

Au fil de plusieurs cycles, cela produit un ensemble de règles plus léger et plus compréhensible, sans qu'à aucun moment le contrôle n'ait été cédé. L'ampleur de l'allégement possible dépend entièrement de l'historique de l'ensemble de règles. Un exemple pour illustrer : si l'analyse trouve, dans un ensemble ayant grandi au fil du temps, un nombre à deux chiffres d'exceptions orphelines, ce sont autant de candidats que vous pouvez examiner de façon contrôlée et éventuellement supprimer. Les pourcentages concrets dépendent toujours du cas particulier.

Souverain, sans diffuser largement des droits d'administration

Pour analyser des règles, tous les collaborateurs n'ont pas besoin d'un accès administrateur complet à Zscaler. CentaurNexus lit la configuration via l'OneAPI officielle et présente les constats de façon basée sur les rôles. Le helpdesk et l'exploitation reçoivent le périmètre autorisé pour leur tâche. Pour les clients européens, l'exploitation en production se fait entièrement sur STACKIT dans l'UE ; d'autres trajets de protection des données sont documentés dans la déclaration de confidentialité.

Bien interpréter l'historique d'utilisation

Une règle sans trafic observé n'est pas automatiquement superflue. La portée du constat dépend de la période observée, de la couverture des flux et de l'objectif métier. Les données de pare-feu NSS peuvent montrer l'activité d'une règle dans l'historique disponible. Les processus saisonniers, les accès d'urgence ou les fenêtres de maintenance rares nécessitent une connaissance opérationnelle.

CentaurNexus présente donc le constat comme une indication à vérifier. Un administrateur évalue les dépendances et choisit la modification individuelle précise. Après une mise en œuvre, l'effet sur le système cible et le read-back confirment le nouvel état. Le nettoyage reste ainsi contrôlé, sans déduire automatiquement une décision de suppression d'une simple absence d'activité.