| Документация по PostgreSQL 9.4.1 | |||
|---|---|---|---|
| Пред. | Уровень выше | Глава 17. Подготовка к работе и сопровождение сервера | След. |
17.9. Защита соединений TCP/IP с применением SSL
В PostgreSQL встроена поддержка SSL для шифрования трафика между клиентом и сервером, что повышает уровень безопасности системы. Для использования этой возможности необходимо, чтобы и на сервере, и на клиенте был установлен OpenSSL, и поддержка SSL была разрешена в PostgreSQL при сборке (см. Главу 15).
Когда в установленном сервере PostgreSQL разрешена поддержка SSL, его можно запустить с включённым механизмом SSL, задав в postgresql.conf для параметра ssl значение on. Запущенный сервер будет принимать, как обычные, так и SSL-подключения в одном порту TCP и будет согласовывать использование SSL с каждым клиентом. По умолчанию клиент выбирает режим подключения сам; как настроить сервер, чтобы он требовал использовать только SSL для всех или некоторых подключений, вы можете узнать в Разделе 19.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. Если закрытый ключ защищён паролем, сервер запросит пароль и не запустится, пока этот пароль не будет введён.
В некоторых случаях сертификат сервера может подписываться "промежуточным" центром сертификации, сам этот сертификат не обязательно должен быть доверенным для клиентов. Чтобы использовать такой сертификат, нужно добавить к файлу server.crt сертификат выдавшего его центра сертификации, затем сертификат вышестоящего центра и так далее, до сертификата "корневого" или "промежуточного" центра, которому доверяют клиенты. Клиенты считают сертификат доверенным, если он подписан сертификатом, содержащимся в их собственном файле root.crt.
17.9.1. Использование клиентских сертификатов
Чтобы клиенты могли подключаться к серверу, только предоставив доверенный сертификат, поместите сертификаты доверенных центров сертификации (ЦСs) в файл root.crt в каталоге данных, задайте для параметра ssl_ca_file в postgresql.conf значение root.crt и присвойте значение 1 параметру clientcert в соответствующих строках hostssl в pg_hba.conf. После этого сервер будет запрашивать от клиента сертификат при попытке установить SSL-соединение. (Как настроить сертификаты на клиенте, описывается в Разделе 31.18.) Получив сертификат клиента, сервер примет его, только если он подписан одним из доверенных центров сертификации. Если в root.crt добавлены сертификаты промежуточных ЦС, этот файл должен также содержать цепочки сертификатов до соответствующих корневых ЦС. Если установлен параметр ssl_crl_file, при подключении также проверяются списки отозванных сертификатов (CRL, Certificate Revocation List). (По ссылке http://h71000.www7.hp.com/DOC/83final/BA554_90007/ch04s02.html можно найти диаграммы, иллюстрирующие применение сертификатов SSL.)
Параметр clientcert в файле конфигурации pg_hba.conf можно использовать с любым методом аутентификации, но только для строк hostssl. Когда clientcert не задан или равен 0, сервер, тем не менее, будет проверять представленный клиентом сертификат по своему списку доверенных ЦС (если он настроен), но позволит клиенту подключиться без сертификата.
Заметьте, что файл root.crt на сервере содержит сертификаты центров сертификации верхнего уровня, которые считаются доверенными для подписания клиентских сертификатов. В принципе в нём может отсутствовать сертификат ЦС, подписавшего сертификат сервера, хотя в большинстве случаев этот ЦС также должен быть доверенным для клиентских сертификатов.
Если вы используете клиентские сертификаты, вы можете также применить метод аутентификации cert, чтобы сертификаты обеспечивали не только защиту соединений, но и проверку подлинности пользователей. За подробностями обратитесь к Подразделу 19.3.9.
17.9.2. Файлы, используемые SSL-сервером
В Таблице 17-2 кратко описаны все файлы, имеющие отношение к настройке SSL на сервере. (Здесь приведены стандартные или типичные имена файлов. В конкретной системе они могут быть другими.)
Таблица 17-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) | сертификаты, отозванные центрами сертификации | сертификат клиента должен отсутствовать в этом списке |
Файлы server.key, server.crt, root.crt и root.crl (или альтернативные файлы, заменяющие их) считываются только при запуске сервера; поэтому сервер необходимо перезапустить, чтобы изменения в них вступили в силу.
17.9.3. Создание самоподписанного сертификата
Чтобы создать самоподписанный сертификат для сервера быстрым способом, выполните следующую команду OpenSSL:
openssl req -new -text -out server.req
Введите информацию, которую запрашивает openssl. Обязательно укажите правильное имя локального компьютера в поле "Common Name" (Общее имя); пароль запроса можно оставить пустым. Программа сгенерирует ключ, защищённый паролем; она не примет пароль короче четырёх символов. Чтобы удалить пароль (вы должны сделать это, если хотите, чтобы сервер запускался автоматически), выполните такие команды:
openssl rsa -in privkey.pem -out server.key rm privkey.pem
Введите старый пароль, чтобы разблокировать файл ключа. Теперь выполните:
openssl req -x509 -in server.req -text -key server.key -out server.crt
В результате вы получите самоподписанный сертификат, и затем нужно будет скопировать ключ и сертификат туда, где их будет искать сервер. Наконец, выполните:
chmod og-rwx server.key
Сервер не примет этот файл, если для него будут заданы более либеральные права доступа. Подробнее узнать о том, как создаётся закрытый ключ и сертификат сервера, можно в документации OpenSSL.
Самоподписанный сертификат можно использовать при тестировании, но для производственной среды необходимо получить сертификат, подписанный центром сертификации (ЦС) (одним из глобальных ЦС или локальным), чтобы клиенты могли проверять подлинность сервера. Если все клиенты относятся к одной организации, рекомендуется использовать локальный ЦС.
| Пред. | Начало | След. |
| Возможности шифрования | Уровень выше | Защита соединений TCP/IP с применением туннелей SSH |