后端开发敏感数据加密处理规范

后端开发中敏感数据加密最常被忽视的问题不是“用不用加密”，而是“在哪里加密”和“密钥怎么管”。很多团队只在数据库字段上做了静态加密，应用层和传输层却裸奔，或者把密钥硬编码在配置文件里，这等于给数据加了一把锁，却把钥匙挂在锁上。敏感数据加密规范的核心要解决四件事：识别敏感数据范围、明确加密层次、统一加密算法与模式、严格管理密钥生命周期。下面直接展开讲具体做法。

不是所有数据都需要加密，过度加密会拖慢性能、增加存储和运维成本。敏感数据至少包括：用户身份标识（身份证号、护照号、社保号）、认证凭据（密码、Token、API Key、私钥）、金融信息（银行卡号、CVV、交易金额）、个人隐私（手机号、邮箱、住址、生物特征）、医疗健康记录、企业内部核心配置（数据库连接串、第三方服务密钥）。判断标准很简单：一旦泄露是否会造成法律风险、财产损失或用户隐私侵权。手机号是否必须加密取决于业务场景，如果只是用于展示脱敏，可以在应用层做掩码；如果用于登录凭证或与用户强绑定，则必须加密存储。

敏感数据在传输、存储、使用、备份、日志、缓存中都会出现。规范必须明确每个环节的加密要求。传输层强制使用TLS 1.2及以上版本，内部服务间通信也要走mTLS，不要因为内网就放松。存储层对数据库字段做加密，优先使用数据库原生透明加密（TDE）加应用层字段级加密的双层防护。应用层加密的意义在于即使数据库被拖库，攻击者拿到的也是密文。日志中严禁记录明文敏感字段，打印前必须脱敏或哈希。缓存（Redis、Memcached）中的敏感数据同样需要加密，很多团队在这里翻车。备份文件要加密，尤其是导出到对象存储或离线介质的备份。

对称加密用于大量数据的高效加解密，推荐AES-256-GCM，因为它同时提供机密性和完整性校验，避免密文被篡改。AES-256-CBC需要额外做HMAC，实现复杂且容易出错，不建议新系统使用。非对称加密用于密钥交换、数字签名和小数据加密，推荐RSA-2048及以上或ECDSA/Ed25519。哈希用于密码存储和完整性校验，密码哈希必须使用bcrypt、scrypt或Argon2，禁止使用MD5、SHA1甚至裸SHA256，因为它们是快速哈希，扛不住暴力破解。需要可逆的敏感字段（如手机号、身份证号）用AES-GCM，不需要可逆的（如密码）用慢哈希加盐。

密钥绝不能硬编码在代码或配置文件里。生产环境必须使用专门的密钥管理服务（KMS）或密钥管理系统，例如云厂商的KMS、HashiCorp Vault、自研的密钥管理平台。密钥要分级：根密钥（KEK）只用于加密数据加密密钥（DEK），DEK用于加密实际数据。DEK可以定期轮换，而KEK轮换周期更长。每次加密操作应生成随机的IV或nonce，GCM模式下12字节随机nonce是标准做法，绝不能复用。密钥轮换要有自动化流程，旧密钥解密、新密钥加密，历史数据需要支持多版本密钥解密。密钥访问要遵循最小权限原则，应用通过身份认证后动态获取密钥，密钥不落盘到应用服务器。

以Java后端为例，使用AES-GCM加密敏感字段的推荐做法如下：

// 使用AES-256-GCM加密
Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
byte[] nonce = new byte[12];
SecureRandom random = new SecureRandom();
random.nextBytes(nonce);
GCMParameterSpec spec = new GCMParameterSpec(128, nonce);
cipher.init(Cipher.ENCRYPT_MODE, secretKey, spec);
byte[] ciphertext = cipher.doFinal(plaintext.getBytes(StandardCharsets.UTF_8));
// 存储格式：nonce + ciphertext，Base64编码后入库

