Безопасность

Безопасность PG Audit основана на трёх принципах: read-only collector (сбор данных без прав записи), snapshot-подход (один снимок за фиксированное время, без длительного мониторинга) и минимизация данных (collector не читает содержимое таблиц, только технические метаданные о конфигурации, схеме и нагрузке). Эти принципы реализованы на уровне кода Collector и не могут быть изменены через настройки конфигурации.

Архитектурно сервис разделён на две части: бесплатный Express Audit, полностью выполняемый в браузере пользователя (см. раздел 6), и платный Full Audit, при котором файл audit_data.json передаётся Исполнителю вручную через согласованное безопасное хранилище. Публичная форма загрузки файла на сайт для Full Audit отсутствует, что снижает риск случайной отправки данных до согласования заказа.

Мы постоянно пересматриваем процессы в ответ на новые угрозы. Если вы нашли уязвимость в нашей инфраструктуре или процессе, см. раздел 10 о responsible disclosure.

PG Audit Collector — утилита с открытым исходным кодом, доступная на https://github.com/pg-audit/pg-audit-collector. Collector работает локально на сервере Заказчика, использует существующий доступ к PostgreSQL через Unix-socket (по умолчанию /var/run/postgresql/.s.PGSQL.5432) или TCP-подключение, явно настроенное пользователем. Collector не требует создания новых пользователей, не выдаёт прав на запись и не модифицирует данные в базе.

Collector не открывает портов и не запускает фоновых служб. После завершения работы он не оставляет постоянно работающих процессов. Поддерживаются несколько методов аутентификации PostgreSQL: peer (рекомендуется для локального запуска от имени postgres-пользователя), md5 (для TCP-подключений с паролем), scram-sha-256 (рекомендуется по современным стандартам). Выбор метода определяется настройками pg_hba.conf на стороне Заказчика; Collector не переопределяет эту конфигурацию.

Все SQL-запросы, выполняемые Collector, можно просмотреть в исходном коде — это набор SELECT-запросов к системным каталогам (pg_catalog, information_schema) и представлениям статистики (pg_stat_activity, pg_stat_database). Collector проверяет, загружено ли расширение pg_stat_statements (через shared_preload_libraries), но не собирает тексты SQL-запросов и не читает содержимое представлений pg_stat_statements. Ни один запрос не выполняет операций INSERT, UPDATE, DELETE, TRUNCATE, GRANT, REVOKE или ALTER. Это гарантируется на уровне исходного кода и может быть проверено Заказчиком перед запуском.

PG Audit не запрашивает и не получает удалённый доступ к PostgreSQL-кластерам Заказчика. Мы не подключаемся к вашей базе — ни по SSH, ни по TCP-порту PostgreSQL, ни через какие-либо туннели. Все диагностические данные Заказчик собирает самостоятельно с помощью Collector и передаёт Исполнителю в виде файла audit_data.json через согласованное хранилище. Это архитектурный принцип, а не просто формальное обязательство.

Это означает, что Заказчик сохраняет полный контроль над своими базами на всех этапах работы. У Исполнителя нет учётных записей на серверах Заказчика, нет SSH-ключей, нет VPN-доступа, нет паролей. В случае, если Заказчик считает нужным предоставить временный доступ для уточнения деталей после получения отчёта, Исполнитель принимает такое решение индивидуально — но это не является стандартной частью услуги Full Audit и не требуется для её оказания.

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

Collector выполняет один снимок состояния базы за фиксированное время — обычно 1–2 секунды на сервере среднего размера. Это не continuous monitoring: мы не запускаем постоянного процесса, не пишем лог на диск сервера Заказчика, не открываем долгоживущих подключений. Снимок содержит технические метаданные на момент запуска: содержимое системных каталогов, состояние pg_stat_activity, кумулятивные счётчики pg_stat_database, текущие параметры postgresql.conf, флаг загрузки pg_stat_statements.

Snapshot-подход минимизирует влияние на production нагрузку. SELECT-запросы к системным каталогам не блокируют пользовательские транзакции, не удерживают длительных блокировок и не создают значимой нагрузки на дисковую подсистему. Для серверов с очень большой нагрузкой (десятки тысяч одновременных подключений) рекомендуется запускать Collector в часы минимальной активности, но это рекомендация, а не требование.

Ограничение snapshot-подхода в том, что он не отражает динамику: кратковременные пики нагрузки, деградации, длящиеся секунды, могут не попасть в снимок. Для выявления таких проблем мы рекомендуем Заказчику параллельно использовать средства постоянного мониторинга (pg_stat_statements, pg_stat_activity, pgbench). Collector не заменяет, а дополняет эти инструменты.

Collector не читает содержимое пользовательских таблиц. Это означает, что данные клиентов, коммерческая информация, персональные данные, хранящиеся в таблицах PostgreSQL, не попадают в audit_data.json и не передаются Исполнителю. Collector ограничивается техническими метаданными: именами таблиц и индексов (без содержимого), типами колонок (без значений), размерами отношений, статистикой использования, параметрами конфигурации сервера, расширений и подключений.

