pgaudit/pgauditРасширение аудита PostgreSQL
Расширение PostgreSQL Audit Extension (pgAudit) обеспечивает детальное журналирование аудита сессий и/или объектов через стандартный механизм журналирования PostgreSQL.
Цель pgAudit — предоставить пользователям PostgreSQL возможность создавать журналы аудита, которые часто требуются для соответствия государственным, финансовым или ISO-сертификациям.
Аудит — это официальная проверка счетов физического лица или организации, обычно проводимая независимым органом. Информация, собираемая pgAudit, правильно называется контрольным следом или журналом аудита. В этой документации используется термин «журнал аудита».
Базовое журналирование операторов может быть обеспечено стандартным механизмом журналирования с помощью log_statement = all. Это приемлемо для мониторинга и других целей, но не обеспечивает уровень детализации, обычно требуемый для аудита. Недостаточно иметь список всех операций, выполненных над базой данных. Также должна быть возможность находить конкретные операторы, представляющие интерес для аудитора. Стандартный механизм журналирования показывает, что запросил пользователь, тогда как pgAudit фокусируется на деталях того, что произошло, пока база данных выполняла запрос.
Например, аудитор может захотеть проверить, что конкретная таблица была создана в пределах задокументированного окна обслуживания. Это может показаться простой задачей для grep, но что, если вам встретится нечто подобное (намеренно обфусцированный) пример:
DO $$
BEGIN
EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
END $$;
Стандартное журналирование выдаст вам это:
LOG: statement: DO $$
BEGIN
EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
END $$;
Похоже, что поиск интересующей таблицы может потребовать некоторого знания кода в тех случаях, когда таблицы создаются динамически. Это не идеально, поскольку предпочтительнее просто искать по имени таблицы. Здесь на помощь приходит pgAudit. Для того же ввода он создаст в журнале следующий вывод:
AUDIT: SESSION,33,1,FUNCTION,DO,,,"DO $$
BEGIN
EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
END $$;"
AUDIT: SESSION,33,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT)
Журналируется не только блок DO, но и подоператор 2 содержит полный текст CREATE TABLE с типом оператора, типом объекта и полным именем, чтобы упростить поиск.
При журналировании операторов SELECT и DML pgAudit можно настроить на запись отдельной записи для каждого отношения, упомянутого в операторе. Для поиска всех операторов, затрагивающих конкретную таблицу, не требуется синтаксический анализ. Фактически, цель состоит в том, чтобы текст оператора предоставлялся в основном для глубокой криминалистики и не требовался для аудита.
В зависимости от настроек pgAudit может создавать огромный объём журналирования. Будьте осторожны, чтобы точно определить, что именно должно журналироваться в вашей среде, чтобы избежать избыточного журналирования.
Например, при работе в среде OLAP, вероятно, неразумно журналировать вставки в большую таблицу фактов. Размер файла журнала, скорее всего, будет во много раз превышать фактический объём данных вставок, поскольку файл журнала представлен в виде текста. Поскольку журналы обычно хранятся вместе с операционной системой, это может привести к очень быстрому исчерпанию дискового пространства. В случаях, когда невозможно ограничить журналирование аудита определёнными таблицами, обязательно оцените влияние на производительность во время тестирования и выделите достаточно места на томе журнала. Это также может относиться к средам OLTP. Даже если объём вставок не так высок, влияние журналирования аудита на производительность может заметно сказаться на задержках.
Чтобы ограничить количество отношений, для которых ведётся журнал аудита для операторов SELECT и DML, рассмотрите возможность использования объектного журналирования аудита (см. Объектное журналирование аудита). Объектное журналирование аудита позволяет выбирать отношения для журналирования, что позволяет уменьшить общий объём журнала. Однако при добавлении новых отношений их необходимо явно добавлять в объектное журналирование аудита. Программное решение, при котором указанные таблицы исключаются из журналирования, а все остальные включаются, может быть хорошим вариантом в этом случае.
pgAudit поддерживает PostgreSQL 14 или новее.
Чтобы поддерживать новые функции, появляющиеся в каждом выпуске PostgreSQL, pgAudit поддерживает отдельную ветку для каждой основной версии PostgreSQL (в настоящее время PostgreSQL 14–19), которая будет поддерживаться аналогично проекту PostgreSQL.
За исключением исправлений ошибок, для стабильных веток дальнейшая разработка не допускается. Любая новая разработка, если таковая будет, будет строго предназначена для следующей невыпущенной основной версии PostgreSQL.
Версии pgAudit соотносятся с основными версиями PostgreSQL следующим образом:
pgAudit v19.X предназначен для поддержки PostgreSQL 19.
pgAudit v18.X предназначен для поддержки PostgreSQL 18.
pgAudit v17.X предназначен для поддержки PostgreSQL 17.
pgAudit v16.X предназначен для поддержки PostgreSQL 16.
pgAudit v1.7.X предназначен для поддержки PostgreSQL 15.
pgAudit v1.6.X предназначен для поддержки PostgreSQL 14.
pgAudit может быть скомпилирован с установленной копией PostgreSQL с пакетами разработки с использованием PGXS. Следующие инструкции должны работать в большинстве Unix-подобных операционных систем.
Клонируйте расширение pgAudit:
git clone https://github.com/pgaudit/pgaudit.git
Перейдите в каталог pgAudit:
cd pgaudit
Переключитесь на ветку REL_19_STABLE (обратите внимание, что стабильной ветки может не существовать для невыпущенных версий PostgreSQL):
git checkout REL_19_STABLE
Соберите и установите pgAudit:
make install USE_PGXS=1 PG_CONFIG=/usr/pgsql-19/bin/pg_config
Инструкции по тестированию и разработке можно найти в test.
Настройки могут изменяться только суперпользователем. Разрешение обычным пользователям изменять свои настройки лишило бы смысла журнал аудита.
Настройки могут быть заданы глобально (в postgresql.conf или с помощью ALTER SYSTEM ... SET), на уровне базы данных (с помощью ALTER DATABASE ... SET) или на уровне роли (с помощью ALTER ROLE ... SET). Обратите внимание, что настройки не наследуются через обычное наследование ролей, и SET ROLE не изменяет настройки pgAudit пользователя. Это ограничение системы ролей, а не особенность pgAudit.
Расширение pgAudit должно быть загружено в shared_preload_libraries. В противном случае при загрузке будет вызвана ошибка, и журналирование аудита не будет выполняться.
Кроме того, перед установкой pgaudit.log необходимо вызвать CREATE EXTENSION pgaudit, чтобы обеспечить корректную работу pgaudit. Расширение устанавливает триггеры событий, которые добавляют дополнительное аудирование для DDL. pgAudit будет работать и без установленного расширения, но операторы DDL не будут содержать информацию о типе и имени объекта.
Если расширение pgaudit удалено и его необходимо пересоздать, сначала необходимо сбросить pgaudit.log, иначе будет вызвана ошибка.
Указывает, какие классы операторов будут журналироваться при сессионном журналировании аудита. Возможные значения:
READ: SELECT и COPY, когда источником является отношение или запрос.
WRITE: INSERT, UPDATE, DELETE, TRUNCATE и COPY, когда назначением является отношение.
FUNCTION: Вызовы функций и блоки DO.