Журналирование и аудит

Описание

Для журналирования аудита событий безопасности используется модифицированное расширение pgAudit, интегрированное в ядро СУБД Pangolin. Оно обеспечивает детальное журналирование сессий и объектов для целей аудита через стандартный механизм ведения журнала PostgreSQL. При необходимости возможно включение расширенного аудита путем добавления классов регистрируемых событий, подлежащих аудиту.

Сведения

Аудит предназначен для регистрации событий обращения к информационным ресурсам объектов и действий пользователей при работе с СУБД. Эти события могут быть вызваны сторонними приложениями, внутренними компонентами системы или непосредственно администраторами БД. Результаты аудита предназначены для снижения рисков безопасности, связанных с доступом субъектов к информационным ресурсам организации.

СУБД Pangolin расширяет возможности аудита:

отделением лога аудита от системного;
добавлением нового системного процесса (аналог syslogger) для асинхронной записи событий аудита в файл;
изменением формата событий аудита для соответствия ГОСТ Р 59548-2022;
добавлением новых событий аудита.

Запись о регистрации события аудита представляет собой строку в журнале событий с тегом AUDIT и содержит информацию о событии в виде последовательности полей.

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

CONNECTION - подключения к серверу;
PROTECTION - использования функций настройки механизма защиты от привилегированных пользователей;
RECOVERY - восстановления базы данных;
INTEGRITY - нарушения целостности объектов контроля;
ACTION - запуска/остановки базы данных с причиной остановки;
PARAMETER - изменения конфигурации системы управления базами данных.

Полный список классов операторов, событий, функций и команд, которые можно регистрировать в события журнала аудита, указан в описании параметра pgaudit.log.

Уровни важности сообщений журналирования

В таблице приведены уровни важности сообщений журнала, используемые в ядре PostgreSQL. Если вывод журнала отправляется в syslog, уровни преобразуются, как показано в таблице.

Уровень важности	Описание	Уровень в `syslog`
`DEBUG1` ... `DEBUG5`	Предоставляет разработчикам последовательно более подробную информацию	`DEBUG`
`INFO`	Предоставляет информацию, неявно запрошенную пользователем, например, вывод из `VACUUM VERBOSE`	`INFO`
`NOTICE`	Предоставляет информацию, которая может быть полезна пользователям, например, уведомление об «усечении» длинных идентификаторов	`NOTICE`
`WARNING`	Выдает предупреждения о возможных проблемах, например, `COMMIT` за пределами блока транзакции	`NOTICE`
`ERROR`	Сообщает об ошибке, которая привела к прерыванию текущей команды	`WARNING`
`LOG`	Сообщает информацию, представляющую интерес для администраторов	`INFO`
`FATAL`	Сообщает об ошибке, которая привела к прерыванию текущего сеанса	`ERR`
`PANIC`	Сообщает об ошибке, которая привела к прерыванию всех сеансов работы с базой данных	`CRIT`

примечание

События уровня debug не рекомендуется включать в промышленных инсталляциях.

Если логирование ведется в журнал syslog, то редактирование текстовым редактором невозможно.

Уровни важности событий аудита

Важность предопределена для каждого события и не может быть изменена. Возможные типы важности:

Уровень важности	Признаки событий
Аварийный `EMERGENCY`	События полной блокировки пользовательского доступа пользователей к СУБД или отдельным БД. Например, скомпрометированы двоичные файлы ядра СУБД / в память СУБД загружен недоверенный код / перезаписана контролируемая функция
Фатальный `FATAL`	События блокировки одиночного объекта или ограничения доступа к объекту. Например, превышено количество неуспешных попыток авторизации / пользователь заблокирован по параметру парольной политики
Критический `CRITICAL`	События отказа в неавторизованном доступе. Например, отклонена попытка подключения с неверным паролем / суперпользователь попробовал без разрешения прочитать или изменить данные в объекте под защитой от действий пользователя
Высокий `HIGH`	События изменения объектов защиты и прав на них (пользовательские УЗ и пароли, параметры политик, права на объекты, системные привилегии и др.), а также вызов команд для изменения БД, схем, отношений, кода, когда есть возможность задать / сменить владельца объекта, схему, права доступа. Добавление / изменение фильтров, умеющих просматривать параметры или результаты, менять поведение других команд. Например, `ALTER USER (GROUP), CREATE DATABASE, CREATE EVENT TRIGGER`
Средний `MEDIUM`	События получения разрешенных привилегий для их применения (`SET` - включение `SET ROLE`). Прочие действия, разрешенные только суперпользователю (перезапуск сервера, снятие и восстановление резервной копии и другие), администратору безопасности (просмотр политики) или существующему владельцу объекта (настройка индексов, триггеров и другие). При условии, что действия не ведут к изменению объектов / прав / кода. Например, подключение / отключение сессии, вызов `CREATE INDEX`
Низкий `LOW`	Нормальное, постоянное использование полученных привилегий: `SELECT / INSERT / UPDATE / DELETE` и прочие пользовательские действия
Отладочный `DEBUG`	Внутренняя информация о деятельности механизмов защиты

Формат

По умолчанию записи аудита записываются в стандартное средство ведения журнала (регулируются параметрами лог-файла) и содержат столбцы в формате CSV.

LOG: AUDIT: <AUDIT_TYPE>, <STATEMENT ID>, <SUBSTATEMENT ID>, <CLASS>, <STATEMENT_TYPE>, <OBJECT_TYPE>, <OBJECT_NAME>, <COMMAND_TEXT>, <PARAMETER_LIST>, ERROR: <ERROR_MESSAGE>

AUDIT_TYPE - тип, может быть:
- SESSION - аудит действий пользователя для всех запросов;
- OBJECT - аудит действий над каким-либо отношением (например, таблицей);
STATEMENT ID - номер запроса;
SUBSTATEMENT ID - номер подзапроса;
CLASS - класс: DDL, READ, WRITE и другие (задаются параметром pgaudit.log);
STATEMENT_TYPE - тип запроса CREATE TABLE, ALTER TABLE, SELECT, INSERT, UPDATE, DELETE и другие;
OBJECT_TYPE - тип объекта, если есть (TABLE, INDEX, VIEW и другие);
OBJECT_NAME - имя объекта, если есть (например, public.account);
COMMAND_TEXT - текст команды (SQL-запрос);
PARAMETER_LIST - список параметров, если есть;
ERROR_MESSAGE - сообщение об ошибке, если есть.

Пример:

LOG:  AUDIT: SESSION,1,1,READ,SELECT,,, SELECT * FROM ext.test_table;,<not logged>,ERROR: permission denied for table test_table

примечание

В случае включенного параметра pgaudit.legal в формат записи событий аудита добавляются следующие поля:

ID - уникальный идентификатор события;
IMPORTANCE - важность события.

В качестве идентификатора событий используется UUIDv4 (формируется случайным образом). Для получения идентификатора используется функция gen_random_uuid(). Формат идентификатора:

xxxxxxxxxxxxMxxxNxxxxxxxxxxxxxxx

Значения на позициях M и N определяют соответственно версию и вариант UUID.

Префикс строки системного журнала

Для добавления любых других полей, необходимых для удовлетворения требований к системному журналу логов, используйте префикс строки (log_line_prefix):

Спецсимвол	Назначение	Только для пользовательского процесса
`%a`	Имя приложения (`application_name`)	да
`%u`	Имя пользователя	да
`%d`	Имя базы данных	да
`%r`	Имя удаленного узла или IP-адрес, а также номер порта	да
`%h`	Имя удаленного узла или IP-адрес	да
`%p`	Идентификатор процесса	нет
`%t`	Штамп времени, без миллисекунд	нет
`%m`	Штамп времени, с миллисекундами	нет
`%n`	Штамп времени, с миллисекундами (в виде времени Unix)	нет
`%i`	Тег команды: тип текущей команды в сессии	да
`%e`	Код ошибки `SQLSTATE`	нет
`%c`	Идентификатор сессии	нет
`%l`	Номер строки журнала для каждой сессии или процесса. Начинается с 1	нет
`%s`	Штамп времени начала процесса	нет
`%v`	Идентификатор виртуальной транзакции (`backendID`/`localXID`)	нет
`%x`	Идентификатор транзакции (0 если не присвоен)	нет
`%q`	Ничего не выводит. Непользовательские процессы останавливаются в этой точке. Игнорируется пользовательскими процессами	нет
`%%`	Выводит `%`	нет

