Комплексная защита PostgreSQL 16: мандатный доступ pg_hba.conf, SSL-шифрование и блокировка брутфорса
Обеспечение безопасности СУБД PostgreSQL 16 в изолированных и публичных инфраструктурах требует применения принципа эшелонированной защиты (Defense in Depth). Надежный пароль учетной записи сам по себе не защищает от перехвата сетевого трафика, подделки IP-адресов или атак методом перебора (brute-force).
Полноценная система безопасности базы данных состоит из взаимодействия четырех основных слоев: ограничение сетевых интерфейсов, фильтрация подключений через файл pg_hba.conf, обязательное шифрование каналов SSL/TLS с проверкой сертификата сервера и реактивная блокировка атак на уровне операционной системы.
Эшелонированная безопасность СУБД: почему одного пароля недостаточно
В базовой конфигурации PostgreSQL прослушивает локальный интерфейс (listen_addresses = 'localhost') и допускает локальные подключения. При открытии внешнего порта 5432 для приложения база данных становится мишенью для сканеров и атак.
Использование небезопасных методов аутентификации (таких как trust или устаревший md5) создает критические уязвимости. Метод trust позволяет любому клиенту, сумевшему установить соединение, войти под любой ролью без проверки пароля. Метод md5 подвержен атакам повторного воспроизведения (replay attacks). Поэтому актуальным стандартом PostgreSQL является метод scram-sha-256 (Salted Challenge Response Authentication Mechanism), обеспечивающий взаимную аутентификацию без передачи пароля в открытом виде.
Настройка pg_hba.conf: порядок правил и методы аутентификации
Файл pg_hba.conf (Host-Based Authentication) управляет доступом на этапе установки соединения. Главное правило работы с pg_hba.conf: файл обрабатывается строго сверху вниз до первого совпадения. Если подключающийся клиент совпал со строкой конфигурации, PostgreSQL выполняет указанный метод аутентификации. Если проверка завершается ошибкой, последующие строки файла не рассматриваются.
Пример безопасного построения правил в pg_hba.conf:
# TYPE DATABASE USER ADDRESS METHOD
# Локальные Unix-сокеты для администратора
local all postgres peer
# Приложение на том же сервере через локальный сокет
local app_db app_user scram-sha-256
# Подключения приложения по защищенному SSL- каналу из внутренней подсети
hostssl app_db app_user 10.0.1.0/24 scram-sha-256
# Явный запрет всех остальных нешифрованных или сторонних подключений
host all all 0.0.0.0/0 reject
host all all ::/0 reject
Обратите внимание: тип записи hostssl обязывает использовать SSL-соединение. Если на сервере отключен параметры ssl=off, строки hostssl игнорируются с предупреждением в логе, так как они не могут совпасть. Для применения изменений в pg_hba.conf не требуется перезапуск сервера — достаточно выполнить SQL-команду SELECT pg_reload_conf();. Для проверки корректности синтаксиса файла перед перезагрузкой используется системное представление pg_hba_file_rules.
Защита сетевых соединений: шифрование SSL/TLS и режим verify-full
Шифрование трафика предотвращает перехват данных и учетных записей в сети. Для включения SSL/TLS в файле postgresql.conf задаются следующие параметры:
ssl = on
ssl_cert_file = '/etc/ssl/certs/server.crt'
ssl_key_file = '/etc/ssl/private/server.key'
ssl_ca_file = '/etc/ssl/certs/root.crt'
ssl_min_protocol_version = 'TLSv1.2'
Файл приватного ключа server.key должен принадлежать системному пользователю postgres и иметь строго ограниченные права доступа (chmod 0600).
На стороне клиента (в приложении или утилите psql) критически важно настроить режим проверки сертификата sslmode. Значение по умолчанию prefer сначала пытается установить SSL, но при ошибке автоматически откатывается на нешифрованное соединение. Режим verify-full обеспечивает максимальную защиту:
- Он требует наличие действующего SSL-соединения.
- Он проверяет цепочку доверия сертификата до корневого CA.
- Он сопоставляет имя хоста, указанное в строке подключения (
db.internal), с доменным именем (SAN/CN) в сертификате сервера.
Новые возможности PostgreSQL 16: параметр require_auth и связывание каналов
PostgreSQL 16 вводит дополнительный параметр клиентской библиотеки libpq — require_auth. Данный параметр позволяет принудительно задать список разрешенных методов аутентификации на стороне клиента:
postgresql://app_user:[email protected]:5432/app_db?sslmode=verify-full&require_auth=scram-sha-256
Если сервер попытается предложить другой метод аутентификации (например, при попытке понижения класса защиты — downgrade attack), клиент незамедлительно разорвет соединение.
Для защиты от атак типа Man-in-the-Middle при использовании TLS документация PostgreSQL 16 также рекомендует задействовать параметр связывания каналов channel_binding=require, связывающий учетные данные SCRAM с TLS-сертификатом сервера.
Логирование аудита и маски формата log_line_prefix
Реакция на инциденты и работа систем предотвращения вторжений (Fail2ban) зависят от качества логов базы данных. В postgresql.conf необходимо включить запись неверных попыток входа и настроить префикс лога:
logging_collector = on
log_connections = on
log_disconnections = on
log_line_prefix = '%m [%p] %q%u@%d %r '
Маска %r в log_line_prefix является обязательной: она фиксирует удаленный IP-адрес и порт подключающегося клиента (remote host and port). Без спецификатора %r утилита Fail2ban не сможет определить IP-адрес нападающего.
Автоматическая защита от брутфорса с помощью Fail2ban
Служба Fail2ban анализирует текстовые логи PostgreSQL и при превышении лимита неудачных попыток аутентификации автоматически добавляет IP-адрес нападающего в правила сетевого экрана (nftables или iptables).
Для настройки Fail2ban создайте файл фильтра /etc/fail2ban/filter.d/postgresql.conf:
[Definition]
failregex = ^<HOST>:\d+ \[\d+\] .*: FATAL: password authentication failed for user ".*"$
^<HOST>:\d+ \[\d+\] .*: FATAL: no pg_hba.conf entry for host ".*"$
Затем настройте правило блокировки в /etc/fail2ban/jail.local:
[postgresql]
enabled = true
port = 5432
protocol = tcp
filter = postgresql
logpath = /var/log/postgresql/postgresql-16-main.log
maxretry = 3
findtime = 600
bantime = 3600
banaction = nftables-multiport
Данная конфигурация блокирует IP-адрес на 1 час (3600 секунд) при совершении 3 неудачных попыток входа в течение 10 минут (600 секунд).
Пошаговый чек-лист безопасного внедрения и валидации
При проведении работ по укреплению защиты СУБД PostgreSQL 16 придерживайтесь следующей последовательности:
- Инвентаризация и бэкап: Сохраните копии файлов
pg_hba.confиpostgresql.conf. Проверьте наличие доступа по локальному Unix-сокету для предотвращения блокировки администратора. - Перевод на SCRAM: Убедитесь, что все учетные записи используют хеширование
scram-sha-256. Обновите пароли пользователей. - Выпуск SSL-сертификатов: Сгенерируйте сертификаты с указанием DNS-имен базы данных в поле Subject Alternative Name (SAN). Установите права
0600на файл ключа. - Редактирование pg_hba.conf: Разместите узкие правила
hostsslвыше общих правил. Включите параметрrequire_authв клиентах. - Проверка файла конфигурации: Выполните валидацию правил без перезапуска:
SELECT file_name, line_number, error FROM pg_hba_file_rules WHERE error IS NOT NULL; - Применение настроек: Выполните безопасную перезагрузку:
SELECT pg_reload_conf(); - Тестирование Fail2ban: Запустите проверку статуса изолятора:
Совершите 3 заведомо неверных попытки подключения с тестового хоста и убедитесь, что IP-адрес заблокирован сетевым экраном.
fail2ban-client status postgresql
Построенная по данной схеме архитектура защиты PostgreSQL 16 обеспечивает надежный барьер против несанкционированного доступа, сетевого перехвата и автоматизированных атак.