Аудит действий пользователей

Glarus BI собирает статистику действий пользователей, сохраняя результаты в базу метаданных приложения (Postgres, БД metabase). Администратор может подключить БД метаданных приложения (достаточно прав на чтение данных в БД) и создать дашборд для получения интересующей его информации о работе пользователей.

В данной статье показано, что контролируется, где хранятся соответствующие данные и даётся пример настройки дашборда для аудита.

Операции пользователей

Изменения настроек ETL-заданий в этой версии не регистрируются в журнале аудита. Историю выполнений задания просматривайте отдельно в Архитекторе данных; она не заменяет аудит изменений.

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

• id — идентификатор записи;
• topic — операция;
• timestamp — информация о дате и времени операции;
• end_timestamp — информация о времени завершения (только для отдельных продолжительных операций, в большинстве случаев записывается NULL);
• user_id — идентификатор субъекта (ФИО, email и другие атрибуты пользователя не присутствуют в отображении, но могут быть получены после присоединения таблицы core_user);
• entity_type — ресурс доступа, в отношении которого было выполнено действие (БД, учётная запись, настройка, дашборд…);
• entity_id — идентификатор ресурса, который был затронут операцией;
• entity_qualified_id — составной идентификатор ресурса, который был затронут операцией, удобен для присоединения справочников;
• details — детальная информация о сути изменений (JSON). Детали специфичны для различных ресурсов доступа.

Регистрируемые операции (topics):

1. Дашборд:
   • dashboard-create — создание дашборда;
   • dashboard-delete — удаление дашборда.
2. Визуализации:
   • card-create — создание визуализации (в составе запроса);
   • card-update — обновление визуализации (в составе запроса);
   • card-delete — удаление визуализации (из запроса).
3. Виджеты дашборда (карточки):
   • dashboard-add-cards — размещение виджета на дашборде;
   • dashboard-remove-cards — удаление виджета с дашборда.
4. Таблицы БД:
   • table-manual-scan — запуск ручного сканирования таблиц.
5. Метрики как карточки используют события card-create, card-update, card-delete.
6. Уведомления:
   • pulse-create — создание уведомления;
   • pulse-delete — удаление уведомления;
   • subscription-unsubscribe — отписка от рассылки;
   • subscription-unsubscribe-undo — отказ от отписки;
   • alert-unsubscribe — отписка от оповещений;
   • subscription-create — создание подписки;
   • subscription-update — обновление подписки;
   • subscription-send — отправка уведомления пользователю;
   • alert-send — отправка оповещения.
7. Оповещения:
   • alert-create — создание оповещения;
   • alert-delete — удаление оповещения;
   • alert-update — обновление настроек оповещения.
8. Сегменты:
   • segment-create — создание сегмента;
   • segment-update — обновление сегмента;
   • segment-delete — удаление сегмента.
9. Учётные записи:
   • user-invited — приглашение пользователя администратором системы (создание учётной записи);
   • user-deactivated — деактивация пользователя;
   • user-reactivated — активация ранее деактивированного пользователя;
   • password-reset-initiated — попытка сброса пароля;
   • password-reset-successful — успешный сброс пароля;
   • user-update — обновление настроек пользователя;
   • user-joined — приглашённый ранее пользователь присоединился к системе (первичный вход и смена пароля).
10. Установка:
    • install — установка системы.
11. Работа с БД:
    • database-create — создание нового подключения к БД в Glarus BI;
    • database-delete — удаление подключения к БД;
    • database-manual-sync — выполнение ручной синхронизации с БД;
    • database-manual-scan — выполнение ручного сканирования БД;
    • database-discard-field-values — инициирован сброс значений полей;
    • database-update — обновление настроек подключения к БД.
12. Проблемы с доступом к данным:
    • write-permission-failure — ошибка получения прав на запись;
    • update-permission-failure — ошибка получения прав на обновление данных;
    • create-permission-failure — ошибка получения прав на создание.
13. Настройки системы:
    • setting-update — изменение настроек системы.
14. Работа с ключами API:
    • api-key-create — создание ключа API;
    • api-key-update — обновление ключа API;
    • api-key-regenerate — перегенерация ключа API;
    • api-key-delete — удаление ключа API.
