云安全

这一课你将能做到

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，服务端去抓取」的功能（比如抓取网页生成摘要），攻击者就填这个地址。

防御两层：

// 应用层：URL 白名单 + 内网地址黑名单
public void fetchUrl(String url) {
    URI uri = URI.create(url);
    String host = uri.getHost();
    InetAddress addr = InetAddress.getByName(host);
    // 拒绝内网、回环、链路本地(元数据)地址
    if (addr.isSiteLocalAddress() || addr.isLoopbackAddress()
            || addr.isLinkLocalAddress() || addr.isAnyLocalAddress()) {
        throw new SecurityException("禁止访问内网地址");
    }
    // 注意 DNS rebinding：解析后还要在连接层再校验一次
}

# 云平台层：开启元数据加固模式（阿里云/ AWS IMDSv2）
# 强制要求先 PUT 拿 token 才能读元数据，SSRF 无法伪造 PUT
aliyun ecs ModifyInstanceMetadataOptions --InstanceId i-xxxx \
  --HttpTokens required --HttpEndpoint enabled

步骤 4：开启操作审计和配置记录

必须开启的云服务（以阿里云为例）：
□ 操作审计 ActionTrail —— 记录所有 API 调用（谁在什么时间干了什么）
□ 配置审计 Config —— 资源变更历史 + 合规规则检查
□ OSS 访问日志 —— 谁在访问文件
□ VPC 流日志 —— 网络流量记录（入侵溯源用）

告警规则至少配：
- root/主账号登录 → 立即告警
- 安全组被改为 0.0.0.0/0 → 立即告警
- 出现创建 AccessKey 操作 → 告警
- 非工作时间登录控制台 → 告警

步骤 5：用 CSPM 工具自动巡检

开源方案（以 Prowler / 云厂商自带为例）：

# Prowler 扫 AWS；阿里云用「配置审计」内置规则包
# 核心检查项包括：
prowler aws --check s3_bucket_public_access        # 桶公开检查
prowler aws --check iam_no_root_access_key         # root 无 AccessKey
prowler aws --check ec2_securitygroup_allow_ingress_from_internet_to_any_port

云厂商托管版：阿里云「云安全中心」、AWS Security Hub——按 CIS 基线自动评分，每周出报告。原则：人工巡检会忘，自动巡检不会。

讲清楚要点

1. 共享责任模型是上云第一课：厂商管「云本身的安全」（机房、宿主机、虚拟化），你管「云上的安全」（配置、数据、IAM、应用）。用 PaaS 只是把 OS 层的责任转移给厂商，数据和应用配置永远是你的。

2. 云安全 = 配置安全：云上被攻破极少因为云厂商漏洞，几乎都是客户配置错——公开桶、0.0.0.0/0 安全组、过大 IAM、AccessKey 泄漏进 git。CSPM 存在的意义就是持续盯着配置。

3. AccessKey 是云上的核按钮：泄漏途径前三——硬编码进代码、写进镜像、前端 JS 里。对策：能用角色（RAM Role/实例角色）就不用 AK；必须用时放 KMS/Vault；CI 里加 gitleaks 扫云 AK 格式。

4. 元数据接口是云特有的攻击面：传统 IDC 没有「访问一个固定 IP 就能拿凭证」这种设计。所有「服务端发起 URL 请求」的功能（SSRF 面）都必须防它，并开启 IMDSv2/加固模式。

5. 多区域也要纳入安全视野：灾备区域的资源常常被遗忘——主区域安全组收紧了，灾备区域还开着 22 对全网。CSPM 巡检要覆盖所有 region。

你可能会懵的地方

• 云厂商自带安全中心够吗？ 基础检查够（端口暴露、弱密码、漏洞），但它不懂你的业务逻辑。它告诉你「安全组开了 3306」，不知道这是合理的主从复制还是错误暴露。自带工具做基线，业务规则自己加。

• AccessKey 和 RAM 角色选哪个？ 应用跑在 ECS 上：用实例 RAM 角色，零密钥。应用跑在 IDC/别家云：才不得不用 AK，此时用子账号 AK + 最小权限 + 定期轮换 + 禁主账号 AK。

