Przejdź do głównej treści
Napisałeś politykę firewalla — postawę default-deny, deny na shell.exec, listę dozwolonych egress — i wierzysz, że jest poprawna. Ale przełączenie jej na ruch agentów na produkcji to skok wiary: jedna zbyt szeroka reguła i blokujesz wywołania, które twoje agenty legalnie robią. Tryb cienia firewalla to przełącznik bezpiecznego wdrożenia. To flaga per polityka, która mówi bramie, by ewaluowała politykę dokładnie tak, jak robiłaby to na produkcji, logowała wszystko, ale niczego nie blokowała. Każdy egzekwujący werdykt jest degradowany do audit, a powód zdarzenia jest poprzedzony przedrostkiem [shadow] would …, więc możesz odczytać dokładnie, co polityka zrobiłaby — nim cokolwiek zrobiła.
Tryb cienia to flaga na polityce, ustawiana w konsoli (lub na trasach zarządzania /api/workspace/firewall/policies, które używają twojej sesji / tokenu dostępu — nie klucza relay sk-orca-…). Przełączanie go to akcja Developer+. Wywołania relay /v1/* twojego agenta się nie zmieniają.

​
1. Co robi tryb cienia firewalla

Gdy flaga shadow_mode polityki jest włączona, brama uruchamia pełną ewaluację — rozwiązuje politykę, przechodzi reguły w kolejności priorytetów, wybiera werdykt — a potem, tuż przed wejściem werdyktu w życie, degraduje wszystko, co zmieniłoby wywołanie:
Rozwiązany werdyktW trybie cienia
deny→ audit, powód [shadow] would deny — …
sanitize→ audit, powód [shadow] would sanitize — …
pending_approval→ audit, powód [shadow] would pending_approval — …
allow / auditbez zmian (już nieblokujące)
Wywołanie zawsze przechodzi. Nic nie jest blokowane, żadne argumenty nie są redagowane, żadne wstrzymanie człowieka nie jest otwierane — ale zdarzenie jest rejestrowane z werdyktem, który polityka wyprodukowałaby, więc strumień zdarzeń czyta się jak uruchomienie produkcyjne z wyłączonym egzekwowaniem.
Przedrostek [shadow] would … to twój nagłówkowy filtr. Posortuj strumień zdarzeń po nim, a masz kompletną listę każdego wywołania, które ta polityka zaraz zacznie blokować, zanim zablokuje choć jedno.

​
2. Jedno konkretne wdrożenie

Powiedzmy, że masz politykę prod-agents z regułą deny na destrukcyjnych poleceniach shella i chcesz potwierdzić, że nie zadziała na niczym legalnym.
1

Włącz tryb cienia

W Security → Firewall → Policies otwórz prod-agents, przełącz Shadow mode na włączone i zapisz. Polityka zachowuje swoje powiązanie i reguły — po prostu przestaje egzekwować.
2

Pozwól płynąć prawdziwemu ruchowi

Twoje agenty dalej wołają bramę dokładnie jak wcześniej. Każde wywołanie narzędzia jest ewaluowane; nic nie jest blokowane. Daj temu reprezentatywne okno — wystarczająco długie, by pokryć twój prawdziwy miks narzędzi.
3

Odczytaj przyszłe odmowy

Otwórz Events i filtruj po powodzie [shadow]. Każdy wiersz pokazuje narzędzie, powierzchnię, uruchomienie i regułę, która dopasowała — więc [shadow] would deny — destructive shell command na wywołaniu shell.exec to dokładnie to, co zobaczyłbyś na produkcji, minus HTTP 400.
4

Wyłącz tryb cienia

Gdy strumień pokazuje, że polityka odpala na tym, czego oczekujesz, i niczym, czego nie chcesz, przełącz Shadow mode na wyłączone. Od następnego wywołania te zdarzenia [shadow] would deny stają się prawdziwymi odmowami firewall_blocked.
Jeśli tryb cienia ujawnił fałszywie pozytywny przypadek — legalne wywołanie, które dopasowało regułę deny — napraw regułę (zacieśnij glob lub dodaj klauzulę argumentu), wciąż będąc w trybie cienia, i obserwuj strumień ponownie. Iterujesz na prawdziwym ruchu z zerowym promieniem rażenia.

​
3. Czego tryb cienia nie łagodzi

Tryb cienia to podgląd polityki, nie główny wyłącznik.
Zarządzane skille wciąż egzekwują pod polityką w cieniu. Skill w trybie block wciąż odmawia, a skill w trybie quarantine wciąż wstrzymuje do zatwierdzenia, nawet gdy dopasowana polityka jest w cieniu. Tryb egzekwowania skilla to właściwość stanu przeglądu skilla, nie polityki, którą podglądasz — wprowadzenie polityki w cień nigdy nie było żądaniem zniesienia kwarantanny skilla. Polityka pozostaje oznaczona jako w cieniu w zdarzeniach, ale dyspozycja skilla wygrywa.
Kilka kolejnych granic wartych poznania:
Tylko egzekwujące werdykty (deny, sanitize, pending_approval) są degradowane. allow lub audit i tak przepuszcza wywołanie, więc nie ma czego łagodzić — te zdarzenia wciąż niosą plakietkę cienia, byś mógł powiedzieć, że polityka była w cieniu, gdy je zarejestrowano.
Reguła cap_cost rozwiązuje się do konkretnego allow lub deny na podstawie zakumulowanych wydatków uruchomienia, i ten rozwiązany werdykt jest tym, co tryb cienia potem degraduje — przyszła odmowa przekroczenia limitu pojawia się jako [shadow] would deny jak każda inna.
Tryb cienia żyje na każdej polityce niezależnie. Możesz wprowadzić w cień zupełnie nową politykę, gdy sprawdzona w boju dalej egzekwuje — nie ma ogólnoprzestrzennego przełącznika cienia, który zapomniałbyś wyłączyć.

​
4. Tryb cienia a inne pokrętła wdrożenia

Firewall daje ci trzy różne kontrolki „nie psuj jeszcze niczego”. Rozwiązują różne problemy:
KontrolkaZakresPytanie, na które odpowiada
Tryb cieniaJedna polityka„Co ta polityka zablokowałaby, gdybym ją egzekwował?”
Werdykt domyślny auditJedna polityka„Loguj wszystko, czego żadna reguła nie nazywa, nie blokuj nic.”
Tryb obserwacjiPrzestrzeń robocza„Które narzędzia działają, gdy żadna polityka ich nie pokrywa?”
Tryb cienia to ten, po który sięgasz, gdy masz prawdziwą, egzekwującą politykę i chcesz zmierzyć jej dokładny wpływ, zanim zmieni ruch. Werdykt domyślny audit jest dla niedopasowanego ogona jednej polityki; tryb obserwacji dotyczy luk w pokryciu w całej przestrzeni roboczej, nie egzekwowania konkretnej polityki.
Możesz je stosować jednocześnie. Nowa polityka default-deny w trybie cienia to najłagodniejsze możliwe wdrożenie: nawet podłoga default-deny tylko loguje [shadow] would deny zamiast blokować, więc widzisz pełny zestaw wywołań, których twoje reguły allow jeszcze nie pokrywają, zanim deny będzie na żywo.

​
5. Pakiety zgodności lądują najpierw w cieniu

Gdy instalujesz pakiet zgodności w trybie obserwacji (nieegzekwującym), polityki firewalla, które materializuje, są tworzone z trybem cienia włączonym — ewaluują i logują wobec twojego ruchu bez blokowania czegokolwiek. Promowanie pakietu do egzekwowania przełącza te polityki poza cień. Ten sam mechanizm, zastosowany za ciebie: zrób dry-run kontroli, odczytaj przyszłe werdykty, potem egzekwuj.

​
6. Przełączanie

W konsoli tryb cienia to przełącznik w edytorze polityki. Ta sama flaga jest wystawiona na API zarządzania jako shadow_mode na obiekcie polityki — te trasy używają twojego tokenu sesji / dostępu i wymagają Developer+:
Metoda i ścieżkaRolaUwaga
PUT /api/workspace/firewall/policiesDeveloper+Ustaw shadow_mode: true / false na polityce w ciele.
GET /api/workspace/firewall/policies/:idMemberOdczytaj bieżący stan shadow_mode polityki.
Każda zmiana zapisuje wiersz audytu i podbija liczbę całkowitą version polityki, więc włączanie i wyłączanie cienia jest samo w sobie śledzone.

​
Dokąd dalej

Utwórz i przypnij politykę

Dwukrokowa konfiguracja, którą wytacza tryb cienia — utwórz politykę, przypnij klucz.

Log zdarzeń

Gdzie pojawia się [shadow] would … — filtruj, wgłębiaj się w uruchomienia i reguły.

Werdykty

Egzekwujące werdykty, które tryb cienia degraduje, i co każdy robi na żywo.

Tryby egzekwowania

Jak cień, audit i obserwacja pasują do szerszego modelu egzekwowania.
Dla zagrożeń, które polityka zatrzymuje, gdy wyłączysz cień, zobacz niebezpieczne wywołania narzędzi i nadmierną sprawczość.