LabHub
学习 学习路径 课程

云权限设计

四条事故路径,以及各自的阻断线

在 LabHub 中继续学习

一句话总结

云安全事故大多不是来自**复杂攻击,而是从我们自己敞开的门进入。**常见路径只有几种, 每条路径对应的阻断线也很明确。

本文内容用于防御。针对每条路径,都会配对说明“哪里出了问题, 以及用什么手段阻止”。

概念图: 复杂攻击,而是从我们自己敞开的门进入。 · 如何发生 · 阻断线 · 几分钟内

为什么需要它

不同云产品的事故看起来各不相同,但最终都会汇聚到公开配置、凭据泄露、权限过大、 滥用元数据服务等少数路径。只有了解每条路径的第一道阻断线,以及事故发生后保存证据的顺序, 才能防止一次配置错误升级为整个组织遭到入侵。

它如何运作

路径 1——公开存储

这是最常见的情况:把存储桶设置为公开访问,随后忘记恢复。

如何发生——为了临时共享文件而开放权限,之后没有撤销; 或者在配置静态网站托管时,误把全部内容改为公开。

阻断线

路径 2——凭据泄露

如何发生——提交到仓库、输出到 CI 日志、出现在截图或聊天中。 上传到公共仓库的密钥会在几分钟内被发现。

阻断线

最后一项的实际效果出乎意料地大。它无法阻止事故,却能让我们在数小时内发现问题。

路径 3——滥用过大的权限

如何发生——内部人员误操作,或被攻陷的账号直接使用其宽泛权限。 拥有 s3:* 的主体一旦被攻陷,攻击者甚至可以删除数据。

阻断线

如果被攻陷的账号连备份都能删除,那就不能算备份。只有跨越账号边界保存, 备份才能在勒索事件中存活。

路径 4——滥用元数据服务(SSRF)

如何发生——应用提供“输入 URL 后由服务器请求该地址”的功能,例如抓取图片; 攻击者传入实例元数据地址,于是实例的临时凭据会出现在响应中。

阻断线

事故发生后的顺序

  1. 确定范围——哪些凭据和资源受到影响
  2. 实施阻断——废止密钥、修改角色信任策略、使会话失效
  3. 保全证据——先保存日志和快照;一旦删除,调查就会终止
  4. 展开调查——根据审计日志还原攻击者执行操作的时间线
  5. 防止复发——增加护栏,确保相同路径不会再次开放

第 2 步中经常遗漏的是已经签发的临时凭据。即使修改角色策略,已签发的会话也可能 在过期前继续有效,因此必须另行执行会话失效操作。

日常应提前完成的五件事

  1. 启用审计日志,并保存在另一个账号
  2. 为根账号启用 MFA,并避免日常使用
  3. 设置预算告警——它是用于发现挖矿型用量激增的辅助检测线
  4. 在账号级启用阻止公开访问
  5. 把备份放在另一个账号中

让权限收窄工作真正运转起来

所有人都同意最小权限原则,但它往往无法落实。因为**一旦收窄权限导致系统停止, 执行这项工作的人就会受到指责。**因此,应当反转顺序:先测量,再收窄。

以实际使用的权限为依据。每个云平台都提供分析访问记录的工具,可以列出“过去 90 天中该角色实际调用过的 API”。这种方式比人工想象并编写策略更准确,更重要的是, 它能让我们提前知道哪些功能可能受影响。

**不要一次性阻断,先只记录警告。**把策略分成两份,实际执行阻断的策略暂时保持不变, 而收窄后的策略只记录“该请求在新策略下会被拒绝”。观察数日,等记录不再出现后再正式切换。

消除长寿命密钥,比逐项调整策略更有效。大多数泄露事故并不是因为策略过宽, 而是因为某处保存了一把访问密钥。让人员改用 SSO,让工作负载改用角色委托或 OIDC 联合, 可以从根本上消除可供窃取的密钥。CI 连接云平台的场景尤其如此。

**对剩余密钥强制设置过期。**不要依靠清单人工管理哪些密钥在用、哪些已经停用, 而应让密钥在 90 天后自动禁用。依赖人员自觉的控制措施,必然会在繁忙季度失效。

**设置一道权限边界,可以限制误操作的影响范围。**允许开发者创建角色,但预先规定 这些角色能够拥有的权限上限。这样既能阻止自行扩大权限的路径,又无需在日常工作中 不断请求他人操作。请求和审批越少,规则就越容易真正执行。

**最后是记录。**把审计日志单独发送到只写存储,并由另一个账号控制谁可以删除该存储。 攻击者在入侵后首先会尝试删除日志,因此,日志是否仍然存在,决定了事故是否还能调查。

生产现场中的表现

下一门课程

下一门课程学习网络。权限决定“谁”,网络则决定“从哪里”。