如何在MySQL中对身份证与银行卡等字段进行应用透明加密？-mysql教程-PHP中文网

MySQL 8.0+原生TDE仅支持表空间级加密，不支持字段级加密；身份证等敏感字段需应用层AES-GCM/CBC加密并Base64存储，密钥须通过环境变量或KMS管理，且加密后无法直接索引或模糊查询。

如何在mysql中对身份证与银行卡等字段进行应用透明加密？

MySQL 8.0+ 原生透明数据加密（TDE）不支持字段级加密

MySQL 的 innodb_encrypt_tables 和表空间加密只作用于整个表空间或表，无法对 id_card 或 bank_card 这类敏感字段单独加密。强行用 TDE 加密整张用户表，会导致所有字段（包括 user_name、created_at）被一并加密，查询性能下降、索引失效、且无法满足「仅加密特定字段」的合规要求。

真正可行的路径只有两条：应用层加密 + 数据库存密文，或使用 MySQL 企业版的 MYSQL_ENCRYPTION 函数（但该函数已弃用，且不推荐用于生产）。所以实际项目中，99% 的团队选择前者 —— 在应用代码里完成加解密逻辑。

应用层加密必须自己实现 AES 加解密，不能依赖 MySQL 内置函数

虽然 MySQL 提供了 AES_ENCRYPT() 和 AES_DECRYPT()，但它们有硬伤：AES_ENCRYPT() 返回 VARBINARY，结果不可预测长度；密钥明文写在 SQL 里极易泄露；无法统一管理密钥轮换；且一旦字段参与 WHERE 查询（比如 WHERE id_card = ?），就必须先解密全量数据再比对，丧失索引能力。

更稳妥的做法是：在应用中用标准 AES-GCM 或 AES-CBC（带 PKCS#7 填充）加密，将结果 Base64 编码后存入 VARCHAR 字段。示例（Python）：

from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.primitives import padding
import os
<p>key = os.environ[b"APP_ENCRYPTION_KEY"]  # 32字节 AES-256 密钥
iv = os.urandom(16)
cipher = Cipher(algorithms.AES(key), modes.CBC(iv))
encryptor = cipher.encryptor()
padder = padding.PKCS7(128).padder()
data = padder.update(b"11010119900307271X") + padder.finalize()
ciphertext = encryptor.update(data) + encryptor.finalize()
stored_value = base64.b64encode(iv + ciphertext).decode()  # 存入数据库</p>

注意：iv 必须随密文一起存储（如拼接在开头），否则无法解密；密钥绝不能硬编码，应通过环境变量或密钥管理服务（KMS）注入。

身份证/银行卡字段加密后无法做模糊查询和等值索引

这是最容易被忽略的代价。加密后的 id_card 是随机字节串，LIKE '%1990%' 或 = '11010119900307271X' 全部失效。如果业务真需要按身份证前6位查户籍地，只能额外加一个明文字段 id_card_prefix（存前6位哈希或直接明文），并为其建索引。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

常见折中方案包括：

对身份证号提取脱敏特征（如出生年份、性别码、地区码）存为独立明文字段，用于条件过滤
银行卡号只加密中间 8–10 位，前后保留 4 位用于 Luhn 校验和显示（6228****1234），但需确认是否符合你所在地区的隐私规范
如必须支持等值查询，考虑使用确定性加密（如 AES-SIV），但会牺牲部分安全性 —— 相同明文永远生成相同密文，可能被频率分析攻击

不要把加解密逻辑写在 DAO 层或 SQL 拼接里

常见错误是让 MyBatis 的 <bind></bind> 或 JPA 的 @PrePersist 直接触发加密，导致加解密分散在多个实体类中，密钥管理混乱、算法升级困难。正确做法是封装成独立服务：

定义一个 SecureFieldService，提供 encryptIdCard(String raw) 和 decryptIdCard(String encrypted) 方法，内部统一处理密钥获取、加解密、异常转换。所有涉及 id_card 和 bank_card 的读写，都必须经过该服务 —— 这样后续切换 KMS、启用国密 SM4、或审计密钥使用痕迹，才具备可操作性。

复杂点在于密钥生命周期管理：开发环境用本地密钥文件，测试环境对接 HashiCorp Vault，生产环境必须走云厂商 KMS（如 AWS KMS、阿里云 KMS），且加解密调用要带 context 标签（如 {"table":"user","field":"id_card"}），否则审计时根本分不清哪次调用对应哪个业务场景。