auditing-cloud-with-cis-benchmarks

# 使用 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 的控制项进行自动化评估。

```bash
# 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 控制项（纵深防御）。

```bash
# 解析 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 系统性地应用修复。

```bash
# 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。

```bash
# 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 账户持续合规监控的证据。

**方法**：
1. 在所有 45 个账户运行 Prowler CIS v5.0 评估，建立基线合规分数
2. 将结果导出为 CSV，按章节（IAM、日志记录、监控、网络）对失败项进行分类
3. 将每个 CIS 控制项映射到相关 SOC 2 信任服务标准（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 审计报告
============================
云提供商: 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 控制项、信息类项目
```