SELECT id, length(dek_cipher), length(dek_plain) FROM order_pii LIMIT 5; aws kms decrypt --ciphertext-blob fileb://dek.bin --key-id alias/order-pii
设计里用 KMS 生成数据密钥 DEK，每条记录用 DEK 加密，但 DEK 的明文被存在同一张表的 dek 列里，导出数据库后不解 KMS 就能直接解密。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。
追下去是这么回事：信封加密的关键是 DEK 只以 KMS 加密后的形式存储，用时才解封。实现时图省事把明文 DEK 一起落库，密钥和密文同处一地。KMS 只剩下生成密钥的作用。
「信封加密 DEK」改完先别急着全量，挑一台机器放半天，真有问题这段时间就能看出来。权限不要一口气开到最大，先加到够用再往上试，范围小才好收。
把复现步骤压到三条以内，交给同事也能跑出来，才算真的定位清楚。
处理上按这个顺序：只存 KMS 加密后的 DEK 密文 明文不落库；每次解密先调 KMS 解封 DEK 再解数据；开启数据库审计 监控 dek 列的异常读取；用导出的数据尝试解密确认没有 KMS 权限拿不到明文。
确认没问题再收工，dek_plain 列被删除 只有 KMS 权限的账号能解出手机号。