云安全：IAM、安全组与数据保护

这一课你将能做到

1. 用最小权限原则编写 IAM 策略与安全组规则，说清「为什么这样开」
2. 加固对象存储：禁止公开列举、防遍历下载、密钥不落代码
3. 为 Spring Boot 平台设计云上的密钥管理与操作审计方案

为什么要学

如今大多数安全事故的入口不再是主机漏洞，而是云配置错误：对象存储桶公开可列举、AccessKey 提交进 Git、安全组开了 0.0.0.0/0 的 22 端口、IAM 用 *:* 一把梭。云厂商负责「云本身的安全」，而「云上的配置」责任在你——这个责任分界叫共享责任模型。

人话：云厂商把大楼建得很牢（机房、硬件、物理安全），但房间门锁没锁、钥匙给了谁，全是你的事。

先建立图像

┌─ 账号层 ── 主账号不用来做日常操作；子账号+MFA；RAM/STS 临时凭证
├─ 身份层 ── IAM 用户/角色/策略：谁(service/person) 能对什么(resource) 做什么(action)
├─ 网络层 ── VPC 划分 + 安全组(白名单) + 内网隔离；数据库不给公网 IP
├─ 数据层 ── 对象存储权限、静态加密、密钥托管(KMS)
└─ 审计层 ── 操作审计(CloudTrail/ActionTrail) + 告警规则

安全组 = 有状态的虚拟防火墙（按实例挂规则）；IAM = 决定「人/服务」能调哪些 API。两者是云安全的左右手。

跟着做

步骤 1：安全组最小开放（以 AWS CLI 为例，阿里云控制台同理）

# 错误示范：全开（很多人图省事这么干）
aws ec2 authorize-security-group-ingress --group-id sg-123 \
  --protocol tcp --port 22 --cidr 0.0.0.0/0     # ❌ 全网可爆破
# 正确：只放办公室/VPN 出口 IP
aws ec2 authorize-security-group-ingress --group-id sg-123 \
  --protocol tcp --port 22 --cidr 203.0.113.0/24  # ✅ 仅办公网段
# 数据库安全组：只允许来自应用安全组的流量（引用 sg-id 而非 IP）
aws ec2 authorize-security-group-ingress --group-id sg-db \
  --protocol tcp --port 3306 --source-group sg-app
# 自查：列出所有 0.0.0.0/0 规则
aws ec2 describe-security-groups \
  --query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]]].[GroupName,IpPermissions]'

