加密做完，只解决了一半问题。密钥存在哪里、哪些账号能调用、丢了怎么办，这三件事决定数据是否真的安全。阿里云KMS（密钥管理服务）是阿里云提供的托管密钥服务，专门处理这些事。
阿里云KMS解决什么问题
很多团队把加密密钥写在配置文件或代码里。这样省事，但代码仓库一旦外泄，密钥跟着泄露，数据也就暴露了。人员离职后，也没人说得清密钥放在哪、还有哪些服务在用。
阿里云KMS把密钥集中保存在云端。应用不直接拿到主密钥，而是调用API提交加解密请求。密钥的创建、轮转、禁用和删除都在控制台或接口里完成。权限通过RAM（访问控制）逐个授予，调用记录由ActionTrail（操作审计）保存。
先搞清四个概念
- 主密钥（CMK）：长期保存在KMS里，用来加密其他密钥。它本身不会离开KMS。
- 数据密钥：由主密钥派生，用于加密文件、数据库记录这类体积较大的内容。
- 信封加密：先用数据密钥加密数据，再用主密钥加密数据密钥，然后把加密后的数据密钥和密文存放在一起。大批量数据不必每次都经过KMS，性能和调用成本都更好控制。
- 密钥轮转：定期生成新版本。旧版本保留，历史数据仍能解开。
三个典型场景
案例一：订单导出文件放进OSS
某中型电商平台每天生成大量订单导出文件，存放在对象存储OSS里，供财务和仓储部门下载。之前文件是明文存放，只靠桶的访问权限挡着。一次误配置让存储桶短时间对外可读，安全团队这才动手改造。
改法不复杂。给OSS桶开启服务端加密，指定一个KMS管理的主密钥。上传时OSS自动完成信封加密，业务代码基本不用动。接着在RAM策略里只给财务服务账号授予解密权限。其他账号就算拿到文件，也读不出内容。
案例二：手机号和身份证号的应用层加密
一家在线教育公司的用户表里存有手机号和身份证号。法务要求这两列在数据库里必须是密文，但登录时仍要按手机号查找用户。
团队采用信封加密。应用启动时调用KMS生成数据密钥，拿到一份明文副本和一份加密副本。用明文副本加密字段，用完即丢弃，只把加密副本和密文一起写入数据库。需要解密时，应用把加密副本交给KMS还原数据密钥。即使数据库被整库导出，没有KMS解密权限的人也读不出明文。
注意一个坑：随机加密后的密文无法直接做等值查询。如果登录要按手机号精确匹配，通常要另存一个用于检索的哈希值或索引字段，否则查询会失效。
案例三：RDS透明加密与密钥轮转
一家物流企业的订单库跑在云数据库RDS上，合规审计要求静态数据必须加密。团队在RDS里开启透明数据加密，选用KMS中的主密钥。开启后，磁盘上的数据文件都是密文，SQL语句不用修改。
半年后，安全策略要求每年轮转一次密钥。运维人员在KMS里为主密钥创建新版本，新写入的数据用新版本加密，历史数据继续用旧版本解密，全程没有停机。团队还为密钥删除设置了等待期。等待期内发起的删除请求随时可以取消，误操作的代价小得多。
上线前的检查清单
- 最小授权：只给需要加解密的服务账号授权。日常调用不要使用主账号身份。
- 管理与使用分开：创建、删除密钥的人，和调用解密的应用身份，最好由不同人或不同角色负责。
- 开启审计：用ActionTrail记录密钥调用，并对异常解密请求设置告警。比如某个服务在短时间内的解密量明显升高，就该排查。
- 记录映射关系：把每个密钥对应的业务数据范围写进台账。定期演练误删或权限变更后的恢复流程，不要等出事了才翻文档。
- 区分环境：开发、测试、生产使用不同密钥，防止测试环境误用生产密钥。
成本方面，具体计费项和单价以阿里云官网当期定价为准。上线前先按数据量和调用频率估算一下请求次数，避免账单出乎意料。
阿里云KMS的作用，是把密钥从应用代码里拿出来，交给专门的服务统一授权、轮转和审计。它不能代替访问控制和数据分类。两者配合到位，加密才算落到实处，出了问题也有迹可查。
