📚 课程目录第2章加密上传下载的必要性

第2章加密上传下载的必要性

说实话，早期做对象存储的时候，我也觉得“先传上去再说，加密不加密没那么急”。直到有一次在金融客户现场，他们直接拿出了合规审查表，指着“传输加密”“存储加密”两个空栏问我们怎么填……

嗯，从那以后我养成了一个习惯：在开始写任何上传下载的代码之前，先确认数据要不要加密，谁来加密，用什么算法。这一章我就把这几年的体会整理出来，帮你少踩几个坑。

很多人觉得“我的数据又不是什么国家机密，加密干嘛？”但我想说的是：数据在被上传到对象存储的过程中，至少经过客户端网络、运营商链路、云服务商内部网络三道关卡。每道关卡都有可能被监听、篡改甚至劫持。

我记得以前帮一个电商客户排查问题，他们上传的订单 CSV 文件从办公室到 OSS 只用了不到两秒，但后来发现那个时间段内，同一链路上有人跑了一个中间人抓包工具。万幸的是文件里只有商品编号没有用户信息……但这让我彻底不再相信“网络是安全的”这种假设。

加密解决的三个核心问题，其实可以用一句话概括：

小提示：很多人只关注“传输加密”（HTTPS），却忽略了“存储加密”和“客户端加密”。如果你把明文存到云端，即使 HTTPS 保护了传输过程，一旦云服务商内部出现权限泄露，数据照样裸奔。

说实话，合规是推动加密最硬的理由。我经历过一个项目：客户是银行，他们要求所有上传到对象存储的交易流水必须使用国密 SM4加密，而且是客户端先加密再上传。

为什么？因为《金融数据安全分级指南》和《等保2.0》里明确写了：四级以上数据必须加密存储，并且密钥不能托管在云服务商。你想想看，如果事先不了解这些要求，等到验收时再改，那代码改动量可不小。

常见的合规场景我列一下：

注意：我在一个项目中吃过亏：用了云服务商提供的默认加密（SSE-S3），但客户审计发现密钥完全由云方管理，不符合他们内部“密钥必须由客户自主控制”的合规要求。最后我们全部改成客户端加密 + KMS 自管密钥。那次返工真是血泪教训。

既然要用加密，那选什么算法呢？我根据多年实战经验，把最常见的几类列出来。记住一个原则：不要自己造算法，用行业标准方案。

加密和解密用同一个密钥。速度快，适合大数据量。对象存储里最常用的是 AES-256 – 尤其是 GCM 模式，能同时保证机密性和完整性。

加密和解密用不同的密钥（公钥/私钥）。速度慢，适合小数据量的密钥交换或数字签名。对象存储里常用 RSA-2048/4096 或 ECC（椭圆曲线） 来包装对称密钥。

虽然不算严格意义的“加密”，但哈希是完整性校验的核心。上传下载过程中，我们通常用 SHA-256 来计算文件内容的哈希值，然后跟服务器端对比判断文件是否被篡改。如果使用了 GCM 模式的对称加密，其实已经自带了认证标签，不需要额外再做哈希。

最佳实践组合（我目前在生产环境用的）：

嗯，这套方案我在三个项目里实践过，稳定性没问题，也能过大多数合规审计。

最后给你一个快速判断表：

第2章 加密上传下载的必要性