Общие сведения о делегированном администрировании и изолированных средах
Архитектура Microsoft Entra с одним клиентом с делегированным администрированием часто подходит для разделения сред. Как подробно описано в других разделах этой статьи, корпорация Майкрософт предоставляет для этого множество инструментов. Однако могут быть случаи, когда вашей организации требуется степень изоляции, превышающая ту, которая может быть достигнута в одном арендаторе.
Прежде чем обсуждать конкретные архитектуры, важно понимать следующее:
Как работает типичный одиночный арендатор.
Как работают административные единицы в идентификаторе Microsoft Entra ID.
Связи между ресурсами Azure и клиентами Microsoft Entra.
Общие требования к изоляции.
Клиент Microsoft Entra в качестве границы безопасности
Клиент Microsoft Entra предоставляет возможности управления удостоверениями и доступом (IAM) для приложений и ресурсов, используемых организацией.
Удостоверение — это объект каталога, который может быть аутентифицирован и авторизован для доступа к ресурсу. Объекты удостоверений существуют для удостоверений человека и удостоверений, не относящихся к человеку. Чтобы различать эти удостоверения, удостоверения человека называются удостоверениями, а удостоверения, не относящиеся к человеку, называются удостоверениями рабочей нагрузки. К объектам, не относящимся к человеку, относятся объекты приложений, субъекты-службы, управляемые удостоверения и устройства. Терминология в отрасли не согласована, но, как правило, удостоверение рабочей нагрузки — это то, что необходимо для вашей сущности программного обеспечения для проверки подлинности в определенной системе.
Чтобы различать удостоверения человека и удостоверения, не относящиеся к человеку, в ИТ-индустрии появляются разные термины:
Удостоверение — удостоверение , начатое с описания объекта Active Directory (AD) и Microsoft Entra, используемого людьми для проверки подлинности. В этой серии статей удостоверение относится к объектам, которые представляют людей.
Удостоверение рабочей нагрузки. В идентификаторе Microsoft Entra удостоверения рабочей нагрузки — это приложения, субъекты-службы и управляемые удостоверения. Удостоверение рабочей нагрузки используется для аутентификации и доступа к другим службам и ресурсам.
Дополнительные сведения об удостоверениях рабочих нагрузок см. в статье Что такое удостоверения рабочих нагрузок.
Клиент Microsoft Entra — это граница безопасности удостоверений, которая находится под контролем администраторов. В пределах этой границы безопасности администрирование подписок, групп управления и групп ресурсов может быть делегировано сегментированному административному контролю ресурсов Azure. Хотя эти группы не взаимодействуют напрямую, они зависят от конфигураций политик и параметров на уровне арендатора. И эти параметры и конфигурации находятся под контролем глобальных Администратор istrаторов Microsoft Entra.
Идентификатор Microsoft Entra используется для предоставления объектам, представляющим удостоверения доступа к приложениям и ресурсам Azure. В этом смысле как ресурсы Azure, так и приложения, доверяющие идентификатору Microsoft Entra, являются ресурсами, которые можно управлять с помощью идентификатора Microsoft Entra. На следующей схеме граница клиента Microsoft Entra отображает объекты удостоверений Microsoft Entra и средства настройки. Под каталогом находятся ресурсы, которые используют объекты удостоверения для управления удостоверением и доступом. В соответствии с рекомендациями среда настроена с тестовой средой для проверки корректности операции IAM.
Доступ к приложениям, используюющим идентификатор Microsoft Entra
Удостоверениям может быть предоставлен доступ ко многим типам приложений. Вот некоторые примеры.
Службы повышения производительности Microsoft, такие как Exchange Online, Microsoft Teams и SharePoint Online.
ИТ-службы Microsoft, такие как Azure Sentinel, Microsoft Intune и ATP в Microsoft 365 Defender.
Инструменты разработчика Microsoft, такие как Azure DevOps и API Microsoft Graph.
Решения SaaS, такие как Salesforce и ServiceNow.
Локальные приложения, интегрированные с возможностями гибридного доступа, такими как прокси приложения Microsoft Entra
Приложения собственной, пользовательской разработки.
Приложения, использующие идентификатор Microsoft Entra, требуют настройки и управления объектами каталога в доверенном клиенте Microsoft Entra. Примеры объектов каталога включают регистрацию приложений, субъекты-службы, группы и расширения атрибутов схемы.
Доступ к ресурсам Azure
Пользователям, группам и объектам субъекта-службы (удостоверениям рабочей нагрузки) в клиенте Microsoft Entra предоставляются роли с помощью контроль доступа на основе ролей Azure (RBAC) и управления доступом на основе атрибутов Azure (ABAC).
Azure RBAC позволяет предоставлять доступ на основе роли, определяемой субъектом безопасности, определением роли и областью действия.
Azure ABAC основывается на Azure RBAC путем добавления условий назначения ролей на основе атрибутов в контексте определенных действий. Условие назначения роли — это еще одна проверка, которую можно дополнительно добавить к назначению роли, чтобы обеспечить более детальное управление доступом.
Доступ к ресурсам Azure, группам ресурсов, подпискам и группам управления осуществляется с помощью этих назначенных ролей RBAC. Например, на следующей схеме показано распределение административных возможностей в идентификаторе Microsoft Entra с помощью управления доступом на основе ролей.
Ресурсы Azure, поддерживающие управляемые удостоверения , позволяют ресурсам проходить проверку подлинности, предоставлять доступ и назначать роли другим ресурсам в пределах клиента Microsoft Entra.
Приложения, использующие идентификатор Microsoft Entra для входа, также могут использовать ресурсы Azure, такие как вычисления или хранилище в рамках его реализации. Например, пользовательское приложение, работающее в Azure и доверяющее идентификатору Microsoft Entra для проверки подлинности, содержит объекты каталогов и ресурсы Azure.
Наконец, все ресурсы Azure в клиенте Microsoft Entra влияют на квоты и ограничения Azure на уровне клиента.
Доступ к объектам каталога
Как описано на предыдущей схеме, удостоверения, ресурсы и их связи представлены в клиенте Microsoft Entra как объекты каталога. Примеры объектов каталога включают пользователей, группы, субъекты-службы и регистрации приложений.
Наличие набора объектов каталога в границе клиента Microsoft Entra приводит к возникновению следующих возможностей:
Видимость. Удостоверения могут обнаруживать или перечислять ресурсы, пользователей, группы, получать доступ к отчетам об использовании и журналам аудита на основе своих разрешений. Например, член каталога может обнаруживать пользователей в каталоге на разрешения пользователя по умолчанию идентификатора Microsoft Entra.
Приложения могут воздействовать на объекты. Приложения могут управлять объектами каталогов через Microsoft Graph в рамках своей бизнес-логики. Типичные примеры включают чтение или настройку атрибутов пользователя, обновление календаря пользователя, отправку электронных писем от имени пользователя и т. д. Необходимо предоставить согласие, чтобы приложения могли влиять на арендатора. Администраторы могут предоставлять согласие для всех пользователей. См. сведения о разрешениях и согласии для платформы удостоверений Майкрософт.
Примечание.
Будьте осторожны при использовании разрешений приложений. Например, при работе с Exchange Online вы должны ограничить разрешения приложения определенными почтовыми ящиками и разрешениями.
- Ограничения на регулирование и обслуживание. Поведение среды выполнения ресурса может активировать регулирование, чтобы предотвратить чрезмерное использование ресурсов или снижение производительности службы. Регулирование может применяться на уровне приложения, арендатора или всей службы. Чаще всего это происходит, когда приложение имеет большое количество запросов внутри арендаторов или между ними. Аналогичным образом существуют ограничения и ограничения службы Microsoft Entra, которые могут повлиять на поведение среды выполнения приложений.
Административные единицы для управления ролями
Административные единицы ограничивают разрешения в роли для любой части организации, которую вы определяете. Вы можете, например, использовать административные единицы для делегирования роли администратора службы поддержки региональным специалистам службы поддержки, чтобы они могли управлять пользователями только в том регионе, который они поддерживают. Административная единица — это ресурс Microsoft Entra, который может быть контейнером для других ресурсов Microsoft Entra. Административная единица может содержать только:
Пользователи
Группы
.
На следующей схеме административные единицы используются для сегментирования клиента Microsoft Entra далее на основе бизнес-структуры или организационной структуры. Это полезно, когда разные бизнес-подразделения или группы имеют выделенный персонал ИТ-поддержки. Административные единицы можно использовать для предоставления привилегированных разрешений, ограниченных назначенной административной единицей.
Дополнительные сведения об административных единицах см. в разделе Администратор istrative units in Microsoft Entra ID.
Распространенные причины изоляции ресурсов
Иногда группу ресурсов следует изолировать от других ресурсов по соображениям безопасности или по другим причинам, например, если у ресурсов есть уникальные требования к доступу. Это хороший вариант использования административных единиц. Вы должны определить, какие пользователи и субъекты безопасности должны иметь доступ к ресурсам и в каких ролях. Причины для изоляции ресурсов могут включать:
Команды разработчиков нуждаются в гибкости для безопасного выполнения итераций в течение жизненного цикла разработки программного обеспечения приложений. Но разработка и тестирование приложений, записываемых в идентификатор Microsoft Entra ID, может повлиять на клиент Microsoft Entra с помощью операций записи. Приведем несколько примеров.
Новые приложения, которые могут изменить содержимое Office 365, например сайты SharePoint, OneDrive, MS Teams и т. д.
Пользовательские приложения, которые могут изменять данные пользователей с помощью MS Graph или аналогичных API в большом масштабе (например, приложения, которым разрешено использование Directory.ReadWrite.All).
Скрипты DevOps, которые обновляют большие наборы объектов в рамках жизненного цикла развертывания.
Разработчикам интегрированных приложений Microsoft Entra необходима возможность создания пользовательских объектов для тестирования, и эти объекты пользователей не должны иметь доступа к рабочим ресурсам.
Непроизводственные ресурсы и приложения Azure, которые могут повлиять на другие ресурсы. Например, новую бета-версию приложения SaaS может понадобиться изолировать от рабочего экземпляра приложения и рабочих пользовательских объектов.
Секретные ресурсы, которые должны быть защищены от обнаружения, перечисления или захвата существующими администраторами по нормативным или критически важным для бизнеса причинам.
Конфигурация в арендаторе
Параметры конфигурации в идентификаторе Microsoft Entra могут повлиять на любой ресурс в клиенте Microsoft Entra с помощью целевых или действий управления на уровне клиента. Примеры настроек на уровне арендатора включают:
Внешние удостоверения: Администратор istrator определяют и управляют внешними удостоверениями, которые можно подготовить в клиенте.
Следует ли разрешать внешние удостоверения в клиенте.
Из каких доменов можно добавлять внешние удостоверения.
Могут ли пользователи приглашать пользователей из других клиентов.
Именованные расположения: Администратор istrators могут создавать именованные расположения, которые затем можно использовать для
Блокировка входа из определенных расположений.
Активация политик условного доступа, таких как MFA.
Обход требований безопасности
Варианты самообслуживания. Администратор istrator задают параметры самообслуживания, такие как самостоятельный сброс пароля и создание групп Microsoft 365 на уровне клиента.
Реализация некоторых конфигураций на уровне клиента может быть область до тех пор, пока они не переопределяются глобальными политиками. Например:
Если в клиенте разрешены внешние удостоверения, администратор ресурсов все равно может запретить доступ для этих удостоверений.
Если в клиенте разрешена регистрация личного устройства, администратор ресурсов может запретить доступ с них к определенным ресурсам.
Если настроены именованные расположения, администратор ресурсов может настроить политики, разрешающие или исключающие доступ из этих расположений.
Распространенные причины изоляции конфигурации
Конфигурации, контролируемые администраторами, влияют на ресурсы. В то время как некоторые конфигурации на уровне арендатора могут быть ограничены политиками, чтобы не применяться или частично применяться к определенному ресурсу, другие не могут. Если ресурс имеет уникальные требования к конфигурации, изолируйте его в отдельном клиенте. Примеры сценариев изоляции конфигурации включают:
Ресурсы с требованиями, противоречащими существующим положениям безопасности или совместной работы на уровне арендатора. (Например, разрешенные типы аутентификации, политики управления устройствами, возможность самообслуживания, проверка удостоверения для внешних удостоверений и т. д.)
Требования к соответствию требованиям, которые область сертификации для всей среды, включая все ресурсы и сам клиент Microsoft Entra, особенно если эти требования конфликтуют с или должны исключить другие организационные ресурсы.
Требования к доступу внешних пользователей, противоречащие политикам производственных или конфиденциальных ресурсов.
Организации, охватывающие несколько стран или регионов и компаний, размещенных в одном клиенте Microsoft Entra. Например, какие параметры и лицензии используются в разных странах или регионах или дочерних компаниях.
Администрация в арендаторе
Удостоверения с привилегированными ролями в клиенте Microsoft Entra имеют видимость и разрешения для выполнения задач конфигурации, описанных в предыдущих разделах. Администрирование включает в себя как администрирование объектов удостоверений, таких как пользователи, группы и устройства, так и ограниченную реализацию конфигураций на уровне арендатора для аутентификации, авторизации и т. д.
Администрирование объектов каталога
Администраторы управляют тем, как объекты идентификации могут получать доступ к ресурсам и при каких обстоятельствах. Они также могут отключать, удалять или изменять объекты каталога в зависимости от своих привилегий. К объектам удостоверений относятся:
Организационные удостоверения, например следующие, представлены объектами пользователей:
Администраторы
Пользователи организации
Разработчики организации.
Учетные записи службы
Тестовые пользователи
Внешние удостоверения представляют пользователей за пределами организации, например:
Партнеры, поставщики или продавцы, подготовленные с помощью локальных учетных записей для среды организации.
Партнеры, поставщики или продавцы, подготовленные через совместную работу Azure B2B.
Группы, представленные такими объектами, как:
Группы безопасности
Динамические группы
Административные единицы
Устройства, представленные такими объектами, как:
Гибридные устройства, присоединенные к Microsoft Entra (локальные компьютеры, синхронизированные с локальная служба Active Directory)
Устройства, присоединенные к Microsoft Entra
Microsoft Entra зарегистрировала мобильные устройства, используемые сотрудниками для доступа к рабочим приложениям.
Microsoft Entra зарегистрировала устройства нижнего уровня (устаревшие версии). Например, Windows 2012 R2.
Удостоверения рабочих нагрузок
Управляемые удостоверения
Субъекты-службы
Приложения
В гибридной среде удостоверения обычно синхронизируются из среды локальная служба Active Directory с помощью Microsoft Entra Подключение.
Администрирование служб идентификации
Администраторы с соответствующими разрешениями также могут управлять порядком реализации политик на уровне арендатора на уровне групп ресурсов, групп безопасности или приложений. При рассмотрении вопросов администрирования ресурсов помните следующее. Каждый из них может быть причиной для хранения ресурсов вместе или для их изоляции.
Глобальный администратор может управлять любой подпиской Azure, связанной с арендатором.
Удостоверение, назначенное ролью проверки подлинности Администратор istrator, может требовать повторной регистрации для проверки подлинности MFA или FIDO.
Условный доступ Администратор istrator может создавать политики условного доступа, требующие входа пользователей в определенные приложения только с устройств, принадлежащих организации. Они также могут охватывать конфигурации. Например, даже если в арендаторе разрешены внешние удостоверения, они могут исключить эти удостоверения из доступа к ресурсу.
Администратор облачных приложений может давать разрешения приложениям от имени всех пользователей.
Распространенные причины административной изоляции
Кто должен иметь возможность управлять средой и ее ресурсами? Бывают случаи, когда администраторы одной среды не должны иметь доступа к другой среде. Вот некоторые примеры.
Разделение административных обязанностей на уровне арендатора для дальнейшего снижения риска безопасности и операционных ошибок, влияющих на критически важные ресурсы.
Правила, которые ограничивают, кто может администрировать окружающую среду на основе таких условий, как гражданство, проживание, уровень разрешения и т. д., которые не могут быть размещены с персоналом.
Рекомендации по безопасности и эксплуатации
Учитывая взаимозависимость между клиентом Microsoft Entra и его ресурсами, важно понимать риски компрометации или ошибки в системе безопасности и эксплуатации. Если вы работаете в федеративной среде с синхронизированными учетными записями, локальный компромисс может привести к компрометации идентификатора Microsoft Entra ID.
Компрометация удостоверения. В пределах арендатора любому удостоверению может быть назначена любая роль при условии, что тот, кто предоставляет доступ, имеет достаточные привилегии. Хотя влияние скомпрометированных не привилегированных удостоверений в значительной степени содержится, скомпрометированные администраторы могут иметь широкие последствия. Например, если учетная запись Microsoft Entra Global Администратор istrator скомпрометирована, ресурсы Azure могут быть скомпрометированы. Чтобы снизить риск компрометации удостоверений или плохих субъектов, реализуйте многоуровневое администрирование и убедитесь, что вы следуете принципам наименьших привилегий для ролей Microsoft Entra Администратор istrator. Аналогичным образом убедитесь, что вы создаете политики условного доступа, которые специально исключают тестовые учетные записи и тестовые субъекты-службы из доступа к ресурсам за пределами тестовых приложений. Дополнительные сведения о стратегии привилегированного доступа см. в статье Привилегированный доступ: стратегия.
Компрометация федеративной среды
Доверие к компрометации ресурсов. Удостоверения человека — не единственный фактор безопасности. Любой скомпрометированный компонент клиента Microsoft Entra может повлиять на доверительные ресурсы на основе его уровня разрешений на уровне клиента и ресурса. Влияние скомпрометированного компонента доверенного ресурса Microsoft Entra ID определяется привилегиями ресурса; Ресурсы, которые глубоко интегрированы с каталогом для выполнения операций записи, могут иметь глубокое влияние на весь клиент. Выполнение рекомендаций из руководства "Никому не доверяй" может помочь ограничить влияние компрометации.
Разработка приложений — ранние этапы жизненного цикла разработки для приложений с правами на запись в идентификатор Microsoft Entra, где ошибки могут непреднамеренно записывать изменения в объекты Microsoft Entra, представлять риск. Следуйте платформа удостоверений Майкрософт рекомендациям во время разработки, чтобы устранить эти риски.
Операционная ошибка. Инцидент с безопасностью может произойти не только по вине злоумышленников, но и из-за операционной ошибки, допущенной администраторами клиента или владельцами ресурсов. Эти риски возникают в любой архитектуре. Снизьте эти риски с помощью разделения обязанностей, многоуровневого администрирования, соблюдения принципов наименьших привилегий и выполнению рекомендаций, прежде чем пытаться уменьшить их с помощью отдельного арендатора.
Включение принципов нулевого доверия в стратегию разработки идентификатора Microsoft Entra ID может помочь в разработке, чтобы устранить эти вопросы. Дополнительную информацию см. на странице Безопасность по модели "Никому не доверяй".