1. 对象存储加密概述：为什么需要加密，加密方式
做对象存储的同学都知道，数据一旦上了云，你的控制权就少了一半。说白了，你把文件丢到S3、OSS或者COS里，物理硬盘归云厂商管，网络链路也是他们的。但数据泄露的责任，还在你身上。
我最早接触对象存储加密是在一个金融项目里。客户要求所有用户身份证照片必须加密存储，审计那边直接说：“你们要是明文存，年审就别过了。” 从那以后我才深刻理解——加密不是可选项，是合规底线。
1.1 为什么需要加密？三个维度看
咱们别绕圈子，直接说核心原因：
- 合规要求：GDPR、HIPAA、等保2.0、PCI DSS…… 这些法规都明文要求存储敏感数据时必须加密。你如果做跨境业务，或者涉及医疗/金融，不加密基本等于违法。
- 数据隔离：对象存储是共享基础设施。同一台物理硬盘上可能存着你公司的数据，也可能存着别人的。一旦硬盘被回收、退役或误挂载，没有加密的数据就裸奔了。我记得有个案例，某云厂商退役硬盘没擦除干净，结果被买家恢复了数据。
- 内部威胁与意外泄露：你想想看，运维人员、云厂商技术人员，理论上都能直接访问底层存储。加密后，就算他们拿到数据包，没有你的密钥也读不懂。
注意：加密不能杜绝网络传输中的窃听，需要搭配TLS使用。本章只讨论“存储态”加密（Data-at-Rest Encryption）。
1.2 加密方式总览：服务端加密 vs 客户端加密
对象存储加密主要分两大流派。我画了张图帮大家理清关系，先看结构，再讲细节。
上图已经很清楚：两条路——服务端加密（SSE）和客户端加密（CSE）。下面我逐一说透。
1.3 服务端加密（SSE）
服务端加密的意思是：你把数据通过HTTPS传到对象存储服务端，然后服务端在写入硬盘之前替你加密。读取时自动解密，对你的应用来说几乎无感知。
常见的三种模式：
| 模式 | 密钥谁管 | 适用场景 |
|---|---|---|
| SSE-S3 | 云厂商（AES-256） | 无特殊合规要求，图省事 |
| SSE-KMS | 客户在KMS中创建和管理 | 需要审计跟踪、密钥轮换、细粒度权限 |
| SSE-C | 客户自己提供密钥（每次请求带上） | 密钥绝不离本地，对云厂商零信任 |
我的建议：大部分业务选SSE-KMS就够了。既能符合合规审计，又不用自己操心密钥存储。我曾经遇到客户为了省钱用SSE-S3，结果等保检查时被问了句“你们能证明数据是被独立密钥加密的吗？”——SSE-S3的密钥是共享的，没法证明，最后连夜迁移到KMS。
1.4 客户端加密（CSE）
客户端加密就是“把加密的活儿揽到自己手里”。数据在离开你的应用进程前，SDK就已经加密过了。上传到存储的是密文，服务端完全不知道你存的是什么。
我整理了一下常用实现方式：
- SDK内置加密：比如AWS SDK的AmazonS3EncryptionClientV2，或是阿里云OSS的客户端加密模块。你只需要提供主密钥，SDK自动帮你完成加密、上传、解密、下载。
- 信封加密模式：用一个主密钥（KMS或本地密钥）加密一个随机的数据密钥，再用数据密钥加密实际文件。数据密钥的密文随文件一起存储。这是最推荐的做法——主密钥不直接加密大量数据，更安全也更灵活。
- 自实现加密：自己用AES-GCM、RSA等算法写加密逻辑。我一般不建议这么干，除非你的安全团队很强且有时间维护。我在一个项目里见过团队自己实现加密，结果密钥硬编码在代码里……嗯，那还不如不做。
避坑指南：我曾经遇到过使用客户端加密后，对象存储不支持范围读取（Range GET）的场景。因为服务端看到的是密文，无法按字节范围解密。如果你需要分片下载视频或大文件，客户端加密的兼容性要提前测试。
1.5 两种方式怎么选？
没有银弹。我一般按这个逻辑决策：
- 如果合规要求明确“用户数据必须由用户持有密钥” —— 只能用客户端加密。
- 如果只是为了防硬盘泄露、防云厂商侧漏 —— 服务端加密（SSE-KMS）性价比最高。
- 如果团队没有专职安全人员 —— 服务端加密更稳妥，别再给自己增加复杂度。
- 如果涉及到多个云之间迁移数据 —— 客户端加密更灵活，因为密文是自包含的，不绑定某家云KMS。
你想想看，其实大部分入门项目用SSE-S3就够用了。但一旦进入生产环境、涉及敏感数据，我强烈建议至少升到SSE-KMS。至于客户端加密，那是进阶玩家的领域，后面几章我们会深入讲参数调优。
核心结论：加密不是“加了就安全”，关键在于密钥谁管、密钥怎么轮换、SDK参数怎么配。本章先帮你建立全局认知，接下来我们会逐一拆解SDK里的加密参数配置——比如CipherSuite、KeySize、EncryptionMaterialsProvider等等。