Найти в Дзене
Postgres Professional

Когда служба ИБ просит логировать все, самый простой путь известен: log_statement = all

Итог тоже знакомый: диск быстро переполняется, база начинает тормозить, а в логах тонет все полезное. Мы изначально делали pg_proaudit не как замену стандартному логгеру PostgreSQL, а как дополнение: отделить аудит от технических артефактов системы и выдавать чистый поток событий для SIEM. Плюс важно не писать все подряд, а выделять конкретные зоны риска и следить именно за ними. Но первая версия уперлась в эксплуатацию: инструмент был мощный и быстрый, но его было слишком сложно настраивать. Администраторы считали, сколько правил нужно создать вручную, и часто выбирали что-то попроще. Сложная настройка всегда повышает риск ошибки: забыли одно правило и у злоумышленника появлялся шанс абсолютно незаметно проделывать грязные делишки. В 2.0 сделали ставку на обобщающие правила. Это потребовало архитектурного разворота: отказаться от хэш-таблиц в пользу оптимизированного перебора правил, чтобы поддержать классы операций, схемы, иерархию ролей и обобщения. Попутно отказались от иденти

Когда служба ИБ просит логировать все, самый простой путь известен: log_statement = all. Итог тоже знакомый: диск быстро переполняется, база начинает тормозить, а в логах тонет все полезное.

Мы изначально делали pg_proaudit не как замену стандартному логгеру PostgreSQL, а как дополнение: отделить аудит от технических артефактов системы и выдавать чистый поток событий для SIEM. Плюс важно не писать все подряд, а выделять конкретные зоны риска и следить именно за ними.

Но первая версия уперлась в эксплуатацию: инструмент был мощный и быстрый, но его было слишком сложно настраивать. Администраторы считали, сколько правил нужно создать вручную, и часто выбирали что-то попроще.

Сложная настройка всегда повышает риск ошибки: забыли одно правило и у злоумышленника появлялся шанс абсолютно незаметно проделывать грязные делишки.

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

Попутно отказались от идентификации объектов по OID в пользу имен, чтобы правила не ломались при пересоздании таблиц. В результате правил стало не сотни, а десяток, сложность управления снизилась в 50-100 раз, а в реальной нагрузке производительность не пострадала.

В чем практическая польза:

✔️ Классы событий + схемы: одно правило на все DDL, модификации данных или управление ролями; если объектом указать схему, правило применится ко всем таблицам внутри нее.

✔️ Группы и иерархия ролей: правило на групповую роль срабатывает и для пользователей, которые входят в нее напрямую или косвенно.

✔️ Интеграция с SIEM: добавили поддержку CEF по запросам клиентов; теперь можно писать одновременно в CSV, CEF и syslog, а также в отдельные файлы или свой канал syslog.

Из инженерных деталей: дисконнекты оказалось сложно отлавливать гарантированно, поэтому пришлось добавлять дополнительный хук прямо в ядро Postgres. С CEF пришлось повозиться из-за разных трактовок стандарта у вендоров SIEM и старых спецификаций.

Подробности читайте на Хабре.