Безопасность PostgreSQL: исчерпывающий чек-лист для администраторов

PostgreSQL, будучи одной из самых продвинутых и надежных систем управления базами данных, тем не менее, требует грамотной настройки для обеспечения должного уровня безопасности. Угрозы варьируются от несанкционированного доступа и инъекций до утечек данных и внутренних атак. Данный чек-лист представляет собой структурированное руководство по усилению защиты вашего экземпляра PostgreSQL, охватывающее сетевые настройки, аутентификацию, управление доступом, аудит и поддержку.

• Сетевая безопасность и доступ.

Первая линия обороны — ограничение сетевого доступа к серверу БД. Никогда не разрешайте публичный доступ (0.0.0.0/0). В конфигурационном файле `postgresql.conf` задайте параметр `listen_addresses` только на необходимые IP-адреса (например, 'localhost, 10.0.1.15'). Используйте файл `pg_hba.conf` (Host-Based Authentication) для детального контроля: разрешайте подключения только с определенных IP-адресов или подсетей, используя самые строгие методы аутентификации (например, `scram-sha-256` или сертификаты) вместо `trust` или слабого `md5`. Рассмотрите возможность размещения PostgreSQL за балансировщиком нагрузки или в приватной подсети без прямого выхода в интернет.

• Аутентификация и управление паролями.

Принудительно используйте надежный метод аутентификации SCRAM-SHA-256. Установите в `pg_hba.conf` для всех хостов `scram-sha-256`. Задайте строгую политику паролей с помощью модуля `pgcrypto` или внешних средств: минимальная длина (12+ символов), сложность, регулярная смена. Переименуйте стандартного суперпользователя `postgres` через параметр `ALTER USER postgres RENAME TO [новое_имя]`. Создавайте отдельных пользователей с минимально необходимыми привилегиями для каждого приложения или службы. Никогда не используйте суперпользователя для работы приложений.

• Управление привилегиями и ролевая модель.

Строго следуйте принципу наименьших привилегий (Principle of Least Privilege). Используйте роли (ROLE) для группировки прав. Создавайте отдельные роли для чтения (`SELECT`), записи (`INSERT, UPDATE, DELETE`) и администрирования объектов в каждой схеме. Предоставляйте привилегии ролям, а затем назначайте эти роли пользователям. Регулярно ревьюьте права, используя запросы к системным каталогам `pg_roles` и `information_schema.table_privileges`. Ограничивайте возможность создания объектов (`CREATE`) только определенными схемами и для определенных ролей.

• Шифрование данных.

Обеспечьте шифрование данных на rest (при хранении). Используйте полнодисковое шифрование (FDE) на уровне ОС или шифрование табличных пространств PostgreSQL. Для шифрования трафика между клиентом и сервером обязательно используйте SSL/TLS. В `postgresql.conf` установите `ssl = on`, сгенерируйте или получите сертификаты от доверенного центра и настройте параметры `ssl_cert_file`, `ssl_key_file`. В `pg_hba.conf` для критичных соединений укажите `hostssl` вместо `host` и параметр `clientcert=verify-ca` или `verify-full` для проверки сертификатов клиентов.

• Защита от SQL-инъекций и безопасность приложений.

Хотя это задача разработчиков, администратор может способствовать безопасности. Поощряйте использование подготовленных выражений (prepared statements) и параметризованных запросов во всех приложениях. Ограничивайте возможности пользователей по выполнению произвольных SQL через функции с `SECURITY DEFINER` и тщательной проверкой входных параметров. Рассмотрите использование расширений вроде `pg_stat_statements` для мониторинга необычных или часто выполняемых запросов, которые могут быть признаком уязвимости.

• Регулярное обновление и мониторинг.

Своевременно применяйте патчи безопасности и обновляйте минорные версии PostgreSQL. Подпишитесь на рассылку уведомлений об уязвимостях. Внедрите систему мониторинга (Zabbix, Prometheus с экспортером) для отслеживания ключевых метрик: число неудачных попыток входа, необычная активность, использование ресурсов. Настройте алерты на подозрительные события.

• Аудит и логирование.

Включите детальное логирование. В `postgresql.conf` установите `log_statement = 'ddl'` (логировать команды изменения структуры) или `'mod'` (все изменения данных), `log_connections = on`, `log_disconnections = on`, `log_hostname = on`. Для соответствия стандартам (PCI DSS, GDPR) используйте расширение `pgAudit`, которое предоставляет сессионный и объектный аудит в формате, удобном для анализа. Централизованно собирайте и защищайте логи, настройте их ротацию и долгосрочное хранение для расследования инцидентов.

• Резервное копирование и восстановление.

Безопасность включает в себя и возможность восстановления. Регулярно выполняйте полные и инкрементальные резервные копии с помощью `pg_dump`, `pg_basebackup` или инструментов вроде Barman, pgBackRest. Храните резервные копии отдельно от основного сервера, в зашифрованном виде. Регулярно тестируйте процедуру восстановления на стенде, чтобы убедиться в ее работоспособности и определить время восстановления (RTO).

• Защита конфигурационных файлов и ОС.

Ограничьте права доступа к файлам `postgresql.conf` и `pg_hba.conf` (только для чтения владельцем-postgres). Запускайте сервер PostgreSQL от отдельного непривилегированного пользователя ОС (`postgres`). Своевременно обновляйте операционную систему. Используйте средства безопасности ОС (SELinux, AppArmor) для ограничения возможностей процесса PostgreSQL.

• Процедурные меры.

Разработайте и задокументируйте политику безопасности БД. Регулярно проводите внутренние аудиты и сканирование уязвимостей с помощью специализированных инструментов. Обучайте разработчиков и администраторов лучшим практикам безопасности. Имейте план реагирования на инциденты, связанные с утечкой данных из БД.
Реализация этого чек-листа не является разовым мероприятием, а должна стать частью циклического процесса непрерывного улучшения безопасности. Начните с самых критичных пунктов, таких как настройка `pg_hba.conf` и отказ от аутентификации `trust`, затем постепенно внедряйте остальные меры, регулярно пересматривая и адаптируя политики под меняющиеся угрозы и требования бизнеса.