Share via

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

  • Статья

Область применения: гибкий сервер Базы данных Azure для PostgreSQL

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

Что такое TLS?

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

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

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

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

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

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

Версии TLS

Существует несколько государственных организаций по всему миру, которые поддерживают рекомендации по протоколу TLS относительно безопасности сети, включая Департамент здравоохранения и человеческих услуг (HHS) или Национальный институт стандартов и технологий (NIST) в США. Уровень безопасности, предоставляемый 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, по умолчанию запрещены.

Примечание.

Сертификаты SSL и TLS подтверждают, что подключение защищено современными протоколами шифрования. Шифрование подключения по сети позволяет предотвратить несанкционированный доступ к данным во время передачи. Поэтому настоятельно рекомендуется использовать последние версии TLS для шифрования подключений к База данных Azure для PostgreSQL гибкому серверу.
Хотя это не рекомендуется, при необходимости можно отключить TLS\SSL для подключений к гибкому серверу База данных Azure для PostgreSQL путем обновления параметра сервера require_secure_transport до OFF. Можно также задать версию TLS, установив параметры сервера ssl_min_protocol_version и ssl_max_protocol_version.

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

Примечание.

База данных Azure для PostgreSQL — гибкий сервер не поддерживает пользовательские 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;

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

openssl s_client -connect localhost:5432 -starttls postgres

Эта команда выводит множество низкоуровневых сведений о протоколе, включая версию 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. Мало важных для нас:

  1. ssl. Подключение с помощью SSL. Это свойство не требует значения, связанного с ним. Простое присутствие указывает SSL-подключение. Однако для совместимости с будущими версиями предпочтительнее значение true. В этом режиме при установке SSL-подключения драйвер клиента проверяет удостоверение сервера, предотвращающее атаки "человек в середине". Это делается, проверка, что сертификат сервера подписан доверенным центром, и что узел, к которому вы подключаетесь, совпадает с именем узла в сертификате.
  2. sslmode. Если требуется шифрование и требуется, чтобы подключение не удалось зашифровать, установите sslmode=require. Это гарантирует, что сервер настроен на прием SSL-подключений для этого узла или IP-адреса, а сервер распознает сертификат клиента. Другими словами, если сервер не принимает SSL-подключения или сертификат клиента не распознается, подключение завершится ошибкой. В таблице ниже перечислены значения для этого параметра:
Режим SSL Описание
disable Шифрование не используется
allow Шифрование используется, если для параметров сервера требуется\принудительное применение
Предпочитают Шифрование используется, если параметры сервера позволяют ему
require Используется шифрование. Это гарантирует, что сервер настроен на прием SSL-подключений для этого IP-адреса узла и распознает сертификат клиента.
verify-ca Используется шифрование. Кроме того, проверьте сигнатуру сертификата сервера, хранящегося на клиенте.
verify-full Используется шифрование. Кроме того, проверьте подпись сертификата сервера и имя узла для сертификата, хранящегося на клиенте.

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

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

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

Примечание.

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

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

Примечание.

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

  • Для подключения к серверам, развернутым в облачных регионах Azure для государственных организаций (US Gov Вирджиния, US Gov Техас, US Gov Аризона): DigiCert Global Root G2 и Корневой центр сертификации Microsoft RSA 2017 корневого ЦС, так как службы переносятся из Digicert в ЦС Майкрософт.
  • Для подключения к серверам, развернутым в общедоступных облачных регионах Azure по всему миру: Digicert Global Root CA и Microsoft RSA Root Certificate Authority 2017, так как службы переносятся из Digicert в центр сертификации Майкрософт.

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

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

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

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

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

Внимание

Некоторые клиентские библиотеки Postgres, при использовании sslmode=verify-full setting, могут возникать сбои подключения с сертификатами корневого ЦС, которые пересекаются с промежуточными сертификатами, что приводит к альтернативным путям доверия. В этом случае рекомендуется явно указать параметр sslrootcert , описанный выше, или задать переменную среды PGSSLROOTCERT на локальный путь, в котором размещен сертификат корневого ЦС Microsoft RSA 2017 из значения по умолчанию %APPDATA%\postgresql\root.crt.

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

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

  • Для подключения к серверам, развернутым в Azure для государственных организаций облачных регионах (US Gov Вирджиния, US Gov Техас, US Gov Аризона): DigiCert Global Root G2 и Корневой центр сертификации Microsoft RSA 2017 корневого ЦС, так как службы переносятся из Digicert в Центр сертификации Майкрософт.
  • Для подключения к серверам, развернутым в общедоступных облачных регионах Azure по всему миру: Digicert Global Root CA и Microsoft RSA Root Certificate Authority 2017, так как службы переносятся из 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.

Тестирование Подключение Подключение SSL/TLS

Прежде чем пытаться получить доступ к серверу с поддержкой 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)

Разные версии SSL/TLS поддерживают различные наборы шифров. Наборы шифров TLS 1.2 не могут быть согласованы с подключениями TLS 1.3 и наоборот. По состоянию на этот База данных Azure для PostgreSQL раз гибкий сервер поддерживает множество наборов шифров с версией протокола TLS 1.2, которая попадает в категорию HIGH:!aNULL.

Устранение неполадок с подключением SSL\TLS

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

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

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