Пример префикса строки журнала: %m %u %d [%p]: – включить вывод метки времени, имени пользователя, имени базы данных и идентификатора процесса для каждой записи журнала сообщений.

Формат отдельных классов регистрируемых событий

События подключения к серверу

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

У записей класса событий CONNECTION свой формат:

AUDIT: <AUDIT_TYPE>,<CLASS>,<EVENT>,<SESSION_TIME>,<DATA_BASE>,<USER>,<ID>,<IMPORTANCE>

AUDIT_TYPE — всегда SESSION;
CLASS — всегда CONNECTION;
EVENT — OPEN, CLOSED, FAILED, CHANGE USER;
SESSION_TIME — только для события CLOSED. Формат записи: session time: %d:%02d:%02d.%03d — часы, минуты, секунды, миллисекунды соответственно;
DATA_BASE — имя базы данных, к которой осуществляется подключение. Формат записи: - database = %s (имя базы данных);
USER — имя пользователя, подключающегося к базе данных. Формат записи: — user = %s (имя пользователя);
ID - уникальный идентификатор события (в случае включенного параметра pgaudit.legal);
IMPORTANCE - важность события (в случае включенного параметра pgaudit.legal).

Примеры вывода:

LOG:  AUDIT: SESSION, CONNECTION, OPEN,database = First_db,user = user_test2
LOG:  AUDIT: SESSION, CONNECTION, CLOSED, session time: 0:14:43.261,database = First_db,user = user_test2

События вызова функций настройки механизма защиты от привилегированных пользователей

Класс событий PROTECTION фиксирует вызовы функций настройки механизма защиты от привилегированных пользователей.

У записей класса событий PROTECTION свой формат:

AUDIT: <AUDIT_TYPE>,<STATEMENT ID>,<SUBSTATEMENT ID>,<CLASS>,<STATEMENT_TYPE>,<OBJECT_TYPE>,<OBJECT_NAME>,<ACTION>,<RESULT>,<ID>,<IMPORTANCE>

AUDIT_TYPE — тип аудита (SESSION или OBJECT);
STATEMENT ID - номер запроса;
SUBSTATEMENT ID - номер подзапроса;
CLASS - класс, всегда PROTECTION;
STATEMENT_TYPE - тип запроса (PROTECT, SUSPEND, CREATE, ALTER, ALTER, GET, LIST, GRANT, RESUME и другие);
OBJECT_TYPE - тип объекта, если есть (например, POLICY, ROLE);
OBJECT_NAME - имя объекта или политики, если есть (например, policy_name, role_name, object_name);
ACTION - действие функции, которая вызывается;
RESULT - результат выполнения функции, если есть:
- SUCCESS - операция успешно завершена;
- FAIL - операция завершена с ошибкой;
ID - идентификатор события;
IMPORTANCE - важность события (HIGH или MEDIUM).

Примеры вывода:

AUDIT: SESSION,2,2,PROTECTION,CREATE,POLICY,"new_policy",""Create policy 'new_policy'"",SUCCESS,<ID>,HIGH
AUDIT: SESSION,4,2,PROTECTION,GRANT,POLICY,"new_policy",""Grant actions {select,insert} for object 'table' 'public.test_table' to policy 'new_policy'"",,SUCCESS,<ID>,HIGH
AUDIT: SESSION,5,2,PROTECTION,ASSIGN,POLICY,"new_policy",""Assign policy 'new_policy' to user 'test_user'"",SUCCESS,<ID>,HIGH

Устранение избыточного маскирования для событий аудита класса PROTECTION

В версии 6.6.0 изменен формат вывода лога вызова функций класса PROTECTION. Ранее при активном маскировании запросов параметры этих событий скрывались полностью, что мешало анализу инцидентов безопасности. Теперь вместо поля <COMMAND_TEXT>, содержащего SQL-запрос, используется <ACTION>, содержащее пояснение с информацией о значениях всех параметров функции, во всех строках лога. Также обновлен формат вывода полей <STATEMENT_TYPE>, <OBJECT_TYPE> и <OBJECT_NAME>, что обеспечивает возможность получать детализированные события безопасности данного класса.

События восстановления базы данных

Класс событий RECOVERY фиксирует события, связанные с выполнением восстановления информации и резервного копирования.

Запись событий указанного класса происходит при включенном параметре pgaudit.legal.

События RECOVERY возникают при использовании утилит:

pg_dump – создание резервной копии;
pg_restore – восстановление из резервной копии;
pg_dumpall – создание резервной копии;
pg_basebackup – создание резервной копии;
pg_probackup – создание резервной копии (событие аудита формируется только в режиме backup);
manage_backup – создание резервной копии.

примечание

События RECOVERY возникают также при использовании сторонних утилит, если они используют pg_backup_start / pg_backup_stop (поле ACTION принимает значение pg_backup_start / pg_backup_stop).

Каждая из утилит в процессе своей работы передает на сервер информацию о событии RECOVERY при помощи одной из функций:

start_recovery_event;
stop_recovery_event;
pg_backup_start;
pg_backup_stop.

Если в работе утилит не возникает ошибок, то формируется два события RECOVERY, отвечающих за начало процесса (PHASE=START) и за его завершение (PHASE=STOP). Если в процессе работы утилит возникают ошибки, то второе событие может отсутствовать в журнале аудита, либо содержать информацию об ошибке.

Формат записи:

AUDIT: <AUDIT_TYPE>,<CLASS>,<ACTION>,<TYPE>,<PHASE>,<DBNAME>,<FILE>,<TIME>,<RESULT>,<ID>,<IMPORTANCE>

Поля:

AUDIT_TYPE - тип аудита, всегда SESSION;
CLASS - класс события, всегда RECOVERY;
ACTION - одно из следующих значений: pg_dump / pg_restore / pg_dumpall / pg_basebackup / pg_probackup / pg_backup_start / pg_backup_stop;
TYPE - тип события:
- BACKUP - создание копии;
- RESTORE - восстановление из копии;
PHASE - фаза:
- START - начало операции;
- STOP - завершение операции;
DBNAME - имя базы данных;
FILE - имя файла / каталога резервной копии;
TIME - продолжительность операции в минутах (для фазы START всегда ноль);
RESULT - результат операции:
- SUCCESS - операция успешно завершена;
- FAIL - операция завершена с ошибкой (для фазы START всегда SUCCESS);
ID - идентификатор события;
IMPORTANCE - важность события, всегда HIGH.

Примеры вывода:

AUDIT: SESSION, RECOVERY, pg_dump, BACKUP, START, testdb, /tmp/dump, 0, SUCCESS, <ID>, HIGH
AUDIT: SESSION, RECOVERY, pg_dump, BACKUP, STOP, testdb, /tmp/dump, 0, SUCCESS, <ID>, HIGH

AUDIT: SESSION, RECOVERY, pg_restore, RESTORE, START, restore_testdb, /tmp/dump, 0, SUCCESS, <ID>, HIGH
AUDIT: SESSION, RECOVERY, pg_restore, RESTORE, STOP, restore_testdb, /tmp/dump, 0, SUCCESS, <ID>, HIGH

AUDIT: SESSION, RECOVERY, pg_probackup, BACKUP, START, postgres, /pgarclogs/06/backups/clustername/database, 0, SUCCESS, <ID>, HIGH
AUDIT: SESSION, RECOVERY, pg_probackup, BACKUP, STOP, postgres, /pgarclogs/06/backups/clustername/database, 0, SUCCESS, <ID>, HIGH

События нарушения целостности объектов контроля

События INTEGRITY возникают, когда для объекта контроля обнаруживается одна из ошибок:

Объект контроля запрещен к использованию, если настройка не позволяет использовать объект контроля. Например, если расширение не содержится в списке для контроля загрузки модулей.

Если список модулей пуст или отсутствует на диске, то при попытке загрузить любой модуль будет возникать данная ошибка;
Объект контроля удален (нет доступа);
Контрольная сумма объекта контроля не совпадает с ожидаемой.

Запись событий указанного класса происходит при включенном параметре pgaudit.legal.

Класс событий INTEGRITY имеет формат:

