Определение политик организации для управления доступом к приложениям в вашей среде
После определения одного или нескольких приложений, которые вы хотите использовать идентификатор Microsoft Entra для управления доступом, запишите политики организации для определения доступа пользователей и других ограничений, которые должна предоставлять система.
Выбор приложений и их ролей в области
Организации с требованиями соответствия требованиям или планами управления рисками имеют конфиденциальные или критически важные для бизнеса приложения. Если это приложение уже существует в вашей среде, возможно, у вас уже есть документированные политики доступа, определяющие круг лиц с доступом к этому приложению. В противном случае вам придется пообщаться со всеми заинтересованным лицам, включая группы по обеспечению соответствия требованиям и управлению рисками, чтобы убедиться в пригодности используемых политик автоматизации решений о доступе к сценарию вашей организации.
Соберите все роли и разрешения, которые предоставляет каждое приложение. Некоторые приложения могут иметь только одну роль, например роль "Пользователь". Более сложные приложения могут управлять несколькими ролями с помощью идентификатора Microsoft Entra. Обычно эти роли приложения налагают широкие ограничения на доступ пользователей с этой ролью к приложению. Например, приложение с выделенными административными возможностями может иметь две роли: "Пользователь" и "Администратор". Другие приложения также могут полагаться на членство в группах или утверждения для более детальных проверок ролей, которые могут быть предоставлены приложению от Microsoft Entra ID в рамках настройки или на основании утверждений, выданных с использованием протоколов федеративного единого входа, или быть записаны в AD как членство в группе безопасности. Наконец, могут быть роли, относящиеся к приложениям, которые не отображаются в идентификаторе Microsoft Entra. Возможно, приложение не разрешает определять администраторов в идентификаторе Microsoft Entra ID, вместо этого опираясь на собственные правила авторизации для идентификации администраторов. Облачные службы управления идентификацией SAP имеют только одну роль, пользователь, доступна для назначения.
Примечание.
Если вы используете приложение из коллекции приложений Microsoft Entra, поддерживающей подготовку, идентификатор Microsoft Entra может импортировать определенные роли в приложении и автоматически обновлять манифест приложения с ролями приложения автоматически, после настройки подготовки.
Выберите, членство в каких ролях и группах должно управляться в идентификаторе Microsoft Entra. В зависимости от требований к соответствию и управлению рисками организации часто ставят приоритеты этих ролей или групп приложений, которые предоставляют привилегированный доступ или доступ к конфиденциальной информации.
Определение политики организации с предварительными условиями и другими ограничениями для доступа к приложению
В этом разделе вы зафиксируете политики организации, которые вы намерены использовать для определения доступа к приложению. Эти данные можно хранить, например, в формате электронной таблицы
| Роль приложения | Предварительные требования для доступа | Утверждающие | Длительность доступа по умолчанию | Ограничения по разделению обязанностей | Политики условного доступа |
|---|---|---|---|---|---|
| Western Sales | Сотрудник отдела продаж | Руководитель пользователя | Ежегодная проверка | Не может иметь доступа к Eastern Sales | Многофакторная проверка подлинности (MFA) и зарегистрированное устройство, необходимое для доступа |
| Western Sales | Любой сотрудник за пределами продаж | руководитель отдела продаж | 90 дней | Н/П | Для доступа требуются MFA и зарегистрированное устройство |
| Western Sales | Внештатный торговый представитель | руководитель отдела продаж | 30 дней | Н/П | Для доступа требуется MFA |
| Eastern Sales | Сотрудник отдела продаж | Руководитель пользователя | Ежегодная проверка | Не может иметь доступа к Western Sales | Для доступа требуется многофакторная аутентификация и зарегистрированное устройство |
| Eastern Sales | Любой сотрудник за пределами продаж | руководитель отдела продаж | 90 дней | Н/П | Для доступа требуется многофакторная аутентификация и зарегистрированное устройство |
| Eastern Sales | Внештатный торговый представитель | руководитель отдела продаж | 30 дней | Н/П | Доступ возможен только при наличии MFA |
Если у вас уже есть определение роли организации, см как перенести роль организации для получения дополнительной информации.
Определите, существуют ли необходимые требования или стандарты, которые пользователь должен выполнить для получения доступа к приложению. Например, при нормальных обстоятельствах доступ к приложению некоторого отдела должны иметь только сотрудники, работающие полный рабочий день, сотрудники определенного отдела или центра затрат. Кроме того, может потребоваться политика управления правами, определяющая одно или несколько дополнительных утверждений для пользователя из другого отдела, запрашивающего доступ. Наличие нескольких этапов утверждения может замедлить процесс получения доступа пользователем, но эти дополнительные этапы позволяют гарантировать, что запросы на доступ подаются правильно и контролируются. Например, организация может определить для запросов сотрудника на доступ два этапа утверждения: сначала от непосредственного руководителя этого пользователя, а затем от одного из владельцев ресурса, ответственных за хранящиеся в приложении данные.
Определите, как долго должен сохраняться утвержденный доступ для пользователя и когда он должен отзываться. Во многих приложениях пользователь может сохранять доступ на неопределенный срок, пока они не перестанут быть связаны с организацией. В других ситуациях доступ можно привязать к определенным проектам или вехам, чтобы он отзывался автоматически при завершении проекта. Если же политика влияет на доступ небольшого числа пользователей к приложению, вы можете настроить ежеквартальные или ежегодные проверки доступа пользователей в рамках данной политики, чтобы поддерживать регулярный контроль.
Если ваша организация управляет доступом уже с помощью модели ролей организации, планируйте перенести модель ролей организации в идентификатор Microsoft Entra. У вас может быть определенная организационная роль, которая назначает доступ на основе свойства пользователя, например, их должности или отдела. Такие процессы позволяют гарантировать, что доступ пользователей в конечном итоге будет отозван, когда он больше не нужен, даже если заранее не известна дата окончания проекта.
Выясните, существуют ли ограничения на разделение обязанностей. Например, у вас может быть приложение с двумя ролями приложений, Западными продажами и восточными продажами, и вы хотите убедиться, что пользователь может одновременно иметь только одну территорию продаж. Добавьте список всех пар ролей приложений, несовместимых для приложения, чтобы, если у пользователя одна роль, они не могут запрашивать вторую роль.
Выберите соответствующую политику условного доступа для доступа к приложению. Рекомендуется проанализировать приложения и сгруппировать приложения с одинаковыми требованиями к ресурсам для одних и тех же пользователей. Если это ваше первое федеративное приложение единого входа, которое вы интегрируете с Microsoft Entra ID Governance для управления удостоверениями, вам может потребоваться создать новую политику условного доступа для установки ограничений, таких как требования к многофакторной аутентификации (MFA) или доступа на основе геолокации. Вы можете указать, что пользователи должны подтверждать согласие с условиями использования. Дополнительные сведения о том, как определить политику условного доступа, см. в разделе "Планирование развертывания условного доступа".
Определите, как следует обрабатывать исключения из заданных критериев. Например, приложение обычно доступно только назначенным сотрудникам, но аудитору или поставщику иногда нужен временный доступ для конкретного проекта. Или сотрудник, который находится в разъездах, может потребовать доступ из расположения, которое обычно заблокировано, так как ваша организация не присутствует в этом месте. В таких ситуациях вы можете выбрать создание политики управления правами для утверждения, которая может иметь разные этапы, или другой лимит времени, или другого утверждающего. Поставщик, вошедший в качестве гостевого пользователя в клиенте Microsoft Entra, может не иметь руководителя, поэтому вместо этого их запросы на доступ могут быть утверждены спонсором для своей организации, или владельцем ресурсов или сотрудником по безопасности.
Поскольку политика организации для тех, кто должен иметь доступ, проверяется заинтересованными лицами, вы можете начать интеграцию приложения с идентификатором Microsoft Entra. Таким образом, на следующем шаге вы готовы развернуть утвержденные организацией политики для доступа в Управление идентификацией Microsoft Entra.