企业官网建设流程全解析

Security-101 云安全共享责任模型（Shared Responsibility Model）深度解析：云服务商与客户的安全责任边界

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

共享责任模型（Shared Responsibility Model）是云安全中最重要的基础概念之一：它明确了云服务提供商（CSP）与客户之间各自承担哪些安全控制，避免安全责任出现空白地带。本指南以 Security-101 课程第 1.6 课（西语版原文，英文原版见 1.6 Shared responsibility model.md）为核心，系统讲解共享责任的由来、IaaS/PaaS/SaaS 三种服务模型下的责任划分差异、如何查证云平台真实提供的安全控制，以及"信任但要验证"（Trust but Verify）的落地方法，帮助你建立清晰的云安全责任边界意识。

什么是共享责任模型：随云计算而生的安全责任分配机制

共享责任是 IT 领域中相对较新的概念，它随云计算的出现而诞生。在传统本地（on-premises）环境中，企业自己拥有并运维从物理机房到应用层的全部基础设施，安全责任完全由自己承担；而在云环境中，基础设施归云服务商所有，安全责任的归属就变得模糊起来——服务器硬件加固由谁负责？虚拟机操作系统补丁由谁打？应用层的漏洞又由谁修复？

从网络安全角度看，理解"谁提供哪些安全控制"至关重要，因为一旦某一方默认另一方会负责某项安全措施，防御就会出现缺口（gaps in defense）。

共享责任模型正是用来回答这个问题的：它指的是云服务提供商（CSP）与其客户之间对安全责任的分配。在云计算环境中，无论是基础设施即服务（IaaS）、平台即服务（PaaS）还是软件即服务（SaaS），CSP 和客户在保障数据、应用和系统安全方面都有各自的角色需要履行。

这一概念在本课程中与模块 1 的其他基础概念一脉相承：模块 1.1 讲解的 CIA 三元组（机密性、可用性、完整性）定义了"要保护什么"，1.3 风险管理定义了"威胁、脆弱性、风险与控制"的关系框架，而共享责任模型则回答"这些控制具体由谁落地实施"这一组织与责任层面的问题。

IaaS、PaaS、SaaS 下的责任划分差异

责任的划分通常取决于所使用的云服务类型。三种主流服务模型下，CSP 与客户的责任边界如下：

• IaaS（基础设施即服务）：CSP 提供底层基础设施（服务器、网络、存储），而客户负责在该基础设施上管理操作系统、应用和安全配置。也就是说，从操作系统向上（OS 补丁、中间件、应用、数据、访问管理）的责任都属于客户，CSP 只负责到虚拟化层和物理设施。

• PaaS（平台即服务）：CSP 提供可供客户构建和部署应用的平台。CSP 管理底层基础设施（含操作系统、运行时环境），客户则聚焦于应用开发和数据安全。责任边界下移：客户不再需要关心服务器与 OS 补丁，但仍要负责自己编写的应用代码、数据以及访问配置。

• SaaS（软件即服务）：CSP 提供通过互联网访问的完整功能应用。此时 CSP 负责应用安全和基础设施安全，客户负责用户访问管理和数据使用。例如使用云邮箱、云办公套件时，服务商保障平台本身的安全，客户则需要做好账号权限、多因素认证和数据外发管控。

理解共享责任之所以关键，是因为它厘清了哪些安全方面由 CSP 覆盖、哪些需要客户自行处理，从而防止误解和推诿，确保安全措施被整体性地（holistically）实施。

上表是三种服务模型责任边界的高度概括（基于本课文档对 IaaS/PaaS/SaaS 的描述归纳）：责任边界越靠下，客户需要亲力亲为的控制越多；越往上走，CSP 承担的安全控制份额越大，但数据与访问管理始终是客户不可转移的责任。

如何查证云平台提供的安全控制

要弄清你的云平台实际提供了哪些安全控制，必须查阅云服务提供商的文档和资源。主要包括三类信息源：