AUDIT: <AUDIT_TYPE>,<CLASS>,<INTEGRITY_SUBJECT>,<INTEGRITY_OBJECT>,<INTEGRITY_ERROR>,<INTEGRITY_MODE>,<INTEGRITY_ACTION>,<ID>,<IMPORTANCE>

Поля:

AUDIT_TYPE - тип аудита, всегда SESSION;
CLASS - класс события, всегда INTEGRITY;
INTEGRITY_SUBJECT - субъект контроля:
- MODULE - контроль загрузки модулей;
- CORE - контроль целостности объектов базы данных;
- CONFIG - контроль целостности конфигурации базы данных;
INTEGRITY_OBJECT - объект контроля: путь к файлу или имя базы/каталога;
INTEGRITY_ERROR - тип изменения:
- NOT_ALLOWED - объект запрещен;
- DELETED - объект удален;
- CHECK_SUM - контрольная сумма объекта не совпала с ожидаемой;
- INTERNAL - внутренняя ошибка механизмов контроля целостности (в поле INTEGRITY_OBJECT будет записана расшифровка ошибки);
INTEGRITY_MODE - метод контроля, всегда SHA256;
INTEGRITY_ACTION - реакция на изменение:
- SKIP - плагин не загружается / расширение не используется;
- BLOCK_CONNECTION - блокировка подключения пользователей (кроме суперпользователей);
ID - идентификатор события;
IMPORTANCE - важность события, всегда EMERGENCY.

Пример вывода:

AUDIT: SESSION, INTEGRITY, CONFIG, /etc/pangolin-manager/postgres.yml, CHECK_SUM, SHA256, BLOCK_CONNECTION, <ID>, EMERGENCY

События запуска/остановки базы данных с причиной остановки

События класса ACTION возникают при запуске или остановке базы данных.

Запись событий указанного класса происходит при включенном параметре pgaudit.legal.

Формат класса ACTION:

AUDIT: <AUDIT_TYPE>,<CLASS>,<ACTION>,<WHAT>,<ID>,<IMPORTANCE>

Поля:

AUDIT_TYPE - тип аудита, всегда SESSION;
CLASS - класс события, всегда ACTION;
ACTION - действие:
- START - запуск базы данных;
- STOP - остановка базы данных;
WHAT - причина остановки базы данных (для действия START не заполняется);
ID - идентификатор события;
IMPORTANCE - важность события, всегда HIGH.

Пример вывода:

AUDIT: SESSION, ACTION, START, , <ID>, HIGH
AUDIT: SESSION, ACTION, STOP, Normal exit, <ID>, HIGH

События изменения конфигурации системы управления базами данных

События класса PARAMETER возникают после перечитывании конфигурации, если:

Параметр был изменен в файле конфигурации СУБД.
Параметр был изменен при помощи ALTER SYSTEM SET <name> = <value>; или ALTER SYSTEM RESET <name>.

Действия по изменению параметров для пользователя или сессии (ALTER USER <user> SET <name> = <value>; или SET <name> = <value>;) попадают в аудит в рамках класса операторов ROLE или MISC соответственно.

Запись событий указанного класса происходит при включенном параметре pgaudit.legal.

Формат записи класса событий PARAMETER:

AUDIT: <AUDIT_TYPE>,<CLASS>,<WHAT>,<ID>,<IMPORTANCE>

AUDIT_TYPE - тип аудита, всегда SESSION;
CLASS - класс события, всегда PARAMETER;
WHAT - сообщение об изменении параметра: "parameter "%name" changed from "%old_value" to "%new_value"":
- %name - название параметра;
- %old_value - предыдущее значение параметра;
- %new_value - новое значение параметра;
ID - идентификатор события;
IMPORTANCE - важность события, всегда HIGH.

Пример вывода:

AUDIT: SESSION, PARAMETER, parameter "exit_on_error" changed from "off" to "on", <ID>, HIGH

Настройка

Настройка журналирования

Действия, выполняемые СУБД Pangolin, фиксируются в системном журнале. Настройка журналирования сообщений СУБД происходит с помощью параметров оригинального ядра PostgreSQL.

Подробная информация о реализации системного журнала и конфигурационных параметрах приведена в разделе «Отчетность и ведение журнала сообщений» документа «Программирование и администрирование сервера PostgreSQL».

Настройка аудита

Все записи, относящиеся к системному аудиту, в журнале сообщений предваряются тегом AUDIT:.

Настройки аудита хранятся в конфигурационном файле, в зависимости от типа конфигурации сервера:

для standalone-конфигурации — в файле $PGDATA/postgresql.conf;
для кластерной конфигурации — в файле /etc/pangolin-manager/postgres.yml.

Настройки могут быть заданы:

глобально (в файле конфигурации или с помощью ALTER SYSTEM ... SET);
на уровне базы данных (с помощью ALTER DATABASE ... SET);
на уровне роли (с помощью ALTER ROLE ... SET).

Настройки недоступны к изменению в рамках текущей сессии. При попытке данных изменений возникает ошибка: ERROR: SET command is prohibited for pgaudit parameters.

Настраиваемый параметр конфигурации pgaudit.log указывает, какие классы операторов и событий будут регистрироваться при ведении журнала аудита сессии.

Общая настройка по умолчанию для всех ролей содержит следующие классы событий:

в случае установки СУБД при использовании скриптов автоматизации: pgaudit.log = 'ddl, role, connection, misc_set, protection';
в случае ручной установки СУБД, классы отсутствуют: pgaudit.log = 'none';

Мониторинг классов событий RECOVERY, INTEGRITY, ACTION и PARAMETER определяется включением параметра pgaudit.legal. Значение данного параметра применяется при перезапуске сервера. Данный параметр также активирует запись лога в отдельный файл.

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

Внимание!

В зависимости от настроек, журнал pgaudit может достигать очень больших объемов.

Максимально точно определите, что именно должно быть записано в журнал аудита, чтобы избежать слишком большого количества записей.

Для изменения параметров аудита и их применения требуется:

наличие прав суперпользователя;
перечитать конфигурацию (кроме pgaudit.legal, для него требуется перезагрузка);
в случае кластерной конфигурации, изменять параметр в конфигурационном файле на всех узлах кластера (Leader, Sync Standby).

Иначе, в случае переключения ролей (смены лидера в кластере), будут применяться настройки лидирующего узла.

примечание

Следует отметить, что в случае понижения параметра pgaudit.log до уровня none аудит событий будет полностью отключен и в таком случае последующее повышение уровня в журнале сообщений отражено не будет.

Для возможности мониторинга включения аудита реализована функция проверки check_pg_audit_is_on().

Параметры

pgaudit.log

Настраиваемый параметр конфигурации pgaudit.log указывает, какие классы событий, функций и операторов будут регистрироваться при ведении журнала аудита сессии. Возможные значения:

READ: SELECTи COPY, если источник — отношение или запрос;
WRITE: INSERT, UPDATE, DELETE, TRUNCATE, и COPY, если цель — отношение;
FUNCTION: вызовы функций и блоки DO;
ROLE: операторы, связанные с ролями и привилегиями: GRANT, REVOKE, CREATE/ALTER/DROP ROLE;
DDL: все DDL, не входящие в класс ROLE;
MISC: прочие операторы, включая DISCARD, FETCH, CHECKPOINT, VACUUM, SET;
MISC_SET: прочие операторы SET, включая SET ROLE;
MISC_SET_ROLE: только события выполнения команд SET ROLE/RESET ROLE;
CONNECTION: события, связанные с подключением к серверу. Существуют 4 типа таких событий: OPEN, CLOSED, FAILED, CHANGE USER. Событие FAILED регистрируется в случае неудачной попытки аутентификации по паролю и независимо от значения pgaudit.log;
PROTECTION: функции настройки механизма защиты от привилегированных пользователей;
RECOVERY: события восстановления базы данных;
INTEGRITY: события нарушения целостности объектов контроля;
ACTION: события запуска/остановки базы данных с причиной остановки;
PARAMETER: события изменения конфигурации системы управления базами данных;
ALL: включить все вышеперечисленное.

Значение по умолчанию:

в случае ручной установки СУБД: pgaudit.log = 'none';
в случае установки СУБД при использовании скриптов автоматизации: pgaudit.log = 'ddl, role, connection, misc_set, protection'.

