企业官网建设流程全解析

Security-101 第 1.6 课深度解读：云安全共同责任模型（Shared Responsibility Model）入门与实践

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

共同责任（Shared Responsibility）是云计算时代诞生的新型安全理念：云上的安全不再由单一一方独立承担，而是由云服务提供商（CSP）与客户按服务模式共同分担。本篇技术指南围绕开源课程 Security-101 的第 1.6 课（共享责任模型）展开，系统讲解共同责任的定义、IaaS/PaaS/SaaS 三种服务模式下的责任划分差异、如何查证云平台实际提供的安全控制，以及"信任但要验证"（Trust but Verify）这一核心实践原则。读完本文，你将掌握判断"云安全到底该由谁负责"的方法论，并能在选型与日常运维中准确识别责任边界、消除防御空白。

本课概览：四个核心问题

本课是 Security-101 课程模块 1（基础安全概念）的重要组成部分，围绕四个核心问题展开：

1. 在网络安全语境下，共同责任（Shared Responsibility）是什么？
2. 在 IaaS、PaaS、SaaS 三种服务模式下，安全控制的共同责任有何差异？
3. 如何获知你的云平台正在提供哪些安全控制？
4. "信任但要验证"（Trust but Verify）意味着什么？

这四个问题共同构成了云安全责任边界分析的完整框架，也是后续理解零信任架构、IAM 身份与访问管理等课程内容的重要前置知识。

什么是网络安全语境下的共同责任

网络安全中的共同责任，指的是安全责任在云服务提供商（CSP）与其客户之间的分配。在 IaaS、PaaS、SaaS 等云计算环境中，CSP 与客户都承担着确保数据、应用程序和系统安全的一部分角色——没有任何一方能够（或应该）独自承担全部安全义务。

理解共同责任之所以关键，在于它清晰地划定了哪些安全方面由 CSP 覆盖、哪些需要客户自行处理。这种清晰的边界划分能够：

• 防止"我以为你负责"的误解，避免责任真空；
• 确保安全措施被整体性（holistically）实施，而不是各自为政；
• 帮助组织在采购云服务前就形成明确的安全预期与合同约束。

从课程定位看，Security-101 是一套**供应商中立（vendor-agnostic）**的入门课程（参见 AGENTS.md），因此本课讲解的是适用于任何云厂商的共同责任通用框架，而非绑定某一家厂商的具体控制项。

IaaS、PaaS、SaaS 下安全控制的共同责任差异

责任划分通常取决于所使用的云服务类型。责任边界随服务抽象层次的提高而向 CSP 一侧移动：你管理的东西越少，CSP 负责的范围就越大。三种模式的典型划分如下：

IaaS：客户承担最重的安全职责

在 IaaS 模式下，CSP 提供的是"地基"——物理服务器、虚拟化层、网络与存储。客户则需要对地基之上的操作系统、应用程序和安全配置负责，包括补丁管理、系统加固、网络 ACL、加密设置等。这一模式对客户的安全能力要求最高，相当于云厂商交给你一间"毛坯房"，内部装潢与安防系统都要自己搭建。

PaaS：平台托管、应用与数据归客户

PaaS 模式下，CSP 托管底层基础设施（运行时、中间件、数据库服务等），客户专注于应用开发与数据安全。责任边界上移到应用层：CSP 保证平台的可用与安全，客户则要保证自己写的代码、处理的数据以及应用配置的安全。

SaaS：客户责任最轻但并非为零

SaaS 交付的是开箱即用的完整应用。此时 CSP 负责应用本身的安全与基础设施，但客户仍需管理用户访问（身份与授权）和数据使用——例如谁能登录、谁能访问哪些数据、数据如何被使用和导出。即便在责任最轻的 SaaS 模式下，客户也绝不是"甩手掌柜"。

这种"责任随抽象层次移动"的规律，可以与本课程模块 2 的身份与访问管理（IAM）内容相互印证：无论采用哪种云服务模式，用户访问与权限管理始终是客户不可让渡的责任，这也是云时代"身份即新边界"理念（见 2.2 IAM 零信任架构）的由来。

如何获知云平台提供了哪些安全控制

要准确了解云平台实际提供哪些安全控制，需要查阅云服务提供商的官方文档与资源。本课给出了三条主要途径：

