兄弟们，做云运维和安全，平时最怕接到的电话就是"咱们数据是不是泄露了"或者"云账单怎么突然爆了"。很多时候，这些问题不是因为黑客技术多牛，而是咱们自己的云资源误配置留下的后门。
今天不讲故事，直接上干货。复盘云上安全配置审计与修复的实战SOP，全是现场拿血泪换来的经验。
🚨 审计与修复"五不要"红线（保命必看）：
- 不要一把梭把所有"不安全"配置都改了：你以为是高危漏洞，直接收紧安全组，结果把核心业务的对外接口给断了，直接造成生产事故。
- 不要只看控制台不看实际流量就改安全组：控制台看着没流量，可能是长连接或者底层心跳，直接删规则会导致业务静默失败。
- 不要改完配置不验证、不准备回滚：改完不测试等于盲改，没留快照和备份，改挂了连怎么退回来都不知道。
- 不要只查不记：审计结果不留档、不建单，等于白查，下个月换个实习生来还得重新查一遍。
- 不要临时改完忘了收：排查问题时临时开放的22端口、临时给的OSS公开读，事后忘了关，直接变成永久后门。
处置总原则就一句话："先盘点资产，再分级审计；先验证影响，再动手改；改完必须验证+留回滚"。
一、 正确开局：先盘资产，别急着改
遇到安全告警或例行审计，第一件事是盘资产，确认你的"地盘"有多大。
- 摸清家底：确认有多少个云账号、多少个地域（Region）、多少个VPC。核心业务跑在哪些ECS、RDS、OSS、Redis上？绑了哪些安全组和SLB？
- 定优先级 ：别眉毛胡子一把抓。优先级排序：互联网暴露面优先 > 核心业务优先 > 有历史故障/告警的优先。
- 分层收敛 ：按 "网络层 → 存储层 → 身份权限层 → 数据层" 逐层往下查。
- 风险分级 ：
- 高危：公网放开高危端口（22/3306/6379等）、OSS公开读写、AK权限过大（AdministratorAccess）。
- 中危：安全组规则冗余、云产品日志未开、数据库备份策略不合理。
- 低危：资源命名不规范、标签（Tag）缺失。
二、 排查主链路：命令与现象对照
排查时，手里要有武器。以下提供基于阿里云CLI（结合jq）和通用Shell的排查命令，直接复制使用：
1. 网络层：安全组与VPC审计
bash
# 查所有安全组中，放通了 0.0.0.0/0 的规则（重点看高危端口）
for sg in $(aliyun ecs DescribeSecurityGroups --RegionId cn-hangzhou | jq -r '.SecurityGroups.SecurityGroup[].SecurityGroupId'); do
aliyun ecs DescribeSecurityGroupAttribute --SecurityGroupId $sg | \
jq -r '.Permissions.Permission[] | select(.SourceCidrIp=="0.0.0.0/0" and (.PortRange | test("22|3306|6379|27017|3389"))) | "\($sg) \(.PortRange) \(.IpProtocol)"'
done
# 查孤儿安全组（关联实例数为0，可能是废弃资源）
aliyun ecs DescribeSecurityGroups --RegionId cn-hangzhou | \
jq -r '.SecurityGroups.SecurityGroup[] | select(.EcsCount==0) | .SecurityGroupId'
# 现象对应：
# - 查出 0.0.0.0/0 放开 6379/3306：极度高危，Redis/MySQL直接裸奔在公网，随时被勒索。
# - 查出孤儿安全组：规则冗余，增加管理成本，可能隐藏了未清理的测试资源。2. 存储层：OSS/对象存储审计
bash
# 查所有Bucket的ACL权限（找公开读写）
aliyun oss ls | awk '{print $3}' | while read bucket; do
acl=$(aliyun oss stat oss://$bucket | grep ACL | awk '{print $2}')
if [[ "$acl" == *"public-read-write"* || "$acl" == *"public-read"* ]]; then
echo "高危: $bucket 权限为 $acl"
fi
done
# 查Bucket Policy是否过宽（允许所有人执行所有操作）
aliyun oss bucket-policy get oss://your-bucket-name
# 现象对应：
# - Bucket列表里有 public-read-write：任何人都能上传恶意文件或删你的数据。
# - 未开启访问日志：出事后无法追溯是谁下载了敏感文件。3. 身份权限层：RAM/身份审计
bash
# 查所有RAM用户的AK，并检查最后使用时间
for user in $(aliyun ram ListUsers | jq -r '.Users.User[].UserName'); do
aliyun ram ListAccessKeys --UserName $user | \
jq -r '.AccessKeys.AccessKey[] | "\($user) \(.AccessKeyId) \(.Status) \(.CreateDate)"'
done
# 查哪些用户/角色挂了 AdministratorAccess（最高权限）
aliyun ram ListPoliciesForUser | jq -r '.Policies.Policy[] | select(.PolicyName=="AdministratorAccess")'
# 现象对应：
# - 某个AK半年没使用但状态还是 Active：疑似泄露或废弃代码残留，极易被拖库。
# - 普通运维人员挂了 AdministratorAccess：权限过于粗放，一旦该人员账号被盗，整个云环境沦陷。4. 数据层：RDS/数据库审计
bash
# 查RDS实例是否分配了公网IP
aliyun rds DescribeDBInstanceNetType --DBInstanceId rm-xxx
# 或者直接看实例列表的 ConnectionString 是否包含 public
# 查RDS白名单是否设置了 0.0.0.0/0
aliyun rds DescribeSecurityIps --DBInstanceId rm-xxx
# 现象对应：
# - RDS有公网连接地址，且白名单是 0.0.0.0/0：数据库直接暴露，等同于送人头。三、 高频现场逐个拆
1. 安全组 0.0.0.0/0 放开高危端口
- 现象：安全组里 22 或 3306 对公网开放。
- 操作 ：先别急着删！查 VPC 流日志（FlowLog）或者在 ECS 上跑
netstat -anp | grep :22，看看到底有没有外部 IP 在连。 - 处理 ：如果确认是堡垒机或特定办公网IP，把
0.0.0.0/0收敛为具体的 IP 段；如果是历史遗留没人用的，先加一条"拒绝"规则观察一天，没报错再彻底删除。
2. OSS Bucket 公开读写
- 现象：Bucket ACL 是 public-read-write。
- 操作：查 OSS 访问日志，看最近有没有异常的大流量下载或奇怪的上传记录。确认业务代码里有没有外部 H5 页面直接依赖这个 Bucket 上传文件。
- 处理 ：如果是纯内部存储，直接改为
private；如果是外部 H5 需要直传，千万别给 public-read-write，改用 STS 临时凭证 或 服务端签名直传 收口。
3. RAM 用户权限过大 (AdministratorAccess)
- 现象：开发人员或自动化脚本账号拥有全局管理员权限。
- 操作：查 ActionTrail（操作审计），看这个账号最近 7 天到底调用了哪些 API。
- 处理：剥离 AdministratorAccess，根据实际调用的 API，自定义一套最小权限策略（如只允许操作特定的 ECS 和 OSS）。
4. AK 长期未使用或疑似泄露
- 现象：代码仓库里扫出了 AK，或者某个 AK 半年没登录过。
- 操作 ：在控制台先点 "禁用"（Disable），千万别直接"删除"。观察业务有没有报错。
- 处理：禁用后 3 天无报错，说明是废弃 AK，直接删除；如果业务报错，说明是核心链路在用，赶紧通知研发替换为新 AK，然后再删旧的。
5. RDS/Redis 公网暴露
- 现象：数据库有公网地址，或者白名单放了全网。
- 操作：确认业务应用是不是都在同 VPC 内。如果是，公网地址纯属多余。
- 处理 ：在 RDS 控制台"释放公网连接"；把白名单从
0.0.0.0/0改为业务 ECS 的内网 IP 或所属安全组。
6. 安全组规则冗余冲突
- 现象：一个安全组里有几百条规则，甚至有互相冲突的（前面允许，后面拒绝）。
- 操作：导出安全组规则，用脚本或 Excel 去重。
- 处理：合并同类项（如把连续的单个 IP 聚合成 CIDR 段）。清理时遵循"先加新规则，再删老规则"的原则，避免业务闪断。
7. 云产品日志未开启
- 现象：OSS 没开日志，RDS 没开 SQL 审计，SLB 没开访问日志。
- 操作：去各产品控制台，找到"日志管理"或"审计"模块。
- 处理：一键开启，并配置投递到 SLS（日志服务）或 OSS。注意评估日志存储成本，设置合理的保留天数（如 30 天或 180 天）。
8. 临时配置忘了收
- 现象：排查故障时临时开的端口、临时提权的 RAM 角色，事后没人管。
- 操作：建立"临时变更台账"。
- 处理：设置定时任务或日历提醒，故障恢复后 24 小时内必须复核并回收临时权限。
四、 修复与变更：分场景给策略
改配置不是点一下鼠标那么简单，必须分场景：
- 直接改（风险低） ：
- 场景：确认无人使用的废弃资源、明显的拼写错误、关闭无人访问的公网端口。
- 策略：改之前导出原配置（快照/备份），改完立刻验证。
- 灰度改（风险中） ：
- 场景：收紧安全组规则、修改 RAM 权限策略。
- 策略：先改一台测试节点或一个非核心业务，观察 1 小时。没问题再全量推开。
- 先观察再改（风险高） ：
- 场景：清理看似冗余的安全组规则、下线疑似泄露的 AK。
- 策略：先开启"观察模式"（如安全组加 Deny 规则但不生效，或 AK 设为禁用），跑几天看监控和日志，确认无影响再真删。
核心忠告 ：什么时候用云安全中心/CSPM工具自动化扫描？用来做全面盘点和基线核查 。什么时候必须手工查？涉及复杂业务上下文时（比如这个 OSS 到底是不是给外部合作伙伴用的），工具扫不出来，必须人工确认。
五、 根因分析：配置为什么会乱？
别总怪黑客，配置乱的根因 99% 在内部管理：
- 没有云配置基线标准：建资源时没模板，大家各凭喜好配。
- 多人操作无审批无记录：谁都能登控制台改配置，改错了找不到人。
- 业务迭代快，临时配置忘了收：为了赶进度，"先开个公网 IP 调通再说"，事后就忘了。
- 缺乏自动化审计：全靠人肉每个月去控制台点，查了这边漏那边。
- 权限给得粗放：图省事，直接给开发发 AdministratorAccess。
- 资产不清：连自己有多少个账号、多少个 Region 都不知道，漏查是必然的。
怎么定责？
拉出 ActionTrail（操作审计日志），结合资源创建时间、配置修改时间，看是谁在什么时间、从哪个 IP 改了配置。数据说话，一锤定音。
六、 事后加固：擦屁股的艺术
- 建立云配置基线：制定安全组、OSS、RAM、RDS 的安全标准文档（如：数据库严禁公网、AK 必须 90 天轮转）。
- 变更管控：配置变更必须走审批，核心配置修改必须双人复核，必须带回滚方案。
- 定期自动化审计：接入云安全中心、CSPM 工具，或者用开源的 Prowler/ScoutSuite，每周自动跑一次扫描。
- 暴露面定期盘点：每月输出一份《互联网暴露面资产清单》，重点盯 EIP、SLB、公网 RDS。
- AK/RAM 定期 Review：每季度强制清理一次长期未使用的 AK 和离职人员账号。
- 审计结果接工单闭环：扫描出的问题，直接生成工单派发给资源 Owner，限期修复，超时升级。
- 新资源强制套基线：通过 IaC（如 Terraform）或云原生编排工具，新建资源时强制套用安全模板。
七、 总结：高频踩坑血泪教训
最后，盘点几个审计修复时无数人踩过的坑：
- 一把梭改配置把业务改挂：看到安全组有冗余规则，直接批量删，结果把底层心跳包给拦了，集群脑裂。
- 只查不改不了了之：审计出了一堆高危，写在 PPT 里汇报完就扔抽屉里了，下次黑客还是从这儿进。
- 改完不验证不回滚：改完 RAM 权限直接下班，结果半夜自动化脚本全报错。
- 临时配置忘了收成永久后门：排查问题时开的 3389 远程桌面，半年后还在公网上敞开着。
- 只看控制台不看实际流量就改安全组：控制台看连接数是 0，其实是长连接没断，一删规则业务直接超时。
- 审计完不留档导致下次重复查：没有台账，换个运维来，又得花三天重新盘一遍资产。
- 缺乏自动化全靠人肉：几百个安全组用眼睛看，查了三天三夜，最后发现还是漏了十几个。
- 权限给得粗放图省事：给外包人员发主账号 AK，外包走后 AK 还在跑，直接被拿去挖矿。
云上安全，三分靠技术，七分靠管理。配置审计不是一次性的运动，而是持续的运营。希望这篇实战复盘，能帮大家在面对云资源误配置时，做到心中有数，手中有招，少背点锅。
如果你觉得这篇文章有用，或者你在云上安全审计时遇到过什么奇葩坑，欢迎在评论区留言交流！
觉得干货不错，别忘了点个赞、收藏一下，以备不时之需（毕竟写审计报告和排查配置时，你可能只想直接复制命令）！我们下期见！