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

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

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

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

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

• Идентификатор 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 ID для федеративной системы единого входа, и Microsoft Entra ID управляет выдачей токенов аутентификации. Если идентификатор Microsoft Entra является единственным поставщиком удостоверений для приложения, то только пользователи, которым назначена одна из ролей приложения в идентификаторе Microsoft Entra ID, могут войти в приложение. Те пользователи, которым отказано в доступе после проверки, теряют назначение роли в приложении и больше не могут получить новый токен для авторизации в приложении.
• Приложение использует списки пользователей или групп, предоставляемые приложению идентификатором Microsoft Entra. Это выполнение может быть осуществлено с помощью протокола предоставления, такого как система управления междоменной идентификацией (SCIM), с помощью приложения, которое запрашивает Microsoft Entra ID через 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. Перейдите к >Entra ID>корпоративные приложения.

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

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

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

    

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

13. Перейдите на вкладку "Подготовка ". Если автоматическая подготовка не настроена, останавливается или находится в карантине, идентификатор Microsoft Entra ID не сможет уведомить приложение, когда доступ пользователя удаляется, если этот доступ запрещен во время проверки. Подготовка может не потребоваться для некоторых шаблонов интеграции, если приложение федеративно и использует только идентификатор Microsoft Entra в качестве поставщика удостоверений, или приложение использует группы AD DS. Однако, если интеграция вашего приложения соответствует шаблону C, и приложение не поддерживает федеративный единый вход с Microsoft Entra ID как единственным поставщиком удостоверений, необходимо настроить предоставление из Microsoft Entra ID для приложения. Профилирование необходимо, чтобы Microsoft Entra ID мог автоматически удалять проверенных пользователей из приложения по завершении проверки, и этот шаг удаления можно выполнить с помощью изменения, отправляемого от Microsoft Entra ID к приложению через 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 с атрибутом в хранилище данных приложения, который необходимо задать на false для Microsoft Entra ID, когда пользователь теряет доступ. Если это сопоставление отсутствует, идентификатор Microsoft Entra не уведомляет приложение, когда пользователь покидает область, как это описано в том, как работает управление ресурсами.

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

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

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

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

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

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

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

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

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

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

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

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

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

Создайте обзоры

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

1. На этом шаге вам следует находиться в роли Identity Governance Administrator.

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

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

   Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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