Mutual TLS authentication in Azure Front Door (preview)

Область применения: ✔️ Front Door Premium

Взаимная TLS (mTLS) аутентификация, или аутентификация клиента, обеспечивает безопасность и доверие трафика в обоих направлениях между клиентом и сервером. Используя mutual TLS, вы можете настроить Azure Front Door для подтверждения личности клиента, предоставив действительный сертификат клиента. Взаимная TLS-аутентификация полезна в ситуациях, когда необходимо безопасно идентифицировать и управлять клиентами для целевых ресурсов, таких как B2B-приложения, приложения Интернета вещей (IoT), банковские приложения, VPN, корпоративные сети и многое другое.

Вы можете использовать mutual TLS вместе с другими авторизациями и методами аутентификации, поддерживаемыми Azure Front Door.

Взаимные режимы валидации TLS

• Отключите mTLS: сертификат клиента и валидация не требуются. Этот параметр в установлен по умолчанию.

• Включить mTLS:

  • Требуется и подтверждено сертификат клиента: Сертификат клиента обязателен. Azure Front Door проводит полную валидацию, включая проверку присутствия сертификатов клиента, валидности, а также проверку на отзыв, корневую цепочку CA и список SAN/CN. Azure Front Door пересылает запрос с заголовком X-Azure-ClientCertificate в исходную точку. Эта опция используется по умолчанию, когда mTLS включён.

  • Требуется сертификат клиента, но не валидирован: Сертификат клиента обязателен. Azure Front Door не выполняет других проверок. Azure Front Door удаляет запросы, не содержащие сертификатов. Источник должен выполнить все валидации. По умолчанию Azure Front Door передаёт сертификат на бэкенд через заголовки в этом режиме.

    • Проверка сертификата клиента, если он представлен: Сертификат клиента не обязателен. Azure Front Door проводит полную валидацию при наличии клиентского сертификата и пересылает сертификат клиента в источник через X-Azure-ClientCertificate заголовок. Если клиент не предоставляет сертификат клиента, Azure Front Door передаёт запрос исходному источнику для дальнейшей проверки.

  • mTLS passthrough до источника: Сертификат клиента не требуется. Azure Front Door не выполняет никаких валидаций. Источник должен выполнить все валидации.

Валидация аутентификации клиента

При настройке Azure Front Door для проверки сертификата клиента проверяется следующая информация:

• Текущая дата меньше даты сертификата Not After .

• Текущая дата больше или равна дате сертификата Not Before .

• Расширенное использование ключа сертификата отсутствует или, если присутствует, содержит OID аутентификации клиента.

• Валидность и целостность того, что сертификат не был изменён, его формат.

• Проверьте цепочётку сертификатов: если клиентский сертификат выдан доверенным эмитентом для указанного домена, CN (имя сертификата) сертификаций образует непрерывную цепочку.

Вы также можете настроить опциональные валидации, такие как:

• Проверьте расширение сертификата клиента SAN/CN по списку Allowed SAN, загруженном в Azure Front Door. Пользовательское доменное имя Azure Front Door должно быть явно включено в этот список, чтобы считаться действительным для взаимной TLS-проверки. SAN проверяется первым, если нет совпадения или SAN пуст, то проверяется CN. Если один из SAN или CN совпадает с разрешенным списком SAN, настроенным на Azure Front Door, проверка проходит успешно.

• Проверьте статус отзыва клиентского сертификата с помощью OCSP (Online Certificate Status Protocol).

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

Azure Front Door поддерживает валидацию по статусу отзыва сертификата. По умолчанию она включена. Во время валидации Azure Front Door ищет сертификат, представленный клиентом, используя определённый ответчик OCSP в расширении Authority Information Access (AIA). Если сертификат клиента аннулируется, Azure Front Door отвечает клиенту с кодом статуса HTTP 403 и причиной. Если сертификат действительн, Azure Front Door продолжает обрабатывать запрос.

Поддерживает ли mTLS публичные и частные сертификаты?

Azure Front Door в настоящее время поддерживает сертификаты, выданные как известными публичными сертификатными центрами, так и частными сертификационными центрами.

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

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

