持续的合规性监控

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是组织的"合规性脉搏"：策略以代码表示，信号不断流动，违规行为立即可见，证据自动收集，审计变成操作例程而不是火灾。