Управление удостоверениями и доступом для акселератора целевой зоны Azure Spring Apps

В этой статье описываются рекомендации и рекомендации по проверке подлинности пользователей в Azure Spring Apps и предоставление пользователям необходимого уровня доступа к ресурсам рабочей нагрузки.

Централизованная команда платформы и команды приложений должны иметь хорошее представление:

• Для каких команд требуется доступ к рабочей нагрузке приложения Azure Spring, развернутой в целевой зоне приложения.
• Роли и ответственность пользователей и пользователей, которым требуется доступ.
• Минимальный уровень привилегий, необходимых для выполнения этих обязанностей.

Сведения о проектировании платформы см . в области проектирования удостоверений Azure и управления доступом.

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

Рекомендации по проектированию

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

• Доступ к приложению. Пользователи могут отправлять запросы в приложение через общедоступный Интернет. Или запросы могут поступать из частных или локальных сетей. В любом случае доступ должен проходить проверку подлинности на основе сертификатов клиента или с помощью идентификатора Microsoft Entra.

  Рассмотрим варианты технологии для механизма обнаружения служб, вызывающего вызовы между приложениями. Параметры зависят от уровня Azure Spring Apps.

  • Базовый или стандартный: обнаружение служб Kubernetes или Реестр управляемых служб Spring Cloud (с помощью Eureka)
  • Корпоративная: Реестр служб Tanzu

• Доступ оператора к ресурсам. Участники группы с различными обязанностями могут получить доступ к рабочей нагрузке. Например, может потребоваться предоставить доступ:

  • Участники группы платформы, которым требуется рабочий доступ.
  • Участники группы приложений, которые разрабатывают приложения.
  • Инженеры DevOps, которые создают и выпускают конвейеры для развертывания рабочей нагрузки и настройки с помощью инфраструктуры в качестве кода (IaC).
  • Инженеры надежности сайта для устранения неполадок.

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

• Доступ к данным конфигурации. На основе выбранного уровня для Azure Spring Apps (базовый или стандартный или корпоративный) необходимо выбрать параметры сервера конфигурации.

  Для "Базовый" рассмотрите возможность поддержки сервера и клиентской стороны. Чтобы сохранить файлы сервера конфигурации, выберите внешнюю конфигурацию в распределенной системе, например Azure DevOps, GitHub, GitLab или Bitbucket.

  Вы можете использовать общедоступные или частные репозитории и выбрать их механизм проверки подлинности. Azure Spring Apps поддерживает базовую проверку подлинности на основе паролей или маркеров и SSH.

  Для Enterprise рекомендуется использовать службу конфигурации приложений для VMware Tanzu, которая позволяет управлять ресурсами ConfigMap на основе Kubernetes, которые заполняются свойствами, определенными в одном или нескольких репозиториях Git.

Рекомендации по проектированию

Управляемые удостоверения

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

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

Дополнительные сведения см. в разделе "Выбор системных или назначаемых пользователем управляемых удостоверений".

Используйте встроенные роли Azure RBAC, чтобы упростить управление необходимыми разрешениями для управляемого удостоверения.

• Используйте собственное управляемое удостоверение для Azure Spring Apps.
• Используйте управляемые удостоверения, назначаемые системой, и назначаемые пользователем удостоверения отдельно. Дополнительные сведения см. в рекомендациях по использованию управляемых удостоверений.
• Используйте управление привилегированными пользователями в идентификаторе Microsoft Entra.

Безопасный интернет-обмен данными

• Используйте сертификаты, выданные центром сертификации, расширенные сертификаты проверки или дикие карта сертификаты.
• Используйте самозаверяющий сертификат только для предварительной среды.
• Безопасно загружайте сертификаты из Azure Key Vault.

управление доступом на основе ролей (RBAC);

• Рассмотрите возможность создания пользовательских ролей. Следуйте принципу наименьших привилегий, если для ролей вне поля требуются изменения существующих разрешений.
• Выберите хранилище расширенной безопасности для ключей, секретов, сертификатов и конфигурации приложений.
• Для автоматического развертывания настройте субъект-службу с минимальными необходимыми разрешениями для развертывания из конвейера CI/CD.
• Включите ведение журнала диагностики для консоли приложений, системных журналов, журналов входящего трафика, журналов сборки и журналов событий контейнера. Эти подробные журналы можно использовать для диагностики проблем с приложением и мониторинга запросов на доступ. При включении этих журналов журналы действий Azure Monitor дает представление о событиях уровня подписки.

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

Топология сети и подключения