接口中的敏感数据（如身份证号、手机号）应该如何加密传输和存储？

🏛 业务架构师

敏感数据（身份证、手机号）的加密传输与存储，我按合规驱动 → 技术方案 → 密钥管理 → 使用体验四层答，第一层是这道题的根基：这是《个保法》《数据安全法》下的合规刚需，不是可选的技术优化。

一、传输加密

二、存储加密

写入: 明文 → AES-256-GCM(数据密钥DEK) 加密 → 密文入库
DEK → KMS主密钥(KMS) 加密后与密文同存(信封加密)

信封加密（信封模式）是标准做法：业务不直接持有主密钥，加解密性能好（DEK 本地缓存），KMS 集中管控
国产化场景用 SM4/国密算法（金融、政务强制）
配套设计可查询性：等值查询加盲索引列（HMAC(server_key, 手机号) 存单独字段建索引）——密文无法查询的问题用它解决（详见模糊搜索题）
日志脱敏：敏感字段在日志输出前强制掩码（138****1234），日志泄漏是数据事故的最大来源

三、密钥管理（安全的命门）

四、业务体验平衡

收尾：我把敏感数据安全总结为三句话：传输防嗅探、存储防拖库、密钥防内鬼。方案成熟度不看算法多强，看"密钥在谁手里、审计能不能回溯到人"。

敏感数据的加密要按传输、存储、展示、检索全生命周期设计，每段要求不同。

1. 传输加密

2. 存储加密（题眼）

加密算法选择：手机号、身份证这类需要反查明文的数据用对称加密（AES-256-GCM 或国密 SM4）+ 每记录随机 IV（绝不能 ECB 模式——相同明文相同密文会暴露规律）；密码类的单向 bcrypt/argon2 加盐慢哈希，绝不存明文或可逆加密
密钥管理（KMS 体系，加密安全的本质）：
- 数据密钥（DEK）加密数据，DEK 本身用 KMS 主密钥（KEK）加密后与密文同存——信封加密
- 密钥轮换：定期换 KEK，历史 DEK 批量重加密或双版本并行
- 权限分离：应用只有"调 KMS 解密"权限，拿不到主密钥本身；操作审计
密文字段存储：VARCHAR 存 base64，注意密文长度比明文长（IV+tag），建表预留

3. 使用与展示脱敏

4. 合规与流程：等保/个保法要求下，最小化收集、访问审批、导出双人复核、加密字段 DLP 扫描。一句话：传输 TLS+报文加密、存储信封加密+KMS、展示脱敏、日志兜底，四段全闭环。

我按传输、存储、展示、密钥管理四层回答，这是敏感数据安全的完整链路。

传输层

全站 HTTPS/TLS 1.3 是底线；防抓包还要字段级加密：客户端用服务端 RSA 公钥加密敏感字段（或 ECDH 协商的对称密钥 AES-GCM 加密），服务端私钥解密——即使 TLS 被中间人剥离（企业代理、安卓 hook），抓到的还是密文。
密钥一对一期换（KMS 管理私钥），别用固定写死的公钥。

存储层

落库密文存储：AES-256-GCM（或国密 SM4），GCM 自带完整性校验。
信封加密：数据密钥加密数据，主密钥存 KMS（阿里云 KMS/自建 Vault），应用只拿数据密钥——主密钥永不落应用服务器，KMS 权限最小化 + 审计。
加密用 MyBatis TypeHandler 统一收口，业务代码无感：

java

@TableField(typeHandler = EncryptTypeHandler.class)
private String phone; // 库内存密文，读取自动解密

等值查询的坑（必讲）

加密后无法 WHERE phone = ?。方案：辅助 HMAC 列——phone_hmac = HMAC_SHA256(saltKey, phone)，查询走 hmac 列等值匹配（HMAC 防字典反查）。精确匹配用 hmac，模糊搜索另题展开。

展示与日志

展示脱敏：138****1234、110***********1234，后端脱敏后返回，全量明文走审批 + 水印。
日志脱敏最易漏：Logback 自定义 Converter 或 @JsonSerialize 脱敏序列化器，把 phone/idCard 字段统一处理，否则库加密了日志全裸奔。
传输日志（Nginx access log）不打 query string 敏感参数。

密钥管理红线：密钥不进代码库（Git 历史也是泄露）、不进配置明文，全部 KMS/Vault；离职换钥演练过一次才算数。