企业官网建设流程全解析

云安全共担责任模型深度解析：Security-101 网络安全入门课程 1.6 课全解读

【免费下载链接】Security-1018 Lessons, Kick-start Your Cybersecurity Learning.项目地址: https://gitcode.com/GitHub_Trending/se/Security-101

共担责任模型（Shared Responsibility Model）是云计算时代理解"谁为哪一层安全负责"的基石概念：云服务商（CSP）与客户各自承担一部分安全控制，只有双方责任无缝衔接，才能避免防御缺口。本文以本仓库 1.6 Shared responsibility model.md 为核心骨架，结合 Security-101 课程其他单元（零信任、CIA 三要素、安全策略体系）为你系统梳理该模型的来龙去脉、IaaS/PaaS/SaaS 三种服务形态下的责任划分、查证 CSP 安全能力的三大信息来源，以及"信任但验证"在采购和集成第三方安全服务时的落地方法。

一、本课导读：你将掌握的内容

本课是 Security-101 网络安全入门课程模块 1（基础安全概念）的第 6 节课，围绕共担责任模型回答四个核心问题：

1. 什么是共担责任模型：在网络安全语境下，CSP 与客户之间如何分配安全职责；
2. IaaS、PaaS、SaaS 的差异：服务形态不同，安全控制的责任分界线如何随之移动；
3. 如何查证 CSP 提供了哪些安全控制：官方文档、独立评估审计、合规认证三大信息来源；
4. 什么是"trust but verify"（信任但验证）：对不由自己掌控的安全控制，如何做到既信任又核实。

在开始之前，建议先阅读模块 1 的前序课程建立基础概念：1.1 CIA 三要素（机密性、完整性、可用性）和 1.5 零信任（默认不信任任何实体）。因为后续会看到：共担责任模型与零信任思想相互呼应——两者都强调"不默认信任、主动验证边界"。

二、什么是网络安全语境下的共担责任模型？

共担责任模型是随云计算普及而出现的新兴 IT 概念。传统自建机房中，从物理服务器到操作系统再到应用数据，全部由企业自己负责；而在云环境中，责任的"一堵墙"被拆成了两半：

共担责任 = 云服务商（CSP）与客户之间安全职责的分配。在 IaaS、PaaS、SaaS 各类云服务中，CSP 与客户都对数据、应用和系统的安全负有责任，只是各自负责的层次不同。

从网络安全视角看，理解"谁在提供哪些安全控制"至关重要，原因有二：

• 避免防御空白：如果双方都以为某层安全由对方负责，就会出现"灰色地带"，攻击者恰好可以从这里突破；
• 避免责任推诿：事故发生后，明确的职责划分决定了由谁响应、由谁修复、由谁承担后果。

原文档特别强调：理解共担责任有助于整体性地（holistically）落实安全措施，防止因职责不清导致的安全误解。

三、IaaS、PaaS、SaaS：责任分界线随服务形态移动

责任划分并非一成不变，而是取决于你使用的云服务类型。服务越"托管化"，CSP 承担的安全层就越多，客户需要自行管理的安全控制就越少。三者的责任分配如下：

3.1 IaaS：客户掌控面最大

在 IaaS 模式下，CSP 只提供地基（物理服务器、网络、存储），客户负责运营系统、应用和该基础设施上的安全配置。这意味着：

• 客户要负责打补丁、加固操作系统、配置防火墙规则、管理身份认证；
• 客户的云上资产如果被攻破，责任通常归客户——因为"门锁"是客户自己装的和自己管理的。

3.2 PaaS：客户从"运维"转向"开发"

PaaS 模式下，CSP 管理底层基础设施与运行平台，客户把精力聚焦在应用开发和数据安全上。客户仍需负责：

• 应用代码的安全（输入校验、身份认证逻辑、依赖漏洞）；
• 数据在应用层级的保护（谁可以读写哪些数据）；
• 平台配置失误导致的暴露面（例如错误开放的公网访问）。

3.3 SaaS：客户只需管"人和数据"

SaaS 模式下，CSP 负责应用软件与基础设施的全部安全，客户管理的范围收缩为用户访问与数据使用：

• 账号生命周期管理（入职开通、离职回收）；
• 权限分配与最小权限原则（结合 2.1 IAM 关键概念 中的 least privilege）；
• 多因素认证（MFA）的启用与推行。

一句话总结：从 IaaS 到 PaaS 再到 SaaS，责任分界线不断上移——客户失去对底层栈的控制权，换来了更少的安全运维负担，同时也意味着必须信任 CSP 替你管理的那部分安全控制（这正是第五节"trust but verify"的由来）。

四、为什么理解共担责任如此重要？

原文档给出了两个层面的理由：

1. 明确边界，消除误解：清晰的职责划分让你知道哪些安全方面由 CSP 覆盖、哪些必须自己解决，避免"我以为对方做了"的想当然；
2. 整体落实安全：只有双方责任拼图完整，安全措施才能无死角地覆盖整个系统生命周期。

结合本仓库课程体系，还可以把共担责任模型放到更大框架中理解：

• 与零信任互补：1.5 Zero trust.md 强调"不信任任何实体、持续验证"，而共担责任模型回答的是"验证的边界和责任归谁"；
• 与安全控制体系衔接：1.4 Security practices and documentation.md 介绍的策略（policy）、标准（standard）、基线（baseline）等文档体系，正是企业落实"自己那一半责任"的落地载体——例如"云虚拟机不得直接暴露公网"就是一条典型的安全基线。

