Основные параметры конфигурации для защиты базы данных PostgreSQL

Защита PostgreSQL начинается с простого вопроса: кому разрешено подключаться, откуда и с каким методом аутентификации? Если pg_hba.conf слишком широк или сервер прослушивает больше интерфейсов, чем необходимо, ваша база данных имеет большую поверхность атаки, чем нужно.

Это руководство охватывает параметры безопасности PostgreSQL, которые следует проверить в первую очередь: pg_hba.conf, аутентификацию по паролю SCRAM, TLS, сетевые прослушиватели, разрешения ролей и журналы.

1. Усиление аутентификации клиентов с помощью `pg_hba.conf`

Файл аутентификации на основе хоста (pg_hba.conf) определяет, какие хосты могут подключаться, под какими пользователями PostgreSQL они могут подключаться, к каким базам данных они могут получить доступ и, что наиболее важно, метод аутентификации, необходимый для этого подключения.

Понимание структуры `pg_hba.conf`

Каждая строка в pg_hba.conf имеет определенный формат:

TYPE DATABASE USER ADDRESS METHOD [OPTIONS]

TYPE: Тип подключения (например, local, host, hostnossl, hostssl).
DATABASE: Имя целевой базы данных (или несколько).
USER: Целевая роль базы данных (или несколько).
ADDRESS: Диапазон IP-адресов клиента.
METHOD: Механизм аутентификации (например, scram-sha-256, md5, reject, trust).

Лучшие практики для методов аутентификации

Никогда не используйте метод trust в производственной среде, так как он позволяет любому, кто соответствует критериям подключения, подключаться без пароля. Рекомендуемые современные методы аутентификации:

Рекомендуется: `scram-sha-256`

SCRAM (Salted Challenge Response Authentication Mechanism) предлагает значительные улучшения по сравнению со старыми методами паролей, такими как md5, используя более сильное хеширование и предотвращая атаки повторного воспроизведения. Это должен быть ваш выбор по умолчанию для удаленных подключений.

# Принудительное использование SCRAM для удаленных подключений из подсети приложения
host    appdb   app_user 10.20.30.0/24  scram-sha-256

Установите password_encryption = 'scram-sha-256' в postgresql.conf перед созданием или сменой паролей. Существующие пароли, хранящиеся с более старыми хешами, не конвертируются автоматически; сбросьте их после включения SCRAM.

password_encryption = 'scram-sha-256'

Избегайте широких правил, подобных этому, если только другой сетевой контроль уже не ограничивает доступ:

host    all     all     0.0.0.0/0       scram-sha-256

Локальные подключения

Для подключений, исходящих с самого сервера (например, приложений, работающих на той же машине), используйте локальные сокеты. Наиболее безопасной настройкой часто является peer (для сокетов Unix) или scram-sha-256, если сокеты отключены или ограничены.

# Используйте аутентификацию peer для локальных подключений через Unix-сокет
local   all     all             peer

Явное отклонение подключений

Используйте метод reject, чтобы явно заблокировать подключения из опасных или ненадежных сетей.

# Заблокировать все подключения из известного небезопасного диапазона IP
host    all     all     192.168.1.0/24  reject

Практический совет: После изменения pg_hba.conf перезагрузите PostgreSQL, чтобы изменения вступили в силу, например, с помощью sudo systemctl reload postgresql или SELECT pg_reload_conf();.

2. Внедрение шифрования SSL/TLS

Чтобы предотвратить перехват конфиденциальных данных (включая пароли) по сети, принудительное использование шифрования SSL/TLS для всех удаленных подключений является обязательным.

Конфигурация в `postgresql.conf`

Убедитесь, что эти параметры правильно установлены в вашем основном файле конфигурации:

ssl = on: Включает поддержку SSL глобально.
ssl_cert_file: Путь к файлу сертификата сервера (например, server.crt).
ssl_key_file: Путь к файлу закрытого ключа сервера (например, server.key).

Принудительное использование SSL в `pg_hba.conf`

Чтобы заставить клиентов использовать SSL, измените тип подключения в pg_hba.conf с host на hostssl:

# Разрешать только подключения через SSL/TLS
hostssl all     all     0.0.0.0/0       scram-sha-256

hostssl соответствует только SSL-подключениям. Убедитесь, что у вас нет более позднего или более раннего правила host, которое разрешает тех же пользователей без TLS. Чтобы сделать политику очевидной, добавьте правило reject для не-SSL подключений:

hostnossl all    all     0.0.0.0/0       reject

3. Минимизация поверхности атаки

Безопасность включает уменьшение воздействия сервера базы данных на внешние угрозы. В основном это управляется через сетевую конфигурацию и отключение ненужных функций.

Ограничение сетевого адреса прослушивания

PostgreSQL по умолчанию часто прослушивает localhost, но пакетные развертывания и управляемые образы могут отличаться. Явно настройте его на прослушивание только того конкретного интерфейса, который требует доступа, или оставьте его на localhost, если подключаются только локальные приложения.

В postgresql.conf:

# Прослушивать только localhost (127.0.0.1), если возможно
listen_addresses = 'localhost'

# ИЛИ, прослушивать только определенный частный сетевой интерфейс
# listen_addresses = '192.168.1.10'

Предупреждение безопасности: Если listen_addresses установлен в *, будут использоваться все интерфейсы. Убедитесь, что pg_hba.conf строго контролирует, какие диапазоны IP могут подключаться.

Отключение ненужных расширений и функций

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

Безопасность паролей и роли

Убедитесь, что все административные роли (например, пользователь postgres по умолчанию) имеют надежные, сложные пароли, установленные с помощью ALTER USER:

ALTER USER postgres WITH PASSWORD 'YourStrongAndComplexPassword123!';

Используйте принцип минимальных привилегий: пользователи приложений должны иметь только разрешения SELECT, INSERT, UPDATE и DELETE на конкретные таблицы, которые им нужны, а не статус суперпользователя.

4. Конфигурация аудита и журналирования

Хотя это не является механизмом контроля доступа, надежное журналирование имеет решающее значение для обнаружения и расследования инцидентов безопасности. Настройте параметры журналирования в postgresql.conf для записи соответствующих событий.

Ключевые настройки для аудита безопасности:

log_statement = 'ddl' или 'all': Регистрирует все команды Data Definition Language (DDL), такие как CREATE TABLE и ALTER USER. Используйте 'all' осторожно, так как это может создать большой объем журнала и может захватывать конфиденциальный текст запросов.
log_connections = on: Регистрирует каждую успешную попытку подключения.
log_disconnections = on: Регистрирует, когда клиенты отключаются.
log_duration = on: Регистрирует время выполнения всех операторов, что иногда может выявить необычные шаблоны активности.

Комбинируя строгие правила доступа в pg_hba.conf, принудительное шифрование через SSL, ограниченный адрес прослушивания и всестороннее журналирование, вы создаете прочную основу для защиты вашего развертывания PostgreSQL.

Основные шаги по обеспечению безопасности

Обновите pg_hba.conf: Используйте scram-sha-256 или peer для методов аутентификации.
Принудительное шифрование: Установите ssl = on в postgresql.conf и используйте записи hostssl в pg_hba.conf.
Ограничьте прослушивание: Настройте listen_addresses только на необходимые интерфейсы, избегая значения * по умолчанию, если это возможно.
Примените минимальные привилегии: Ограничьте роли базы данных только теми разрешениями, которые абсолютно необходимы для их функции.
Перезагрузите конфигурацию: Всегда перезагружайте или перезапускайте PostgreSQL после изменения файлов безопасности, чтобы применить изменения.

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