Безопасное подключение с помощью TLS и SSL в База данных Azure для PostgreSQL — гибкий сервер

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для PostgreSQL — гибкий сервер

База данных Azure для PostgreSQL . Гибкий сервер принудительно подключает клиентские приложения к База данных Azure для PostgreSQL — гибкий сервер с помощью TLS. TLS — это стандартный отраслевой протокол, который обеспечивает зашифрованные сетевые соединения между сервером базы данных и клиентскими приложениями. TLS представляет собой обновленный протокол SSL (Secure Sockets Layer).

Что такое TLS?

ПРОТОКОЛ TLS был сделан из протокола SSL Netscape и регулярно заменял его. Термины SSL или TLS/SSL по-прежнему часто используются взаимозаменяемо. TLS состоит из двух уровней: отображение записи TLS и шоу подтверждения TLS. Запись показывает, что обеспечивает безопасность ассоциаций. Подтверждение показывает, что сервер и клиент могут подтвердить друг друга и координировать оценки шифрования и криптографические ключи перед торговлей любой информацией.

На предыдущей схеме показана типичная последовательность подтверждения TLS 1.2, состоящая из следующих шагов:

1. Клиент начинается с отправки сообщения, которое ClientHello выражает готовность взаимодействовать через TLS 1.2 с набором наборов шифров, поддерживаемых клиентом.
2. Сервер получает сообщение, отвечает на ServerHelloних и соглашается взаимодействовать с клиентом через TLS 1.2 с помощью определенного набора шифров.
3. Сервер также отправляет свою общую папку ключей. Особенности этого общего ресурса ключей изменяются на основе выбранного набора шифров. Чтобы клиент и сервер согласились с криптографическим ключом, им нужно получить часть друг друга или предоставить общий доступ.
4. Сервер отправляет сертификат (подписанный центром сертификации [ЦС]) и подпись на части ClientHello и ServerHello. Он также включает в себя общую папку ключей. Таким образом, клиент знает, что они аутентичные.
5. После успешного получения данных клиентом и создания собственной общей папки ключей он смешает его с общей папкой ключей сервера, чтобы создать ключи шифрования для сеанса.
6. Клиент отправляет серверу общую Finished папку ключей, включает шифрование и отправляет сообщение. Это сообщение хэш расшифровки того, что произошло до сих пор. Сервер выполняет то же самое. Он смешивает ключевые папки, чтобы получить ключ и отправить собственное Finished сообщение.
7. Теперь данные приложения можно отправлять зашифрованными в подключении.

Цепочки сертификатов

Цепочка сертификатов — это упорядоченный список сертификатов, содержащих сертификаты TLS/SSL и сертификаты ЦС. Они позволяют получателю убедиться, что отправитель и все ЦС являются надежными. Цепочка или путь начинается с TLS/SSL-сертификата. Каждый сертификат в цепочке подписан сущностью, определяемой следующим сертификатом в цепочке.

Цепочка завершается сертификатом корневого ЦС. Этот сертификат всегда подписан самим ЦС. Подписи всех сертификатов в цепочке должны быть проверены до корневого сертификата ЦС.

Любой сертификат, который находится между TLS/SSL-сертификатом и корневым сертификатом ЦС в цепочке, называется промежуточным сертификатом.

Версии TLS

Несколько государственных организаций по всему миру поддерживают рекомендации по TLS относительно безопасности сети. В США эти организации включают Департамент здравоохранения и человеческих услуг и Национальный институт стандартов и технологий. Уровень безопасности, предоставляемый TLS, наиболее влияет на версию протокола TLS и поддерживаемые наборы шифров.

Набор шифров — это набор алгоритмов, включающих шифр, алгоритм обмена ключами и хэширование. Они используются вместе для установления безопасного TLS-подключения. Большинство клиентов и серверов TLS поддерживают несколько альтернативных вариантов. Они должны согласовывать, когда они устанавливают безопасное подключение, чтобы выбрать общую версию TLS и набор шифров.

База данных Azure для PostgreSQL поддерживает TLS версии 1.2 и более поздних версий. Инженерная рабочая группа Интернета (IETF) явным образом предписывает в стандарте RFC 8996 не использовать протоколы TLS 1.0 и TLS 1.1. Оба эти протокола были признаны нерекомендуемыми в конце 2019 г.

