减少过高权限和应用

作为旨在设计和实现遵循“零信任指导原则”的应用程序的开发人员，你希望以最低特权提高应用程序安全性。 你必须减少应用程序的受攻击面和安全漏洞的影响。

在本文中，你将了解应用程序为何不应请求超过其所需的权限。 你了解过高权限这个术语，并发现有关限制应用程序中的特权以管理访问权限并提高安全性的建议和最佳做法。

什么是过度授权？

当应用程序请求或接收的权限超过应用程序正常运行所需的权限时，将发生过度授权。 通过本文其余部分的未使用和可减少权限的示例，提高对过高权限的理解。

未使用的权限

对于此未使用的钥匙示例，假设有三扇锁门（蓝色、黄色和绿色），如下图所示。

你的资产在门后。 你有三把钥匙（蓝色、黄色、绿色），让你能打开相应的门。 例如，蓝色钥匙可以打开蓝色的门。 当你只需要进入黄色的门时，仅携带黄色钥匙。

为了最好地保护资产，只在需要时携带所需的钥匙，并将未使用的钥匙保存在安全的位置。

可缩小的权限

可减少钥匙示例比未使用的钥匙示例更为复杂，我们现在添加两个特殊钥匙，如下图所示。

第一把黑色钥匙是一把万能钥匙，可以打开所有门。 第二把黑色钥匙可以打开黄色和绿色的门。 当你只需要进入黄色的门时，仅携带第二把黑色钥匙。 你可以将万能钥匙和冗余的绿色钥匙保存在安全位置。

在 Microsoft 标识世界中，密钥代表访问权限。 你的资源和你（密钥持有者）都是应用程序。 如果你了解携带不必要密钥的风险，请注意应用程序具有不必要权限的风险。

权限差距和风险

门和钥匙如何帮助理解过度授权是如何发生的？ 为什么应用程序有权执行任务，但仍过度授权？ 让我们在下图中看看可能导致差异的权限差距。

X 轴表示时间，Y 轴表示权限。 在测量时间开始时，你请求并接收应用程序的权限。 随着业务随时间发展和变化，你添加了新的权限来支持你的需求，并且授予的权限斜率也在增加。 如果忘记删除不必要的权限（例如，如果应用程序未中断），那么使用的权限可能低于授予的权限，从而导致出现权限差距。

以下是 Microsoft 标识平台中有趣的观察结果。

• Microsoft Graph 中有超过 4,000 个 API。
• Microsoft 标识平台上提供超过 200 个 Microsoft Graph 权限。
• 开发人员有权访问广泛的数据，并且能够将粒度应用于其应用请求的权限。
• 在我们的调查中，我们发现应用在其场景中仅有 10% 的权限得到充分利用。

仔细考虑你的应用实际需要的权限。 请注意权限差距，并定期检查应用程序权限。

过度授权损害安全性

让我们通过示例，更深入地了解权限差距导致的风险。 这个存在风险场景包括两个角色：IT 管理员和开发人员。

• IT 管理员：Jeff 是租户管理员，负责确保 Microsoft Entra ID 中的应用程序可信且安全。 Jeff 的部分工作是向应用开发人员授予所需的权限。
• 开发人员：Kelly 是使用 Microsoft 标识平台并拥有应用的应用开发人员。 Kelly 的工作是确保应用程序具有执行所需任务的适当权限。

过高权限的以下常见安全漏洞情况通常分为四个阶段。

1. 首先，开发人员开始配置应用程序，并添加所需的权限。
2. 其次，IT 管理员审查所需权限并授予同意。
3. 第三，不良参与者开始破解用户凭据，并成功破解用户标识。
4. 如果用户拥有多个应用程序，程序会获得过高的特权。 不良参与者可以快速使用已授予权限的令牌，检索敏感数据。

特权过高的应用程序

当实体所请求或接收到的权限超出其需求时，实体将获得过高权限。 Microsoft 标识平台中对具有过高权限的应用程序的定义为“任何具有未使用或可减少权限的应用程序”。

