AuthN/AuthZ 鸿沟的影响

“身份即新边界”在云环境中已成为共识。这句话很漂亮，很容易放进演示文稿或文章中，但要把它转化为可落地的指导就没那么容易了。今天，我只想聚焦云 IAM 的一个方面，我称之为“AuthN/AuthZ 鸿沟”。实际上，只要使用联合身份验证，这个问题就会存在，但在云中风险更高，因为云管理平面始终面向互联网。

首先，简要说明 AuthN 与 AuthZ 的区别：

• AuthN 即身份验证。即证明您是某个实体的行为。对于我们普通人而言，通常是用户名、密码，可能还有 MFA。
• AuthZ 即授权。即判断某项操作是否被允许的行为。对于 IaaS 云而言，这几乎总是对应到一次 API 调用，即便您使用的是 Web 控制台/门户。

身份验证与授权是不同的任务，流程也不同。当我们登录某个网站时，我们完成身份验证，这通常会创建一个会话。我们不必每次点击都重新输入凭据，浏览器只会发送一个在一定时间内有效的令牌。而授权通常在我们每次尝试执行操作时都会被检查，以确认我们拥有相应权限。

仔细想想，一旦获得了该会话令牌，除非代码中有某种机制强制重新检查，否则它不会被再次校验。您的身份验证在整个会话期间有效，因此您可以执行授权范围内的任何操作。视平台/系统而定，即使这些临时凭据已被吊销，或账户已被彻底删除，它们仍可能继续有效。这就是 AuthN/AuthZ 鸿沟。

在讲授云事件响应课程时，我会在这个话题上花费大量时间，因为我发现即便是经验丰富的安全响应人员也未必总能理解其影响。设想云凭据被盗的情形：您吊销或删除了凭据，但攻击者持有一个仍然活跃的会话，仍有可能执行已获授权的操作。这……很糟糕。

如何解决？

根据您使用这些凭据的方式，最简单的办法通常是更改授权。只需对该实体设置拒绝策略（或移除允许的操作），因为攻击者发起的每一次 API 调用都会对其进行评估。虽然这是最简单的选项，但并不总是最佳选择，因为它可能中断正在运行的任务（被盗凭据并不总是仅与用户相关联）。视您的云服务提供商的支持情况，其他可选方案包括：

• 添加条件限制，以约束 API 调用的来源 IP。
• 拒绝在特定日期/时间之前创建的所有会话。

相比在云服务提供商内部，联合身份验证接入云服务提供商时更容易遇到这一问题。我刚在 AWS 中做了一项测试：删除 IAM 用户后，活跃会话的访问权限很快就失效了。然而，从外部身份提供商联合接入时情况未必如此，甚至在 AWS 内部，某些服务在活跃会话期间也不会再次检查凭据（例如，在删除授予访问权限的角色之后，我的 Session Manager 会话仍然保持了大约 15 分钟以上）。

这并不是什么鲜为人知的重大漏洞，而是您在制定云安全控制措施和事件响应手册时需要牢记的一点。不同类型的凭据，无论是在不同云服务提供商之间还是在同一提供商内部，其生命周期都各不相同。您的身份提供商也是一个影响因素，此外还有您尝试吊销凭据的位置。例如，如果您在 Active Directory 中拥有一个用户，并将其联合接入 AWS，该用户在 AWS 中扮演某个角色并获取了该角色的会话凭据，那么您需要吊销或限制该已扮演角色的凭据，即便您已在 AD 中限制了该用户。在会话结束、需要重新验证身份之前，AWS 根本无从得知该用户来自 AD 的会话已不再有效。

在内部，我们改用了自己的 Authorization Control 工具，它支持通过 ChatOps 创建带有限制条件的会话，同时不会增加任何可能拖慢开发人员进度的摩擦。该工具尚未正式发布，如果您有兴趣在早期使用阶段进行试用，请直接发送邮件至 rich.mogull@firemon.com。