使用 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 基準涵蓋範圍：
+-------------------+-------------------------+------------------------+
| 章節 | AWS v5.0 | Azure v4.0 |
+-------------------+-------------------------+------------------------+
| 身分識別與存取 | IAM 政策、MFA、root 帳號| Azure AD、RBAC、PIM |
| 記錄 | CloudTrail、Config | Activity Log、Diag |
| 監控 | CloudWatch 警報 | Defender、Sentinel |
| 網路 | VPC、SG、NACL | NSG、ASG、防火牆 |
| 儲存 | 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 設定檔 | 深度防禦控制項，可能限制功能，需要仔細規劃後才能實作 |
| Foundations 基準 | 專為雲端供應商設計的 CIS 基準，涵蓋 IAM、記錄、監控、網路與儲存安全 |
| 控制項 ID | 每個 CIS 建議的獨特數值識別碼（例如 1.4 用於 root 存取金鑰檢查，2.1.1 用於 S3 加密） |
| 合規分數 | 處於通過狀態的 CIS 控制項百分比，隨時間追蹤以衡量安全態勢改善 |
| 自動化評估 | 使用雲端供應商 API 檢查資源設定是否符合基準要求的工具驅動評估 |
| 修復劇本 | 修復特定失敗 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 Trust Services Criteria（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 控制項、資訊性項目