Для применения измененного значения данного параметра необходимо перечитать конфигурацию. Для добавления новых классов событий (RECOVERY, INTEGRITY, ACTION и PARAMETER) необходимо включить параметр pgaudit.legal.

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

подсказка

Чтобы ограничить количество записей аудита отношений для команд DML, рассмотрите возможность использования журнала аудита объектов. Ведение журнала аудита объектов позволяет выбрать отношения, которые будут регистрироваться, что позволяет уменьшить общий объем журнала. Однако все новые создаваемые отношения должны быть явно добавлены в журнал аудита объектов. В этом случае хорошим вариантом может быть программное решение, в котором некоторые определенные таблицы исключаются из ведения журнала, а все остальные включаются. Подробнее в подразделе «Ведение журнала аудита объектов».

Дополнительные параметры

Другие параметры аудита, помимо pgaudit.log, описаны в данном подразделе. Для применения данных параметров достаточно перечитать конфигурацию.

Конфигурационные параметры аудита
Параметр	Описание	Тип	Значение
`pgaudit.legal`	Включение/отключение расширенных возможностей аудита: запись логов аудита в отдельный файл, регистрация дополнительных событий аудита, использование нового формата событий аудита. Для активации указанных в таблице параметров аудита (и добавления в `pgaudit.log` новых классов событий) необходимо включить данный параметр (`pgaudit.legal` = `on`)	`boolean`	Параметр может быть установлен в значения `on/off`, применяется при перезапуске сервера. Значение по умолчанию - `off`
`pgaudit.log_syslog`	Включение/отключение записи логов аудита в системный журнал при включенной записи в файл	`boolean`	По умолчанию - `off`
`pgaudit.log_directory`	Путь к каталогу для сохранения файлов аудита. Это может быть абсолютный путь или заданный относительно каталога данных (`$PGDATA`)	`string`	Значение по умолчанию - `audit` Файлы аудита будут созданы в каталоге `$PGDATA/audit`
`pgaudit.log_filename`	Используемый шаблон имен файлов для журналов событий	`string`	Шаблон может содержать спецпоследовательности, определяющие временную метку, которые начинаются со знака `%`. Значение по умолчанию `audit-%Y-%m-%d_%H%M%S.log`
`pgaudit.log_rotation_size`	Максимальный размер файла CSV-журнала в килобайтах. При достижении установленного лимита для записи событий безопасности создается новый файл	`integer`	Если параметр равен `0`, новый файл в зависимости от размера текущего создаваться не будет. Значение по умолчанию `10240` (10 Мбайт)
`pgaudit.log_rotation_age`	Максимальное время жизни файла журнала в минутах. По истечении этого времени создается новый файл для записи событий безопасности	`integer`	Если параметр равен `0`, создание новых файлов журналов по времени отключается. Значение по умолчанию - `1440`
`pgaudit.log_truncate_on_rotation`	Определяет, должны ли усекаться файлы журналов при переключении записи на уже существующий файл журнала. Параметр учитывается только при ротации по времени. В остальных случаях запись всегда продолжается в конец файла	`boolean`	Если значение параметра `off`, запись продолжается в конец файла. Значение по умолчанию - `off`
`pgaudit.log_file_mode`	Определяет права на файл аудита при создании и задается в восьмеричном виде	`integer`	Значение по умолчанию - `0600`
`pgaudit.log_recovery`	Параметр включает или отключает обработку фатальных ошибок, которые могут возникнуть при работе с файлами аудита	`boolean`	Значение по умолчанию - `off`
`pgaudit.log_catalog`	Указывает, должно ли быть включено ведение журнала сессии в том случае, если все отношения в операторе находятся в `pg_catalog`. Отключение этого параметра уменьшит шум в журнале от таких инструментов, как `psql` и `pgAdmin`, которые часто обращаются к каталогу	`boolean`	Значение по умолчанию - `on`
`pgaudit.log_client`	Указывает, будут ли сообщения журнала видны клиентскому процессу, такому как `psql`. Этот параметр обычно следует оставить отключенным, но он может быть полезен для отладки или других целей	`boolean`	`pgaudit.log_client` активен только тогда, когда значение `pgaudit.log_level` задано. Значение по умолчанию - `off`
`pgaudit.log_level`	Указывает уровень журналирования, который будет использоваться для записей журнала (подробнее в подразделе «Уровни важности сообщений»). Обратите внимание, что значения `ERROR`, `FATAL` и `PANIC` не допускаются. Этот параметр используется для регрессионного тестирования, а также может быть полезен конечным пользователям для тестирования или других целей	`string`	Значение`pgaudit.log_level` используется только тогда, когда `pgaudit.log_client` включен; в противном случае будет использоваться значение по умолчанию. Значение по умолчанию - `log`
`pgaudit.log_parameter`	Указывает, что ведение журнала аудита должно включать параметры, переданные вместе с оператором. При наличии параметров они будут включены в формате CSV после текста оператора	`boolean`	Значение по умолчанию - `off`
`pgaudit.log_relation`	Указывает, должно ли ведение журнала аудита сессии создавать отдельную запись журнала для каждого отношения (`TABLE`, `VIEW` и другие), на которое ссылается оператор `SELECT` или `DML`. Это полезный прием для исчерпывающего ведения журнала без использования журнала аудита объектов	`boolean`	Значение по умолчанию - `off`
`pgaudit.log_rows`	Указывает, что журнал аудита должен включать количество строк, извлеченных или затронутых оператором. При включении (`on`) поле строк будет указан после поля параметра (при `pgaudit.log_parameter` = `on`)	`boolean`	Значение по умолчанию - `off`
`pgaudit.log_statement`	Указывает, будет ли в журнал аудита включаться текст запроса и параметры (если это разрешено). В зависимости от требований журнал аудита может не нуждаться в этом, и это делает журналы менее подробными	`boolean`	Значение по умолчанию - `on`
`pgaudit.log_statement_once`	Указывает, будут ли текст и параметры оператора прикрепляться к первой записи в журнале для комбинации оператора и вложенных операторов или к каждой записи. Отключение этого параметра приведет к менее подробному ведению журнала, но может затруднить определение оператора, сгенерировавшего запись журнала, хотя пары оператора и вложенного оператора вместе с идентификатором процесса должно быть достаточно для идентификации текста оператора, записанного в предыдущей записи	`boolean`	Значение по умолчанию - `off`
`pgaudit.misc_set_exclude`	Указывает, какие события `SET` не должны логироваться. Дает возможность анализа других событий `SET` помимо `SET ROLE`, через систему аудита, без большого количества избыточной информации. Параметр уменьшает количество логов только при `pgaudit.log` = `ALL`/`MISC`/`MISC_SET`	`string`	Принимает значения `configuration_parameter` или TIME ZONE. В параметр `pgaudit.misc_set_exclude` нельзя добавлять значение `role` и `session_authorization`. Значение по умолчанию отсутствует
`pgaudit.role`	Указывает главную роль, используемую для ведения журнала аудита объектов. Можно определить несколько ролей аудита, закрепив их главной роли. Это позволяет нескольким группам отвечать за различные аспекты ведения журнала аудита	`string`	Значение по умолчанию отсутствует

Управление

Важно

В СУБД Pangolin только пользователи с правами superuser могут настраивать аудит и управлять им. Параметры аудита могут быть установлены как в файле конфигурации, так и командой ALTER SYSTEM SET. При попытке изменить параметр командой SET пользователь получит предупреждение и значение параметра не изменится.

Если разрешить обычным пользователям изменять свои настройки, то ведение журнала аудита утрачивает значение.

Настройки не наследуются через обычное наследование ролей, и SET ROLE не изменит настройки pgaudit пользователя. Это ограничение системы ролей, а не особенность pgaudit.

Просмотр настройки аудита

Параметры аудита событий хранятся в системном каталоге кластера и отображаются через системное представление pg_settings:

SELECT name, setting, context FROM pg_settings WHERE name LIKE 'pgaudit%';

Пример вывода:

┌──────────────────────────────────┬─────────────────────────────────────────────┬────────────┐
│               name               │                   setting                   │  context   │
├──────────────────────────────────┼─────────────────────────────────────────────┼────────────┤
│ pgaudit.legal                    │ off                                         │ postmaster │
│ pgaudit.log                      │ ddl, role, connection, misc_set, protection │ superuser  │
│ pgaudit.log_catalog              │ on                                          │ superuser  │
│ pgaudit.log_client               │ off                                         │ superuser  │
│ pgaudit.log_directory            │ audit                                       │ sighup     │
│ pgaudit.log_file_mode            │ 0600                                        │ sighup     │
│ pgaudit.log_filename             │ audit-%Y-%m-%d_%H%M%S.log                   │ sighup     │
│ pgaudit.log_level                │ log                                         │ superuser  │
│ pgaudit.log_parameter            │ off                                         │ superuser  │
│ pgaudit.log_recovery             │ off                                         │ sighup     │
│ pgaudit.log_relation             │ off                                         │ superuser  │
│ pgaudit.log_rotation_age         │ 1440                                        │ sighup     │
│ pgaudit.log_rotation_size        │ 10240                                       │ sighup     │
│ pgaudit.log_rows                 │ off                                         │ superuser  │
│ pgaudit.log_statement            │ on                                          │ superuser  │
│ pgaudit.log_statement_once       │ off                                         │ superuser  │
│ pgaudit.log_syslog               │ off                                         │ sighup     │
│ pgaudit.log_truncate_on_rotation │ off                                         │ sighup     │
│ pgaudit.misc_set_exclude         │                                             │ superuser  │
│ pgaudit.role                     │                                             │ superuser  │
└──────────────────────────────────┴─────────────────────────────────────────────┴────────────┘
(20 rows)

В данном выводе команды можно увидеть список возможных параметров аудита и их заданные значения (в примере это значения по умолчанию). Также в поле context отражено, что они не требуют перезагрузки сервера (кроме pgaudit.legal), для их изменения достаточно перечитать конфигурационные файлы командой SELECT pg_reload_conf().

Настройка вывода логов аудита в отдельный журнал

Настройка вывода логов аудита в отдельный журнал регулируется параметром pgaudit.legal.

Пример настройки:

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

pgaudit.log = 'all'
pgaudit.legal = 'on'
pgaudit.log_level = 'log'

При необходимости изменения директории и наименования файла требуется изменить соответствущие параметры: pgaudit.log_directory и pgaudit.log_filename.

Ротация файлов аудита

Файлы аудита могут быть ротированы в процессе записи событий аудита. В функциональность встроено четыре механизма ротации файлов аудита:

по запросу (сигнал SIGUSR1);
при изменении параметров pgaudit.log_directory, pgaudit.log_filename;
по размеру файла (размер файла, при превышении которого произойдет ротация, настраивается параметром pgaudit.log_rotation_size);
по времени (период ротации настраивается параметром pgaudit.log_rotation_age).

Если файл со сформированным при ротации именем уже существует на диске, то запуск очистки старого содержимого будет регулироваться значением параметра pgaudit.log_truncate_on_rotation:

Параметр	Ротация по запросу	Ротация при изменении параметров	Ротация по размеру	Ротация по времени
on	дозапись	дозапись	дозапись	дозапись
off	дозапись	дозапись	дозапись	очистка

Если во время ротации по времени или размеру происходит ошибка, то эти механизмы ротации отключаются. Чтобы вновь включить ротацию по времени или размеру, выполните ротацию по запросу или обновите параметры, влияющие на имя файла аудита.

Логика механизма ротации приведена ниже:

примечание

Данное поведение совпадает с механизмом ротации логов базы данных.

Настройка доступа к журналу событий безопасности

Журнал событий аудита представляет собой коллекцию текстовых файлов. Файлы можно просмотреть средствами операционной системы. Чтобы разграничить доступ к этим файлам, необходимо настроить чтение файлов журнала на уровне SQL. Для этого рекомендуется использовать расширение file_fdw — обертку сторонних данных для обращения к файлам на сервере.

Инструкция по разграничению доступа к журналу аудита:

Установите file_fdw и создайте определение стороннего сервера:
```
CREATE EXTENSION file_fdw;
CREATE SERVER pangolin_audit_server FOREIGN DATA WRAPPER file_fdw;
```
Создайте стороннюю таблицу, определив ее столбцы и указав абсолютный путь к файлу журнала. Фактический путь определяется параметрами pgaudit.log_directory и pgaudit.log_filename:
```
CREATE FOREIGN TABLE pangolin_audit
     ( audit_time timestamp(3) with time zone,
       role_name text,
       database_name text,
       process_id bigint,
       remote_host_port text,
       session_id text,
       session_line_num bigint,
       ps_display text,
       session_start_time timestamp(3) with time zone,
       virtual_transaction_id text,
       transaction_id bigint,
       error_severity text,
       sql_state text,
       audit_data text,
       audit_detailed text,
       audit_hint text,
       internal_query text,
       internal_query_position text,
       context text,
       user_query text,
       user_query_position text,
       file_position text,
       app_name text,
       backend_type text,
       leader_id text,
       query_id bigint)
SERVER pangolin_audit_server
OPTIONS (filename '{path_to_log}', FORMAT 'csv');
```
Где {path_to_log} – абсолютный путь к файлу журнала аудита.

примечание
Если журнал аудита состоит из множества файлов (настройка pgaudit.log_filename содержит временные метки, а также включена ротация файлов по времени или размеру), то необходимо создавать одну родительскую таблицу, определяющую формат, с множеством дочерних таблиц для доступа к отдельным файлам журнала. Количество файлов зависит от настроек аудита.
Сделайте файлы журнала аудита доступными только для владельца и установите в значение 0600 (значение по умолчанию) параметр pgaudit.log_file_mode.

Если файлы уже созданы, то для каждого из них выполните команду:
```
chmod 600 <файл_журнала_аудита>
```
Настройте ограничения доступа к определенным записям журнала: создайте отдельные представления на базе таблицы pangolin_audit и разрешите чтение этих представлений, используя встроенные механизмы управления доступом СУБД Pangolin.

Далее приведен пример по разграничению доступа к журналу аудита, разбитому по дням недели:

Выполните пункт 1 из инструкции по разграничению доступа к журналу аудита, приведенной выше.
Настройте параметры аудита для включения ротации по дням недели:
```
pgaudit.log_filename = 'audit-%u.log'
pgaudit.log_directory = '/pgdata/0{major_version}/data/audit'
pgaudit.log_rotation_age = 1440
pgaudit.log_rotation_size = 0
pgaudit.log_truncate_on_rotation = on
```
Где /pgdata/0{major_version}/data – путь к каталогу данных.

Создайте пустые файлы журнала аудита для семи дней недели и сделайте их доступными только для владельца:

touch /pgdata/0{major_version}/data/audit/audit-1.log
touch /pgdata/0{major_version}/data/audit/audit-2.log
touch /pgdata/0{major_version}/data/audit/audit-3.log
touch /pgdata/0{major_version}/data/audit/audit-4.log
touch /pgdata/0{major_version}/data/audit/audit-5.log
touch /pgdata/0{major_version}/data/audit/audit-6.log
touch /pgdata/0{major_version}/data/audit/audit-7.log
chmod 600 /pgdata/0{major_version}/data/audit/audit-*.log

Создайте таблицу для чтения записей журнала:

CREATE TABLE pangolin_audit
   ( audit_time timestamp(3) with time zone,
     role_name text,
     database_name text,
     process_id bigint,
     remote_host_port text,
     session_id text,
     session_line_num bigint,
     ps_display text,
     session_start_time timestamp(3) with time zone,
     virtual_transaction_id text,
     transaction_id bigint,
     error_severity text,
     sql_state text,
     audit_data text,
     audit_detailed text,
     audit_hint text,
     internal_query text,
     internal_query_position text,
     context text,
     user_query text,
     user_query_position text,
     file_position text,
     app_name text,
     backend_type text,
     leader_id text,
     query_id bigint);

Создайте для таблицы pangolin_audit семь дочерних сторонних таблиц (для каждого дня недели):

