云服务模型与责任共担：谁该为数据安全买单？
很多刚接触云安全的同学都会问一句：「数据放在云上，安全到底归谁管？」
这个问题不搞清楚，后面所有路径分析和风险评分都是扯淡。我个人习惯把这件事总结成一个简单原则：云厂商管云平台的安全，你用云的人管你在云里放的东西的安全。但这句话太笼统了，实际落地得看你选的是 IaaS、PaaS 还是 SaaS。
三种服务模型，责任边界完全不一样
先看一个最经典的对比表，这表我每次做培训都会贴出来。你想想看，同样是“数据加密”，在不同模型下谁来做，差别大了去了。
| 责任维度 | IaaS | PaaS | SaaS |
|---|---|---|---|
| 物理安全 | 云厂商 | 云厂商 | 云厂商 |
| 网络与虚拟化 | 云厂商 | 云厂商 | 云厂商 |
| 操作系统与中间件 | 客户 | 云厂商 | 云厂商 |
| 运行时与数据 | 客户 | 客户 | 云厂商 |
| 用户端访问控制 | 客户 | 客户 | 客户 |
| 数据加密（静态与传输） | 客户（云厂商提供工具） | 共担（平台默认加密+客户管理密钥） | 云厂商（客户可配置） |
| 合规与审计 | 共担 | 共担 | 云厂商主导 |
这张表里最有意思的是最后一行「数据加密」。我遇到过一家金融客户上了 IaaS 的裸金属服务器，以为云厂商自动给硬盘加密了，结果等审计发现数据全明文存储……嗯，IaaS 里云厂商只保证你拿到的是物理安全的硬盘，加密得你自己搞。
IaaS：你管系统，我管机房
基础设施即服务，说白了就是云厂商给你一台虚拟服务器、一块虚拟硬盘、一个虚拟网络。剩下的操作系统打补丁、装数据库、配置防火墙、加密磁盘——全都是你的事。
我曾经帮一个创业团队复盘数据泄露事件。他们用了 IaaS，把 MySQL 直接装在默认的公共子网里，连安全组都没配。我问他们为什么不做？对方回我：「云不是自带安全吗？」……这是典型的责任边界认知陷阱。
PaaS：不用管系统，但数据还是你的
平台即服务，比如阿里云的 RDS、AWS 的 Lambda。云厂商帮你管好了操作系统、中间件和运行时环境。你直接在上面写代码、建表、跑逻辑。
但这不代表你可以撒手不管。我问你一个场景：你在 PaaS 上建了一个 PostgreSQL 数据库，云厂商默认帮你开启传输加密（TLS），但你写代码时没校验 SQL 注入——数据照样可以通过 SQL 注入被拖走。这不是云厂商的责任，这是你应用层的暴露路径。
我记得有一次做渗透测试，目标是一个跑在 PaaS 上的 REST API。我扫了一圈，底层平台加固得很好，但我发现 API 的 JWT 里直接嵌了明文用户 ID……这就是典型的数据安全责任边界模糊点：平台安全由云厂商兜底，但应用数据安全必须你自己盯着。
SaaS：你也别闲着，配置和权限才是命门
软件即服务，Salesforce、钉钉、飞书、Google Workspace 都是例子。这时候云厂商连应用层都管了，你只管用。
等一下，那是不是完全不用操心了？当然不是。数据暴露路径最常见的重灾区就是 SaaS 里的权限配置和共享设置：
- 不小心把一个带敏感数据的在线文档设为「公开链接可访问」
- 离职员工的账号没及时停用
- 第三方 OAuth 应用获取了太高的数据读取权限
这些暴露路径跟云厂商无关，纯粹是人的操作问题。说白了，SaaS 模式下你放弃了对底层和平台的控制权，但换来的是必须做好配置管理。
共享责任模型：一张图讲清楚
下面这张图是我每次讲共享责任模型都会画的。它清晰地告诉你：云厂商负责“云的安全”，你负责“在云中的安全”。两者的交界处就是最容易出问题的灰色地带。
中间那条红色的「共享责任边界」是我重点圈出来的。很多泄露事件都出在这条线附近——比如云厂商负责网络 ACL，但你忘了关闭 3306 端口；云厂商提供 KMS，但你用了一个弱口令去保护主密钥。说白了，边界上的安全，需要双方都做好自己的那部分。
三个模型下的数据暴露路径典型场景
结合我自己的实际排查经验，整理几个最容易踩的坑：
• 未打补丁的操作系统被 CVE 漏洞利用 → 攻击者拿到 shell → 拖走数据库文件
• 安全组规则过于宽松（/0 开放 SSH） → 暴力破解成功 → 横向移动到数据盘
• 对象存储（如 AWS S3）配置为公开读写 → 数据直接暴露在公网
• 数据库连接字符串硬编码在代码中，上传到公开的 Git 仓库 → 被爬虫抓取 → 直接登录数据库
• 云函数（Function）环境变量里存了 ，日志未脱敏 → 运维日志泄漏密钥
• 消息队列未开启访问认证 → 内部消息被第三方订阅
• 企业网盘分享链接设置「知道链接即可查看」 → 链接被转发到外部群组 → 数据泄露
• 第三方 OAuth 应用申请了过多的数据范围，且未定期审核 → 应用被攻破后数据大规模泄露
• 用户误将机密文档上传到公共团队空间 → 内部任何人都能访问
如何用共享责任模型做风险评分
在我做数据暴露路径分析时，会把每个发现的风险点先贴到这张责任模型图上，看它落在哪个区域：
- 落在客户责任区的风险：评分直接给高，因为控制权在客户手里，修复成本相对可控，但一旦暴露影响极大。
- 落在云厂商责任区的风险：评分中等偏低（毕竟云厂商有 SLA 和自动修复），但需要确认云厂商是否真正做到了承诺。
- 落在共享边界上的风险：这是最难评分的。比如加密密钥管理——云厂商提供 KMS，但密钥由客户保管。这时候需要检查密钥的生命周期策略、是否启用自动轮换、是否有审计日志。我通常会给这类风险加个「责任归属不明确」的标签，评分时额外加权重。