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

Обзор взаимной проверки подлинности с помощью Шлюз приложений

Взаимная проверка подлинности или проверка подлинности клиента позволяет Шлюзу приложений проверять подлинность клиента, отправляющего запросы. Как правило, только клиент выполняет проверку подлинности Шлюз приложений; взаимная проверка подлинности позволяет как клиенту, так и Шлюз приложений выполнять проверку подлинности друг друга.

Примечание.

Мы рекомендуем использовать протокол TLS версии 1.2 с взаимной проверкой подлинности, так как в будущем эта версия станет обязательной.

Взаимная проверка подлинности

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

Шлюз приложений предоставляет следующие два варианта проверки сертификатов клиента:

Режим мутуального сквозного пассинга TLS

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

Примечание.

В настоящее время эта функция поддерживается только с помощью развертывания Azure Resource Manager с помощью API версии 2025-03-01.

Строгий режим взаимной TLS

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

Сведения о настройке строгого режима взаимного TLS

Чтобы настроить строгий режим взаимной проверки подлинности, необходимо отправить сертификат доверенного клиентского ЦС в рамках части проверки подлинности клиента профиля SSL. Затем профиль SSL должен быть связан с прослушивателем, чтобы завершить настройку взаимной проверки подлинности. В загружаемом сертификате клиента всегда должен быть корневой сертификат ЦС. Вы также можете отправить цепочку сертификатов, но кроме необходимого количества промежуточных сертификатов ЦС, она должна содержать корневой сертификат ЦС. Максимальный размер каждого отправленного файла должен составлять 25 КБ или меньше.

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

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

Внимание

Не забудьте отправить всю цепочку сертификатов ЦС доверенного клиента в Шлюз приложений при использовании взаимной проверки подлинности.

Каждый профиль SSL может поддерживать до 100 доверенных цепочек сертификатов ЦС клиента. Один Шлюз приложений может поддерживать в общей сложности 200 доверенных цепочек сертификатов ЦС клиента.

Примечание.

Сертификаты, поддерживаемые для взаимной проверки подлинности в строгом режиме TLS

Шлюз приложений поддерживает сертификаты, выданные как общедоступными, так и частными центрами сертификации.

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

Примечание.

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

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

Проверка уникального имени сертификата клиента

У вас есть возможность проверить непосредственного издателя сертификата клиента и разрешить Шлюзу приложений доверять только этому издателю. Этот параметр отключен по умолчанию, но этот параметр можно включить с помощью портала, PowerShell или Azure CLI.

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

  • Сценарий 1. Цепочка сертификатов включает в себя корневой сертификат — промежуточный сертификат — конечный сертификат
    • Имя субъекта промежуточного сертификата — это то, что шлюз приложений извлекает в качестве DN издателя клиентского сертификата и против которого будет проверяться.
  • Сценарий 2. Цепочка сертификатов включает в себя корневой сертификат — промежуточный1 сертификат — промежуточный2 сертификат — конечный сертификат
    • Имя субъекта сертификата Intermediate2 извлекается в качестве различимого имени (DN) издателя сертификата клиента и будет проверяться.
  • Сценарий 3. Цепочка сертификатов включает: корневой сертификат — конечный сертификат
    • Имя субъекта корневого сертификата извлекается как DN издателя клиентского сертификата.
  • Сценарий 4. Несколько цепочек сертификатов одинаковой длины в одном файле. Цепочка 1 включает: корневой сертификат — промежуточный сертификат1 — конечный сертификат. Цепочка 2 включает: корневой сертификат — промежуточный сертификат2 — конечный сертификат.
    • Имя субъекта промежуточного1 сертификата извлекается как DN издателя сертификата клиента.
  • Сценарий 5. Несколько цепочек сертификатов разной длины в одном файле. Цепочка 1 включает: корневой сертификат — промежуточный сертификат1 — конечный сертификат. Цепочка 2 включает: корневой сертификат — промежуточный сертификат2 — промежуточный сертификат3 — конечный сертификат.
    • Имя субъекта промежуточного сертификата 3 извлекается как DN издателя клиентского сертификата.

Внимание

Мы рекомендуем отправлять только одну цепочку сертификатов для каждого файла. Это особенно важно, если включена проверка сертификата различающегося имени клиента. Отправив несколько цепочек сертификатов в одном файле, вы в конечном итоге окажетесь в сценарии четыре или пять и можете столкнуться с проблемами в будущем, когда представленный клиентский сертификат не соответствует тому, который Issuer DN извлёк из цепочек Application Gateway.

Дополнительные сведения о том, как извлечь цепочки сертификатов ЦС доверенного клиента, см. здесь.

Переменные сервера

При взаимной проверке подлинности TLS существуют дополнительные переменные сервера, которые можно использовать для передачи сведений о сертификате клиента серверным серверам за Шлюз приложений. Дополнительные сведения о том, какие переменные сервера доступны и как их использовать, см. в разделе о переменных сервера.

Отзыв сертификатов

Когда клиент инициирует подключение к Шлюз приложений, настроенной с взаимной проверкой подлинности TLS, можно проверить не только цепочку сертификатов и различающееся имя издателя, но и состояние отзыва сертификата клиента можно проверить с помощью OCSP (протокол состояния сертификата в Сети). Во время проверки сертификат, представленный клиентом, будет проверен с помощью представителя OCSP, указанного в расширении AIA в разделе доступа к информации полномочий. В случае отзыва сертификата клиента шлюз приложений отвечает клиенту с кодом состояния HTTP 400 и причиной. Если сертификат действителен, запрос будет продолжать обрабатываться шлюзом приложений и перенаправляться в определенный серверный пул.

Отзыв сертификата клиента можно включить через REST API, шаблон ARM, Bicep, CLI или PowerShell.

Чтобы настроить проверку отзыва клиента на существующий Шлюз приложений с помощью Azure PowerShell, можно ссылаться на следующие команды:

# Get Application Gateway configuration
$AppGw = Get-AzApplicationGateway -Name "ApplicationGateway01" -ResourceGroupName "ResourceGroup01"

# Create new SSL Profile
$profile  = Get-AzApplicationGatewaySslProfile -Name "SslProfile01" -ApplicationGateway $AppGw

# Verify Client Cert Issuer DN and enable Client Revocation Check
Set-AzApplicationGatewayClientAuthConfiguration -SslProfile $profile -VerifyClientCertIssuerDN -VerifyClientRevocation OCSP

# Update Application Gateway
Set-AzApplicationGateway -ApplicationGateway $AppGw

Список всех ссылок Azure PowerShell для конфигурации проверки подлинности клиента на Шлюз приложений можно найти здесь:

Чтобы проверить состояние отзыва OCSP для запроса клиента, журналы доступа будут содержать свойство sslClientVerify с состоянием ответа OCSP.

Важно, чтобы сервер-ответчик OCSP обеспечивал высокую доступность, а сетевое подключение между шлюзом приложений и сервером-ответчиком было возможно. В случае, если шлюз приложений не может разрешить полное доменное имя (FQDN) указанного ответчика или если сетевое подключение блокируется к ответчику или от него, проверка статуса отзыва сертификата завершается неудачей, и шлюз приложений вернет клиенту HTTP-ответ 400.

Примечание.

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

Примечания.

  • Проверка отзыва через CRL не поддерживается
  • Проверка отзыва клиента появилась в API версии 2022-05-01

Следующие шаги

Ознакомившись со взаимной проверкой подлинности, прочтите статью Настройка Шлюза приложений с использованием взаимной проверки подлинности в PowerShell, чтобы создать Шлюз приложений с использованием взаимной проверки подлинности.

  • Last updated on