Подготовка к проверке доступа пользователей к приложению

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

Организации с требованиями соответствия требованиям или планами управления рисками имеют конфиденциальные или критически важные для бизнеса приложения. Конфиденциальность приложения может зависеть от его цели или содержащихся в нем данных, таких как финансовая информация или личная информация клиентов организации. Для этих приложений только подмножество всех пользователей в организации разрешено иметь доступ, и доступ должен быть разрешен только на основе документированных бизнес-требований. Идентификатор Microsoft Entra можно интегрировать со многими популярными приложениями SaaS, локальными приложениями и приложениями, которые разрабатывает ваша организация, используя стандартные интерфейсы протокола и API. С помощью этих интерфейсов идентификатор Microsoft Entra может быть авторитетным источником для управления доступом к этим приложениям. После интеграции приложений с идентификатором Microsoft Entra можно использовать проверки доступа для повторной сертификации пользователей, имеющих доступ к этим приложениям, и удалить доступ к тем пользователям, которым больше не нужен доступ. Вы также можете использовать другие функции, включая условия использования, условный доступ и управление правами, для управления доступом к приложениям, как описано в том, как управлять доступом к приложениям в вашей среде.

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

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

• Идентификатор Microsoft Entra P2 или Управление идентификацией Microsoft Entra
• лицензия Enterprise Mobility + Security (EMS) E5.

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

Кроме того, хотя это и не требуется для проверки доступа к приложению, рекомендуется регулярно проверять членство в привилегированных ролях каталога, которые дают возможность управлять доступом других пользователей ко всем приложениям. Администраторы в Global Administrator, Identity Governance Administrator, User Administrator, Application Administrator, Cloud Application Administrator и Privileged Role Administrator могут вносить изменения в пользователей и назначения им ролей приложений, поэтому убедитесь, что проверка доступа для этих ролей каталога была запланирована.

Определение интеграции приложения с идентификатором Microsoft Entra

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

• Приложение использует идентификатор Microsoft Entra для федеративного единого входа, а идентификатор Microsoft Entra ID управляет выдачой маркера проверки подлинности. Если идентификатор Microsoft Entra является единственным поставщиком удостоверений для приложения, то только пользователи, которым назначена одна из ролей приложения в идентификаторе Microsoft Entra ID, могут войти в приложение. Те пользователи, которые получили отказ в результате проверки, теряют назначение роли приложения и больше не могут получить новый маркер для входа в приложение.
• Приложение использует списки пользователей или групп, предоставляемые приложению идентификатором Microsoft Entra. Это можно сделать с помощью протокола подготовки, такого как система для управления междоменных удостоверений (SCIM), приложение запрашивает идентификатор Microsoft Entra с помощью Microsoft Graph, Microsoft Entra подготавливает пользователей в базу данных или группы приложения, записываемые в AD DS. Те пользователи, которые получили отказ в результате проверки, теряют назначение роли приложения или членство в группе, а когда эти изменения становятся доступными для приложения, отклоненные пользователи лишаются прав доступа.

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

Чтобы обеспечить широкий спектр приложений и ИТ-требований для решения с помощью идентификатора Microsoft Entra ID, существует несколько шаблонов для интеграции приложения с идентификатором Microsoft Entra. Каждый шаблон использует различные артефакты Microsoft Entra. В следующей блок-схеме показано, как выбрать из трех шаблонов интеграции A, B и C, которые подходят для приложений для использования с управлением удостоверениями. Зная, какой шаблон используется для конкретного приложения, вы можете настроить соответствующие ресурсы в идентификаторе Microsoft Entra, чтобы быть готовым к проверке доступа.

Другие варианты

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

• Некоторые веб-службы Майкрософт, такие как Exchange Online, используют лицензии. Хотя лицензии пользователей нельзя проверить напрямую, если вы используете назначения лицензий на основе групп и группы с назначенными пользователями, вы можете проверить членство в этих группах.
• Некоторые приложения используют делегированное согласие пользователя для управления доступом к Microsoft Graph или другим ресурсам. Поскольку согласие каждого пользователя не контролируется процессом утверждения, согласие не просматривается. Вместо этого можно проверить, кто может подключаться к приложению с помощью политик условного доступа, которые могут быть основаны на назначениях ролей приложения или членства в группах.
• Если приложение не поддерживает протоколы федерации или подготовки, вам потребуется процесс ручного применения результатов при завершении проверки. В случае приложения, поддерживающего только интеграцию единого входа с паролем, если назначение приложения будет удалено после завершения проверки, приложение не будет отображаться на странице myapps для пользователя, но это не помешает пользователю, который уже знает пароль, продолжить вход в приложение. Сведения о локальных приложениях см. в разделе "Управление пользователями приложения, которое не поддерживает подготовку". Для приложений SaaS попросите поставщика SaaS подключиться к коллекции приложений для федерации или подготовки, обновив свое приложение для поддержки стандартного протокола.

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

