killvxk 使用 CIS Benchmarks 审计云环境
适用场景
- 对云环境进行初始安全审计时，以行业标准基准衡量现状
- 准备参考 CIS 控制项的 SOC 2、ISO 27001 或法规审计时
- 为新云账户或订阅建立可衡量的安全基线时
- 通过定期重新评估跟踪合规改进情况时
- 评估收购或接管的云环境安全态势时
不适用于：运行时威胁检测（参见 detecting-cloud-threats-with-guardduty）、应用层安全测试（参见 conducting-cloud-penetration-testing），或非 CIS 的合规框架（参见相关合规 skill 文件）。
前置条件
- 对目标云账户的只读访问（AWS SecurityAudit 策略、Azure Reader 角色、GCP Viewer 角色）
- 安装并配置 Prowler、ScoutSuite 或云原生 CSPM 工具
- 了解 CIS 基准结构：章节、控制项、配置文件（Level 1 和 Level 2）
- 用于实施修复的修复访问权限（与审计凭据分开）
工作流程
步骤 1：选择合适的 CIS Benchmark 版本
为每个云提供商选择正确的基准版本。截至 2025 年的当前版本包括：CIS AWS Foundations Benchmark v5.0、CIS Azure Foundations Benchmark v4.0 和 CIS GCP Foundations Benchmark v4.0。
CIS Benchmark 覆盖范围：
+-------------------+-------------------------+------------------------+
| 章节 | AWS v5.0 | Azure v4.0 |
+-------------------+-------------------------+------------------------+
| 身份与访问 | IAM 策略、MFA、root | Azure AD、RBAC、PIM |
| 日志记录 | CloudTrail、Config | Activity Log、Diag |
| 监控 | CloudWatch 告警 | Defender、Sentinel |
| 网络 | VPC、SG、NACLs | NSG、ASG、防火墙 |
| 存储 | S3 加密、访问 | Storage 加密 |
| 数据库 | RDS 加密 | SQL TDE、审计 |
+-------------------+-------------------------+------------------------+
CIS 配置文件级别：
Level 1：实用安全设置，不会对性能或功能产生重大影响即可实施
Level 2：纵深防御设置，可能降低功能性或需要额外规划才能实施
步骤 2：使用 Prowler 运行自动化评估
使用 Prowler 执行全面的 CIS 基准扫描，对 AWS、Azure 和 GCP 的控制项进行自动化评估。
# AWS CIS v5.0 评估
prowler aws \
--compliance cis_5.0_aws \
--profile audit-account \
--output-formats json-ocsf,html,csv \
--output-directory ./cis-audit-$(date +%Y%m%d)
# Azure CIS v4.0 评估
prowler azure \
--compliance cis_4.0_azure \
--subscription-ids "sub-id-1,sub-id-2" \
--output-formats json-ocsf,html,csv \
--output-directory ./cis-audit-azure-$(date +%Y%m%d)
# GCP CIS v4.0 评估
prowler gcp \
--compliance cis_4.0_gcp \
--project-ids "project-1,project-2" \
--output-formats json-ocsf,html,csv \
--output-directory ./cis-audit-gcp-$(date +%Y%m%d)
# 使用 ScoutSuite 进行多账户 AWS 扫描
scout suite aws \
--profile audit-account \
--report-dir ./scout-report \
--ruleset cis-5.0 \
--force
步骤 3：解读结果并确定修复优先级
按章节和严重程度分析审计结果。优先处理 Level 1 控制项（代表基本安全卫生），然后处理 Level 2 控制项（纵深防御）。
# 解析 Prowler 结果中的失败控制项
cat ./cis-audit-*/prowler-output-*.json | \
jq '[.[] | select(.StatusExtended == "FAIL")] | group_by(.CheckID) |
map({control: .[0].CheckID, description: .[0].CheckTitle,
failed_resources: length, severity: .[0].Severity}) |
sort_by(-.failed_resources)'
# 按章节生成合规分数
cat ./cis-audit-*/prowler-output-*.json | \
jq 'group_by(.Section) | map({
section: .[0].Section,
total: length,
passed: [.[] | select(.StatusExtended == "PASS")] | length,
failed: [.[] | select(.StatusExtended == "FAIL")] | length,
score: (([.[] | select(.StatusExtended == "PASS")] | length) / length * 100 | round)
})'
步骤 4：修复严重和高风险控制项
从最高影响项开始处理失败的控制项。使用 AWS Config 修复、Azure Policy 或 Terraform 系统性地应用修复。
# CIS 1.4：确保 root 账户无访问密钥
aws iam list-access-keys --user-name root
# 如果密钥存在则删除
aws iam delete-access-key --user-name root --access-key-id AKIAEXAMPLE
# CIS 2.1.1：确保 S3 存储桶启用默认加密
for bucket in $(aws s3api list-buckets --query 'Buckets[*].Name' --output text); do
aws s3api put-bucket-encryption --bucket "$bucket" \
--server-side-encryption-configuration '{
"Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"}}]
}' 2>/dev/null && echo "已加密: $bucket" || echo "失败: $bucket"
done
# CIS 3.1：确保 CloudTrail 在所有区域启用
aws cloudtrail create-trail \
--name organization-trail \
--s3-bucket-name cloudtrail-logs-bucket \
--is-multi-region-trail \
--enable-log-file-validation \
--kms-key-id arn:aws:kms:us-east-1:123456789012:key/key-id
aws cloudtrail start-logging --name organization-trail
# CIS 4.x：配置 CloudWatch 指标过滤器和告警
aws logs put-metric-filter \
--log-group-name CloudTrail/DefaultLogGroup \
--filter-name UnauthorizedAPICalls \
--filter-pattern '{ ($.errorCode = "*UnauthorizedAccess*") || ($.errorCode = "AccessDenied*") }' \
--metric-transformations metricName=UnauthorizedAPICalls,metricNamespace=CISBenchmark,metricValue=1
步骤 5：建立持续合规监控
部署自动化合规监控，检测定期审计之间的配置漂移。使用 AWS Security Hub、Azure Policy 或 GCP Security Command Center。
# AWS：在 Security Hub 中启用 CIS v5.0
aws securityhub batch-enable-standards \
--standards-subscription-requests '[
{"StandardsArn": "arn:aws:securityhub:::ruleset/cis-aws-foundations-benchmark/v/5.0.0"}
]'
# Azure：分配 CIS 基准策略倡议
az policy assignment create \
--name cis-azure-benchmark \
--scope "/subscriptions/<sub-id>" \
--policy-set-definition "1a5bb27d-173f-493e-9568-eb56638dbd0e" \
--params '{"effect": {"value": "AuditIfNotExists"}}'
# 安排定期 Prowler 评估
# 通过 cron 或 CI/CD 流水线每周运行
0 2 * * 1 prowler aws --compliance cis_5.0_aws --output-formats csv --output-directory /opt/audits/weekly-$(date +\%Y\%m\%d)
核心概念
| 术语 | 定义 |
|---|---|
| CIS Benchmark | 互联网安全中心通过社区共识制定的规范性安全配置指南 |
| Level 1 配置文件 | 可实施的实用安全控制项，不会对性能或功能产生重大影响，代表安全卫生 |
| Level 2 配置文件 | 纵深防御控制项，可能限制功能，实施前需仔细规划 |
| Foundations Benchmark | 专为云提供商设计的 CIS 基准，涵盖 IAM、日志记录、监控、网络和存储安全 |
| 控制项 ID（Control ID） | 每个 CIS 建议的唯一数字标识符（如 1.4 表示 root 访问密钥检查，2.1.1 表示 S3 加密） |
| 合规分数（Compliance Score） | 处于通过状态的 CIS 控制项百分比，随时间跟踪以衡量安全态势改进 |
| 自动化评估（Automated Assessment） | 使用云提供商 API 检查资源配置是否符合基准要求的工具驱动评估 |
| 修复手册（Remediation Runbook） | 修复特定失败 CIS 控制项的文档化分步骤程序，包括预检查和验证 |
工具与系统
- Prowler：开源云安全工具，执行 300+ 项检查，包括 AWS、Azure 和 GCP 的 CIS 基准评估
- ScoutSuite：多云安全审计工具，包含 CIS 基准规则集，生成 HTML 报告
- AWS Security Hub：AWS 原生服务，支持将 CIS AWS Foundations Benchmark 作为安全标准
- Azure Policy：治理服务，包含内置 CIS 基准策略倡议，用于自动化合规监控
- GCP Security Command Center：GCP 原生服务，根据 CIS GCP Foundations Benchmark 评估配置
常见场景
场景：SOC 2 认证前的 CIS 预审计评估
场景背景：一家寻求 SOC 2 Type II 认证的 SaaS 公司需要证明其云安全控制符合 CIS 基准。审计员要求提供 45 个 AWS 账户持续合规监控的证据。
方法：
- 在所有 45 个账户运行 Prowler CIS v5.0 评估，建立基线合规分数
- 将结果导出为 CSV，按章节（IAM、日志记录、监控、网络）对失败项进行分类
- 将每个 CIS 控制项映射到相关 SOC 2 信任服务标准（CC6.1、CC6.6、CC7.1 等）
- 30 天内修复所有 Level 1 控制失败，60 天内修复 Level 2
- 在 AWS Security Hub 中启用 CIS v5.0，进行持续监控和自动化漂移检测
- 生成每周合规报告，向审计员展示改进轨迹
- 为有意不实施的控制项记录例外情况，并附上风险接受理由
常见陷阱：未先在预演环境测试就修复控制项可能会破坏生产工作负载。即使 Level 2 控制项不是严格要求的，完全忽略它们也会削弱审计论据。
输出格式
CIS Benchmark 审计报告
============================
云提供商: AWS
基准版本: CIS AWS Foundations Benchmark v5.0
评估账户数: 45
评估日期: 2025-02-23
工具: Prowler v4.3.0
总体合规分数: 74%
各章节合规情况:
1. 身份和访问管理: 68% (41/60 个控制项通过)
2. 存储: 82% (28/34 个控制项通过)
3. 日志记录: 91% (20/22 个控制项通过)
4. 监控: 55% (18/33 个控制项通过)
5. 网络: 78% (32/41 个控制项通过)
最多失败控制项（按受影响账户数排序）:
[1.4] root 账户存在活跃访问密钥 - 3/45 个账户
[1.5] root 账户未启用 MFA - 2/45 个账户
[2.1.1] S3 未启用默认加密 - 12/45 个账户
[3.1] CloudTrail 未启用多区域 - 8/45 个账户
[4.3] 未配置 root 账户使用告警 - 28/45 个账户
[5.1] VPC 未启用流日志 - 15/45 个账户
[5.4] 安全组允许 0.0.0.0/0 入站 - 22/45 个账户
修复优先级:
严重（7 天内修复）: root 访问密钥、缺失 root MFA
高（30 天内修复）: S3 加密、CloudTrail、VPC 流日志
中（60 天内修复）: CloudWatch 告警、安全组限制
低（90 天内修复）: Level 2 控制项、信息类项目