Планирование развертывания проверок доступа Microsoft Entra

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

• Запланируйте регулярные проверки или нерегламентированные проверки, чтобы узнать, кто имеет доступ к определенным ресурсам, таким как приложения и группы.

• Отслеживать данные проверок для получения аналитических сведений, из соображений соответствия нормативным требованиям или политикам.

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

• Использовать аналитику, чтобы эффективно определять, нужно ли продлить предоставление доступа тому или иному пользователю.

• Автоматически рассматривать последствия, например отзыв доступа пользователя к ресурсам.

  

Проверки доступа — это возможность Управление идентификацией Microsoft Entra. Другие возможности — управление правами, управление привилегированными пользователями (PIM), рабочие процессы жизненного цикла, подготовка и условия использования. Вместе они помогают ответить на следующие четыре вопроса:

• Какие пользователи и к каким ресурсам должны иметь доступ?
• Как эти пользователи применяют этот доступ?
• Имеются ли эффективные средства управления доступом на уровне организации?
• Могут ли аудиторы убедиться, что эти средства работают правильно?

Планирование развертывания проверок доступа обязательно для осуществления выбранной вами стратегии управления пользователями в организации.

Ключевые преимущества

Основные преимущества включения проверок доступа перечислены ниже.

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

Обучающие материалы

Следующие видеоматериалы помогут вам узнать больше о проверках доступа:

• Что такое проверки доступа в идентификаторе Microsoft Entra?
• Создание проверок доступа в идентификаторе Microsoft Entra
• Создание автоматических проверок доступа для всех гостевых пользователей с доступом к группам Microsoft 365 в идентификаторе Microsoft Entra
• Включение проверок доступа в идентификаторе Microsoft Entra
• Проверка доступа с помощью портала "Мой доступ"

Лицензии

Эта функция требует Управление идентификацией Microsoft Entra или подписок Microsoft Entra Suite для пользователей вашей организации. Некоторые возможности в рамках этой функции могут работать с подпиской Microsoft Entra ID P2. Дополнительные сведения см. в статьях о каждой возможности. Чтобы найти подходящую лицензию для ваших требований, см. Управление идентификацией Microsoft Entra основы лицензирования.

Планирование проекта развертывания проверок доступа

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

Привлечение соответствующих заинтересованных лиц

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

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

• ИТ-администраторы управляют ИТ-инфраструктурой и администрируют инвестиции в облако и приложения SaaS (программное обеспечение как услуга). Эта команда:

  • Проверяет привилегированный доступ к инфраструктуре и приложениям, включая Идентификатор Microsoft 365 и Microsoft Entra.
  • планирует и запускает проверки доступа для групп, используемых для обеспечения работы списка исключений и пилотных ИТ-проектов, чтобы поддерживать актуальность списков доступа;
  • гарантирует управление программным (основанным на скриптах) доступом к ресурсам через субъекты-службы и проверку такого доступа.
  • Автоматизация процессов, таких как подключение пользователей и отключение, запросы доступа и сертификации доступа.

• Группы безопасности гарантируют, что план соответствует требованиям безопасности вашей организации и применяет нулевое доверие. Эта команда:

  • Снижение риска и укрепление безопасности
  • Обеспечивает минимальный привилегированный доступ к ресурсам и приложениям
  • Использует средства для просмотра централизованного авторитетного источника, того, кто имеет доступ к чему, и как долго.

• Группы разработки создают и обслуживают приложения для вашей организации. Эта команда:

  • определяет, кто может получать доступ к компонентам в ресурсах SaaS, PaaS и IaaS, входящим в состав разработанных решений, и управлять ими;
  • управляет группами, которым разрешен доступ к приложениям и средствам для разработки внутренних приложений;
  • требует привилегированных удостоверений, которые имеют доступ к рабочим экземплярам программного обеспечения или решениям, размещаемым для ваших клиентов.

• Бизнес-подразделения управляют проектами и собственными приложениями. Эта команда:

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

• Корпоративное управление гарантирует, что организация будет соблюдать внутреннюю политику и нормативные требования. Эта команда:

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

