Перейти к основному содержанию
Когда два правила могли бы оба совпасть с одним вызовом инструмента, приоритет правил firewall решает, какое побеждает. Политика firewall — это упорядоченный список правил — движок проходит их в порядке приоритета, останавливается на первом, которое совпало, и применяет его вердикт. Сделайте порядок правильным, и широкий страж плюс узкое исключение сосуществуют чисто; сделайте неправильно, и широкое правило проглотит исключение, которое вы хотели вырезать. Эта страница — сфокусированный справочник по упорядочиванию. О полной грамматике правил см. Правила Firewall; о вердиктах, которые может произвести правило, см. Вердикты.

​
1. Порядок: приоритет по возрастанию, побеждает первое совпадение

Внутри политики правила вычисляются в порядке priority ASC, id ASC:
  1. Меньший priority выполняется первым. Правило с priority: 0 проверяется до правила с priority: 10. Думайте об этом как о позиции в очереди, а не оценке силы — меньшее число получает слово первым.
  2. Ничьи разрешаются по id правила. Два правила с одним priority выполняются в порядке создания (возрастающий id правила), так что более старое правило побеждает в ничьей. Используйте разные приоритеты, когда порядок реально важен, а не полагайтесь на разрешение ничьи по id.
  3. Побеждает первое совпадение. Движок останавливается на первом правиле, чьи условия все держатся, и применяет его вердикт. Правила дальше по списку никогда не консультируются для этого вызова.
  4. Нет совпадения → default-вердикт. Если ничего не совпало, применяется default_verdict политики — audit, если вы его не изменили.
Правило совпадает, только когда каждое объявленное условие держится сразу: поверхность, глоб имени инструмента, опциональный глоб навыка, опциональные клаузы аргументов и область egress (только egress-правила). Частичное совпадение — не совпадение, и вычисление переходит к следующему правилу.

​
2. Один конкретный пример: конкретное перед широким

Каноническая задача упорядочивания — дать узкому allow пережить широкий deny. Поставьте конкретное правило на меньший приоритет, так чтобы оно достигалось первым: 
// Rule A — priority 10: trust this one exact tool.
{ "label": "allow safe shell", "priority": 10,
  "tool_name_glob": "shell.echo", "verdict": "allow" }

// Rule B — priority 20: block the rest of the shell family.
{ "label": "block shell family", "priority": 20,
  "tool_name_glob": "shell.*", "verdict": "deny" }
Вызов shell.echo попадает сначала на Rule A (priority 10), совпадает и разрешается — движок никогда не достигает Rule B. Вызов shell.exec проваливается через A (глоб не совпадает), попадает на Rule B и отклоняется. Переверните приоритеты, и широкий deny shell.* на priority 10 поймал бы shell.echo первым, а ваш allow на priority 20 был бы мёртвым кодом. Правило большого пальца: самое конкретное первым, самое широкое последним.
Не зависьте от разрешения ничьи по id для этого. Если allow и deny разделяют один priority, побеждает то правило, которое вы создали первым — хрупкое упорядочивание, которое молча переворачивается, если вы удаляете и пересоздаёте правило. Дайте конкретному правилу меньший priority, и намерение явно.

​
3. Проверьте порядок, прежде чем полагаться на него

Рассуждать о приоритете на бумаге чревато ошибками, как только в политике больше горстки правил. Песочница Test запускает реальный движок против образца вызова инструмента и говорит вам не только вердикт, но какое правило победило — так что вы можете подтвердить, что правило, которое вы ожидали, реально сработало:
1

Откройте вкладку Test политики

В консоли откройте политику и переключитесь на Test (Developer+).
2

Отправьте образец вызова

Введите имя инструмента (и аргументы, если ваши правила их инспектируют) и запустите. Ничего не диспетчеризуется и ничего не сохраняется — это прогон вхолостую.
3

Прочитайте совпавшее правило

