使用 CIS 基准（CIS Benchmarks）审计云环境：Prowler 扫描、结果解读与持续合规实践

本文基于开源仓库 Anthropic-Cybersecurity-Skills 中的技能文件 auditing-cloud-with-cis-benchmarks/SKILL.md 及其配套源码撰写。该技能面向需要完成云安全审计、验证 CIS 合规状态（AWS CIS v5、Azure CIS v4、GCP CIS v4）或搭建持续云合规监控的安全工程师与 AI Agent，读完本文你将掌握：选择正确基准版本的判断方法、用 Prowler/ScoutSuite 执行自动化扫描的完整命令、用 jq 解析审计结果并生成合规得分的技巧，以及从整改到持续监控的闭环方法论。

技能定位：何时使用、何时不用

云安全审计的核心目标，是依据行业公认的基准来衡量云账户的"安全基线"。本技能适用于以下场景：

• 对新云账户或订阅建立可度量的安全基线；
• 为 SOC 2、ISO 27001 等引用 CIS 控制项的合规审计做准备；
• 通过周期性再评估跟踪合规性随时间的变化；
• 评估收购或继承的云环境的安全态势。

该技能同样给出了明确的边界：不用于运行时威胁检测（可参考 detecting-cloud-threats-with-guardduty）、不用于应用层安全测试（可参考 conducting-cloud-penetration-testing）、也不覆盖非 CIS 体系的合规框架。

技能元数据（frontmatter）显示它被映射到多套框架，可作为审计工作中跨框架对齐的依据：NIST CSF 2.0 对应 PR.IR-01（事件响应规划）、ID.AM-08（资产管理）、GV.SC-06（供应链治理）、DE.CM-01（监控）；MITRE ATT&CK 对应 T1078.004（云账户）、T1530（云存储数据）、T1098.003（额外云角色）、T1685.002（备用账户）、T1580（云基础设施发现）——这些恰好是 CIS 控制项所防御的常见云侧攻击手法。

前置条件：最小权限与工具准备

在执行审计前需要满足四项前提：

1. 只读访问权限：AWS 使用 SecurityAudit 托管策略、Azure 使用 Reader 角色、GCP 使用 Viewer 角色，确保扫描器只能读取配置、不能改动资源；
2. 工具就绪：安装并配置 Prowler、ScoutSuite 或云厂商原生的 CSPM（云安全态势管理）工具；
3. 理解 CIS 基准结构：掌握章节（section）、控制项（control）、配置文件（profile）的概念，特别是 Level 1 与 Level 2 的差异；
4. 独立的整改权限：用于实施修复的账号必须与审计凭据分离，避免以高权限账号运行只读扫描。

工作流概览：五步完成 CIS 审计闭环

整个审计流程被组织为五个可重复执行的步骤：选版本 → 自动扫描 → 解读结果 → 优先整改 → 持续监控。

Step 1：选择正确的 CIS 基准版本

不同云厂商、不同年份的基准版本覆盖范围不同。截至 2025 年，主流版本为 CIS AWS Foundations Benchmark v5.0、CIS Azure Foundations Benchmark v4.0、CIS GCP Foundations Benchmark v4.0。三者的覆盖章节对比如下：

CIS Benchmark Coverage Areas:
+-------------------+-------------------------+------------------------+
| Section           | AWS v5.0                | Azure v4.0             |
+-------------------+-------------------------+------------------------+
| Identity & Access | IAM policies, MFA, root | Azure AD, RBAC, PIM    |
| Logging           | CloudTrail, Config      | Activity Log, Diag     |
| Monitoring        | CloudWatch alarms       | Defender, Sentinel     |
| Networking        | VPC, SG, NACLs         | NSG, ASG, Firewall     |
| Storage           | S3 encryption, access   | Storage encryption     |
| Database          | RDS encryption          | SQL TDE, auditing      |
+-------------------+-------------------------+------------------------+

配置文件（Profile）分两级，理解这一差异直接决定整改优先级：

• Level 1：可在不明显影响性能或功能的前提下落地的务实安全设置，代表"安全卫生基线"；
• Level 2：纵深防御设置，可能降低功能或需要额外规划，适合高风险环境。

Step 2：用 Prowler 执行自动化评估

Prowler 是跨 AWS、Azure、GCP 的开源云安全扫描器，可自动评估 CIS 控制项。以下命令覆盖三大云厂商：

# AWS CIS v5.0 assessment
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 assessment
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 assessment
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)

# Multi-account AWS scan using ScoutSuite
scout suite aws \
  --profile audit-account \
  --report-dir ./scout-report \
  --ruleset cis-5.0 \
  --force

参数要点：--compliance 指定基准标识（如 cis_5.0_aws）；--output-formats 同时输出 json-ocsf（机器可读的 OCSF 格式，便于后续解析）、html（可视化报告）与 csv（表格数据）；输出目录按日期命名便于版本管理。ScoutSuite 则通过 --ruleset cis-5.0 直接套用 CIS 规则集，生成 HTML 报告。

配套的 API 参考文档 references/api-reference.md 给出了 Prowler 的精简调用等价式：

