Qu'est-ce qu'une règle Any-Any ?
Une règle Any-Any est une règle de pare-feu ou d'accès qui couvre à la fois toutes les sources et toutes les destinations, souvent aussi tous les services. C'est donc la forme la plus large d'une règle dans l'ensemble de règles. Son effet dépend de l'action : en règle d'autorisation, elle ouvre énormément d'un coup ; en règle de blocage finale, elle constitue une posture de base sensée, dans l'esprit du Default Deny. Ce sont surtout les autorisations larges qui sont risquées, car elles contournent le principe du moindre privilège, élargissent la surface d'attaque et brouillent les analyses. Les règles Any-Any naissent le plus souvent comme solution transitoire, puis restent involontairement dans l'ensemble de règles.
Règle Any-Any en détail
Le terme vient du monde classique des pare-feux et décrit une règle dont les conditions sont volontairement laissées ouvertes : source quelconque, destination quelconque, souvent aussi service quelconque. Dans un ensemble de règles Zscaler, par exemple dans le Cloud Firewall de ZIA, une telle règle est vite posée et agit immédiatement sur énormément de trafic. Ce qui compte, c'est ce que fait la règle : une autorisation large ouvre en bloc, un blocage large en fin d'ensemble de règles capte tout ce qu'aucune règle plus spécifique n'a intercepté.
La règle Any-Any n'est donc pas mauvaise en soi, tout dépend du contexte. Elle devient problématique lorsqu'une autorisation large reste en place durablement et que plus personne ne sait à quoi elle servait. La position compte aussi : une règle large tout en haut peut rendre inopérantes les règles plus spécifiques placées en dessous, car l'ensemble de règles fonctionne selon le principe du premier résultat trouvé.
Pourquoi les règles Any-Any comptent-elles dans l'exploitation Zscaler ?
Les autorisations larges sont l'adversaire du Zero Trust. La façon dont les accès any-to-any entrent comme indicateur propre dans le score global, notre vidéo sur le score de configuration le montre. Qui veut lier étroitement l'accès aux rôles et aux besoins peut difficilement justifier une autorisation Any-Any générale. Pour la sécurité, cela signifie : plus de voies ouvertes que quiconque n'en surveille activement. Pour l'exploitation, cela signifie : chaque recherche d'erreur prend plus de temps, car une règle large influence beaucoup de cas à la fois et peut se superposer à d'autres règles.
Côté preuves, les règles Any-Any sont un point de contrôle classique. Qui doit démontrer, au titre de NIS2 ou de DORA, que les policies d'accès et de filtrage suivent le principe du moindre privilège doit expliquer ou démanteler les autorisations larges. L'ordre de la démarche compte ici : d'abord rendre visibles et évaluer toutes les règles Any-Any, puis resserrer chaque autorisation risquée par une modification individuelle, justifiée et validée, plutôt que par une action groupée.
Sources d'erreur courantes
- Autorisation large comme solution provisoire : une règle prévue pour la migration reste en place et ouvre durablement plus que nécessaire.
- Mauvaise position : une règle large placée tout en haut masque des règles plus spécifiques, qui ne s'appliquent alors jamais.
- Suppression précipitée : qui retire une autorisation large sans vérifier les dépendances risque une panne.
- Confusion entre blocage par défaut et règle à risque : un blocage Any-Any final est voulu, une autorisation large ne l'est pas.
Règles Any-Any en pratique : ce qu'apporte CentaurNexus
La Policy Rule Map de CentaurNexus représente graphiquement l'ensemble de règles ZIA et met visiblement en évidence les règles Any-Any, pour que les règles larges ne se perdent pas dans de longues listes. L'analyse est purement en lecture et ne modifie rien : chaque constat reste une proposition, et chaque ajustement se fait comme une modification individuelle et traçable, validée en option selon le principe des quatre yeux et journalisée dans l'audit trail tenu en append-only. Une collection diffuse de règles larges devient ainsi une démarche traitable et justifiée. Comment se déroule pas à pas une telle revue de règles, le guide suivant le montre : Trouver et nettoyer les règles Zscaler inutilisées.
Termes associés
Questions fréquentes sur la règle Any-Any
Une règle Any-Any couvre toutes les sources et toutes les destinations à la fois, souvent aussi tous les services. C'est donc la forme la plus large d'une règle de pare-feu ou d'accès. Son effet dépend de l'action : en règle d'autorisation, elle ouvre énormément ; en règle de blocage finale, elle constitue une posture de base sensée.
Cela dépend de l'action et de la position. Une règle d'autorisation large élargit la surface d'attaque et brouille les analyses. Un blocage Any-Any en fin d'ensemble de règles est en revanche la sécurisation Default Deny classique. Ce sont surtout les autorisations larges que plus personne ne peut justifier qui posent problème.
Souvent par manque de temps : lors de migrations, de tests ou d'incidents, une règle large est posée comme solution transitoire puis jamais démantelée. La facilité joue aussi un rôle, quand une autorisation large va plus vite que des règles propres et étroites. Il en reste ainsi des scories qui masquent l'objectif initial.
D'abord les rendre visibles, puis les évaluer : la règle est-elle un blocage par défaut voulu ou une autorisation large risquée ? Les autorisations larges sont resserrées progressivement, justifiées et modifiées une à une, idéalement avec le principe des quatre yeux et un snapshot préalable. Le risque diminue ainsi sans qu'une refonte ne déclenche de nouveaux incidents.
Le Least Privilege exige de n'accorder que l'accès strictement nécessaire. Une autorisation Any-Any large va à l'encontre de ce principe, car elle ouvre en bloc au lieu d'autoriser de façon ciblée. Les audits selon NIS2 ou DORA surveillent donc ce type de règles : elles sont difficiles à justifier et constituent un constat classique lors d'une revue de l'ensemble de règles.
- NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy - csrc.nist.gov
- BSI IT-Grundschutz, Baustein NET.3.2 Firewall - bsi.bund.de/.../NET_3_2_Firewall
- Portail d'aide Zscaler : ZIA Cloud Firewall Policy - help.zscaler.com
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.