Перейти к основному содержанию
Вы написали политику firewall — позицию default-deny, deny на shell.exec, egress allow-list — и считаете, что она верна. Но включение её против production-трафика агентов — прыжок веры: одно слишком широкое правило, и вы блокируете вызовы, которые ваши агенты делают законно. Shadow-режим firewall — это переключатель безопасного развёртывания. Это флаг на уровне политики, который говорит шлюзу вычислять политику ровно так, как она работала бы в production, логировать всё, но не блокировать ничего. Каждый применяющий вердикт понижается до audit, а причина события получает префикс [shadow] would …, так что вы можете точно прочитать, что политика сделала бы, — без того, чтобы она что-либо уже сделала.
Shadow-режим — это флаг на политике, устанавливаемый в консоли (или через управляющие маршруты /api/workspace/firewall/policies, которые используют вашу сессию / access-токен — не ретрансляционный ключ sk-orca-…). Переключение его — действие Developer+. Ваши вызовы агента /v1/* через ретрансляцию не меняются.

​
1. Что делает shadow-режим firewall

Когда флаг shadow_mode политики включён, шлюз выполняет полное вычисление — разрешает политику, проходит правила в порядке приоритета, выбирает вердикт — и затем, прямо перед тем, как вердикт вступит в силу, понижает всё, что изменило бы вызов:
Разрешённый вердиктВ shadow-режиме
deny→ audit, причина [shadow] would deny — …
sanitize→ audit, причина [shadow] would sanitize — …
pending_approval→ audit, причина [shadow] would pending_approval — …
allow / auditбез изменений (уже неблокирующие)
Вызов всегда проходит. Ничего не блокируется, никакие аргументы не редактируются, никакое удержание для человека не открывается — но событие записывается с вердиктом, который политика произвела бы, так что лента событий читается как production-прогон с выключенным применением.
Префикс [shadow] would … — ваш главный фильтр. Отсортируйте ленту событий по нему, и у вас будет полный список каждого вызова, который эта политика вот-вот начнёт блокировать, до того как она заблокирует хоть один.

​
2. Один конкретный сценарий развёртывания

Допустим, у вас есть политика prod-agents с правилом deny на деструктивные shell-команды, и вы хотите подтвердить, что она не сработает ни на чём законном.
1

Включите shadow-режим

В Security → Firewall → Policies откройте prod-agents, переключите Shadow mode в положение «вкл» и сохраните. Политика сохраняет свою привязку и свои правила — она просто перестаёт применять.
2

Дайте реальному трафику течь

Ваши агенты продолжают вызывать шлюз ровно как раньше. Каждый вызов инструмента вычисляется; ничего не блокируется. Дайте этому репрезентативное окно — достаточно длинное, чтобы покрыть ваш реальный набор инструментов.
3

Прочитайте потенциальные отказы

Откройте Events и отфильтруйте по причине [shadow]. Каждая строка показывает инструмент, поверхность, прогон и правило, которое совпало, — так что [shadow] would deny — destructive shell command на вызове shell.exec — это ровно то, что вы увидели бы в production, минус HTTP 400.
4

Выключите shadow-режим

Как только лента покажет, что политика срабатывает на том, что вы ожидаете, и ни на чём, чего не ожидаете, переключите Shadow mode в «выкл». С следующего вызова те события [shadow] would deny станут реальными отказами firewall_blocked.
Если shadow-режим всё-таки выявил ложное срабатывание — законный вызов, совпавший с правилом deny, — исправьте правило (ужесточите глоб или добавьте клаузу аргумента), оставаясь в shadow, и снова понаблюдайте за лентой. Вы итерируете против реального трафика с нулевым радиусом поражения.

​
3. Что shadow-режим не смягчает

Shadow-режим — это предпросмотр политики, а не главный выключатель.
Управляемые навыки всё равно применяются под shadow-политикой. Навык в режиме block всё равно отказывает, а навык в режиме quarantine всё равно удерживает для подтверждения, даже когда совпавшая политика в shadow. Режим применения навыка — это свойство состояния разбора навыка, а не политики, которую вы предпросматриваете — shadow для политики никогда не был запросом снять навык с карантина. Политика остаётся помеченной как shadowed в событиях, но решение навыка побеждает.
Ещё несколько границ, которые стоит знать:
Понижаются только применяющие вердикты (deny, sanitize, pending_approval). allow или audit уже пропускают вызов, так что смягчать нечего — те события всё равно несут shadow-метку, так что вы можете сказать, что политика была в shadow, когда они записывались.
Правило cap_cost разрешается в конкретный allow или deny на основе накопленных трат прогона, и этот разрешённый вердикт затем понижает shadow-режим — потенциальный отказ по cap-trip показывается как [shadow] would deny, как любой другой.
Shadow-режим живёт на каждой политике независимо. Вы можете держать в shadow совершенно новую политику, пока обкатанная продолжает применять — нет общего для рабочего пространства shadow-переключателя, который можно забыть выключить.

​
4. Shadow-режим против остальных регуляторов развёртывания

Firewall даёт вам три разных контроля «не сломай пока ничего». Они решают разные проблемы:
КонтрольОбластьВопрос, на который он отвечает
Shadow-режимОдна политика«Что заблокировала бы эта политика, если бы я её применял?»
Default-вердикт auditОдна политика«Логировать всё, что не названо ни одним правилом, не блокировать ничего.»
Observe-режимРабочее пространство«Какие инструменты работают, не покрытые ни одной политикой?»
Shadow-режим — это то, за чем тянуться, когда у вас есть реальная, применяющая политика и вы хотите измерить её точное влияние до того, как она изменит трафик. Default-вердикт audit — для несовпавшего хвоста одной политики; observe-режим — о пробелах покрытия по рабочему пространству, а не о применении конкретной политики.
Их можно складывать. Новая политика default-deny под shadow-режимом — самое мягкое возможное развёртывание: даже пол default-deny только логирует [shadow] would deny вместо блокировки, так что вы видите полный набор вызовов, которые ваши allow-правила ещё не покрывают, до того как deny станет живым.

​
5. Комплаенс-паки приземляются сначала в shadow

Когда вы устанавливаете комплаенс-пак в observe (неприменяющем) режиме, политики firewall, которые он материализует, создаются с включённым shadow-режимом — они вычисляют и логируют против вашего трафика, ничего не блокируя. Продвижение пака к применению выводит эти политики из shadow. Тот же механизм, применённый за вас: прогон контролей вхолостую, чтение потенциальных вердиктов, затем применение.

​
6. Переключение

В консоли shadow-режим — это переключатель в редакторе политики. Тот же флаг выставлен на управляющем API как shadow_mode на объекте политики — эти маршруты используют вашу сессию / access-токен и требуют Developer+:
Метод и путьРольПримечание
PUT /api/workspace/firewall/policiesDeveloper+Установить shadow_mode: true / false на политике в теле.
GET /api/workspace/firewall/policies/:idMemberПрочитать текущее состояние shadow_mode политики.
Каждое изменение пишет строку аудита и увеличивает целочисленный version политики, так что включение и выключение shadow само по себе отслеживается.

​
Куда двигаться дальше

Создать и привязать политику

Двухшаговая настройка, которую разворачивает shadow-режим — создать политику, привязать ключ.

Журнал событий

Где появляется [shadow] would … — фильтруйте, углубляйтесь в прогоны и правила.

Вердикты

Применяющие вердикты, которые понижает shadow-режим, и что каждый делает вживую.

Режимы применения

Как shadow, audit и observe вписываются в более широкую модель применения.
Об угрозах, которые политика останавливает, как только вы выключите shadow, см. опасные вызовы инструментов и избыточную автономию.