云端审计之CIS基准评测 是做什么的？
何时使用
- 对云环境进行初始安全审计，对照行业标准基准
- 为 SOC 2、ISO 27001 或引用 CIS 控制的法规审计做准备
- 为新云账户或订阅建立可衡量的安全基线
- 通过定期重新评估跟踪合规性改进
- 评估收购或继承的云环境的安全态势
请勿使用此技能进行运行时威胁检测（请参考 detecting-cloud-threats-with-guardduty）、应用层安全测试（请参考 conducting-cloud-penetration-testing）或非基于 CIS 的合规框架（请参考具体的法规技能文件）。
前提条件
- 目标云账户的只读访问权限（AWS SecurityAudit 策略、Azure Reader 角色、GCP Viewer 角色）
- 安装并配置 Prowler、ScoutSuite 或云原生 CSPM 工具
- 了解 CIS 基准结构：章节、控制项、配置文件（Level 1 和 Level 2）
- 用于实施修复的访问权限（与审计凭证分开）
工作流程
步骤 1：选择合适的 CIS 基准版本
为每个云提供商选择正确的基准版本。截至 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 | 活动日志、诊断 |
| 监控 | CloudWatch 告警 | Defender、Sentinel |
| 网络 | VPC、SG、NACL | NSG、ASG、Firewall |
| 存储 | S3 加密、访问控制 | 存储加密 |
| 数据库 | 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 基准 | 由互联网安全中心通过社区共识制定的规范性安全配置指南 |
| Level 1 配置文件 | 可在不显著影响性能或功能的情况下实施的实用安全控制项，代表安全卫生 |
| Level 2 配置文件 | 深度防御控制项，可能限制功能并需要在实施前仔细规划 |
| 基础基准 | 专为云提供商设计的 CIS 基准，涵盖 IAM、日志记录、监控、网络和存储安全 |
| 控制项 ID | 每个 CIS 建议的唯一数字标识符（例如，1.4 用于 root 访问密钥检查，2.1.1 用于 S3 加密） |
| 合规分数 | 处于通过状态的控制项百分比，随时间跟踪以衡量安全态势改进 |
| 自动评估 | 使用云提供商 API 检查资源配置是否达到基准要求的工具驱动型 CIS 控制评估 |
| 修复手册 | 修复特定失败 CIS 控制的记录逐步流程，包括预检查和验证 |
工具与系统
- Prowler：开源云安全工具，执行 300 多项检查，包括 AWS、Azure 和 GCP 的 CIS 基准评估
- ScoutSuite：多云安全审计工具，带有 CIS 基准规则集，生成 HTML 报告
- AWS Security Hub：原生 AWS 服务，支持 CIS AWS 基础基准作为安全标准
- Azure Policy：治理服务，具有内置的 CIS 基准策略计划，用于自动化合规监控
- GCP Security Command Center：原生 GCP 服务，根据 CIS GCP 基础基准评估配置
常见场景
场景：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 基准审计报告
============================
云提供商：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 控制项、信息性项目