Журналы аудита
Журналы аудита фиксируют каждое действие, меняющее состояние в вашей организации, — назначения ролей, правки движка, выпуск API-ключей, изменения в биллинге — и показывают их в виде временной шкалы с поиском и фильтрами. Доступно на тарифе Enterprise вместе с Ролями и разрешениями.
Журнал устроен по принципу append-only на уровне базы данных: подключение приложения не может изменять, удалять или очищать строки аудита. Что записано, то уже не переписать.
Что записывается#
Для каждого события фиксируются инициатор, действие, объект и HTTP-контекст, в котором пришел запрос.
| Поле | Примечания |
|---|---|
| Инициатор | Пользователь или API-ключ, выполнивший действие |
| Действие | Типизированное значение вроде engine.created или member.role_changed |
| Объект | Сущность, которую затронуло действие, например движок, роль или элемент глоссария |
| Метаданные | ID связанных сущностей — без имен, email-адресов и фрагментов содержимого |
| Контекст запроса | request_id, IP-адрес, user agent — фиксируются, когда запрос приходит по HTTP |
| Метка времени | UTC, плюс монотонный порядковый номер для обнаружения пропусков |
Только ID — так и задумано
В столбце метаданных хранятся ID, а не человекочитаемые значения. При чтении интерфейс подтягивает актуальные имена, поэтому переименование движка или пользователя не переписывает историю. Это также помогает избежать конфликтов с GDPR и правом на удаление: здесь нет содержимого, которое нужно редактировать.
Какие действия охватываются#
События сгруппированы по категориям, которые соответствуют фильтрам в дашборде.
| Категория | Подключенные на сегодня действия |
|---|---|
| Организация | org.created, org.settings_updated, org.ownership_transferred, org.deleted |
| Участники | member.invited, member.removed, member.role_changed |
| Роли | role.created, role.updated, role.deleted |
| Движки | engine.created, engine.updated, engine.deleted |
| API-ключи | api_key.created, api_key.revoked |
| Контент | glossary_item.*, instruction.*, brand_voice.* (только операции с отдельными объектами) |
Доступ к журналу#
Раздел Журнал аудита всегда есть в Настройках, в подразделе Admin. Если соответствующего права RBAC нет, вместо временной шкалы страница покажет «Журнал аудита недоступен в вашем плане». Что внутри:
- Список с фильтрами — сузьте выборку по Действию, Исполнителю и Периоду (готовые пресеты, например Последние 7 дней, или диапазон С / По). Будущие даты недоступны.
- Загрузить более ранние события — новые события идут первыми; нажмите Загрузить более ранние события внизу списка, чтобы загрузить следующую страницу.
- Детали события — нажмите на любую строку, чтобы развернуть её прямо в списке и увидеть все метаданные: идентификатор запроса, IP-адрес и User-Agent.
- Общие ссылки — фильтры и открытое событие отражаются в URL, так что любым видом легко поделиться.
Кто может просматривать#
Доступ к странице определяется двумя условиями:
- Право на функцию — для организации должна быть включена возможность audit-logs (тариф Enterprise).
- Разрешение — роль пользователя должна включать
org:view_audit_logs. Предустановленная роль Full Access содержит его по умолчанию; у владельцев оно есть всегда.
Участники без этого разрешения вместо временной шкалы увидят страницу «Нет доступа». Участники организации без этого права на функцию увидят paywall.
Если ваш тариф Enterprise закончится
Логи аудита входят в тот же уровень прав RBAC. Прошлые события остаются в базе данных, но страница показывает «Журнал аудита недоступен в вашем плане», а эндпоинты чтения возвращают 403 — пока план не будет восстановлен.
Защита от незаметных изменений#
Журналы аудита — это не просто запись: изменить их задним числом действительно непросто.
- Append-only на уровне базы данных. Миграция, создающая таблицу, выполняет
REVOKE UPDATE, DELETE, TRUNCATEдля API-роли. Любой будущий путь в коде — баг, новый эндпоинт или даже SQL-инъекция — будет отклонен Postgres еще до того, как сможет изменить строку. - Монотонная последовательность. В каждой строке есть строго возрастающий столбец
seq. Аудитор, проверяющий последовательность, может заметить удаления по пропускам.
Этого достаточно для контролей уровня SOC 2. Но это не защищает от злоумышленника с прямым доступом к production-базе данных — более строгие варианты защиты, такие как отдельная owner-роль или WORM-зеркало, доступны по запросу.
Срок хранения#
По умолчанию события аудита хранятся бессрочно. На Enterprise доступны индивидуальные сроки хранения — обычно 1, 3 или 7 лет. Свяжитесь с нами, если вам нужна конкретная политика хранения для соответствия требованиям или анкет по безопасности.
Что не охватывается#
Несколько осознанных ограничений v1, о которых стоит знать:
- Best-effort emit, а не транзакционность. Транзакционная запись событий есть в ближайшем roadmap. Событие аудита записывается после описываемого действия, а не в рамках той же транзакции базы данных. В редких сценариях сбоя, когда действие проходит успешно, а вставка записи аудита затем завершается ошибкой, действие может произойти без соответствующего события.
- Некоторые типы действий пока не подключены. Изменения состава участников движка, connect / update / disconnect интеграций, правки конфигурации модели, изменения подписки биллинга и массовые операции с контентом (загрузка CSV,
createMany/updateMany/deleteMany) пока не создают событий. Словарь действий уже зарезервирован, поэтому после подключения они появятся в существующих категориях фильтра. - Операции чтения не аудируются. Просмотр самого журнала аудита, просмотр журналов запросов движка или скачивание глоссария не создает событий. Фиксируются только действия, меняющие состояние.
- Экспорта пока нет. Данные аудита доступны через дашборд. Экспорт CSV, SIEM webhook и зеркалирование в S3 есть в roadmap — дайте знать, если они вам нужны.
- Нет представления с фильтрацией по движку. Все события аудита организации отображаются в единой временной шкале. Сузьте выборку с помощью фильтров по действию или исполнителю.
- Нет потоковой трансляции. Ни кнопки Обновить, ни WebSocket-потока не предусмотрено — перезагрузите страницу, чтобы получить свежие события.