Все входящие подключения, использующие более ранние версии протокола TLS, такие как TLS 1.0 и TLS 1.1, по умолчанию запрещены.

IETF выпустила спецификацию TLS 1.3 в RFC 8446 в августе 2018 года, а TLS 1.3 теперь является наиболее распространенной и рекомендуемой версией TLS. TLS 1.3 быстрее и безопаснее, чем TLS 1.2.

Проверка подлинности сертификата выполняется с помощью SSL-сертификатов клиента для проверки подлинности. В этом сценарии сервер PostgreSQL сравнивает атрибут общего имени (CN) сертификата клиента, представленного с запрошенным пользователем базы данных.

В настоящее время База данных Azure для PostgreSQL — гибкий сервер не поддерживает:

• Проверка подлинности на основе SSL-сертификата.
• Пользовательские СЕРТИФИКАТЫ SSL\TLS.

Чтобы определить текущее состояние подключения TLS\SSL, можно загрузить расширение sslinfo, а затем вызвать ssl_is_used() функцию, чтобы определить, используется ли SSL. Функция возвращается t , если подключение использует SSL. В противном случае возвращается значение f. Вы также можете собирать все сведения об использовании SSL База данных Azure для PostgreSQL гибкого сервера по процессу, клиенту и приложению с помощью следующего запроса:

SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
   FROM pg_stat_ssl
   JOIN pg_stat_activity
   ON pg_stat_ssl.pid = pg_stat_activity.pid
   ORDER BY ssl;

Для тестирования можно также использовать команду напрямую openssl :

openssl s_client -starttls postgres -showcerts -connect <your-postgresql-server-name>:5432

Эта команда выводит сведения о протоколе низкого уровня, такие как версия TLS и шифр. Необходимо использовать параметр -starttls postgres. В противном случае эта команда сообщает, что ssl не используется. Для использования этой команды требуется по крайней мере OpenSSL 1.1.1.

Чтобы применить последнюю, наиболее безопасную версию TLS для защиты подключения от клиента к База данных Azure для PostgreSQL — гибкий сервер, установите значение ssl_min_protocol_version 1.3. Для этого параметра требуется, чтобы клиенты, подключающиеся к База данных Azure для PostgreSQL гибкому серверу, использовали эту версию протокола только для безопасного взаимодействия. Старые клиенты могут не взаимодействовать с сервером, так как они не поддерживают эту версию.

Настройка SSL на клиенте

По умолчанию PostgreSQL не выполняет проверку сертификата сервера. По этой причине можно спуфинировать удостоверение сервера (например, изменив запись DNS или заняв IP-адрес сервера) без знания клиента. Все параметры SSL несут издержки в виде шифрования и обмена ключами, поэтому компромисс выполняется между производительностью и безопасностью.

Чтобы предотвратить спуфинирование, необходимо использовать проверку SSL-сертификата на клиенте.

Существует множество параметров подключения для настройки клиента для SSL. Ниже приведены некоторые важные:

• ssl: подключение с помощью SSL. Это свойство не требует значения, связанного с ним. Простое присутствие указывает SSL-подключение. Для совместимости с будущими версиями значение true предпочтительнее. В этом режиме при установке SSL-подключения драйвер клиента проверяет удостоверение сервера, чтобы предотвратить атаки в середине. Он проверяет, подписан ли сертификат сервера доверенным центром и что узел, к которому вы подключаетесь, совпадает с именем узла в сертификате.

• sslmode: если требуется шифрование и требуется, чтобы подключение не удалось зашифровать, задайте.sslmode=require Этот параметр гарантирует, что сервер настроен на прием SSL-подключений для этого узла или IP-адреса, а сервер распознает сертификат клиента. Если сервер не принимает SSL-подключения или сертификат клиента не распознается, подключение завершается ошибкой. В следующей таблице перечислены значения для этого параметра:

  Режим SSL	Описание
  disable	Шифрование не используется.
  allow	Шифрование используется, если параметры сервера требуют или применяют его.
  prefer	Шифрование используется, если параметры сервера позволяют ему.
  require	Используется шифрование. Он гарантирует, что сервер настроен на прием SSL-подключений для этого IP-адреса узла и распознает сертификат клиента.
  verify-ca	Используется шифрование. Проверьте подпись сертификата сервера для сертификата, хранящегося на клиенте.
  verify-full	Используется шифрование. Проверьте подпись сертификата сервера и имя узла для сертификата, хранящегося на клиенте.

  Используемый по умолчанию sslmode режим отличается от клиентов на основе libpq (например, psql) и JDBC. Клиенты на основе libpq по умолчанию prefer. Клиенты JDBC по умолчанию verify-full.

