通过

准备对用户对应用程序的访问权限进行访问评审

  • 项目

利用 Microsoft Entra ID 治理，可以在组织的安全性和员工工作效率与适当的流程和可见性需求之间实现平衡。 使用这项服务，可以确保人员、人员具备的访问权限以及访问权限对应的资源都是正确的。

具有合规性要求或风险管理计划的组织拥有敏感或业务关键型应用程序。 应用程序的敏感性可能基于其目的或其包含的数据，例如组织客户的财务信息或个人信息。 对于这些应用程序，组织中只有一部分用户有权访问，只应根据记录的业务要求许可访问。 Microsoft Entra ID 可以使用标准协议和 API 接口与许多常用的 SaaS 应用程序、本地应用程序和你的组织开发的应用程序集成。 通过这些接口，Microsoft Entra ID 可以成为控制谁有权访问这些应用程序的权威源。 将应用程序与 Microsoft Entra ID 集成时，可以使用访问评审来再次验证有权访问这些应用程序的用户，并移除不再需要访问权限的用户的访问权限。 还可以使用其他功能（包括使用条款、条件访问和权利管理）来管理对应用程序的访问，如如何管理在环境中对应用程序进行的访问中所述。

评审访问权限的先决条件

若要使用 Microsoft Entra ID 对应用程序的访问权限进行访问评审，必须在租户中拥有以下许可证之一：

  • Microsoft Entra ID P2 或 Microsoft Entra ID 治理
  • 企业移动性 + 安全性 (EMS) E5 许可证

虽然使用访问评审功能并不要求为用户分配这些许可证才能使用该功能，但你需要拥有足够的许可证。 有关详细信息，请参阅访问评审的许可场景示例。

此外，虽然评审应用程序访问权限不要求这样做，但我们还是建议定期评审能够控制其他用户对所有应用程序访问权限的特权目录角色的成员身份。 Global Administrator、Identity Governance Administrator、User Administrator、Application Administrator、Cloud Application Administrator 和 Privileged Role Administrator 中的管理员可以对用户及其应用程序角色分配进行更改，因此请确保已安排对这些目录角色的访问评审。

确定应用程序如何与 Microsoft Entra ID 集成

若要将 Microsoft Entra 访问评审用于应用程序，必须首先将应用程序与 Microsoft Entra ID 集成并在目录中进行表示。 与 Microsoft Entra ID 集成的应用程序意味着必须满足以下两个要求之一：

  • 应用程序依赖 Microsoft Entra ID 进行联合 SSO，Microsoft Entra ID 控制身份验证令牌颁发。 如果 Microsoft Entra ID 是应用程序的唯一标识提供者，则只有分配到 Microsoft Entra ID 中应用程序角色之一的用户才能登录到应用程序。 被评审拒绝的用户将失去其应用程序角色分配，并且无法再获取用于登录到应用程序的新令牌。
  • 应用程序依赖于 Microsoft Entra ID 提供给应用程序的用户或组列表。 要完成此操作，可使用预配协议，例如跨域身份管理系统 (SCIM)，或者使用通过 Microsoft Graph 查询 Microsoft Entra ID 的应用程序、将用户预配到应用程序数据库的 Microsoft Entra 或写入 AD DS 的组。 被评审拒绝的用户将失去其应用程序角色分配或组成员身份，当这些更改可供应用程序使用时，被拒绝的用户将不再具有访问权限。

如果应用程序不满足这两个条件，由于应用程序不依赖于 Microsoft Entra ID，因此仍可使用访问评审，但可能存在一些限制。 不在 Microsoft Entra ID 中或未在 Microsoft Entra ID 中分配给应用程序角色的用户不会包含在评审中。 此外，如果应用程序不支持任何预配协议，则删除被拒绝用户的更改将无法自动发送到应用程序。 相反，组织必须具备将已完成的评审结果发送到应用程序的流程。

