Использование многоэтапных проверок для удовлетворения потребностей аттестации и сертификации с помощью Microsoft Entra

Проверки доступа Microsoft Entra поддерживают до трех этапов проверки, в которых несколько типов рецензентов участвуют в определении того, кто по-прежнему нуждается в доступе к ресурсам компании. Эти проверки могут быть для членства в группах или командах, доступа к приложениям, назначения привилегированных ролей или назначения пакетов доступа. При проверке администраторы настраивают проверку для автоматического применения решений, в конце периода проверки доступ отменяется для запрещенных пользователей.

Варианты использования многоэтапных проверок

Многоэтапные проверки доступа позволяют вам и вашей организации разрешать сложные рабочие процессы в соответствии с требованиями повторной сертификации и аудита, которые призывают нескольких рецензентов проверить доступ пользователей в определенной последовательности. Кроме того, это помогает создавать более эффективные проверки для владельцев ресурсов и аудиторов, уменьшая количество решений, за которые несет ответственность каждый рецензент. Этот подход позволяет объединять в противном случае несвязанные отдельные проверки для одного ресурса в одном обзоре доступа.

Ниже приведены некоторые сценарии, которые можно рассмотреть.

• Достичь консенсуса в нескольких наборах рецензентов: пусть две аудитории рецензентов независимо просматривают доступ к ресурсу. Вы можете настроить проверки таким образом, чтобы оба этапа рецензирования достигли согласия о утверждении без видения решений друг друга.
• Назначьте альтернативных рецензентов, чтобы высказать своё мнение о непроверенных решениях: позвольте владельцу ресурса сначала подтвердить доступ к своему ресурсу. Затем пользователи, для которых не записано решение, переходят ко второму этапу рецензирования, например, к менеджеру пользователя или команде аудиторов, которые проверяют неопределённые запросы.
• Уменьшить нагрузку на рецензентов более поздних этапов: проверки можно настроить таким образом, чтобы пользователи, отклоненные на более ранних стадиях, не проверялись на более поздних этапах, что позволяет рецензентам более поздних этапов просмотреть отфильтрованный список. Используйте этот сценарий для последовательной фильтрации пользователей на каждом этапе.

Достижение консенсуса в нескольких наборах рецензентов

Достижение кворума по обеспечению правильного доступа для пользователей может оказаться трудным. Для ресурсов, к которым у многих пользователей есть доступ, или для разнообразной группы пользователей, которые необходимо проверить, особенно трудно сделать правильный выбор для всех проверяющих. Достижение консенсуса путем предоставления до трех различных групп рецензентов возможности записывать решения и, показывая, что более ранние аудитории рецензента сказали, помогает добиться консенсуса относительно того, кто должен иметь доступ к ресурсу.

Примером будет проверка, состоящая из трех этапов, определяющих членство в группе, которая управляет доступом к ресурсу. В настройках обзора администратор выбирает не показывать решения предыдущих этапов рецензирования. Эта конфигурация позволяет каждой аудитории проверки, например менеджеру пользователя, владельцу группы и сотруднику по безопасности самостоятельно просматривать доступ. Три этапа выстраиваются с увеличением важности веса аудитории рецензента, причем решения последней аудитории рецензентов потенциально могут перезаписать решения рецензентов предыдущих этапов.

Конфигурация для этого сценария будет выглядеть следующим образом:

Назначьте других рецензентов для оценки непроверенных решений.

Для сценариев, где требуется записывать решения и убедиться в сохранении доступа для нужных людей, многоэтапные проверки позволяют перемещать подмножество проверяющихся на следующий этап, что может потребовать второй аудитории рецензентов для двойной проверки или принятия решений. Используйте этот шаблон, чтобы гарантировать, что количество непроверенных пользователей или пользователей, отмеченных как не знаю, уменьшилось, переводя их на следующий этап, и чтобы другая группа рецензентов принимала решения.

Примером будет проверка, содержащая два этапа, определяющих доступ к приложению. В настройках обзора администратор обзора выбирает показывать решения предыдущих этапов рецензентам следующих этапов. Для оцениваемых, которые переходят на следующий этап, будут добавлены решения, требующие подтверждения: чтобы убедиться, что все оцениваемые имеют решение, выберите оцениваемых, помеченных как "Не знаю" и не оценены оцениваемые, чтобы позже рецензенты видели только неопределенных или неуверенных оцениваемых и могли сохранить правильный доступ.

Уменьшение нагрузки на рецензентов более поздних этапов

Для проверок, которые могут включать множество пользователей, подлежащих проверке и подтверждению, стоит потребовать от всех пользователей самостоятельно подтвердить данные перед тем, как их проверят владелец ресурса или их менеджер на более позднем этапе. Эта модель позволяет отфильтровывать оцениваемых на каждом этапе, переходят на следующий этап только самоутвердившиеся.

