Настройки безопасности и маскирования

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

IAM.Secure отделяет обнаружение, действие политики, замену найденных значений и доставку событий. Настройки этих механизмов независимы. Изменять политику и интеграции может только роль с соответствующими правами на tenant; редакция продукта дополнительно ограничивает некоторые возможности.

Где включать и отключать механизмы

Единого клиентского переключателя «выключить весь анализ трафика» в этих разделах нет. Для проверки решения без блокировки используйте целевое действие flag в узком scope и убедитесь, что более строгая активная политика не переопределяет его. Это изменение защитного действия, а не отключение детектора.

Создать, включить, приостановить и настроить политику

1. Политики → Новая политика. Укажите уникальный ID, название, владельца, описание и статус Черновик.
2. Выберите конкретный tenant, не *. Hosted-версия отклоняет непустые scope.apps и scope.groups с HTTP 422: эти границы ещё не поддерживаются. Для изоляции используйте отдельный tenant.
3. Добавить правило → Тип условия → Значение условия → Действие. Укажите заметку. Стрелками разместите более конкретное правило раньше общего.
4. Для составных условий, point и канонических действий откройте JSON. Сохраните документ, проверьте его чтением обратно и тестом учебного текста.
5. Только после проверки переведите статус в Активна. Для прекращения исполнения конкретной политики — Поставить на паузу. Проверяйте результат в аудите.

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

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. Сохранённое состояние автоматически читается всеми репликами из общего хранилища.

Совместимость формы и JSON. Некоторые версии визуального редактора записывают blocked / masked / rerouted / flagged / allowed, а валидатор шлюза принимает block / mask / reroute / flag / allow. При 422 используйте канонические значения в JSON; отвергнутая форма не считается сохранённой политикой. Простая форма представляет одно условие на правило: для нескольких условий и point оставайтесь в JSON, иначе часть условий может потеряться при преобразовании.

Как разрешаются несколько правил

В одной политике выигрывает первое совпадение сверху вниз. Среди всех подходящих активных политик применяется самое строгое действие: allow < flag < mask < reroute < block. Условия одного when должны выполняться вместе. Если ни одно правило не совпало и инспекция доступна, результат — allow; поэтому проверяйте полное покрытие нужного scope. При отказе инспекции действует block, даже если доступен on-prem: непроверенный запрос не отправляется ни в один upstream. Если инспекция успешна, но mask невозможен, действие повышается до reroute при доступном on-prem, иначе block.

Проверить текстовое вложение в интеграции

Для вызова API нужен inference key вашего tenant; просмотр аудита и оригинала требует отдельных административных прав. Передайте текстовый файл через OpenAI file.file_data / input_file.file_data либо SDK document.source с type=base64 и media_type=text/plain. Поддерживаются текстовые MIME, JSON, XML, JavaScript и YAML; для raw base64 file_data укажите filename с поддерживаемым расширением. Это контракт интеграции; новая кнопка загрузки в консоли не добавляется.

{"messages":[{"role":"user","content":[{"type":"file","file":{"filename":"example.txt","file_data":"data:text/plain;base64,aGVsbG8="}}]}],"point":"attachment","context":"chat"}

1. На staging отправьте этот учебный объект в /v1/inspect, используя свой inference key. Содержимое файла hello декодируется до классификации; итоговое действие зависит от активных политик.
2. Повторите проверку с учебными приватными данными и injection внутри файла. Проверьте decision, verdict.point и Request ID в Аудит и форензика. Inspect проверяет решение, но не вызывает генерацию ответа провайдера.
3. Для разрешённого вызова /v1/chat/completions шлюз сохраняет исходные encoded bytes при отправке провайдеру. Streaming-ответ с data URL/JSON удерживается до полной проверки; обычный текст продолжает проверяться окнами.
4. Некорректная кодировка, превышение лимита, неподдерживаемый бинарный файл или документ через file_id, file_url / source.url дают fail-closed block. Исправьте данные или передайте поддерживаемый текстовый экспорт; не повторяйте недоступную ссылку как способ обхода проверки.

Извлечение ограничено 64 MiB суммарно декодированных данных и глубиной восьми вложенных кодировок. Удерживаемые SSE frames ограничены 96 MiB; превышение блокирует поток без частичной выдачи вложения. PDF/DOCX, OCR, расшифровка аудио и загрузка удалённого документа этим текстовым контрактом не подтверждаются. Сохранение SDK media fields при пересылке не означает анализ содержимого изображения или аудио.