15. Загрузка файлов:
    • upload-create — импорт данных из файла в новую таблицу;
    • upload-append — импорт данных из файла с присоединением к существующей таблице;
    • upload-replace — импорт данных из файла с заменой существующей таблицы.
16. Настройки кэширования:
    • cache-config-update — обновление настроек кэширования.

Информация о просмотрах

Информация о просмотрах может быть получена из представления v_view_log:

• id — идентификатор записи журнала;
• timestamp — дата и время события;
• user_id — идентификатор пользователя, который выполнил просмотр;
• entity_type — ресурс доступа, который был просмотрен;
• entity_id — идентификатор ресурса доступа;
• entity_qualified_id — составной идентификатор ресурса, удобен для присоединения справочников (JOIN).

Ресурсы доступа:

• card — карточка (запрос, визуализация);
• collection — коллекция;
• dashboard — дашборд;
• table — таблица.

Выполненные запросы

Информация о выполненных запросах доступна в представлении v_query_log:

• entity_id — идентификатор записи;
• started_at — дата и время запуска запроса;
• running_time_seconds — длительность выполнения запроса;
• result_rows — число строк в результате;
• is_native — признак прямого запроса;
• query_source — площадка, откуда запрос был запущен (дашборд, конструктор запросов и т.д.);
• error — ошибка (если запрос завершился с ошибкой);
• user_id — идентификатор пользователя;
• card_id — идентификатор ресурса "запрос" в Glarus BI;
• card_qualified_id — составной идентификатор ресурса "запрос" в Glarus BI;
• dashboard_id — идентификатор дашборда;
• dashboard_qualified_id — составной идентификатор дашборда;
• pulse_id — идентификатор уведомления;
• database_id — идентификатор БД;
• database_qualified_id — составной идентификатор БД;
• query — код запроса.

Дополнительные справочники

1. Пользователи. Информация о пользователях сохранена в таблице core_user. Ниже перечислены только значимые для аудита поля:

   • id — идентификатор пользователя в таблице;
   • email — адрес электронной почты пользователя;
   • first_name — имя (или имя и отчество);
   • last_name — фамилия;
   • is_active — признак активности учётной записи;
   • is_superuser — признак администратора;
   • last_login — дата последнего успешного входа в систему (учитываются только факты получения нового токена авторизации; автоматический вход с "запомнить меня" в систему не обновляет это поле).

2. Ресурсы. Информация о ресурсах доступна в представлении v_content. Полезные для аудита поля:

   • entity_qualified_id — составной идентификатор ресурса, удобен для JOIN;
   • name — название ресурса;
   • description — описание ресурса;
   • collection_id — идентификатор коллекции, в которой хранится ресурс;
   • made_public_by_user — признак общедоступной ссылки;
   • archived — признак ресурса в архиве;
   • question_viz_type — тип визуализации (для запросов);
   • question_database_id — составной идентификатор базы данных, с которой связан ресурс;
   • question_is_native — признак прямого запроса.

3. Базы данных. Название подключения к БД, описание и тип базы данных могут быть получены из представления v_databases:

   • entity_qualified_id — составной идентификатор подключения к БД, рекомендуется для JOIN;
   • name — название подключения к БД;
   • description — описание подключения к БД;
   • database_type — тип БД.

4. Коллекции. Информация о коллекции может быть получена из таблицы collection:

   • id — идентификатор коллекции;
   • name — название коллекции;
   • description — описание коллекции;
   • archived — признак архивной коллекции.

История изменений прав

При сохранении графа прав приложение записывает ревизию в свою базу данных. Ревизии прав на данные хранятся в permissions_revision, прав на коллекции — в collection_permission_graph_revision, прав приложения — в application_permissions_revision. В записях есть автор (user_id), время создания (created_at) и JSON-поля before и after. Их содержимое зависит от типа графа; отдельную построчную разницу можно получить сравнением этих значений в запросе.

Например, этот запрос показывает автора, время и значения до и после изменения прав на данные. Создайте в редакторе SQL переменные типа «Дата» start_date и end_date, а также необязательную переменную user_email:

