Поделиться через

Безопасность транспортного уровня (TLS) в Базе данных Azure для PostgreSQL

База данных Azure для PostgreSQL требует, чтобы все клиентские подключения использовали протокол TLS, стандартный отраслевый протокол, который шифрует обмен данными между сервером базы данных и клиентскими приложениями. TLS заменяет старый протокол SSL, а только tls версии 1.2 и 1.3 распознаются как безопасные. Целостность безопасности TLS зависит от трех основных принципов:

  • Использование только TLS-версий 1.2 или 1.3.
  • Клиент проверяет сертификат TLS сервера, выданный центром сертификации (ЦС) в цепочке ЦС, начинающейся с доверенного корневого ЦС.
  • Переговоры о безопасном наборе шифров между сервером и клиентом.

Доверенные корневые сертификаты и смены сертификатов

Это важно

Корпорация Майкрософт начала смену сертификата TLS для Базы данных Azure для PostgreSQL для обновления промежуточных сертификатов ЦС и результирующей цепочки сертификатов. Корневые ЦС остаются неизменными.

Если конфигурация клиента использует рекомендуемые конфигурации для TLS, вам не нужно предпринимать никаких действий.

Расписание смены сертификатов

  • 11 ноября 2025 г. в регионах Azure Западно-Центральный США, Восточная Азия и Южная Великобритания началась смена сертификатов TLS.
  • Начиная с 19 января 2026 г., эта смена сертификатов планируется продлить до оставшихся (за исключением Китая) регионов, включая Azure для государственных организаций.
  • После Весеннего фестиваля (китайский Новый год) 2026 года в регионах Китая начнется ротация сертификатов; она будет включать изменение одного из корневых ЦС.

Корневые удостоверяющие центры, используемые базой данных Azure для PostgreSQL

Корневые центры сертификации — это центры верхнего уровня в цепочке сертификатов. База данных Azure для PostgreSQL в настоящее время использует двойные подписанные сертификаты, выданные промежуточным ЦС (ICA), привязанным к следующим корневым ЦС:

В настоящее время регионы Китая используют следующие ЦС:

Промежуточные ЦС

База данных Azure для PostgreSQL использует промежуточные ЦС (ICA) для выдачи сертификатов сервера. Чтобы обеспечить безопасность, корпорация Майкрософт периодически заменяет эти ICA-сертификаты и серверные сертификаты, которые они выдают. Эти ротации являются обычными и не объявляются заранее.

Текущая ротация промежуточных центров сертификации для DigiCert Global Root CA (см. ротацию сертификатов) началась в ноябре 2023 года и планируется завершиться в первом квартале 2024 года. Если вы выполнили рекомендации, это изменение не требует изменений в вашей среде.

Старая цепочка ЦС

Не используйте промежуточные ЦС или сертификаты сервера в доверенном корневом хранилище.

  • DigiCert Global Root G2
    • Microsoft Azure RSA TLS Issuing CA 03 / 04 / 07 / 08
      • Сертификат сервера

Новая цепочка ЦС

Не используйте промежуточные ЦС или сертификаты сервера в доверенном корневом хранилище.

  • DigiCert Global Root G2
    • Microsoft TLS RSA Root G2
      • Microsoft TLS G2 RSA CA OCSP 02 / 04 / 06 / 08 / 10 / 12 / 14 / 16
        • Сертификат сервера

Реплики для чтения

Миграция корневого удостоверяющего центра (DigiCert Global Root CA) к удостоверяющему центру DigiCert Global Root G2 не завершена во всех регионах. Поэтому вновь созданные реплики для чтения могут использовать более новый корневой сертификат ЦС, чем основной сервер. Необходимо добавить DigiCert Global Root CA в доверенные хранилища для реплик чтения.

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

Цепочка сертификатов — это иерархическая последовательность сертификатов, выданных доверенными центрами сертификации (ЦС). Цепочка начинается с корневого центра сертификации (ЦС), который выдает промежуточные сертификаты центра сертификации (ICA). ЦКУ может выдавать сертификаты для подчинённых ЦКУ. Самый низкий уровень ICA в цепочке выдает отдельные сертификаты сервера. Вы устанавливаете цепочку доверия, проверяя каждый сертификат в ней вплоть до корневого сертификата ЦС.