prowler aws --compliance cis_5.0_aws --output-formats json,csv
prowler azure --compliance cis_4.0_azure
prowler gcp --compliance cis_4.0_gcp

Step 3：解读结果并排定整改优先级

扫描结束后，用 jq 对 Prowler 的 JSON 输出（OCSF 格式）做结构化分析。第一条命令按控制项分组统计失败资源数量，得出"哪些控制项影响面最大"：

# Parse Prowler results for failed controls
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)'

第二条命令按章节聚合，直接计算各章节的合规得分：

# Generate compliance score by section
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)
  })'

优先级原则：先处理 Level 1 控制项——它们是基础安全卫生；再处理 Level 2 控制项——它们提供纵深防御。按严重程度排序时，建议以"影响账户/资源数量 × 控制项严重级别"为联合排序依据，而不是只看单一指标。

Step 4：整改关键与高危控制项

从影响面最大的失败项开始，用云原生服务或 IaC（Terraform）系统性修复。以下是技能文件给出的 AWS 侧典型整改示例：

# CIS 1.4: Ensure no root account access key exists
aws iam list-access-keys --user-name root
# If keys exist, delete them
aws iam delete-access-key --user-name root --access-key-id AKIAEXAMPLE

# CIS 2.1.1: Ensure S3 bucket default encryption is enabled
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 "Encrypted: $bucket" || echo "FAILED: $bucket"
done

# CIS 3.1: Ensure CloudTrail is enabled in all regions
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: Configure CloudWatch metric filters and alarms
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

这些命令对应 CIS 1.x（身份与访问管理）、2.x（存储）、3.x（日志）、4.x（监控）四大章节的典型失败项：删除 root 访问密钥、为 S3 桶开启默认加密、创建多区域 CloudTrail 并启用日志文件校验、为 CloudTrail 日志配置 CloudWatch 指标过滤器以驱动告警。

源码级扩展：用 boto3 手工核验 CIS 控制项

仓库提供的审计脚本 scripts/agent.py 展示了上述 CLI 操作背后的 API 调用链——它用 boto3 实现了 8 个 CIS 控制项检查，逻辑清晰，适合作为自定义扫描器的参考实现：

• CIS 1.4 / 1.5（root 密钥与 MFA）：调用 iam.get_account_summary()，读取 AccountAccessKeysPresent 与 AccountMFAEnabled 字段判断是否 FAIL（见 check_root_access_keys、check_root_mfa）；
• CIS 1.8–1.11（密码策略）：调用 iam.get_account_password_policy()，逐一校验最小长度（<14 判失败）、大小写、数字、符号要求（见 check_password_policy）；
• CIS 3.1 / 3.2（CloudTrail）：调用 cloudtrail.describe_trails()，检查 IsMultiRegionTrail 与 LogFileValidationEnabled 字段（见 check_cloudtrail_multiregion、check_cloudtrail_log_validation）；
• CIS 2.1.1（S3 加密）：遍历 s3.list_buckets()，对每个桶调用 s3.get_bucket_encryption()，抛 ClientError 即视为未加密（见 check_s3_encryption）；
• CIS 5.1（VPC 流日志）：用 ec2.describe_vpcs() 与 ec2.describe_flow_logs() 求差集，找出无流日志覆盖的 VPC（见 check_vpc_flow_logs）；
• CIS 5.4（默认安全组）：过滤 group-name=default 的安全组，检查入站规则中是否存在 0.0.0.0/0（见 check_default_sg_restrictions）。

脚本入口 main() 通过 boto3.Session 复用 AWS 配置（--profile 默认取 AWS_PROFILE 环境变量、--region 默认 us-east-1），审计结果以 JSON 落盘并输出综合得分。对应的 api-reference.md 中还给出了控制项与 API 方法的速查表：

CIS Control	boto3 Method	Check
1.4 Root keys	iam.get_account_summary()	AccountAccessKeysPresent == 0
1.5 Root MFA	iam.get_account_summary()	AccountMFAEnabled == 1
2.1.1 S3 encryption	s3.get_bucket_encryption()	No ClientError
3.1 CloudTrail	ct.describe_trails()	IsMultiRegionTrail
5.1 VPC flow logs	ec2.describe_flow_logs()	All VPCs covered
5.4 Default SG	ec2.describe_security_groups()	No 0.0.0.0/0 rules

这套"CLI 整改 + API 核验"的组合思路，可以让你在自动化扫描之外建立独立抽检能力，避免工具误报导致的错误结论。

Step 5：建立持续合规监控

周期审计只能提供时间快照，配置漂移（configuration drift）随时可能让环境脱离合规状态。技能文件建议在三大云厂商分别部署持续监控：

# AWS: Enable CIS v5.0 in Security Hub
aws securityhub batch-enable-standards \
  --standards-subscription-requests '[
    {"StandardsArn": "arn:aws:securityhub:::ruleset/cis-aws-foundations-benchmark/v/5.0.0"}
  ]'