为了允许使用 Microsoft Entra ID 解决各种应用程序和 IT 要求，对于如何将应用程序与 Microsoft Entra ID 集成有多种模式。 每个模式都使用不同的 Microsoft Entra 项目。 以下流程图演示了如何从三种集成模式（A、B 和 C）中进行选择，这些模式适用于用于标识治理的应用程序。 了解特定应用程序正在使用的模式有助于在 Microsoft Entra ID 中配置适当的资源，以便为访问评审做好准备。

应用程序集成模式流程图

模式 应用程序集成模式 准备访问评审的步骤
A 应用程序支持联合 SSO，Microsoft Entra ID 是唯一的标识提供者，且应用程序不依赖于组或角色声明。 在此模式中，你将进行以下配置：应用程序需要单个应用程序角色分配，将用户分配到该应用程序。 然后，若要执行评审，你将为分配给此应用程序角色的用户创建一个访问评审。 评审完成后，如果用户被拒绝，则会从应用程序角色中移除它们。 然后，Microsoft Entra ID 将不再向该用户颁发联合令牌，并且该用户将无法登录到该应用程序。
B 如果应用程序除应用程序角色分配外还使用组声明。 应用程序可使用 Active Directory 或 Microsoft Entra 组成员身份来表达更精细的访问（此身份与应用程序角色不同）。 此处，你可以根据业务需求选择是评审具有应用程序角色分配的用户，还是评审具有组成员身份的用户。 如果组不提供全面的访问范围，特别是如果用户即使不是这些组的成员也可以访问应用程序，则建议查看应用程序角色分配，如之前的模式 A 所示。
C 如果应用程序不完全依赖 Microsoft Entra ID 进行联合 SSO，而是支持通过 SCIM 或通过更新用户的 SQL 表或非 AD LDAP 目录进行预配，或者支持 SOAP 或 REST 预配协议。 在此模式中，你将配置 Microsoft Entra ID 以预配具有应用程序数据库或目录的应用程序角色分配的用户，使用当前具有访问权限的用户的列表更新 Microsoft Entra ID 中的应用程序角色分配，然后创建对应用程序角色分配的单个访问评审。 有关详细信息，请参阅治理应用程序的现有用户以更新 Microsoft Entra ID 中的应用程序角色分配。

其他选项

先前部分中列出的集成模式适用于第三方 SaaS 应用程序，或适用于由组织开发或为组织开发的应用程序。

  • 某些 Microsoft Online Services（例如 Exchange Online）使用许可证。 虽然无法直接评审用户的许可证，但如果使用的是基于组的许可证分配，且具有已分配用户的组，则可以改为评审这些组的成员身份。
  • 某些应用程序可能使用委派的用户同意来控制对 Microsoft Graph 或其他资源的访问。 由于每个用户的同意不受审批过程的控制，因此无法在此对其进行评审。 相反，你可以查看谁能够通过条件访问策略连接到应用程序，这些策略可能基于应用程序角色分配或组成员身份。
  • 如果应用程序不支持联合身份验证或预配协议，则需要一个在评审完成后手动应用结果的过程。 对于仅支持密码 SSO 集成的应用程序，如果在评审完成后删除了应用程序分配，则应用程序不会显示在用户的 myapps 页面上，但不会阻止已知道密码的用户能够继续登录到应用程序。 对于本地应用程序，请参阅控制不支持预配的应用程序的用户。 对于 SaaS 应用程序，请要求 SaaS 供应商加入应用库，方法是通过更新其应用程序来支持标准协议，从而进行联合或预配。

检查应用程序是否已准备好进行评审

