Журнал аудита, хранение и выгрузка

Каждое действие ассистента записано: кто спросил, к какой базе, что было разрешено, замаскировано или заблокировано. Инциденты разбираются по записям журнала, а не по памяти.

Что попадает в журнал

• Каждый терминальный исход вызова инструмента записывается строкой mcp_tool_call: статус, длительность в миллисекундах, размер входа и, когда он есть, идентификатор токена.
• Каждый участник команды атрибутируется независимо: у него свои токены, и его действия видны в журнале отдельно.
• Маскирование персональных данных пишет собственные детальные записи: SHA256 оригинала, идентификатор правила, токен и инструмент.
• Отдельные события фиксируют решения политик, например включение небезопасной схемы подключения к 1С (onec.config.insecure_scheme) или явное разрешение внешнего git-зеркала (git_bridge.mirror.external_allowed).

Выгрузка CSV и JSONL

Журнал аудита и активность пользователей выгружаются потоково:

• GET /web/admin/audit/export: выгрузка журнала аудита;
• GET /web/admin/activity/export: выгрузка активности с агрегацией по пользователям.

Выгрузка отдаёт те же строки, что видны в текущем фильтре просмотра, в формате CSV или JSONL. Формат укреплён: UTF-8 BOM и нейтрализация формульных инъекций. Перед каждым экспортным endpoint стоит ограничитель 10 выгрузок в час на пользователя; доступ только у Owner и Admin.

Срок хранения

Автоматическая очистка старых записей аудита по умолчанию выключена и включается переменной TRUST_AUDIT_RETENTION_ENABLED. Свойства:

• записи удаляются ограниченными пакетами, чтобы не держать долгие блокировки в базе данных;
• граница окна исключающая, а минимальный срок хранения зафиксирован жёстким полом в 90 дней, поэтому ошибка настройки не удалит свежие записи;
• удаление необратимо, и автоматическая выгрузка перед удалением не выполняется: решение о предварительной выгрузке принимает владелец (в том числе по требованиям юристов), см. выгрузку выше.

Аудит ролей и RLS

Детерминированный отчёт о безопасности ролей, прав и RLS строится поверх полного дампа конфигурации и доступен под правом просмотра аудита. Разбираются Roles/<Имя>.xml и Ext/Rights.xml в матрицу прав по ролям и текст RLS-ограничений; находки формируются набором правил D1..D7.

Ядро защиты от ложных тревог: правило о пропущенном RLS помечает не отсутствие RLS вообще, а отклонение от паттерна самой конфигурации (config-relative). Отчёт готовит фоновый воркер; у кого нет права, у того отчёт не появляется вовсе.

Дополнительно:

• опциональный слой семантики RLS на локальной (on-prem) LLM выключен по умолчанию; его находки советующие и в счётчики критичного не входят;
• при код-ревью запроса на слияние отдельный класс правил аудитирует изменённые роли поверх гейта качества.