加密与动态脱敏是防脱裤的最后防线，敏感字段须加密存储（如aes-256-gcm）、密码须单向哈希（如bcrypt），脱敏应在数据库代理层最靠近输出端实现，并配合最小权限、审计与密钥管理。
单纯靠防注入不能拦住脱裤，一旦攻击者绕过防护或利用高权限账户执行 SELECT *，加密和动态脱敏才是最后防线。
敏感字段必须加密存储，而非仅靠防注入
参数化查询能防拼接式注入，但拦不住合法查询下的全量导出。比如攻击者已拿到一个有 SELECT 权限的账号，又通过漏洞（如越权、逻辑缺陷）触发了“导出全部用户数据”接口——此时所有字段若明文存储，等于直接送库。
- 密码必须用
bcrypt或Argon2单向哈希，禁用MD5/SHA1 - 身份证号、手机号、银行卡号等 PII 数据，应使用 AES-256-GCM 等带认证的加密算法，密钥由 KMS 管理，绝不硬编码
- 避免在应用层解密后再传给前端：加密字段应在数据库层或中间件层完成加解密，减少内存泄露面
- 注意时序风险：加密后字段长度可能变化（如填充），需统一用
VARCHAR(255)或固定长度类型，避免因长度差异暴露原始值位数
动态脱敏要在查询路径最靠近输出端的位置做
脱敏不是“显示时打星号”，而是让数据库返回的结果本身就不含完整敏感信息。越早脱敏，越难被中间环节（如日志、缓存、调试输出）意外泄露。
- 优先在数据库视图或函数中实现：例如 PostgreSQL 的
pgcrypto+substr()组合，MySQL 8.0+ 可用HEX(AES_ENCRYPT())配合应用层密钥管理 - ORM 层脱敏容易失效：Hibernate
@Convert或 MyBatisTypeHandler只对实体生效，绕过 ORM 的原生 SQL 查询会跳过脱敏逻辑 - API 网关层脱敏有盲区：只能处理响应体 JSON，对二进制导出（如 Excel、CSV）、GraphQL 字段选择、WebSocket 推送等场景无效
- 真正可靠的点是数据库代理层（如 ProxySQL、ShardingSphere-Proxy）：可拦截
SELECT响应，在发往应用前按策略重写字段值
加密与脱敏必须配合最小权限和审计才有效
再强的加密，如果数据库账号能执行 SHOW CREATE TABLE 或 INFORMATION_SCHEMA 查询，攻击者就能反推哪些字段加密、用的什么算法、甚至猜出密钥长度。
- 禁止应用账号访问
INFORMATION_SCHEMA和mysql系统库（MySQL）；PostgreSQL 中收回pg_catalog的SELECT权限 - 对高频敏感字段查询（如
SELECT phone FROM users）开启 DBA 审计日志，设置告警阈值（如单次查超 1000 行触发人工复核） - 加密密钥轮换时，旧密文必须保留解密能力——否则历史数据不可读；但轮换后新写入必须用新密钥，且密钥版本需随数据一并记录
- 别忽略备份文件：加密只作用于运行时数据，
mysqldump或pg_dump输出仍是明文，需额外对备份文件加密（如用gpg --symmetric）
最容易被忽略的是：加密和脱敏都解决不了“合法账号被社工盗用”这个前提。如果登录口令弱、MFA 缺失、会话 token 泄露，再厚的加密层也会被从内部掀开。防御链条里，人和流程永远是最薄的一环。