Из файла audit_data.json исключаются: значения любых столбцов с пользовательскими данными, тела функций и процедур (если они содержат чувствительную информацию — отдельная настройка), пароли и хэши из pg_shadow, содержимое журналов (pg_log). Включается только структура: список таблиц с количеством строк (приближённая оценка через pg_class.reltuples), список индексов с типами и размерами, список расширений с версиями, параметры postgresql.conf, флаг загрузки pg_stat_statements (без текстов запросов — только проверка факта загрузки расширения через shared_preload_libraries).

Заказчик может просмотреть исходный код Collector перед запуском и убедиться, что никакие нежелательные запросы не выполняются. Если требуется ещё более строгий режим, Collector поддерживает флаг --metadata-only, который исключает из выгрузки статистику использования и оставляет только структуру и конфигурацию.

Для платного Full Audit файл audit_data.json передаётся Исполнителю через согласованное безопасное хранилище. Архитектурно публичная форма загрузки на сайт отсутствует, и передача файла возможна только после согласования заказа и подтверждения контакта. Это снижает риск случайной отправки данных до заключения договора.

Доступные способы передачи: через форму контактов (для файлов размером до 25 MB), временная ссылка на Yandex Disk с ограниченным доступом (применяется пароль-защита и срок действия ссылки — 14 дней), ограниченный GitHub Gist (для пользователей, привыкших к этой площадке). После получения файл хранится в зашифрованном виде на устройствах Исполнителя; доступ имеет только специалист, ведущий конкретный заказ.

Срок хранения файла — не более 30 дней с момента передачи отчёта Заказчику. По истечении срока файл уничтожается безвозвратно с использованием методов гарантированного удаления (перезапись данных), исключающих возможность восстановления файла программными средствами. Файл также уничтожается из всех резервных копий, созданных за период хранения, в течение 30 дней после завершения срока хранения. По запросу Заказчика файл может быть уничтожен досрочно — Исполнитель подтверждает уничтожение ответным письмом в течение 1 рабочего дня.

Обязательно тестируйте remediation.sql на staging-окружении перед применением на production. Это правило закреплено в оферте (раздел 8) и является обязательным условием ответственности Исполнителя. Staging-окружение должно копировать структуру и объём данных production, а также версию PostgreSQL, расширения и параметры конфигурации. Идеальное staging создаётся из актуальной резервной копии production.

SQL-команды в remediation.sql потенциально разрушительны. Примеры: VACUUM FULL полностью блокирует таблицу на время выполнения и требует эксклюзивной блокировки; DROP INDEX удаляет индекс без возможности отката (если он не был создан в транзакции); ALTER TABLE … ALTER COLUMN может потребовать полной перезаписи таблицы; изменения параметров postgresql.conf требуют перезагрузки сервера и могут привести к недоступности на время перезапуска.

Тестирование на staging должно включать: проверку плана выполнения ключевых запросов до и после применения рекомендаций (EXPLAIN ANALYZE); проверку времени выполнения типовых операций; проверку корректности работы приложения на обновлённой базе. При выявлении негативных эффектов команду следует исключить из применения на production и сообщить об этом Исполнителю для корректировки рекомендаций.

Перед применением remediation.sql на production Заказчик обязан создать полную резервную копию базы данных. Это правило является обязательным условием ответственности Исполнителя (см. оферту, раздел 8). Без резервной копии применение любых деструктивных команд недопустимо.

Рекомендуемые способы создания резервной копии: pg_dump с флагом --format=custom для отдельных баз или --format=directory для всех баз; pg_basebackup для физической копии всего кластера (с WAL-архивом для point-in-time recovery). Для крупных баз (терабайты данных) предпочтительнее pg_basebackup с последующим восстановлением на отдельной машине.

Дополнительно рекомендуется проверить, что резервная копия действительно восстанавливается — создать тестовую базу из копии и убедиться, что все ключевые таблицы и функции присутствуют и корректны. Это защитит от ситуаций, когда формальная резервная копия создана, но не может быть использована из-за ошибки в процессе резервирования. Применение remediation.sql без проверки восстанавливаемости резервной копии считается нарушением рекомендаций и снижает уровень защиты Заказчика в случае возникновения проблем.

Если вы обнаружили уязвимость в инфраструктуре PG Audit (веб-сайт, формы, передача данных, обработка файлов), просим сообщить о ней через форму контактов или в Telegram-канал @pg_audit_cases с темой письма «[Security] Responsible disclosure». В письме опишите: суть уязвимости, шаги для воспроизведения, потенциальное влияние, ваши контактные данные для уточнения деталей.

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

При значительной уязвимости мы благодарим исследователя упоминанием в списке благодарностей (с согласия исследователя) и можем предложить вознаграждение в размере, соответствующем критичности. Мы не публикуем публичные bounty-программы, но относимся к ответственному раскрытию серьёзно и ценим вклад сообщества в безопасность нашего сервиса.