3. 常见云数据存储服务：对象存储、块存储、文件存储、数据库服务概览
说起云存储，大家最先想到的肯定是 S3 和 OSS。但云上不只有这一种存储。
我个人习惯把云存储分为四类：对象存储、块存储、文件存储、数据库服务。每类的暴露路径和风险完全不一样。今天咱们就捋一遍。
3.1 对象存储（S3 / OSS）
对象存储是云上最容易被“裸奔”的服务。说白了，它就是用来存非结构化数据的——图片、视频、日志、备份文件，什么都往里扔。
核心概念就两个：Bucket（桶）和Object（对象）。每个 Object 都有一组元数据和唯一的 URL。你想想看，这东西天生就是通过 API 或 SDK 访问的，所以它的数据暴露路径也多半跟“网络访问”有关。
- 扁平结构，没有目录层级，靠前缀模拟文件夹
- 通过 HTTP/HTTPS 访问，支持匿名读取
- 无限扩展，单个 Object 最大可达 5TB
- 内置访问控制列表（ACL）和 Bucket Policy
我记得有一次帮客户做审计，发现一个 S3 Bucket 存了数万张身份证照片。Bucket 策略是“*\:*” —— 全世界都能读。
嗯，这不算罕见。对象存储的错误配置是云上数据泄露的头号杀手。
还有一点要注意：对象存储的底层不支持直接挂载成文件系统。你不能把它当 C 盘用。要通过 SDK 或 API 读写。所以它的数据暴露路径主要是 网络层暴露，不是文件系统层。
| 特性 | 对象存储 | 块存储 | 文件存储 | 数据库 |
|---|---|---|---|---|
| 数据形态 | 非结构化（文件、图片） | 原始块设备 | 文件系统共享 | 结构化数据 |
| 访问方式 | HTTP/HTTPS、SDK | 挂载到虚拟机 | NFS/SMB 挂载 | SQL/NoSQL 协议 |
| 主要暴露风险 | 桶策略、匿名访问 | 快照、挂载点 | 共享权限、ACL | 弱密码、Wi |
3.2 块存储（EBS / 云盘）
块存储更贴近传统硬盘。你想想看，云主机的系统盘就是块存储。
它提供的是原始块设备，你可以格式化，自己装文件系统。它的暴露路径跟对象存储不太一样——主要靠快照泄露和错误挂载。
我在项目里遇到过一件事：某个团队把 EBS 快照自动复制到另一个区域，然后那个区域的手动快照被设置成“公开”。结果快照里包含了一个完整的数据库备份，用户名密码全在里面。这算是一个典型的数据暴露路径：块存储 → 快照 → 公开共享。
- 块存储默认只能在同可用区内挂载，不可跨区域
- 快照可以跨区域复制，但复制后可能被误共享
- 加密的块存储快照也是加密的，但密钥管理不当同样危险
我个人建议：块存储一定要启用默认加密。AWS 的 EBS 默认加密可以在账号级别开启。一旦开启，新创建的卷都会自动加密。这样就算快照不小心公开了，别人也读不了数据。
还有一点：块存储的写入缓存问题。我记得有一次排查性能问题，发现云盘的写入缓存没关，结果在快照时数据不一致，恢复出来的数据库是坏的。这块存储本身不暴露，但它的快照和挂载行为决定了你的数据会不会被看到。
3.3 文件存储（EFS / NAS / FSx）
文件存储，说白了就是一台 NAS 挂载到云上。
它支持 NFS 和 SMB 协议，适合多台云主机共享数据。比如 Web 集群的静态资源、Git 仓库、共享配置等。
它的暴露路径跟前面两个不太一样：挂载点和权限策略。
- 挂载点需要安全组控制，默认只允许内网访问
- NFS 权限由客户端 IP 和 UID/GID 决定
- SMB 权限由 Windows ACL 控制
- 文件存储本身不提供公开访问，但挂载点如果配了公网，就危险了
有一次我帮客户看一个 EFS 文件系统。它的挂载目标配了一个安全组，安全组里有一条规则：源地址是 0.0.0.0/0，端口 2049。这意味着任何互联网机器都能尝试挂载 EFS。虽然 NFS 协议本身还要做用户认证，但暴露面已经太大了。
嗯，这里要注意：文件存储的挂载点不要暴露到公网，除非你明确知道自己在干什么。
我建议部署文件存储时，一定要配合 VPC 内的安全组和 NFS 的 export 选项。比如在 AWS 上，EFS 可以用 Access Points 来限制每个应用的访问路径和权限。这样做的好处是：即使挂载点被攻击者利用了，也只能访问特定的子路径。
3.4 数据库服务（RDS / Aurora / 云原生数据库）
最后说说数据库。这部分其实比存储更危险。为什么？因为数据库直接面对业务应用，网络暴露面广，而且数据高价值。
云数据库分两大类：关系型（RDS、Aurora、云数据库 MySQL）和 NoSQL（DynamoDB、MongoDB Atlas、Cassandra）。它们的暴露路径差异很大。
| 类型 | 暴露路径示例 | 典型风险 |
|---|---|---|
| 关系型（RDS） | 公网访问、弱密码、未开启SSL | SQL注入、暴力破解 |
| NoSQL（DynamoDB） | IAM策略配置错误、表公开 | 越权访问、数据导出 |
| 托管数据库（如 MongoDB Atlas） | IP白名单过宽、认证开关没关 | 无需密码直接连 |
我记得在某次渗透测试中，发现一个 RDS 实例居然直接绑了公网 IP。然后它的安全组又把 0.0.0.0/0 的 3306 端口放开了。密码还是 'admin123'。这种案例太典型了。
- 永远不要给数据库绑定公网 IP
- 默认关闭“publicly accessible”选项
- 强制使用 SSL/TLS 连接
- 审计日志要开启，记录谁在什么时间访问了什么数据
对于 NoSQL 数据库，还有一点要注意：很多 NoSQL 默认没有用户认证（比如老版本 MongoDB）。我见过一个 DynamoDB 表的访问策略写成了“Principal: *”，结果任何人都能查整个表。这种错误配置比关系型数据库更难发现，因为它不是简单的网络访问，而是 IAM 策略层面的暴露。
3.5 四类存储的数据暴露路径对比
3.6 小结：四类存储的风险画像
这四类存储，各有各的脾气。
- 对象存储：最容易被“公开”。我经手的案例里，80% 的数据泄露跟对象存储的桶策略有关。它的暴露路径数量最多，但也是最好修的一类——关掉公开访问就行。
- 块存储：快照是最大的风险点。而且块存储的加密策略往往被忽略。我在实践中发现，很多团队只加密了传输中的数据，但忘了加密静置状态的数据。
- 文件存储：安全边界在挂载点和权限控制。只要不把挂载点暴露到公网，风险相对可控。但 NFS 的 export 选项写错，就等于把文件系统直接给了攻击者。
- 数据库：危害最大。一旦暴露，完整的数据表、用户记录、密码散列全都在那里。数据库的安全必须做到“默认零信任”——任何人都不应该直接访问数据库实例。
- 对象存储靠 策略审计 保命
- 块存储和文件存储靠 加密 和 网络隔离
- 数据库靠 零信任 和 连接加密
这四类服务的数据暴露路径覆盖了云上 90% 以上的泄露场景。了解它们，就是建立云数据安全的第一道防线。