2、云服务商责任共担模型：AWS、Azure、阿里云与用户责任边界
聊到Serverless安全，第一个绕不开的话题就是「责任共担」。
说白了，云不是万能的，它不会替你管所有事。你想想看，如果你把代码丢上去，出了数据泄露，到底是云厂商的锅，还是你的锅？
这个边界，必须一开始就划清楚。我见过太多团队，出了事才发现「哦，原来这个是我自己该管的」。嗯，今天我们就来把AWS、Azure、阿里云这三家的模型掰开揉碎讲清楚。
2.1 AWS责任共担模型：最经典的「分水岭」
AWS是最早提出责任共担模型的云厂商。它的逻辑很简单：AWS负责「云的安全」，用户负责「云中的安全」。
核心分界线：
- AWS负责：物理基础设施、虚拟化层、计算存储网络硬件、托管服务（如Lambda运行时、S3存储层）。
- 用户负责：客户数据、IAM权限配置、网络ACL规则、操作系统补丁（EC2）、应用代码安全、加密密钥管理。
我个人习惯把AWS的模型想象成「房东与租客」。房东保证房子不漏雨、不断电，但你自己得锁好门、管好钥匙。
在Serverless场景下，这个边界会移动。 比如你用Lambda，AWS负责底层运行时和基础设施的安全，但你的函数代码、环境变量、IAM角色权限，全是你自己的事。
避坑指南： 我曾经遇到一个团队，Lambda函数用了过于宽松的IAM角色，结果被攻击者利用函数提权，读取了S3里的敏感数据。AWS不会替你检查「你的Lambda是不是权限太大了」——这是你的责任。
2.2 Azure责任共担模型：更细粒度的「滑动条」
Azure的模型比AWS更灵活，但也更复杂。它把责任分成了三类：「平台即服务（PaaS）」、「基础设施即服务（IaaS）」、「软件即服务（SaaS）」，每种模型下责任边界不同。
| 服务类型 | 微软负责 | 用户负责 |
|---|---|---|
| IaaS（如VM） | 物理硬件、网络、虚拟化 | OS、应用、数据、网络配置 |
| PaaS（如Azure Functions） | 运行时、中间件、OS补丁 | 应用代码、数据、访问控制 |
| SaaS（如Office 365） | 几乎全部 | 用户数据、身份管理 |
你想想看，Azure Functions属于PaaS，微软负责运行时安全，但你的函数代码里有没有硬编码密钥？你的Azure AD权限有没有配置错？这些都得你自己盯着。
我记得有一次帮客户做审计，发现他们把Azure Functions的连接字符串直接写在了代码里。嗯，这其实属于用户责任边界内的事——微软不会替你加密这些。
注意： Azure的「责任滑动条」意味着，当你从IaaS迁移到PaaS再到SaaS，你的安全责任会逐渐减轻，但永远不会归零。哪怕你用SaaS，数据泄露了，微软也不会替你背锅。
2.3 阿里云责任共担模型：本土化的「三层架构」
阿里云的模型更贴近国内用户习惯。它把责任分为三层：「云平台安全」、「云产品安全」、「用户安全」。
- 云平台安全： 阿里云负责物理机房、网络、虚拟化、基础服务（如OSS存储层）。
- 云产品安全： 阿里云负责产品自身的安全能力（如RDS的数据库漏洞修复、函数计算的运行时隔离）。
- 用户安全： 用户负责账号管理、权限配置、数据加密、应用代码安全。
我个人觉得阿里云这个模型更直观。它把「云产品安全」单独拎出来，意思是：阿里云会保证产品本身没有漏洞，但你怎么用这个产品，是你的事。
举个例子，你用阿里云函数计算（FC），阿里云会保证函数实例之间的隔离性，但你的函数里有没有写死AccessKey？你的触发器权限有没有配成公开？这些阿里云不管。
避坑指南： 我曾经见过一个项目，把阿里云OSS的Bucket权限设成了「公共读写」，结果被爬虫扫到，数据全被拖走。阿里云提供了权限检查工具，但用不用是你的事——这就是用户责任边界。
2.4 用户责任边界：到底哪些事必须你来做？
不管用哪家云，用户责任边界其实大同小异。我总结了一个「用户必做清单」，你可以对照检查：
- 身份与访问管理（IAM）： 最小权限原则，别给Lambda或函数计算配Admin角色。
- 数据加密： 传输中加密（TLS）、存储时加密（KMS/CMK），别裸奔。
- 代码安全： 别硬编码密钥，用密钥管理服务（如AWS Secrets Manager、阿里云KMS）。
- 网络隔离： 函数计算是否应该放在VPC内？API网关是否应该限制来源IP？
- 日志与监控： 开启CloudTrail/ActionTrail，别等出了事才查日志。
- 依赖管理： 第三方库有没有漏洞？Serverless应用的依赖也得定期扫描。
核心原则： 云厂商负责「平台安全」，你负责「应用安全」和「数据安全」。这个边界永远不会模糊——哪怕你用全托管的Serverless服务。
嗯，说到这里，我想起一个经典案例。有个客户用了AWS Lambda + DynamoDB，觉得「全托管嘛，安全肯定没问题」。结果Lambda函数里直接拼装了用户输入，导致NoSQL注入，数据被删了。AWS不会替你过滤用户输入——这是你的责任。
所以，我的建议是：永远假设云厂商只帮你管到「基础设施层」，剩下的全得你自己兜底。 别偷懒，该配的权限配好，该加的加密加上，该做的审计开着。
下一章，我们会深入讲IAM权限模型，看看怎么用最小权限原则把Serverless应用锁死。到时候我会分享一些我踩过的坑，保证让你少走弯路。