Vai al contenuto principale
Quando due regole potrebbero entrambe corrispondere alla stessa chiamata a tool, la priorità delle regole del firewall decide quale vince. Una policy del firewall è un elenco ordinato di regole — il motore le percorre in ordine di priorità, si ferma alla prima che corrisponde, e applica il suo verdetto. Azzecca l’ordine e una guardia ampia più un’eccezione stretta coesistono in modo pulito; sbaglialo e la regola ampia inghiotte l’eccezione che intendevi ricavare. Questa pagina è il riferimento focalizzato sull’ordinamento. Per la grammatica completa delle regole vedi Regole del Firewall; per i verdetti che una regola può produrre vedi Verdetti.

​
1. L’ordine: priorità ascendente, vince il primo match

All’interno di una policy, le regole sono valutate in ordine priority ASC, id ASC:
  1. La priority più bassa gira per prima. Una regola con priority: 0 è controllata prima di una con priority: 10. Pensala come una posizione in coda, non un punteggio di forza — il numero più piccolo ha la prima parola.
  2. Le parità si risolvono per id della regola. Due regole alla stessa priority girano in ordine di creazione (id della regola ascendente), così la regola più vecchia vince la parità. Usa priorità distinte quando l’ordine conta davvero anziché affidarti alla risoluzione della parità per id.
  3. Vince il primo match. Il motore si ferma alla prima regola le cui condizioni tutte valgono e applica il suo verdetto. Le regole più in basso nell’elenco non vengono mai consultate per quella chiamata.
  4. Nessun match → il verdetto di default. Se nulla corrisponde, si applica il default_verdict della policy — audit a meno che tu non l’abbia cambiato.
Una regola corrisponde solo quando ogni condizione dichiarata vale contemporaneamente: la superficie, il glob sul nome del tool, il glob opzionale sulla skill, le clausole opzionali sugli argomenti e lo scope di egress (solo regole egress). Un match parziale è un non-match, e la valutazione passa alla regola successiva.

​
2. Un esempio concreto: specifico prima di ampio

Il compito di ordinamento canonico è far sopravvivere un allow stretto a un deny ampio. Metti la regola specifica a una priorità più bassa così viene raggiunta per prima: 
// 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" }
Una chiamata a shell.echo colpisce prima la Regola A (priorità 10), corrisponde, ed è consentita — il motore non raggiunge mai la Regola B. Una chiamata a shell.exec ricade attraverso A (il glob non corrisponde), colpisce la Regola B, ed è negata. Inverti le priorità e il deny ampio shell.* a priorità 10 catturerebbe prima shell.echo, e il tuo allow a priorità 20 sarebbe codice morto. La regola generale: il più specifico per primo, il più ampio per ultimo.
Non dipendere dalla risoluzione della parità per id per questo. Se l’allow e il deny condividono la stessa priority, il vincitore è qualunque regola hai creato per prima — un ordinamento fragile che si ribalta silenziosamente se elimini e ricrei una regola. Dai alla regola specifica una priority più bassa e l’intento è esplicito.

​
3. Verifica l’ordine prima di farci affidamento

Ragionare sulla priorità sulla carta è soggetto a errori una volta che una policy ha più di una manciata di regole. La sandbox Test fa girare il motore reale contro una chiamata a tool di esempio e ti dice non solo il verdetto ma quale regola ha vinto — così puoi confermare che la regola che ti aspettavi sia effettivamente scattata:
1

Apri la scheda Test della policy

Nella console, apri la policy e passa a Test (Developer+).
2

Invia una chiamata di esempio

Inserisci un nome di tool (e gli argomenti, se le tue regole li ispezionano) ed eseguila. Nulla viene dispatchato e nulla viene persistito — è un dry run.
3

Leggi la regola corrispondente

Il risultato nomina il verdetto, la regola corrispondente (per etichetta/id) e la motivazione. Se una regola ampia ha vinto dove ti aspettavi una stretta, abbassa la priority della regola stretta e ri-testa.
Vedi Testa le regole per la sandbox completa, e Gestisci le policy per modificare l’ordine delle regole sul posto.

