6.3 数据加密：三把钥匙各管一段

6.3 数据加密：三把钥匙各管一段

本节摘要：MinIO 的加密体系按数据的旅程分三段：传输中的 TLS、落盘后的服务端加密（SSE-S3 与 SSE-KMS 两种模式）、以及客户端自带密钥的 SSE-C。本节讲清三段各自的威胁模型、"谁能解密"的权限差别，以及密钥管理服务（KMS）的接入姿势。

加密防的是谁

配置加密之前先想清楚威胁模型，否则容易把力气花错地方。传输加密（TLS）防的是链路上的窃听与篡改——凭证与数据在网络里裸奔的岁月必须终结，这在 2.3 已经落地。静态加密（SSE）防的是介质层面的泄露——硬盘退役流出、整机失窃、快照副本落入他人之手，盘上的密文让这些场景变成"拿到了也读不懂"。客户端加密防的是存储系统本身——数据在到达服务器之前就已加密，服务端全程只见密文。三段各挡一路敌人，不存在谁替代谁。

图 6-3 数据旅程上的三段加密

SSE-S3：运维友好的一键加密

SSE-S3 模式下，MinIO 为每个对象生成数据密钥加密后落盘，数据密钥本身再由 KMS 的根密钥包裹保存。开启后应用完全无感——读写 API 一个字都不用改，加密解密全部发生在服务端。它防的是介质泄露，不改变访问控制的边界：能通过 IAM 读到对象的人，就能拿到明文。

开启姿势是给桶设默认加密头，此后所有未显式声明加密选项的写入都自动加密：

# 前提:集群已接入 KMS（本节后文给出接入配置）
mc admin kms key status fleet

# 为桶设置默认服务端加密
mc encrypt set sse-s3 fleet/medical-images

# 验证:写入一个对象,查它的加密元数据
mc cp scan-0412.dcm fleet/medical-images/
mc stat fleet/medical-images/scan-0412.dcm
# 输出中的加密字段应显示 SSE-S3
​

SSE-KMS：密钥维度的隔离

SSE-KMS 模式把密钥选择权交给调用方：每个桶可以绑定独立密钥，单次写入也可以在请求头里指定。它的价值在于密钥权限独立于存储权限：备份团队的用户可以读对象元数据、可以复制对象，但如果 KMS 侧没有授权它使用那个密钥，解密依然被拒。合规场景（如"研发环境不得解密生产数据"）靠的就是这一层。

与 KMS 的对接通过 MinIO 的密钥加密服务组件完成，它向上为 MinIO 提供统一接口，向下对接各类 KMS 后端：

# KES 服务配置要点（节选,完整部署见官方部署指引）
# keystore 指向实际的 KMS 后端,fleet 集群的策略允许其使用指定密钥

# MinIO 侧配置 KES 地址与身份证书
mc admin config set fleet kms_esk default

# 在 KMS 里创建业务密钥
mc admin kms key create fleet/medical-key

# 桶绑定默认 KMS 加密并指定密钥
mc encrypt set sse-kms medical-key fleet/medical-images
​

密钥治理的两条纪律：密钥与数据分离存放，KMS 的可用性与备份等级应不低于存储集群本身——KMS 丢了，全量密文变化石；密钥轮换要演练，轮换只影响新写入的数据密钥包裹，历史对象解密不受影响，但这个行为要在测试环境验证过再上生产。

SSE-C 与加密的性能账

SSE-C 把密钥完全交给客户端：每次请求自带密钥头，服务端用完即弃、绝不保存。它适合"存储系统不可全信"的极端场景，代价是密钥丢了数据永久不可恢复——这是一把没有备用钥匙的锁。日常业务很少用到它，知道有这条路即可。

性能方面，加密的开销集中在写入路径的对称加密与读取路径的解密，现代 CPU 的 AES 指令集把这笔开销压到个位数百分比。真正的性能敏感点不在加解密本身，而在 KMS 的网络往返：SSE-KMS 每次数据密钥操作要访问一次 KMS,高并发小对象场景下要给 KES 配置缓存并压测（口径见 7.3）。加密与性能不是对立面，粗放的配置才是。

案例：医疗影像系统的加密改造

背景：某三甲医院的影像归档系统迁移到 MinIO,合规要求：传输全程加密、落盘加密、且运维人员不得解密影像内容。

操作：集群启用 TLS（2.3 的方案）；影像桶设置 SSE-KMS 默认加密并绑定专用密钥；KMS 的密钥策略只授权影像应用的服务账号使用该密钥；运维账号可以管理桶与对象（列目录、清理过期），但密钥策略里没有它。

结果：运维在做日常巡检时可以确认对象存在与大小，抽查内容时被密钥策略拒绝——"运维可管理、不可窥视"的审计要求逐项达成。

解读：这个案例里 SSE-S3 也能加密落盘，但做不到"有存储权限的人解不开"。选 SSE-KMS 的唯一理由就是要把解密权从存储权限里拆出来——需求决定模式，倒过来配置就是浪费。

变式：若医院还要求数据出本地时（5.4 的异地副本）同样加密，站点复制同步的是密文形态——副本站点若无密钥授权，同样只能管理不能解密，密钥隔离随复制语义自然延伸。

本节要点回顾

• 三段加密各防一路：TLS 防链路、SSE 防介质、SSE-C 防存储本身，不互相替代。
• SSE-S3 省事，SSE-KMS 拆权：前者一键全加密，后者把解密权从 IAM 独立出来，按威胁模型选。
• KMS 是新的命门：可用性与备份等级不低于存储，轮换先演练。
• 性能开销可控：AES 指令集下加密本身几无感，要压测的是 KMS 往返。

守仓三课——身份、取证、加密——到此完备。第 7 章换一个赛道：让这套防线跑出应有的速度。

加密的三个延伸疑问

开了加密，存储还能去重省空间吗？

MinIO 本身不做内容级去重，加密与否不影响这一点。但要注意加密会消灭"上游去重"的可能性：同样的明文每次加密产生不同密文，任何期望"相同内容只存一份"的上游设计（如同步工具的内容寻重）都会失效。容量规划时按密文口径算，别按明文想象空间。

加密与版本控制怎么交互？

每个版本独立加密、独立携带自己的数据密钥包裹。这意味着轮换根密钥只影响之后新写入的版本，历史版本仍用旧密钥体系解密——所以 KMS 里的旧密钥在保留期内必须可用，删除旧密钥等于销毁历史数据。密钥的退役周期要与数据保留期对齐。

KES 停机会发生什么？

新写入会失败（拿不到数据密钥），读取的解密同样需要 KES 参与而失败——密钥服务是数据路径的一部分，不是管理路径的旁路。因此 KES 的部署等级要按数据路径组件对待：多实例、跨故障域、有监控（8.2 的清单里加上 KES 可用性）。加密换来的每一点安全，都要付一份可用性上的认真。

三问的共同指向是一个判断：加密方案的一半在存储，另一半在密钥治理。只配存储侧、不管密钥生命周期的加密，等于买了最好的锁却把钥匙挂在门上。