Результат называет вердикт, совпавшее правило (по метке/id) и причину. Если широкое правило победило там, где вы ожидали узкое, понизьте priority узкого правила и протестируйте снова.
См. Тестирование правил о полной песочнице и Управление политиками о редактировании порядка правил на месте.

​
4. Применение навыка накладывается сверху

Приоритет правил решает вердикт побеждающего правила — но это не всегда финальный ответ. Если вызов инструмента принадлежит управляемому навыку, режим применения навыка накладывается поверх побеждающего вердикта, после разрешения first-match:
Режим навыкаЭффект на побеждающий вердикт
allowБез изменений — вердикт правила стоит.
quarantineЭскалирует всё, что меньше deny, до pending_approval; существующий deny оставляется как есть.
blockПринудительно даёт deny независимо от вердикта правила.
Так навык quarantine может превратить allow правила в удержанный вызов, а навык block отклоняет вызов, даже когда ни одно правило не называет его инструменты. Quarantine только эскалирует — он никогда не понижает deny до чего-то более мягкого. Вот почему навык, авто-детектированный как рискованный, остаётся в карантине, пока вы его не проверите, как бы разрешительны ни были ваши правила.
Режим навыка — не правило, так что у него нет priority, и вы не можете переупорядочить его относительно ваших правил. Он всегда вычисляется после выбора побеждающего вердикта. Если режим управляемого навыка блокирует вызовы, которые вы ожидали разрешить, исправьте это на навыке, а не добавлением allow-правила с более высоким приоритетом — правило не может переопределить режим.

​
5. Вещи, которые не идут по first-match

Несколько механизмов сидят вне per-rule прохода приоритета — знайте, где они приземляются, чтобы не пытаться их упорядочить:
Правило cap_cost под своим потолком трактуется как несовпадающее, так что вычисление продолжается к следующему правилу, а не позволяет ему победить first-match как разрешение. Над потолком оно разрешается в deny. Оно никогда не замыкает накоротко правило с меньшим приоритетом просто будучи достигнутым.
Правило последовательности совпадает с цепочкой вызовов в окне времени, так что оно применяется реактивно асинхронным сопоставителем, а не на единственном вызове, который завершает цепочку. Оно зажигает ленту событий, но не побеждает проход first-match для отдельного вызова.
Shadow-режим не меняет, какое правило побеждает — он понижает побеждающий применяющий вердикт до audit (причина с префиксом [shadow] would …) после разрешения first-match, так что вы можете измерить влияние политики до того, как она изменит трафик.

​
6. Собираем вместе

Для любого вызова инструмента полное разрешение такое:
  1. Разрешить политику — привязанную к вызывающему ключу или default рабочего пространства. См. область.
  2. Пройти правила в priority ASC, id ASC — побеждает первое совпадение; нет совпадения → default_verdict.
  3. Применить применение навыка — режим управляемого навыка накладывается поверх побеждающего вердикта (block принудительно даёт deny, quarantine эскалирует).
  4. Применить shadow-режим — если включён, понизить применяющие вердикты до audit.
  5. Записать событие — вердикт, поверхность, инструмент и совпавшее правило приземляются в ленте событий.
Редактирование приоритета правила вступает в силу на следующем вызове для каждого ключа, привязанного к политике — без передеплоя, без изменений в коде агента. Перезапустите песочницу Test после переупорядочивания, чтобы подтвердить нового победителя, прежде чем живой трафик от него зависит.

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

Вердикты

Что каждый побеждающий вердикт реально делает.

Синтаксис глобов

Как сопоставление имени инструмента решает, является ли правило вообще кандидатом.

Тестирование правил

Прогоните политику вхолостую и увидьте, какое правило побеждает.

Allow-листинг инструментов

Паттерн default-deny, который опирается на упорядочивание сильнее всего.
О языке сопоставления за правилом см. полный справочник Правил Firewall; о том, как навыки наслаиваются сверху, см. Навыки Firewall и режимы применения.