Определение политик организации для управления доступом к приложениям в вашей среде
После определения одного или нескольких приложений, которые вы хотите использовать идентификатор 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 | MFA и зарегистрированное устройство, необходимое для доступа |
| Eastern Sales | Любой сотрудник за пределами продаж | руководитель отдела продаж | 90 дней | Н/П | MFA и зарегистрированное устройство, необходимое для доступа |
| Eastern Sales | Внештатный торговый представитель | руководитель отдела продаж | 30 дней | Н/П | MFA, необходимая для доступа |
Если у вас уже есть определение роли организации, см . дополнительные сведения о переносе роли организации.
Определите, существуют ли необходимые требования или стандарты, которые пользователь должен выполнить для получения доступа к приложению. Например, при нормальных обстоятельствах доступ к приложению некоторого отдела должны иметь только сотрудники, работающие полный рабочий день, сотрудники определенного отдела или центра затрат. Кроме того, может потребоваться политика управления правами, определяющая одно или несколько дополнительных утверждений для пользователя из другого отдела, запрашивающего доступ. Наличие нескольких этапов утверждения может замедлить процесс получения доступа пользователем, но эти дополнительные этапы позволяют гарантировать, что запросы на доступ подаются правильно и контролируются. Например, организация может определить для запросов сотрудника на доступ два этапа утверждения: сначала от непосредственного руководителя этого пользователя, а затем от одного из владельцев ресурса, ответственных за хранящиеся в приложении данные.
Определите, как долго должен сохраняться утвержденный доступ для пользователя и когда он должен отзываться. Во многих приложениях допустимо, чтобы пользователь сохранял доступ неопределенно долго, пока он остается в пределах организации. В других ситуациях доступ можно привязать к определенным проектам или вехам, чтобы он отзывался автоматически при завершении проекта. Если же политика влияет на доступ малого числа пользователей к приложению, вы можете настроить ежеквартальные или ежегодные проверки доступа для всех пользователей, на которых распространяется эта политика, чтобы поддерживать регулярный контроль.
Если ваша организация управляет доступом уже с помощью модели ролей организации, планируйте перенести модель ролей организации в идентификатор Microsoft Entra. У вас может быть определенная организация, которая назначает доступ на основе свойства пользователя, например их должности или отдела. Такие процессы позволяют гарантировать, что доступ пользователей в конечном итоге будет отозван, когда он больше не нужен, даже если заранее не известна дата окончания проекта.
Выясните, существуют ли разделения для ограничений обязанностей. Например, у вас может быть приложение с двумя ролями приложений, Западными продажами и восточными продажами, и вы хотите убедиться, что пользователь может одновременно иметь только одну территорию продаж. Добавьте список всех пар ролей приложений, несовместимых для приложения, чтобы, если у пользователя одна роль, они не могут запрашивать вторую роль.
Выберите соответствующую политику условного доступа для доступа к приложению. Рекомендуется проанализировать приложения и сгруппировать приложения с одинаковыми требованиями к ресурсам для одних и тех же пользователей. Если это первое федеративное приложение единого входа, которое вы интегрируете с Управление идентификацией Microsoft Entra для управления удостоверениями, может потребоваться создать новую политику условного доступа для выражения ограничений, таких как требования для многофакторной проверки подлинности (MFA) или доступа на основе расположения. Вы можете указать, что пользователи должны подтверждать согласие с условиями использования. Дополнительные сведения о том, как определить политику условного доступа, см . в плане развертывания условного доступа.
Определите, как следует обрабатывать исключения из заданных критериев. Например, приложение обычно доступно только назначенным сотрудникам, но аудитору или поставщику иногда нужен временный доступ для конкретного проекта. Или же сотрудник, который работает в разъездах, может иногда обращаться к приложению из обычно заблокированного расположения, в котором нет подразделений вашей организации. В таких ситуациях вы можете создать политику управления правами для утверждения исключений с отдельным набором этапов, лимитом времени или набором утверждающих лиц. Поставщик, вошедший в качестве гостевого пользователя в клиенте Microsoft Entra, может не иметь руководителя, поэтому вместо этого их запросы на доступ могут быть утверждены спонсором для своей организации, или владельцем ресурсов или сотрудником по безопасности.
Поскольку политика организации для тех, кто должен иметь доступ, проверяется заинтересованными лицами, вы можете начать интеграцию приложения с идентификатором Microsoft Entra. Таким образом, на следующем шаге вы готовы развернуть утвержденные организацией политики для доступа в Управление идентификацией Microsoft Entra.