Планирование информирования

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

Информирование об изменениях в системе отчетности

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

ИТ-отдел хочет контролировать все решения доступа, связанные с инфраструктурой, и назначения привилегированных ролей.

Настройка информирования по электронной почте

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

Сообщение электронной почты, отправляемое проверяющим, можно настроить так, чтобы оно включало короткое сообщение, которое порекомендует им принимать меры по результатам проверки. Этот дополнительный текст позволяет:

• Включить личное сообщение проверяющим, чтобы они понимали, что оно отправлено вашим отделом соответствия или ИТ.

• Добавить ссылку на внутреннюю информацию о том, что ожидается от проверки, а также дополнительные справочные или учебные материалы.

  

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

Планирование пилотного проекта

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

В пилотном проекте рекомендуется:

• Начните с проверок, в которых результаты не применяются автоматически, и вы сможете управлять их последствиями.
• Убедитесь, что у всех пользователей есть допустимые адреса электронной почты, указанные в идентификаторе Microsoft Entra. Убедитесь, что они получают сообщения электронной почты, чтобы предпринять соответствующие действия.
• Задокументируйте любой доступ, удаленный в рамках пилотного проекта, на тот случай, если необходимо быстро восстановить его.
• Отслеживайте журналы аудита, чтобы убедиться, что все события должным образом проверены.

Дополнительные сведения см. в рекомендациях по пилотным проектам.

Общие сведения о проверках доступа

В этом разделе представлены основные понятия проверок доступа, с которыми необходимо ознакомиться, прежде чем планировать проверки.

Какие типы ресурсов можно просмотреть?

После интеграции ресурсов организации с идентификатором Microsoft Entra, например пользователями, приложениями и группами, их можно управлять и проверять.

Ниже приведены типичные целевые объекты для проверки:

• Приложения, интегрированные с идентификатором Microsoft Entra для единого входа, например SaaS и бизнес-процессов.
• Членство в группе синхронизировано с идентификатором Microsoft Entra или создано в идентификаторе Microsoft Entra или Microsoft 365, включая Microsoft Teams.
• пакет для доступа, в котором ресурсы (группы, приложения и сайты) собраны в один пакет для управления доступом;
• Роли Microsoft Entra и роли ресурсов Azure, как определено в PIM.

Кто будет создавать проверки доступа и управлять ими?

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

Тип ресурса	Создание проверок доступа и управление ими (создатели)	Чтение результатов проверки доступа
Группа или приложение	Глобальный администратор Администратор пользователей Администратор управления удостоверениями Администратор привилегированных ролей (выполняет проверки только для групп, назначаемых ролями Майкрософт) Владелец группы (если включено администратором)	Глобальный администратор Глобальный читатель Администратор пользователей Администратор управления удостоверениями Администратор привилегированных ролей Читатель сведений о безопасности Владелец группы (если включено администратором)
Роли Microsoft Entra	Глобальный администратор Администратор привилегированных ролей	Глобальный администратор Глобальный читатель Администратор пользователей Администратор привилегированных ролей Читатель сведений о безопасности
Роли ресурсов Azure	Администратор доступа пользователей (для ресурса) Владелец ресурса Пользовательские роли с разрешением Microsoft.Authorization/* .	Администратор доступа пользователей (для ресурса) Владелец ресурса Читатель (для ресурса) Пользовательские роли с разрешениями Microsoft.Authorization/*/read.
Пакет доступа	Глобальный администратор Администратор управления удостоверениями Владелец каталога (для пакета для доступа) Доступ к диспетчеру пакетов (для пакета для доступа)	Глобальный администратор Глобальный читатель Администратор пользователей Администратор управления удостоверениями Владелец каталога (для пакета для доступа) Доступ к диспетчеру пакетов (для пакета для доступа) Читатель сведений о безопасности

Дополнительные сведения см. в разделе "Разрешения роли администратора" в идентификаторе Microsoft Entra.

Кто будет проверять доступ к ресурсу?

