制定应用程序权限策略

在你了解如何使用零信任原则进行开发时,请在查看获取访问资源的授权制定委托权限策略后参考本文。 使用 Microsoft 标识平台对应用程序进行身份验证和授权以及管理权限和同意时,定义凭据管理的应用程序权限方法。

不涉及用户时,你没有一个有效的权限模型,因为应用程序始终被授予其预分配的权限。

  • 应用证明它是请求权限的应用。 应用程序使用以下方法之一来证明自己的身份

  • 应用始终需要事先获得管理员同意。 应用程序使用 .default 范围请求此权限。 它请求管理员分配给应用程序的权限。

  • 跨用户功能。 默认情况下,User.ReadWrite.All 允许应用程序更新每个用户的配置文件。 作为一种应用程序权限,它允许应用程序读取和更新租户中每个用户的配置文件。

  • 授予应用的权限始终是使用的权限。委托的权限不同,应用程序权限不受任何特定用户可执行的操作约束。

限制应用程序权限

有三种方法将应用程序限制为非全局访问。

  • Microsoft Teams 应用具有特定于资源的许可 (RSC),允许应用程序访问特定团队,而不是访问企业中的所有团队。 RSC 是 Microsoft Teams 与 Microsoft Graph API 的集成,允许应用使用 API 终结点并管理特定资源。 其权限模型使 Teams 和聊天所有者能够同意应用程序访问和修改其 Teams 和聊天数据。

  • Microsoft Exchange 管理员可以创建 Exchange 应用程序策略,以使用 PowerShell 脚本限制应用对特定邮箱的访问权限。 它们可以将特定应用程序对特定邮箱的访问权限限制为 Calendar.ReadMail.Read。 例如,这允许你构建自动化,以便仅读取一个邮箱,或者仅从一个邮箱发送邮件,而不是从企业中的每个人发送邮件。

  • SharePoint 使用 Sites.Selected 作为特定范围,以允许使用应用程序访问 SharePoint 的粒度权限。 默认情况下,为应用程序选择 Sites.Selected 而不是其他权限之一会导致应用程序无法访问任何 SharePoint 网站集。 管理员使用站点权限终结点向应用程序授予读取、写入或读写权限。

管理应用程序凭据

凭据安全机制可以确保应用程序能够快速地从潜在的漏洞恢复。 以下最佳做法指导你开发应用程序,这些应用程序执行检测和修正,同时避免停机和影响合法用户。 这些建议支持在准备应对安全事件时的“假定漏洞”零信任原则

  • 从代码和配置中删除所有机密。 使用 Azure 平台时,在密钥保管库放置机密,并通过 Azure 资源托管标识访问它们。 如果发生泄露,使代码能够灵活处理机密轮换。 IT 管理员可以删除和轮换机密和证书,而无需关闭应用程序或影响合法用户。

  • 使用证书而非客户端密码,除非有安全进程来管理机密。 攻击者知道处理客户端密码往往不太安全,泄露的机密使用情况难以跟踪。如果被盗用,证书可得到更好的管理并可撤销。 使用机密时,为其生成或使用安全的无触摸部署和滚动更新流程。 使用机密时设定过期时间段(例如,一年、两年),避免设置为“永不过期”

  • 定期滚动更新证书和机密,以在应用程序中形成复原能力,并避免由于紧急滚动更新而中断。

后续步骤