Журналы аудита фиксируют каждое действие, меняющее состояние в вашей организации, — назначения ролей, правки движка, выпуск 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.* (только операции с отдельными объектами) |
Доступ к журналу#
Пункт Журналы аудита появляется в боковом меню организации только в том случае, если эта возможность включена для вашей организации. Внутри вы найдете:
- Список с фильтрами — отбирайте события по инициатору, категории действия, типу объекта и диапазону дат. Будущие даты недоступны, а верхняя граница всегда ≥ нижней.
- Бесконечная прокрутка — сначала показываются новые события, а более старые подгружаются по мере прокрутки.
- Панель деталей — нажмите на любую строку, чтобы увидеть полные метаданные, ID запроса, 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 — дайте знать, если они вам нужны.
- Нет представления в рамках движка. Все события аудита организации находятся в единой временной шкале. Используйте фильтр по типу объекта или ID объекта, чтобы сузить выборку.
- Нет live tail. Список обновляется по запросу или при нажатии Обновить — потока WebSocket нет.