Для декодированного текста span_basis=extracted_text: spans относятся к извлечённому содержимому. Пока исходный формат не поддерживает безопасное переписывание, такой вердикт не является maskable; API маскирования с запросом реальной замены возвращает ошибку вместо успешного ответа с неизменённым секретом. Проверьте причину блокировки/маршрутизации в аудите; успешное извлечение само по себе не обещает allow или reversible FPE.

Пример: маскировать email в запросах отдельного учебного tenant

Создайте черновик; имя класса возьмите из реального вердикта вашего реестра.

{
  "id": "DOCS-EMAIL",
  "name": "Mask email in support requests",
  "status": "draft",
  "owner": "secops",
  "description": "Educational policy; activate only after scoped checks",
  "scope": {"tenant": "docs-demo", "groups": [], "apps": []},
  "on_inspection_unavailable": "fail_closed",
  "block_message": "Request blocked by organization policy",
  "rules": [
    {"id": "INJECTION", "when": {"injection_detected": true}, "then": "block"},
    {"id": "EMAIL", "when": {"data_class": "pii.email", "point": "request"}, "then": "mask"}
  ]
}

Для проверки отправьте учебный email, чистый текст и injection с нужными tenant/app/point; дополнительно проверьте другую организацию, ответ модели и вывод инструмента. Draft не исполняется: используйте предусмотренную симуляцию или активируйте только на тестовом tenant staging. Простой инспектор показывает решение действующих политик, а не автоматически открытого черновика.

Наблюдать без блокировки

В целевом правиле замените block на flag, сохраняя условия и узкую область применения. flag пропускает текст и отмечает событие. Наличие другого правила block в активной политике всё равно блокирует запрос. Проверьте policy_id и rule_id победившего решения. Для отмены восстановите предыдущий документ / версию и повторите проверку.

Настроить маскирование

1. Маскирование → Автообнаружение / Только классы вердикта.
2. Нажмите Сохранить, затем Обновить и проверьте возвращённый режим.
3. Протестируйте замену на учебных данных через реально подключённый защищаемый поток, а не только внешний вид переключателя.

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

1 2 3 4

1. Обновить
2. Автообнаружение
3. Только классы вердикта
4. Сохранить

Router имеет дополнительный floor. Не переносите его автоматически на standalone Secure: это разные административные контракты. Hosted-версия сохраняет режим в общем Redis без TTL; перезапуск gateway и смена реплики его не сбрасывают. settings_backend=redis означает общее хранилище настроек; memory — только память процесса. Потеря Redis и резервное копирование остаются отдельной ответственностью оператора.

Custom DLP: добавить или изменить свой детектор

1. Убедитесь, что редакция разрешает Custom DLP и у вас есть административные права.
2. Передайте оператору JSON с массивом patterns: стабильный id, имя name, категория check, severity и regex / keywords. Файл подключается через IAM_SEC_CUSTOM_DLP_PATH.
3. Custom DLP → Перезагрузить, проверьте число загруженных паттернов. Экран не содержит редактора самого файла.
4. В Проверить используйте положительный и отрицательный учебные примеры; затем создайте правило по ID обнаруженного класса и проверьте финальное действие.
5. Для удаления детектора обновите файл и перечитайте его; проверьте политики, которые ссылались на этот ID. Выключение одного детектора не выключает остальные классы DLP.

Готовый файл и проверка совпадений

{
  "patterns": [
    {"id": "org.customer_id", "name": "Учебный номер клиента", "check": "dlp", "severity": "high", "regex": "\\bDOCS-CUST-[0-9]{6}\\b"},
    {"id": "org.project_name", "name": "Учебный код проекта", "check": "dlp", "severity": "medium", "keywords": ["DOCS-PROJECT-ORION"]}
  ]
}

Отдельных type, pattern и sensitivity в этом файловом контракте нет. Чувствительность в условии политики относится к вердикту инспекции, а не к произвольному полю custom-файла. Детекторы текущей версии общие для шлюза, не изолированы верхним tenant-фильтром; ограничивайте действие политики через её scope.

В Custom DLP → Проверить введите DOCS-CUST-123456: ожидайте org.customer_id в matched. Для DOCS-CUST-12345 совпадения нет. docs-project-orion должен находиться без учёта регистра; DOCS-PROJECT-OTHER — нет. Проверка возвращает совпадения и masked_text, но не исполняет все активные политики: отдельно проверьте итоговое решение защищённого запроса. Если «Перезагрузить» вернул reload_failed / 400, продолжает работать предыдущий успешно загруженный набор; исправьте файл и повторите чтение/проверку. 404 not_configured означает, что оператор не подключил путь.

Оповещения, коррелятор, webhook и SIEM

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

1 2 3 4

1. Тенант
2. Событие
3. Порог / окно / cooldown
4. Сохранить

Настроить коррелятор инцидентов