CREATE FOREIGN TABLE pangolin_audit_1 () INHERITS (pangolin_audit) SERVER pangolin_audit_server
OPTIONS (filename '/pgdata/0{major_version}/data/audit/audit-1.log',  FORMAT 'csv');
CREATE FOREIGN TABLE pangolin_audit_2 () INHERITS (pangolin_audit) SERVER pangolin_audit_server
OPTIONS (filename '/pgdata/0{major_version}/data/audit/audit-2.log',  FORMAT 'csv');
CREATE FOREIGN TABLE pangolin_audit_3 () INHERITS (pangolin_audit) SERVER pangolin_audit_server
OPTIONS (filename '/pgdata/0{major_version}/data/audit/audit-3.log',  FORMAT 'csv');
CREATE FOREIGN TABLE pangolin_audit_4 () INHERITS (pangolin_audit) SERVER pangolin_audit_server
OPTIONS (filename '/pgdata/0{major_version}/data/audit/audit-4.log',  FORMAT 'csv');
CREATE FOREIGN TABLE pangolin_audit_5 () INHERITS (pangolin_audit) SERVER pangolin_audit_server
OPTIONS (filename '/pgdata/0{major_version}/data/audit/audit-5.log',  FORMAT 'csv');
CREATE FOREIGN TABLE pangolin_audit_6 () INHERITS (pangolin_audit) SERVER pangolin_audit_server
OPTIONS (filename '/pgdata/0{major_version}/data/audit/audit-6.log',  FORMAT 'csv');
CREATE FOREIGN TABLE pangolin_audit_7 () INHERITS (pangolin_audit) SERVER pangolin_audit_server
OPTIONS (filename '/pgdata/0{major_version}/data/audit/audit-7.log',  FORMAT 'csv');

Выполните пункт 4 из инструкции по разграничению доступа к журналу аудита выше.

Оповещение о событиях безопасности

В СУБД Pangolin предусмотрена настройка механизма оповещения администратора системы управления базами данных, администратора базы данных (администратора информационной системы) о событиях безопасности. Далее приведен скрипт оповещения администраторов:

#!/bin/sh

# Адрес/адреса администраторов
admins="admin@localhost admin1@localhost admin2@localhost"

# В зависимости от параметров конфигурации аудита указывается множество файлов журнала
# Например, если
#     pgaudit.log_filename = 'audit-%u.log'
#     pgaudit.log_directory = '/pgdata/0{major_version}/data/audit'
# то audit_files=/pgdata/0{major_version}/data/audit/audit-*.log
audit_files={множество_файлов_журнала}

# Каталог для хранения временных файлов, которые создаются в процессе работы скрипта
# Необходимы права для модификации данного каталога
audit_tmp_directory={каталог_для_хранения_временных_файлов}

# Пересоздание каталога для хранения временных файлов
rm -rf $audit_tmp_directory
mkdir $audit_tmp_directory

# Проверка наличия необходимых утилит для скрипта
t="inotifywait sendmail"
if [ "$(which $t &>/dev/null; echo $?)" != 0 ]
  then
    echo "ERROR: [$t] tools not available! Exiting..."
    exit 1
fi

# Сохранение референсных файлов аудита
cp $audit_files $audit_tmp_directory

while true; do

