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

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

  • Статья

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

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

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

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

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

  • Существует несколько стандартов проверки подлинности и авторизации, таких как OAuth 2.0, OpenID Подключение, веб-токены JSON (JWTs) и SAML (язык разметки утверждения безопасности). Определите, какие стандарты проверки подлинности и авторизации используются для приложения.

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

    • Как конечные пользователи будут проходить проверку подлинности и получать доступ к приложению?

    • Кто требуется разрешение на управление доступом на основе ролей (RBAC) для ресурсов и служб, которые использует приложение?

    • Существуют ли существующие встроенные роли охватывают требования к доступу RBAC как для уровня управления, так и для доступа к плоскости данных, или вам нужно создать новые пользовательские роли?

    • Группа платформы реализовала какие-либо политики соответствия требованиям, которые могут вызвать проблемы с приложением?

    • Какие компоненты приложения должны взаимодействовать друг с другом?

    • Существуют ли требования к доступу к общим ресурсам, таким как доменные службы Microsoft Entra, которые развертываются в целевой зоне платформы?

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

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

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

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

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

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

    • Легко спутать, как субъекты-службы и управляемые удостоверения получают доступ к ресурсам Azure. Чтобы понять разницу между этими двумя, см . раздел "Демистификация субъектов-служб" — управляемые удостоверения.

    • По возможности используйте управляемые удостоверения для поддержки проверки подлинности, а не с помощью субъектов-служб и регистрации приложений идентификатора Microsoft Entra. Для создания субъектов-служб и регистрации приложений необходимо иметь роли Application Администратор istrator или Application Developer RBAC. Эти привилегированные роли обычно назначаются команде платформы или группе удостоверений. Используйте управляемые удостоверения, чтобы устранить необходимость в команде платформы для создания субъектов-служб и регистрации приложений для вашей команды приложений.

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

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

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

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

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

    • Как и назначения ролей RBAC пользователя, следуйте принципу наименьших привилегий при предоставлении управляемому удостоверению доступа к ресурсу.

Внешние пользователи

Вы можете оценить сценарии, связанные с настройкой внешних пользователей, клиентов или партнеров, чтобы они могли получить доступ к ресурсам. Определите, включают ли эти сценарии конфигурации Microsoft Entra B2B или Azure Active Directory B2C (Azure AD B2C). Дополнительные сведения см. в разделе "Обзор Внешняя идентификация Microsoft Entra".

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

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

OpenID Connect

Если команда приложений использует конвейеры непрерывной интеграции и непрерывной доставки (CI/CD) для программного развертывания приложений, настройте проверку подлинности OpenID Подключение в службах Azure. Подключение OpenID использует временный маркер без учетных данных для проверки подлинности в службах Azure. Дополнительные сведения см. в статье "Федерация удостоверений рабочей нагрузки".

Если Подключение OpenID не поддерживается, создайте субъект-службу и назначьте необходимые разрешения для развертывания инфраструктуры или кода приложения. Дополнительные сведения см. в модуле обучения. Проверка подлинности конвейера развертывания Azure с помощью субъектов-служб.

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

Чтобы дополнительно ограничить доступ и запретить несанкционированный доступ к данным, используйте управление доступом на основе атрибутов (ABAC), где поддерживается, например с Хранилище BLOB-объектов Azure.

Доступ к виртуальной машине

По возможности используйте удостоверения идентификаторов Microsoft Entra для управления доступом к виртуальным машинам Azure. Используйте идентификатор Microsoft Entra вместо локальной проверки подлинности для предоставления доступа к виртуальным машинам, используя преимущества условного доступа Microsoft Entra, ведения журнала аудита и многофакторной проверки подлинности Microsoft Entra (MFA). Эта конфигурация снижает риск использования злоумышленниками небезопасных локальных служб проверки подлинности. Дополнительные сведения см. в статье "Вход в виртуальную машину Linux в Azure" с помощью идентификатора Microsoft Entra и OpenSSH и входа в виртуальную машину Windows в Azure с помощью идентификатора Microsoft Entra, включая пароль без пароля.

Платформа удостоверений Майкрософт

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

    • Рабочие или учебные учетные записи, подготовленные с помощью идентификатора Microsoft Entra

    • Личные учетные записи Майкрософт (Skype, Xbox, Outlook.com)

    • Социальные или локальные учетные записи с помощью идентификатора Microsoft Entra

  • В списке платформа удостоверений Майкрософт рекомендации и рекомендации проверка содержатся рекомендации по эффективной интеграции приложения с платформа удостоверений Майкрософт.

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

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

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

  • Если существует требование использовать управляемые удостоверения в масштабе, используйте управляемое удостоверение, назначаемое пользователем, для каждого типа ресурса в каждом регионе. Такой подход предотвращает сбой удостоверений. Например, агент Azure Monitor требует управляемого удостоверения на отслеживаемых виртуальных машинах Azure, что может привести к созданию (и удалению) идентификатора Microsoft Entra значительному количеству удостоверений. Управляемые удостоверения, назначаемые пользователем, можно создавать один раз и совместно использовать их на нескольких виртуальных машинах. Используйте Политика Azure для реализации этой рекомендации.

Key Vault

  • С помощью Key Vault можно управлять секретами, ключами, сертификатами, которые используются приложениями.

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

Прокси приложения Microsoft Entra

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

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

    • Если вы используете конвейеры развертывания CI/CD с достаточными разрешениями, владельцы приложений могут настроить прокси приложения Microsoft Entra с помощью API Microsoft Graph.

  • Если приложение использует устаревшие протоколы, например Kerberos, убедитесь, что целевая зона приложения имеет сетевое подключение к контроллерам домена в подписке платформа удостоверений Майкрософт.

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

Организация ресурсов