Защита изоляции ресурсов в одном клиенте в идентификаторе Microsoft Entra
Многие сценарии разделения можно достичь в одном клиенте. Если это возможно, рекомендуется делегировать администрирование в отдельные среды в одном клиенте, чтобы обеспечить лучшую производительность и совместную работу.
Результаты
Разделение ресурсов. Чтобы ограничить доступ к ресурсам пользователям, группам и субъектам-службам, используйте роли каталога Microsoft Entra, группы безопасности, политики условного доступа, группы ресурсов Azure, группы управления Azure, административные единицы (AUS) и другие элементы управления. Включение отдельных администраторов для управления ресурсами. Используйте отдельные пользователи, разрешения и требования к доступу.
Используйте изоляцию в нескольких клиентах, если есть:
- Наборы ресурсов, требующие параметров на уровне клиента
- Минимальный уровень допустимости риска для несанкционированного доступа участниками клиента
- Изменения конфигурации вызывают нежелательные последствия
Разделение конфигурации. В некоторых случаях такие ресурсы, как приложения, имеют зависимости от конфигураций на уровне клиента, таких как методы проверки подлинности или именованные расположения. При изоляции ресурсов следует учитывать зависимости. Глобальные администраторы могут настроить параметры ресурсов и параметры на уровне клиента, влияющие на ресурсы.
Если набор ресурсов требует уникальных параметров на уровне клиента или другая сущность управляет параметрами клиента, используйте изоляцию с несколькими клиентами.
Административное разделение — с делегированным администрированием идентификатора Microsoft Entra ID, разделение администрирования ресурсов, таких как приложения и API, пользователи и группы, группы ресурсов и политики условного доступа.
Глобальные администраторы могут обнаруживать и получать доступ к доверенным ресурсам. Настройка аудита и оповещений для изменений администратора, прошедших проверку подлинности, в ресурс.
Используйте административные единицы (AUS) в идентификаторе Microsoft Entra для административного разделения. AUs ограничивает разрешения в роли определенной частью вашей организации. Используйте AUS, чтобы делегировать роль администратора helpdesk специалистам региональной поддержки. Затем они могут управлять пользователями в регионе, который они поддерживают.
Используйте AUS для разделения пользователей, групп и объектов устройств. Назначьте единицы правилам для динамических групп членства.
С помощью управление привилегированными пользователями (PIM) выберите пользователя, чтобы утвердить запросы на высоко привилегированные роли. Например, выберите администраторов, которым требуется доступ администратора проверки подлинности для внесения изменений в метод проверки подлинности пользователей.
Примечание.
Использование PIM требуется и лицензия Microsoft Entra ID P2 на человека.
Чтобы подтвердить, что администраторы проверки подлинности не могут управлять ресурсом, изолируйте ресурс в отдельном клиенте с отдельными администраторами проверки подлинности. Используйте этот метод для резервного копирования. Примеры см . в руководстве по многопользовательской авторизации.
Распространенные варианты использования
Обычное использование нескольких сред в одном клиенте — разделение рабочей среды от непроизводственных ресурсов. В клиенте команды разработки и владельцы приложений создают отдельную среду с помощью тестовых приложений, тестовых пользователей и групп и тестовых политик для этих объектов. Аналогичным образом команды создают непроизводственные экземпляры ресурсов Azure и доверенных приложений.
Используйте непроизводственные ресурсы Azure и непроизводственные экземпляры интегрированных приложений Microsoft Entra с эквивалентными объектами каталога непроизводства. Непроизводственные ресурсы в каталоге предназначены для тестирования.
Примечание.
Избегайте нескольких сред Microsoft 365 в клиенте Microsoft Entra. Однако в клиенте Microsoft Entra можно использовать несколько сред Dynamics 365.
Другой сценарий изоляции в одном клиенте — разделение между расположениями, дочерними или многоуровневой администрированием. См. модель корпоративного доступа.
Используйте назначения управления доступом на основе ролей Azure (Azure RBAC) для администрирования ресурсов Azure с ограниченной областью. Аналогичным образом включите управление идентификаторами Microsoft Entra ID для приложений с доверием к приложениям с помощью нескольких возможностей. Примерами являются условный доступ, фильтрация пользователей и групп, назначения административных единиц и назначения приложений.
Чтобы обеспечить изоляцию служб Microsoft 365, включая промежуточное размещение конфигурации на уровне организации, выберите изоляцию нескольких клиентов.
Управление с заданной областью для ресурсов Azure
Используйте Azure RBAC для разработки модели администрирования с детализированной областью и областью поверхности. Рассмотрим иерархию управления в следующем примере:
Примечание.
Иерархию управления можно определить на основе требований организации, ограничений и целей. Дополнительные сведения см. в руководстве по Cloud Adoption Framework, организации ресурсов Azure.
- Группа управления— назначение ролей группам управления, чтобы они не влияли на другие группы управления. В предыдущем сценарии команда отдела кадров определяет политику Azure для аудита регионов, где ресурсы развертываются в подписках отдела кадров.
- Подписка — назначение ролей подписке, чтобы предотвратить влияние других групп ресурсов. В предыдущем сценарии команда отдела кадров назначает роль читателя для подписки "Преимущества", не читая другие подписки на персонал или подписку из другой команды.
- Группа ресурсов — назначение ролей группам ресурсов, чтобы они не влияли на другие группы ресурсов. Группа разработчиков преимуществ назначает роль участника кому-то для управления тестовой базой данных и тестируемым веб-приложением, а также для добавления дополнительных ресурсов.
- Отдельные ресурсы — назначение ролей ресурсам, чтобы они не влияли на другие ресурсы. Команда разработчиков преимуществ назначает аналитику данных роль читателя учетной записи Cosmos DB для тестового экземпляра базы данных Azure Cosmos DB. Эта работа не мешает тестовой веб-приложению или рабочему ресурсу.
Дополнительные сведения см. в статье о встроенных ролях Azure и о том, что такое Azure RBAC?.
Структура является иерархической. Таким образом, чем выше в иерархии, тем шире область, видимость и влияние на более низкие уровни. Области верхнего уровня влияют на ресурсы Azure в границе клиента Microsoft Entra. Разрешения можно применять на нескольких уровнях. Это действие представляет риск. Назначение ролей выше иерархии может обеспечить более низкий уровень доступа, чем вы планируете. Microsoft Entra обеспечивает видимость и исправление, чтобы снизить риск.
- Корневая группа управления определяет политики Azure и назначения ролей RBAC, применяемые к подпискам и ресурсам.
- Глобальные администраторы могут повысить доступ к подпискам и группам управления
Отслеживайте области верхнего уровня. Важно планировать другие измерения изоляции ресурсов, например сети. Рекомендации по сети Azure см . в рекомендациях по обеспечению безопасности сети Azure. Рабочие нагрузки инфраструктуры как услуги (IaaS) имеют сценарии, в которых идентификация и изоляция ресурсов должны быть частью проектирования и стратегии.
Рассмотрите возможность изоляции конфиденциальных или тестовых ресурсов в соответствии с концептуальной архитектурой целевой зоны Azure. Например, назначьте подписки удостоверений отдельным группам управления. Отдельные подписки для разработки в группах управления песочницами. Дополнительные сведения см. в документации по масштабированию предприятия. Разделение для тестирования в клиенте рассматривается в иерархии группы управления эталонной архитектуры.
Управление областью для приложений, которыми доверяет идентификатор Microsoft Entra
В следующем разделе показан шаблон управления областью управления доверенными приложениями Microsoft Entra ID.
Идентификатор Microsoft Entra поддерживает настройку нескольких экземпляров пользовательских приложений и приложений SaaS, но не в большинстве службы Майкрософт в одном каталоге с независимыми назначениями пользователей. В предыдущем примере есть рабочая и тестовая версия приложения для путешествий. Чтобы добиться разделения конфигурации и политики для конкретного приложения, разверните предварительные версии для корпоративного клиента. Это действие позволяет владельцам рабочих нагрузок выполнять тестирование с корпоративными учетными данными. Объекты каталогов, непроизводственные, такие как тестовые пользователи и группы тестирования, связаны с непроизводным приложением с отдельным владельцем этих объектов.
Существуют аспекты, влияющие на доверие приложений в границе клиента Microsoft Entra:
- Глобальные администраторы управляют всеми параметрами на уровне клиента
- Другие роли каталога, такие как администратор пользователей, администратор приложений и администраторы условного доступа, управляют конфигурацией на уровне клиента в области роли.
Параметры конфигурации, такие методы проверки подлинности, гибридные конфигурации, разрешить совместную работу B2B домены и именованные расположения являются широкими клиентами.
Примечание.
Разрешения API Microsoft Graph и разрешения на согласие не могут быть ограничены участниками группы или au. Эти разрешения назначаются на уровне каталога. Только согласие для конкретного ресурса разрешает область на уровне ресурсов, в настоящее время ограничена разрешениями Чата Microsoft Teams.
Внимание
Жизненный цикл служб Microsoft SaaS, таких как Office 365, Microsoft Dynamics и Microsoft Exchange, привязан к клиенту Microsoft Entra. В результате для нескольких экземпляров этих служб требуется несколько клиентов Microsoft Entra.