数据上云，大多数人最先担心的是别人能不能看到。阿里云的加密能力分几类，分别管存储、传输和密钥，各自解决的问题并不一样。把它们混在一起用，很容易留下缺口。下面按数据所在的位置讲清楚各类加密怎么配合，并用一个电商的例子说明落地思路。
先分清三类加密
数据在云上的流转大致有三个阶段。写入磁盘或对象存储时，做的是静态加密。在网络上传输时，做的是传输加密，常见做法是用 TLS 证书。程序真正处理数据的那一刻，才涉及计算中加密，这类需求多出现在金融和政务系统里。
不少团队只做了静态加密，就觉得数据已经安全了。可如果密钥和数据放在同一个地方，加密基本等于摆设。
密钥管理是关键
阿里云的密钥管理服务 KMS 是各类加密功能的底座。它用的是信封加密：主密钥（CMK）加密一把数据密钥，数据密钥再去加密真正的数据。主密钥一直留在 KMS 内部，不会明文交给业务代码。
这样做的好处很实际。数据文件就算被整个复制出去，没有 KMS 访问权限也解不开。配合 RAM 访问控制，可以限定哪个角色能调用哪把密钥。再开启操作审计，每次解密请求都有记录，出了问题能查到是谁、什么时候调用的。
案例：电商的订单库和合同文件
设想一个中型电商。订单数据库里有用户手机号和收货地址，对象存储（OSS）里放着供应商签回的合同扫描件。两类数据敏感程度不同，加密方式也不该一样。
订单数据库：用数据库层加密
订单库部署在 RDS 上，可以开启透明数据加密（TDE）。磁盘上的数据文件是密文，应用代码不用改，读写方式跟以前一样。TDE 的密钥由 KMS 管理，按安全策略定期轮换就行。
但要记住，TDE 只保护落盘的数据。假如客服只能看到手机号后四位，这种需求要在应用层做字段级加密，或者用脱敏规则处理。两者不能互相替代，别指望开了 TDE 就不用管字段权限。
合同文件：用 OSS 服务端加密
OSS 支持服务端加密，可以选择由 KMS 托管的密钥。上传时指定加密方式，文件以密文保存。下载时服务端自动解密，前提是请求方有该密钥的使用权限。
这里最容易出错的地方是 Bucket 权限。如果设成了公开读，任何拿到链接的人都能访问，服务端会照常解密并返回内容，加密等于白做。对象存储里，权限配置往往比加密开关更重要。
落地时常踩的坑
- 密钥和数据由同一账号、同一权限管理。 如果开发人员既能读数据，又能改密钥策略，加密就起不到隔离作用。密钥管理员和数据使用者最好分开。
- 只加密，从不轮换。 同一把密钥用好几年，一旦泄露，影响面会非常大。按安全策略设定轮换周期，并确认轮换后业务正常。
- 删除或禁用密钥前不确认影响。 用它加密过的数据可能就再也打不开了。操作前先查清哪些资源在用这把密钥。
- 默认配置直接上线。 云厂商的默认值面向通用场景，敏感数据要单独评估，不能想当然。
选型可以这样走
- 先盘点数据，分清哪些是个人信息，哪些是商业机密，哪些可以公开。
- 按数据所在位置选加密方式：数据库用 TDE，对象存储用服务端加密，接口和网络走 TLS。
- 个人信息这类高敏感字段，额外加应用层加密或脱敏。
- 密钥统一交给 KMS，权限用 RAM 隔开，操作用审计日志留痕。
- 上线前检查一遍公开访问设置，确认没有绕过加密的通道。
阿里云加密真正有用的地方，是把密钥管理、访问控制和审计串成一套。只打开某一个加密开关，解决的只是一小部分问题。
