Часть 2. Требования проверки подлинности в этом примере

Предыдущая часть: введение и фон

В этом примере основное приложение имеет три различных требования к проверке подлинности:

• Azure Key Vault

  Приложение должно пройти проверку подлинности с помощью Azure Key Vault, чтобы получить защищенный ключ API, необходимый для вызова сторонней службы.

• Сторонний API

  После получения ключа API приложение использует ключ для проверки подлинности с помощью внешнего стороннего API.

• Хранилище очередей Azure

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

Для этих задач приложению требуется управлять тремя наборами учетных данных:

• Два набора ресурсов Azure (Key Vault и Storage)

• Один набор для внешнего сервиса (сторонний API)

Проблемы проверки подлинности ключей

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

• Циклическая зависимость от Key Vault

  Приложение использует Azure Key Vault для безопасного хранения секретов, таких как ключи API сторонних производителей или учетные данные службы хранилища Azure. Однако для получения этих секретов приложение должно сначала пройти проверку подлинности с помощью Key Vault. В этой ситуации возникает циклическая проблема: приложению требуются учетные данные для доступа к Key Vault, но эти учетные данные должны храниться безопасно. Без безопасного решения эта проблема может привести к жестко закодированных учетных данных или небезопасным конфигурациям в средах разработки.

• Безопасная обработка ключей API третьих сторон

  После получения ключа API из Key Vault приложение должно использовать его для вызова внешней сторонней службы. Обработайте этот ключ с чрезвычайной осторожностью:

  • Никогда не жестко кодировать его в файлах исходного кода или конфигурации
  • Никогда не регистрировать его в stdout, stderr или журналы приложений
  • Храните его только в памяти и обращайтесь к нему во время выполнения, непосредственно перед использованием
  • Немедленно удалите это после выполнения запроса

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

• Защита учетных данных хранилища очередей Azure

  Для записи сообщений в хранилище очередей Azure приложению обычно требуется строка подключения или токен общего доступа. Эти учетные данные:

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

• Гибкость среды

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

  Это требование означает:

  • Не внедряйте секреты для конкретной среды в код
  • Не переключайте учетные данные или пути логики вручную
  • Согласованное использование проверки подлинности на основе удостоверений в разных средах

Проверка подлинности с приоритетом Azure с помощью Microsoft Entra ID

Так как облачные приложения масштабируются в сложности и интегрируются с дополнительными службами, безопасная и упрощенная проверка подлинности становится важной. Azure предлагает модель управления идентификацией, ориентированную в первую очередь на Azure, на базе Microsoft Entra ID, обеспечивая единое управление идентификацией и бесшовную интеграцию со службами Azure для безопасной аутентификации без учетных данных.

Вместо того, чтобы вручную управлять секретами или внедрением учетных данных в код приложения — практика, подверженная рискам безопасности, Microsoft Entra ID позволяет приложениям безопасно проходить проверку подлинности с помощью управляемых удостоверений.

Основные преимущества управляемых удостоверений Microsoft Entra:

• Нет секретов в коде

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

• Встроенное удостоверение для приложений

  Azure может автоматически назначать управляемое удостоверение приложению, поэтому он может безопасно получать доступ к таким службам, как Key Vault, хранилище и SQL без дополнительных учетных данных.

• Согласованность среды

  Одна и та же модель кода и удостоверений работает как при локальной разработке, так и в средах, размещенных в Azure, с помощью Azure SDK DefaultAzureCredential.

Поток идентификации для специфичной среды

Приложения, использующие идентификатор Microsoft Entra для проверки подлинности, используют гибкие модели удостоверений, которые легко работают в средах разработки, размещенных в Azure и локальных средах разработки. DefaultAzureCredential Azure SDK обеспечивает эту согласованность путем автоматического выбора соответствующего метода идентификации в зависимости от среды.

Среда Azure

При развертывании приложения в Azure:

• Приложению автоматически назначается управляемая идентичность.
• Azure самостоятельно управляет выдачей токенов и жизненным циклом учетных данных, поэтому вам не нужно работать с какими-либо секретами.
• Приложение обращается к службам с использованием ролевого управления доступом (RBAC) или политик доступа Key Vault.

Локальная среда разработки

Во время локальной разработки:

• Субъект-служба служит удостоверением приложения.
• Разработчики проходят проверку подлинности с помощью Azure CLI (az login), переменных среды или интеграции Visual Studio/VS Code.
• Тот же код приложения работает без каких-либо изменений — меняется только источник идентификации.

В обеих средах пакеты SDK Azure используют DefaultAzureCredential, который абстрагирует источник учетных данных и автоматически выбирает подходящий метод.

Рекомендации по безопасной разработке

Хотя секреты можно задать как переменные среды (например, с помощью параметров приложение Azure), этот подход имеет недостатки:

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

Вместо этого используйте следующий подход:

• Используйте Key Vault для хранения сторонних ключей API и других секретов.
• Назначьте управляемое удостоверение личности развернутому приложению.
• Используйте субъект-службу для локальной разработки и назначьте ему те же права доступа.
• Используйте DefaultAzureCredential в коде для абстрактной логики проверки подлинности.
• Избегайте хранения или ведения журнала учетных данных.

Поток проверки подлинности на практике

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

• Ваш код создает этот DefaultAzureCredential экземпляр.
• Эти учетные данные используются для создания экземпляра клиента (например, SecretClient, QueueServiceClient).
• Когда приложение вызывает метод (например, get_secret()), клиент использует учетные данные для проверки подлинности запроса.
• Azure проверяет идентичность и проверяет, имеет ли она правильную роль или политику, чтобы выполнить операцию.

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