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

Описание

Пример

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

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

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

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

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

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

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

Пример

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

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

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

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

Уровни серьезности сообщений

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

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

Формат

примечание

Выходные данные соответствуют формату CSV (разделитель запятая) только в том случае, если префикс строки журнала каждой записи удален.

По умолчанию записи аудита записываются в стандартное средство ведения журнала (регулируются параметрами лог-файла) и содержат столбцы в формате 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

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

Для добавления любых других полей, необходимых для удовлетворения требований к системному журналу логов, используйте префикс строки (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\]:" - включить дату/время, имя пользователя, имя базы данных и идентификатор процесса для каждой записи журнала аудита.

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

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

Формат событий трассировки сессии

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

AUDIT_TYPE - всегда SESSION;
CLASS - всегда MISC;
STATEMENT_TYPE - всегда SET;
OBJECT_TYPE - всегда TRACING;
OBJECT_NAME - пусто;
COMMAND_TEXT — зависит от события:
- для события включения трассировки сессии сообщение вида: \"<start,числовое_значение_уровня_логирования,имя_лог-файла>\". Слово start является константой;
- для события выключения трассировки сессии содержит константу stop: \"<stop>\".

Пример:

LOG:  AUDIT: SESSION,1,1,MISC,SET,TRACING,,\"<start,15,/pgdata/0{major_version}/data/tracing/trace1.log>\",<not logged>
LOG:  AUDIT: SESSION,2,1,MISC,SET,TRACING,,\"<stop>\",<not logged>

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

Важно

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

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

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

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

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

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" (имя пользователя).

Пример:

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

Данный класс событий задан по умолчанию в pgaudit.log. Активация параметра pgaudit.legal для фиксации событий данного класса не требуется.

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

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

События 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.

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

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

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

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

Класс событий 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.

Для формирования таких событий в модуль pgaudit добавлена функция pgaudit_integrity_violation_event:

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

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

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

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

Поля:

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

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

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

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

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

Формат записи класса событий 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.

Настройка

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

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

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

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

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

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

pgaudit.log = 'ddl, role, connection, misc_set, protection'

Мониторинг дополнительных (отдельных классов) событий аудита определяется включением параметра 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: включить все вышеперечисленное.

Значение по умолчанию - 'ddl, role, connection, misc_set, protection'.

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

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

Совет

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

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

Конфигурационные параметры аудита

Параметр	Описание	Тип	Значение
`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.role`	Указывает главную роль, используемую для ведения журнала аудита объектов. Можно определить несколько ролей аудита, закрепив их главной роли. Это позволяет нескольким группам отвечать за различные аспекты ведения журнала аудита	`string`	Значение по умолчанию отсутствует

Управление

Важно

В СУБД Pangolin только пользователи с правами superuser могут настраивать аудит и управлять им.

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

Настройки не наследуются через обычное наследование ролей, и 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.role                     |                                             | superuser
(19 rows)

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

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

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

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 'абсолютный_путь_к_файлу_журнала_аудита', FORMAT 'csv');

примечание