Создатель проверки доступа во время создания принимает решение, кто будет выполнять проверку. После запуска проверки этот параметр нельзя изменить. Проверяющими могут быть:

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

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

Компоненты проверки доступа

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

Чтобы создать политику проверки доступа, необходимо знать следующее:

• Какие ресурсы следует проверить?

• Чей доступ проверяется?

• Как часто должна проводиться проверка?

• Кто будет выполнять проверку?

  • Как они будут уведомлены о проверке?
  • Какие сроки должны быть соблюдены для проверки?

• Какие автоматические действия следует применять в зависимости от проверки?

  • Что произойдет, если проверяющий не ответит вовремя?

• Какие действия вручную выполняются в результате проверки?

• Какие сообщения должны отправляться в зависимости от выполненных действий?

Пример плана проверки доступа

Компонент	Значение
Ресурсы для проверки	Доступ к Microsoft Dynamics.
Частота проверки	Ежемесячно.
Кто выполняет проверку	Руководители программ в бизнес-группах Dynamics.
Notification	В начале проверки на псевдоним Dynamics-Pms отправляется электронное письмо. Включите в него воодушевляющее сообщение для проверяющих, чтобы заручиться их поддержкой.
Временная шкала	48 часов с момента уведомления.
Автоматические действия	Удаление доступа из любой учетной записи, не имевшей интерактивного входа в течение 90 дней, путем удаления пользователя из группы безопасности dynamics-access. Выполните действия, если проверка не выполнена в срок.
Действия, выполняемые вручную	Проверяющие могут выполнить утверждение удаления перед автоматическим действием, если это необходимо.

Автоматизация действий на основе проверок доступа

Можно выбрать автоматическое удаление доступа, установив для параметра Автоматически применять результаты к ресурсу значение Включить.

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

Принять рекомендации

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

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

Проверка доступа гостевых пользователей

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

Внешним удостоверениям может предоставляться доступ к ресурсам компании. Они могут быть следующими:

• Добавлен в группу.
• Приглашен в команды.
• Приписан к корпоративному приложению или пакету доступа.
• Назначена привилегированная роль в идентификаторе Microsoft Entra или в подписке Azure.

Дополнительные сведения см. в примере скрипта. Пример скрипта показывает, где используются внешние удостоверения, приглашенные в клиент. В идентификаторе Microsoft Entra ID можно увидеть членство во внешней группе пользователя, назначения ролей и назначения приложений. Скрипт не будет отображать никаких назначений за пределами идентификатора Microsoft Entra, например, прямого назначения прав ресурсам SharePoint без использования групп.

При создании проверки доступа для групп или приложений можно разрешить рецензенту сосредоточиться только на всех пользователей или гостевых пользователей. Выбрав только гостевых пользователей, рецензенты получают ориентированный список внешних удостоверений из microsoft Entra business to business (B2B), имеющих доступ к ресурсу.

Планирование проверок доступа для пакетов доступа

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

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

Откройте вкладку Жизненный цикл и прокрутите ее вниз к разделу "Проверки доступа".

Планирование проверок доступа для групп

Кроме пакетов доступа, самым эффективным способом управления доступом является проверка членства в группах. Назначьте доступ к ресурсам с помощью групп безопасности или групп Microsoft 365. Добавьте пользователей в эти группы для получения доступа.

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

Членство в группе можно просмотреть, выполнив следующие действия:

• Администраторы.
• Владельцы группы.
• Выбранные пользователи, которым при создании проверки делегирована возможность проверки.
• Участники группы, которые самостоятельно выполняют подтверждение.
• Руководители, которые проверяют доступ своих непосредственных подчиненных.

Владение группой

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

• Группы, созданные в Microsoft 365 и Идентификаторе Microsoft Entra, имеют одного или нескольких четко определенных владельцев. В большинстве случаев эти владельцы представляют собой идеальных рецензентов для своих собственных групп, так как они знают, кто должен иметь доступ.

  Например, Microsoft Teams использует группы Microsoft 365 в качестве базовой модели авторизации, чтобы предоставить пользователям доступ к ресурсам SharePoint, Exchange, OneNote или другим службам Microsoft 365. Создатель группы автоматически станет ее владельцем и должен отвечать за подтверждение членства в этой группе.