SELECT r.created_at,
       u.email,
       r.id,
       r.before,
       r.after
FROM permissions_revision AS r
LEFT JOIN core_user AS u ON u.id = r.user_id
WHERE r.created_at >= {{start_date}}
  AND r.created_at < {{end_date}}
  [[AND u.email = {{user_email}}]]
ORDER BY r.created_at DESC;

Создание, изменение и удаление групп, а также включение пользователя в группу и исключение из неё записываются в представление v_audit_log. В поле user_id указан инициатор события; поля entity_id и details помогают определить группу и пользователя. Запрос ниже отбирает эти события за выбранный период:

SELECT "timestamp",
       topic,
       user_id,
       entity_type,
       entity_id,
       details
FROM v_audit_log
WHERE topic IN (
  'group-create', 'group-update', 'group-delete',
  'group-membership-create', 'group-membership-delete'
)
[[AND "timestamp" >= {{start_date}}]]
[[AND "timestamp" < {{end_date}}]]
ORDER BY "timestamp" DESC;

Сохраните запросы как карточки и добавьте их на дашборд. Для карточек можно настроить фильтры по дате, пользователю и типу события. Порядок создания дашборда описан в разделе «Создание дашборда для аудита»; описание полей журнала событий — в разделе «Типы событий: детализация и старые и новые значения».

Для таблиц query_execution, audit_log и view_log срок хранения задаёт параметр MB_AUDIT_MAX_RETENTION_DAYS: по умолчанию это 720 дней, минимум — 30 дней, а значение 0 означает бессрочное хранение. Очистка запускается каждые 12 часов. Таблицы ревизий прав не входят в список этой очистки; отдельный срок их хранения этим параметром не задаётся.

Отдельного экрана истории изменений прав в интерфейсе нет: записи просматривают запросом или дашбордом к базе приложения. Правила ограничения строк хранятся отдельно в таблице sandboxes и не попадают в перечисленные ревизии прав; приведённые запросы не показывают историю изменения таких правил.

Создание дашборда для аудита

Вы можете получить дашборд за секунды — выполните "умный анализ" представления v_audit_log:

1. В "Обзор" откройте "Базы данных".
2. Найдите БД метаданных в списке (если её нет, то настройте к ней подключение).
3. Найдите плитку "V Audit Log".
4. Наведите курсор мыши на плитку — появятся кнопки дополнительных действий.
5. Нажмите кнопку умного анализа (в виде молнии). — Система отобразит автоматически составленный дашборд, который даст вам представление о наборе данных и может стать отправной точкой для дальнейших изменений.

По аналогии вы можете получить результат автоматического исследования представлений v_view_log и v_query_log.

Если же вы хотите собрать дашборд "с нуля", вам следует:

1. Создать коллекцию аудита.
2. Создать и сохранить запрос к v_audit_log, присоединить (JOIN) таблицу пользователей core_user и другие нужные вам справочники, настроить набор полей и сортировку.
3. Выбрать визуализацию.
4. Сохранить запрос в коллекцию. При сохранении создать новый дашборд (сохранить дашборд в коллекцию аудита) и добавить запрос на него.
5. Создать запросы с визуализациями для деталей и статистики. Добавить их на дашборд.
6. Добавить фильтры на дашборд, связать с карточками и настроить интерактивность.
7. Если требуется, добавить уведомления и оповещения о событиях.
8. Настроить доступ других пользователей (групп) к коллекции аудита: например, запретить всем, разрешить только администраторам и сотрудникам, отвечающим за информационную безопасность.

По аналогии вы можете создать дополнительные дашборды (или вкладки на первом) с данными о просмотрах и запросах (v_view_log, v_query_log).

Конечный вид дашборда и набор виджетов будет зависеть от ваших потребностей. Вы можете присоединять в конструкторе таблицы из БД метаданных, перечисленные как справочные, для получения дополнительных деталей об изменённых и просмотренных объектах.

Пример запроса для получения детальной информации об операциях:

Пример дашборда аудита, вкладка операций:

Слева расположен интерактивный список операций, справа — блок деталей, на гистограмме снизу отображается активность за выбранный период. Фильтры связаны с карточками. Щелчок по записи в списке событий вызывает открытие деталей или фильтрацию по выбранному признаку.