• sslcert, sslkeyи sslrootcert: эти параметры могут переопределить расположение сертификата клиента по умолчанию, ключа клиента PKCS-8 и корневого сертификата. По умолчанию они по умолчанию /defaultdir/postgresql.crt/defaultdir/postgresql.pk8/defaultdir/root.crtи соответственно, где defaultdir находится ${user.home}/.postgresql/ в системах nix и %appdata%/postgresql/ в Windows.

Центры сертификации несут ответственность за выдачу сертификатов. Доверенный центр сертификации — это сущность, которая имеет право убедиться, что кто-то, кто они говорят, что они есть. Для работы этой модели все участники должны согласиться с набором доверенных ЦС. Все операционные системы и большинство веб-браузеров поставляются с набором доверенных ЦС.

Параметры использования verify-ca и verify-full sslmode конфигурации также могут называться закреплением сертификатов. В этом случае сертификаты корневого ЦС на сервере PostgreSQL должны соответствовать сигнатуре сертификата и даже имени узла для сертификата на клиенте.

При изменении или истечении срока действия ЦС на сертификатах сервера PostgreSQL может периодически потребоваться обновить сохраненные клиентом сертификаты. Чтобы определить, закрепляете ли центры сертификации, см . сведения о закреплении сертификатов и службах Azure.

Дополнительные сведения о конфигурации SSL\TLS на клиенте см . в документации по PostgreSQL.

Для клиентов, использующих verify-ca и verify-full sslmode параметров конфигурации (т. е. закрепление сертификатов), они должны развертывать три корневого ЦС в хранилищах сертификатов клиента:

• Сертификаты корневого ЦС DigiCert Global G2 и Корневого ЦС Microsoft RSA 2017 , так как службы переносятся из Digicert в центр сертификации Майкрософт.
• Digicert Global Root CA для устаревшей совместимости.

Скачивание сертификатов корневого ЦС и обновление клиентов приложений в сценариях закрепления сертификатов

Чтобы обновить клиентские приложения в сценариях закрепления сертификатов, можно скачать сертификаты:

• Корневой ЦС Microsoft RSA 2017
• DigiCert Global Root G2
• Глобальный корневой ЦС Digicert

Чтобы импортировать сертификаты в хранилища сертификатов клиента, может потребоваться преобразовать файлы сертификата CRT в pem-формат после скачивания файлов сертификатов из предыдущих URI. С помощью служебной программы OpenSSL можно выполнить следующие преобразования файлов:

openssl x509 -inform DER -in certificate.crt -out certificate.pem -outform PEM

Сведения об обновлении хранилищ сертификатов клиентских приложений с новыми корневыми сертификатами ЦС описаны в обновлении сертификатов TLS клиента для клиентов приложений.

Чтение реплик с помощью сценариев закрепления сертификатов

При миграции корневого ЦС на корневой ЦС Microsoft RSA Root CA 2017 возможно, чтобы созданные реплики находились на новом корневом сертификате ЦС, чем на сервере-источнике, созданном ранее. Для клиентов, использующих verify-ca и verify-full sslmode параметров конфигурации (т. е. закрепление сертификатов), необходимо прервать подключение для принятия трех корневых сертификатов ЦС:

• Корневой ЦС Microsoft RSA 2017
• DigiCert Global Root G2
• Глобальный корневой ЦС Digicert

В настоящее время База данных Azure для PostgreSQL — гибкий сервер не поддерживает проверку подлинности на основе сертификатов.

Тестирование сертификатов клиента путем подключения к psql в сценариях закрепления сертификатов

С помощью командной psql строки клиента можно проверить подключение к серверу в сценариях закрепления сертификатов:

$ psql "host=hostname.postgres.database.azure.com port=5432 user=myuser dbname=mydatabase sslmode=verify-full sslcert=client.crt sslkey=client.key sslrootcert=ca.crt"

