共同责任模型：IaaS、PaaS、SaaS

云服务主要通过三种模型交付，每种模型提供不同程度的抽象。基础设施即服务（IaaS）提供原始的计算、存储和网络资源。平台即服务（PaaS）进一步提供 OS、中间件和运行时环境。软件即服务（SaaS）通过互联网交付功能完整的应用程序。理解这些模型至关重要，因为它们之间的安全责任差异非常大。

共享责任模型规定哪些安全任务由云服务提供商负责，哪些任务由客户负责。该模型通常概括为：提供商负责云本身的安全（实体数据中心、虚拟机监控程序和网络基础设施），而客户负责云内部的安全（数据、访问管理、应用程序安全和配置）。误解这一边界，是导致云安全事件的主要原因之一。

在IaaS中，客户承担最多的安全责任。云服务提供商负责保护实体基础设施、虚拟机监控程序和网络结构。客户负责：OS 安装、修补和加固；运行时和中间件配置；应用程序安全；网络安全组规则；IAM 策略和用户管理；静态数据和传输中数据的加密；以及合规配置。IaaS 提供最大的控制权，但也需要投入最多的安全工作。

在PaaS中，提供商接管 OS 和运行时管理。客户不再负责修补操作系统或管理中间件，这些工作由提供商处理。不过，客户仍负责：应用程序代码安全（不得存在 SQL 注入、XSS 等问题）、数据分类和加密、身份与访问管理、应用程序配置（环境变量、机密信息管理），以及应用程序接口安全。PaaS 将部分负担转移给提供商，让客户专注于应用程序逻辑。

在SaaS中，提供商几乎负责所有工作。客户主要承担以下安全责任：访问管理（哪些人拥有账户、强制使用 MFA、审查权限）、数据治理（上传哪些数据、保留多长时间）、配置安全（隐私设置、共享权限、第三方集成），以及可接受使用合规性。许多 SaaS 数据泄露事件源于共享设置配置错误或第三方应用权限过度，而不是提供商发生故障。

有些控制由提供商和客户共同负责。例如加密：云提供商可能提供加密服务（KMS、默认加密），但客户必须启用这些服务、配置密钥管理并选择适当的算法。同样，对于身份管理，提供商提供 IAM 工具，但客户必须配置最小权限 policy 并强制执行 MFA。误以为提供商会处理共享控制，却不进行相应配置，是一种常见且危险的错误。

共享责任模型最常因客户配置错误而失效，而不是因为提供商发生故障。典型案例包括：S3 bucket 保持公开访问状态（Capital One 2019 年数据泄露，1 亿条记录暴露）、允许权限提升的权限过于宽泛的 IAM 角色、在敏感端口上配置入站 0.0.0.0/0 规则的安全组，以及部署在云中的数据库仍使用未更改的默认凭据。提供商底层基础设施是安全的，问题出在客户的配置上。

共享模型中的一个关键挑战是可见性。在本地部署环境中，安全团队可以控制所有日志记录。在云中，提供商基础设施的日志可能无法访问。客户必须启用云原生日志服务：AWS CloudTrail、Azure Monitor 和 GCP Cloud Audit Logs 会记录 API 调用和配置变更。如果不启用这些服务，组织就没有云环境中“谁在何时做了什么”的审计轨迹，这会造成严重的合规与取证缺口。

当组织使用托管服务提供商（MSP）运营云环境时，责任会分成三方。客户必须确保合同（SLA 和 DPA）明确规定安全义务。通过 SaaS 访问的第三方云应用会引入额外复杂性：向权限过于宽泛的应用授予 OAuth 同意后，该应用便可以访问您的数据。审查并定期审计第三方 OAuth 同意，是 SaaS 安全卫生的一部分。

工作负载迁移到云中，并不意味着合规要求会消失。HIPAA 要求处理 PHI 的云提供商签署商业伙伴协议（BAA）；AWS、Azure 和 GCP 都提供 BAA。PCI-DSS 要求云环境处于评估范围之内；提供商提供的共享责任矩阵会记录哪些 PCI 控制已经满足。组织必须了解提供商负责哪些内容，以及自身必须实施哪些内容，才能通过审计。

共享责任模型具有法律效力。云提供商的服务条款和服务级别协议（SLA）规定可用性保证及例外情况。GDPR 下的数据处理协议（DPA）规定处理方的义务。如果泄露是由提供商一方的故障造成的，客户可以依据 SLA 要求补救。如果泄露源于客户配置错误，提供商不承担责任。理解合同与理解技术控制同样重要。

请测试您对本课 CompTIA Security+（SY0-701）概念的理解。

本课您学习了：共享责任模型定义了 IaaS、PaaS 和 SaaS 中提供商与客户各自承担的安全义务；在 IaaS 中客户承担的安全责任最多，在 SaaS 中最少，但访问管理和数据治理始终由客户负责；以及客户配置错误，而非提供商故障，是云环境数据泄露的主要原因。接下来我们将探讨云存储安全和数据暴露风险。