让我们在实际示例中将 Microsoft Graph 用作 Microsoft 标识平台的一部分，以便更好地了解未使用的权限和可减少的权限。

当应用程序收到所需任务不需要的权限时，就会出现未使用的权限。 例如，生成日历应用时。 你的日历应用请求并接收 Files.ReadWrite.All 权限。 你的应用不与任何文件 API 集成。 因此，应用程序具有未使用的 Files.ReadWrite.All 权限。

可减少的权限更难以发现。 当应用程序收到较少的权限，但具有较低特权的替代方法，为所需任务提供足够的访问权限时，就会出现这种情况。 在日历应用的示例中，你的应用请求并接收 Files.ReadWrite.All 权限。 但是，它只需要从已登录用户的 OneDrive 读取文件，并且无需创建新文件或修改现有文件。 在这种情况下，应用程序仅部分利用 Files.ReadWrite.All，因此需要降级到 Files.Read.All。

用于减少过度授权场景的推荐

安全是一段旅程，而不是目的地。 安全生命周期分为三个不同的阶段：

• 防护
• 审核
• 修正

下图演示了减少过高权限场景的建议。

• “阻止”：生成应用程序时，应充分了解应用程序要进行的 API 调用所需的权限，并仅请求启用场景所需的权限。 Microsoft Graph 文档对所有终结点的最低特权权限到最高特权权限都有明确的参考。 在确定所需的权限时，请注意过度授权的场景。
• “审核”：你和 IT 管理员应定期检查现有应用程序以前授予的权限。
• “修正”：如果你或 IT 管理员注意到生态系统中过度授权的应用程序，则应停止请求过度授权权限的令牌。 IT 管理员应撤销授予的同意。 此步骤通常需要更改代码。

维护最低特权权限的最佳做法

对应用程序保持最低特权权限的两大动力是推动应用程序采用和阻止其扩散。

• 为客户构建一款值得信赖的应用程序，避免过多的权限请求，从而推动应用程序的采用。 将应用程序权限限制为仅完成其任务所需的权限。 这种做法可减少攻击的潜在影响范围，并增加客户对应用的采用。 在查看应用程序请求的权限，并决定是否授予应用权限时，请进行更多审查。
• 确保攻击者无法使用过度特权获取进一步访问权限，以此阻止传播。 如果创建的应用要求不必要的权限，那么它最不可能获得批准或会被完全拒绝。 控制损坏的最佳方式是防止攻击者获得提升的权限，以此扩大入侵范围。 例如，如果应用程序仅需要 User.ReadBasic.All 读取用户基本信息，即使应用遭到入侵，OneDrive、Outlook、Teams 和任何保密数据都是安全的。

后续步骤

• 获取访问资源的授权有助于了解在获取应用程序的资源访问权限时如何最好地确保零信任。
• 使用标识零信任方法生成应用概述了权限和访问的最佳做法。
• 自定义令牌介绍了可以在 Microsoft Entra 令牌中接收的信息。 它说明了如何自定义令牌以提高灵活性和控制度，同时提高最低特权下的应用程序零信任安全性。
• 在令牌中配置组声明和应用角色介绍了如何使用应用角色定义来配置应用，以及如何将安全组分配给应用角色。 这些方法有助于提高灵活性和控制度，同时提高最低特权下的应用程序零信任安全性。
• 在应用中实现零信任就绪情况：设计最低特权有助于使用 Microsoft 标识平台的最低特权访问原则来设计应用。
• 使用最低特权原则提高应用程序安全性帮助减少应用程序的攻击面，以及应在集成了 Microsoft 标识平台的应用程序中出现的安全漏洞的影响（冲击范围）。
• Graph 资源管理器和 Microsoft Graph 权限参考可帮助你选择 Microsoft Graph API 调用，以启用场景，并查找从最低权限到大多数特权的相应权限。