Безопасные соединения TCP/IP с помощью SSL
Эта страница переведена при помощи нейросети GigaChat.
PostgreSQL имеет встроенную поддержку использования соединений SSL для преобразования связи между клиентом и сервером для повышения безопасности. Для этого требуется, чтобы OpenSSL был установлен как на клиентской, так и на серверной системах, а поддержка в PostgreSQL была включена во время сборки.
Термины SSL и TLS часто используются взаимозаменяемо для обозначения защищенного преобразованного соединения с использованием протокола TLS. Протоколы SSL являются предшественниками протоколов TLS, и термин SSL все еще используется для обозначения преобразованных соединений, даже несмотря на то, что протоколы SSL больше не поддерживаются. В PostgreSQL термины SSL и TLS используются взаимозаменяемо.
Основная настройка
С поддержкой SSL, скомпилированной в PostgreSQL, сервер может быть запущен с поддержкой преобразованных соединений, использующих протоколы TLS, включенные путем установки параметра ssl на on в postgresql.conf. Сервер будет слушать как обычные, так и соединения SSL на одном и том же порту TCP и будет вести переговоры с любым подключающимся клиентом о том, следует ли использовать SSL. По умолчанию это зависит от клиента; см. раздел Файл pg_hba.conf о том, как настроить сервер для использования SSL для некоторых или всех соединений.
Чтобы запустить в режиме SSL, должны существовать файлы, содержащие сертификат сервера и закрытый ключ. По умолчанию эти файлы ожидаются под именами server.crt и server.key соответственно, в каталоге данных сервера, но можно указать другие имена и местоположения, используя параметры конфигурации ssl_cert_file и ssl_key_file.
В системах Unix разрешения на server.key должны запрещать любой доступ к миру или группе; добиться этого можно командой chmod 0600 server.key. В качестве альтернативы файл может принадлежать корневому пользователю и иметь групповой доступ для чтения (то есть права доступа 0640). Эта настройка предназначена для установок, где сертификаты и ключи файлов управляются операционной системой. Пользователь, под которым работает сервер PostgreSQL, затем должен стать членом группы, имеющей доступ к этим файлам сертификатов и ключей.
Если каталог данных позволяет групповому чтению, то файлы сертификатов могут нуждаться в размещении вне каталога данных для соответствия требованиям безопасности, изложенным выше. Как правило, доступ к группе разрешен для того, чтобы непривилегированный пользователь мог выполнить резервное копирование базы данных, и в этом случае программное обеспечение для резервного копирования не сможет прочитать файлы сертификатов и, вероятно, выдаст ошибку.
Если закрытый ключ защищен парольной фразой, сервер запросит парольную фразу и не запустится до тех пор, пока она не будет введена. Использование парольной фразы по умолчанию отключает возможность изменения конфигурации SSL-сервера без перезапуска сервера, но см. ssl_passphrase_command_supports_reload. Кроме того, закрытые ключи, защищенные паролем, вообще нельзя использовать в Windows.
Первый сертификат в server.crt должен быть сертификатом сервера, поскольку он должен соответствовать закрытому ключу сервера. К файлу также могут быть добавлены сертификаты «промежуточных» центров сертификации. Это устраняет необходимость хранения промежуточных сертификатов на клиентах при условии, что корневые и промежуточные сертификаты были созданы с расширениями v3_ca. (Это устанавливает основное ограничение сертификата CA на true.) Это позволяет легче истекать срок действия промежуточных сертификатов.
Не обязательно добавлять корневой сертификат в server.crt. Вместо этого клиенты должны иметь корневой сертификат цепочки сертификатов сервера.
Конфигурация OpenSSL
PostgreSQL читает системный файл конфигурации OpenSSL. По умолчанию этот файл называется openssl.cnf и находится в каталоге, указанном в openssl version -d. Этот параметр можно изменить, установив переменную окружения OPENSSL_CONF равным имени желаемого файла конфигурации.
OpenSSL поддерживает широкий спектр шифров и алгоритмов аутентификации различной степени надежности. Хотя список шифров может быть указан в файле конфигурации OpenSSL, можно указать шифры специально для использования сервером баз данных, изменив ssl_ciphers в postgresql.conf.
Возможно иметь аутентификацию без накладных расходов на преобразование, используя шифры NULL-SHA или NULL-MD5. Однако человек посередине мог бы читать и передавать сообщения между клиентом и сервером. Кроме того, накладные расходы на преобразование минимальны по сравнению с накладными расходами на аутентификацию. По этим причинам шифры NULL не рекомендуются.
Использование клиентских сертификатов
Чтобы потребовать от клиента предоставить надежный сертификат, поместите сертификаты корневых центров сертификации (CA), которым доверяют, в файл в каталоге данных, установите параметр ssl_ca_file в postgresql.conf на новое имя файла и добавьте опцию аутентификации clientcert=verify-ca или clientcert=verify-full к соответствующей строке(ам) hostssl в pg_hba.conf. Затем во время запуска соединения SSL будет запрошен сертификат с клиента.
Для записи с hostssl, сервер проверит, подписан ли сертификат клиента одним из доверенных центров сертификации. Если указано clientcert=verify-full, сервер не только проверяет цепочку сертификатов, но также проверяет, соответствует ли имя пользователя или его сопоставление cn (Общее имя) предоставленного сертификата. Обратите внимание, что проверка цепочки сертификатов всегда гарантируется при использовании метода аутентификации cert (см. раздел Аутентификация по сертификату).
Промежуточные сертификаты, которые образуют цепочку до существующих корневых сертификатов, могут также появиться в файле ssl_ca_file, если требуется избежать их хранения на клиентах (предполагая, что корневые и промежуточные сертификаты были созданы с расширениями v3_ca). Записи списка отозванных сертификатов (CRL) также проверяются, если установлен параметр ssl_crl_file или ssl_crl_dir.
Параметр аутентификации clientcert доступен для всех методов аутентификации, но только в строках pg_hba.conf, указанных как hostssl. Когда clientcert не указан, сервер проверяет клиентский сертификат против своего файла CA только в том случае, если представлен клиентский сертификат и настроен CA.
Существует два подхода к обеспечению того, чтобы пользователи предоставляли сертификат во время входа в систему.
Первый подход использует метод аутентификации для записей в , так что сам сертификат используется для аутентификации, а также обеспечивает безопасность соединения SSL. См. раздел Аутентификация по сертификату для получения подробной информации. (Не нужно явно указывать какие-либо параметры при использовании метода аутентификации .) В этом случае проверяется имя пользователя или соответствующее сопоставление.
Второй подход сочетает любой метод аутентификации для записей с проверкой клиентских сертификатов путем установки параметра аутентификации на или . Первый вариант только требует, чтобы сертификат был действительным, тогда как второй также гарантирует, что в сертификате совпадает с именем пользователя или соответствующим отображением.
Использование файлов SSL-сервера
В таблице ниже обобщены файлы, которые имеют отношение к настройке SSL на сервере. (Показанные имена файлов являются именами по умолчанию. Локально настроенные имена могут быть другими.)
Использование файлов SSL-сервера
| Файл | Содержание | Эффект |
|---|---|---|
ssl_cert_file ($PGDATA/server.crt) | сертификат сервера | отправляется клиенту для указания идентичности сервера |
ssl_key_file ($PGDATA/server.key) | закрытый ключ сервера | доказывает, что сертификат сервера был отправлен владельцем; не указывает, что владелец сертификата заслуживает доверия |
| ssl_ca_file | доверенные центры сертификации | проверяет, подписан ли клиентский сертификат доверенным центром сертификации |
| ssl_crl_file | сертификаты, отозванные центрами сертификации | клиентский сертификат не должен быть в этом списке |
Сервер читает эти файлы при запуске сервера и всякий раз, когда конфигурация сервера перезагружается. В системах Windows они также повторно считываются каждый раз, когда для нового клиентского подключения создается новый фоновый процесс.
Если при запуске сервера обнаруживается ошибка в этих файлах, сервер откажется запускаться. Но если ошибка обнаружена во время перезагрузки конфигурации, эти файлы игнорируются и продолжает использоваться старая конфигурация SSL. В системах Windows, если при запуске бэкенда обнаруживается ошибка в этих файлах, этот бэкенд не сможет установить соединение SSL. Во всех этих случаях состояние ошибки регистрируется в журнале сервера.
Создание сертификатов
Чтобы создать простой самоподписанный сертификат для сервера, действительный в течение 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 должны храниться офлайн для использования при создании будущих сертификатов.