Однако Azure Front Door проводит проверки расширенного использования ключей (EKU) на сертификатах клиентов, чтобы убедиться, что они предназначены для аутентификации клиента. Из-за изменений в отрасли публичные сертификационные центры (CA) вскоре перестают выдавать сертификаты аутентификации клиентов с необходимым EKU.

Переход к использованию частных CA, которые могут продолжать выдавать сертификаты с правильным EKU, для сценариев mTLS на Azure Front Door. Этот переход обеспечивает бесперебойную и безопасную аутентификацию клиента.

Важные проектные аспекты перед внедрением mTLS на доменах Front Door

• Включите mTLS на новых доменах и новых конечных точках, чтобы избежать ненужных простоев.

• Когда вы включаете mTLS, вы не можете включить кэширование маршрутов или контролировать маршруты движка с помощью кэширования. Это ограничение не позволяет возвращать кэшированный контент неаутентифицированным клиентам.

• mTLS функционально работает в доменной области. Однако для обеспечения безопасности там, где злоумышленники не могут обойти mTLS, чтобы связаться с вашим источником, на Azure Front Door есть управление mTLS. Перед включением mTLS на пользовательском домене сначала включите mTLS на Azure Front Door endpoint, к которому будет привязан пользовательский домен. Все домены с mTLS могут быть связаны только с маршрутами под такими конечными точками. Нельзя связывать домены с смешанным состоянием взаимной аутентификации с одной и той же конечной точкой.

• Нельзя связать домен Azure Front Door с маршрутами, если mTLS включён на Front Door endpoint. Наоборот, нужно отключить домен конечной точки от всех маршрутов под конечной точкой, прежде чем включать mTLS на конце.

• Если включить mTLS на существующем домене Azure Front Door, возникает простой, так как необходимо внести следующие изменения. Включите mTLS для новых пользовательских доменов.

1. Создайте новую конечную точку с включённым mTLS или используйте любой существующий эндпойнт Azure Front Door с включённым mTLS.

2. Отключите пользовательский домен от существующих маршрутов и конечной точки, у которых нет включённого mTLS.

3. Затем заново ассоциируйте пользовательский домен с конечной точкой.

• Как только взаимная аутентификация включена на домене, её отключение также приводит к простою.

  1. Отключить пользовательский домен от всех маршрутов в существующей конечной точке с поддержкой mTLS.

  2. Отключите mTLS на домене.

  3. Пересвязать домен с другой конечной точкой без включённого mTLS.

• Добавьте контроль доступа к вашему источнику, чтобы подтвердить, что запрос поступает с действительной Front Door. Дополнительные сведения см. в разделе Защита трафика к источникам Azure Front Door.

• CA Certificate Management: загрузите корень и до трёх промежуточных (PEM, <25 КБ) через Azure Key Vault. Нет авторотации, но поддержка двойного CA обеспечивает бесшовный переворот.

• Azure Front Door проводит проверки расширенного использования ключей (EKU) на сертификатах клиентов, чтобы убедиться, что они предназначены для аутентификации клиента, что является важной мерой безопасности. Однако из-за изменений в отрасли публичные центры сертификации (CA) вскоре прекратят выдачу сертификатов аутентификации клиентов с необходимым EKU. Переход к использованию частных CA, которые могут продолжать выдавать сертификаты с правильным EKU для mTLS-сценариев на Azure Front Door, обеспечивая бесперебойную и безопасную аутентификацию клиента.

• Клиенты уходят из OCSP. Во время проверки отзыва сертификатов Front Door Azure Front Door сейчас проверяет только OCSP.

• Если клиент отправляет запросы со следующими заголовками, Azure Front Door убирает эти заголовки и пересылает запрос в origin.

  • X-Azure-ClientCertEndDate
  • X-Azure-ClientCertFingerprint
  • X-Azure-ClientCertIssuer
  • X-Azure-ClientCertSerial
  • X-Azure-ClientCertStartDate
  • X-Azure-ClientCertSubject
  • X-Azure-ClientCertVerify
  • X-Azure-ClientCertificate

Какие метрики и логарифмические поля показывает решение?

