Поделиться через

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

  • Статья

Управление идентификацией 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, чтобы быть готовым к проверке доступа.

Блок-схема шаблонов интеграции приложений

Расписание Шаблон интеграции приложений Шаги по подготовке к проверке доступа
а Приложение поддерживает федеративный SSO, Microsoft Entra ID является единственным поставщиком удостоверений, и приложение не полагается на требования группы или роли. В этом шаблоне вы настраиваете, что приложению требуются индивидуальные назначения ролей приложения, и пользователи назначены для приложения. Затем, чтобы выполнить проверку, создайте единую проверку доступа для приложения, охватывающую пользователей, которым назначена роль этого приложения. После завершения проверки, если пользователю было отказано, он будет исключён из роли приложения. Идентификатор Microsoft Entra ID больше не будет выдавать этому пользователю токены федерации, и пользователь не сможет войти в это приложение.
Б Если приложение использует утверждения групп в дополнение к назначениям ролей приложения. Приложение может использовать членство в группах Active Directory или Microsoft Entra, отличающееся от ролей приложений, для предоставления более тонкой настройки прав доступа. Здесь вы можете выбрать в зависимости от ваших бизнес-требований либо проверку пользователей, которым назначены роли приложений, либо проверку пользователей, которые имеют членство в группах. Если группы не предоставляют комплексного покрытия доступа, в частности, если у пользователей есть доступ к приложению, даже если они не являются членами этих групп, рекомендуется просмотреть назначения ролей приложения, как показано в предыдущем шаблоне A.
C Если приложение не полагается исключительно на идентификатор Microsoft Entra для федеративного единого входа, но поддерживает подготовку через SCIM, через обновления таблицы SQL пользователей, имеет каталог LDAP, отличный от AD LDAP, или поддерживает протокол подготовки SOAP или REST. В этом шаблоне вы настраиваете Microsoft Entra ID для предоставления пользователям назначений ролей приложения в базе данных или каталоге приложения, обновляете назначения ролей приложения в Microsoft Entra ID, добавляя список пользователей, которые в настоящее время имеют доступ, а затем создаете единый обзор назначений ролей приложения. Дополнительные сведения см. в разделе "Управление существующими пользователями приложения" для обновления назначений ролей приложения в идентификаторе 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. Если приложение еще не указано, но использует группы безопасности Microsoft Entra исключительно для управления доступом, перейдите к следующему разделу.

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

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

    Снимок экрана: планирование назначения приложений.

  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.

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

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

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

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

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

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

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

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

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

  1. Войдите в Центр администрирования Microsoft Entra в качестве Администратора управления удостоверениями.
  2. Перейдите к >группам.
  3. Найдите и выберите каждую группу из списка.
  4. На вкладке Обзор убедитесь, что Тип членства – Назначено, а Источник – Облако. Если приложение использует динамическую группу или группу, синхронизированную из локальной среды, эти членства в группах нельзя изменить в идентификаторе 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 с ссылкой на панель доступа, где они просматривают членство в группах или доступе к приложению.

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

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

  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. Дополнительные сведения об управлении временем существования маркеров доступа см. в разделе о настройке времени существования маркеров.

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