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

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

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

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

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

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

Версии TLS

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

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

База данных Azure для PostgreSQL поддерживает TLS версии 1.2 и более поздних версий. В RFC 8996 целевая группа разработчиков Интернета (IETF) явно утверждает, что протокол 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_version1.3. Для этого параметра требуется , чтобы клиенты, подключающиеся к гибкому экземпляру сервера Базы данных Azure для PostgreSQL, использовали эту версию протокола только для безопасного взаимодействия. Старые клиенты могут не взаимодействовать с сервером, так как они не поддерживают эту версию.

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

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

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

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

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

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

  Режим SSL	Explanation
  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/ в системах Linux и %appdata%/postgresql/ в Windows.

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

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

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

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

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

• Сертификаты корневого ЦС 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 клиента для клиентов приложений.

1. Потеря подключения от клиентского приложения к гибкому серверному экземпляру базы данных Azure для PostgreSQL. Открыт запрос в службу поддержки.
2. Если промежуточный сертификат был изменен, может потребоваться обновить хранилище сертификатов клиента с новым промежуточным сертификатом.
3. Как проверить, закрепляете ли промежуточный сертификат, см. сведения о закреплении сертификатов и службах Azure.

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

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

• Корневой ЦС 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 .

Troubleshoot

Используйте инструкции из этого раздела "Устранение неполадок", чтобы быстро определить и устранить распространенные проблемы TLS/SSL. Начните с воспроизведения проблемы и сбора диагностических данных (сообщения об ошибках на стороне клиента, выходные данные psql, openSSL s_client выходные данные и журналы сервера), а затем проверьте параметры сервера (require_secure_transport, ssl_min_protocol_version, ssl_max_protocol_version), цепочку сертификатов и параметры sslmode/sslrootcert, чтобы определить несоответствия в версиях протокола, наборах шифров или отсутствующих или вращающихся сертификатов.

Ошибки подключения 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по умолчанию.

Проблемы с закреплением сертификатов

1. Проверьте, используете ли вы закрепление сертификатов в вашем приложении.
2. Создание списка сертификатов, которые находятся в доверенном корневом хранилище
   1. Например, вы можете получить список доверенных сертификатов в Хранилище ключей Java программным способом.
   2. Например, можно проверить хранилище ключей java cacerts, чтобы узнать, содержит ли он уже необходимые сертификаты.
3. Вы используете закрепление сертификатов, если у вас имеются отдельные промежуточные сертификаты или отдельные сертификаты сервера PostgreSQL.
4. Чтобы удалить пиннинг сертификатов, удалите все сертификаты из доверенного корневого хранилища сертификатов и добавьте новые.
   1. Обновленные сертификаты можно скачать из официального репозитория Майкрософт: сведения об центре сертификации Azure.
      1. Текущая цепочка:
         1. DigiCert Global Root G2
         2. Microsoft Azure RSA TLS, Центр сертификации, выпускающий сертификаты 03/04/07/08
      2. Новая цепочка:
         1. DigiCert Global Root G2
         2. Microsoft TLS RSA Root G2
         3. Microsoft TLS G2 RSA CA OCSP 02/ 04 / 06 / 08 / 10 / 12 / 14 / 16

Если вы столкнулись с проблемами даже после выполнения этих действий, обратитесь в службу поддержки Майкрософт. Включите в название вращение ICA 2026.

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

• Портал Azure
• Azure CLI
• Портал Azure
• Azure CLI