Сокращение сбоев подключения

Использование рекомендуемых конфигураций TLS помогает снизить риск сбоев подключения из-за смены сертификатов или изменений промежуточных ЦС. В частности, избегайте доверия промежуточных ЦС или отдельных сертификатов сервера. Эти методики могут привести к непредвиденным проблемам с подключением при обновлении цепочки сертификатов Корпорацией Майкрософт.

Это важно

Корпорация Майкрософт заранее объявляет об изменениях корневых ЦС, чтобы помочь вам подготовить клиентские приложения. Однако смены сертификатов сервера и изменения промежуточных ЦС являются обычными и не объявляются.

Caution

Использование неподдерживаемых конфигураций (клиента) приводит к непредвиденным сбоям подключения.

Оптимальная конфигурация

  • Примените последнюю, самую безопасную версию TLS, задав ssl_min_protocol_version для параметра сервера значение TLSv1.3.
  • Используйте sslmode=verify-all для подключений PostgreSQL для проверки полного сертификата и имени узла. В зависимости от конфигурации DNS с частными конечными точками или интеграцией виртуальной сети, verify-all может быть невозможно. Поэтому вместо этого можно использовать verify-ca .
  • Всегда сохраняйте полный набор корневых сертификатов Azure в доверенном корневом хранилище.

Хорошая конфигурация

  • ssl_min_protocol_version Задайте для параметра сервера значение TLSv1.3. Если необходимо поддерживать TLS 1.2, не устанавливайте минимальную версию.
  • Используйте sslmode=verify-all или sslmode=verify-ca для подключений PostgreSQL для обеспечения полной или частичной проверки сертификата.
  • Убедитесь, что доверенное корневое хранилище содержит сертификат корневого ЦС, который в настоящее время используется базой данных Azure для PostgreSQL.

Не используйте следующие конфигурации:

  • Отключите TLS, установив require_secure_transport в OFF и установив значение на стороне клиента в sslmode=disable.
  • Используйте настройки на стороне sslmode клиента disable, allow, prefer или require, которые могут сделать приложение уязвимым к атакам типа "человек посередине".

Неподдерживаемые конфигурации; Не используйте

Azure PostgreSQL не объявляет об изменениях промежуточного УЦ или ротации отдельных сертификатов сервера. Таким образом, следующие конфигурации не поддерживаются при использовании sslmode параметров verify-ca или verify-all:

  • Использование промежуточных сертификатов Центра Сертификации в доверенном хранилище.
  • Использование закрепления сертификатов, таких как использование отдельных сертификатов сервера в доверенном хранилище.

Caution

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

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

Замечание

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

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

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

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

Другие рекомендации по протоколу TLS

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

Небезопасные и безопасные версии TLS

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

База данных Azure для PostgreSQL поддерживает TLS версии 1.2 и 1.3. В 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 1.2.

Несмотря на то что мы не рекомендуем отключать TLS, при необходимости вы можете сделать это для подключений к базе данных Azure для PostgreSQL. Параметр сервера можно обновить require_secure_transport до OFF.

Это важно

Используйте последнюю версию TLS 1.3 для шифрования подключений к базе данных. Минимальную версию TLS можно указать, задав ssl_min_protocol_version для параметра сервера значение TLSv1.3. Не устанавливайте ssl_max_protocol_version параметр сервера.

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

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

  • Клиент отправляет список допустимых наборов шифров.
  • Сервер выбирает лучший набор шифров из списка и сообщает клиенту о выборе.

Функции TLS, недоступные в Базе данных Azure для PostgreSQL

В настоящее время База данных Azure для PostgreSQL не реализует следующие функции TLS:

  • Проверка подлинности клиента на основе сертификатов TLS через TLS с взаимной проверкой подлинности (mTLS).
  • Пользовательские сертификаты сервера (принести собственные сертификаты TLS).

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

  • Last updated on