log_statement = all. Итог тоже знакомый: диск быстро переполняется, база начинает тормозить, а в логах тонет все полезное.Мы изначально делали
pg_proaudit не как замену стандартному логгеру PostgreSQL, а как дополнение: отделить аудит от технических артефактов системы и выдавать чистый поток событий для SIEM. Плюс важно не писать все подряд, а выделять конкретные зоны риска и следить именно за ними.Но первая версия уперлась в эксплуатацию: инструмент был мощный и быстрый, но его было слишком сложно настраивать. Администраторы считали, сколько правил нужно создать вручную, и часто выбирали что-то попроще.
Сложная настройка всегда повышает риск ошибки: забыли одно правило и у злоумышленника появлялся шанс абсолютно незаметно проделывать грязные делишки.
В 2.0 сделали ставку на обобщающие правила. Это потребовало архитектурного разворота: отказаться от хэш-таблиц в пользу оптимизированного перебора правил, чтобы поддержать классы операций, схемы, иерархию ролей и обобщения.
Попутно отказались от идентификации объектов по OID в пользу имен, чтобы правила не ломались при пересоздании таблиц. В результате правил стало не сотни, а десяток, сложность управления снизилась в 50-100 раз, а в реальной нагрузке производительность не пострадала.
В чем практическая польза:
✔️ Классы событий + схемы: одно правило на все DDL, модификации данных или управление ролями; если объектом указать схему, правило применится ко всем таблицам внутри нее.
✔️ Группы и иерархия ролей: правило на групповую роль срабатывает и для пользователей, которые входят в нее напрямую или косвенно.
✔️ Интеграция с SIEM: добавили поддержку CEF по запросам клиентов; теперь можно писать одновременно в CSV, CEF и syslog, а также в отдельные файлы или свой канал syslog.
Из инженерных деталей: дисконнекты оказалось сложно отлавливать гарантированно, поэтому пришлось добавлять дополнительный хук прямо в ядро Postgres. С CEF пришлось повозиться из-за разных трактовок стандарта у вендоров SIEM и старых спецификаций.
Подробности читайте на Хабре.