F.33. pgAudit#
F.33. pgAudit
F.33.2. Введение
pgAudit обеспечивает подробное ведение журнала сессий и/или объектов с помощью стандартного инструмента ведения журнала Tantor SE .
F.33.3. Почему 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 можно настроить на регистрацию отдельной записи для каждой связанной с операцией таблицы. Для поиска всех операций, которые затрагивают определенную таблицу не нужен разбор. Фактически, цель состоит в том, чтобы текст операции предоставлялся в основном для глубокого анализа и не требовался для аудита.
F.33.4. Рекомендации по использованию
В зависимости от настроек, pgAudit может генерировать огромный объем записей в журнал. Важно точно определить, что нужно регистрировать в журнале аудита в вашей среде, чтобы избежать раздутия журналов.
Например, при работе в среде OLAP, вероятно, не стоит регистрировать записи журнала аудита в большую фактическую таблицу. Размер журнала вероятно будет в несколько раз больше фактического размера данных записей, потому что файл журнала представляет собой текст. Поскольку журналы обычно хранятся вместе с ОС, дисковое пространство может быстро закончится. В случаях, когда невозможно ограничить регистрацию определенными таблицами, обязательно оцените его влияние на производительность во время тестирования и выделите достаточно места под журнал. Это также может касаться среды OLTP. Даже если объем записей не так велик, ведение журнала аудита все равно может вызывать заметные задержки.
Чтобы ограничить количество отслеживаемых отношений для операторов SELECT и DML, рассмотрите возможность ведения журнала аудита объектов (см. ведение журнала объектов). Ведение журнала аудита объектов позволяет выбирать отслеживаемые отношения, что позволяет сократить общий объем журнала. Однако, при добавлении новых связей, их необходимо явно указать для ведение журнала аудита объектов. В этом случае хорошим вариантом может быть программное решение, при котором указанные таблицы исключаются из журналирования, а по всем остальным ведется журнал.
F.33.5. Tantor SE Совместимость версий
pgAudit был изначально разработан под PostgreSQL 9.5 и более поздних версий.
Для поддержки новых функций, появляющихся в каждом релизе Tantor SE pgAudit поддерживает отдельную ветку для каждого мажорного релиза Tantor SE которая будет поддерживаться по аналогии с проектом PostgreSQL.
Помимо исправления ошибок, для стабильных веток дальнейшее развитие не планируется. Новые разработки, если они будут, будут только для очередного мажорного релиза PostgreSQL.
F.33.6. Настройки
Настройки могут быть изменены только суперпользователем. Предоставление обычным пользователя возможности изменять свои настройки противоречит цели файла аудита.
Настройки можно указать глобально (в файле postgresql.conf или с помощью ALTER SYSTEM ... SET), на уровне базы данных (с помощью ALTER DATABASE ... SET) или на уровне роли (с помощью ALTER ROLE ... SET). Обратите внимание, что настройки не наследуются через обычное наследование ролей и команда SET ROLE не изменит пользовательские настройки pgAudit. Это ограничение системы ролей, а не расширения pgAudit.
F.33.6.1. 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.ALL : Включает все вышеуказанное.
Несколько классов можно указать с помощью списка через запятую, и классы можно вычитать, написав перед классом знак - (см. ведение журнала аудита сессии).
По умолчанию используется none.
F.33.6.2. pgaudit.log_catalog
Указывает, что регистрация сессии должна быть включена в случае, если все отношения в операторе находятся в pg_catalog. Отключение этой настройки снизит шум в журнале от таких инструментов, как psql и PgAdmin, которые интенсивно запрашивают каталог.
По умолчанию значение on.
F.33.6.3. pgaudit.log_client
Определяет, будут ли сообщения журнала видны клиентскому процессу типа psql. Эта настройка обычно должна быть отключена, но может быть полезна для отладки или других целей.
Обратите внимание, что pgaudit.log_level включается только
когда включен
( on) pgaudit.log_client.
По умолчанию - отключено ( off).
F.33.6.4. pgaudit.log_level
Определяет уровень регистрации данных, который будет использоваться для записей журнала (см.
Уровни
серьезности сообщений для допустимых уровней), но обратите внимание, что уровни
ERROR, FATAL и
PANIC не разрешены). Этот параметр используется
для регрессионного тестирования и также может быть полезен конечным пользователям для
тестирования или других целей.
Обратите внимание, что pgaudit.log_level включается только
когда включен
( on) pgaudit.log_client; в противном случае будет использовано значение по умолчанию.
По умолчанию используется log.
F.33.6.5. pgaudit.log_parameter
Указывает, что ведение журнала аудита должно включать параметры, которые были переданы вместе с оператором. Когда параметры присутствуют, они будут включены в формате CSV после текста оператора.
По умолчанию - отключено ( off).
F.33.6.6. pgaudit.log_relation
Определяет, должно ли ведение журнала аудита сессии создавать отдельную запись журнала для каждого отношения (TABLE, VIEW и т. д.), на которое ссылается оператор SELECT или DML. Это полезный сокращенный вариант для исчерпывающей регистрации без ведение журнала аудита объектов.
По умолчанию - отключено ( off).
F.33.6.7. pgaudit.log_rows
Указывает, что файл аудита должен включать строки, полученные или затронутые оператором. При включении, поле rows будет добавлено после поля параметров.
По умолчанию - отключено ( off).
F.33.6.8. pgaudit.log_statement
Определяет, будут ли регистрироваться текст запроса и параметры в журнале (если включено). В зависимости от ситуаций, для журнала аудита эти данные могут не требоваться, что делает журналы менее детальными.
По умолчанию значение on.
F.33.6.9. pgaudit.log_statement_once
Определяет, будет ли в журнале регистрироваться текст и параметры оператора вместе с первой записью журнала для связи запрос/подзапрос или вместе с каждой записью. Отключение этой настройки приведет к более сжатому ведению журнала, но может затруднить определение запроса, который сгенерировал запись в журнале, хотя пара запрос/подзапрос вместе с идентификатором процесса должны быть достаточными для идентификации текста запроса, зарегистрированного с предыдущей записью.
По умолчанию - отключено ( off).
F.33.6.10. pgaudit.role
Указывает главную роль, которую следует использовать для ведения журнала аудита объектов. Можно определить несколько ролей аудита, предоставив их главной роли. Это позволяет нескольким группам отвечать за различные аспекты ведения журнала аудита.
Нет значения по умолчанию.
F.33.7. Ведение журнала аудита сессии
Ведение журнала аудита сессии обеспечивает детальную регистрацию всех операторов, выполненных пользователем в бэкенде.
F.33.7.1. Конфигурация
Ведение журнала сессии включается через настройку 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;
F.33.7.2. Пример
В этом примере используется ведение журнала аудита сессии для регистрации операторов DDL и SELECT.
Обратите внимание, что оператор insert не регистрируется, так как класс WRITE не включен.
SQL:
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>
F.33.8. Ведение журнала аудита объектов
Журналы аудита объектов регистрируют операторы, которые влияют на конкретное
отношение. Поддерживаются только SELECT,
INSERT, UPDATE и
DELETE .
Команда TRUNCATE не включается в журнал аудита объектов.
Ведение журнала аудита объектов предназначено как более детальная альтернатива параметра pgaudit.log = 'read, write'. Поэтому, возможно, не имеет смысла использовать их совместно, но один из возможных сценариев - использовать ведение журнала сессии для записи каждого оператора, а затем дополнить его ведением журнала объектов для получения более подробной информации о конкретных отношениях.
F.33.8.1. Конфигурация
Ведение журнала аудита объектов реализуется через систему ролей.
Настройка 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;
F.33.8.2. Пример
В этом примере используется ведение журнала аудита объектов чтобы продемонстрировать, как можно применить детализированный подход к регистрации операторов SELECT и DML. Обратите внимание, что ведение журнала на таблице account контролируется разрешениями на уровне столбцов, в то время как ведение журнала на таблице account_role_map происходит на уровне таблицы.
SQL:
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>
F.33.9. Формат
Записи аудита регистрируются через стандартный механизм ведения журнала и содержат следующие столбцы с данными, разделенными запятой. Вывод соответствует формату CSV только в том случае, если префикс каждой записи журнала удален.
AUDIT_TYPE -
SESSIONилиOBJECT.STATEMENT_ID - Уникальный идентификатор оператора для данной сессии. Каждый идентификатор оператора представляет собой вызов сервера. Идентификаторы операторов являются последовательными, даже если некоторые операторы не регистрируются. Может быть несколько записей для одного идентификатора оператора, когда записывается более одного отношения.
SUBSTATEMENT_ID - Последовательный идентификатор для каждого подзапроса внутри основного оператора. Например, вызов функции из запроса. Идентификаторы подзапросов непрерывны, даже если некоторые подзапросы не регистрируются в журнале. Может быть несколько записей для идентификатора подзапроса, когда в журнал записывается более одного отношения.
CLASS - например,
READ,ROLE(см. pgaudit.log).COMMAND - например,
ALTER TABLE,SELECT.OBJECT_TYPE -
TABLE,INDEX,VIEWи т. д. доступны дляSELECT,DMLи большинстваDDLоператоров.OBJECT_NAME - Полностью уточненное имя объекта (например, public.account). Доступно для операторов
SELECT,DMLи большинства операторовDDL.STATEMENT - Оператор, исполненный на бэкенде.
PARAMETER - Если параметр
pgaudit.log_parameterустановлен, то это поле будет содержать параметры оператора через запятую в кавычках или<none>, если параметров нет. В противном случае, поле будет содержать значение<not logged>.
Используйте log_line_prefix для добавления любых других полей, необходимых для соответствия требованиям к журналу аудита. Типичный префикс строки журнала выглядит как '%m %u %d [%p]: ' и содержит дату/время, имя пользователя, имя базы данных и идентификатор процесса для каждой записи аудита.
F.33.10. Пояснения
При переименовании объекты регистрируются по новым именем. Например, переименование таблицы приведет к следующему результату:
ALTER TABLE test RENAME TO test2; AUDIT: SESSION,36,1,DDL,ALTER TABLE,TABLE,public.test2,ALTER TABLE test RENAME TO test2,<not logged>
Команда может быть зарегистрирована несколько раз. Например, при создании таблицы с указанием первичного ключа, индекс для первичного ключа будет зарегистрирован отдельно, и будет создана еще одна запись аудита для индекса в рамках записи о создании таблицы. Однако, несколько записей будут зарегистрированы под одном идентификаторе оператора.
Операции autovacuum и autoanalyze не регистрируются.
Операторы, выполняемые после того, как транзакция переходит в состояние "отменена", не будут зарегистрированы в журнале аудита. Однако, оператор, вызвавший ошибку, и все последующие операторы, выполненные в отмененной транзакции, будут зарегистрированы как ОШИБКИ стандартным механизмом ведения журнала.
F.33.11. Авторы
Расширение Audit основано на 2ndQuadrant pgaudit project , авторами которого являются Simon Riggs, Abhijit Menon-Sen и Ian Barwick и которое было представлено как расширение для ядра PostgreSQL. Дополнительная разработка была выполнена Дэвидом Стилом (David Steele) из Crunchy Data..