Passer au contenu principal
Quand deux règles pourraient toutes deux correspondre au même appel d’outil, la priorité des règles de firewall décide laquelle gagne. Une politique firewall est une liste ordonnée de règles — le moteur les parcourt dans l’ordre de priorité, s’arrête à la première qui correspond, et applique son verdict. Obtenez le bon ordre et un garde large plus une exception étroite coexistent proprement ; obtenez le mauvais et la règle large avale l’exception que vous vouliez tailler. Cette page est la référence ciblée sur l’ordonnancement. Pour la grammaire complète des règles, voir Règles du Firewall ; pour les verdicts qu’une règle peut produire, voir Verdicts.

​
1. L’ordre : priorité ascendante, première correspondance gagne

Au sein d’une politique, les règles sont évaluées dans l’ordre priority ASC, id ASC :
  1. La priority plus basse s’exécute en premier. Une règle avec priority: 0 est vérifiée avant une avec priority: 10. Pensez-y comme à une position dans une file, pas un score de force — le plus petit numéro a son mot à dire en premier.
  2. Les égalités se tranchent par l’id de règle. Deux règles à la même priority s’exécutent dans l’ordre de création (id de règle ascendant), de sorte que la règle la plus ancienne gagne l’égalité. Utilisez des priorités distinctes quand l’ordre compte réellement plutôt que de compter sur le tie-break par id.
  3. La première correspondance gagne. Le moteur s’arrête à la première règle dont les conditions tiennent toutes et applique son verdict. Les règles plus bas dans la liste ne sont jamais consultées pour cet appel.
  4. Aucune correspondance → le verdict par défaut. Si rien ne correspond, le default_verdict de la politique s’applique — audit sauf si vous l’avez changé.
Une règle ne correspond que lorsque chaque condition déclarée tient à la fois : la surface, le glob de nom d’outil, le glob de skill optionnel, les clauses d’arguments optionnelles, et la portée d’egress (règles d’egress seulement). Une correspondance partielle est une non-correspondance, et l’évaluation passe à la règle suivante.

​
2. Un exemple concret : spécifique avant large

Le job d’ordonnancement canonique est de laisser un allow étroit survivre à un deny large. Placez la règle spécifique à une priorité plus basse pour qu’elle soit atteinte en premier : 
// Rule A — priority 10: trust this one exact tool.
{ "label": "allow safe shell", "priority": 10,
  "tool_name_glob": "shell.echo", "verdict": "allow" }

// Rule B — priority 20: block the rest of the shell family.
{ "label": "block shell family", "priority": 20,
  "tool_name_glob": "shell.*", "verdict": "deny" }
Un appel à shell.echo atteint Rule A en premier (priorité 10), correspond, et est autorisé — le moteur n’atteint jamais Rule B. Un appel à shell.exec retombe à travers A (le glob ne correspond pas), atteint Rule B, et est refusé. Inversez les priorités et le deny large shell.* à la priorité 10 attraperait shell.echo en premier, et votre allow à la priorité 20 serait du code mort. La règle de pouce : le plus spécifique en premier, le plus large en dernier.
Ne dépendez pas du tie-break par id pour cela. Si l’allow et le deny partagent la même priority, le gagnant est la règle que vous avez créée en premier — un ordonnancement fragile qui s’inverse silencieusement si vous supprimez et re-créez une règle. Donnez à la règle spécifique une priority plus basse et l’intention est explicite.

​
3. Vérifier l’ordre avant de vous y fier

Raisonner sur la priorité sur papier est sujet aux erreurs une fois qu’une politique a plus d’une poignée de règles. Le sandbox Test exécute le vrai moteur contre un appel d’outil d’échantillon et vous dit non seulement le verdict mais quelle règle a gagné — de sorte que vous pouvez confirmer que la règle que vous attendiez s’est réellement déclenchée :
1

Ouvrir l'onglet Test de la politique

Dans la console, ouvrez la politique et passez à Test (Developer+).
2

Soumettre un appel d'échantillon

Entrez un nom d’outil (et des arguments, si vos règles les inspectent) et exécutez-le. Rien n’est dispatché et rien n’est persisté — c’est un dry run.
3

Lire la règle correspondante

