怎样在MySQL中对敏感手机号和身份证进行列加密-mysql教程-PHP中文网

MySQL 8.0+ 的 AES_ENCRYPT()/AES_DECRYPT() 不适合直接用于手机号、身份证等敏感字段加密，因其返回二进制值无法索引或模糊查询，ECB 模式导致相同明文密文一致，且无认证防篡改；推荐应用层使用 AES-GCM 等带认证加密，密钥由 KMS 托管，密文 base64 后存 VARCHAR。

怎样在mysql中对敏感手机号和身份证进行列加密

MySQL 8.0+ 原生加密函数是否适合敏感字段？

MySQL 提供了 AES_ENCRYPT() 和 AES_DECRYPT()，但它们不适合直接用于手机号/身份证列加密——不是功能不行，而是用错场景。这些函数返回的是二进制（BLOB），无法索引、无法比较、无法做 LIKE 查询，且密钥硬编码在 SQL 里极易泄露。

更关键的是：AES_ENCRYPT() 不带认证，无法防篡改；若用 ECB 模式（默认），相同号码加密后结果完全一致，攻击者可直接通过密文频率反推真实值（比如“138****1234”反复出现）。

所以结论很明确：不要在 MySQL 层做应用级敏感字段加解密。

推荐方案：应用层加密 + MySQL 存储密文字符串

把加密逻辑移出数据库，在应用代码中完成，MySQL 只负责安全存储和传输。这是目前最可控、审计友好、也符合等保/个保法要求的做法。

使用带认证的加密模式，如 AES-GCM 或 AES-CBC + HMAC-SHA256（推荐 crypto/aes + crypto/cipher 在 Go，或 cryptography.hazmat.primitives.ciphers 在 Python）
密钥由 KMS（如阿里云 KMS、AWS KMS）托管，应用启动时动态获取，绝不写死
加密后 base64 编码为字符串，存入 VARCHAR(255) 字段（AES-256-GCM 密文 + IV + tag 总长通常 ≤ 192 字节）
解密只在必要业务环节（如实名核验）触发，避免全量解密扫描

示例（Python 简化逻辑）：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.primitives import padding
import os
<p>def encrypt_phone(phone: str, key: bytes) -> str:
iv = os.urandom(16)
cipher = Cipher(algorithms.AES(key), modes.CBC(iv))
encryptor = cipher.encryptor()
padder = padding.PKCS7(128).padder()
padded_data = padder.update(phone.encode()) + padder.finalize()
ciphertext = encryptor.update(padded_data) + encryptor.finalize()
return base64.b64encode(iv + ciphertext).decode()  # IV 显式拼接，便于解密</p>

如果必须用 MySQL 函数，至少要绕过哪些坑？

极少数遗留系统不允许改应用层，只能妥协使用 MySQL 内置函数。此时务必规避以下问题：

AES_ENCRYPT() 必须显式指定模式，禁用默认 ECB：AES_ENCRYPT(data, key, 'AES-256-CBC')（MySQL 8.0.30+ 支持）
IV 必须随机生成并和密文一起存储（例如拼成 CONCAT(HEX(iv), ':', HEX(AES_ENCRYPT(...)))），否则 CBC 失效
密钥不能是明文字符串，应从会话变量注入：SET @key = UNHEX(SHA2('your-salt-and-app-secret', 256));，再传给 AES_ENCRYPT()
字段类型必须为 VARBINARY（不是 VARCHAR），长度至少 256，否则截断导致解密失败
解密时若返回 NULL，大概率是密钥/IV/模式不匹配，不是数据损坏——MySQL 不报具体错误