持續的合規性監控

1）什麼是連續合規性監控

• 減少人工檢查和人為因素。
• 減少TTD/MTTR違規行為。
• 隨時提供「審核就緒」狀態。
• 通過策略即代碼加速實施更改。

2） CCM的範圍（scope）

訪問和身份（IAM/IGA）：SoD，冗余角色，「沒有所有者的訪問」。
數據和隱私：撤回/TTL，蒙面，法律保留，DSAR-SLA。
基礎架構/雲/IaC：配置漂移，加密，分段。
產品/代碼/CI-CD：存儲庫中的秘密，SCA/SAST/DAST，OSS許可證。
交易/AML：制裁/RER篩選，異常規則，STR/SAR。
操作：審計日誌、備份和恢復、漏洞。

3）CCM參考體系結構

1.信號收集：代理和連接器（雲、DB、日誌、SIEM、IAM、CI/CD、DLP、郵件/聊天存檔）。

2.正常化和豐富：事件總線（Kafka/Bus）+ETL/ELT到Compliance店面。

3.CaC：YAML/Rego存儲庫/具有版本，測試和評論的策略。

4.規則引擎（stream/batch）：計算違規、優先級和風險範圍。

5.編排：ticketing/SOAR+升級通過RACI，自動修復，SLA快門。

6.Evidence/WORM：不可更改的工件（日誌、圖像、報告）。

7.Dashbords和報告：heatmap，KPI/SLO，監管卸載。

4） Policy as code： 迷你電路

yaml id: IAM-SOD-007 title: "Prohibition of toxic combination of roles: finance_approver + vendor_onboarder"
scope: ["iam:"]
detect:
query: iam_sod_violations_last_1h. sql severity: high notify: ["GRC","SecOps"]
remediate:
playbook: revoke_extra_role sla:
detect_minutes: 15 remediate_hours: 24 evidence:
sink: s3://evidence/iam-sod/dt={{ts}}
owners: ["IGA","FinanceOps"]

yaml id: GDPR-RET-001 title: "TTL 24м для PI; LegalHold priority"
rule: "object. age_months <= 24          object. legal_hold == true"
detect:
job: retention_scan_daily sla: { detect_minutes: 60, remediate_days: 7 }

5）標準控制範本

6）度量和SLO

覆蓋率：監控下系統/數據的百分比（目標≥ 90％）。
MTTD/MTTR控制：平均檢測時間/消除時間。
漂移率：漂移配置/時間。
假正價：根據規則誤報的比例。
審核準備時間：準備時間（目標-時鐘）。
DSAR SLA：按時關閉的百分比；響應中位數。
Access Hygiene：過時的權利份額；關閉SoD違規行為。

7） CCM過程（SOP）

1.識別要求→「標準→控制→度量」矩陣。
2.規則設計→策略即代碼，測試，PR/review，驗證。
3.部署→叠加驗證，然後是帶有特征標誌的prod。
4.監視和異常→優先級（sev/impact）、降噪、重復數據消除。
5.Remediation →自動花花公子+提克特車主；SLA升級。
6.Evidence →偶爾的快照；WORM/immutability;哈希摘要。
7.重新評估→季度規則調整，FPR/TPR分析，A/B比較。
8.培訓→跟蹤控制所有者、說明和異常目錄（waivers）。

8）Alert的生命周期

Detect → Triage → Assign → Remediate → Verify → Close → Learn.

對於每個步驟，都記錄下來：所有者，所采取的措施，證據文物。

9）整合

GRC-要求，風險，控制，咆哮活動，文物存儲。
SIEM/SOAR-事件相關性，自動花花公子。
IAM/IGA-認證，SoD，RBAC/ABAC，訪問生命周期。
CI/CD/DevSecOps-合規門，SAST/DAST/SCA，秘密掃描。
Data Platform-「Compliance」店面，目錄/lineage，掩碼。

DLP/EDRM-敏感性標簽,禁止滲出,日誌.

Ticketing/ITSM-SLA、升級、業主和團隊報告。

10）Dashbords（最低設置）

Compliance Heatmap（系統×法規×狀態）。
SLA中心（DSAR/AML/PCI/SOC2截止日期，逾期）。
Access＆SoD（有毒角色，「被遺忘」的可用性）。
Retention&Deletion （TTL違規,Legal Hold鎖）。
Infra/Cloud Drift（IaC/現實狀態不匹配）。
事件與發現（重復趨勢，重制效率）。

11）規則示例（SQL/偽）

sql
SELECT user_id, dataset, created_at
FROM pi_objects
WHERE age_months(created_at) > 24
AND legal_hold = false;

sql
SELECT u. id, r1. role, r2. role
FROM user_roles r1
JOIN user_roles r2 ON r1. user_id = r2. user_id
JOIN users u ON u. id = r1. user_id
WHERE r1. role = 'finance_approver' AND r2. role = 'vendor_onboarder';

12）角色和RACI

13）例外管理（waivers）

正式請求，有理由和到期日期。
風險評估和補償控制。
審查自動提醒。
報告中的反映（審計員的透明度）。

14） CCM的隱私和安全

窗口和日誌中的數據最小化（PII修訂版）。
分工，最低特權。

Immutability (WORM/S3 Object Lock) для evidence.

加密報告提交（哈希鏈）。
對文物的訪問控制和日誌記錄。

15）支票單

啟動CCM

• 矩陣的「標準→控制→度量」是一致的。
• 連接了關鍵信號源。
• 策略由代碼描述，包括測試和咆哮。
• 包括dashbords和alertes；由SLO/SLA定義。
• 配置了事件歸檔（immutability）。
• 業主受過培訓；定義了等待者的過程。

在審核之前

• 更新了策略和更改版本。
• 進行抽樣抽樣。
• 已關閉逾期修復和例外。
• Coverage/MTTD/MTTR/Drift度量標準已驗證。

16）反模式

「審核」代替永久控制。
噪音規則沒有優先級或重復數據消除。
沒有考試和測試的政策。
沒有所有者和SLA的監控。
在可變位置/無哈希提交中的事件。

17） CCM成熟度模型（M0-M4）

M0手動：零星檢查,Excel報告。
M1工具：部分遙測，一次性規則。
M2 Autodetect：持續檢查，基本SLO和Alerta。
M3 Orchestrated：SOAR，自動復制，「試用就緒」。
M4 Continuous Assurance：在SDLC/Prode中進行審核+自我審核。

18）相關的wiki文章

編譯和報告自動化

法律保留和數據凍結

Privacy by Design和最小化數據

數據存儲和刪除時間表

PCI DSS/SOC 2： 控制和認證

事件管理和前瞻性

底線

CCM是組織的「合規性脈搏」：策略以代碼表示，信號不斷流動，違規行為立即可見，證據自動收集，審計變成操作例程而不是火災。