MySQL存储敏感数据须加密：密码用带盐强哈希（如bcrypt），其他可逆字段用应用层AES加密+KMS密钥管理，禁用数据库内置加密函数；TDE仅保护静态数据；需配套最小权限、审计与脱敏。
MySQL 中存储敏感数据（如身份证号、手机号、银行卡号、密码等）必须加密，不能明文保存。核心原则是：加密在应用层做，数据库只存密文；密钥与数据分离，避免密钥硬编码或和数据库同机部署。
密码类字段：永远用不可逆哈希 + 盐值
用户登录密码绝不能加密存储，而应使用强哈希算法（如 bcrypt、Argon2 或 PBKDF2），并为每个用户生成唯一随机盐值。MySQL 本身不推荐用 SHA2() 或 MD5() 等通用哈希函数处理密码——它们无盐、无迭代、易被彩虹表或 GPU 暴力破解。
- 应用层调用 bcrypt（如 Python 的
bcrypt.hashpw()、Java 的BCryptPasswordEncoder）生成带盐哈希值，再存入 MySQLVARCHAR(255)字段 - 验证时同样用原始密码 + 数据库存储的完整哈希值比对，无需解密
- 避免在 SQL 中用
SHA2(password, 256)直接插入——盐值缺失且无法控制迭代轮数
可逆敏感字段：AES 加密 + 应用层密钥管理
对于需后续解密使用的字段（如用户真实姓名、银行卡号），应在应用代码中完成 AES-256-GCM 或 AES-128-CBC 加密，再将密文（Base64 编码后）存入 TEXT 或 VARCHAR 字段。密钥不得写死在配置文件或代码中。
- 使用 KMS（如 AWS KMS、阿里云 KMS、HashiCorp Vault）动态获取加密密钥，每次加解密都调用 KMS API
- 若无 KMS，至少把密钥存在独立配置服务（如 Consul、etcd）或环境变量中，并限制数据库服务器访问权限
- MySQL 8.0+ 提供
AES_ENCRYPT()/AES_DECRYPT()，但密钥仍需传入 SQL，极易泄露（如被慢查询日志、审计日志、代理中间件捕获），不推荐生产使用
字段级透明加密（TDE）：适合合规场景，但有局限
MySQL 企业版支持 InnoDB 表空间级 TDE（Transparent Data Encryption），可加密 ibd 文件，防止磁盘被盗导致数据泄露。但它不解决内存、SQL 日志、备份文件、DBA 权限滥用等问题。
- TDE 加密的是物理存储，对已授权连接的用户完全透明——DBA 仍可直接
SELECT明文 - 仅保护静态数据（at-rest），不保护传输中（in-transit）或使用中（in-use）的数据
- 启用需修改配置
innodb_encrypt_tables=ON，并配置密钥环插件（keyring_file 或 keyring_okv）；密钥文件必须设严格权限（如 600），且不应与数据目录同盘
最小权限 + 审计 + 脱敏：配套必须跟上
加密只是纵深防御的一环。还需从访问控制和行为监控层面加固：
- 为不同应用分配专用数据库账号，按需授予
SELECT/INSERT/UPDATE权限，禁用FILE、PROCESS、GRANT OPTION等高危权限 - 开启 MySQL 企业版 Audit Log 或社区版的
general_log+过滤（慎用，性能影响大），重点记录含敏感表名（如user_profile、payment_card）的查询 - 开发和测试环境必须使用脱敏数据：用
REPLACE()、正则替换或专业工具（如 Delphix、DataSunrise）生成仿真但不可还原的假数据
