云安全

这一课你将能做到

1. 说清云共享责任模型（IaaS/PaaS/SaaS 各自谁负责什么），并判断任意一个组件归谁管
2. 识别云环境的三大经典翻车场景（公开存储桶、过宽 IAM、元数据接口 SSRF），并给出修复配置
3. 用 CSPM 思路给本站云资源做一次配置审计：安全组、IAM 策略、日志、加密

为什么要学

上云没有消灭安全问题，只是换了个形态。物理机时代担心「机房门没锁」，云时代担心「安全组开了 0.0.0.0/0」——后者更危险，因为一次点击就全网可达。Verizon、Capital One 的云泄露事件，根因都不是高深 0day，而是配置错误。

人话：云厂商把数据中心、宿主机、网络设备管好了，但「你怎么用」全是你自己的锅。统计显示云安全事故 95% 以上源自客户侧配置错误。CSPM（云安全态势管理）就是专门持续检查「你有没有配错」的工具类别。

先建立图像

共享责任模型：

                 IaaS(ECS)      PaaS(RDS)      SaaS(钉钉)
数据             你             你             你
应用             你             你             厂商
运行时/中间件     你             厂商           厂商
操作系统         你             厂商           厂商
虚拟化/宿主机     厂商           厂商           厂商
物理网络/机房     厂商           厂商           厂商

一句话：越往 IaaS，你的责任越大；但「数据和你的配置」永远是你的责任。

三大经典云翻车：

① 存储桶公开: 对象存储(OSS/S3) ACL 设成 public-read
   → 任何人可下载全部文件，搜索引擎还会收录

② IAM 过大: 应用角色给 AdministratorAccess
   → 一个 SSRF/RCE 漏洞 = 整个云账号沦陷

③ 元数据 SSRF: ECS 的 169.254.169.254 元数据接口
   → 应用有 SSRF 漏洞 → 攻击者拿到临时凭证 → 横向移动

跟着做

步骤 1：审计安全组（最常见翻车点）

# 阿里云 CLI 查所有安全组规则里对全网开放的
aliyun ecs DescribeSecurityGroupAttribute \
  --SecurityGroupId sg-xxxx --Direction ingress

# 危险信号：SourceCidrIp = 0.0.0.0/0 且端口不是 80/443

正确基线（本站）：

安全组-nginx:   入站 80/443 对 0.0.0.0/0；22 仅办公网 IP
安全组-app:     入站 8080 仅来自安全组-nginx；不出站限制
安全组-mysql:   入站 3306 仅来自安全组-app
安全组-redis:   入站 6379 仅来自安全组-app

关键技巧：安全组规则引用另一个安全组而不是 IP 段——服务器扩容换 IP 时规则自动跟随。

步骤 2：IAM 最小权限改造

❌ 常见错法：应用用主账号 AccessKey，或角色挂 AdministratorAccess。

✅ 正确：每个应用一个角色，策略精确到资源和动作。本站「上传课程封面到 OSS」的最小策略：

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["oss:PutObject", "oss:GetObject"],
      "Resource": ["acs:oss:*:*:coderoadmap-covers/*"]
    }
  ]
}

注意三点：Action 不用 oss:*；Resource 精确到单个 bucket 前缀；没有 oss:DeleteObject（被攻破也不能删文件勒索）。

步骤 3：堵元数据 SSRF

云服务器都有元数据接口 http://169.254.169.254/，能拿到临时凭证。如果你的 Java 应用有「用户填 URL，服务端去抓取」的功能（比如抓取网页生成摘要），攻击者就填这个地址。