Позднее рецензенты более поздних этапов, такие как менеджеры пользователей или владелец ресурса, видят только сокращенный список проверяемых — те, которые были утверждены ранее. Количество проверяемых на каждом этапе уменьшается от этапа к этапу. Только те пользователи, которые были утверждены на всех трех этапах, сохраняют доступ.

Примером может быть проверка группы, которая предоставляет ИТ-исключение, которое администратор хочет регулярно просматривать. Так как это исключение популярно, пользователей просят сначала дать ответ, и только те, кто ответил, что им все еще нужно исключение, переходят ко второму этапу, где их менеджер принимает решение. Только если пользователь и менеджер одобрят, ИТ-администраторам для исключения будет предоставлен доступ к списку пользователей, которые по-прежнему нуждаются и хотят исключения, чтобы просмотреть сокращенный список участников проверки.

Отзывы гостевых пользователей

Отзывы гостевых пользователей помогают организациям, используюющим Microsoft Entra B2B для совместной работы. Доступ этих гостевых пользователей следует регулярно пересматривать, чтобы убедиться, что у них по-прежнему правильный доступ и что совместная работа с ними все еще желательна. Это позволяет при необходимости отозвать доступ или удалить учетные записи гостевых пользователей, которые больше не нужны.

Этот сценарий можно настроить с помощью многоэтапных проверок, аналогичных тому, как работает сценарий "Сокращение нагрузки на последующих рецензентах". Во-первых, попросите гостевых пользователей самостоятельно проверить и подтвердить свой постоянный интерес и потребность в совместной работе, включая требование предоставить бизнес-обоснование. Только гости, которые сами инициируют свой процесс проверки, переходят на более поздний этап, где спонсор или другой сотрудник утверждает или отклоняет дальнейший доступ или возможность сотрудничества.

Для отзывов пользователей-гостей также рассмотрите возможность использования параметра только неактивные пользователи (на уровне клиента). Это приведет к проверке неактивных внешних пользователей, которые не вошли в клиент ресурсов в число указанных дней.

В сценариях для гостевых пользователей функция "Проверка доступа" поддерживает дополнительную опцию конфигурации: действие, применяемое к отклоненным гостевым пользователям, что может привести к следующим результатам:

• Удаление членства пользователя из ресурса
• Заблокировать вход пользователя в течение 30 дней, а затем удалить пользователя из клиента

В зависимости от ваших потребностей в проверке, гостевые пользователи, которые не отвечают на запрос проверки или отклоняют дальнейшее сотрудничество, могут быть автоматически удалены из вашей учетной записи. Это приводит к блокировке учетной записи гостевого пользователя B2B в течение 30 дней после удаления учетной записи.

Длительность этапов проверки

Администраторы определяют длительность каждого этапа проверки и, следовательно, сколько времени рецензенты должны записывать свои решения. Каждый этап можно настроить на собственную длительность, чтобы учитывать доступность и ожидания рецензентов.

Каждый этап проверки остается доступен рецензентам для добавления решений на весь период. Администраторы проверки могут остановить запущенный этап и автоматически перейти ко следующему этапу общей проверки на странице обзора рецензента, выбрав "Остановить текущий этап".

Применение результатов

Проверки доступа Microsoft Entra могут принимать решения о доступе к ресурсу, удаляя больше не нужных пользователей из ресурса. Решения всегда применяются в конце периода проверки или когда администратор проверки вручную завершает проверку. Автоматическое применение результатов определяется администратором проверки с автоматическим применением результатов к параметру ресурса или вручную с помощью кнопки "Применить результаты" на странице обзора проверки.

Рецензенты собирают решения для каждого этапа. Настройки проверяемых, переходящих на следующий этап определяют, каких проверяемых поздние этапы рецензенты увидят и попросят записать решения для них. Только в конце общего обзора решения применяются к ресурсу.

Для всех решений последнее решение, записанное для проверяемого, применяется в конце проверки. Решения, принятые для Джейн на первом этапе обзора, могут быть изменены на втором и третьем этапах рецензентами более поздних этапов.

Если настройка "Те, кого проверяют, переходят на следующий этап" установлена таким образом, что только часть проверяемых переходит на последующие этапы, может случиться, что решения, принятые на первом этапе, применяются в конце проверки. Если администратор проверки настроил трехэтапный процесс и хочет, чтобы только отклоненные и не проверенные переходили на следующие этапы, если Джейн была утверждена на первом этапе, она не перейдет на последующие этапы, и её решение об утверждении записывается и в конце проверки применяется.

Следующие шаги

• Что такое проверки доступа Microsoft Entra
• Создание проверки доступа для групп и приложений в Microsoft Entra ID