深色模式
云安全基线
摘要：云安全基线是一组「默认必须开启」的配置：审计日志、MFA、密钥托管、公共访问阻断、配置漂移检测。本文给出一份可勾选的基线清单，以及用开源工具自动巡检的方法。
适用环境
bash
# 需要云账号的安全审计只读权限
which jq python3
pip3 install --quiet checkov 2>/dev/null || echo "checkov 可自行安装"
# 主机侧基线检查工具可选
which lynis || echo "可选"1
2
3
4
5
2
3
4
5
操作步骤
一、基线清单（逐条勾选）
| 分类 | 基线项 | 为什么 |
|---|---|---|
| 账号 | 主账号开启 MFA、删除主账号 AK | 防止最高权限凭证泄露 |
| 账号 | 所有子账号开启 MFA | 防止弱口令撞库 |
| 账号 | AK 90 天内轮换，无 90 天以上未用凭证 | 缩小暴露窗口 |
| 审计 | 开启操作审计（CloudTrail / ActionTrail）并投递到独立账号 | 事后可追溯 |
| 审计 | 日志文件完整性校验 + 长期归档 | 防止攻击者删日志 |
| 网络 | 安全组不对 0.0.0.0/0 开放 22/3389/3306/6379 | 防止直接暴露 |
| 存储 | 所有桶阻断公共访问、默认开启服务端加密 | 防止数据泄露 |
| 主机 | 使用密钥登录，禁用密码登录 | 防止暴力破解 |
| 数据 | 数据库不分配公网 IP、开启备份 | 防止暴露与丢数据 |
二、开启操作审计并保护日志
bash
# 创建审计日志桶（独立账号更佳，这里简化为同账号）
aws s3api create-bucket --bucket my-audit-log-bucket --region ap-east-1 \
--create-bucket-configuration LocationConstraint=ap-east-1
# 开启审计跟踪，投递到对象存储并开启日志文件校验
aws cloudtrail create-trail --name org-trail \
--s3-bucket-name my-audit-log-bucket --is-multi-region-trail \
--enable-log-file-validation
aws cloudtrail start-logging --name org-trail
# 确认状态
aws cloudtrail get-trail-status --name org-trail1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
危险
审计日志桶必须与业务资源隔离权限。攻击者拿下业务账号后的第一件事往往就是删除审计日志，务必开启日志校验并把日志投递到受限的另一个账号/桶中。
三、密钥统一托管
bash
# 数据库密码、API Key 不应出现在代码、环境变量文件或镜像里
# 使用云厂商的密钥管理服务，按需授予读取权限
aws secretsmanager create-secret --name prod/db/password \
--secret-string "$(openssl rand -base64 32)"
# 应用运行时通过实例角色读取
aws secretsmanager get-secret-value --secret-id prod/db/password \
--query SecretString --output text1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
四、自动巡检配置漂移
用开源工具扫描 IaC 与云上实际配置：
bash
# 扫描 Terraform 代码
checkov -d infra/ --framework terraform
# 扫描云上已有配置（以 Prowler 为例，AWS）
pip3 install prowler
prowler aws --checks ec2_instance_secrets s3_bucket_public_access \
--severity critical high
# 只输出高风险项
checkov -d infra/ --check HIGH --compact1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
五、主机侧基线
bash
# 检查 SSH 是否禁用密码登录
sshd -T | grep -E "^(passwordauthentication|permitrootlogin|pubkeyauthentication)"
# 检查是否有 90 天未改密码的账号
awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd | while read u; do
chage -l "$u" | awk -v U="$u" '/Last password change/ {print U, $0}'
done
# 检查未清理的授权密钥
for h in /root /home/*; do
[ -f "$h/.ssh/authorized_keys" ] && echo "$h: $(wc -l < "$h/.ssh/authorized_keys") 条"
done1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
六、固化基线
把基线检查做成每周定时任务，输出不合格项到工单：
bash
# 每周一 09:00 扫描，结果存到对象存储
0 9 * * 1 /usr/local/bin/baseline-scan.sh > /var/log/baseline-$(date +\%F).txt 2>&11
2
2
验证
- [ ]
aws cloudtrail get-trail-status显示IsLogging=true且LatestDeliveryTime为近期 - [ ] 扫描工具输出的高危项为 0，或每项都有已记录的豁免理由与整改时间
- [ ]
sshd -T显示passwordauthentication no - [ ] 代码仓库扫描（含历史提交）未发现明文 AK
bash
# 历史提交里搜 AK（发现即视为已泄露，必须轮换）
git log -p | grep -In "AKIA\|LTAI" | head1
2
2
常见坑
- 开了审计但没保护：日志桶和业务同权限，被一起删掉。
- 只检查 IaC 不管线上：代码合规但有人手工改了线上配置，产生漂移。两处都要扫。
- 基线一次性检查：配完就不管，半年后新资源全都不合规。必须定时巡检。
- 密钥轮换后未同步：改了密钥但应用没更新，导致半夜服务全挂。轮换要有灰度与回滚。
- 为了合规而合规：基线项要理解背后的风险，否则会出现「MFA 开了但所有人共用一台手机」的伪合规。