# Azure: Assign CIS benchmark policy initiative
az policy assignment create \
  --name cis-azure-benchmark \
  --scope "/subscriptions/<sub-id>" \
  --policy-set-definition "1a5bb27d-173f-493e-9568-eb56638dbd0e" \
  --params '{"effect": {"value": "AuditIfNotExists"}}'

# Schedule periodic Prowler assessments
# Run weekly via cron or CI/CD pipeline
0 2 * * 1 prowler aws --compliance cis_5.0_aws --output-formats csv --output-directory /opt/audits/weekly-$(date +\%Y\%m\%d)

要点解读：AWS Security Hub 原生支持将 CIS AWS Foundations Benchmark 作为安全标准订阅；Azure 侧将 CIS 基准策略计划（initiative）以 AuditIfNotExists 效果分配给订阅；Prowler 则可通过 cron（示例为每周一凌晨 2 点）或 CI/CD 流水线定期重扫，产出可对比的历史数据。

关键概念速查

Term	Definition
CIS Benchmark	由互联网安全中心（Center for Internet Security）经社区共识制定的规范性安全配置指南
Level 1 Profile	可在无明显性能或功能影响下落地的务实安全控制项，代表安全卫生基线
Level 2 Profile	纵深防御控制项，可能限制功能，实施前需要仔细规划
Foundations Benchmark	面向云厂商的 CIS 基准，覆盖 IAM、日志、监控、网络与存储安全
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 预审计

背景：一家 SaaS 公司正在申请 SOC 2 Type II 认证，需要向审计方证明其 45 个 AWS 账户的云安全控制与 CIS 基准对齐，且具备持续合规监控的证据。

执行路径（与前述五步工作流一一对应）：

1. 在全部 45 个账户上运行 Prowler CIS v5.0 评估，建立基线合规得分；
2. 将结果导出为 CSV，按章节（IAM、日志、监控、网络）归类失败项；
3. 将每条 CIS 控制项映射到 SOC 2 信任服务标准（Trust Services Criteria），如 CC6.1、CC6.6、CC7.1 等；
4. 30 天内修复全部 Level 1 失败项，60 天内修复 Level 2；
5. 在 AWS Security Hub 启用 CIS v5.0，实现持续监控与自动化漂移检测；
6. 生成每周合规报告，向审计方展示改善轨迹；
7. 对有意不实施的控制项，记录例外声明并附风险接受理由。

常见陷阱：不先在预发环境测试就直接整改，可能破坏生产工作负载；完全忽略 Level 2 控制项会削弱审计叙事，即便它们并非强制要求。

输出格式：一份可直接复用的审计报告模板

技能文件提供了标准化的审计报告输出模板，涵盖总体得分、分章节得分、失败控制项清单与整改优先级，可直接套用于交付物：

CIS Benchmark Audit Report
============================
Cloud Provider: AWS
Benchmark Version: CIS AWS Foundations Benchmark v5.0
Accounts Assessed: 45
Assessment Date: 2025-02-23
Tool: Prowler v4.3.0

OVERALL COMPLIANCE SCORE: 74%

COMPLIANCE BY SECTION:
  1. Identity and Access Management:  68% (41/60 controls passed)
  2. Storage:                         82% (28/34 controls passed)
  3. Logging:                         91% (20/22 controls passed)
  4. Monitoring:                      55% (18/33 controls passed)
  5. Networking:                      78% (32/41 controls passed)

TOP FAILED CONTROLS (by affected accounts):
  [1.4]   Root account has active access keys           - 3/45 accounts
  [1.5]   MFA not enabled for root account              - 2/45 accounts
  [2.1.1] S3 default encryption not enabled             - 12/45 accounts
  [3.1]   CloudTrail not multi-region                   - 8/45 accounts
  [4.3]   No alarm for root account usage               - 28/45 accounts
  [5.1]   VPC flow logs not enabled                     - 15/45 accounts
  [5.4]   Security groups allow 0.0.0.0/0 ingress      - 22/45 accounts

REMEDIATION PRIORITY:
  Critical (Fix within 7 days):  Root access keys, missing root MFA
  High (Fix within 30 days):     S3 encryption, CloudTrail, VPC flow logs
  Medium (Fix within 60 days):   CloudWatch alarms, security group restrictions
  Low (Fix within 90 days):      Level 2 controls, informational items

模板中的"按受影响账户数排序的失败控制项"与"按时间窗划分的整改优先级"两节，直接承接了 Step 3 的 jq 分析结果，让报告从"数据罗列"升级为"可执行决策"。示例数据（如 74% 总得分、各章节通过数量）为模板占位值，实际输出应以你环境的扫描结果为准。

延伸阅读

• 技能主体：skills/auditing-cloud-with-cis-benchmarks/SKILL.md
• API 参考（boto3 检查方法与 Prowler CLI）：skills/auditing-cloud-with-cis-benchmarks/references/api-reference.md
• 可运行的审计 Agent 脚本：skills/auditing-cloud-with-cis-benchmarks/scripts/agent.py
• 技能框架映射说明：mappings/README.md 与 docs/mitre-f3-mapping.md
• 相关技能：云威胁检测见 detecting-cloud-threats-with-guardduty，云渗透测试见 conducting-cloud-penetration-testing