在企业上云过程中，“安全”始终是一个无法回避、也不能回避的话题。无论是刚开始引入云服务的中小型企业，还是已经完成核心业务系统上云的大型组织，云安全都不再只是技术问题，而是直接关系到业务连续性、合规要求以及企业长期可持续发展的核心能力。
随着业务系统逐步云化，企业 IT 架构从封闭、可控的本地环境，转变为更加开放、弹性的云环境。如果仍然沿用传统数据中心时代的安全认知，很容易在权限设计、系统边界、责任划分等方面出现认知错位，进而放大安全风险。
与传统数据中心不同，云计算并不是简单的“外包 IT 基础设施”，而是一种基于平台能力的责任协作模式。云服务商与客户之间，并非“甲方交钱、乙方兜底”的关系，而是各自承担清晰、明确、不可替代的安全责任。如果缺乏对这一点的正确理解，企业往往会在架构设计、权限管理、合规审计和运营治理等关键环节埋下隐患。
正是为了帮助客户建立统一、清晰且可落地的安全认知，AWS 提出了 Shared Responsibility Model（共享责任模型）。该模型通过明确 AWS 与客户在云环境中的安全职责边界，为企业构建云上安全体系提供了一个可靠、清晰、可执行的基础框架，是理解 AWS 云安全能力的核心前提。
作为 AWS 官方代理商，在云上在大量企业上云与云原生改造项目中发现：
只有真正理解并正确落实共享责任模型，企业才能在 AWS 云上构建稳定、合规、可持续演进的业务系统，而不仅仅是将传统系统简单地“迁移”到云上。
什么是 AWS Shared Responsibility Model？
AWS Shared Responsibility Model 是 AWS 定义的一套安全责任划分框架，用于明确在云计算环境中：
- 哪些安全责任由 AWS 负责
- 哪些安全责任需要由客户自行承担
该模型并非针对某一款具体服务，而是适用于 AWS 整体云平台及其服务体系，是 AWS 云安全设计的底层逻辑。
其核心理念可以概括为一句话：
AWS 负责“云的安全（Security of the Cloud）”，
客户负责“云上的安全（Security in the Cloud）”。
这一定义并非一句抽象口号，而是直接决定了云上安全事故发生后“谁该为哪一部分负责”的判断基础，也影响着企业的安全架构设计、审计边界和治理分工。
共享责任模型的真正意义，并不在于“谁承担的责任更多”，而在于责任边界是否足够清晰，是否具备可执行性。只有责任划分明确，安全治理才能真正落地，否则即便投入了大量安全工具，也可能因为责任错位而效果有限。
AWS 通过统一托管复杂、规模化的基础设施安全，极大降低了企业在硬件、机房和底层防护方面的投入；同时，保留客户对数据、身份、应用和业务规则的完全控制权，使企业既能充分利用云平台的规模优势，又不会失去对核心资产的主导权。
AWS 负责的内容：云的安全（Security of the Cloud）
AWS 负责的是云平台本身的安全，这些安全控制主要集中在基础设施层面，对客户而言通常是“不可见、不可直接操作”的部分。
1. 全球基础设施安全
AWS 在全球范围内建设和运营数据中心，其物理安全标准远高于绝大多数企业自建机房，包括但不限于：
- 严格的多重物理门禁与身份验证机制
- 全天候监控、巡检与入侵防护系统
- 数据中心选址、防火、防洪、防灾能力设计
- 电力、制冷和网络的多层冗余架构
这些能力构成了 AWS 云服务能够长期稳定运行的物理基础，也是企业很难自行构建的安全能力。
2. 硬件与底层设施安全
AWS 统一负责所有云基础硬件及其运行环境的安全与维护，包括：
- 服务器、存储介质与网络设备
- 虚拟化层（Hypervisor）的隔离与防护
- 核心网络架构与底层软件组件
客户无需参与硬件采购、生命周期管理、故障更换或底层漏洞修复，这些工作均由 AWS 按照统一标准、规模化执行。
3. 托管服务的运行保障
对于 RDS、S3、Lambda 等托管型与 Serverless 服务，AWS 还额外承担：
- 底层运行环境的维护与升级
- 服务级可用性与稳定性保障
- 平台层补丁更新与安全修复
同时，AWS 持续通过 ISO、SOC、PCI DSS 等多项国际合规认证，为企业在审计与合规层面提供权威背书。
客户负责的内容：云上的安全（Security in the Cloud）
需要明确的一点是：云平台本身的安全，并不等于业务天然安全。
应用、数据、访问权限和配置的安全，始终由客户自己负责，这也是企业在实际使用云服务过程中最容易产生误解、同时风险最高的部分。
1. 数据安全与合规治理
客户需要对自身数据的全生命周期负责，包括：
- 数据分类与分级管理
- 静态与传输加密策略设计
- 数据备份与灾难恢复机制
- 数据保留、归档与删除流程
- 合规要求的具体落地（如 GDPR、行业监管）
AWS 提供能力和工具，但是否启用、如何配置、是否合规，最终仍取决于企业自身的治理策略。
2. 身份与访问管理（IAM）
在云环境中，权限设计的复杂度显著提高，权限配置错误往往比技术漏洞更具破坏性。客户需要：
- 合理设计 IAM 用户、角色和策略
- 严格落实最小权限原则
- 启用多因素认证（MFA）
- 定期执行权限审计与清理
在大量云安全事件中，问题并非源于“被黑”，而是合法身份被过度授权。
3. 操作系统与应用安全
在使用 EC2、自管容器或部分 PaaS 场景下，客户仍需对以下内容负责：
- 操作系统补丁管理
- 应用漏洞修复
- 中间件、运行时和容器的安全配置
基础设施上云，并不意味着应用安全会自动完成。
4. 网络与配置安全
云上的网络同样需要精细化设计和持续治理，包括：
- VPC 架构与子网规划
- 路由、安全组与 ACL 配置
- 日志审计、监控与安全告警
在云环境中，配置错误往往比硬件故障更容易引发安全事故。
不同 AWS 服务下的责任差异
共享责任模型并非静态不变，而是随着服务抽象层级的提升而动态变化：
- IaaS（如 EC2）：客户需要负责操作系统、应用和安全配置
- PaaS（如 RDS、ECS）：AWS 托管更多组件，客户聚焦配置与访问控制
- Serverless（如 Lambda、Fargate）：基础设施完全由 AWS 管理，客户主要关注代码、权限和数据治理
服务越托管，企业就越需要将注意力从“运维执行”转向“安全策略与治理能力”。
在云上如何帮助企业真正落地共享责任模型？
作为 AWS 官方代理商，在云上不仅提供云资源交付，更关注共享责任模型在企业实际架构中的长期落地，包括：
- 云上安全架构设计与风险评估
- IAM 权限体系规划与持续审计
- 合规体系与安全基线建设
- 日志、监控与安全告警方案实施
- 安全最佳实践的持续优化与演进
通过将共享责任模型与业务场景深度结合，帮助企业在责任边界清晰的前提下，构建可控、可审计、可持续演进的云平台。
总结
AWS Shared Responsibility Model 是理解云安全的基础框架，也是企业开展云安全治理的起点。
AWS 提供稳定、安全、合规的云基础设施，而客户需要对云上资产、配置和数据承担相应责任。
只有在责任边界清晰、协同运作的前提下，云计算才能真正释放其灵活性与规模优势。
作为 AWS 官方代理商，在云上将持续协助企业正确理解并落实共享责任模型，让云安全不只是工具问题，而成为企业长期可持续演进的治理能力。