步骤 2：IAM 最小权限策略

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::java-nav-avatars/*"
  }]
}

对比错误写法 "Action": "s3:*", "Resource": "*"：前者只读特定桶，泄露后攻击者最多看到头像；后者能删桶、能列举所有桶。原则：Action 最小、Resource 精确、Condition 补条件（如限定 IP 或 MFA）。

步骤 3：对象存储加固

# 检查桶是否公开可列举
curl https://java-nav-avatars.s3.amazonaws.com/?list-type=2
# 返回 ListBucketResult XML = 可列举 ❌ → 关闭公开访问
aws s3api put-public-access-block --bucket java-nav-avatars \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
# 静态资源走 CDN + 签名 URL，而不是开公开读

步骤 4：密钥不落代码

# ❌ 错误：application.yml 提交仓库
# access-key: AKIAIOSFODNN7EXAMPLE
# ✅ 正确：环境变量 / KMS / Vault 注入
cloud:
  aws:
    credentials:
      use-default-aws-credentials-chain: true   # 走实例角色，代码里零密钥

# ECS/EC2 场景首选：给实例绑 IAM Role，应用无感取凭证，可自动轮换
# 本地开发：SSO/环境变量，绝不写文件入库
git secrets --scan    # 提交前扫描意外入库的 AK/SK

步骤 5：操作审计与告警

# 开启 CloudTrail（AWS）或操作审计（阿里云），写入专用日志桶
aws cloudtrail create-trail --name java-nav-audit \
  --s3-bucket-name java-nav-audit-logs --is-multi-region-trail
# 高危动作告警示例：安全组变更、IAM 策略修改、AK 创建
# 用 EventBridge 规则匹配事件源 ec2:AuthorizeSecurityGroupIngress → SNS 通知

讲清楚要点

1. 共享责任模型：厂商管「of the cloud」（物理、宿主、虚拟化），你管「in the cloud」（系统加固、配置、数据、访问控制）。绝大多数云安全事件是配置层责任，不是厂商被打穿。
2. IAM 三要素：principal（谁）、resource（什么）、action（做什么）。写策略时先拒绝思考法——默认全拒绝，逐条允许；高危动作（删除、提权、密钥管理）单独拆策略便于审计。
3. 角色优于用户，临时凭证优于长期 AK：EC2/ECS 绑 Role 后应用自动取短期凭证并轮换；长期 AccessKey 是泄露事故的常客，能不用就不用。
4. 安全组按「引用」而非「地址」授权：DB 安全组放行 sg-app 而不是维护应用 IP 列表，扩缩容时规则自动跟随，也不会出现「为了省事开 0.0.0.0/0」。
5. 审计日志自身要保护：日志桶对业务账号只写不删（bucket policy 拒绝 delete），否则攻击者拿 AK 后第一件事是清审计。

你可能会懵的地方

• 安全组和网络 ACL 的区别？ 安全组有状态、按实例、只支持 allow；NACL 无状态、按子网、支持 allow/deny 且规则有序。一般架构安全组足够，需要子网级强制拒绝（如封特定恶意 IP 段）才上 NACL。

• 为什么强调实例角色而不是把 AK 放环境变量？ 环境变量会随崩溃日志、docker inspect、CI 日志泄露；角色凭证由元数据服务下发、短期自动轮换，代码里根本不存在密钥，泄露面几乎为零。

• 对象存储想让图片公开访问怎么办？ 桶保持私有，公开访问走 CDN + 签名 URL/OAC（源站访问控制）。直接开公开读不仅泄露风险，还会被刷流量直接烧钱。

• ** sts:AssumeRole 是干什么的？** 跨账号/临时授权机制：A 账号的策略允许 AssumeRole 到 B 账号的某角色，换取临时凭证。CI/CD、跨部门协作的标准做法，避免共享长期密钥。

• 云上的安全基线怎么快速自查？ 用厂商自带工具：AWS Security Hub / 阿里云安全中心基线检查，覆盖公开桶、弱安全组、未开审计、未开 MFA 等高频配置错误，先跑一遍再逐项修。

错法对照

错法	问题	正解
22/3389 开 0.0.0.0/0	全网爆破入口	白名单办公网段 + 跳板机
IAM 策略 Action: *	泄露即全权限	最小 Action + 精确 Resource
AK/SK 写 application.yml	Git 泄露成重大事故	实例角色 / KMS / 环境变量
对象存储开公开列举	数据被批量遍历下载	私有桶 + CDN 签名 URL
审计日志随业务一起可删	攻击者清痕	独立日志桶只写不删 + 告警

卡点急救

1. 应用报 AccessDenied 但策略看着有权限：检查 Resource ARN 是否精确到对象级（bucket/* 与 bucket 是两回事：前者对象操作，后者桶操作如 ListBucket）。
2. 绑了实例角色还是拿不到凭证：确认实例元数据服务可达（IMDSv2 需带 Token 请求头）、SDK 走了默认凭证链、没有残留的静态 AK 覆盖。
3. 误删安全组规则导致业务中断：恢复端口放行并复盘——变更走 IaC（Terraform）+ 变更审批，杜绝控制台随手改。

面试常问

• 解释云的共享责任模型。 厂商负责云本身（物理设施、硬件、虚拟化层），用户负责云上内容（OS 加固、应用安全、IAM 配置、数据加密）。IaaS/PaaS/SaaS 的分界线逐层上移，但配置错误始终是用户侧责任，也是云事故的主因。

• 如何设计一套云上 IAM 的最小权限实践？ 按角色拆分（应用只读桶、CI 只推镜像、运维带 MFA 管控台）；Resource 精确到 ARN；生产高危操作要求 MFA/审批；用实例角色替代静态 AK；定期用 IAM Access Analyzer 复核未使用的权限并回收。

• 对象存储数据泄露的常见原因与防护？ 原因：桶策略误开公开读、列举接口未关、AK 泄露后遍历。防护：公开访问块全开、CDN+签名 URL、静态加密 + KMS、审计告警异常大批量下载。

自测三问

1. 安全组放行流量时「引用安全组」比「写 IP」好在哪？
2. 为什么说实例角色比环境变量放 AK 安全？
3. 你的平台在云上，哪三类配置错误最容易让你出事？

小结一句话

云安全的主战场是配置而非漏洞：IAM 最小权限、安全组精确放行、密钥托管不落码、对象存储默认私有、审计日志独立只增——这五条守住，就避开了绝大多数云事故。

延伸

• AWS IAM 最佳实践
• 阿里云安全基线最佳实践
• 下一课：渗透测试方法论与 Burp Suite 实操。