• Группы, созданные вручную в Центре администрирования Microsoft Entra или с помощью сценариев с помощью Microsoft Graph, могут не обязательно определять владельцев. Определите их с помощью Центра администрирования Microsoft Entra в разделе "Владельцы" группы или через Microsoft Graph.

• Группы, синхронизированные из локальная служба Active Directory, не могут иметь владельца в идентификаторе Microsoft Entra. При создании проверки доступа для них следует выбрать пользователей, которые лучше всего подходят для принятия решения о членстве в них.

Проверка членства в группах исключений в политиках условного доступа

Сведения о том, как проверить членство в исключенных группах, см. в статье Об использовании проверок доступа Microsoft Entra для управления пользователями, исключенными из политик условного доступа.

Проверка членства в группах гостевых пользователей

Сведения о том, как просмотреть доступ гостевых пользователей к членству в группах, см. в статье "Управление гостевым доступом с помощью проверок доступа Microsoft Entra".

Проверка доступа к локальным группам

Проверки доступа не могут изменить членство в группах, которые синхронизируются из локальной службы AD с Microsoft Entra Connect. Это ограничение связано с тем, что источник центра для группы, созданной в AD, является локальной службой AD. Чтобы управлять доступом к приложениям на основе групп AD, используйте обратную запись группы Microsoft Entra Cloud Sync.

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

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

• Скачайте отчет в формате CSV из проверки доступа, затем, руководствуясь этим отчетом, примите соответствующие меры вручную.
• Использование Microsoft Graph для программного получения результатов решений завершенных проверок доступа.

Например, чтобы получить результаты для управляемой windows Server AD группы, используйте этот пример скрипта PowerShell. Сценарий описывает необходимые вызовы Microsoft Graph и экспортирует команды Windows Server AD PowerShell для выполнения изменений.

Планирование проверок доступа для приложений

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

Планируйте проверки для приложений в следующих сценариях.

• Пользователям предоставлен прямой доступ к приложению (вне группы или пакета доступа).
• Приложение предоставляет важную или конфиденциальную информацию.
• Приложение имеет определенные требования к соответствию, на которые необходимо пройти аттестацию.
• Вы подозреваете недопустимый доступ.

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

Затем назначьте пользователей и группы, доступ которых вы хотите проверить.

См. дополнительные сведения о том, как подготовиться к проверке доступа пользователей к приложению.

Рецензенты для приложения

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

Планирование проверки идентификатора Microsoft Entra и ролей ресурсов Azure

управление привилегированными пользователями упрощает управление привилегированным доступом к ресурсам в идентификаторе Microsoft Entra. Использование PIM сохраняет список привилегированных ролей в идентификаторе Microsoft Entra ID и ресурсах Azure меньше. Кроме того, это также повышает общую безопасность каталога.

Проверки доступа позволяют рецензентам указывать, должны ли пользователи по-прежнему относиться к определенной роли. Как и проверки доступа для пакетов доступа, проверки для ролей Microsoft Entra и ресурсов Azure интегрированы в интерфейс пользователя администратора PIM.

Регулярно проверяйте следующие назначения ролей:

• Глобальный администратор
• Администратор пользователей
• Привилегированный администратор проверки подлинности
• Администратор условного доступа
• Администратор безопасности
• все роли администраторов Microsoft 365 и службы Dynamics.

Проверяемые роли содержат постоянные и доступные назначения.

В разделе Рецензенты выберите одного или нескольких пользователей для проверки всех пользователей. Вы также можете выбрать диспетчер, чтобы просмотреть доступ к пользователям, которым они управляют, или "Участники" (самостоятельно), чтобы участники могли просматривать собственный доступ.

Развертывание проверок доступа

