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

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

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

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

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

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

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

  

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

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

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

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

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

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

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

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

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

Лицензии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  

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

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

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

В вашем пилотном проекте мы рекомендуем, чтобы вы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Добавлен в группу.
• Приглашен в команды.
• Приписан к корпоративному приложению или пакету доступа.
• Вам назначена привилегированная роль в Microsoft Entra ID или в подписке 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 ID. При создании для них обзора доступа выберите тех пользователей, которые наиболее компетентны в решении вопросов членства.

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

Сведения о том, как проверить членство в исключенных группах, см. в статье Об использовании проверок доступа 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 ID как приложение в вашем клиенте, с пользователями, назначенными на роли в приложении, и параметр Требуется назначение пользователей? в приложении должен быть установлен на Да. При выборе значения Нет все пользователи в каталоге, включая пользователей с внешними удостоверениями, смогут получать доступ к приложению, и выполнить проверку доступа для приложения будет невозможно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Статьи с инструкциями	Описание
Создание проверок доступа	Создание проверок доступа для привилегированных ролей ресурсов 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 Monitor Log Analytics или Центры событий Azure. Если журналы аудита хранятся в системе "Log Analytics", вы можете использовать мощный язык аналитики и создавать собственные панели мониторинга. Дополнительные сведения см. в статье Архивные журналы и отчеты об управлении правами в Azure Monitor.

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

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

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