Пример запроса для получения детальной информации о просмотрах:

Пример дашборда аудита, вкладка просмотров:

Дополнительная информация

• Коллекции
• Разрешения на коллекции
• Дашборды
• Общедоступные ссылки

Типы событий: детализация и старые и новые значения

Источники ниже дополняют друг друга. Журнал приложения и история фоновых задач показывают работу системы; аудит действий и аналитика использования — операции над объектами, просмотры и запросы. Запись действий в таблицу аудита и её отражение в JSON-поток зависят от доступности функции аудита в вашей конфигурации.

Тип события	Где хранится	Детализация	Старое и новое значение
Системные	Журнал приложения; «Фоновые задачи»; модель «Системные задачи»	Уровень логирования, сообщение и исключение; тип задачи, начало, конец, длительность и результат	Это записи выполнения, а не история значений настроек
Действия пользователей	audit_log/v_audit_log; v_view_log; v_query_log	user-login, user-login-failure, user-logout; просмотр объекта; выгрузки с источником csv-download, xlsx-download, json-download	У входа и просмотра нет пары «до/после»; у изменений профиля она зависит от изменённых аудируемых полей
Действия администраторов	audit_log/v_audit_log	setting-update, database-*, group-*, group-membership-*, api-key-*, channel-*; приглашение, деактивация, повторная активация и изменение пользователя; создание и удаление публичных ссылок	Изменённые аудируемые поля в details.previous и details.new; для настроек — previous-value и new-value с учётом политики скрытия
Работа разработчиков контента	audit_log/v_audit_log; история версий	card-*, создание и удаление дашбордов, добавление и удаление карточек, segment-*, alert-*, subscription-*. Метрики как карточки используют card-*	Краткая разница аудируемых полей; версии запросов и дашбордов сохраняются отдельно для сравнения и восстановления
Запросы к источникам	query_execution, определение запроса в query; представление v_query_log	Время, длительность, число строк, ошибка, источник запуска, is_native, Cache Hit и поле query с определением	Каждая строка описывает выполнение; это не разница двух версий запроса

Границы детализации. Пары previous/new содержат только изменившиеся поля, присутствующие в обеих аудируемых версиях объекта. Это не полный снимок объекта и не запись всех секретов: например, у подключения сохраняются название и тип, у API-ключа — префикс вместо полного ключа, у канала — общие атрибуты без закрытых параметров. Настройки используют другую форму: key, previous-value, new-value; отдельные настройки не журналируются или записываются без значений.

История версий хранит сериализованные версии карточек и дашбордов, включая определение запроса и состав дашборда, с исключением служебных полей; это не резервная копия всей базы. Сохраняются до 15 последних версий объекта. Изменение дашборда просматривайте в истории версий: отдельного события dashboard-update в этом журнале нет. Прежние названия metric-create, metric-update, metric-delete не следует ожидать как отдельные события для современных карточек-метрик.

Поле is_native показывает сохранённый признак типа запроса. Для определения реального запроса проверяйте также query: запрос с SQL-шагом может иметь is_native = false. Источник запуска и признак попадания в кэш описывают выполнение, а не изменения текста SQL.

JSON-поток для SIEM. Логгер metabase.audit.core на уровне INFO выводит JSON-сообщение события в журнал приложения. Схема включает ts, event, result, actor; при наличии контекста добавляются ip, user_agent, session_id, request_id, target, details. У фонового события контекста HTTP-запроса может не быть. Внешний сборщик читает журнал приложения или контейнера и отправляет сообщения в SIEM либо syslog; настройку доставки и долговременного защищённого хранения выполняют отдельно.

Срок хранения строк query_execution, audit_log и view_log задаёт MB_AUDIT_MAX_RETENTION_DAYS: по умолчанию 720 дней, минимум 30; значения от 1 до 29 трактуются как 30, 0 означает бессрочное хранение. Очистка выполняется по расписанию дважды в сутки. Это правило не задаёт срок хранения внешнего JSON-потока.

Изменения настроек ETL-заданий в этот аудит не записываются. См. аналитику использования, фоновые задачи и журнал приложения.