企业官网建设流程全解析

Security-101 共享责任模型：云安全边界划分、IaaS/PaaS/SaaS 责任对照与"信任但验证"实践指南

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

本文基于 Security-101 开源网络安全入门课程第 1.6 课《共享责任模型》（匈牙利语翻译版，英文原版）编写。作为课程"基础安全概念"模块的第 6 课，本文旨在讲清：在云计算时代，安全控制（security controls）的责任如何在云服务提供商（CSP）与客户之间划分；IaaS、PaaS、SaaS 三种服务模型下责任边界有何不同；以及如何在接入第三方服务时落实"信任但验证"原则。读完本文，你将能准确判断云环境中的"防御空白区"归属，掌握查证云平台安全能力的标准方法，并建立跨团队落实安全责任的基本框架。

本课导读：你将学到什么

在开始深入之前，先明确本课要回答的四个核心问题，这也是整篇文章的主线：

• 网络安全语境下的共享责任到底是什么？
• IaaS、PaaS、SaaS 三种服务模型下，安全控制的责任划分有何不同？
• 去哪里可以查清你的云平台实际提供了哪些安全控制？
• 什么是**"信任但验证"（trust but verify）**原则，如何落地？

这四个问题层层递进：先建立概念，再对比模型，然后给出查证方法，最后落实到风险决策。

什么是网络安全语境下的共享责任模型

共享责任（shared responsibility）是 IT 领域相对较新的概念，它伴随着云计算的普及而产生。在传统自建数据中心模式中，安全责任通常由单一组织全权承担；而迁移到云环境后，安全责任被切分到云服务提供商（Cloud Service Provider，CSP）与客户双方。

从网络安全的角度看，准确理解"谁在提供哪些安全控制"至关重要——这是避免防御体系出现空白（gaps in defense）的前提。如果双方都以为某项控制由对方负责，该环节就会成为攻击者的突破口。

原文档给出了正式定义：共享责任在网络安全中指的是安全职责在云服务提供商及其客户之间的分配。在 IaaS（基础设施即服务）、PaaS（平台即服务）、SaaS（软件即服务）等云环境中，CSP 与客户在保障数据、应用和系统安全方面都扮演着各自的角色，任何一方都无法独自覆盖全部安全需求。

需要强调的是，共享责任不等于"责任减半"。它是一种职责划分机制，目的在于让每一层安全控制都有明确的负责人，从而保证防护的完整性与闭环。

IaaS、PaaS、SaaS 之间：安全控制的责任划分差异

责任如何切分，通常取决于所使用的云服务类型。三种主流服务模型下的责任边界如下（内容完整继承自原文档）：

• IaaS（基础设施即服务）：CSP 提供基础基础设施（服务器、网络、存储），而客户负责管理该基础设施之上的操作系统、应用程序和安全配置。可以理解为"云厂商交付机房与硬件抽象，客户接管虚拟化层以上的全部运维与加固工作"。
• PaaS（平台即服务）：CSP 提供可供客户构建和部署应用的平台。CSP 管理底层基础设施，客户则聚焦于应用程序开发和数据安全。操作系统补丁、运行时环境等由平台方托管，客户的责任重心上移至应用层。
• SaaS（软件即服务）：CSP 提供通过互联网访问的完整可用应用程序。此时 CSP 负责应用及其基础设施的安全，客户主要管理用户访问权限和数据使用。客户的防御重点收敛到身份与数据治理层面。

将三种模型对照来看，责任边界随抽象层级升高而不断向 CSP 一侧移动：

理解共享责任之所以关键，是因为它厘清了"哪些安全方面由 CSP 覆盖、哪些必须由客户自行处理"。这有助于防止双方产生误解，并确保安全措施得以整体性地（holistically）落实。从实践角度看，一个常见误区是客户默认"上云即安全"，而实际上——从上面表格可以推断——在 IaaS 场景下，客户操作系统补丁缺失、安全组配置错误等问题，责任完全在客户一侧；即便在 SaaS 场景下，若身份权限管理不当，同样会造成严重的数据泄露。

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

要搞清楚你的云平台究竟提供了哪些安全控制，原文档给出的答案是：研究云服务提供商的文档和资源。具体包括以下三类来源：