• CSP 官网与文档：CSP 的网站会公布其服务所包含的安全功能与控制项，通常提供详细文档说明其安全实践、控制项和推荐做法，形式包括白皮书（whitepapers）、安全指南和技术文档。这是判断"平台能帮你做什么"的第一手依据。

• 安全评估与审计：大多数 CSP 会邀请独立的第三方安全专家与机构对其安全控制进行评估和审查。这些评审结果可以反映 CSP 安全措施的真实质量，有时还会推动 CSP 取得安全合规证书（见下一条）。

• 安全合规认证：大多数 CSP 会取得 ISO:27001、SOC 2、FedRAMP 等认证。这些认证表明提供商满足特定的安全与合规标准，可作为其控制有效性的第三方背书。

需要记住的是：不同云服务商在信息披露的详细程度和可用性上存在差异。务必以云服务商提供的官方、最新资源为准，据此对云上资产的安全做出知情决策——这正是"信任但要验证"在采购与选型阶段的直接应用。

"信任但要验证"：把信任建立在对等验证之上

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

• 安全评估（security assessments）：对照自身安全基线审查供应商的控制清单；
• 渗透测试（penetration testing）：主动探测其产品/服务是否存在可被利用的弱点；
• 审查外部方的安全控制：核对审计报告、合规证书与实际控制文档是否一致。

所有个人和组织都应本着"信任但要验证"的态度，去核查那些不由自己负责的安全控制——越是依赖对方，越要验证对方。这与本课程 1.5 零信任 中介绍的零信任理念形成递进关系：零信任从架构层面"挑战传统'信任但要验证'的假设"，主张对任何用户、设备、应用默认不信任、持续验证；而共享责任模型则从合同与责任层面提醒你，CSP 承诺的安全能力同样需要被独立验证，两者共同构成现代云安全的两大支柱。

组织内部的共享责任：安全从来不是安全团队的单打独斗

共享责任不仅存在于组织与云服务商之间，也存在于组织内部不同团队之间。安全团队很少会亲自实施所有控制，他们必须与以下角色协作才能落地全部必要的安全控制：

• 运维团队（operations）：负责系统加固、补丁管理、监控与故障响应等日常安全运营；
• 开发团队（developers）：负责在应用开发生命周期中落实安全编码、依赖治理与应用层控制；
• 业务部门（other parts of the business）：负责人员安全意识、业务流程中的数据使用规范等。

这呼应了 1.3 风险管理 中的观点：风险评估与控制实施通常横跨多个团队，极少由一个团队端到端包办。把"共享责任"这一概念同时应用到云服务商边界和内部团队边界两层，才能形成无死角的防御纵深。

本课在 Security-101 课程体系中的位置与后续路径

本课是模块 1（基础安全概念）的第 6 课，紧随零信任（1.5）之后、模块测验（1.7）之前。课程设计将每个小课控制在 30～60 分钟，模块 1 结束时可通过 1.7 模块测验 检验学习成果。

掌握共享责任模型后，你可以带着"责任边界"的视角继续深入学习后续模块：模块 2 的身份与访问管理（IAM）、模块 3 的网络安全、模块 4 的安全运营、模块 5 的应用安全、模块 6 的基础设施安全、模块 7 的数据安全，每一层能力最终都要回答"由谁负责落地"这一问题。课程总览见 README.md，该仓库还通过 Co-op Translator 提供了 50+ 语言的翻译版本（本课西语版即位于 translations/es 目录），供非英语读者对照学习。

小结：共享责任模型定义了云环境中 CSP 与客户的安全控制边界——IaaS 客户责任最重、PaaS 居中、SaaS 最轻，但数据与访问管理责任在任何模型下都无法转嫁；通过 CSP 官方文档、独立审计与合规认证可以核实平台真实能力；以"信任但要验证"的态度对待所有非己方负责的控制；同时在组织内部同样践行责任共担，与运维、开发、业务团队协同，才能构建完整、无缺口的云安全防线。

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