• 配置漂移（Drift）是什么？ Terraform 里安全组是收紧的，但有人图省事在控制台手动开了一条规则，IaC 状态和实际状态漂移了。对策：Config/Config Rules 持续比对，或锁定控制台修改权限，一切变更走 IaC。

• OSS bucket 公开一定错吗？ 静态网站托管场景可以公开，但要：独立 bucket 只放公开资源、和存用户私有文件的 bucket 分开、开访问日志。用户头像这类「半公开」资源用签名 URL（带过期时间）而不是公开桶。

• 小团队有必要搞 CSPM 吗？ 有，且零成本起步：云厂商配置审计免费规则包 + ActionTrail 开启 + 三条核心告警，半天搞定。出一次公开桶事故的代价远超这个投入。

错法对照

错法	问题	正解
安全组 3306 对 0.0.0.0/0	全网爆破 MySQL	只放行应用安全组
应用用主账号 AK	泄漏=账号全沦陷	RAM 角色+最小策略
AK 写在代码/前端	git 泄漏被挖矿	实例角色或 KMS
桶 public-read 存用户文件	数据全泄漏	私有桶+签名 URL
不做操作审计	出事无法溯源	ActionTrail+日志留存 180 天
只盯主 region	灾备区成后门	CSPM 覆盖所有 region

卡点急救

1. 收紧安全组后服务不通了：按链路逐跳查——Nginx→App 查 app 安全组入站、App→MySQL 查 mysql 安全组入站是否引用了正确的源安全组。临时诊断可以开一条窄规则（仅自己办公 IP），确认后删掉，别留着。

2. RAM 角色不生效，应用报 AccessDenied：检查三件事——角色是否绑定到了正确的 ECS 实例、策略 Resource 的 ARN 格式是否精确（注意末尾 /* 和桶名本身的区别）、应用 SDK 是否用了 RoleCredential 而不是硬编码 AK。

3. 配置审计一堆「不合规」不知道哪些要紧：优先级排序——公开访问类（桶/安全组）最高危立即修；加密类（磁盘未加密、日志未加密）次之；打分类（密码策略、MFA）按合规要求排期。别被总量吓到，先清公开类。

面试常问

• 什么是云共享责任模型？ 云厂商负责「云本身的安全」：物理设施、宿主机、虚拟化层；客户负责「云上的安全」：数据、身份权限、网络配置、应用。IaaS 客户责任最大（含 OS 补丁），PaaS 厂商管到运行时，SaaS 厂商管到应用层。但无论哪种模式，数据和访问权限的责任永远在客户。

• 云上最常见的安全事故类型？ 配置错误居首：公开的对象存储桶（数据泄露第一来源）、过宽安全组（数据库暴露公网）、IAM 权限过大+AccessKey 泄漏（挖矿/数据勒索）、SSRF 打元数据接口拿临时凭证横向移动。对策对应为：CSPM 持续巡检、最小权限、密钥管理、IMDSv2。

• CSPM 是什么？解决什么问题？ Cloud Security Posture Management，云安全态势管理。持续扫描云资源配置，对照 CIS 基线/合规标准发现错误配置（公开桶、过宽端口、未加密、无审计日志），并出修复建议甚至自动修复。解决的核心问题是：云资源配置项成百上千且分散在多人多区域，人工盯不住，配置漂移随时发生。

自测三问

1. 用 RDS（PaaS）时，OS 补丁和数据库账号权限分别归谁负责？
2. 为什么「应用部署在 ECS 上时」不应该使用 AccessKey？用什么替代？
3. 元数据接口 SSRF 的攻击链是什么？两层防御分别是什么？

小结一句话

云安全的本质是配置安全：共享责任划清边界，最小权限管住 IAM，CSPM 持续盯住配置漂移——云上 95% 的事故都是 preventable 的配置错误。

延伸

• CIS Benchmarks — 各云平台的配置基线标准
• 下一课：容器安全——镜像扫描、SBOM、K8s 安全上下文，以及为什么 latest 标签是供应链的敌人。