​
4. L’applicazione della skill si sovrappone

La priorità delle regole decide il verdetto della regola vincente — ma quella non è sempre la risposta finale. Se la chiamata a tool è di proprietà di una skill governata, la modalità di applicazione della skill è applicata sopra il verdetto vincente, dopo la risoluzione del primo match:
Modalità della skillEffetto sul verdetto vincente
allowNessun cambiamento — il verdetto della regola regge.
quarantineEscala qualsiasi cosa al di sotto di deny a pending_approval; un deny esistente è lasciato com’è.
blockForza un deny indipendentemente dal verdetto della regola.
Quindi una skill quarantine può trasformare un allow di una regola in una chiamata in attesa, e una skill block nega una chiamata anche quando nessuna regola nomina i suoi tool. La quarantine escala soltanto — non declassa mai un deny a qualcosa di più morbido. È per questo che una skill auto-rilevata come rischiosa resta in quarantine finché non la revisioni, per quanto permissive siano le tue regole.
La modalità della skill non è una regola, quindi non ha una priority e non puoi ri-ordinarla rispetto alle tue regole. Valuta sempre dopo che il verdetto vincente è scelto. Se la modalità di una skill governata sta bloccando chiamate che ti aspettavi di consentire, sistemala sulla skill, non aggiungendo una regola di allow a priorità più alta — la regola non può sovrascrivere la modalità.

​
5. Cose che non seguono il primo-match

Alcuni meccanismi stanno fuori dal percorso di priorità per-regola — sappi dove atterrano così non provi a ordinarli:
Una regola cap_cost sotto il suo tetto è trattata come non corrispondente, così la valutazione continua alla regola successiva anziché farla vincere il primo-match come un grant. Sopra il tetto si risolve in un deny. Non fa mai short-circuit di una regola a priorità più bassa solo per essere stata raggiunta.
Una regola di sequenza corrisponde a una catena di chiamate attraverso una finestra temporale, quindi è applicata reattivamente da un matcher asincrono anziché sulla singola chiamata che completa la catena. Illumina il feed degli eventi ma non vince il percorso del primo-match per una chiamata individuale.
La shadow mode non cambia quale regola vince — declassa il verdetto applicativo vincente a audit (motivazione prefissata [shadow] would …) dopo la risoluzione del primo match, così puoi misurare l’impatto di una policy prima che modifichi il traffico.

​
6. Mettendo tutto insieme

Per ogni chiamata a tool la risoluzione completa è:
  1. Risolvi la policy — quella collegata alla chiave chiamante, o il default del workspace. Vedi scope.
  2. Percorri le regole in priority ASC, id ASC — vince il primo match; nessun match → default_verdict.
  3. Applica l’applicazione della skill — la modalità di una skill governata si sovrappone al verdetto vincente (block forza il deny, quarantine escala).
  4. Applica la shadow mode — se attiva, declassa i verdetti applicativi a audit.
  5. Registra l’evento — verdetto, superficie, tool e regola corrispondente atterrano nel feed degli eventi.
Modificare la priorità di una regola ha effetto sulla chiamata successiva per ogni chiave collegata alla policy — nessun redeploy, nessuna modifica al codice dell’agent. Ri-esegui la sandbox Test dopo aver ri-ordinato per confermare il nuovo vincitore prima che il traffico live ci faccia affidamento.

​
Dove andare dopo

Verdetti

Cosa fa effettivamente ogni verdetto vincente.

Sintassi glob

Come il matching sul nome del tool decide se una regola è anche solo un candidato.

Testa le regole

Dry-run di una policy e vedi quale regola vince.

Allow-listing dei tool

Il pattern default-deny che si appoggia di più sull’ordinamento.
Per il linguaggio di matching dietro una regola, vedi il riferimento completo delle Regole del Firewall; per come le skill si stratificano sopra, vedi Skill del Firewall e modalità di applicazione.