现在，你已确定应用程序的集成模式，请检查以 Microsoft Entra ID 表示的应用程序是否已做好评审准备。

  1. 至少以标识治理管理员身份登录到 Microsoft Entra 管理中心。

  2. 浏览到>“标识”>“应用程序”>“企业应用程序”。

  3. 可在此处检查，以查看应用程序是否位于租户中的企业应用程序列表上。

  4. 如果尚未列出该应用程序，请查看该应用程序是否可用于应用程序库，以获取可集成用于联合 SSO 或预配的应用程序。 如果它位于库中，则使用教程配置应用程序以进行联合，如果它支持预配，则还要配置应用程序以进行预配。

  5. 如果应用程序尚未列出，但使用 AD 安全组并且是 Web 应用程序，而且应用程序的配置可以更改为查找 AD 中的不同安全组，则请添加应用程序以通过应用程序代理进行远程访问，将现有 AD 安全组的成员身份移动到新的 Microsoft Entra 组，并配置到 AD 的组写回。 然后，按照管理基于本地 Active Directory 的应用 (Kerberos)中所述，更新应用程序以检查是否存在组写回创建的新 AD 组。

  6. 如果应用程序尚未列出，但使用 AD 安全组并且是 Web 应用程序，而且应用程序的配置无法更改为查找 AD 中的不同安全组，则请添加应用程序以通过应用程序代理进行远程访问，将现有 AD 安全组的成员身份移动到新的 Microsoft Entra 组，并配置到 AD 的组写回。 然后，根据管理基于本地 Active Directory 的应用 (Kerberos) 中所述，更新应用程序正在进行检查的现有 AD 安全组，以将新组作为成员包括在内。

  7. 如果应用程序尚未列出，使用 AD 安全组并且不是 Web 应用程序，而且应用程序的配置可以更改为查找 AD 中的不同安全组，则请将现有 AD 安全组的成员身份移动到新的 Microsoft Entra 组，并配置到 AD 的组写回。 接下来，根据管理基于本地 Active Directory 的应用 (Kerberos) 中所述，更新应用程序以检查是否存在由组写回创建的新 AD 组。 请继续阅读下一节。

  8. 如果应用程序尚未列出，使用 AD 安全组并且不是 Web 应用程序，而且应用程序的配置无法更改为查找 AD 中的不同安全组，则请将现有 AD 安全组的成员身份移动到新的 Microsoft Entra 组，并配置到 AD 的组写回。 接下来，根据管理基于本地 Active Directory 的应用 (Kerberos) 中所述，更新应用程序正在进行检查的现有 AD 安全组，以将新组作为成员包括在内。 请继续阅读下一节。

  9. 应用程序位于租户中的企业应用程序列表中后，请从列表中选择应用程序。

  10. 更改为“属性”选项卡。验证“需要进行用户分配?”选项是否设置为“是”。 如果设置为“否”，则目录中的所有用户（包括外部标识）都可以访问应用程序，并且无法评审对应用程序的访问。

    显示计划应用分配的屏幕截图。

  11. 更改为“角色和管理员”选项卡。此选项卡显示管理角色，这些角色授予在 Microsoft Entra ID 中控制应用程序表示形式的权限，而不是应用程序中的访问权限。 对于具有允许更改应用程序集成或分配的权限，并具有对该管理角色的分配的每个管理角色，请确保只有授权用户处于该角色中。

  12. 更改为“预配”选项卡。如果未配置自动预配，自动预配已停止或已被隔离，则在用户访问权限被移除后，如果评审期间该访问权限被拒绝，Microsoft Entra ID 无法通知应用程序。 如果应用程序是联合的，并且仅依赖 Microsoft Entra ID 作为其标识提供者，或者应用程序使用 AD DS 组，某些集成模式可能就不需要预配。 但是，如果应用程序集成是模式 C，并且应用程序不支持将 Microsoft Entra ID 的联合 SSO 作为其唯一标识提供者，则需要配置从 Microsoft Entra ID 到应用程序的预配。 必须进行预配，以便 Microsoft Entra ID 可以在评审完成时自动从应用程序中删除已评审的用户，并且可以通过 SCIM、LDAP、SQL、SOAP 或 REST 从 Microsoft Entra ID 发送到应用程序的更改来完成此删除步骤。

