В PostgreSQL встроена поддержка SSL для шифрования трафика между клиентом и сервером, что повышает уровень безопасности системы. Для использования этой возможности необходимо, чтобы и на сервере, и на клиенте был установлен OpenSSL, и поддержка SSL была разрешена в PostgreSQL при сборке (см. Главу 16).
Когда в установленном сервере PostgreSQL разрешена поддержка SSL, его можно запустить с включённым механизмом SSL, задав в postgresql.conf для параметра ssl значение on. Запущенный сервер будет принимать, как обычные, так и SSL-подключения в одном порту TCP и будет согласовывать использование SSL с каждым клиентом. По умолчанию клиент выбирает режим подключения сам; как настроить сервер, чтобы он требовал использовать только SSL для всех или некоторых подключений, вы можете узнать в Разделе 20.1.
PostgreSQL читает системный файл конфигурации OpenSSL. По умолчанию этот файл называется openssl.cnf и находится в каталоге, который сообщает команда openssl version -d. Если требуется указать другое расположение файла конфигурации, его можно задать в переменной окружения OPENSSL_CONF.
OpenSSL предоставляет широкий выбор шифров и алгоритмов аутентификации разной защищённости. Хотя список шифров может быть задан непосредственно в файле конфигурации OpenSSL, можно задать отдельные шифры именно для сервера баз данных, указав их в параметре ssl_ciphers в postgresql.conf.
Накладные расходы, связанные с шифрованием, в принципе можно исключить, ограничившись только проверкой подлинности, то есть применяя шифр NULL-SHA или NULL-MD5. Однако в этом случае посредник сможет пропускать через себя и читать весь трафик между клиентом и сервером. Кроме того, шифрование привносит минимальную дополнительную нагрузку по сравнению с проверкой подлинности. По этим причинам использовать шифры NULL не рекомендуется.
Чтобы сервер мог работать в режиме SSL, ему необходимы файлы с сертификатом сервера и закрытым ключом. По умолчанию это должны быть файлы server.crt и server.key, соответственно, расположенные в каталоге данных, но можно использовать и другие имена и местоположения файлов, задав их в конфигурационных параметрах ssl_cert_file и ssl_key_file.
В Unix-подобных системах к файлу server.key должен быть запрещён любой доступ группы и всех остальных; чтобы установить такое ограничение, выполните chmod 0600 server.key. Возможен и другой вариант, когда этим файлом владеет root, а группа имеет доступ на чтение (то есть, маска разрешений 0640). Данный вариант предназначен для систем, в которых файлами сертификатов и ключей управляет сама операционная система. В этом случае пользователь, запускающий сервер PostgreSQL, должен быть членом группы, имеющей доступ к указанным файлам сертификата и ключа.
Если закрытый ключ защищён паролем, сервер спросит этот пароль и не будет запускаться, пока он не будет введён. Использование такого пароля лишает возможности изменять конфигурацию SSL без перезагрузки сервера. Более того, закрытые ключи, защищённые паролям, не годятся для использования в Windows.
В некоторых случаях сертификат сервера может подписываться «промежуточным» центром сертификации, сам этот сертификат не обязательно должен быть доверенным для клиентов. Чтобы использовать такой сертификат, нужно добавить к файлу server.crt сертификат выдавшего его центра сертификации, затем сертификат вышестоящего центра и так далее, до сертификата «корневого» или «промежуточного» центра, которому доверяют клиенты. Клиенты считают сертификат доверенным, если он подписан сертификатом, содержащимся в их собственном файле root.crt.
Чтобы клиенты должны были предоставлять серверу доверенные сертификаты, поместите сертификаты центров сертификации (ЦС), которым вы доверяете, в файл root.crt в каталоге данных, укажите в параметре ssl_ca_file в postgresql.conf имя файла root.crt и добавьте параметр аутентификации clientcert=1 в соответствующие строки hostssl в pg_hba.conf. В результате от клиента в процессе установления SSL-подключения будет затребован сертификат. (Как настроить сертификаты на стороне клиента, описывается в Разделе 33.18.) Получив сертификат, сервер будет проверять, был ли этот сертификат подписан одним из доверенным центром сертификации.
Если в root.crt вносятся промежуточные ЦС, в этом файле также должны содержаться цепочки сертификатов до их корневых ЦС. Если установлен параметр ssl_crl_file, также проверяется список отзыва сертификатов (Certificate Revocation List, CRL). (На странице http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04s02.html можно найти наглядные диаграммы, иллюстрирующие применение сертификатов SSL.)
Параметр аутентификации clientcert можно использовать с любым методом проверки подлинности, но только в строках pg_hba.conf типа hostssl. Когда clientcert не задан или равен 0, сервер, тем не менее, будет проверять все представленные клиентские сертификаты по своему файлу со списком ЦС (если он настроен) — но позволит подключаться клиентам без сертификата.
Заметьте, что файл root.crt на сервере содержит сертификаты центров сертификации верхнего уровня, которые считаются доверенными для подписания клиентских сертификатов. В принципе в нём может отсутствовать сертификат ЦС, подписавшего сертификат сервера, хотя в большинстве случаев этот ЦС также должен быть доверенным для клиентских сертификатов.
Если вы используете клиентские сертификаты, вы можете также применить метод аутентификации cert, чтобы сертификаты обеспечивали не только защиту соединений, но и проверку подлинности пользователей. За подробностями обратитесь к Подразделу 20.3.9. (Устанавливать clientcert=1 явно при использовании метода аутентификации cert не требуется.)
В Таблице 18.2 кратко описаны все файлы, имеющие отношение к настройке SSL на сервере. (Здесь приведены стандартные или типичные имена файлов. В конкретной системе они могут быть другими.)
Таблица 18.2. Файлы, используемые SSL-сервером
| Файл | Содержимое | Назначение |
|---|---|---|
ssl_cert_file ($PGDATA/server.crt) | сертификат сервера | отправляется клиенту для идентификации сервера |
ssl_key_file ($PGDATA/server.key) | закрытый ключ сервера | подтверждает, что сертификат сервера был передан его владельцем; не гарантирует, что его владельцу можно доверять |
ssl_ca_file ($PGDATA/root.crt) | сертификаты доверенных ЦС | позволяет проверить, что сертификат клиента подписан доверенным центром сертификации |
ssl_crl_file ($PGDATA/root.crl) | сертификаты, отозванные центрами сертификации | сертификат клиента должен отсутствовать в этом списке |
Сервер читает эти файлы при запуске или при перезагрузке конфигурации. В системах Windows они также считываются заново, когда для нового клиентского подключения запускается новый обслуживающий процесс.
Если в этих файлах при запуске сервера обнаружится ошибка, сервер откажется запускаться. Но если ошибка обнаруживается при перезагрузке конфигурации, эти файлы игнорируются и продолжает использоваться старая конфигурация SSL. В системах Windows, если в одном из этих файлов обнаруживается ошибка при запуске обслуживающего процесса, этот процесс не сможет устанавливать SSL-соединения. Во всех таких случаях в журнал событий сервера выводится сообщение об ошибке.
Чтобы быстро создать самоподписанный сертификат для сервера, действующий 365 дней, выполните следующую команду OpenSSL, заменив yourdomain.com именем компьютера, где размещён сервер:
openssl req -new -x509 -days 365 -nodes -text -out server.crt \
-keyout server.key -subj "/CN=yourdomain.com"Затем выполните:
chmod og-rwx server.key
так как сервер не примет этот файл, если разрешения будут более либеральными, чем показанные. За дополнительными сведениями относительно создания закрытого ключа и сертификата сервера обратитесь к документации OpenSSL.
Самоподписанный сертификат можно использовать при тестировании, но для производственной среды необходимо получить сертификат, подписанный центром сертификации (ЦС) (одним из глобальных ЦС или локальным), чтобы клиенты могли проверять подлинность сервера. Если все клиенты относятся к одной организации, рекомендуется использовать локальный ЦС.