Если журнал аудита состоит из множества файлов (настройка 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

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

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 из инструкции по разграничению доступа к журналу аудита выше.

Архивирование журнала при исчерпании области памяти, отведенной под журнал событий безопасности

Для архивирования журнала используйте утилиту logrotate.

Далее приведена инструкция по настройке архивирования журнала (при помощи утилиты logrotate):

Добавьте конфигурационный файл pangolin_audit в каталог /etc/logrotate.d/. Содержимое pangolin_audit:
```
{путь к файлам журнала аудита}
{
missingok
daily
copytruncate
notifempty
size 1G
compress
}
```
Опции:

missingok – не выдавать ошибки, если лог-файла не существует;
daily – обрабатывать журнал каждый день (с возможностью установить другой интервал проверки):
- hourly - каждый час;
- weekly - каждую неделю;
- monthly - каждый месяц;
- yearly - каждый год.
copytruncate – обрезать оригинальный файл до нулевого размера после создания копии вместо переименования оригинального файла и создания нового;
notifempty – не ротировать файл лога, если он пуст;
compress — сжатие логов;
size — размер лога, при достижении которого он будет перемещен (в примере выше указан 1 Гбайт).

Путь к файлам журнала аудита зависит от настроек, например, для настроек, приведенных далее, путь будет соответствовать /pgdata/0{major_version}/data/audit/audit-*.log.

Проверьте конфигурационный файл при помощи команды:
```
sudo logrotate /etc/logrotate.conf --debug
```
В каталоге аудита будут появляться архивированные логи аудита.

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

В СУБД 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-сообщения с серверов PG требуется наличие утилит: inotifywaitи sendmail.

Ведение журнала аудита сессии

Описание

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

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

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

Включить ведение журнала сессии для всех DML и 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 и SELECT:

примечание

Оператор 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>

Обновление

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

DO $$
DECLARE
  text_type_id integer;
  bool_type_id integer;
  int4_type_id integer;

BEGIN

-- Create new functions
CREATE FUNCTION pg_catalog.stop_recovery_event(text, text, text, bool, int4, bool)
 RETURNS void
 LANGUAGE internal
 STABLE PARALLEL SAFE STRICT
AS $function$stop_recovery_event$function$;

CREATE FUNCTION pg_catalog.start_recovery_event(text, text, text, bool)
 RETURNS boolean
 LANGUAGE internal
 STABLE PARALLEL SAFE STRICT
AS $function$start_recovery_event$function$;

SELECT oid INTO text_type_id FROM pg_type WHERE typname='text';
SELECT oid INTO bool_type_id FROM pg_type WHERE typname='bool';
SELECT oid INTO int4_type_id FROM pg_type WHERE typname='int4';

-- Update params for new functions
UPDATE pg_catalog.pg_proc AS pp SET
proallargtypes = ARRAY[text_type_id,text_type_id,text_type_id,bool_type_id,int4_type_id,bool_type_id],
proargmodes = '{i,i,i,i,i,i}',
proacl = '{postgres=X/postgres}'
WHERE pp.oid = (select oid from pg_catalog.pg_proc where proname = 'stop_recovery_event');

UPDATE pg_catalog.pg_proc AS pp SET
proallargtypes = ARRAY[text_type_id,text_type_id,text_type_id,bool_type_id],
proargmodes = '{i,i,i,i}',
proacl = '{postgres=X/postgres}'
WHERE pp.oid = (select oid from pg_catalog.pg_proc where proname = 'start_recovery_event');

GRANT EXECUTE ON FUNCTION pg_catalog.stop_recovery_event(text, text, text, bool, int4, bool) TO PUBLIC;
GRANT EXECUTE ON FUNCTION pg_catalog.start_recovery_event(text, text, text, bool) TO PUBLIC;

EXCEPTION
  WHEN duplicate_function THEN
  NULL;
END$$;

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

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

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

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

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

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

check_pg_audit_is_on
----------------------
t
(1 row)
```

Пример вывода информации класса PROTECTION при определенном сценарии:

Защита включена, пользователь sec_admin выполняет запрос SELECT pm_get_policies();.

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

AUDIT: SESSION,2,1,READ,SELECT,,,select pm_get_policies();,<not logged>
AUDIT: SESSION,2,2,PROTECTION,EXECUTE,FUNCTION,pg_catalog.pm_get_policies,select pm_get_policies();,<not logged>
AUDIT: SESSION,2,2,PROTECTION,EXECUTE,FUNCTION,pg_catalog.pm_get_policies,select pm_get_policies();,<not logged>,SUCCESS

Пример вывода информации класса 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 настроить параметры в секции log:

log:
destination: file
file_name: pangolin-manager.log
file_mode: 644
redirect_min_size: 10

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

примечание

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

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

Параметры

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

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: 644 – устанавливает права доступа к лог-файлу. Применение параметра производится только после остановки/перезапуска 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: /pgerrorlogs/0{major_version}
destination: file
file_name: pangolin-manager.log
file_size: 26214400
file_num: 4
file_mode: 644
redirect_min_size: 10

Выполните команду date (текущая отметка времени).

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

Выведите записи из лога о процессе 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-6.3.0/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"
```
Выполните команды перезапуска сервиса и релоада демона:
```
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

Описание​

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

Уровни серьезности сообщений​

Формат​

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

Формат событий трассировки сессии​

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

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

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

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

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

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

Настройка​

Параметры​

pgaudit.log​

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

Конфигурационные параметры аудита​

Управление​

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

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

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

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

Архивирование журнала при исчерпании области памяти, отведенной под журнал событий безопасности​

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

Ведение журнала аудита сессии​

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

Обновление​

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

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

Лог Pangolin Manager​

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

Настройка​

Параметры​

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

Управление​

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

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

Описание

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

Уровни серьезности сообщений

Формат

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

Формат событий трассировки сессии

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

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

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

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

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

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

Настройка

Параметры

pgaudit.log

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

Конфигурационные параметры аудита

Управление

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

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

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

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

Архивирование журнала при исчерпании области памяти, отведенной под журнал событий безопасности

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

Ведение журнала аудита сессии

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

Обновление

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

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

Лог Pangolin Manager

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

Настройка

Параметры

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

Управление

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

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