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

  • Статья

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

Примечание.

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

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

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

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

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

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

Внимание

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

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

Примечание.

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

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

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

Примечание.

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

Дополнительная проверка подлинности клиента

Проверка различающегося имени сертификата клиента

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

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

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

Внимание

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

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

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

При взаимной проверке подлинности 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) определенного ответчика или сетевого подключения заблокировано в ответе, состояние отзыва сертификатов завершится ошибкой, и Шлюз приложений вернет 400 HTTP-ответ клиенту запроса.

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

Примечания.

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

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

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