Passer au contenu principal
Vous avez déjà une politique firewall en laquelle vous avez confiance en staging, et vous en voulez une seconde pour la production avec deux règles modifiées — ou vous voulez resserrer la politique en live sans perdre la trace de ce qui a changé. Les deux sont des mouvements de cycle de vie de politique : dressez une seconde politique comme point de départ, et appuyez-vous sur la version qui s’incrémente à chaque mise à jour pour savoir que votre changement s’est propagé. Cette page est la référence du cycle de vie — dériver, versionner, défaut, et activer/désactiver/supprimer. Pour la configuration initiale, voir Créer et attacher ; pour la grammaire des règles, voir Règles du Firewall.
Toute la gestion des politiques se fait dans la console (ou les routes de gestion /api/workspace/firewall/*, qui s’authentifient avec votre session / token d’accès — pas une clé de relais sk-orca-…). Seuls les appels /v1/* de votre agent utilisent la clé de relais. Créer, éditer et mettre par défaut une politique sont des actions Developer+ ; lire la liste des politiques et leur version est ouvert à chaque Member.

​
1. Dériver votre posture en une seconde politique

Il n’y a pas de verdict « fork » ni de bouton de copie — un nom de politique est unique par espace de travail, donc le pattern est de dresser une seconde politique versionnée indépendamment et de la faire diverger librement sans toucher à l’originale. Deux façons de l’initialiser :
1

Créer la nouvelle politique, puis rédiger ses règles

Ouvrez Security → Firewall → Policies → New policy. Une nouvelle politique est créée avec aucune règle et le default_verdict que vous avez choisi — rédigez ses règles dans l’éditeur (ou copiez-en quelques-unes de la politique source à la main). Donnez-lui un nom unique dans l’espace de travail (par ex. prod-firewall à côté de staging-firewall).
2

Ou appliquer un template de cas d'usage

La galerie Templates (POST /api/workspace/firewall/templates/apply) crée une nouvelle politique plus toutes ses règles en une seule transaction — Coding, Support, RAG, Data, DevOps, Browser, ou Baseline. Plus rapide que la rédaction à la main quand un template correspond.
3

Faire diverger et attacher

Éditez les règles de la nouvelle politique — resserrez le deny du shell destructeur, remplacez un host d’allow-list d’egress — puis attachez-la à la clé de production via firewall_policy_id, ou marquez-la comme défaut de l’espace de travail. La politique source est intacte.
Une seconde politique est la façon sûre de tester une posture plus risquée. Dressez-en une, activez le mode shadow dessus, attachez-la à une seule clé canary, et surveillez le flux d’événements — la politique de production sur chaque autre clé continue d’appliquer inchangée.
Chaque politique porte sa propre provenance, son propre compte de clés attachées, et sa propre ligne de version.

​
2. La version qui s’incrémente à chaque mise à jour

Chaque politique firewall a un entier version. Il commence à 1 quand la politique est créée et s’incrémente de un à chaque mise à jour — une édition de règle, un changement de verdict par défaut, un basculement activer/désactiver, un basculement de mode shadow. Il est monotone et ne se réinitialise jamais. 
// GET /api/workspace/firewall/policies/:id  → (abridged)
{
  "id": 42,
  "name": "prod-firewall",
  "enabled": true,
  "is_default": true,
  "default_verdict": "audit",
  "shadow_mode": false,
  "version": 7,          // bumped from 6 → 7 by your last save
  "rule_count": 11,
  "attached_key_count": 3
}
La version est votre signal de propagation : la passerelle met en cache brièvement les politiques résolues, et chaque enregistrement invalide ce cache de sorte que votre édition prend effet sur les clés attachées en quelques secondes — aucun redéploiement, aucun changement de code d’agent. La version ne pilote pas le cache ; c’est un compteur de changements monotone que vous relisez. Quand vous enregistrez une politique et voulez confirmer que le changement est en live, relisez la politique et vérifiez que version a avancé.
La version de la politique est un compteur de changements, pas un point de restauration. Elle vous dit que la politique a changé et laisse la passerelle propager l’édition — ce n’est pas un diff par version ni un rollback. Pour un historique versionné avec diff et annulation en un clic, cette capacité vit sur les Guardrails : GET /api/guardrail/:id/history, …/history/diff, et POST /api/guardrail/:id/revert (l’annulation est Developer+). Pour les politiques firewall, votre piste d’audit et le fait de garder une politique known-good rétrogradée dans la liste sont votre moyen de préserver un point de restauration — voir §5.

​
3. Définir et déplacer le défaut de l’espace de travail

Un espace de travail peut marquer une politique comme défaut. Chaque clé sans son propre firewall_policy_id s’y résout (ordre de résolution).
  • Éditez une politique et définissez-la comme défaut de l’espace de travail. Promouvoir un nouveau défaut rétrograde l’ancien dans la même transaction — il n’y a jamais une fenêtre avec deux défauts, ni une fenêtre avec aucun en plein échange.
  • Dresser une seconde politique est une façon propre de faire avancer le défaut : construisez la nouvelle politique, ajustez, validez sous le mode shadow, puis promouvez-la. L’ancien défaut reste dans la liste, rétrogradé, comme votre fallback.
Déplacer le défaut change l’application pour chaque clé non attachée à la fois. Si le nouveau défaut resserre le default_verdict à deny, les appels que vos règles n’autorisent pas explicitement commencent à bloquer immédiatement. Déployez un nouveau défaut derrière le mode shadow et surveillez Events avant de le promouvoir.

​
4. Activer, désactiver et supprimer

Basculer Enabled sur désactivé empêche une politique de se résoudre. Mais rappelez-vous le fall-through du firewall : une clé dont la politique attachée est désactivée retombe sur le défaut de l’espace de travail — désactiver ne retire pas la clé de la portée du firewall. Pour retirer une clé de l’application, détachez-la (définissez firewall_policy_id à 0), ne désactivez pas seulement sa politique. (Cela diffère des guardrails, où un attachement désactivé se résout en aucun.)
DELETE /api/workspace/firewall/policies/:id (Developer+) supprime une politique — mais renvoie 409 si une clé y fait encore référence. Détachez ou re-pointez ces clés d’abord, puis supprimez. Cette garde est la raison pour laquelle dresser une seconde politique, plutôt que de réécrire sur place, est la façon la plus sûre de faire évoluer une politique dont des clés en live dépendent.
Un nom de politique est unique au sein d’un espace de travail, donc une seconde politique a besoin d’un nouveau nom. Utilisez une convention qui survit au cycle de vie — staging-firewall / prod-firewall, ou un suffixe de date — plutôt que policy-copy-2.

​
5. Piste d’audit

Chaque création, mise à jour (ce qui inclut une promotion de défaut ou un basculement de mode shadow) et suppression de politique écrit une ligne d’audit — à la fois une ligne d’espace de travail et une ligne d’admin centrale — après que le changement est committé. Un enregistrement échoué (nom en double, verdict invalide) n’écrit rien. Les blobs de règles et les secrets ne sont jamais écrits dans le journal d’audit. Donc même si les politiques firewall ne portent pas d’historique diff-et-annulation propre, la piste d’audit vous dit qui a changé quelle politique, quand, et la version monotone vous dit combien de fois elle a changé. Associez cela au fait de garder une politique rétrogradée et known-good dans la liste, et vous avez un chemin de restauration pratique.

​
6. Le cycle de vie en un coup d’œil

ActionRouteRôle
Lister les politiques (+ version, comptes)GET /api/workspace/firewall/policiesMember
Lire une politiqueGET /api/workspace/firewall/policies/:idMember
Créer une politique (aucune règle)POST /api/workspace/firewall/policiesDeveloper+
Appliquer un template (politique + règles)POST /api/workspace/firewall/templates/applyDeveloper+
Mettre à jour (incrémente version)PUT /api/workspace/firewall/policiesDeveloper+
Supprimer (409 si des clés sont attachées)DELETE /api/workspace/firewall/policies/:idDeveloper+
Avant de vous fier à une politique nouvelle ou fraîchement promue, exécutez-la en dry-run dans l’onglet Test du sandbox — il renvoie le verdict, la règle correspondante et la raison sans rien dispatcher. Voir Tester les règles.

​
Où aller ensuite

Créer et attacher

Le chemin de configuration initiale — créer une politique et pointer une clé dessus.

Mode shadow

Déployer une politique nouvelle ou re-mise par défaut sans changer le trafic réel.

Firewall + Guardrails

Comment les politiques d’action se composent avec les guardrails de texte — et où vit l’annulation versionnée.

Portée : clés, politiques, espaces de travail

Comment l’attachement et le défaut de l’espace de travail se résolvent.