1. Откройте Инциденты → Коррелятор → Настроить. Если панель отсутствует, проверьте доступность API коррелятора: это не доказательство выключенного анализа.
2. Запишите прежние значения, измените нужные поля и нажмите Применить. Отмена сбрасывает несохранённый редактор.
3. Перечитайте панель и сравните значения. Проверьте события тестового tenant, окно времени и созданный инцидент; новое решение обработки запроса этим не задаётся.

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

1 2 3 4 5

1. Порог инъекций
2. Порог DLP
3. Доля блокировок
4. Окно, секунды
5. Применить

API: GET /admin/incidents/correlation-config, затем PATCH по тому же адресу с административным правом записи и телом ниже; повторный GET возвращает окно строкой 10m0s, а не window_seconds.

{"injection_burst": 3, "dlp_burst": 15, "block_rate_min_reqs": 10, "block_rate_threshold": 0.5, "window_seconds": 600}

Это учебный пример исходных значений, не настройка вашего стенда. PATCH меняет только переданные поля; tick_interval не изменяется этим запросом. 422 — нарушен диапазон; 503 — коррелятор недоступен. Изменение runtime не обещает сохранение после рестарта или распространение на другие реплики: перечитайте значения на затронутом экземпляре. Для возврата примените прежние параметры и проверьте следующий проход. Коррелятор читает до 2000 последних записей в окне; на большом потоке его выборка не равна полной статистике всей организации. Нулём эти пороги не выключаются; выключение уведомления задаётся отдельным правилом Alert Rules.

Подключить SIEM

1. Получите от администратора SIEM адрес и требуемый формат.
2. SIEM → Endpoint URL → Формат событий → Включить SIEM экспорт → Сохранить.
3. Токен получателя настраивает оператор через IAM_SEC_SIEM_WEBHOOK_AUTH; интерфейс не показывает его. Не вставляйте токен в опубликованный URL.
4. Выполните Тестовая доставка только в согласованный получатель. Проверьте статус и событие на стороне SIEM.
5. Для отключения снимите переключатель и сохраните; проверьте статус «Отключён». Анализ и локальный аудит продолжаются.

Сервисные параметры и хранилища

Значения ниже — исходные defaults, не утверждение о текущем hosted-стенде. Изменяет оператор; клиент запрашивает нужное значение и проверяет его через доступный контракт.

Все разделы приложения · Анализ трафика · 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 и обезличенный пример; не ослабляйте глобальную защиту ради зелёного теста.

Доступ шлюза к PostgreSQL

Для администратора self-hosted-контура. В hosted-версии клиент не получает доступ к БД: ключи приложения и роль оператора консоли не являются учётной записью PostgreSQL. Для настройки политик используйте консоль выше.

У роли шлюза отключены SUPERUSER, CREATEROLE, CREATEDB, REPLICATION и BYPASSRLS. Запрещены изменение схемы, DROP/TRUNCATE, отключение триггеров, серверные команды и чтение файлов сервера. Это не заменяет изоляцию tenant на уровне приложения и не делает аудит неизменяемым: штатное удаление аудита по сроку хранения остаётся разрешено.

1. До ограничения прав сделайте согласованную резервную копию и восстановите её в отдельной БД. Сохраните параметры аутентификации и роли отдельно от публичной документации.
2. Установите схему административной ролью. Для работающего шлюза задайте IAM_DB_SCHEMA_MODE=verify: запуск проверяет схему без CREATE/ALTER. Ошибки миграции исправляйте через администратора, без выдачи SUPERUSER шлюзу.
3. Разделите владельца, рабочую роль и резервное копирование. В существующей установке сохраните пароль DSN; не подменяйте его паролем администратора. Для дампов необходим SELECT последовательностей, который не нужен шлюзу.
4. Перезапустите реплики gateway последовательно. Убедитесь, что все физические подключения прежней привилегированной роли закрыты; смена флагов роли сама по себе не завершает старые подключения.
5. Проверьте создание, ротацию и отзыв тестового ключа, сохранение политики, Активировать → Поставить на паузу, аудит/инциденты, сохранённый поиск и восстановление из резервной копии. Удалите временные ключи; не очищайте клиентские таблицы для теста.

Если после обновления не сохраняются настройки. Проверьте режим verify, доступ к нужной БД и точечные DML-права по журналу ошибки. Для ключей нужен UPDATE(version, updated_at) таблицы версии кэша: его вызывает триггер. Для архива оригиналов нужен UPDATE(ciphertext, status), для истории — INSERT и USAGE выделяющей последовательности. Исправляйте конкретное разрешение и повторяйте сценарий на staging. Не включайте режим migrate в рабочем gateway с ограниченной ролью.