Теперь, когда вы определили шаблон интеграции для приложения, проверьте, как это приложение представлено в идентификаторе Microsoft Entra ID, готово к просмотру.

1. Войдите в Центр администрирования Microsoft Entra как минимум администратор управления удостоверениями.

2. Перейдите к >корпоративным приложениям> удостоверений.>

3. Здесь можно проверить, находится ли ваше приложение в списке корпоративных приложений в клиенте.

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

5. Если приложение еще не указано, но использует группы безопасности AD и является веб-приложением, а конфигурация приложения может быть изменена для поиска различных групп безопасности в AD, а затем добавьте приложение для удаленного доступа через прокси приложения, переместите членство существующих групп безопасности AD в новые группы Microsoft Entra и настройте обратную запись в AD. Затем обновите приложение, чтобы проверить наличие новых групп AD, созданных с помощью обратной записи групп, как описано в разделе "Управление приложениями на основе локальная служба Active Directory ( Kerberos)".

6. Если приложение еще не указано, но использует группы безопасности AD и является веб-приложением, а конфигурация приложения не может быть изменена для поиска различных групп безопасности в AD, а затем добавьте приложение для удаленного доступа через прокси приложения, переместите членство существующих групп безопасности AD в новые группы Microsoft Entra и настройте обратную запись в AD. Затем обновите существующие группы безопасности AD, которые приложение проверяло, чтобы включить новые группы в качестве члена, как описано в разделе управления локальная служба Active Directory приложениями на основе Kerberos.

7. Если приложение еще не указано, использует группы безопасности AD и не является веб-приложением, а конфигурация приложения может быть изменена, чтобы искать различные группы безопасности в AD, а затем переместить членство существующих групп безопасности AD в новые группы Microsoft Entra и настроить обратную запись в AD. Затем обновите приложение, чтобы проверить наличие новых групп AD, созданных с помощью обратной записи группы, как описано в разделе "Управление приложениями на основе локальная служба Active Directory ( Kerberos)". Затем перейдите к следующему разделу.

8. Если приложение еще не указано, использует группы безопасности AD и не является веб-приложением, а конфигурация приложения не может быть изменена, чтобы искать различные группы безопасности в AD, а затем переместить членство существующих групп безопасности AD в новые группы Microsoft Entra и настроить обратную запись в AD. Затем обновите существующие группы безопасности AD, которые приложение проверяло, чтобы включить новые группы в качестве члена, как описано в разделе управления локальная служба Active Directory приложениями на основе Kerberos. Затем перейдите к следующему разделу.

9. Когда приложение появится в списке корпоративных приложений в арендаторе, выберите приложение из списка.

10. Перейдите на вкладку Свойства. Убедитесь, что для параметра Требуется назначение пользователя? установлено значение Да. При выборе значения Нет все пользователи в каталоге, включая пользователей с внешними удостоверениями, смогут получать доступ к приложению, и выполнить проверку доступа для приложения будет невозможно.

    

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

12. Перейдите на вкладку "Подготовка ". Если автоматическая подготовка не настроена, останавливается или находится в карантине, идентификатор Microsoft Entra ID не сможет уведомить приложение, когда доступ пользователя удаляется, если этот доступ запрещен во время проверки. Подготовка может не потребоваться для некоторых шаблонов интеграции, если приложение федеративно и использует только идентификатор Microsoft Entra в качестве поставщика удостоверений, или приложение использует группы AD DS. Однако если интеграция с приложением является шаблоном C, а приложение не поддерживает федеративный единый вход с идентификатором Microsoft Entra в качестве своего единственного поставщика удостоверений, необходимо настроить подготовку из идентификатора Microsoft Entra в приложение. Подготовка необходима, чтобы идентификатор Microsoft Entra можно автоматически удалить проверяемых пользователей из приложения после завершения проверки, и этот шаг удаления можно выполнить с помощью изменения, отправляемого с идентификатора Microsoft Entra в приложение через SCIM, LDAP, SQL, SOAP или REST.

    • Если это приложение коллекции, поддерживающее подготовку, настройте приложение для подготовки.
    • Если приложение является облачным и поддерживает SCIM, настройте подготовку пользователей с помощью SCIM.
    • Если приложение является локальным и поддерживает SCIM, настройте приложение с помощью агента подготовки для локальных приложений на основе SCIM.
    • Если приложение использует базу данных SQL, настройте приложение с агентом подготовки для локальных приложений SQL.
    • Если приложение использует другой каталог LDAP, настройте приложение с помощью агента подготовки для локальных приложений на основе LDAP.
    • Если у приложения есть локальные учетные записи пользователей, управляемые с помощью SOAP или REST API, настройте приложение с агентом подготовки с помощью соединителя веб-служб.
    • Если у приложения есть локальные учетные записи пользователей, управляемые через соединитель MIM, настройте приложение с агентом подготовки с помощью пользовательского соединителя.
    • Если приложение является SAP ECC с NetWeaver AS ABAP 7.0 или более поздней версии, настройте приложение с агентом подготовки с помощью соединителя веб-служб, настроенного SAP ECC.

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

