01 · 研究背景与意义
1.1 云计算成为默认基础设施，安全责任被重新划定
自2006年Amazon Web Services相继推出S3（3月）与EC2（8月）以来，"基础设施即服务"的商业模式确立并逐步成为数字化转型的默认底座。NIST SP 800-145（2011年）与ISO/IEC 17788（云计算词汇与概述）为云计算建立了跨组织的统一话语体系：五大基本特征（按需自助服务、广泛的网络访问、资源池化、快速弹性、可计量服务）、三大服务模式与四大部署模式。该定义的安全学意义在于：服务模式的每一次选择，都是一次安全责任的重新分配——IaaS下云客户负责操作系统及以上全部栈层，SaaS下绝大部分责任上移至云服务商，PaaS居于两者之间。责任分配的正确认知与持续维护，构成了云安全治理的全部起点。
1.2 共享责任模型：被误用最广的安全概念
共享责任模型（Shared Responsibility Model）由云服务商在多年实践中逐步表述成型，并得到NIST SP 500-307（NIST云计算安全与隐私指南文献）、CSA指南等权威文献的系统化整理。其核心是"CSP负责云自身安全（security of the cloud），客户负责云内安全（security in the cloud）"。但在工程实践中，这一模型存在三类系统性误用：
- 误用一："上了云，安全就归厂商管"。SaaS模式下责任确实大幅上移，但数据分类分级、账号与身份治理、终端安全、合规举证等责任仍不可转移；IaaS/PaaS模式下客户责任面更大。多起数据泄露事件的根因即为客户侧错误配置而非CSP设施被攻破。
- 误用二："责任矩阵签一次就够了"。责任边界随架构演进持续漂移：新增一个SaaS订阅、启用一项托管服务、引入一个无服务器函数，都无声地改写了责任分配。CSA将"配置错误与变更控制不足"列为云顶级威胁之首，其机制正在于此。
- 误用三："责任可委托，问责也可委托"。无论责任如何分配，数据控制者对监管与用户的最终问责不可外包（参见GDPR第28条处理者条款与《个人信息保护法》第21条委托处理条款的共性问题）。
1.3 本课题的三个结构性挑战
| 挑战 | 内涵 | 本课题应对（对应页） |
|---|---|---|
| 责任灰区 | PaaS/SaaS中身份管理、日志可见性、加密密钥归属等交叠地带责任模糊，事故归因与举证困难 | 第2页：责任矩阵与灰区治理 |
| 配置复杂性 | 云IAM策略语言、存储桶策略、安全组与网络ACL的表达能力极强，默认宽松+人工维护必然产生错误配置 | 第3页：错误配置模式库与IAM治理 |
| 合规多锚点 | 中国等保2.0云扩展要求、云计算服务安全评估办法与ISO 27017/27018、CSA CCM多套体系并存，控制项交叉引用成本高 | 第4、7页：控制映射与合规体系 |
认知纠偏："通过ISO 27001或SOC 2认证的云服务商，其平台上的应用天然合规"——这一推论不成立。ISO 27001证书覆盖的是CSP管理体系的特定范围（scope），既不覆盖客户侧配置，也不覆盖客户数据的使用合规性。共享责任的正确打开方式是：以责任矩阵为纲，以CSPM持续审计为目，以书面合同与SLA固化双方义务。
02 · 研究目标与关键问题
- 模型完备性目标：建立覆盖"服务模式×部署模式×数据生命周期"三维的责任矩阵模型（第2页），并对身份、日志、密钥三大灰区给出书面化界定模板。
- 风险可测目标：建立云错误配置的模式库（pattern library）与严重度分级，使"配置风险"成为可度量、可跟踪、可自动检测的资产属性（第3页）。
- 控制可映射目标：建立CSA CCM v4、ISO/IEC 27017/27018与国内等保2.0云扩展要求之间的控制项映射表，支撑一套证据、多方举证（第4、7页）。
- 运营可持续目标：形成"CSPM持续监测→漂移告警→自动修复→合规报表"的运营闭环规范（第6、8页），并给出分级分域的成熟度模型。
2.1 三个关键研究问题（KQ）
| 编号 | 关键问题 | 内涵说明 | 对应章节 |
|---|---|---|---|
| KQ-1 | 责任灰区的边界划法 | 在PaaS/SaaS组合架构中，身份联合、日志可见性、密钥归属、备份责任等灰区如何书面界定？界定条款应覆盖哪些最低要素（数据位置、泄露通知时限、审计权、退出与数据返还）？ | 第2页 |
| KQ-2 | 错误配置的系统性检测 | 模式库应覆盖哪些配置类别（存储/IAM/网络/日志/加密）？不同类别错误的发现率、修复时效与误报成本如何权衡？自动修复的护栏（guardrail）如何设计？ | 第3、6页 |
| KQ-3 | 多合规锚点的证据复用 | 一次技术测评的证据如何同时满足等保2.0、云评估办法、ISO 27017与STAR的举证要求？控制项映射的粒度（条款级 vs 目标级）如何选取？ | 第4、7、8页 |
03 · 生态参与方与演进时间线
3.1 生态参与方与职责
| 角色 | 职责/产出 | 代表 |
|---|---|---|
| 标准与定义机构 | 云计算定义、安全控制指南、供应链安全要求的权威发布 | NIST（SP 800-145、SP 500-307、SP 800-53 Rev.5云控制补充）、ISO/IEC JTC 1/SC 27（27017、27018、17788/17789） |
| 行业联盟 | 云威胁研究、控制矩阵、认证体系与最佳实践 | 云安全联盟CSA（CCM、CAIQ、STAR、Top Threats系列报告） |
| 监管与治理机构 | 云上合规制度、评估办法、安全事件通报与执法 | 中国：中央网信办、工信部、公安部（等保）、国家密码管理局（密评）；美国：CISA、FTC（云数据泄露执法） |
| 云服务商 | 云自身安全、共享责任文档、透明度报告、合规白皮书 | AWS、Microsoft Azure、Google Cloud、阿里云、腾讯云、华为云及其责任共担白皮书与合规资源页 |
| 第三方评估与工具社区 | 测评认证、配置核查基线、CSPM/CIEM工具 | 认证机构（STAR注册与审计）、CIS（各云平台Benchmark）、开源社区（Prowler、ScoutSuite、Cloud Custodian） |
3.2 领域演进关键时间线
| 时间 | 事件（均可公开查证） |
|---|---|
| 2006 | AWS S3（3月）与EC2（8月）相继推出，IaaS商业模式确立，云安全问题随之进入产业视野 |
| 2011 | NIST SP 800-145（9月）发布，云计算三大服务模式/四大部署模式获得权威定义；ISO/IEC 17788/17789系列随后跟进 |
| 2013—2015 | CSA发布CCM v3与Top Threats系列早期版本；ISO/IEC 27017（2015年发布）与27018（2014年发布、2019年更新）确立云服务控制与PII保护国际基线；AWS首创将"责任共担"图示化写入官方文档 |
| 2017—2019 | 多起大规模云错误配置泄露事件集中曝光（Deep Root Analytics 2017、Exactis 2018、Capital One 2019年3月发生/7月披露、Docker Hub 2019年5月）；中国等保2.0（GB/T 22239-2019）发布并于2019年12月1日实施，设云计算安全扩展要求；《云计算服务安全评估办法》2019年发布施行（2019年9月1日施行） |
| 2020—2021 | CSPM品类成熟并被Gartner纳入云工作负载保护平台（CWPP）向CNAPP演进的报告体系；CSA CCM v4（2021年发布）控制项大幅扩充；SolarWinds与Log4Shell事件使供应链成为云安全核心议题 |
| 2022—2023 | 身份优先安全兴起：CIEM（云基础设施权限管理）从CSPM中分化成独立品类；多云/混合云策略漂移检测与"策略即代码"（OPA、Terraform Sentinel）普及 |
| 2024至今 | CISA发布云安全相关基线指南（如安全业务应用程序开发与云基线方向）；CSPM向CNAPP+DSPM（数据安全态势管理）扩展；国内云上密评、数据安全评估与云评估办法形成叠加合规格局 |
04 · 术语速查与常见误区
4.1 核心术语
| 术语 | 释义 |
|---|---|
| 共享责任模型 | 云服务商与云客户按服务模式划分安全责任的框架：CSP负责"云自身安全"，客户负责"云内安全"，边界随服务模式变化（NIST SP 500-307、CSA及各大云厂商文档均有表述） |
| CSPM | Cloud Security Posture Management，云安全态势管理：对云资源配置进行持续核查、漂移告警与合规映射的产品品类 |
| CIEM | Cloud Infrastructure Entitlement Management，云基础设施权限管理：聚焦身份权限过度授予的发现与收敛（CSPM的身份维度深化） |
| 错误配置（Misconfiguration） | 资源配置偏离安全基线或业务意图的状态，如公开可读存储桶、0.0.0.0/0安全组、*:* IAM权限——CSA Top Threats将其列为云顶级威胁之首 |
| IMDS | Instance Metadata Service，实例元数据服务：云主机内查询自身元数据与临时凭证的链路（AWS IMDSv1/v2），SSRF攻击的经典目标 |
| CAIQ | Consensus Assessments Initiative Questionnaire，CSA共识评估倡议问卷：基于CCM控制项的供应商自评估问卷，STAR自评估的技术载体 |
| SSRF | Server-Side Request Forgery，服务端请求伪造： Capital One事件的核心漏洞类型，被用于访问实例元数据端点窃取临时凭证 |
| 配置漂移（Drift） | 资源运行配置偏离已声明基线的渐进变化，多源团队协作与紧急变更的高发后果 |
4.2 常见误区辨析
| 误区 | 辨析 |
|---|---|
| "云服务商通过了ISO 27001，客户就高枕无忧" | ISO 27001证书有明确的适用边界声明（Statement of Applicability），覆盖CSP自身管理域，不覆盖客户侧错误配置与数据使用合规。共享责任意味着客户侧永远存在不可转移的责任面。 |
| "错误配置只是低级失误，与攻击面无关" | 公开可读存储桶+桶内凭证文件=凭据失陷；宽松安全组+未打补丁管理端口=初始访问入口。第5页事件档案中多起事件的完整攻击链均由单一错误配置起步。 |
| "IMDSv2上线后元数据安全问题即告终结" | IMDSv2以会话令牌阻断无会话令牌的GET请求，大幅抬高SSRF利用门槛，但应用若将令牌回显、或实例角色权限过宽，残余风险仍在。纵深防御要求"IMDSv2+角色最小权限+SSRF出口收敛"三件套同时落地。 |
| "多云环境照搬单一云厂商基线即可" | 不同厂商的默认配置、策略语言与原生安全能力差异显著（如默认加密、日志默认开关、IAM策略评估逻辑），跨云基线必须做策略等价性翻译与漂移检测（第6页展开）。 |
05 · 研究范围与合规边界
- 对象范围：公有云IaaS/PaaS/SaaS与混合云/多云环境下的责任架构、错误配置治理、控制映射与合规评估；覆盖企业上云全生命周期（选型、迁移、运营、退出）。
- 深度边界：做到"责任矩阵→配置基线→持续审计→合规举证"层面；具体产品渗透测试与云上数据安全技术（加密、脱敏、密钥管理内部机制）属本子课题02/数据安全课题范围。
- 协同边界：容器与Kubernetes编排基线属子课题02；供应链签名验证属子课题03；Serverless权限收敛属子课题04；多云统一身份与策略漂移属子课题05；本课题为其提供责任架构与CSPM方法底座。
- 时效声明：所引标准均为现行有效版本（GB/T 22239-2019、CSA CCM v4等）；事件事实以官方披露与司法文件为准；不虚构精确数值，统计口径不明处明确标注。
合规与伦理声明：①本子课题为防御研究与合规方法论研究，遵守《网络安全法》《数据安全法》《个人信息保护法》及网络安全等级保护制度；②文中错误配置检测方法仅用于自有云环境或书面授权范围内的安全核查，不构成对第三方云资源的探测指引；③涉及云上个人信息处理的建议均遵循最小必要与告知原则；④引用CSA、NIST等境外标准仅作方法论参照，国内合规以现行法律法规与国家标准为唯一准绳。
06 · 与课题体系的协同关系
| 协同子课题 | 数据/方法交换内容 |
|---|---|
| 02 容器与Kubernetes安全 | 本课题的IAM最小权限与CSPM审计方法下沉至K8s控制面（ServiceAccount令牌、RBAC核查）；K8s CIS Benchmark核查结果回传本课题作为配置基线的集群层证据 |
| 03 云原生软件供应链与镜像安全 | CI/CD流水线凭证的权限治理遵循本课题IAM基线（短期凭证、最小授权）；本课题为其SBOM/签名验证提供云侧存储与访问控制基线 |
| 04 Serverless与函数计算安全 | 函数执行角色权限收敛直接复用本课题CIEM方法；事件源注入的输入校验基线作为函数配置基线的一部分 |
| 05 多云与混合云统一防护 | 本课题的责任矩阵模板扩展至跨云场景；其"策略等价性"方法解决本课题多云基线漂移问题；统一身份治理的联邦信任链审计双向复用 |
| 06 云安全合规与评估 | 本子课题第4、7页的控制映射与证据复用方法为其测评执行提供操作层支撑；其等保测评发现的问题回流本课题配置基线库 |
07 · 预期成果与交付物
- 《云安全责任矩阵模板与灰区界定指引》（服务模式×部署模式矩阵、三大灰区书面条款模板，第2页）
- 《云错误配置模式库与IAM治理基线》（五大配置类别模式库、严重度分级、IMDSv2/SSRF三件套基线，第3页）
- 《CSA CCM v4 控制映射表与STAR认证路径指南》（CCM↔ISO 27017↔等保2.0云扩展三方映射，第4、7页）
- 《云错误配置事件档案与攻击链复盘集》（Capital One等六案例的深度复盘模板，第5页）
- 《CSPM/CIEM工具链选型与工程流水线规范》（开源+商业工具对照、监测-告警-修复闭环，第6页）
- 《云安全治理成熟度模型与12个月实施路线》（五级成熟度、季度路线图，第8页）
本节参考来源（第1页）
以下均为真实可查的权威来源（NIST、ISO、CSA、IETF官方档案、公司官方披露与司法文件），用于支撑本页事实性表述。
NIST SP 800-145《The NIST Definition of Cloud Computing》（2011年9月）：csrc.nist.gov/pubs/sp/800/145/final。
NIST SP 500-307《Security and Privacy Controls for Cloud Computing》及NIST云计算安全工作组文献：csrc.nist.gov。
云安全联盟CSA：CCM云控制矩阵（v4，2021）、CAIQ问卷、STAR认证与Top Threats系列报告：cloudsecurityalliance.org/research。
ISO/IEC 27017:2015（云服务信息安全控制措施）与ISO/IEC 27018:2019（公有云PII保护）：iso.org。
GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》——国家标准全文公开系统：openstd.samr.gov.cn；《云计算服务安全评估办法》（2019年发布，2019年9月1日施行）：cac.gov.cn。
Capital One数据泄露事件：公司2019年7月官方披露（capitalone.com/facts2019）与美国司法部案件信息（justice.gov）；Paige Thompson于2022年被西雅图联邦法院定罪。
CIS Benchmarks（AWS/Azure/GCP/Foundation Benchmarks等）：cisecurity.org/cis-benchmarks。
Durumeric Z.等《ZMap: Fast Internet-Wide Scanning and Its Security Applications》（USENIX Security 2013）——全互联网测量研究伦理参照（Menlo Report：caida.org）。