脱敏与加密必须在数据库层或ORM层做，因拖库攻击直接读取磁盘文件（如.ibd），绕过所有应用层逻辑；前端或业务层处理对此完全无效。
SQL注入一旦发生，参数化查询已失效，此时防拖库的核心不是堵入口，而是让偷走的数据无法直接使用——脱敏与加密是最后一道实操防线。
为什么脱敏和加密必须在数据库层或ORM层做，而不是靠前端或业务逻辑？
因为拖库攻击的目标是原始数据文件或备份快照，只要数据以明文形式落在磁盘（如MySQL的.ibd文件、PostgreSQL的base目录），攻击者拿到文件就能绕过所有应用层逻辑直接读取。前端过滤、JS校验、甚至Controller里的encrypt()调用，对拖库完全无效。
- 脱敏/加密必须作用于写入磁盘前的字节流，常见位置是：数据库驱动拦截（如ShardingSphere的
EncryptAlgorithm）、ORM的字段级hook（如Hibernate的@Convert）、或数据库自身的透明数据加密TDE功能 - 如果用业务代码手动加解密，容易漏掉批量导入、日志打印、缓存序列化等场景，反而制造“伪安全”假象
- AES-256-GCM比单纯AES-128-CBC更稳妥，前者自带完整性校验，能防止密文被篡改后解出乱码数据却无报错
脱敏配置选掩码还是加密？看字段用途和合规等级
掩码（如138****5678）和加密（如AES_ENCRYPT()）不是二选一，而是按字段敏感度分层使用：
- 开发测试环境用掩码：身份证、手机号等字段只需保留格式和部分可见性，方便排查问题，且不依赖密钥管理
- 生产环境核心字段必须加密：银行卡号、密码哈希盐值、生物特征模板等，即使拖库也需离线爆破或密钥泄露才能还原
- 警惕“伪脱敏”：用固定字符串替换（如所有身份证都替换成
110101199001011234）等于没脱敏，审计时会被直接否决
MySQL TDE和应用层加密哪个更可靠？
MySQL 5.7+的TDE（Transparent Data Encryption）只加密.ibd文件，不加密binlog、slow log、error log，也不加密网络传输中的明文包。这意味着：
- 若攻击者有服务器root权限，可直接抓包
mysqld进程的内存或socket流量，TDE形同虚设 - 应用层加密（如ShardingSphere或MyBatis插件）控制力更强，但要注意：加密后的字段长度会膨胀（AES加密后约+30%），需提前调整
VARCHAR长度，否则插入失败报Data too long for column - 密钥不能硬编码在配置文件里，推荐用Vault或KMS托管，每次解密前动态拉取，避免密钥随代码库泄露
脱敏后查询怎么保持可用性？别让WHERE条件失效
全量加密会导致WHERE name = '张三'无法命中——因为数据库里存的是密文。解决方案有限且必须明确选型：
- 确定性加密（如
AES_ENCRYPT('张三', @key)固定输出同一密文）：支持等值查询，但牺牲安全性，可能被频率分析破解 - 带索引的脱敏字段：对手机号用
SHA2(phone, 256)生成摘要并建索引，查询时先算摘要再匹配，但无法支持LIKE '138%' - 完全放弃模糊查询：合规要求高的场景（如GDPR），直接禁止前端输入框支持模糊搜索，改为精确ID或唯一业务码查询
最常被忽略的一点：日志系统本身可能记录脱敏前的SQL语句。检查slow_query_log和应用框架的SQL日志开关，确保password、id_card等字段在日志中已被***覆盖，否则日志文件就是第二份明文数据库。