Решение выделяет следующие метрики:

• Количество mTLS-запросов.

• Неудачные запросы mTLS.

• mTLS-запросы ошибок, разбитые по типам ошибок, именам SNI и протоколам TLS.

Предел конфигурационных квот

• Цепочка сертификатов клиентского CA может включать корень и до трёх промежуточных компонентов.

• Сертификаты CA должны быть закодированы PEM и иметь объем менее 25 КБ.

• Автоматическое вращение не поддерживается.

• Вы можете приложить два сертификата CA для бесшовного перевода во время истечения срока действия или отзыва. Azure Front Door использует действующий сертификат CA для проверки во время выполнения.

Шаги настройки

1. Чтобы узнать больше об ограничениях, смотрите раздел «Важные дизайнерские соображения ». Рекомендуется включать mTLS на новых конечных устройствах и доменах.

2. Войдите в портал Azure и найдите свой профиль Front Door.

3. В разделе «Безопасность» выберите сертификаты Mutual TLS CA. Вы видите список существующих цепочек сертификатов mTLS, если вы их загружали раньше.

4. Щелкните + Добавить. Вы видите объекты Key Vault и Secret, к которым у вас есть доступ. Выберите те, которые хотите использовать как открытый ключ в mTLS Handshake.

5. В разделе «Настройки» выберите «Менеджер входных дверей». Вы видите список ваших конечных точек.

6. Выберите + Add a endpoint и отметьте Enforce mutual TLS.

   Note

   Нельзя добавить домен Azure Front Door по умолчанию (например.z01.azurefd.net) в маршруты на этом конечном устройстве, если включен режим Enforce mutual TLS. Перейдите к следующему шагу, чтобы создать пользовательские домены с включённым mTLS, прежде чем создавать маршруты.

7. В разделе "Параметры" выберите "Домены". Вы видите список ваших существующих пользовательских доменов.

8. Щелкните + Добавить.

9. В разделе «Добавить страницу домена » настройте свой домен, затем прокрутите вниз до Расширенных настроек и выберите Включить mutual TLS , чтобы настроить mutual TLS для домена.

10. Выберите «Добавить », чтобы создать домен.

    1. Режим взаимного TLS: выберите из четырёх вариантов

       • Требуется и подтверждено сертификат клиента
       • Требуется сертификат клиента, но не валидирован
       • Проверка сертификата клиента при представлении
       • mTLS passthrough до источника

    2. Выберите сертификат CA при заполнении для Azure Front Door для проверки сертификата клиента.

    3. Включите проверку отзыва сертификата.

    4. Добавьте список SAN/CN для проверки. Пользовательское доменное имя Azure Front Door должно быть явно включено в этот список, чтобы считаться действительным для взаимной TLS-проверки.

11. После успешного создания домена перейдите на ранее созданную конечную точку в Front Door Manager и добавьте маршрут для связи этого домена с нужной группой происхождения.

12. Проверьте, работает ли mTLS как ожидается. Вы можете проверить это состояние, привязав локальный IP хоста к одному из IP-адресов Azure Front Door.

13. После успешной валидации обновите запись пользовательского домена CNMAE в DNS, чтобы она указывала на Azure Front Door endpoint.

    Ограничите доступ к серверу/источнику только для принятия трафика от Azure Front Door, который не позволяет обойти mTLS, напрямую обращаясь к исходному устройству. Дополнительные сведения см. в разделе Защита трафика к источникам Azure Front Door.

Для редактирования существующей конфигурации mTLS на домене на странице «Домены » выберите доменное имя. Страница «Редактировать домен» появляется с текущей конфигурацией mTLS.

Unexpected 403 (Forbidden) от Azure Front Door for mTLS request

Для получения дополнительной диагностической информации передайте заголовок X-Azure-DebugInfo:1 с запросом в Azure Front Door. Для ответа Front Door возвращает заголовок отладки, X-Azure-Externalerror, с значением, которое указывает на возможные ошибки. В следующей таблице перечислены значения ошибок и их значения.

Связанные материалы

• Шифрование TLS с помощью Azure Front Door
• Политика TLS Azure Front Door