Общее описание аудитов и журналов#

Система аудита и логирования Global ERP — централизованный механизм регистрации, хранения и просмотра значимых событий системы. Журналы используются для контроля действий пользователей, изменений данных и прав доступа, выполнения скриптов, изменений структуры БД, а также для технической диагностики и расследования инцидентов.

Документация по аудитам делится на 4 группы:

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

  • Аудиты базы данных и производительности — фиксируют события, связанные с базой данных, изменением структуры схемы, обновлениями, производительностью SQL-запросов и техническим состоянием таблиц.

  • Аудиты прикладных действий — регистрируют действия пользователей и прикладной логики: изменение бизнес-данных, открытие форм, выполнение операций, построение отчетов и запуск JEXL-скриптов.

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

Разделение на группы помогает описывать журналы по их основному назначению. При этом часть журналов может использоваться в нескольких сценариях анализа. Например, журналы базы данных применяются не только для контроля изменений структуры, но и при расследовании несанкционированных изменений. Технические журналы, в свою очередь, могут использоваться как дополнительный источник данных при анализе ошибок, сбоев и инцидентов безопасности.

Система Global ERP предоставляет инструменты для контроля и анализа следующих событий:

  • добавление, изменение и удаление данных;

  • изменение ролей, профилей и прав доступа;

  • подключение пользователей и сервисных учетных записей;

  • открытие форм и выполнение операций;

  • построение отчетов и печатных форм;

  • выполнение JEXL-скриптов;

  • изменение структуры базы данных;

  • выполнение обновлений и миграционных задач;

  • ошибки приложения и технические события.

Внимание

Перед построением данных задайте период и доступные уточняющие фильтры: пользователя, объект, интерфейс или тип события. Запрос без ограничений может загрузить большой объем записей и надолго заблокировать интерфейс. Начинайте с минимального периода и расширяйте его только при необходимости.

Отсутствие записи не всегда означает, что действие не выполнялось. История может быть неполной, если аудит не был включен в момент действия, запись не формируется для данного способа выполнения или данные уже очищены. Сводные формы объединяют только предусмотренные для них источники; для детального анализа используйте страницу соответствующего аудита.

Все таблицы аудита хранятся в отдельной схеме базы данных AUD. Физическое размещение таблиц, то есть табличное пространство, определяется настройкой модуля btk «Табличное пространство аудита». По умолчанию используется табличное пространство pg_default, однако администратор может изменить его при необходимости.

Работа аудита по умолчанию#

По умолчанию большинство видов аудита отключено. Активация аудитов выполняется по усмотрению заказчика. Инструкция по включению конкретного аудита приводится в статье соответствующего журнала.

Запись в журналы аудита выполняется в автономной транзакции. Она не зависит от основной бизнес-транзакции: даже если основная операция будет отменена через rollback, запись аудита останется в журнале. Это гарантирует сохранение истории действий пользователя.

После включения аудита необходимо:

  1. Очистить кэш ORM: Сервис > Управление решением > Очистить кэш ORM (shared кэш).

  2. Переоткрыть формы, в которых должен применяться аудит.

По умолчанию включены:

  • Аудит подключений.

  • Аудит подключений к сервисам REST/SOAP/WS.

  • Аудит JEXL.

Аудит выборок по умолчанию#

Для выборок предусмотрена настройка «Включать полный аудит для всех выборок по умолчанию».

Путь к настройке: Приложение «Настройка системы» > Настройки и сервисы > Настройка модулей системы > Общие настройки модулей > btk > Аудит > Включать полный аудит для всех выборок по умолчанию.

Если настройка выключена, аудит для выборок по умолчанию не ведётся. В этом случае режим аудита определяется настройками конкретной выборки.

Если настройка включена, полный аудит автоматически применяется ко всем выборкам системы:

  • уже существующим;

  • новым выборкам, которые будут созданы после включения настройки.

Для отдельной выборки можно определить режим аудита:

  • Не вести аудит — действия в выборке не фиксируются.

  • Аудит успешных операций — фиксируются только успешно выполненные операции.

  • Полный аудит с сохранением ошибок — фиксируются успешные операции и ошибки выполнения.

Автоматическое включение аудита классов#

Внимание

При создании технического класса, например регистра или свертки, необходимо отключать аудит в коде. Для этого укажите в odm.xml свойство isAuditDisabledByDefault="true", чтобы при включении настройки «Включить аудит на все классы системы» в аудит не записывались изменения технических неинтерфейсных сущностей.

Настройка «Включить аудит на все классы системы» позволяет автоматически включить аудит для классов, для которых он не отключен явно.

Путь: Приложение «Настройка системы» > Настройки и сервисы > Настройка модулей системы > Общие настройки модулей > btk > Аудит.

Система считает аудит для класса включенным, если одновременно выполняются два условия:

  • включен флаг «Включить аудит на все классы системы»;

  • для класса не задано свойство «Аудит отключен по умолчанию» или оно выключено.

Свойство «Аудит отключен по умолчанию» позволяет исключить отдельный класс из автоматического включения аудита.

Путь: Приложение «Настройка системы» > Сущности > Классы > [Класс] > Характеристики > Группа: Настройка аудита.

При генерации схемы таблицы аудита создаются для всех классов независимо от значений этих настроек. Наличие таблицы аудита само по себе не означает, что аудит для класса включен.

Внимание

Если аудит включен для дочернего класса, например позиции документа, но не включен для класса-шапки бизнес-объекта, например самого документа, данные аудита сохраняться не будут, поскольку принадлежность записи к бизнес-объекту определяется через поле gidRoot_dz и без корректной связи с классом-шапкой запись не может быть ассоциирована с бизнес-объектом.

Аудит построения отчётов по умолчанию#

Для печатных форм и отчётов предусмотрена настройка модуля rpt «Включать ведение аудита построения отчета по умолчанию».

Путь к настройке: Приложение «Настройка системы» > Настройки и сервисы > Настройка модулей системы > Общие настройки модулей > rpt > Включать ведение аудита построения отчета по умолчанию.

Логика настройки аналогична аудиту выборок. Если настройка выключена, аудит построения отчётов по умолчанию не ведётся и должен определяться настройками конкретной печатной формы или отчёта.

Если настройка включена, аудит построения отчётов применяется по умолчанию ко всем печатным формам и отчётам:

  • уже существующим;

  • новым, которые будут созданы после включения настройки.

Такой аудит позволяет фиксировать факты построения отчётов и печатных форм, в том числе пользователя, время выполнения и контекст запуска.