• CSP 官网与文档：CSP 官网会公布其服务所包含的安全功能与控制措施。大多数 CSP 提供详细的文档，说明其安全实践、控制项与建议，涵盖白皮书（whitepapers）、安全指南（security guides）和技术文档（technical documentation）等形式。
• 安全评估与审计（Security Assessments and Audits）：大多数 CSP 会邀请独立的安全专家和组织对其安全控制进行评估。这些审查结果能够反映 CSP 安全措施的质量水平，有时还会进一步促成 CSP 获得安全合规认证（见下一条）。
• 安全合规认证（Security compliance certifications）：大多数 CSP 会取得诸如 ISO 27001、SOC 2、FedRAMP 等认证。这些认证证明了服务商符合特定的安全与合规标准，是评估其安全成熟度的客观信号。

需要特别留意原文档的提醒：不同云服务商在信息详细程度与可获得性上可能存在差异。在做关于云资产安全的决策时，务必查阅 CSP 提供的官方且最新的资料，而不是依赖二手信息或过时文档。建议把"查证安全控制"固化为云选型流程中的固定环节，而不是事后的补救动作。

什么是"信任但验证"（Trust but Verify）原则

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

• 安全评估（security assessments）：对服务商的安全态势进行系统性评估，核对安全控制清单与声称的一致性；
• 渗透测试（penetration testing）：以攻击者视角检验服务商防护的真实有效性，验证其声称的安全边界是否站得住脚；
• 安全控制审查（review of the external party's security controls）：审阅服务商的架构、配置基线、日志与审计证据，确认控制项确实落地并持续运行。

原文档给出的结论是：所有个人和组织都应当对自己不负责的那些安全控制采取"信任但验证"的态度。这既是对共享责任模型的自然延伸，也是风险管理的基本纪律——把责任划给对方不等于放弃监督。

值得一提的是，这一原则与本课程第 1.5 课《零信任（Zero Trust）》形成了概念上的对照：零信任模型正是挑战了传统"信任但验证"的默认信任假设，主张"不信任任何实体，一律显式验证"。可以理解为，"信任但验证"是面对外部服务商时的务实基线，而零信任则是把这种审慎态度内化到自身架构的每一个访问请求中。两者共同构成了从供应商治理到内部架构设计的完整验证链条。

组织内部的共享责任

共享责任并不仅限于"客户 vs 云厂商"这一对关系。原文档明确指出，组织内部不同团队之间同样存在安全责任的共享，这一点同样需要被认真对待：

• 安全团队很少能够独立实现所有安全控制；
• 他们必须与运维团队、开发人员以及业务部门其他部分协作，才能落实组织保持安全所需的全部控制项。

从本课程的课程结构看（见 README.md 的模块总览），这种跨团队协作理念贯穿后续各模块——例如第 2 模块 IAM 需要与应用开发协作落地最小权限、第 4 模块 SecOps 需要与 IT 运维团队协同，本质上都是"共享责任"在组织内部的具体形态。可以推断，成熟的安全组织会把责任矩阵（RACI 式的职责划分）落实到具体团队与岗位，而不仅仅停留在"我们有一个安全团队"的层面。

在 Security-101 课程中的位置与延伸学习

本课是 Security-101 课程**模块一"基础安全概念"的第 6 课。根据 README.md 的课程说明，这是一门厂商中立（vendor agnostic）**的入门课程，每课约需 30～60 分钟，每课附有小测验和延伸阅读链接。模块一的整体脉络是：先掌握 CIA 三元组与基础概念（1.1）、常见威胁（1.2）、风险管理（1.3）、安全实践与文档（1.4）、零信任（1.5），再以共享责任模型（1.6）收束"边界与责任"这一主题，最后通过模块一期末测验检验学习效果。后续模块（IAM、网络、SecOps、应用安全、基础设施、数据安全、AI 安全）都建立在本文所讲的"谁负责什么"这一基础认知之上。

如果你希望继续深入本主题，原文档的"进一步阅读"部分列出了以下权威参考资料（均为通用安全知识出处，本文不附外部链接）：Microsoft Azure 官方文档中关于云共享责任的说明、TechTarget 关于共享责任模型的定义条目、CSO Online 对共享责任模型及其云安全意义的解读，以及 CIS（Center for Internet Security）关于云安全共享责任的博客文章。结合本文给出的"查证安全控制"方法，你可以根据自己使用的具体云平台，去其官方文档中定位对应的责任矩阵与安全控制清单。

本文依据 Security-101 仓库中的课程文档整理编写，事实性内容以原文档及仓库源码为准。

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