Дополнительные сведения о параметрах SSL и сертификатов см . в документации по psql.

Проверка подключения TLS/SSL

Прежде чем пытаться получить доступ к серверу с поддержкой SSL из клиентского приложения, убедитесь, что вы сможете перейти к нему через psql. Если вы установили SSL-подключение, вы увидите выходные данные, аналогичные следующему примеру:

psql (14.5)SSL-подключение (протокол: TLSv1.2, шифр: ECDHE-RSA-AES256-GCM-SHA384, биты: 256, сжатие: off)Введите "справка" для справки.

Вы также можете загрузить расширение sslinfo, а затем вызвать ssl_is_used() функцию, чтобы определить, используется ли SSL. Функция возвращается t , если подключение использует SSL. В противном случае возвращается значение f.

Комплекты шифров

Комплект шифров представляет собой набор криптографических алгоритмов. Протоколы TLS/SSL используют алгоритмы из набора шифров для создания ключей и шифрования информации.

Набор шифров отображается как длинная строка, казалось бы, случайной информации, но каждый сегмент этой строки содержит важную информацию. Как правило, эта строка данных включает несколько ключевых компонентов:

• Протокол (то есть TLS 1.2 или TLS 1.3)
• Алгоритм обмена ключами или соглашения
• Алгоритм цифровой подписи (проверка подлинности)
• Алгоритм массового шифрования
• Алгоритм кода проверки подлинности сообщений (MAC)

Разные версии TLS/SSL поддерживают различные наборы шифров. Наборы шифров TLS 1.2 не могут быть согласованы с подключениями TLS 1.3 и наоборот.

В настоящее время База данных Azure для PostgreSQL — гибкий сервер поддерживает множество наборов шифров с версией протокола TLS 1.2, которая попадает в категорию HIGH:!aNULL.

Устранение ошибок подключения TLS/SSL

1. Первым шагом для устранения неполадок совместимости версий протокола TLS/SSL является определение сообщений об ошибках, которые вы или ваши пользователи видят при попытке получить доступ к гибкому серверу База данных Azure для PostgreSQL при шифровании TLS от клиента. В зависимости от приложения и платформы сообщения об ошибках могут отличаться. Во многих случаях они указывают на основную проблему.

2. Чтобы быть уверены в совместимости версий протокола TLS/SSL, проверьте конфигурацию TLS/SSL сервера базы данных и клиента приложения, чтобы убедиться, что они поддерживают совместимые версии и наборы шифров.

3. Анализ любых несоответствий или пробелов между сервером базы данных и версиями TLS/SSL клиента и наборами шифров. Попробуйте устранить их путем включения или отключения определенных параметров, обновления или понижения уровня программного обеспечения или изменения сертификатов или ключей. Например, может потребоваться включить или отключить определенные версии TLS/SSL на сервере или клиенте в зависимости от требований к безопасности и совместимости. Например, может потребоваться отключить TLS 1.0 и TLS 1.1, которые считаются небезопасными и устаревшими, и включить TLS 1.2 и TLS 1.3, которые являются более безопасными и современными.

4. Самый новый сертификат, выданный корневым ЦС Microsoft RSA 2017, имеет промежуточный уровень в цепочке, подписанной Digicert Global Root G2 ЦС. Некоторые клиентские библиотеки Postgres при использовании sslmode=verify-full или sslmode=verify-ca настройке могут столкнуться с ошибками подключения с сертификатами корневого ЦС, которые перекрестно подписаны промежуточными сертификатами. Результатом являются альтернативные пути доверия.

   Чтобы обойти эти проблемы, добавьте все три необходимых сертификата в хранилище сертификатов клиента или явно укажите sslrootcert этот параметр. Или задайте PGSSLROOTCERT переменную среды локальным путем, в котором размещается корневой сертификат ЦС Microsoft RSA 2017 из значения %APPDATA%\postgresql\root.crtпо умолчанию.

Связанный контент

• Узнайте, как создать гибкий сервер База данных Azure для PostgreSQL с помощью параметра "Приватный доступ" (интеграция с виртуальной сетью) в портал Azure или Azure CLI.
• Узнайте, как создать гибкий сервер База данных Azure для PostgreSQL с помощью параметра "Общедоступный доступ" (разрешенные IP-адреса) в портал Azure или Azure CLI.