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