1. Если подготовка настроена, выберите "Изменить сопоставления атрибутов", разверните раздел "Сопоставление" и выберите "Подготовка пользователей Microsoft Entra". Убедитесь, что в списке сопоставлений атрибутов есть сопоставление isSoftDeleted атрибута в хранилище данных приложения, которое вы хотите задать для идентификатора Microsoft Entra значение false, когда пользователь теряет доступ. Если это сопоставление отсутствует, идентификатор Microsoft Entra не уведомляет приложение, когда пользователь покидает область, как описано в том, как работает подготовка.

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

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

4. Если приложение интегрировано с шаблоном C, перед началом проверки необходимо убедиться, что пользователи в этом списке совпадают с данными в внутреннем хранилище данных приложений. Идентификатор Microsoft Entra не импортирует пользователей или права доступа из приложения, но вы можете назначить пользователей роли приложения с помощью PowerShell. Сведения о том, как перенести пользователей из разных хранилищ данных приложений в идентификатор Microsoft Entra и назначить их роли приложения, см. в разделе "Управление существующими пользователями ".

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

6. Проверьте список объектов каталога, назначенных ролям, чтобы убедиться в отсутствии групп, назначенных ролям приложения. Это приложение можно просмотреть, если для роли назначена группа; Однако пользователь, являющийся членом группы, назначенной роли, и доступ которого был отклонен, не будет автоматически удален из группы. Если приложение не полагается на группы, рекомендуется сначала преобразовать приложение в прямые назначения пользователей, а не члены групп, чтобы пользователь, доступ которого запрещен во время проверки доступа, может автоматически удалить назначение роли приложения. Если приложение полагается на группы, а все группы приложений назначаются одной роли приложения, то вместо проверки назначений приложений просмотрите членства в группах.

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

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

1. Войдите в Центр администрирования Microsoft Entra как минимум администратор управления удостоверениями.
2. Перейдите к >группам.
3. Найдите и выберите каждую группу из списка.
4. На вкладке Обзор убедитесь, что Тип членства – Назначено, а Источник – Облако. Если приложение использует динамическую группу или группу, синхронизированную из локальной среды, эти членства в группах нельзя изменить в идентификаторе Microsoft Entra. Мы рекомендуем преобразовать приложение в группы, созданные в идентификаторе Microsoft Entra с назначенными членством, а затем скопировать пользователей-участников в новую группу.
5. Перейдите на вкладку "Роли и администраторы ". На этой вкладке отображаются административные роли, которые предоставляют права на управление представлением группы в идентификаторе Microsoft Entra, а не права доступа в приложении. Что касается каждой административной роли, которая позволяет изменять членство в группе и имеет пользователей в этой административной роли, необходимо убедиться, что в этой роли находятся только полномочные пользователи.
6. Перейдите на вкладку Члены. Убедитесь, что членами группы являются пользователи, и что в ней нет членов, не являющихся пользователями, или вложенных групп. Если при запуске проверки нет членов группы, проверка этой группы завершается немедленно.
7. Перейдите на вкладку "Владельцы ". Убедитесь, что несанкционированные пользователи не отображаются как владельцы. Если вы просите владельцев групп выполнить проверку доступа группы, убедитесь, что у группы есть один или несколько владельцев.

Выбор подходящих рецензентов

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

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

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

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

Создание проверок

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

1. На этом шаге Identity Governance Administrator вы должны быть в роли.

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

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

   Примечание.

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

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

Просмотр назначений, которые обновляются после завершения проверок

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

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

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

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

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

5. Если вы настроили обратную запись группы для проверяемых групп, дождитесь завершения обратной записи группы в Microsoft Entra Cloud Sync и изменения распространяются на все контроллеры домена.

6. Если подготовка не настроена для приложения, необходимо отдельно скопировать список запрещенных пользователей в приложение. Например, при проверке доступа для группы, управляемой Windows Server AD, используйте следующий пример скрипта PowerShell. В этом скрипте показаны требуемые вызовы Microsoft Graph. Он также экспортирует командлеты PowerShell для работы с Windows Server AD, которые производят необходимые изменения.

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

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

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

• Планирование развертывания проверок доступа Microsoft Entra
• Создание проверки доступа для группы или приложения
• Управление доступом к приложениям