Zum Hauptinhalt springen
Sie haben bereits eine Firewall-Policy, der Sie in Staging vertrauen, und Sie wollen eine zweite für Produktion mit zwei geänderten Regeln — oder Sie wollen die Live-Policy verschärfen, ohne den Überblick zu verlieren, was sich änderte. Beides sind Policy-Lebenszyklus-Schritte: stellen Sie eine zweite Policy als Ausgangspunkt auf, und lehnen Sie sich an die Version, die bei jedem Update hochzählt, um zu wissen, dass sich Ihre Änderung propagiert hat. Diese Seite ist die Lebenszyklus-Referenz — abzweigen, versionieren, defaulten und aktivieren/deaktivieren/löschen. Für die Erstkonfiguration siehe Erstellen & anhängen; für die Regelgrammatik siehe Firewall-Regeln.
Die gesamte Policy-Verwaltung passiert in der Konsole (oder den /api/workspace/firewall/*-Management-Routen, die sich mit Ihrem Session-/Access-Token authentifizieren — nicht mit einem sk-orca-…-Relay-Key). Nur die /v1/*-Aufrufe Ihres Agenten nutzen den Relay-Key. Eine Policy erstellen, bearbeiten und defaulten sind Developer+-Aktionen; das Lesen der Policy-Liste und ihrer Version ist für jedes Member offen.

​
1. Ihre Haltung in eine zweite Policy abzweigen

Es gibt kein „Fork”-Verdikt oder Kopier-Button — ein Policy-Name ist pro Workspace eindeutig, sodass das Muster ist, eine zweite, unabhängig versionierte Policy aufzustellen und sie frei zu divergieren, ohne das Original zu berühren. Zwei Wege, sie zu seeden:
1

Die neue Policy erstellen, dann ihre Regeln verfassen

Öffnen Sie Security → Firewall → Policies → New policy. Eine neue Policy wird mit keinen Regeln und Ihrem gewählten default_verdict erstellt — verfassen Sie ihre Regeln im Editor (oder kopieren Sie ein paar von Hand aus der Quell-Policy herüber). Geben Sie ihr einen workspace-eindeutigen Namen (z. B. prod-firewall neben staging-firewall).
2

Oder ein Use-Case-Template anwenden

Die Templates-Galerie (POST /api/workspace/firewall/templates/apply) erstellt eine neue Policy plus all ihre Regeln in einer einzigen Transaktion — Coding, Support, RAG, Data, DevOps, Browser oder Baseline. Schneller als Handverfassen, wenn ein Template passt.
3

Divergieren und anhängen

Bearbeiten Sie die Regeln der neuen Policy — verschärfen Sie das destruktive-Shell-deny, tauschen Sie einen Egress-Allow-List-Host — dann hängen Sie sie via firewall_policy_id an den Produktions-Key, oder markieren Sie sie als Workspace-Default. Die Quell-Policy bleibt unberührt.
Eine zweite Policy ist der sichere Weg, eine riskantere Haltung zu testen. Stellen Sie eine auf, schalten Sie Shadow-Mode darauf ein, hängen Sie sie an einen Canary-Key und beobachten Sie den Events-Feed — die Produktions-Policy auf jedem anderen Key setzt unverändert weiter durch.
Jede Policy trägt ihre eigene Provenienz, ihren eigenen Angehängte-Key-Zähler und ihre eigene Versionslinie.

​
2. Die Version, die bei jedem Update hochzählt

Jede Firewall-Policy hat eine version-Ganzzahl. Sie startet bei 1, wenn die Policy erstellt wird, und inkrementiert um eins bei jedem Update — einer Regelbearbeitung, einer Default-Verdikt-Änderung, einem Aktivieren/Deaktivieren-Toggle, einem Shadow-Mode-Flip. Sie ist monoton und setzt nie zurück. 
// 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
}
Die Version ist Ihr Propagationssignal: das Gateway cacht aufgelöste Policies kurz, und jeder Save invalidiert diesen Cache, sodass Ihre Bearbeitung auf angehängten Keys innerhalb von Sekunden wirksam wird — kein Redeploy, keine Änderung im Agenten-Code. Die version treibt den Cache nicht; sie ist ein monotoner Änderungszähler, den Sie zurücklesen. Wenn Sie eine Policy speichern und bestätigen wollen, dass die Änderung aktiv ist, lesen Sie die Policy erneut und prüfen, dass version vorgerückt ist.
Die Policy-version ist ein Änderungszähler, kein Wiederherstellungspunkt. Sie sagt Ihnen, dass sich die Policy geändert hat, und lässt das Gateway die Bearbeitung propagieren — sie ist kein Pro-Version-Diff oder -Rollback. Für volle versionierte Historie mit Diff und Ein-Klick-Revert lebt diese Fähigkeit auf Guardrails: GET /api/guardrail/:id/history, …/history/diff und POST /api/guardrail/:id/revert (Revert ist Developer+). Für Firewall-Policies sind Ihre Audit-Spur und das Behalten einer degradierten, bekannt-guten Policy in der Liste die Art, wie Sie einen Wiederherstellungspunkt bewahren — siehe §5.

​
3. Den Workspace-Default setzen und verschieben

Ein Workspace kann eine Policy als Default markieren. Jeder Key ohne eigene firewall_policy_id löst auf sie auf (Auflösungsreihenfolge).
  • Bearbeiten Sie eine Policy und setzen Sie sie als Workspace-Default. Das Promoten eines neuen Defaults degradiert den alten in derselben Transaktion — es gibt nie ein Fenster mit zwei Defaults und nie ein Fenster mit keinem mitten im Tausch.
  • Eine zweite Policy aufzustellen ist ein sauberer Weg, den Default vorzurollen: bauen Sie die neue Policy, justieren Sie, validieren Sie unter Shadow-Mode, dann promoten Sie sie. Der alte Default bleibt in der Liste, degradiert, als Ihr Fallback.
Den Default zu verschieben ändert die Durchsetzung für jeden unangehängten Key auf einmal. Wenn der neue Default das default_verdict auf deny verschärft, beginnen Aufrufe, die Ihre Regeln nicht explizit erlauben, sofort zu blockieren. Rollen Sie einen neuen Default hinter Shadow-Mode aus und beobachten Sie Events, bevor Sie ihn promoten.

​
4. Aktivieren, deaktivieren und löschen

Das Umschalten von Enabled auf aus stoppt eine Policy am Auflösen. Aber denken Sie an die Firewall-Fall-through: ein Key, dessen angehängte Policy deaktiviert ist, fällt auf den Workspace-Default zurück — das Deaktivieren nimmt den Key nicht aus dem Firewall-Scope. Um einen Key aus der Durchsetzung zu entfernen, detachen Sie ihn (setzen Sie firewall_policy_id auf 0), deaktivieren Sie nicht einfach seine Policy. (Dies unterscheidet sich von Guardrails, wo ein deaktivierter Anhang auf keinen auflöst.)
DELETE /api/workspace/firewall/policies/:id (Developer+) entfernt eine Policy — gibt aber 409 zurück, wenn ein Key sie noch referenziert. Detachen oder verweisen Sie diese Keys zuerst um, dann löschen. Dieser Schutz ist der Grund, warum das Aufstellen einer zweiten Policy, nicht das In-Place-Neuschreiben, der sicherere Weg ist, eine Policy zu evolvieren, von der Live-Keys abhängen.
Ein Policy-Name ist innerhalb eines Workspaces eindeutig, sodass eine zweite Policy einen neuen Namen braucht. Verwenden Sie eine Konvention, die den Lebenszyklus überlebt — staging-firewall / prod-firewall, oder ein Datums-Suffix — statt policy-copy-2.

​
5. Audit-Spur

Jedes Policy-Create, -Update (was eine Default-Promotion oder einen Shadow-Mode-Flip einschließt) und -Delete schreibt eine Audit-Zeile — sowohl eine Workspace-Zeile als auch eine zentrale Admin-Zeile — nachdem die Änderung committed ist. Ein fehlgeschlagener Save (Duplikat-Name, ungültiges Verdikt) schreibt nichts. Regel-Blobs und Secrets werden nie ins Audit-Log geschrieben. Auch wenn Firewall-Policies keine eigene Diff-und-Revert-Historie tragen, sagt Ihnen die Audit-Spur wer welche Policy wann geändert hat, und die monotone version sagt Ihnen wie viele Male sie sich geändert hat. Paaren Sie das mit dem Behalten einer degradierten, bekannt-guten Policy in der Liste, und Sie haben einen praktischen Wiederherstellungspfad.

​
6. Lebenszyklus auf einen Blick

AktionRouteRolle
Policies auflisten (+ Version, Zähler)GET /api/workspace/firewall/policiesMember
Eine Policy lesenGET /api/workspace/firewall/policies/:idMember
Policy erstellen (keine Regeln)POST /api/workspace/firewall/policiesDeveloper+
Ein Template anwenden (Policy + Regeln)POST /api/workspace/firewall/templates/applyDeveloper+
Update (zählt version hoch)PUT /api/workspace/firewall/policiesDeveloper+
Löschen (409 bei angehängten Keys)DELETE /api/workspace/firewall/policies/:idDeveloper+
Bevor Sie sich auf eine neue oder frisch promotete Policy verlassen, dry-runnen Sie sie im Sandbox-Test-Tab — er gibt das Verdikt, die gematchte Regel und den Grund zurück, ohne irgendetwas zu dispatchen. Siehe Regeln testen.

​
Wohin als Nächstes

Erstellen & anhängen

Der Erstkonfigurationspfad — eine Policy erstellen und einen Key darauf richten.

Shadow-Mode

Rollen Sie eine neue oder neu-gedefaultete Policy aus, ohne Live-Traffic zu ändern.

Firewall + Guardrails

Wie sich Aktions-Policies mit Text-Guardrails komponieren — und wo versionierter Revert lebt.

Scope: Keys, Policies, Workspaces

Wie Anhang und der Workspace-Default auflösen.