01 · CSA CCM v4 体系解构
云控制矩阵（Cloud Controls Matrix, CCM）是CSA的核心工具，其设计目标是成为"云控制的通用语言"：每个控制域（domain）下按控制项（control ID，如IAM-01、CEK-03）组织，每个控制项标注与ISO 27001/27017/27018、NIST SP 800-53、PCI DSS等框架的映射关系。v4版本（2021年发布）较v3的重大变化包括：控制域重组与扩充至17个、新增现代云安全议题（如容器、DevSecOps、威胁情报）、控制项措辞与云原生术语对齐。
| 域ID | 域名称 | 与子课题01的相关性 |
|---|---|---|
| IAM | 身份与访问管理 | 核心域：账号生命周期、认证强度、权限最小化——第3页IAM治理的控制映射锚点 |
| CEK | 密码学与密钥管理 | 核心域：密钥归属灰区（第2页5.3节）的控制依据 |
| LOG | 日志与监控 | 核心域：日志可见性灰区与留存合规（网络安全法第21条）的映射源 |
| AAC | 应用与接口安全 | SSRF防护三件套中应用层的映射依据（配合OWASP） |
| BCR | 业务连续性 | 责任矩阵中"谁负责备份恢复"的控制化表达 |
| UEM | 终端设备通用 | 责任矩阵"终端用户设备客户全责"行的控制支撑 |
| DSP | 数据安全与隐私 | 数据生命周期控制，与等保2.0数据安全条款互为映射（第7页） |
| CCC | 变更控制与配置管理 | 配置漂移与CSPM检测规则（第3、6页）的治理依据 |
使用要点：CCM的价值不在"通过认证"而在映射关系本身——它使一份IAM基线可以同时回答"CIS Benchmark哪一条、CCM哪个控制项、等保哪一项"三个问题。建议组织以CCM控制ID为主键维护控制库（参见第6节方法论），而非为每套合规体系各建一套台账。
02 · CAIQ 问卷机制
共识评估倡议问卷（CAIQ）是CCM的操作化载体：将每个控制项转化为供应商可回答的是/否/不适用问题，并附证据说明栏。典型应用场景：
- SaaS采购尽调：采购团队向SaaS供应商发放CAIQ，由供应商自答并附证据（截图、制度文件编号），安全团队按CCM域抽查验证——这是STAR自评估（Level 1/2）的技术内容。
- 内部差距分析：以CAIQ为检查单逐项自评，输出"满足/部分满足/不满足"矩阵，直接生成整改 backlog。
- 多供应商可比性：同一问卷模板使不同供应商的回答可横向比较，避免各家自定义问卷导致的不可比性。
局限须知：CAIQ是自评估工具，回答质量依赖供应商诚信与能力；关键SaaS应在其自答基础上要求第三方审计报告（SOC 2 Type II、STAR Level 2以上）或实施现场核验。对处理重要数据的SaaS，"CAIQ回答+合同审计权"是底线组合。
03 · STAR 认证四级路径
STAR（Security, Trust, Assurance, and Risk）是CSA以CCM+CAIQ为技术底座、叠加ISO/IEC 27001管理要求的注册与认证体系，其等级设计体现了"透明度递进"思想：
| 等级 | 性质 | 技术内容 | 适用场景 |
|---|---|---|---|
| Level 1 | STAR注册 | 提交法律承诺与基本企业信息入册 | 供应商初步透明度声明 |
| Level 2 | STAR自评估 | 发布CAIQ自评估结果（含公有云自评与场景自评等变体） | 采购尽调的可比性输入 |
| Level 3 | STAR认证（第三方） | ISO/IEC 27001认证基础上叠加CCM控制核查 | 重要供应商准入的充分条件 |
| Level 4 | STAR持续审计 | 自动化、持续的控制有效性验证与持续合规监测 | 关键业务供应商的持续监督 |
对采购方的实践建议：按数据敏感度分级要求STAR等级——一般业务SaaS要求Level 2（自评公开可查），处理重要数据的SaaS要求Level 3（第三方认证），关键业务供应商推动Level 4或至少建立年度复审机制。
04 · ISO/IEC 27017 与 27018 对照
两项国际标准与CCM存在覆盖重叠但定位不同：27017是"云服务专用的27002控制实施指南"（2015年发布），面向CSP与云客户双方给出控制实施指引；27018（2014年发布、2019年修订）是"公有云个人信息保护实施规范"，为PII处理者建立控制基线。
| 议题 | ISO/IEC 27017 处理角度 | ISO/IEC 27018 处理角度 | CCM 对应域 |
|---|---|---|---|
| 责任与角色界定 | 区分CSP/客户控制实施责任，提供共享控制实施指引 | 明确PII处理者与控制者的责任划分条款 | Governance域系列、IAM |
| 数据删除与返还 | 服务终止时的数据处置控制 | PII删除、可携与留存限制 | DSP |
| 分包商管理 | CSP分包商变更告知与管控 | PII处理分包商的合同约束 | DSP/Supply Chain域 |
| 数据位置 | 数据存储位置相关的控制 | 跨境PII转移的告知与同意机制 | DSP、A&A |
| 事件通知 | 安全事件通报控制 | PII泄露通知的具体时限与内容要求 | LOG、Incident域 |
与国内的关系：27018与我国《个人信息保护法》受托处理条款（第21条）在目的限定、不得转委托、安全保障义务等要素上高度同构，可作为出海业务的国际对照基线；但国内合规的准绳是《个保法》《数安法》及配套国标，境外标准仅作方法参照（见第7页合规边界声明）。
05 · NIST 与 CISA 云安全基线
5.1 NIST 侧
- SP 800-53 Rev.5（2020年发布）：首次将控制目录与"控制增强"按适用环境标注（含云环境），其附录与在线OLIR（OSCAL-based Control Mappings）为控制映射提供机器可读格式的权威参照。
- SP 500-307：云计算安全与隐私控制的实施指南文献，回答"800-53的控制上云后怎么落地"。
- SP 1800 系列实践指南（NCCoE）：如面向多云环境的实践指南项目，提供工程化落地样例（虚构企业场景但技术配置真实可复现）。
5.2 CISA 侧
美国网络安全和基础设施安全局（CISA）近年发布面向云环境的配置基线类资源（面向联邦机构但公开可查），核心思想是：为云环境定义"安全的默认值"清单——与其让各机构从零梳理基线，不如由监管机构直接给出最低安全基线（minimum viable security baseline）并配套自动化核查脚本。该思路对组织内基线建设同样适用：先采纳权威基线（CIS/CISA），再叠加行业特性裁剪，而非从空白开始。
06 · 控制映射方法论
6.1 映射粒度选择
| 粒度 | 优点 | 代价 | 建议适用 |
|---|---|---|---|
| 域级映射（17域↔等保大类） | 维护成本低、稳定性高 | 证据指向模糊，测评时需人工解释 | 管理层汇报、年度概览 |
| 控制项级映射（IAM-01↔具体条款） | 证据可精确挂接，复用性最佳 | 初次建立工作量大 | 推荐主用粒度：测评复用与整改跟踪 |
| 核查项级映射（CIS条目逐条对挂） | 自动化程度最高 | 框架修订时跟随维护成本高 | CSPM规则库内部结构（第6页） |
本节参考来源（第4页）
以下均为真实可查的权威来源，用于支撑本页事实性表述。
CSA Cloud Controls Matrix v4（2021年发布）与CAIQ问卷、STAR注册/认证规则：cloudsecurityalliance.org/research/cloud-controls-matrix。
ISO/IEC 27017:2015《Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services》与ISO/IEC 27018:2019《Code of practice for protection of PII in public clouds acting as PII processors》：iso.org。
NIST SP 800-53 Rev.5《Security and Privacy Controls for Information Systems and Organizations》（2020年9月，含OLIR/OSCAL机器可读映射资源）：csrc.nist.gov。
NIST NCCoE SP 1800 系列云安全实践指南（如多云安全实践指南项目）：nccoe.nist.gov。
CISA云安全基线与已知被利用漏洞目录（KEV）：cisa.gov。
《中华人民共和国个人信息保护法》第21条（委托处理）：中国人大网公布文本。