LabHub
学习 学习路径 课程

云的基本功

「云会替你搞定」到此为止的那个点

在 LabHub 中继续学习

一句话总结

云服务商负责云基础设施本身的安全(security of the cloud), 我们负责部署在云上的内容安全(security in the cloud)。 大多数事故都发生在误解这条边界的位置。

概念图: S3 存储桶被配置为公开访问 · 数据和访问权限 · 主动启用 · 退款标准

为什么需要它

查看新闻中所谓“在 AWS 上发生客户数据泄露”的事故,几乎全都是因为 S3 存储桶被配置为公开访问。AWS 并没有被攻破,作出这种配置的是客户。

相反,虚拟机监控器漏洞或数据中心的物理入侵属于我们无法干预的领域, 这部分应由服务商负责。

不了解边界时,会在两个方向上犯错——重复完成本应由服务商负责的工作 (造成浪费),或者相信服务商会替我们完成本应由自己负责的工作(导致事故)。

它如何运作

边界会随着服务模型移动

        IaaS(EC2)      PaaS(RDS)       SaaS(Workspaces)
데이터        고객           고객              고객      ← 항상 고객
접근 권한     고객           고객              고객      ← 항상 고객
애플리케이션  고객           고객            사업자
런타임        고객           사업자          사업자
OS 패치       고객           사업자          사업자
하이퍼바이저  사업자         사업자          사업자
물리          사업자         사업자          사업자

最上面的两行——数据和访问权限——无论采用哪种模型,都由客户负责。 这正是“既然是托管服务就一定安全”无法成立的原因。即使使用 RDS,如果把 密码设为 admin/admin,事故责任仍然在我们。

五种常见误解

误解 实际情况
“既然是托管服务,备份也会自动处理” 自动备份通常需要主动启用,保留期限也由我们决定
“默认就会加密” 静态加密常常只是可选项,传输加密则必须由应用强制执行
“补丁由服务商负责” IaaS 的操作系统补丁由客户负责;即使是托管服务,维护窗口也由我们决定
“删除后就会消失” 数据仍可能留在快照、副本和日志中;备份保留期就是删除延迟
“保证 99.99% 可用性” SLA 是退款标准,不是零故障承诺

最后一行尤其重要。SLA 99.99% 表示“每年约 52 分钟以内的中断仍属正常范围, 超过后退还部分费用额度”。我们的服务是否能够承受这 52 分钟,必须由我们自行设计。

因此,我们必须完成的工作

  1. 访问权限——谁可以做什么。这是下一门课程的主题。
  2. 数据分类与加密——确定哪些数据敏感,并优先加密这些数据。
  3. 备份与恢复演练——启用备份和真正能够恢复是两回事。
  4. 配置监控——自动发现公开存储桶和开放的安全组。
  5. 日志保留——事故发生时用于调查的材料,服务商不会自动替我们保留。

不同服务类型具有不同边界

“共同责任”只有一句话,但实际边界会因服务而异。

我负责的内容 服务商负责的内容
IaaS (EC2) 操作系统补丁、防火墙、应用程序、数据 虚拟机监控器、物理安全、网络
PaaS (RDS) 模式、账号、参数、备份策略 操作系统与引擎补丁、硬件
SaaS (S3) 权限、加密选择、生命周期 其他所有部分
无服务器 (Lambda) 代码、依赖项、权限 运行时、扩缩容、补丁

越向上层移动,我们负责的内容越少,但数据和权限在任何层级都仍由我们负责。 现实中的大多数事故都来自这两项。

真实事故原因排名

排名 原因 由谁负责
1 错误的权限配置(公开存储桶、过大的 IAM 权限) 我方
2 凭据泄露(git 提交、日志) 我方
3 未修补的应用依赖项 我方
4 没有备份或从未验证恢复 我方
5 服务商故障 服务商(但影响仍由我们承受)

**因云服务商自身缺陷造成数据泄露的情况很少。**绝大多数问题都来自配置。 因此,“因为在云上所以安全”是一句危险的话——云只替我们完成了过去工作中的一部分, 同时还会增加新的工作(权限设计、凭据管理)。

第五类问题同样必须防范

即使属于服务商责任,我们也不能袖手旁观。发生故障时,用户会向我们投诉。

最后一点会直接影响设计。若要提高可用性,减少串行依赖通常比单独提升每个组件 更有效。

生产现场中的表现

下一步内容

接下来将了解服务模型(IaaS/PaaS/SaaS)具体如何移动这条责任边界。