当 MFA 不足以应对时

云安全的第一条准则是：“任何时候都必须使用 MFA。”为什么？因为当您迁移到公有云计算时，实际上是把所有管理界面整合到单一门户或 API 中，然后……将其置于互联网上，仅以用户名、密码以及（或许有的）MFA 加以保护。即便您使用联合身份验证也是如此。

但事实证明，即使是 MFA 也并非总是足够，正如 多起重大数据泄露事件，其中包括发生在 Uber 的事件。

这是云环境与传统基础设施之间最关键的差异之一，也是您不断听到“身份即新边界”这一说法的原因。在云出现之前，我们在私有网络内部（或通过 VPN、跳板机等受控访问点）管理数据中心。而在云中，所有这些默认都暴露在互联网上，很难加以封锁，尤其是在我们如今越来越多地支持远程员工和管理员的情况下。

MFA 是保护用户/管理员身份验证的有效方式。我们有大量选择，从安全性略高的方式（基于消息的 MFA）到安全性极高的方式（硬件密钥）。但即便使用 MFA，问题依然在于用户拥有持久的访问权限和持久的权限级别。如果您为用户分配了某个角色，他们在通过身份验证之后随时都可以使用这些权限。攻击者深知这一点，并已开发出一系列获取已验证访问权限的技术。他们会：

• 滥用静态凭据，尤其是在未使用 MFA 的情况下。
• 突破某些 MFA。例如，他们通过 SIM 卡交换来拦截发往手机的短信。
• 通过社会工程手段诱使管理员禁用 MFA，或将其重置到攻击者控制的设备上。
• 通过社会工程手段诱使用户交出 MFA 验证码。
• 在用户完成身份验证后，从其系统中窃取会话凭据，再从攻击者控制的系统上加以使用。

攻击者一旦获得访问权限，便会开始探查各项权限，并最终利用这些权限从事恶意活动。

最小权限是一个谎言

核心问题在于，我们授予权限的依据并非某人在某一时刻需要做什么，而是其将来可能需要做什么。 用户，尤其是管理员，拥有涵盖所有可能操作的最大权限集合。 全球每一项安全标准都要求 IAM 应默认拒绝并遵循最小权限原则，但这在某种程度上是一个谎言，因为 所谓“最小权限”的集合，是由他们在某个时访问，而不是始终可访问。

即使允许用户切换角色、在不同会话中使用不同权限，他们几乎仍然可以随时使用这些角色。实际上，最小权限不仅应与用户绑定，还应与时间绑定。长期以来，我们通过分配角色来管理权限，而角色在一定范围内拥有权限。“您是这 5 个账户的管理员，是其他 98 个账户的普通用户。”我们甚至常常为一个用户分配多个角色；这些角色要么合并权限，要么让用户在执行不同任务时切换角色。

试想一下，如果我们消除持久性权限，攻击者的难度会增加多少。用户通过身份验证后不再获得其全部权限，而是仅获得极小的一组权限，任何具有潜在危害的操作都必须申请提权。

通过动态授权增强安全性

我并不是主张取消 MFA 或其他身份验证层面的安全措施。这些措施依然至关重要，但有时并不足够。在云安全领域尤其如此，因为云天然面临更大程度的互联网暴露。不过云也有其优势，其中包括基于会话的联合身份验证和细粒度授权（可细化到单个 API 调用）。

我们不再为用户提供其可能需要的所有权限的持久访问，而是给予更受限的访问权限，再由他们申请提升权限。这并非新概念；特权用户管理产品多年来一直采用这种方式。但这些产品往往仍依赖代理会话、轮换临时密码等笨拙的技术手段。云本身更为灵活，因为原生 IAM 模型天生基于会话，且权限在策略文档中定义（通常以 JSON 编写）。

我们的 FireMon Authorization Control 等工具正是这样运作的。您也可以看看开源示例 Netflix ConsoleMe。用户在需要时提出访问申请，平台随后依据策略判定审批所需的条件。当这些条件得到满足（例如获得经理或同事的签核）后，用户即被授权在一个会话中使用某个角色。平台甚至可以插入附加条件，例如“仅允许来自发起申请的 IP 地址的该会话”。这类申请通常通过带外方式提出，并使用 ChatOps 等旁路渠道进行审批，使流程刻意变得“高调”，对敏感的生产环境访问尤其如此。

授权层面的安全实际上让每个人的工作都更轻松，从开发人员、用户到安全管理员皆是如此。您无需提前掌握全部可能需要的权限。相反，用户在需要时申请所需权限。策略会确定在不损害安全性的前提下提供该访问权限的最低摩擦路径。借助 ChatOps 之类的工具，开发人员可以申请访问一个新账户并在数秒内得到答复，而不必向工单系统提交申请、等待数天甚至数周。

通过为授权环节增加安全防护，我们降低了凭据被盗和身份验证被攻破的影响，同时减少了摩擦和管理开销。