# Ожидание изменений в любом из файлов журнала, возвращает полный путь до измененного файла
file_path=$(inotifywait --format %w -e modify $audit_files)
# Имя файла без пути
file_name=${file_path##*/}

# Сохранение измененного файла во временный каталог
# Последующие изменения журнала попадут в новые сообщения
cp $file_path $audit_tmp_directory/audit.tmp
# Сообщение для администратора - это новые данные аудита, добавленные в файл (относительно референцных)
audit_message=$(diff --changed-group-format='%<' --unchanged-group-format='' $audit_tmp_directory/audit.tmp $audit_tmp_directory/$file_name)

# Подготовка и отправка письма
# Для конструкции EOF в качестве отступов использовать <tab>
echo "send mail: $audit_message"

cat <<EOF | sendmail -t
To: $admins
Subject: audit event occurred

$audit_message
EOF

# Сохранение файла (после старого event'а) для последующего сравнения
mv $audit_tmp_directory/audit.tmp $audit_tmp_directory/$file_name

done

Для обеспечения возможности отправлять email-сообщения с серверов СУБД требуется наличие утилит: inotifywaitи sendmail.

Ведение журнала аудита сессии пользователя

примечание

Журнал аудита сессии (AUDIT_TYPE = SESSION) отображает подробные записи всех операций, выполняемых пользователем на сервере.

Ведение журнала сессии включается с помощью параметра pgaudit.log (по умолчанию включено). О настройке вывода логов аудита в отдельный журнал указано в одноименном разделе.

Варианты настройки:

Включить ведение журнала сессии для всех WRITE и DDL и протоколировать все отношения в операторах DML:
```
SET pgaudit.log = 'write, ddl';

SET pgaudit.log_relation = 'on';
```
Включить ведение журнала сессии для всех команд, кроме MISC, и выводить сообщения журнала аудита с пометкой NOTICE:
```
SET pgaudit.log = 'all, -misc';

SET pgaudit.log_level = 'notice';
```

Использование журнала аудита сессии для ведения фиксаций операторов DDL и READ:

примечание

Оператор INSERT не регистрируется, так как класс WRITE не включен.

Пример запросов:

SET pgaudit.log = 'read, ddl';

CREATE TABLE account
(
 id int,
 name text,
 password text,
 description text
);

INSERT INTO account (id, name, password, description)
          VALUES (1, 'user1', 'HASH1', 'blah, blah');

SELECT *
 FROM account;

Пример вывода в журнале:

AUDIT: SESSION,1,1,DDL,CREATE TABLE,TABLE,public.account,CREATE TABLE account
(
 id int,
 name text,
 password text,
 description text
);,<not logged>
AUDIT: SESSION,2,1,READ,SELECT,,,SELECT *
 FROM account,,<not logged>

Ведение журнала аудита объектов

примечание

Журнал аудита объектов регистрирует операторы, влияющие на определенное отношение. Поддерживаются только команды SELECT, INSERT, UPDATE и DELETE. Операция TRUNCATE не включается в журнал аудита объектов.

Ведение журнала аудита объектов — более подробная альтернатива pgaudit.log = 'read, write'. Нет смысла использовать их вместе, но можно, например, использовать ведение журнала сеансов для регистрации каждого оператора, а затем дополнить его ведением журнала объектов, чтобы получить более подробную информацию о конкретных отношениях.

Ведение журнала аудита на уровне объектов осуществляется через систему ролей. Параметр pgaudit.role определяет роль, которая будет использоваться для ведения журнала аудита. Отношение (TABLE, VIEW) будет записываться в журнал аудита, если роль аудита имеет разрешения для выполняемой команды или наследует разрешения от другой роли. Это позволяет эффективно использовать несколько ролей аудита, даже если в любом контексте существует одна главная роль.

Задайте для pgaudit.role значение auditor и наделите ее правами SELECT и DELETE над таблицей account. Теперь операции SELECT и DELETE (выполненные любой ролью) над таблицей account будут заноситься в журнал:

SET pgaudit.role = 'auditor';

GRANT SELECT, DELETE
   ON public.account
   TO auditor;

В примере ниже ведение журнала аудита объектов используется для иллюстрации того, как может быть применен детализированный подход к журналированию операторов SELECT и DML. Обратите внимание, что ведение журнала операций над таблицей account контролируется разрешениями на уровне столбцов, а ведение журнала операций над таблицей account_role_map — на уровне таблиц.

Пример запросов:

SET pgaudit.role = 'auditor';

CREATE TABLE account
(
    id int,
    name text,
    password text,
    description text
);

GRANT SELECT (password)
   ON public.account
   TO auditor;

SELECT id, name
  FROM account;

SELECT password
  FROM account;

GRANT UPDATE (name, password)
   ON public.account
   TO auditor;

UPDATE account
   SET DESCRIPTION = 'yada, yada';

UPDATE account
   SET PASSWORD = 'HASH2';

CREATE TABLE account_role_map
(
    account_id int,
    role_id int
);

GRANT SELECT
   ON public.account_role_map
   TO auditor;

SELECT account.password,
       account_role_map.role_id
  FROM account
       INNER JOIN account_role_map
            ON account.id = account_role_map.account_id

Пример вывода в журнале:

AUDIT: OBJECT,1,1,READ,SELECT,TABLE,public.account,SELECT password
  FROM account,<not logged>
AUDIT: OBJECT,2,1,WRITE,UPDATE,TABLE,public.account,UPDATE account
   SET PASSWORD = 'HASH2',<not logged>
AUDIT: OBJECT,3,1,READ,SELECT,TABLE,public.account,SELECT account.password,
       account_role_map.role_id
  FROM account
       INNER JOIN account_role_map
            ON account.id = account_role_map.account_id,<not logged>
AUDIT: OBJECT,3,1,READ,SELECT,TABLE,public.account_role_map,SELECT account.password,
       account_role_map.role_id
  FROM account
       INNER JOIN account_role_map
            ON account.id = account_role_map.account_id,<not logged>

Диагностика ошибок

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

Если во время ротации файла аудита происходит ошибка, то реакция зависит от параметра pgaudit.log_recovery:

включен — лог аудита продолжает записываться в текущий файл, при этом в лог базы данных выводятся предупреждения о невозможности ротации:
```
WARNING: Could not rotate audit file: ошибка
WARNING: Recovery mode is on: continue writing to the current file "<file_name>"
```
выключен — Pangolin останавливается с фатальной ошибкой:
```
FATAL: Could not rotate audit file: ошибка
```

Если во время записи в файл происходит ошибка, то реакция зависит от параметра pgaudit.log_recovery и кода ошибки.

При включенном pgaudit.log_recovery:

`errno`	Описание	Реакция `auditlogger`	Сообщение в лог
`EAGAIN`	Установлен флаг `O_NONBLOCK`	Ошибка не ожидается, обработка неопределенной ошибки	Не выводится
`EBADF`	Запись происходит в невалидный дескриптор	Повторная запись во временный файл	Не выводится
`EFBIG`	Попытка записи в файл, превышающий максимальный размер (лимит), доступный в системе	Повторная запись во временный файл	Не выводится
`EINTR`	Операция записи прервана	Повторная запись в текущий файл	Не выводится
`EIO`	Ошибка записи на физическом уровне	Повторная запись во временный файл	Не выводится
`ENOSPC`	На устройстве нет памяти	Фатальная ошибка	`FATAL: An unhandled error occurred: ошибка, Fail to write audit data: сообщенние аудита`
`EPIPE`	Ошибка записи в pipe	Ошибка не ожидается, обработка неопределенной ошибки	Не выводится
`ENOMEM`	На устройстве нет памяти	Фатальная ошибка	`FATAL: An unhandled error occurred: ошибка, Fail to write audit data: сообщенние аудита`
`?`	Неопределенная ошибка	Повторная запись во временный файл	`WARNING: Unknown error: ошибка`

Имя временного файла получается из имени текущего файла с добавлением .recovery. При создании временного файла выводится предупреждение:

WARNING:  Create recovery audit file имя временного файла

Повторная ошибка при записи во временный файл приводит к остановке СУБД:

FATAL: Fail to write audit data: сообщение аудита

Если pgaudit.log_recovery выключен, то попытки создать и записать сообщение во временный файл не происходит, СУБД останавливается сразу:

FATAL: Fail to write audit data: сообщение аудита

Ошибка может произойти при отправке сообщения аудита, реакция зависит от параметра pgaudit.log_recovery:

включен — сообщение аудита будет отправлено в лог СУБД Pangolin, который так же будет содержать предупреждение:
```
WARNING: Could not write audit message: ошибка
```
выключен — процесс, который отправляет сообщение аудита, завершается с ошибкой:
```
FATAL: Could not write audit message: ошибка
```

При возникновении ошибки ERROR: SET command is prohibited for pgaudit parameters обратите внимание на ограничения по настройке параметров. Настройки недоступны к изменению в рамках текущей сессии.

В случае указания исключенного класса событий pg_background в значения параметра pgaudit.log возникнет ошибка:

DEBUG1: Using pg_background at pgaudit.log parameter is deprecated, ignored

Обновление

Обратите внимание, что при обновлении с версии ранее чем 6.2.0 (где функциональность еще не реализована), для работы новой функциональности аудита необходимо выполнить скрипт, добавляющий новые функции.

Сценарии использования

Мониторинг проверки включения механизма аудита (check_pg_audit_is_on()):
```
SELECT * FROM check_pg_audit_is_on();

check_pg_audit_is_on
----------------------
t
(1 row)
```
Пример вывода информации класса PROTECTION при определенном сценарии:

Защита данных от привилегированных пользователей включена, администратор безопасности выполняет запрос SELECT * FROM pm_get_policies();.

Пример вывода в лог аудита:
```
AUDIT: SESSION,2,1,READ,SELECT,,,SELECT * FROM pm_get_policies();,<not logged>,<ID>,LOW
AUDIT: SESSION,2,2,PROTECTION,LIST,POLICY,,""Output list of policies"",<ID>,MEDIUM
AUDIT: SESSION,2,2,PROTECTION,LIST,POLICY,,""Output list of policies"",SUCCESS,<ID>,MEDIUM
```
Пример вывода информации класса PARAMETER при определенном сценарии:

Текущие настройки аудита:
```
pgaudit.log = 'ddl, misc_set, role, connection, recovery, parameter, action'

pgaudit.legal = 'on'
```
Пользователь производит изменение параметра pgaudit.log_client в файле конфигурации и изменение параметра work_mem запросом ALTER SYSTEM SET.

После перечитывания конфигурации (pg_reload_conf()) в лог выведены следующие записи:
```
AUDIT: SESSION, PARAMETER, parameter ""work_mem"" changed from ""16384"" to ""17408"", <ID>, HIGH
AUDIT: SESSION, PARAMETER, parameter ""pgaudit.log_client"" changed from ""on"" to ""off"", <ID>, HIGH
```

Журналирование сообщений компонента Pangolin Manager

примечание

Доступен при кластерной конфигурации СУБД.

Перенаправление записи лога из системного журнала в файл

Функциональность позволяет перенаправить запись лога Pangolin Manager в файл, вместо системного журнала (journald).

Настройка

Для включения перенаправления лога в файл необходимо в конфигурационном файле postgres.yml настроить параметры в секциях audit и log:

audit:
   enabled: true
   directory: /pangolinlogs/audit
   filename: pangolin-manager
   rotation_age: 1d
   rotation_size: 10M
   file_mode: 660
log:
   dir: /pangolinlogs/pangolin-manager
   file_name: pangolin-manager-%Y-%m-%d_%H%M%S.log
   destination: file
   file_mode: 600
   redirect_min_size: 10

Секция audit отвечает за настройку аудита событий безопасности компонента, а секция log за логирование событий действий компонента.

Одновременно для логирования (log) может быть активен только один канал вывода: или системный журнал, или лог-файл. Для переключения вывода лога достаточно команды reload (параметр destination).

примечание

Если Pangolin Manager не имеет доступа к директории, указанной в параметре log.dir (а далее и в параметре audit.directory) логирования или не может создать файл, указанный в параметре file_name, то вывод осуществляется в системный журнал.

Для повышения удобства эксплуатации, в старое место назначения записи лога выводится информационная строка, сообщающая куда именно будет проводиться дальнейший вывод логированной информации (syslog или полное имя файла). Это строчка может быть не последней – это специфика работы буферизации вывода.

Параметры

Описание параметров:

секция audit:
- enabled: true – активирует аудит событий безопасности.
- directory: /pangolinlogs/audit – определяет каталог, в котором будут созданы файлы журнала аудита. В случае если указанная директория не существует, Pangolin Manager попытается создать (права на директорию 600). В случае если создать директорию не удастся, в лог будет выведено сообщение, а логирование продолжится в предыдущий файл:
```
Failed to create directory for audit log file, permission denied.
Correct 'audit.directory' parameter in config file
and ensure that user has write permissions on specified directory.
```
- filename: pangolin-manager – отвечает за имя лог-файла аудита. Если включена любая из ротаций, то к имени файла через дефис добавляется дата создания в формате %Y-%m-%d_%H%M%S.
- rotation_age: 1d – определяет максимальное время использования отдельного лог-файла, после которого будет создан новый файл.
- rotation_size: 10M – определяет максимальный размер отдельного лог-файла (в Мбайтах). После того, как это количество данных было записано в файл журнала, будет создан новый файл журнала.
- file_mode: 600 – устанавливает права доступа к лог-файлу аудита.
секция log:
- dir: /pangolinlogs/pangolin-manager – определяет каталог, в котором будут созданы файлы логирования.
- destination: file – отвечает за вывод в лог-файл, значение по умолчанию file. Если значение установлено в syslog вывод осуществляется в journald. Соответствует переменной окружения PATRONI_LOG_DESTINATION. Для применения параметра достаточно выполнения reload.
- file_name: pangolin-manager.log – отвечает за имя лог-файла, значение по умолчанию pangolin-manager.log. Соответствует переменной окружения PATRONI_LOG_FILE_NAME. Применение параметра производится только после остановки/перезапуска Pangolin средствами systemctl.
- file_mode: 600 – устанавливает права доступа к лог-файлу. Применение параметра производится только после остановки/перезапуска Pangolin средствами systemctl.
- redirect_min_size: 10 – устанавливает размер минимально свободного места (в Кбайтах) в системе для логирования, при достижении которого происходит переключение потока логирования в системный журнал. При установке redirect_min_size: 0, для ускорения работы Pangolin Manager, проверка свободного места не осуществляется. После освобождения места в папке логирования необходимо выполнить команду reload и логирование продолжится в файл.

примечание

Дополнительные параметры, отвечающие за директорию и настройки ротации остались без изменений относительно оригинальной реализации.

Табличное представление параметров

Табличное представление параметров логирования (включает присвоение значение из переменной окружения – внимание, для сервиса источником переменных окружения являются только настройки .service-файла):

Параметр	Переменная окружения	Значение по умолчанию	Влияние
`log: destination`	`PATRONI_LOG_DESTINATION`	`file`	Применяется при загрузке/перезагрузке сервиса и демона (`systemctl --user daemon-reload`)
`log: file_name`	`PATRONI_LOG_FILE_NAME`	`pangolin-manager.log`	Применяется при загрузке/перезагрузке сервиса и демона (`systemctl --user restart pangolin-manager`)
`log: file_mode`	`PATRONI_LOG_FILE_MODE`	`644`	Применяется при загрузке/перезагрузке сервиса и демона (`systemctl --user daemon-reload`)
`log: redirect_min_size`	`PATRONI_LOG_REDIRECT_MIN_SIZE`	`10`	Применяется при загрузке/перезагрузке сервиса и демона (`systemctl --user restart pangolin-manager`)

Управление

Настройка вывода лога Pangolin Manager в файл (pangolin-manager.log)

Задайте значения для параметров destination, dir и filename в конфигурационном файле postgres.yml.

Пример вывода настроек:
```
log:
  dir: /pangolinlogs/pangolin-manager
  destination: file
  file_name: pangolin-manager.log
  file_mode: 644
  redirect_min_size: 10
```
Выполните команду date (текущая отметка времени).

Пример вывода:
```
Fri Jun 28 15:07:22 MSK 2024
```
Выполните команду reload.
```
systemctl reload pangolin-manager
```

Выведите записи из лога о процессе reload на экран.

Пример записи выведенной на экран:

2024-06-28 15:08:38,311 INFO: No local configuration items changed.
2024-06-28 15:08:38,324 INFO: REST API: server's certificate is not changed
2024-06-28 15:08:38,328 INFO: Changed archive_command from (disabled) to /usr/pangolin-dbms-client-{product_name}/bin/pg_probackup archive-push -B /pgarclogs/0{major_version} --instance clustername --wal-file-path=%p --wal-file-name=%f --compress --overwrite -j 4 --batch-size=100
2024-06-28 15:08:38,328 INFO: Changed archive_mode from off to False (restart might be required)
2024-06-28 15:08:38,329 INFO: Changed autounite_pause_period from Autounite pause period is not set to
2024-06-28 15:08:38,329 INFO: Changed DateStyle from ISO, MDY to iso, mdy
2024-06-28 15:08:38,329 INFO: Changed pg_hint_plan.debug_print from off to False
2024-06-28 15:08:38,329 INFO: Changed pg_stat_kcache.linux_hz from 1000000 to -1

Задание параметра через файл pangolin-manager.service

Задайте значение параметра file_name в pangolin-manager.service.

Пример вывода о заданном значении:
```
Environment="PATRONI_LOG_FILE_NAME=pangolin_manager_new.log"
```
Выполните перечитывание конфигурации служб и перезапустите сервис pangolin-manager:
```
systemctl --user daemon-reload
systemctl --user restart pangolin-manager
```
примечание
При необходимости можно убедиться в успешности выполнения команд с помощью команды list.

Убедитесь, что вывод идет в нужный файл. Откройте файл pangolin_manager_new.log для просмотра.

Пример вывода лога:

2024-06-28 15:49:47,832 AUDIT: <STATEMENT ID>;2024-06-28-12-49-47.832429;Низкий;события, связанные с управлением журналами (записями) регистрации событий безопасности;;Начата запись журнала регистрации событий безопасности
2024-06-28 15:49:47,832 AUDIT: <STATEMENT ID>;2024-06-28-12-49-47.832582;Cредний;события, связанные с управлением журналами (записями) регистрации событий безопасности;;Заданы параметры ротации файла журнала событий безопасности;путь=<путь>;имя=pangolin-manager;период=86400;размер=10000000
2024-06-28 15:49:47,834 INFO: Returning dcs class with pangolin_dcs
2024-06-28 15:49:47,834 INFO: DCS (init):  self_addr is: {host_name}
2024-06-28 15:49:47,834 INFO: DCS (init):  partner_addrs is: {'{host_name}', '{host_name}'}
2024-06-28 15:49:47,834 INFO: DCS (init):  data directory is set to /pgdata/0{major_version}/raft_data
2024-06-28 15:49:47,834 INFO: DCS (init):  dump directory is set to /pgdata/0{major_version}/raft_dump

Описание​

Уровни важности сообщений журналирования​

Уровни важности событий аудита​

Формат​

Префикс строки системного журнала​

Формат отдельных классов регистрируемых событий​

События подключения к серверу​

События вызова функций настройки механизма защиты от привилегированных пользователей​

Устранение избыточного маскирования для событий аудита класса PROTECTION​

События восстановления базы данных​

События нарушения целостности объектов контроля​

События запуска/остановки базы данных с причиной остановки​

События изменения конфигурации системы управления базами данных​

Настройка​

Настройка журналирования​

Настройка аудита​

Параметры​

pgaudit.log​

Дополнительные параметры​

Управление​

Просмотр настройки аудита​

Настройка вывода логов аудита в отдельный журнал​

Ротация файлов аудита​

Настройка доступа к журналу событий безопасности​

Оповещение о событиях безопасности​

Ведение журнала аудита сессии пользователя​

Ведение журнала аудита объектов​

Диагностика ошибок​

Обновление​

Сценарии использования​

Журналирование сообщений компонента Pangolin Manager​

Перенаправление записи лога из системного журнала в файл​

Настройка​

Параметры​

Табличное представление параметров​

Управление​

Настройка вывода лога Pangolin Manager в файл (pangolin-manager.log)​

Задание параметра через файл pangolin-manager.service​

Описание

Уровни важности сообщений журналирования

Уровни важности событий аудита

Формат

Префикс строки системного журнала

Формат отдельных классов регистрируемых событий

События подключения к серверу

События вызова функций настройки механизма защиты от привилегированных пользователей

Устранение избыточного маскирования для событий аудита класса PROTECTION

События восстановления базы данных

События нарушения целостности объектов контроля

События запуска/остановки базы данных с причиной остановки

События изменения конфигурации системы управления базами данных

Настройка

Настройка журналирования

Настройка аудита

Параметры

pgaudit.log

Дополнительные параметры

Управление

Просмотр настройки аудита

Настройка вывода логов аудита в отдельный журнал

Ротация файлов аудита

Настройка доступа к журналу событий безопасности

Оповещение о событиях безопасности

Ведение журнала аудита сессии пользователя

Ведение журнала аудита объектов

Диагностика ошибок

Обновление

Сценарии использования

Журналирование сообщений компонента Pangolin Manager

Перенаправление записи лога из системного журнала в файл

Настройка

Параметры

Табличное представление параметров

Управление

Настройка вывода лога Pangolin Manager в файл (pangolin-manager.log)

Задание параметра через файл pangolin-manager.service