Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Управление доступом на основе ролей (RBAC) предоставляет платформу для классификации пользователей и ИТ-ресурсов. Эта структура позволяет явно определить их взаимосвязь и права доступа, которые соответствуют данной классификации. Например, путем назначения атрибутам пользователя, указывающим название задания пользователей и назначения проекта, пользователю можно предоставить доступ к средствам, необходимым для задания пользователя и данных, которые пользователь должен внести в конкретный проект. Если у пользователя изменяются рабочее место и задания по проектам, изменение атрибутов, которые указывают на должность и проекты пользователя, автоматически блокирует доступ к ресурсам, которые требовались только для предыдущей должности пользователя.
В Microsoft Entra ID можно использовать модели ролей несколькими способами для управления доступом в масштабе через управление идентификацией.
- Пакеты доступа можно использовать для представления ролей организации в организации, таких как "представитель по продажам". Пакет доступа, представляющий эту должность в организации, будет включать все типичные права доступа, необходимые для представителя по продажам в различных ресурсах.
- Приложения могут определять свои собственные роли. Например, если у вас есть приложение для продаж и это приложение включало в манифест роль приложения "salesperson", можно включить эту роль из манифеста приложения в пакет доступа. Приложения также могут использовать группы безопасности в сценариях, когда пользователь может одновременно иметь несколько ролей для конкретных приложений.
- Роли можно использовать для делегирования административного доступа. Если у вас есть каталог для всех пакетов доступа, необходимых для продаж, вы можете назначить кого-то ответственного за этот каталог, назначив им роль для конкретного каталога.
В этой статье описывается, как моделировать роли организации с помощью пакетов доступа к управлению правами, чтобы можно было перенести определения ролей в идентификатор Microsoft Entra для принудительного доступа.
Перенос модели ролей организации
В следующей таблице показано, как концепции, связанные с определениями ролей в организациях, с которыми вы можете быть знакомы из других продуктов, соответствуют возможностям управления правами.
| Концепция моделирования ролей организации | Представление в управлении правами |
|---|---|
| Делегированное управление ролями | Делегируйте создателям каталога |
| Коллекция разрешений для одного или нескольких приложений | Создание пакета доступа с ролями ресурсов |
| Ограничение длительности доступа, предоставляемого ролью | Задание параметров жизненного цикла политики пакета доступа для даты окончания срока действия |
| Индивидуальное назначение на роль | Создание непосредственного назначения пакета доступа |
| Назначение ролей пользователям на основе свойств (таких как их отдел) | Установка автоматического назначения пакету доступа |
| Пользователи могут запрашивать роль и получать на нее одобрение. | Настройка параметров политики для того, кто может запросить пакет доступа |
| Доступ к повторной сертификации участников роли | Настройка параметров проверки повторяющегося доступа в политике пакета доступа |
| Разделение обязанностей между ролями | Определение двух или более пакетов доступа как несовместимых |
Например, у организации может быть существующая модель ролей организации, аналогичная следующей таблице.
| Имя роли | Разрешения, которые предоставляет роль | Автоматическое назначение роли | Назначение роли на основе запроса | Проверка разделения обязанностей |
|---|---|---|---|---|
| Продавец | Член группы продаж | Да | Нет | нет |
| Диспетчер решений для продаж | Разрешения для роли продавца и менеджера по решениям в приложении Sales. | нет | Продавец может делать запросы, которые требуют утверждения руководителя и ежеквартального рассмотрения. | Запрашивающий не может быть менеджером по продажам |
| Менеджер по продажам | Разрешения роли приложения Salesperson и менеджера аккаунтов в приложении Sales | нет | Продавец может делать запросы, которые требуют утверждения руководителя и ежеквартального рассмотрения. | Запрос не может быть менеджером по продажам |
| Поддержка продаж | Те же разрешения, что и продавец | нет | Любой сотрудник, не связанный с продажами, может подавать запросы, но нуждается в утверждении руководителя и ежеквартальном рассмотрении. | Запрашивающий не может быть продавцом |
Это может быть представлено в Управление идентификацией Microsoft Entra в виде каталога пакетов доступа, содержащего четыре пакета доступа.
| Пакет доступа | Роли ресурсов | Политики | Несовместимые пакеты доступа |
|---|---|---|---|
| Продавец | Член группы продаж | Автоматическое назначение | |
| Диспетчер решений для продаж | Роль менеджера решений в приложении Sales | На основе запросов | Менеджер по продажам |
| Менеджер по продажам | Роль приложения менеджера по работе с клиентами в приложении Sales | На основе запросов | Диспетчер решений для продаж |
| Поддержка продаж | Член группы продаж | На основе запросов | Продавец |
В следующих разделах описывается процесс миграции и создание артефактов идентификации Microsoft Entra и управления идентификацией Microsoft Entra для обеспечения эквивалентного доступа в рамках модели организационной роли.
Подключите приложения, разрешения которых указаны в организационных ролях, к Microsoft Entra ID
Если роли организации используются для назначения разрешений, которые управляют доступом к приложениям, отличным от Microsoft SaaS, локальным приложениям или собственным облачным приложениям, вам потребуется подключить приложения к идентификатору Microsoft Entra.
Чтобы пакет доступа, представляющий организационную роль, мог ссылаться на роли приложения в качестве разрешений, которые включаются в роль, для приложения с несколькими ролями, поддерживающего современные стандарты, такие как SCIM, необходимо интегрировать приложение с Microsoft Entra ID и убедиться, что роли приложения перечислены в манифесте приложения.
Если приложение имеет только одну роль, необходимо по-прежнему интегрировать приложение с идентификатором Microsoft Entra. Для приложений, не поддерживающих SCIM, идентификатор Microsoft Entra может записывать пользователей в существующий каталог приложения или базу данных SQL или добавлять пользователей AD в группу AD.
Заполните схему Microsoft Entra, используемую приложениями и правилами определения области пользовательской аудитории в организационных ролях.
Если определения ролей включают утверждения типа "все пользователи с этими значениями атрибутов автоматически назначаются на роль" или "пользователи с этими значениями атрибутов могут запрашивать", необходимо убедиться, что эти атрибуты присутствуют в идентификаторе Microsoft Entra.
Вы можете расширить схему Microsoft Entra, а затем заполнить эти атрибуты из локальной службы AD, через Microsoft Entra Connect или из системы управления персоналом, например Workday или SuccessFactors.
Создание каталогов для делегирования
Если текущее обслуживание ролей делегировано, вы можете делегировать администрирование пакетов доступа, создав каталог для каждой части организации, в которую вы будете делегироваться.
При наличии нескольких каталогов для создания можно использовать скрипт PowerShell для создания каждого каталога.
Если вы не планируете делегировать администрирование пакетов доступа, можно сохранить пакеты доступа в одном каталоге.
Добавление ресурсов в каталоги
Теперь, когда вы определили каталоги, добавьте приложения, группы или сайты , включенные в пакеты доступа, представляющие роли организации в каталоги.
Если у вас много ресурсов, можно использовать скрипт PowerShell для добавления каждого ресурса в каталог. Дополнительные сведения см. в статье "Создание пакета доступа в управлении правами для приложения с одной ролью с помощью PowerShell".
Создание пакетов доступа, соответствующих определениям ролей организации
Каждое определение роли организации может быть представлено пакетом доступа в этом каталоге.
Скрипт PowerShell можно использовать для создания пакета доступа в каталоге.
После создания пакета доступа необходимо связать одну или несколько ролей ресурсов в каталоге с пакетом доступа. Это представляет разрешения для организационной роли.
Кроме того, вы создадите политику для прямого назначения в составе этого пакета доступа, который можно использовать для отслеживания пользователей, у которых уже есть индивидуальные назначения ролей в организации.
Создать назначения пакетов доступа для существующих назначений индивидуальных ролей в организации
Если у некоторых пользователей уже есть членство в роли организации, которое они не получили бы через автоматическое назначение, то вам следует создать прямые назначения для этих пользователей в соответствующие пакеты доступов.
Если у вас много пользователей, которым нужны назначения, можно использовать скрипт PowerShell для назначения каждому пользователю пакета доступа. Это свяжет пользователей с политикой прямого назначения.
Добавьте политики к этим пакетам доступа для автоматического назначения
Если определение роли организации включает правило на основе атрибутов пользователя для автоматического назначения и удаления доступа на основе этих атрибутов, это можно представить с помощью политики автоматического назначения. Пакет доступа может иметь только одну политику автоматического назначения.
Если у вас много определений ролей, которые имеют определение роли, можно использовать сценарий PowerShell для создания каждой политики автоматического назначения в каждом пакете доступа.
Настройка пакетов доступа как несовместимых для обеспечения разделения обязанностей
Если у вас есть ограничения на разделение обязанностей, которые препятствуют принятию пользователем одной организационной роли, если у них уже есть другой, вы можете запретить пользователю запрашивать доступ в управлении правами, помечая эти сочетания пакетов доступа как несовместимые.
Для каждого пакета доступа, который должен быть помечен как несовместимый с другим, можно использовать скрипт PowerShell для настройки пакетов доступа как несовместимых.
Добавление политик для доступа к пакетам, чтобы пользователи могли запрашивать доступ
Если пользователям, у которых еще нет роли в организации, разрешено запрашивать и быть одобренными для получения роли, то вы также можете настроить управление правами доступа так, чтобы пользователи могли запрашивать пакет доступа. Вы можете добавить дополнительные политики в пакет доступа, а в каждой политике указать, какие пользователи могут запрашивать и кто должен утвердить.
Настройка проверок доступа в политиках назначения пакетов доступа
Если организационные роли требуют регулярного пересмотра их членства, вы можете настроить регулярные проверки доступа в политиках, основанных на запросах, и политиках прямых назначений.