01 · NIST云计算参考模型
NIST SP 800-145在其图1中给出了云计算参考模型：纵向为五层技术栈（设施层、虚拟化层、操作系统层、中间件层、应用层），三种服务模式在栈上的覆盖范围各不相同；横向为三类角色（云服务商、云客户、云经纪人等辅助角色）的行为视角。理解该模型的关键在于：服务模式的"层覆盖"决定了责任覆盖——IaaS只向下覆盖到虚拟化层，其上的操作系统、中间件、应用、数据全部由客户负责；PaaS覆盖到中间件层；SaaS则覆盖全部五层，客户主要保留数据治理与访问管理的责任。
阅读方法：各云服务商官网的"责任共担"图示（如AWS Shared Responsibility Model、Microsoft Azure共同责任、阿里云责任共担白皮书）均可在NIST参考模型的坐标系中定位。实务中建议以NIST模型为基准语言，叠加厂商文档的具体表述，避免不同团队对同一张图的理解漂移。
02 · 五大基本特征的安全含义
NIST SP 800-145定义的五大基本特征在带来业务价值的同时，各自携带结构性安全后果，这是责任架构设计的物理基础：
| 基本特征 | 业务价值 | 结构性安全后果 |
|---|---|---|
| 按需自助服务 | 用户无需人工审批即可开通资源 | 影子IT与影子云的直接成因：资源开通绕开安全评审，台账缺失——本课题CSPM资产发现（第6页）的首要动因 |
| 广泛的网络访问 | 随时随地经标准机制访问 | 默认面向互联网开放的管理面与API端点，凭证强度成为第一道也是最后一道闸门 |
| 资源池化 | 多租户共享物理资源，按需分配 | 侧信道、邻居噪声与"吵闹邻居"问题；虚拟化隔离强度成为CSP侧核心责任（属CSP设施层） |
| 快速弹性 | 资源随负载伸缩 | 资产清单分钟级过期；安全策略必须以"策略即代码"方式随资源同步伸缩，人工审批模式失效 |
| 可计量服务 | 用量透明、按量计费 | 计费日志成为天然的行为审计数据源；同时盗用资源挖矿的账单异常是云滥用的重要检测信号（第5页Tesla案例） |
03 · 三大服务模式责任矩阵
下表是三种服务模式的逐层责任矩阵（以主流公有云实践与NIST SP 500-307、CSA指南为基准归纳；"CSP为主"表示CSP承担主要实施责任，"客户为主"表示客户承担配置与运维责任，"共担"表示双方均有义务且需书面界定）：
| 栈层/事项 | IaaS | PaaS | SaaS |
|---|---|---|---|
| 物理设施/机房 | CSP | CSP | CSP |
| 虚拟化/宿主机 | CSP | CSP | CSP |
| 操作系统与补丁 | 客户 | CSP（托管基线） | CSP |
| 中间件/运行时 | 客户 | 共担 | CSP |
| 应用代码与配置 | 客户 | 客户 | 共担（租户配置） |
| 数据分类分级与加密 | 客户（密钥可自管） | 共担（密钥归属需界定） | 共担（数据控制者责任不可转移） |
| 身份与访问管理 | 客户（IAM全责） | 共担（平台身份+租户身份） | 共担（租户账号治理） |
| 日志与审计可见性 | 客户（需自行开启留存） | 共担 | 共担（依赖SaaS审计能力） |
| 网络边界与隔离 | 客户（安全组/VPC配置） | 共担 | CSP（多租户隔离） |
| 终端用户设备 | 客户全责（三种模式下客户均负责终端安全与浏览器访问控制） | ||
要点：矩阵中最易被忽视的是最后一行——终端用户设备在三种模式下均由客户全责。SaaS再"省心"，也解决不了员工终端被植入窃密木马后的会话劫持问题。这也是零信任（NIST SP 800-207）"永不信任、持续验证"架构在SaaS时代重新兴起的根本原因。
04 · 四大部署模式安全特征
| 部署模式 | 定义（SP 800-145） | 安全特征与责任要点 |
|---|---|---|
| 公有云 | 云基础设施面向公众或多行业客户开放，由云服务商拥有运营 | 责任分界最清晰（按服务模式矩阵执行）；共享租户环境依赖CSP虚拟化隔离强度；合规上需关注数据出境与所在地法律适用 |
| 私有云 | 基础设施仅为单一组织专用，可由该组织或第三方拥有运营 | 客户责任面最大（接近自建数据中心），但保留云的五大特征；管理上常见误区是"私有化=安全"，实际责任矩阵几乎全落在组织自身 |
| 社区云 | 由若干具有共同诉求的组织共享专用基础设施 | 需建立跨组织治理委员会统一基线；责任分界依赖成员间协议（SLA与AUP），是责任书面化需求最强的模式 |
| 混合云 | 两种及以上部署模式通过技术或标准化机制绑定、可移植 | 跨环境身份联邦、一致策略与数据流动审计是核心难题；责任矩阵需按环境分别绘制并标注衔接面（参见子课题05） |
05 · 三大责任灰区治理
5.1 灰区一：身份与访问管理
PaaS/SaaS中普遍存在"平台身份"（CSP管理）与"租户身份"（客户管理）的双层结构。灰区表现为：CSP控制台账号与业务账号的归属混乱、离职回收依赖人工、SaaS管理员权限范围无书面界定。治理要点：身份源（IdP）统一归客户侧管理，SaaS通过SAML/OIDC联邦接入；CSP控制台访问强制MFA并纳入客户IAM生命周期；所有跨层身份的创建、提权、注销留痕可审计。
5.2 灰区二：日志与审计可见性
IaaS下控制面日志（如AWS CloudTrail、Azure Activity Log）往往默认关闭或留存期很短；PaaS/SaaS下应用层日志的可见深度依赖厂商开放能力。灰区治理要求合同中明确：日志范围（管理面/数据面）、留存期限（中国《网络安全法》第21条要求网络日志留存不少于六个月）、客户可访问性、司法调取配合机制。未书面界定的日志可见性，等于放弃了事后举证能力。
5.3 灰区三：加密与密钥归属
三种密钥模型对应三种责任结构：CSP托管密钥（CSP持有密钥，客户仅控制数据）、客户主密钥托管于CSP KMS（共担，密钥使用可审计）、客户自持密钥（BYOK/HYOK，客户全责但可用性自担）。灰区风险在于"加密了但密钥在CSP手中"是否满足监管对密码应用的要求——中国商用密码管理框架下，云上密评（GB/T 39786-2021《信息安全技术 信息系统密码应用基本要求》）对密钥管理有明确控制要求，选型时必须前置确认。
合同条款最低要素清单（灰区书面化）：①数据存储位置与跨区域流动规则；②安全事件通知时限与配合义务；③客户审计权与第三方测评准入；④数据返还与删除证明（退出场景）；⑤分包商（subprocessor）变更通知机制。上述要素与GDPR第28条、中国《个人信息保护法》第21条受托处理条款高度同构，可作为中外合规的统一模板。
06 · 组织内责任矩阵制定与维护流程
| 触发事件 | 复审动作 | 责任归口 |
|---|---|---|
| 新增云服务商/区域 | 重绘该环境的责任矩阵，确认日志与密钥灰区条款 | 安全架构组 |
| 新增SaaS订阅 | 按SaaS责任行核查身份联邦、审计能力与退出条款 | IT采购+安全组 |
| 架构升级（如IaaS→PaaS迁移） | 重估上移的责任释放与新增灰区，更新CSPM监测范围 | 平台工程组 |
| 监管要求变化 | 对照等保2.0、云评估办法等更新合规举证列（第7页） | 合规与审计组 |
| 安全事件复盘 | 将事件根因回写矩阵（是否责任格无人认领），修订基线 | SOC+安全架构组 |
本节参考来源（第2页）
以下均为真实可查的权威来源，用于支撑本页事实性表述。
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。
AWS《AWS Shared Responsibility Model》官方文档与Microsoft Azure《Shared responsibility in the cloud》文档（各云厂商责任共担图示的官方表述，均可公开查证）。
CSA《Security Guidance for Critical Areas of Focus in Cloud Computing》系列指南：cloudsecurityalliance.org。
NIST SP 800-207《Zero Trust Architecture》（2020年8月）：csrc.nist.gov/pubs/sp/800/207/final。
《中华人民共和国网络安全法》（2017年6月1日施行，第21条日志留存要求）；《中华人民共和国个人信息保护法》（2021年11月1日施行，第21条委托处理条款）：中国人大网公布文本。
GB/T 39786-2021《信息安全技术 信息系统密码应用基本要求》（国家标准全文公开系统可查）。