五、如何查证你的云平台提供了哪些安全控制？

这是本课最具实操价值的部分：在选择云服务商、评估是否将业务迁入云端之前，你应当通过以下三类官方且最新的信息来源，摸清 CSP 到底提供了哪些安全控制：

5.1 CSP 官方网站与文档

CSP 官网通常提供：

• 白皮书（whitepapers）：阐述整体安全架构与治理理念；
• 安全指南（security guides）：按服务讲解安全特性与配置建议；
• 技术文档（technical documentation）：具体到每项服务的默认安全设置、可用的安全控制清单。

这些内容会明确写出"平台提供了什么"与"需要客户自己做什么"。

5.2 独立安全评估与审计

大多数 CSP 会邀请独立的第三方安全专家与机构对其安全控制进行评估。这类评估的价值在于：

• 提供独立于厂商宣传的客观视角；
• 能反映其安全措施的实际质量；
• 评估结果往往成为 CSP 获得合规认证的前提（见 5.3）。

5.3 安全合规认证

大多数 CSP 会争取获取主流合规认证，以证明其满足特定安全与合规标准，常见的有：

• ISO 27001：信息安全管理体系的国际标准；
• SOC 2：面向服务组织的控制鉴证报告，评估安全性、可用性、机密性等信任服务标准；
• FedRAMP：美国联邦政府认可的云服务安全评估与授权框架。

这些认证证书是"第三方背书"的强信号——意味着 CSP 的安全控制经过了独立审查并符合行业公认标准。

注意：原文档提醒，不同 CSP 在信息详实程度与可获取性上存在差异。务必查阅官方、及时更新的资料来做决策，切勿依赖过时或二手信息判断云上资产的安全边界。

六、什么是"trust but verify"（信任但验证）？

"信任但验证"是贯穿本课的安全方法论。当组织引入 CSP、第三方软件或其他 IT 安全服务时，通常一开始会信任供应商关于其安全措施的声明——但真正的安全不能建立在"对方说的"之上。

"trust but verify"要求你在完全集成该软件或服务之前，主动验证这些声明，验证手段包括：

• 安全评估（security assessments）：对供应商的安全控制做系统性核查；
• 渗透测试（penetration testing）：从攻击者视角测试其防护是否真实有效；
• 外部方安全控制审查（review of the external party's security controls）：逐项比对承诺与实现。

原文档给出的原则非常明确：所有个人和组织，都应当对自己不负责的那部分安全控制秉持"信任但验证"。这与 1.5 Zero trust.md 中"零信任挑战传统 trust but verify 模式"的表述形成有趣的呼应——零信任进一步升级为"永远验证、默认不信任"，而共担责任模型则告诉你"哪些控制值得你去验证"。

七、组织内部的责任共担：安全不是安全团队一个人的事

共担责任不仅存在于企业与云服务商之间，也存在于企业内部的不同团队之间。原文档明确指出：

安全团队很少能亲自落地所有控制，他们必须与运维团队、开发团队以及业务其他部门协作，才能实施维持组织安全所需的全套安全控制。

这意味着：

• 安全团队负责制定策略、标准和基线（见 1.4 Security practices and documentation.md）；
• 运维与开发团队负责在系统与应用层面落地这些要求（如 6.1 基础设施安全关键概念 中的加固、打补丁）；
• 业务部门负责人员与流程层面的配合（访问审批、安全培训）。

内部职责划分不清，同样会产生"人人有责、人人无责"的防御空白——这与云共担责任模型中的"灰色地带"如出一辙。

八、课程定位与本课之后的路径

本课属于 Security-101 课程模块 1：基础安全概念的第 6 课，紧接其后的是 1.7 模块测验。完成模块 1 后，你可以进入模块 2 起的具体领域安全课程，将共担责任的视角应用到各安全域：

• 2.1 IAM 关键概念：身份与访问管理（对应客户侧"用户访问"责任）；
• 3.1 网络关键概念：网络层安全（对应 IaaS 客户侧网络配置责任）；
• 6.1 基础设施安全关键概念：主机加固、补丁与容器安全（对应客户侧系统责任）；
• 7.1 数据安全关键概念：数据分类与留存（对应客户侧数据责任）。

原文档在"Further reading"一节提供了多篇外部权威资料（微软 Azure 共担责任文档、TechTarget 定义、CSO Online 解析、CIS 安全中心博客等），可在原文件 1.6 Shared responsibility model.md 中查看链接列表，按需深入阅读。

九、核心要点速记

• 共担责任模型= CSP 与客户之间安全职责的分配，随服务形态（IaaS/PaaS/SaaS）移动分界线；
• IaaS 客户管系统与应用，PaaS 客户管应用与数据，SaaS 客户只管用户访问与数据使用；
• 查证 CSP 安全控制三渠道：官方文档与白皮书、独立安全评估与审计、合规认证（ISO 27001 / SOC 2 / FedRAMP）；
• "trust but verify"：对不由自己负责的安全控制，先验证（评估、渗透测试、审查）再完全集成；
• 组织内部同样适用共担责任：安全团队须与运维、开发及业务部门协作落地控制；
• 与课程体系联动：共担责任模型与零信任（1.5）、安全文档体系（1.4）、CIA 三要素（1.1）共同构成模块 1 的完整安全世界观。

【免费下载链接】Security-1018 Lessons, Kick-start Your Cybersecurity Learning.项目地址: https://gitcode.com/GitHub_Trending/se/Security-101