Le résultat nomme le verdict, la règle correspondante (par label/id), et la raison. Si une règle large a gagné là où vous attendiez une étroite, abaissez la priority de la règle étroite et re-testez.
Voir Tester les règles pour le sandbox complet, et Gérer les politiques pour éditer l’ordre des règles sur place.

​
4. L’application de skill se superpose par-dessus

La priorité des règles décide le verdict de la règle gagnante — mais ce n’est pas toujours la réponse finale. Si l’appel d’outil appartient à un skill gouverné, le mode d’application du skill est appliqué par-dessus le verdict gagnant, après la résolution first-match :
Mode du skillEffet sur le verdict gagnant
allowAucun changement — le verdict de la règle tient.
quarantineEscalade tout ce qui est en-deçà d’un deny vers pending_approval ; un deny existant est laissé tel quel.
blockForce un deny quel que soit le verdict de la règle.
Donc un skill quarantine peut transformer un allow de règle en un appel mis en attente, et un skill block refuse un appel même quand aucune règle ne nomme ses outils. La quarantaine n’escalade que — elle ne rétrograde jamais un deny vers quelque chose de plus doux. C’est pourquoi un skill auto-détecté comme risqué reste en quarantaine jusqu’à ce que vous le relisiez, peu importe à quel point vos règles sont permissives.
Le mode du skill n’est pas une règle, donc il n’a pas de priority et vous ne pouvez pas le réordonner par rapport à vos règles. Il s’évalue toujours après que le verdict gagnant est choisi. Si le mode d’un skill gouverné bloque des appels que vous attendiez d’autoriser, corrigez-le sur le skill, pas en ajoutant une règle allow de priorité plus haute — la règle ne peut pas outrepasser le mode.

​
5. Les choses qui ne suivent pas la première correspondance

Quelques mécanismes se situent en dehors du parcours de priorité par règle — sachez où ils atterrissent pour ne pas essayer de les ordonner :
Une règle cap_cost sous son plafond est traitée comme non-correspondante, de sorte que l’évaluation continue vers la règle suivante plutôt que de la laisser gagner en première correspondance comme une autorisation. Au-dessus du plafond, elle se résout en un deny. Elle ne court-circuite jamais une règle de priorité plus basse juste en étant atteinte.
Une règle de séquence correspond à une chaîne d’appels sur une fenêtre temporelle, donc elle est appliquée réactivement par un matcher asynchrone plutôt que sur l’unique appel qui complète la chaîne. Elle allume le flux d’événements mais ne gagne pas le parcours first-match pour un appel individuel.
Le mode shadow ne change pas quelle règle gagne — il rétrograde le verdict appliquant gagnant en audit (raison préfixée [shadow] would …) après la résolution first-match, de sorte que vous pouvez mesurer l’impact d’une politique avant qu’elle ne change le trafic.

​
6. Mettre le tout ensemble

Pour tout appel d’outil, la résolution complète est :
  1. Résoudre la politique — celle attachée à la clé appelante, ou le défaut de l’espace de travail. Voir portée.
  2. Parcourir les règles dans priority ASC, id ASC — la première correspondance gagne ; aucune correspondance → default_verdict.
  3. Appliquer l’application de skill — le mode d’un skill gouverné se superpose au verdict gagnant (block force un deny, quarantine escalade).
  4. Appliquer le mode shadow — si activé, rétrograder les verdicts appliquants en audit.
  5. Enregistrer l’événement — verdict, surface, outil et règle correspondante atterrissent dans le flux d’événements.
Éditer la priorité d’une règle prend effet dès le prochain appel pour chaque clé attachée à la politique — aucun redéploiement, aucun changement de code d’agent. Ré-exécutez le sandbox Test après réordonnancement pour confirmer le nouveau gagnant avant que le trafic réel n’en dépende.

​
Où aller ensuite

Verdicts

Ce que fait réellement chaque verdict gagnant.

Syntaxe glob

Comment la correspondance de nom d’outil décide si une règle est même un candidat.

Tester les règles

Dry-run d’une politique et voir quelle règle gagne.

Liste blanche d'outils

Le pattern default-deny qui s’appuie le plus sur l’ordonnancement.
Pour le langage de correspondance derrière une règle, voir la référence complète des Règles du Firewall ; pour la façon dont les skills se superposent, voir Firewall Skills et modes d’application.