未配置应用程序的管理员同意工作流

如果没有管理员同意工作流，非管理员用户就没有内置的途径来提升对应用程序的权限请求。因此，用户可能会采取变通方法，或者（如果允许用户同意）自行授予权限（详情请参阅“应用程序的无限制用户同意”IoE）。在这两种情况下，组织都会失去对权限授予的可见性和控制力，从而削弱了最小特权原则的执行。

同意网络钓鱼攻击（也称为非法同意授予攻击）会诱骗用户向看似合法的恶意应用授予访问权限。如果没有审批工作流，就缺少了用于标记可疑权限范围的审查层，例如 Files.ReadWrite（对用户文件的完全访问权限）或 Mail.ReadWrite（对所有邮箱的读写访问权限）。因此，攻击者可以获得对用户数据的持久访问权限，这种访问不会因密码更改或 MFA 的启用而被撤销。

如果没有管理员同意工作流，管理员就必须通过临时渠道（如电子邮件、聊天工具或直接联系）来处理权限请求，而这会产生审批盲点。既无自动请求流程，也无提醒系统，更无关于批准者、时间或原因的记录。在缺乏审批的情况下，管理员难以验证在授予应用程序权限之前是否进行了适当的审查。

根据 BOD 25-01 的规定，CISA“Microsoft Entra ID 的 M365 安全配置基准”中的 MS.AAD.5.3v1 策略明确要求：“应为应用程序配置管理员同意工作流”。Microsoft 在“配置 Microsoft Entra 以提高安全性”一文中还建议“启用管理员同意工作流”。

在您的 Entra ID 租户中启用并配置管理员同意工作流，以建立一个清晰、标准化的流程，供用户请求需要管理员同意的应用程序权限。启用后，用户会看到“需要审批”对话框，并可提交请求理由。系统会自动将请求发送给指定的审批人。这一结构化的工作流覆盖所有请求，并使管理员能够全面查看所有待处理的请求。

启用管理员同意工作流后，管理员必须分配合适的审批人。要批准请求，审批人必须拥有特定角色，例如全局管理员、云应用程序管理员、应用程序管理员或特权角色管理员。将用户指定为审批人，并不会提升其特权。没有所需角色的审批人可以查看、阻止或拒绝请求，但只有已拥有可在租户范围内授予管理员同意的角色的审批人，才能批准这些请求。 Tenable 建议尽可能分配“云应用程序管理员”角色，因为该角色提供了必要的权限，而不会像“全局管理员”角色那样拥有广泛的访问权限。后者应仅在紧急情况下使用。然而，只有全局管理员才能批准针对请求 Microsoft Graph 应用角色的应用程序的管理员同意请求。

定期审核审批人列表，确保在人员变动时审批权限的分配保持最新。新的审批人只能查看在其获得分配后创建的请求，而已移除的审批人仍可访问此前的请求记录。管理员应谨慎规划审批人的增补与移除，以防止审批范围出现漏洞。

审查流程规范化后，请配置针对同意请求的电子邮件通知和过期设置。这些设置可在有新的请求提出或请求即将过期时，向审批人发出提醒。提交请求的用户会在其请求被批准、拒绝或阻止时收到通知。定义失效期，可防止过时请求无限期地滞留系统中。

名称: 未配置应用程序的管理员同意工作流

代码名称: ADMIN-CONSENT-WORKFLOW-FOR-APPLICATIONS-NOT-CONFIGURED

严重性: Medium

类型: Microsoft Entra ID Indicator of Exposure