密文存储格式要统一，建议将nonce和密文拼接后Base64编码，字段长度要预留足够空间，AES-GCM密文比明文多16字节认证标签加12字节nonce。数据库字段类型用VARBINARY或TEXT，不要用VARCHAR，避免字符集转换破坏密文。加密字段无法直接做等值查询和范围查询，如果需要按手机号精确查询，可以额外存储手机号的HMAC值（带密钥的哈希）作为查询索引，但HMAC密钥要与加密密钥分开管理。

很多开发者把脱敏当成加密，这是严重误解。脱敏是展示层的格式化处理，例如手机号显示为1385678，它不改变存储的数据。加密是存储层的安全防护，改变数据本身。规范中必须明确：日志、接口返回、页面展示使用脱敏；数据库存储、缓存、备份使用加密。两者可以叠加，但不能互相替代。接口返回给前端的敏感字段即使做了脱敏，如果前端需要完整值（如用户修改资料时回显），必须通过受控的接口获取，且该接口要有严格的鉴权和审计。

加密解密失败时不能把异常堆栈直接抛给前端，更不能把明文数据打到日志里。规范要定义统一的错误码，例如“数据处理失败”，避免暴露加密细节。所有涉及敏感数据的操作都要记录审计日志，包括谁在什么时间访问了哪个字段、解密了多少条数据、密钥轮换记录。审计日志本身不能包含敏感明文，可以记录操作类型、数据主键、操作者ID、时间戳和结果状态。异常的解密频率或批量导出行为要触发告警，这能帮助发现内部滥用和外部攻击。

字段级加密会带来CPU开销和存储膨胀，AES-GCM在现代CPU上有硬件加速指令（AES-NI），性能损耗通常在可接受范围内。批量处理时可以复用Cipher实例，但每次加密必须重新生成nonce。对于高并发场景，可以将DEK缓存在内存中，避免每次请求都访问KMS，但缓存要有过期时间和内存加密保护。数据库索引无法建立在加密字段上，所以查询设计要避免对加密字段做模糊搜索。如果业务确实需要模糊搜索，可以考虑使用保序加密或同态加密，但这些方案在性能和安全性上都有明显缺陷，不建议在一般业务中引入。

如果业务涉及支付卡数据，必须遵守PCI DSS标准，卡号存储要求强加密、密钥管理有严格规范，CVV禁止存储。涉及个人信息保护，要符合《个人信息保护法》和《数据安全法》的要求，加密是其中一项技术措施，但不是全部，还需要配合访问控制、数据分类分级、应急预案。医疗行业遵循HIPAA，金融行业遵循等保2.0和银保监会相关指引。规范中要引用适用的合规条款，并定期做安全审计和渗透测试，验证加密实现没有漏洞。

第一，使用ECB模式，相同的明文块会生成相同的密文块，泄露数据模式。第二，IV或nonce固定不变，导致相同明文生成相同密文，攻击者可以分析流量。第三，密钥和密文存在同一个数据库或同一台服务器。第四，密码用可逆加密而不是哈希。第五，加密了数据库字段但日志里打印明文。第六，密钥轮换时没有保留旧密钥，导致历史数据无法解密。第七，自研加密算法，认为“别人不知道算法就安全”，这是典型的混淆而非加密。第八，只加密了部分敏感字段，遗漏了关联字段，例如加密了身份证号但没加密姓名和住址，攻击者依然能拼出完整画像。

制定规范后，要配套代码审查工具和自动化扫描，例如在CI流水线中加入敏感数据检测，扫描代码中是否出现明文密钥、是否使用弱算法。建立数据分类分级表，明确每个字段的敏感级别和加密要求。定期做密钥轮换演练，验证轮换流程不会导致服务中断。对开发人员进行安全编码培训，重点讲清楚“为什么不能用ECB”和“密钥为什么不能硬编码”。每季度做一次加密实现审计，检查是否有新字段遗漏、是否有旧的弱算法还在使用。规范不是写完就结束，要持续迭代，跟随业务变化和新的安全威胁更新。