如需更多详细信息，请参阅将应用程序与 Microsoft Entra ID 集成。

  1. 如果已配置预配，请选择“编辑属性映射”，展开“映射”部分，然后选择“预配 Microsoft Entra 用户”。 检查属性映射列表中是否存在某个 isSoftDeleted 到应用程序数据存储中的属性的映射，你希望在用户失去访问权限时让 Microsoft Entra ID 将其设置为 false。 如果此映射不存在，则 Microsoft Entra ID 不会在用户离开范围时通知应用程序，如预配工作原理中所述。

  2. 如果应用程序支持联合 SSO，请更改为“条件访问”选项卡。检查此应用程序的已启用策略。 如果存在已启用、阻止访问、已将用户分配到策略但没有其他条件的策略，则可能已阻止这些用户将联合 SSO 连接到应用程序。

  3. 更改为“用户和组”选项卡。此列表包含分配给 Microsoft Entra ID 中的应用程序的所有用户。 如果列表为空，则应用程序评审会立即完成，因为评审者没有可评审的访问。

  4. 如果应用程序与模式 C 集成，则需要在开始评审之前确认此列表中的用户与应用程序内部数据存储中的用户相同。 Microsoft Entra ID 不会自动从应用程序导入用户或其访问权限，但你可以通过 PowerShell 将用户分配到应用程序角色。 若要了解如何将不同应用程序数据存储中的用户引入 Microsoft Entra ID，并将其分配给应用程序角色，请参阅管理应用程序的现有用户。

  5. 检查是否将所有用户分配到同一应用程序角色，例如“用户”。 如果用户被分配到多个角色，则创建应用程序的访问评审后，将对应用程序所有角色的所有分配一起评审。

  6. 请检查分配给角色的目录对象列表，以确认没有分配给应用程序角色的组。 如果有分配给角色的组，则可以评审此应用程序；但是，如果用户是分配给该角色的组的成员，并且其访问权限被拒绝，则不会自动从该组中删除。 如果应用程序本身不依赖组，建议首先将应用程序转换为具有直接用户分配，而不是组成员，以便在访问评审期间被拒绝的用户可以自动移除其应用程序角色分配。 如果应用程序确实依赖于组，并且将应用程序的所有组分配给同一应用程序角色，那么你将查看组成员身份，而不是查看应用程序分配情况。

检查组是否已准备好进行评审

如果应用程序不依赖于组，请跳到下一部分。 否则，如果应用程序集成还要求评审一个或多个组（如模式 B 中所述），则查看每个组是否已准备好进行评审。

  1. 至少以标识治理管理员身份登录到 Microsoft Entra 管理中心。
  2. 浏览到 >“组”。
  3. 搜索并从列表中选择每个组。
  4. 在“概述”选项卡上，验证是否已分配“成员类型”，并且“源”是“云”。 如果应用程序使用动态组或从本地同步的组，则无法在 Microsoft Entra ID 中更改这些组成员身份。 建议将应用程序转换为在 Microsoft Entra ID 中创建的具有已分配成员身份的组，然后将成员用户复制到该新组。
  5. 更改为“角色和管理员”选项卡。此选项卡显示管理角色，这些角色授予在 Microsoft Entra ID 中控制组表示形式的权限，而不是应用程序中的访问权限。 对于允许更改组成员身份并具有该管理角色的用户的每个管理角色，请确保只有授权用户处于该角色。
  6. 更改为“成员”选项卡。验证组的成员是否为用户，以及没有非用户成员或嵌套组。 如果评审开始时某个组没有成员，则该组的评审会立即完成。
  7. 更改到“所有者”选项卡。确保没有未经授权的用户显示为所有者。 如果你要求组所有者执行组的访问评审，请确认该组具有一个或多个所有者。

选择适当的审阅者

创建每个访问评审时，管理员可以选择一个或多个审阅者。 审阅者都可以通过选择继续访问资源的用户或将其删除来执行评审。

通常，资源所有者负责执行评审。 如果要创建组评审，作为评审模式 B 中集成的应用程序的访问权限的一部分，则可以选择组所有者作为审阅者。 因为 Microsoft Entra ID 中的应用程序不一定具有所有者，因此无法选择应用程序所有者作为审阅者。 相反，在创建评审时，可以提供应用程序所有者的名称作为审阅者。

