18.9. Безопасные TCP/IP-соединения с использованием SSL#
18.9. Безопасные TCP/IP-соединения с использованием SSL
Tantor SE имеет встроенную поддержку использования SSL соединений для шифрования клиент-серверного обмена для повышения безопасности
Термины SSL и TLS часто используются взаимозаменяемо для обозначения безопасного зашифрованного соединения с использованием протокола TLS. Протоколы SSL являются предшественниками протоколов TLS, и термин SSL все еще используется для зашифрованных соединений, даже если протоколы SSL больше не поддерживаются. SSL используется взаимозаменяемо с TLS в Tantor SE.
18.9.1. Основная настройка
С поддержкой SSL компилированный сервер Tantor SE можно запустить с поддержкой шифрованных соединений, используя протоколы TLS, включенные путем установки параметра ssl в on в файле postgresql.conf. Сервер будет прослушивать как обычные, так и SSL соединения на одном и том же TCP-порту и будет вести переговоры с любым подключающимся клиентом о том, использовать ли SSL. По умолчанию это на выбор клиента; см. Раздел 20.1 о том, как настроить сервер для требования использования SSL для некоторых или всех соединений.
Для запуска в режиме SSL необходимо наличие файлов, содержащих сертификат сервера и закрытый ключ. По умолчанию, эти файлы ожидаются с именами server.crt и server.key соответственно, в каталоге данных сервера, но можно указать другие имена и расположение, используя параметры конфигурации ssl_cert_file и ssl_key_file.
На Unix-системах разрешения на файл server.key должны запрещать доступ миру или группе; для этого используйте команду chmod 0600 server.key. В качестве альтернативы, файл может принадлежать пользователю root и иметь доступ на чтение для группы (то есть разрешения 0640). Эта настройка предназначена для установок, где сертификаты и ключевые файлы управляются операционной системой. Затем пользователь, от имени которого работает сервер Tantor SE, должен быть добавлен в группу, которая имеет доступ к этим сертификатам и ключевым файлам.
Если каталог данных разрешает групповой доступ на чтение, то файлы сертификатов могут потребоваться разместить вне каталога данных, чтобы соответствовать указанным выше требованиям безопасности. Обычно групповой доступ разрешается для того, чтобы непривилегированный пользователь мог создавать резервные копии базы данных, и в этом случае программное обеспечение для создания резервных копий не сможет прочитать файлы сертификатов и, вероятно, выдаст ошибку.
Если закрытый ключ защищён паролем, сервер запросит этот пароль и не запустится, пока он не будет введён. Использование пароля по умолчанию отключает возможность изменять SSL-конфигурацию сервера без его перезапуска, но смотрите ssl_passphrase_command_supports_reload.
Первый сертификат в файле server.crt должен быть сертификатом сервера, так как он должен соответствовать закрытому ключу сервера.
Сертификаты промежуточных центров сертификации также могут быть добавлены в файл. Это позволяет избежать необходимости хранить промежуточные сертификаты на клиентах, при условии, что корневые и промежуточные сертификаты были созданы с использованием расширений v3_ca. (Это устанавливает базовое ограничение сертификата CA в значение true).
Это упрощает срок действия промежуточных сертификатов.
Необходимо добавить корневой сертификат в server.crt. Вместо этого клиенты должны иметь корневой сертификат цепочки сертификатов сервера.
18.9.2. Конфигурация OpenSSL
Tantor SE читает системный файл конфигурации OpenSSL. По умолчанию этот файл называется openssl.cnf и находится в каталоге, указанном в выводе команды openssl version -d.
Это значение по умолчанию можно изменить, установив переменную среды OPENSSL_CONF на имя желаемого файла конфигурации.
OpenSSL поддерживает широкий спектр шифров и алгоритмов аутентификации различной степени надежности. Хотя список шифров можно указать в конфигурационном файле OpenSSL, вы можете указать шифры, специально предназначенные для использования сервером базы данных, изменяя ssl_ciphers в файле postgresql.conf.
Примечание
Возможно осуществить аутентификацию без издержек на шифрование, используя шифры NULL-SHA или NULL-MD5. Однако, злоумышленник может прочитать и передать данные между клиентом и сервером. Кроме того, издержки на шифрование минимальны по сравнению с издержками на аутентификацию. По этим причинам не рекомендуется использовать NULL шифры.
18.9.3. Использование клиентских сертификатов
Чтобы запрашивать от клиента предоставления доверенного сертификата, поместите сертификаты корневых удостоверяющих центров (CA), которым вы доверяете, в файл в каталоге данных, установите параметр ssl_ca_file в postgresql.conf на новое имя файла и добавьте опцию аутентификации clientcert=verify-ca или clientcert=verify-full в соответствующие строки hostssl в pg_hba.conf. Затем при установке SSL-соединения будет запрошен сертификат от клиента. (См. Раздел 32.19 для описания настройки сертификатов на клиенте).
Для записи hostssl с параметром clientcert=verify-ca сервер будет проверять, что сертификат клиента подписан одним из доверенных удостоверяющих центров. Если указан параметр clientcert=verify-full, сервер не только проверит цепочку сертификатов, но также проверит, соответствует ли имя пользователя или его отображение cn (Общее имя) предоставленному сертификату. Обратите внимание, что проверка цепочки сертификатов всегда обеспечивается при использовании метода аутентификации cert (см. Раздел 20.11).
В промежуточных сертификатах, которые связываются с существующими корневыми сертификатами, также могут присутствовать в файле ssl_ca_file, если нужно избежать их хранения на клиентах (предполагается, что корневые и промежуточные сертификаты были созданы с использованием расширений v3_ca). Записи списка отзыва сертификатов (CRL) также проверяются, если установлен параметр ssl_crl_file или ssl_crl_dir.
Вариант аутентификации clientcert доступен для всех методов аутентификации, но только в строках pg_hba.conf, указанных как hostssl. Когда clientcert не указан, сервер проверяет сертификат клиента только по своему файлу CA, если представлен сертификат клиента и CA настроена.
Существует два подхода для обеспечения того, чтобы пользователи предоставляли сертификат при входе.
Первый подход использует метод аутентификации cert для записей hostssl в файле pg_hba.conf, так что сам сертификат используется для аутентификации, обеспечивая при этом безопасность ssl-соединения. См. Раздел 20.11 для получения подробной информации. (При использовании метода аутентификации cert не требуется явно указывать какие-либо параметры clientcert). В этом случае проверяется cn (общее имя), указанное в сертификате, с именем пользователя или соответствующим отображением.
Второй подход объединяет любой метод аутентификации для записей hostssl с проверкой клиентских сертификатов путем установки параметра аутентификации clientcert в значение verify-ca или verify-full. Первый вариант только проверяет, что сертификат действителен, в то время как второй также гарантирует, что cn (общее имя) в сертификате соответствует имени пользователя или соответствующему отображению.
18.9.4. Использование файлов SSL сервера
Таблица 18.2 подводит итоги файлов, которые относятся к настройке SSL на сервере. (Показанные имена файлов являются именами по умолчанию. Локально настроенные имена могут отличаться).
Таблица 18.2. Использование файлов SSL сервера
| Файл | Содержание | Эффект |
|---|---|---|
ssl_cert_file ($PGDATA/server.crt) | сертификат сервера | отправляется клиенту для указания идентификации сервера |
ssl_key_file ($PGDATA/server.key) | серверный закрытый ключ | подтверждает, что сертификат сервера был отправлен владельцем; не указывает на доверие к владельцу сертификата |
| ssl_ca_file | доверенные центры сертификации | проверяет, что клиентский сертификат подписан доверенным центром сертификации |
| ssl_crl_file | сертификаты, отозванные удостоверяющими центрами | клиентский сертификат не должен быть в этом списке |
Сервер читает эти файлы при запуске сервера и каждый раз, когда конфигурация сервера перезагружается.
Если при запуске сервера в этих файлах обнаруживается ошибка, сервер откажется запускаться. Однако если ошибка обнаружена во время перезагрузки конфигурации, эти файлы игнорируются, и используется старая SSL-конфигурация. Во всех этих случаях информация об ошибке записывается в журнал сервера.
18.9.5. Создание сертификатов
Для создания простого самоподписанного сертификата для сервера, действительного в течение 365 дней, используйте следующую команду OpenSSL, заменив dbhost.yourdomain.com на имя хоста сервера:
openssl req -new -x509 -days 365 -nodes -text -out server.crt \
-keyout server.key -subj "/CN=dbhost.yourdomain.com"
Затем выполните:
chmod og-rwx server.key
потому что сервер отклонит файл, если его разрешения будут более свободными, чем это. Для получения более подробной информации о том, как создать закрытый ключ и сертификат сервера, обратитесь к документации OpenSSL.
В то время как самоподписанный сертификат может быть использован для тестирования, в производстве следует использовать сертификат, подписанный удостоверяющим центром (CA)) (обычно корневым CA) для всей организации).
Для создания сертификата сервера, идентификация которого может быть проверена клиентами, сначала создайте запрос на подпись сертификата (CSR) и файл с открытым/закрытым ключом:
openssl req -new -nodes -text -out root.csr \
-keyout root.key -subj "/CN=root.yourdomain.com"
chmod og-rwx root.key
Затем подпишите запрос с помощью ключа для создания корневого сертификата удостоверяющего центра (используя расположение файла конфигурации по умолчанию OpenSSL на Linux):
openssl x509 -req -in root.csr -text -days 3650 \ -extfile /etc/ssl/openssl.cnf -extensions v3_ca \ -signkey root.key -out root.crt
Наконец, создайте серверный сертификат, подписанный новым корневым сертификатом авторитетом:
openssl req -new -nodes -text -out server.csr \
-keyout server.key -subj "/CN=dbhost.yourdomain.com"
chmod og-rwx server.key
openssl x509 -req -in server.csr -text -days 365 \
-CA root.crt -CAkey root.key -CAcreateserial \
-out server.crt
Сертификаты server.crt и server.key должны храниться на сервере, а root.crt должен храниться на клиенте, чтобы клиент мог проверить, что сертификат сервера был подписан доверенным корневым сертификатом.
root.key должен храниться в офлайн-режиме для использования при создании будущих сертификатов.
Также возможно создать цепочку доверия, которая включает промежуточные сертификаты:
# root openssl req -new -nodes -text -out root.csr \ -keyout root.key -subj "/CN=root.yourdomain.com" chmod og-rwx root.key openssl x509 -req -in root.csr -text -days 3650 \ -extfile /etc/ssl/openssl.cnf -extensions v3_ca \ -signkey root.key -out root.crt # intermediate openssl req -new -nodes -text -out intermediate.csr \ -keyout intermediate.key -subj "/CN=intermediate.yourdomain.com" chmod og-rwx intermediate.key openssl x509 -req -in intermediate.csr -text -days 1825 \ -extfile /etc/ssl/openssl.cnf -extensions v3_ca \ -CA root.crt -CAkey root.key -CAcreateserial \ -out intermediate.crt # leaf openssl req -new -nodes -text -out server.csr \ -keyout server.key -subj "/CN=dbhost.yourdomain.com" chmod og-rwx server.key openssl x509 -req -in server.csr -text -days 365 \ -CA intermediate.crt -CAkey intermediate.key -CAcreateserial \ -out server.crt
server.crt и intermediate.crt должны быть объединены в один файл сертификата и сохранены на сервере. server.key также должен быть сохранен на сервере. root.crt должен быть сохранен на клиенте, чтобы клиент мог проверить, что сертификат сервера был подписан цепочкой сертификатов, связанных с его доверенным корневым сертификатом. root.key и intermediate.key должны быть сохранены в офлайн-режиме для использования при создании будущих сертификатов.