Подготовив стратегию и план для проверки доступа к ресурсам, интегрированным с идентификатором Microsoft Entra ID, разверните проверки и управляйте ими с помощью следующих ресурсов.

Проверка пакетов доступа

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

Статьи с инструкциями	Description
Создание проверок доступа	Включение проверок в пакете для доступа.
Выполнение проверок доступа	Выполнение проверок доступа для других пользователей, назначенных в пакет для доступа.
Самостоятельная проверка назначенных пакетов для доступа	Самостоятельная проверка пользователем назначенных ему пакетов для доступа.

Проверка групп и приложений

Потребности сотрудников и гостевых пользователей в доступе к группам и приложениям часто меняются со временем. Чтобы уменьшить риск, связанный с устаревшими назначениями доступа, администраторы могут создать в Azure Active Directory (AAD) проверки доступа для участников групп или доступа к приложениям. Следуйте инструкциям в статьях, перечисленных в таблице.

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

Просмотр ролей Microsoft Entra

Чтобы снизить риск, связанный с устаревшими назначениями ролей, регулярно просматривайте доступ к привилегированным ролям Microsoft Entra.

Следуйте инструкциям в статьях, перечисленных в таблице.

Статьи с инструкциями	Description
Создание проверок доступа	Создайте проверки доступа для привилегированных ролей Microsoft Entra в PIM.
Самостоятельная проверка собственного доступа	Если вам назначена роль администратора, вы можете утвердить или отклонить свой доступ к этой роли.
Выполнение проверки доступа	Просмотр проверки доступа и применение ее результатов.

Проверка ролей ресурсов Azure

Чтобы снизить риск, связанный с устаревшими назначениями ролей, регулярно проверяйте доступ для привилегированных ролей ресурсов Azure.

Следуйте инструкциям в статьях, перечисленных в таблице.

Статьи с инструкциями	Description
Создание проверок доступа	Создание проверок доступа для привилегированных ролей ресурсов Azure в PIM.
Самостоятельная проверка собственного доступа	Если вам назначена роль администратора, вы можете утвердить или отклонить свой доступ к этой роли.
Выполнение проверки доступа	Просмотр проверки доступа и применение ее результатов.

Использование API проверок доступа

См. статьи Методы API Microsoft Graph и Проверки авторизации разрешений для ролей и приложений, в которых описано взаимодействие с ресурсами, подлежащими проверке, и управление ими. Методы проверки доступа в API Microsoft Graph доступны для контекстов приложения и пользователя. При выполнении скриптов в контексте приложения учетной записи, используемой для запуска API (субъект-служба), должно быть предоставлено разрешение AccessReview.Read.All, чтобы она могла запрашивать данные проверок доступа.

Задачи проверки доступа, которые часто автоматизируются с помощью API Microsoft Graph для проверок доступа, перечислены ниже.

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

При создании новых запросов API Microsoft Graph для автоматизации используйте Graph Explorer, чтобы создавать и изучать запросы Microsoft Graph, прежде чем добавлять их в скрипты и код. Таким образом вы сможете быстро выполнять итерации запроса, получая в точности нужные вам результаты, без необходимости изменять код скрипта.

Мониторинг проверок доступа

Действия проверки доступа записываются и доступны из журналов аудита Microsoft Entra. Данные аудита можно отфильтровать по категории, типу действия и диапазону дат. Вот пример запроса:

Категория	Политика
Тип активности	Создание проверки доступа
	Обновление проверки доступа
	Окончание проверки доступа
	Удаление проверки доступа
	Утвердить решение
	Запретить решение
	Сбросить решение
	Применить решение
Диапазон дат	Семь дней

Для более сложных запросов и анализа проверок доступа и отслеживания изменений и завершения проверок экспортируйте журналы аудита Microsoft Entra в Azure Log Analytics или Центры событий Azure. Если журналы хранятся в службе анализа журналов, вы можете использовать мощный язык аналитики и создать собственные панели мониторинга.

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

Ознакомьтесь со следующими связанными технологиями:

• Что такое управление правами Майкрософт?
• Что такое Microsoft управление привилегированными пользователями?