Включение SSL-шифрования
ADPG поддерживает SSL-шифрование трафика между клиентом и сервером. Чтобы использовать эту функцию, OpenSSL должен быть установлен как на сервере, так и на клиенте. Поддержка SSL включается в ADPG во время его сборки. Чтобы его использовать, необходимо получить сертификаты и настроить SSL с помощью пользовательского интерфейса ADCM.
Для работы сервера в режиме SSL ему необходимы файлы, содержащие сертификат сервера и закрытый ключ. По умолчанию эти файлы называются server.crt и server.key соответственно и хранятся в каталоге данных ADPG (/pg_data1/adpg16). Другие имена и местоположения можно указать с помощью параметров конфигурации ssl_cert_file и ssl_key_file, как описано в разделе Настройка через ADCM.
Если закрытый ключ защищен паролем, сервер запросит пароль и не запустится, пока он не будет введен. Использование пароля отключает возможность изменения SSL-конфигурации сервера без перезагрузки.
Использование клиентских сертификатов
Чтобы требовать от клиентов предоставления доверенного сертификата, поместите сертификаты корневых центров сертификации (ЦС), которым вы доверяете, в файл каталога данных, укажите параметр ssl_ca_file в пользовательском интерфейсе ADCM и добавьте вариант аутентификации clientcert=verify-ca или clientcert=verify-full в соответствующие строки hostssl секции PG_HBA, как описано в разделе Настройка SSL через ADCM. Сертификат будет запрошен у клиента во время запуска SSL-соединения. За информацией о том, как настроить сертификаты на клиенте, обратитесь к статье SSL Support.
Для записи hostssl с clientcert=verify-ca сервер проверяет, что сертификат клиента подписан одним из доверенных центров сертификации. Если используется clientcert=verify-full, сервер не только проверяет цепочку сертификатов, но также проверяет, соответствует ли имя пользователя или его сопоставление cn (Common Name) предоставленного сертификата. Обратите внимание, что при использовании метода аутентификации cert всегда обеспечивается проверка цепочки сертификатов.
Промежуточные сертификаты, которые связаны с существующими корневыми сертификатами, также могут быть включены в файл, указанный в параметре ssl_ca_file, если вы хотите избежать их хранения на клиентах. Списки отзыва сертификатов (Certificate Revocation List, CRL) также проверяются, если параметры ssl_crl_file, ssl_crl_dir установлены через ADCM так же, как и другие параметры SSL.
Опция аутентификации clientcert доступна для всех методов аутентификации в записях PG_HBA, указанных как hostssl. Если clientcert не указан, сервер проверяет сертификат клиента по своему списку ЦС, только если сертификат предоставлен и этот список определен.
Существует два подхода к обеспечению того, чтобы пользователи предоставляли сертификат при входе в систему:
-
Использование метода аутентификации
certдля записейhostsslв PG_HBA. Сертификат будет использоваться как для аутентификации, так и для защиты SSL-соединения. См. Certificate authentication. (При использовании метода аутентификацииcertнет необходимости явно указывать какие-либо параметрыclientcert). В этом случае параметрcn(Common Name), указанный в сертификате, сверяется с именем пользователя или применяемым сопоставлением. -
Использование любого метода аутентификации для записей
hostsslс проверкой клиентских сертификатов через установку для параметра аутентификацииclientcertзначенияverify-caилиverify-full. Первое значение только гарантирует, что сертификат действителен, а второе также гарантирует, чтоcn(Common Name) в сертификате соответствует имени пользователя или применимому сопоставлению.
Создание SSL-сертификатов
Вместо сертификатов ЦС вы также можете создать свои собственные самоподписанные сертификаты, которые можно использовать для разработки и тестирования, но не рекомендуется использовать в производственном окружении.
Генерация SSL-сертификата для сервера
Для сервера можно создать самоподписанный сертификат, в котором Issuer и Subject совпадают, или сертификат, подписанный корневым центром сертификации, который также создан на вашем сервере.
Чтобы сгенерировать SSL-сертификаты, измените текущий рабочий каталог на каталог данных ADPG (по умолчанию, /pg_data1/adpg16):
$ cd /pg_data1/adpg16Генерация самоподписанного SSL-сертификата
Чтобы создать простой самоподписанный сертификат для сервера, действительный в течение 365 дней, используйте следующую команду OpenSSL, заменив <dbhost.yourdomain.com> именем хоста сервера, например, CN=ees-adpg-adpg:
$ openssl req -new -x509 -days 365 -nodes -text -out server.crt \
-keyout server.key -subj "/CN=<dbhost.yourdomain.com>"Будут созданы следующие файлы:
-
server.crt — файл сертификата сервера;
-
server.key — файл закрытого ключа.
В системах Unix права доступа к server.key должны запрещать любой доступ группы и других пользователей. Также необходимо присвоить права владельца файлов server.key и server.crt пользователю и группе postgres. Для этого используйте следующие команды:
$ chmod 600 server.key
$ chown postgres:postgres server.key server.crtГенерация корневого сертификата и подписание им сертификата сервера
Чтобы создать сертификат сервера, который смогут проверить клиенты, создайте запрос сертификата (Certificate Signing Request, CSR) и файлы открытого/закрытого ключей. Также необходимо установить разрешения:
$ openssl req -new -nodes -text -out root.csr -keyout root.key -subj "/CN=<root.yourdomain.com>"
$ chmod 600 root.keyПодпишите запрос ключом, чтобы создать корневой центр сертификации. Обратите внимание, что путь к файлу openssl.cnf (/etc/ssl/openssl.cnf) может отличаться в вашем окружении:
$ openssl x509 -req -in root.csr -text -days 3650 \
-extfile /etc/ssl/openssl.cnf -extensions v3_ca \
-signkey root.key -out root.crt
$ chmod 600 root.crtСоздайте сертификат сервера, подписанный новым корневым центром сертификации:
$ openssl req -new -nodes -text -out server.csr -keyout server.key -subj "/CN=<dbhost.yourdomain.com>"
$ chmod 600 server.key
$ openssl x509 -req -in server.csr -text -days 365 -CA root.crt -CAkey root.key -CAcreateserial -out server.crtУдалите файл CSR:
$ rm server.csrФайлы server.crt и server.key должны храниться на сервере, а root.crt — на клиенте, по следующему пути: ~/.postgresql/root.crt.(См. SSL client file usage.) Таким образом, клиент сможет убедиться в том, что сертификат сервера подписан центром сертификации, которому он доверяет.
Файл root.key следует хранить в изолированном месте для создания сертификатов в будущем.
Генерация SSL-сертификата для клиентов
В этом примере используется сертификат сервера из примера Генерация корневого сертификата и подписание им сертификата сервера.
Создайте запрос сертификата (CSR), где CN — имя пользователя базы данных:
$ openssl req -days 3650 -new -nodes -subj "/CN=<database_username>" -keyout client.key -out client.csr
$ chmod 600 client.keyСоздайте подписанный сертификат для клиента, используя корневой сертификат:
$ openssl x509 -days 3650 -req -CAcreateserial -in client.csr -CA root.crt -CAkey root.key -out client.crtУдалите файл CSR:
$ rm client.csrФайлы client.crt и client.key должны храниться на клиенте, по следующему пути: ~/.postgresql/. См. SSL client file usage.
Настройка SSL через ADCM
Для настройки SSL потребуются параметры, перечисленные в таблице. Поле таблицы Значение содержит имена файлов из примера, приведенного выше.
| Имя | Значение | Описание |
|---|---|---|
ssl |
on |
Включает SSL-соединения |
ssl_ca_file |
root.crt |
Указывает имя файла, содержащего сертификаты центров сертификации (ЦС) для SSL-сервера. Путь должен быть указан относительно каталога данных ADPG. Параметр нужен, только если ожидается проверка клиентского сертификата. Значение пути по умолчанию: /pg_data1/adpg16 |
ssl_cert_file |
server.crt |
Указывает имя файла, содержащего сертификат SSL-сервера. Путь должен быть указан относительно каталога данных ADPG. Значение пути по умолчанию: /pg_data1/adpg16 |
ssl_key_file |
server.key |
Указывает имя файла, содержащего закрытый ключ SSL-сервера. Путь должен быть указан относительно каталога данных ADPG. Значение пути по умолчанию: /pg_data1/adpg16 |
Чтобы настроить SSL через ADCM, перейдите на страницу Clusters, выберите кластер ADPG и переключитесь на вкладку Services. Выберите сервис ADPG, разверните ноду ADPG configurations в дереве Configuration и кликните по полю postgresql.conf.
Добавьте SSL-параметры в открывшееся текстовое поле. Параметры со значениями из примера выше будут выглядеть следующим образом:
ssl_cert_file = '/pg_data1/adpg16/server.crt' ssl_key_file = '/pg_data1/adpg16/server.key' ssl_ca_file = '/pg_data1/adpg16/root.crt' ssl = on
Кликните Apply, чтобы применить изменения. После того как поле postgresql.conf закроется, сохраните конфигурацию, нажав Save.
Далее запустите действие Reconfigure & Restart, чтобы сервис ADPG применил изменения. Это необходимо сделать до добавления настроек SSL-соединения в поле PG_HBA.
Разрешите SSL-соединения для сервера ADPG. Например, добавьте следующую строку к содержимому поля PG_HBA в дереве Configuration:
hostssl all all 0.0.0.0/0 cert
Эта запись позволяет всем пользователям (all) использовать SSL-соединения (hostssl) со всеми базами данных (all) со всех адресов IPv4 (0.0.0.0/0). Аутентификация осуществляется с использованием клиентских сертификатов SSL (cert).
Сохраните изменения и запустите действие Reconfigure and Restart, чтобы применить изменения.
Также возможно выполнить действие Reconfigure and Restart только один раз после настройки PG_HBA, установив флаг Force reconfigure and restart. Будьте осторожны при использовании этого флага, так как он отключает валидацию конфигурационных файлов и в случае ошибки в настройках предупреждающее сообщение не будет выведено.