在创建组或应用程序的评审时，还可以选择进行多阶段评审。 例如，可以选择让每个分配的用户的经理执行评审的第一个阶段，让资源所有者执行第二阶段。 这样，资源所有者就可以专注于已获得其经理批准的用户。

在创建评审之前，请检查租户中是否有足够的 Microsoft Entra ID P2 或 Microsoft Entra ID Governance SKU 席位。 此外，请检查所有审阅者是否都是具有电子邮件地址的活动用户。 访问评审开始后，他们都会查看来自 Microsoft Entra ID 的电子邮件。 如果审阅者没有邮箱，则在评审开始时，他们不会收到电子邮件或电子邮件提醒。 而且，如果阻止他们登录 Microsoft Entra ID，则他们将无法执行评审。

创建评审

根据集成模式以及审阅者应由谁来确定资源、应用程序以及一个或多个组（可选）后，可以配置 Microsoft Entra ID 以启动评审。

  1. 对于此步骤，你应为 Identity Governance Administrator 角色。

  2. 在模式 A 和 C 中，你将创建一个访问评审，选择应用程序。 按照创建组或应用程序的访问评审指南中的说明，创建应用程序的角色分配评审。

  3. 如果应用程序与模式 B 集成，请使用同一指南为每个组创建其他访问评审。

    注意

    如果创建访问评审并启用评审决策帮助程序，则决策帮助程序将因要评审的资源而异。 如果资源是应用程序，则建议将基于 30 天间隔期，该间隔期从用户上次登录到应用程序的时间算起。 如果资源是一个组，则建议基于用户上次登录到租户中任何应用程序的时间间隔，而不仅仅是使用这些组的应用程序。

  4. 访问评审开始时，要求审阅者提供输入。 默认情况下，他们每个人都会收到来自 Microsoft Entra ID 的电子邮件，其中包含指向访问面板的链接，他们将在其中评审组中的成员身份或对应用程序的访问权限。

查看评审完成时更新的作业

评审开始后，可以监视其进度，并根据需要更新审阅者，直到评审完成。 然后，可以确认其访问权限被审阅者拒绝的用户是否已从应用程序中删除其访问权限。

  1. 监视访问评审，确保评审人员选择批准或拒绝用户继续访问的需要，直到访问评审完成。

  2. 如果在创建评审时未选择自动应用，则需要在评审完成后应用评审结果。

  3. 等待评审的状态更改为“已应用结果”。 几分钟后，应会看到被拒绝的用户（如果有）已从组成员身份或应用程序分配中删除。

  4. 如果以前已将预配用户预配到应用程序，则应用结果后，Microsoft Entra ID 会开始从应用程序中取消预配被拒绝的用户。 可以监视取消预配用户的过程。 如果预配指示应用程序出错，可以下载预配日志以调查应用程序是否存在问题。

  5. 如果已经为已评审的组配置了组写回，请等到 Microsoft Entra 云同步中的组写回完成，然后更改会传播到所有域控制器。

  6. 如果未为应用程序配置预配，则需要单独将拒绝用户列表复制到应用程序。 例如，在 Windows Server AD 托管组的访问评审中，请使用此 PowerShell 示例脚本。 此脚本概述了所需的 Microsoft Graph 调用，并导出了 Windows Server AD-PowerShell cmdlet 来执行更改。

  7. 如果需要，还可以下载已完成评审的评审历史记录报告。

  8. 被拒绝继续访问的用户能够继续使用联合应用程序的时长取决于应用程序自己的会话生存期和访问令牌生存期。 如果应用程序使用 Kerberos，由于 Kerberos 会在用户登录域时缓存该用户的组成员身份，因此用户继续享有访问权限，直至其 Kerberos 票证过期。 若要了解有关控制访问令牌生存期的详细信息，请参阅可配置令牌生存期。

后续步骤