Подготовить и включить политику для тенанта

Роль: администратор контура. Эти действия выполняются в операторской консоли. В обычном hosted-кабинете доступны собственные ключи и лимиты; изменение политик, режима защиты и маскирования запрашивается у администратора.

Перед началом

Нужно право изменять политики и согласованные условия защиты. Создание черновика и включение enforcement — разные действия.

Что нажимать

1. Откройте Политики (/policies) → Новая политика.
2. Укажите уникальный ID, Название, Владелец и описание. Оставьте Статус: Черновик на время подготовки.
3. В Тенант укажите конкретную организацию. Значение * охватывает все тенанты. Непустые groups/apps не поддерживаются и отклоняются с 422. Для изоляции используйте конкретный tenant.
4. В строке правила выберите Тип условия, Значение условия и Действие. Пример для согласованной политики: «Чувствительность → RESTRICTED → Заблокировать».
5. Нажмите Добавить правило, если требуется ещё правило, и проверьте порядок. Откройте JSON и проверьте каноническое значение then (block, а не blocked), затем Создать политику. Неподдерживаемые значения формы шлюз отклоняет с 422. Составные условия и point сохраняйте в JSON.
6. Откройте созданную карточку → Редактировать документ, проверьте scope и переведите статус в активный, когда проверка согласована.
7. Выполните контрольную инспекцию и откройте Аудит и форензика либо кнопку Аудит в карточке политики.

Увеличить скриншот

1 2 3 4 5 6

1. Проверить все условия
2. Статус
3. Тенант
4. true / false
5. Действие
6. Сохранить политику

Редактор и сервер опубликованы 15.10.2026. Каноническое действие block, ID правила и дополнительные условия сохраняются при JSON → Форма → JSON. Для injection_detected и provider_unlisted форма показывает и позволяет выбрать true либо false; значение false больше не изображается как RESTRICTED. Составные условия, включая point, проверяйте в JSON. Неподдерживаемые groups/apps отключены с пояснением и отвергаются сервером с 422; используйте конкретный tenant. Сохранённое состояние автоматически читается всеми репликами из общего хранилища.

Как проверить результат

Черновик сохранён с вашим ID и scope. После активации тестовый запрос показывает ожидаемое действие и соответствующий идентификатор политики. Сохранённый черновик сам по себе не доказывает enforcement.

Если не получилось

Если после создания карточка есть в списке, но Редактировать документ возвращает 404, нажмите Отмена. Не сохраняйте подставленную пустую форму: в ней может снова стоять Тенант: *, что изменит область защиты. Передайте оператору ID политики и время ошибки; он должен проверить чтение документа и согласованность всех реплик. До успешного чтения и контрольного запроса активация не подтверждена.

Для первого включения черновика используйте Активировать в карточке либо Редактировать документ → Статус: Активна → Сохранить политику. Для временного исключения — Поставить на паузу, для возврата — Активировать. После каждого действия перечитайте документ и выполните новый запрос тем же ключом.

409 при сохранении требует сверить актуальный документ. Не меняйте scope на *, чтобы обойти отсутствие доступа. Если чистый запрос блокируется, проверьте условия и порядок правил на тестовых данных.

Все поля политики и совместимость JSON · FAQ

Согласованность реплик после сохранения

В hosted-версии, выпущенной 15.10.2026, политики сохраняются в общем PostgreSQL. Реплики перечитывают сохранённые overrides при чтении и перед принятием нового решения. После Сохранить политику, Активировать и Поставить на паузу отдельный ручной reload каждой реплики не требуется.

1. Сохраните исходный JSON, ID и конкретный tenant. Создавайте и проверяйте изменения сначала как Черновик на staging.
2. Сохраните документ, перечитайте GET /admin/policies/{id}?format=document и сравните scope, status, ID правил и все условия. Переход JSON → форма → JSON не должен терять point или явно заданный false.
3. Включите тестовую политику и выполните новый /v1/inspect своим клиентским ключом. Сверьте decision.action, policy_id, rule_id и Request ID. Администратор проверяет тот же документ и запрос через каждую обслуживающую реплику.
4. Поставить на паузу исключает только эту политику. Другие активные правила продолжают действовать, поэтому результат не обязан стать allow. Для возврата нажмите Активировать.
5. При откате восстановите исходный документ или нужную версию и повторите чтение и контрольный запрос. Файловую базовую политику нельзя удалить через API: для временного исключения используйте паузу.

При недоступности общего хранилища запись не подтверждается как успешная; инспекция с непрочитанным актуальным набором политик блокируется. Не исправляйте ошибку хранилища изменением scope на * или ослаблением правил. В старых self-hosted версиях возможен прежний ручной reload; сначала уточните версию gateway у оператора.

Проверка общего staging выполнила сохранение через операторский редактор и active → block → paused → другое действующее правило → active на обеих репликах без reload. На отдельном изолированном staging заменены обе реплики; политика и выбранный режим сохранились.

Что подтверждено на работающем стенде

• Штатный SSO клиента, создание ключа, сохранение списка после reload, реальный API-запрос, отзыв и HTTP 401 старого ключа.
• Изменение лимитов клиента, чтение после полной перезагрузки, приостановка входа и восстановление — клиентский кабинет.
• Сохранение и переключение тестовой политики с контролем каждой реплики. Tenant-граница проверена; app-граница не исполнялась.
• Маскирование: общий контур сохраняет режим в Redis и перечитывает его между репликами. На отдельном реальном staging со своими PostgreSQL/Redis проверены UI-сохранение auto → verdict_classes → auto, сохранность после замены обоих pod, замена синтетического email на [CONTACT] у тестового получателя и отсутствие вызова получателя при block. Этот серверный механизм выпущен в hosted production. Приёмка не является проверкой всех классов замен или гарантией сохранности Redis после потери самого хранилища.

На безопасном вопросе о столице Франции /v1/inspect вернул HTTP 200, CONFIDENTIAL и reroute по другой политике. Это ложноположительная классификация, а не доказательство наличия секретов или успешной генерации ответа. Передайте оператору Request ID и обезличенный пример; не ослабляйте глобальную защиту ради зелёного теста.