CSP 官网与安全文档

CSP 官网会公布作为其服务一部分而提供的安全特性与控制信息。成熟云厂商通常提供详细文档，说明其安全实践、控制项与推荐配置，形式包括：

• 白皮书（whitepapers）：阐述安全架构与设计原则；
• 安全指南（security guides）：给出具体的配置与加固建议；
• 技术文档：涵盖具体的控制项、API 与合规能力。

安全评估与审计报告

大多数 CSP 会邀请独立的第三方安全专家与组织对其安全控制进行评估。这些评估报告能够反映 CSP 安全措施的质量水平，并经常成为其获得安全合规认证（见下一点）的依据。评估与审计报告是客户在采购决策前核验供应商安全能力的重要证据。

安全合规认证

大多数 CSP 会取得行业公认的合规认证，常见的有：

• ISO 27001：国际公认的信息安全管理体系标准；
• SOC 2：面向服务组织的信任服务标准，覆盖安全性、可用性、处理完整性、保密性与隐私；
• FedRAMP：美国联邦政府采用的云服务安全评估与授权框架。

这些认证表明供应商达到了特定的安全与合规标准，可以作为责任边界判断的客观锚点。

需要提醒的是，不同云厂商在信息详细程度与可获得性上存在差异。始终以 CSP 提供的官方、最新资源为准，才能对云上资产的安全做出明智决策。这也是本课程反复强调"以官方权威来源为准"的原因——课程文档中明确建议读者不要依赖二手或过时信息。

"信任但要验证"（Trust but Verify）

在使用 CSP、第三方软件或其他 IT 安全服务时，组织可能最初会信任供应商关于安全措施的声明。但为了真正保障自身数据与系统的安全，组织应在将该软件或服务完全集成到日常运营之前，通过以下方式验证这些声明：

• 安全评估：对供应商的安全态势进行系统化审查；
• 渗透测试：以攻击者视角主动探测其防护的有效性；
• 第三方安全控制审查：独立核查外部方安全控制的落地情况。

本课强调的原则非常明确：所有个人与组织，都应对那些不由自己负责的安全控制"信任但要验证"。信任是起点，验证才是保障——这与课程零信任（Zero Trust）一课所倡导的理念一脉相承：零信任正是对"信任但要验证"的彻底化，即默认不信任任何实体，无论其位于网络内部还是外部。可以说，"信任但要验证"是零信任思想在供应商关系维度的具体体现。

组织内部的共同责任

共同责任不仅存在于组织与云厂商之间，也存在于组织内部的不同团队之间。安全团队很少能够独自实施所有安全控制，他们必须与以下角色协作：

• 运维团队：负责日常系统运维与环境管理中的安全控制落地；
• 开发者：在应用开发生命周期中落实安全编码与配置要求；
• 业务部门：提供业务上下文，配合安全政策与流程的执行。

课程风险管理（1.3）一课中同样强调，风险评估通常由组织内多个团队协同完成，很少由一个团队端到端负责。这与本课的结论一致：安全是组织级的分工协作，而非安全团队的独角戏。明确内部责任矩阵，才能让每项安全控制都有明确的"第一责任人"。

在本课程中的位置与学习路径

本节内容属于 Security-101 课程的模块 1（基础安全概念），与以下课程内容构成递进关系：

课程整体设计为 8 个模块、每课 30~60 分钟的入门节奏（参见 README.md 与 AGENTS.md），本课属于模块 1 的倒数第二课，其后是模块 1 的章节测验。

延伸学习建议

本课在"进一步阅读"中推荐了若干权威资源，读者可按需深入：

• Microsoft Learn的《Shared responsibility in the cloud》文档：系统阐述云中共同责任模型及其在 Azure 中的具体呈现；
• TechTarget的共同责任模型定义条目：提供简洁的术语级解释；
• CSO Online的共同责任模型解析：从云安全实践角度展开说明；
• CIS（Center for Internet Security）的云安全共同责任博客：从行业安全基准视角给出要点。

这些资源从定义、实践与合规多个维度补充了本课内容。建议读者在完成本课学习后，结合课程测验自测，并对照自己正在使用或评估的云服务，实际梳理一遍"责任清单"，将概念落地为可执行的检查项。

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