身份是新的边界

上一课划出了一条线,区分云服务商保护的部分和客户必须自己保护的部分。在客户这一侧,有一样东西比其他任何东西都更关键:身份——谁被允许登录,以及登录之后能做什么。传统的办公网络有一堵墙和一扇上锁的门;而云账户只有一个登录表单,地球上任何地方、任何时间都能访问到它。保护这个登录入口,基本上就是“云中的安全”在实践中的全部含义。

账户实际上是怎么被接管的

账户被接管的过程很少涉及攻击者攻破云服务商的系统。它通常遵循本大学威胁建模课程中讲过的凭证盗窃模式:一个从某个被入侵、且与此无关的服务那里重复使用的密码,或者一个足以以假乱真、直接索要登录信息的钓鱼页面。一旦攻击者拿到了有效的凭证,大多数云服务都没有办法把他们和真正的账户所有者区分开来——这正是为什么美国网络安全和基础设施安全局(CISA)把多因素验证(MFA)列为高于一切其他控制手段的唯一措施。

MFA,以及为什么不是所有形式都同样有效

CISA 明确指出,“开启 MFA 的用户被攻破的可能性显著更低”,因为仅凭一个被窃取的密码不再足够。但 CISA 同时也按抗钓鱼能力对现有的 MFA 形式进行了排名,这个排名很重要:“目前唯一被广泛使用的抗钓鱼验证方式是 FIDO/WebAuthn 验证”——这正是密钥(passkey)和硬件安全密钥背后的标准,在密码学课程中有详细介绍。用 CISA 的话说,短信验证码仍然远远好过完全没有第二重验证,但它可能被足够有决心的攻击者拦截或转发;基于应用的推送通知加数字匹配则介于两者之间。对于持有任何敏感内容的云账户来说,开启该账户所提供的最强 MFA 选项,是本课中价值最高的一步。

OAuth:你授予其他应用的权限

每次你点击“使用 Google 登录”,或者把一个日程安排工具连接到你的日历时,你用的都是 OAuth,该标准自己的文档把它描述为“行业标准的授权协议”。它有用的地方在于,第三方应用永远看不到你的密码——你直接向你的服务商登录,然后为该应用批准一组特定的、有限的权限,称为“作用域”(scope)。它的风险恰恰就在这次权限授予上:一个只需要读取你日历空闲/忙碌时间的日程安排应用,可能会索要——而且往往会照常获得——以你的身份读取和发送邮件的权限。每一个已连接的应用都是一次持续有效的访问授权,会一直存在,直到有人撤销它为止,这也是为什么本课程的最后一课会讲到定期检查这份清单,而不只是一次性设置正确就完事。

泄露的密钥:OAuth 那个不太起眼的表亲

自动化工具和集成服务往往用 API 密钥而不是人工登录来进行身份验证——一长串字符,作用和密码类似,但不是由人手动输入的,而且往往完全没有 MFA 保护。这些密钥暴露的频率比大多数人想象的要高:被粘贴进一份支持工单里、被不小心提交到代码仓库中、被留在一个分享范围超出预期的配置文件里。像对待密码一样谨慎地对待 API 密钥——绝不以明文分享它、在它可能已经泄露时轮换它、并限制它被允许做的事情——能补上 MFA(为人类登录而设计)所无法覆盖的这一块缺口。