Saltar al contenido principal
Ya tienes una política de firewall en la que confías en staging, y quieres una segunda para producción con dos reglas cambiadas — o quieres endurecer la política en vivo sin perder el rastro de lo que cambió. Ambos son movimientos de ciclo de vida de política: levanta una segunda política como punto de partida, y apóyate en la versión que se incrementa en cada actualización para saber que tu cambio se propagó. Esta página es la referencia del ciclo de vida — ramificar, versionar, valor por defecto, y habilitar/deshabilitar/eliminar. Para la configuración inicial ver Crear y adjuntar; para la gramática de reglas ver Reglas del Firewall.
Toda la gestión de políticas ocurre en la consola (o las rutas de gestión /api/workspace/firewall/*, que se autentican con tu sesión / token de acceso — no una clave de relay sk-orca-…). Solo las llamadas /v1/* de tu agente usan la clave de relay. Crear, editar y establecer una política como valor por defecto son acciones Developer+; leer la lista de políticas y su versión está abierto a cada Member.

​
1. Ramifica tu postura en una segunda política

No hay veredicto “fork” ni botón de copia — un nombre de política es único por espacio de trabajo, así que el patrón es levantar una segunda política versionada de forma independiente y divergirla libremente sin tocar la original. Dos formas de sembrarla:
1

Crea la nueva política, luego autora sus reglas

Abre Security → Firewall → Policies → New policy. Una política nueva se crea con ninguna regla y tu default_verdict elegido — autora sus reglas en el editor (o copia algunas de la política origen a mano). Dale un nombre único en el espacio de trabajo (p. ej. prod-firewall junto a staging-firewall).
2

O aplica una plantilla de caso de uso

La galería de Templates (POST /api/workspace/firewall/templates/apply) crea una política nueva más todas sus reglas en una sola transacción — Coding, Support, RAG, Data, DevOps, Browser o Baseline. Más rápido que autorar a mano cuando una plantilla coincide.
3

Diverge y adjunta

Edita las reglas de la nueva política — endurece el deny de shell destructivo, intercambia un host de lista de permitidos de egress — luego adjúntala a la clave de producción vía firewall_policy_id, o márcala como el valor por defecto del espacio de trabajo. La política origen queda sin tocar.
Una segunda política es la forma segura de probar una postura más arriesgada. Levanta una, activa el modo shadow en ella, adjúntala a una clave canaria, y observa el feed de eventos — la política de producción en cada otra clave sigue aplicando sin cambios.
Cada política lleva su propia procedencia, su propio conteo de claves adjuntas y su propia línea de versión.

​
2. La versión que se incrementa en cada actualización

Cada política de firewall tiene un entero version. Empieza en 1 cuando la política se crea e incrementa en uno en cada actualización — una edición de regla, un cambio de veredicto por defecto, un interruptor de habilitar/deshabilitar, un cambio de modo shadow. Es monótono y nunca se reinicia. 
// 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 versión es tu señal de propagación: el gateway cachea las políticas resueltas brevemente, y cada guardado invalida ese caché para que tu edición surta efecto en las claves adjuntas en segundos — sin redespliegue, sin cambio de código del agente. La version no impulsa el caché; es un contador de cambios monótono que lees de vuelta. Cuando guardas una política y quieres confirmar que el cambio está en vivo, relee la política y verifica que version avanzó.
La version de la política es un contador de cambios, no un punto de restauración. Te dice que la política cambió y deja que el gateway propague la edición — no es un diff por versión ni un rollback. Para historial versionado con diff y revertir de un clic, esa capacidad vive en Guardrails: GET /api/guardrail/:id/history, …/history/diff, y POST /api/guardrail/:id/revert (revertir es Developer+). Para las políticas de firewall, tu rastro de auditoría y mantener una política buena-conocida degradada en la lista son cómo preservas un punto de restauración — ver §5.

​
3. Establece y mueve el valor por defecto del espacio de trabajo

Un espacio de trabajo puede marcar una política como el valor por defecto. Cada clave sin su propio firewall_policy_id resuelve a ella (orden de resolución).
  • Edita una política y establécela como el valor por defecto del espacio de trabajo. Promover un nuevo valor por defecto degrada al anterior en la misma transacción — nunca hay una ventana con dos valores por defecto, ni una ventana con ninguno a mitad de intercambio.
  • Levantar una segunda política es una forma limpia de avanzar el valor por defecto: construye la nueva política, ajusta, valida bajo modo shadow, luego promuévela. El valor por defecto antiguo se queda en la lista, degradado, como tu fallback.
Mover el valor por defecto cambia la aplicación para cada clave sin vincular a la vez. Si el nuevo valor por defecto endurece el default_verdict a deny, las llamadas que tus reglas no permiten explícitamente empiezan a bloquearse de inmediato. Lanza un nuevo valor por defecto detrás de modo shadow y observa Events antes de promoverlo.

​
4. Habilitar, deshabilitar y eliminar

Alternar Enabled a apagado detiene que una política resuelva. Pero recuerda el fall-through del firewall: una clave cuya política adjunta está deshabilitada hace fallback al valor por defecto del espacio de trabajo — deshabilitar no saca la clave del alcance del firewall. Para quitar una clave de la aplicación, desvincúlala (establece firewall_policy_id a 0), no solo deshabilites su política. (Esto difiere de los guardrails, donde una vinculación deshabilitada resuelve a ninguna.)
DELETE /api/workspace/firewall/policies/:id (Developer+) elimina una política — pero devuelve 409 si alguna clave aún la referencia. Desvincula o reapunta esas claves primero, luego elimina. Esta guarda es por qué levantar una segunda política, no reescribir en el lugar, es la forma más segura de evolucionar una política de la que dependen claves en vivo.
Un nombre de política es único dentro de un espacio de trabajo, así que una segunda política necesita un nombre nuevo. Usa una convención que sobreviva el ciclo de vida — staging-firewall / prod-firewall, o un sufijo de fecha — en vez de policy-copy-2.

​
5. Rastro de auditoría

Cada creación, actualización (que incluye una promoción de valor por defecto o un cambio de modo shadow) y eliminación de política escribe una fila de auditoría — tanto una fila de espacio de trabajo como una fila central de admin — después de que el cambio se confirma. Un guardado fallido (nombre duplicado, veredicto inválido) no escribe nada. Los blobs de reglas y los secretos nunca se escriben en el registro de auditoría. Así que aunque las políticas de firewall no llevan un historial de diff y revertir propio, el rastro de auditoría te dice quién cambió qué política, cuándo, y la version monótona te dice cuántas veces ha cambiado. Combina eso con mantener una política buena-conocida degradada en la lista, y tienes una ruta de restauración práctica.

​
6. Ciclo de vida de un vistazo

AcciónRutaRol
Listar políticas (+ versión, conteos)GET /api/workspace/firewall/policiesMember
Leer una políticaGET /api/workspace/firewall/policies/:idMember
Crear política (sin reglas)POST /api/workspace/firewall/policiesDeveloper+
Aplicar una plantilla (política + reglas)POST /api/workspace/firewall/templates/applyDeveloper+
Actualizar (incrementa version)PUT /api/workspace/firewall/policiesDeveloper+
Eliminar (409 si hay claves adjuntas)DELETE /api/workspace/firewall/policies/:idDeveloper+
Antes de confiar en una política nueva o recién promovida, ejecútala en seco en la pestaña Test del sandbox — devuelve el veredicto, la regla coincidente y la razón sin despachar nada. Ver Probar reglas.

​
Dónde ir a continuación

Crear y adjuntar

La ruta de configuración inicial — crea una política y apunta una clave hacia ella.

Modo shadow

Lanza una política nueva o con nuevo valor por defecto sin cambiar el tráfico en vivo.

Firewall + Guardrails

Cómo las políticas de acción se componen con los guardrails de texto — y dónde vive el revertir versionado.

Alcance: claves, políticas, espacios de trabajo

Cómo resuelven la vinculación y el valor por defecto del espacio de trabajo.