PostgreSQL поддерживает использование SSL соединений для шифрования общения клиент/сервер, обеспечивая более высокий уровень безопасности. Для этого требуется, чтобы OpenSSL был установлен как на клиенте, так и на сервере и чтобы поддержка SSL была включена в момент сборки PostgreSQL (см главу 15).
Со включённой поддержкой SSL PostgreSQL сервер может быть запущен с параметром, активирующем SSL. Для этого задайте значение ssl равное on в postgresql.conf. Сервер будет слушать как нормальные, так и SSL подключения на одном и том же TCP порту и будет взаимодействовать с любыми клиентами, вне зависимости, использует ли он SSL. По умолчанию это зависит от настроек клиента; смотрите раздел 19.1, где говорится о том, как настроить сервер на приём SSL соединений ото всех пользователей или ото всех.
PostgreSQL считывает системные настройки файла конфигурации OpenSSL. По умолчанию это файл называется openssl.cnf и он расположен в каталоге, узнать который можно при помощи команды openssl version -d. Это значение по умолчанию может быть переопределено, задав имя файла настройки в качестве переменной окружения OPENSSL_CONF.
OpenSSL поддерживает широкий спектр алгоритмов шифрования и аутентификации разной степени надёжности. Хотя список шифров может быть определён в файлах настройки OpenSSL, Вы можете перечислить список доступных шифров для использования сервером изменив ssl_ciphers в postgresq.conf.
Примечание: Возможно проводить аутентификацию без шифрования при помощи шифров NULL-SHA или NULL-MD5. Но в таком случае MitM может вмешаться в коммуникацию между клиентом и сервером. Кроме того, расходы на шифрование малы, по сравнению с накладными расходами на аутентификацию. По этим причинам использовать NULL шифры не рекомендуется.
Для того, чтобы начать режим SSL, файлы server.crt и server.key должны существовать с каталоге с данными сервера. Эти файлы должны содержать сертификат сервера и его закрытый ключ соответственно. На системах UNIX разрешения на server.key не должны разрешать доступ группе и остальным; этого можно добиться командой shmod 0600 server.key. Если закрытый ключ защищён паролем, то сервер запросит пароль и не запустится, пока его не получит.
В некоторых случаях сертификат сервера может быть подписан промежуточным центром сертификации, а не напрямую доверенным центром. Чтобы использовать этот сертификат, добавьте все промежуточные сертификаты вплоть до корневого центра сертификации к файлу server.crt. Корневой сертификат должен быть добавлен в server.crt в любом случае, если он содержит больше чем один сертификат.
17.9.1 Использование сертификата клиента
Для того, чтобы клиент предоставил доверенный сертификат, разместите сертификат центров сертификации (СА), которым Вы доверяете, в файл root.crt в каталоге с данными и установите параметр hostssl соответствующего хоста в 1 в файле pg_hba.conf. В этом случае при установке SSL соединения у клиента будет запрошен сертификат. (В разделе 31.17 описано как установить сертификат на клиенте). Сервер проверит, что сертификат клиента подписан одним из доверенных центров сертификации. Кроме того, если присутствует файл root.crl, проверяется список отозванных сертификатов (CRL). (Здесь есть диаграмма, показывающая использование SSL сертификатов).
Опция clientcert в pg_hba.conf доступна для всех методов аутентификации, но только для строк, отмеченных как hostssl. Если clientcert не определён или равен 0, то сервер будет проверять клиентский сертификат при помощи root.crt, но не будет настаивать на предоставлении ему клиентом сертификата.
Обратите внимание, что список root.crt содержит корневые центры сертификации для подписи клиентских сертификатов; указывать там корневой сервер сертификации для сертификата сервера нет необходимости.
Если Вы настраиваете сертификаты клиентов, Вы можете захотеть использовать метод аутентификации cert, чтобы сертификаты использовались не только для обеспечения безопасности, но и для аутентификации клиента. Подробнее об этом написано в разделе 19.3.10.
17.9.2 Использование файлов SSL сервером
Таблица 17-3 перечисляет файлы, относящиеся к настройке SSL на сервере.
Таблица 17-3 Использование файлов SSL сервером
| Файл | Содержание | Использование |
|---|---|---|
| $PGDATA/server.crt | сертификат сервера | посылается клиенту для идентификации сервера |
| $PGDATA/server.key | закрытый ключ сервера | подтверждает, что сертификат сервера был послан именно им; не подтвеждает доверенность владельца сертификата |
| $PGDATA/root.crt | сертификаты доверенных центров сертификации | проверяет, что сертификат клиента подписан одним из доверенных центров сертификации |
| $PGDATA/root.crl | сертификаты, отозванные центрами сертификации | сертификат клиента не должен быть здесь |
Файлы server.key, server.crt, root.crt и root.crl проверяются только при запуске сервера, так что при их изменении сервер должен быть перезапущен.
openssl req -new -text -out server.req
Сообщите всю информацию, запрашиваемую openssl. Убедитесь, что в имени хоста Вы указали "Common Name"; пароль можно не указывать. Программа создаст ключ, защищённый паролем; пароль меньше чем 4 символа не будет принят. Для того, чтобы удалить пароль (так как иначе Вы должны будете вводить его при запуске сервера), выполните команду:
openssl rsa -in privkey.pem -out server.key
rm privkey.pem
Введите старый пароль чтобы разблокировать существующий ключ. После чего выполните:
openssl req -x509 -in server.req -test -key server.key -out server.crt
Теперь ваш сертификат стал самозаверенным и осталось скопировать его туда, где сервер будет его искать. После чего останется лишь изменить права доступа к нему:
chmod og-rwx server.key
Так как иначе сервер просто не будет его использовать. Более подробно о создании закрытого ключа и сертификата написано в документации по OpenSSL.
Самозаверенный сертификат может быть использован для тестирования, но для продакшена должен быть использован сертификат, подписанный доверенным центром сертификации (СА) (глобальным или локальным), чтобы клиент мог убедиться в идентичности сервера. Если все клиенты находятся в одной организации, то предпочтительнее использовать локальные центры сертификации.
17.9.3 Создание самозаверенного сертификата
Для того, чтобы быстро создать самозаверенный сертификат для сервера, используйте следующую команду OpenSSL:openssl req -new -text -out server.req
Сообщите всю информацию, запрашиваемую openssl. Убедитесь, что в имени хоста Вы указали "Common Name"; пароль можно не указывать. Программа создаст ключ, защищённый паролем; пароль меньше чем 4 символа не будет принят. Для того, чтобы удалить пароль (так как иначе Вы должны будете вводить его при запуске сервера), выполните команду:
openssl rsa -in privkey.pem -out server.key
rm privkey.pem
Введите старый пароль чтобы разблокировать существующий ключ. После чего выполните:
openssl req -x509 -in server.req -test -key server.key -out server.crt
Теперь ваш сертификат стал самозаверенным и осталось скопировать его туда, где сервер будет его искать. После чего останется лишь изменить права доступа к нему:
chmod og-rwx server.key
Так как иначе сервер просто не будет его использовать. Более подробно о создании закрытого ключа и сертификата написано в документации по OpenSSL.
Самозаверенный сертификат может быть использован для тестирования, но для продакшена должен быть использован сертификат, подписанный доверенным центром сертификации (СА) (глобальным или локальным), чтобы клиент мог убедиться в идентичности сервера. Если все клиенты находятся в одной организации, то предпочтительнее использовать локальные центры сертификации.
Комментариев нет:
Отправить комментарий