Przejdź do głównej treści
Masz już politykę firewalla, której ufasz w stagingu, i chcesz drugą na produkcję z dwiema zmienionymi regułami — albo chcesz zacieśnić politykę na żywo, nie tracąc orientacji, co się zmieniło. Oba to ruchy cyklu życia polityki: postaw drugą politykę jako punkt wyjścia i oprzyj się na wersji, która podbija się przy każdej aktualizacji, by wiedzieć, że twoja zmiana się rozpropagowała. Ta strona to referencja cyklu życia — rozgałęzienie, wersjonowanie, domyślna i włącz/wyłącz/usuń. Dla pierwszej konfiguracji zobacz Utwórz i przypnij; dla gramatyki reguł zobacz Reguły Firewall.
Całe zarządzanie politykami odbywa się w konsoli (lub na trasach zarządzania /api/workspace/firewall/*, które uwierzytelniają się twoją sesją / tokenem dostępu — nie kluczem relay sk-orca-…). Tylko wywołania /v1/* twojego agenta używają klucza relay. Tworzenie, edycja i ustawianie polityki jako domyślnej to akcje Developer+; odczyt listy polityk i jej wersji jest otwarty dla każdego Membera.

​
1. Rozgałęź postawę w drugą politykę

Nie ma werdyktu „fork” ani przycisku kopiowania — nazwa polityki jest unikalna per przestrzeń robocza, więc wzorzec to postawienie drugiej, niezależnie wersjonowanej polityki i swobodne jej rozbieżenie bez dotykania oryginału. Dwa sposoby, by ją zasiać:
1

Utwórz nową politykę, potem napisz jej reguły

Otwórz Security → Firewall → Policies → New policy. Nowa polityka jest tworzona z brakiem reguł i wybranym przez ciebie default_verdict — napisz jej reguły w edytorze (lub skopiuj kilka z polityki źródłowej ręcznie). Daj jej unikalną w przestrzeni roboczej nazwę (np. prod-firewall obok staging-firewall).
2

Albo zastosuj szablon przypadku użycia

Galeria Templates (POST /api/workspace/firewall/templates/apply) tworzy jedną nową politykę plus wszystkie jej reguły w pojedynczej transakcji — Coding, Support, RAG, Data, DevOps, Browser lub Baseline. Szybsze niż ręczne autorowanie, gdy szablon pasuje.
3

Rozbież i przypnij

Edytuj reguły nowej polityki — zacieśnij deny destrukcyjnego shella, zamień host listy dozwolonych egress — potem przypnij ją do klucza produkcyjnego przez firewall_policy_id lub oznacz jako domyślną przestrzeni roboczej. Polityka źródłowa jest nietknięta.
Druga polityka to bezpieczny sposób na testowanie bardziej ryzykownej postawy. Postaw jedną, włącz na niej tryb cienia, przypnij ją do jednego klucza kanarkowego i obserwuj strumień zdarzeń — polityka produkcyjna na każdym innym kluczu dalej egzekwuje niezmieniona.
Każda polityka niesie własną proweniencję, własny licznik przypiętych kluczy i własną linię wersji.

​
2. Wersja, która podbija się przy każdej aktualizacji

Każda polityka firewalla ma liczbę całkowitą version. Zaczyna się od 1, gdy polityka jest tworzona, i inkrementuje o jeden przy każdej aktualizacji — edycji reguły, zmianie werdyktu domyślnego, przełączeniu włącz/wyłącz, przełączeniu trybu cienia. Jest monotoniczna i nigdy się nie resetuje. 
// 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
}
Wersja to twój sygnał propagacji: brama buforuje rozwiązane polityki krótko, a każdy zapis unieważnia ten bufor, więc twoja edycja wchodzi w życie na przypiętych kluczach w ciągu sekund — bez ponownego wdrożenia, bez zmiany w kodzie agenta. version nie napędza bufora; to monotoniczny licznik zmian, który odczytujesz z powrotem. Gdy zapisujesz politykę i chcesz potwierdzić, że zmiana jest na żywo, odczytaj politykę ponownie i sprawdź, że version postąpił.
version polityki to licznik zmian, nie punkt przywracania. Mówi ci, że polityka się zmieniła, i pozwala bramie rozpropagować edycję — nie jest to diff per wersja ani rollback. Dla pełnej wersjonowanej historii z diffem i cofnięciem jednym kliknięciem ta zdolność żyje na Guardrails: GET /api/guardrail/:id/history, …/history/diff i POST /api/guardrail/:id/revert (revert to Developer+). Dla polityk firewalla twój ślad audytu i utrzymywanie zdegradowanej znanej-dobrej polityki na liście to sposób, w jaki zachowujesz punkt przywracania — zobacz §5.

​
3. Ustaw i przesuń domyślną przestrzeni roboczej

Przestrzeń robocza może oznaczyć jedną politykę jako domyślną. Każdy klucz bez własnego firewall_policy_id rozwiązuje się do niej (kolejność rozwiązywania).
  • Edytuj politykę i ustaw ją jako domyślną przestrzeni roboczej. Promowanie nowej domyślnej degraduje starą w tej samej transakcji — nigdy nie ma okna z dwiema domyślnymi ani okna z żadną w trakcie zamiany.
  • Postawienie drugiej polityki to czysty sposób na przesunięcie domyślnej do przodu: zbuduj nową politykę, dostrój, zwaliduj w trybie cienia, potem ją promuj. Stara domyślna pozostaje na liście, zdegradowana, jako twój fallback.
Przesunięcie domyślnej zmienia egzekwowanie dla każdego nieprzypiętego klucza naraz. Jeśli nowa domyślna zacieśnia default_verdict do deny, wywołania, których twoje reguły wyraźnie nie zezwalają, zaczynają blokować się natychmiast. Wytocz nową domyślną za trybem cienia i obserwuj Events, zanim ją promujesz.

​
4. Włącz, wyłącz i usuń

Przełączenie Enabled na wyłączone powstrzymuje politykę od rozwiązywania się. Ale pamiętaj o przepuszczaniu firewalla: klucz, którego przypięta polityka jest wyłączona, wraca do domyślnej przestrzeni roboczej — wyłączenie nie wyjmuje klucza z zakresu firewalla. Aby usunąć klucz z egzekwowania, odepnij go (ustaw firewall_policy_id na 0), nie tylko wyłącz jego politykę. (To różni się od guardrails, gdzie wyłączone powiązanie rozwiązuje się do braku.)
DELETE /api/workspace/firewall/policies/:id (Developer+) usuwa politykę — ale zwraca 409, jeśli jakiś klucz wciąż się do niej odwołuje. Odepnij lub przekieruj te klucze najpierw, potem usuń. Ten strażnik to powód, dla którego postawienie drugiej polityki, a nie przepisywanie w miejscu, to bezpieczniejszy sposób na ewolucję polityki, od której zależą klucze na żywo.
Nazwa polityki jest unikalna w przestrzeni roboczej, więc druga polityka potrzebuje nowej nazwy. Użyj konwencji, która przeżyje cykl życia — staging-firewall / prod-firewall lub sufiks daty — zamiast policy-copy-2.

​
5. Ślad audytu

Każde utworzenie, aktualizacja (która obejmuje promocję domyślnej lub przełączenie trybu cienia) i usunięcie polityki zapisuje wiersz audytu — zarówno wiersz przestrzeni roboczej, jak i centralny wiersz admina — po tym, jak zmiana się zatwierdzi. Nieudany zapis (zduplikowana nazwa, nieprawidłowy werdykt) nie zapisuje nic. Bloby reguł i sekrety nigdy nie są zapisywane do logu audytu. Więc nawet jeśli polityki firewalla nie niosą własnej historii diff-i-revert, ślad audytu mówi ci, kto zmienił którą politykę, kiedy, a monotoniczny version mówi ci, ile razy się zmieniła. Połącz to z utrzymywaniem zdegradowanej, znanej-dobrej polityki na liście, a masz praktyczną ścieżkę przywracania.

​
6. Cykl życia w skrócie

AkcjaTrasaRola
Lista polityk (+ wersja, liczniki)GET /api/workspace/firewall/policiesMember
Odczyt jednej politykiGET /api/workspace/firewall/policies/:idMember
Utwórz politykę (bez reguł)POST /api/workspace/firewall/policiesDeveloper+
Zastosuj szablon (polityka + reguły)POST /api/workspace/firewall/templates/applyDeveloper+
Aktualizuj (podbija version)PUT /api/workspace/firewall/policiesDeveloper+
Usuń (409, jeśli klucze przypięte)DELETE /api/workspace/firewall/policies/:idDeveloper+
Zanim polegniesz na nowej lub świeżo promowanej polityce, zrób jej dry-run w piaskownicowej zakładce Test — zwraca werdykt, dopasowaną regułę i powód bez dyspozytowania czegokolwiek. Zobacz Testowanie reguł.

​
Dokąd dalej

Utwórz i przypnij

Ścieżka pierwszej konfiguracji — utwórz politykę i skieruj na nią klucz.

Tryb cienia

Wytocz nową lub ponownie-domyślną politykę bez zmiany ruchu na żywo.

Firewall + Guardrails

Jak polityki akcji komponują się z guardrails tekstu — i gdzie żyje wersjonowany revert.

Zakres: klucze, polityki, przestrzenie robocze

Jak rozwiązują się powiązanie i domyślna przestrzeni roboczej.