SQL数据库敏感数据保护需结合脱敏与加密：脱敏用于开发测试等需格式保留场景，加密用于生产环境高敏感字段；先分级识别身份、金融、健康、业务类字段，再依级别实施静态/动态脱敏或AES-256/TDE加密，并强化权限管控与审计。
SQL数据库中的敏感数据保护，核心在于“不让不该看的人看到真实信息”，脱敏和加密是两种最常用且互补的手段。脱敏适用于开发、测试、分析等需要保留数据格式和可用性的场景；加密则用于生产环境存储或传输中对高敏感字段（如身份证号、银行卡号、密码）的强保护。
哪些字段该脱敏？先识别再分级
不是所有字段都需要处理，重点盯住明确属于个人隐私或业务机密的数据：
- 身份类：身份证号、护照号、手机号、邮箱地址
- 金融类：银行卡号、信用卡CVV、交易金额（部分场景）、开户行信息
- 健康类：病历号、诊断结果、医保卡号（医疗系统）
- 业务类：客户地址详情、合同金额、供应商银行账户
建议按“公开/内部/机密/绝密”四级打标，不同级别对应不同保护强度——比如手机号可掩码为138****1234，而银行卡号在非必要时应加密存储而非仅脱敏。
脱敏怎么做？选对方法比工具更重要
脱敏不是简单替换字符，要兼顾不可逆性、一致性、可识别性和业务兼容性：
- 静态脱敏（SDM）：导出前批量处理，适合测试库初始化。用正则+哈希（如SHA-256加盐）生成稳定假值，确保同一身份证号每次脱敏结果一致
- 动态脱敏（DDM）：查询时实时拦截并转换，权限驱动。例如MySQL 8.0+可通过DATA_MASKING插件或视图+函数实现；SQL Server支持行级安全与动态数据掩码策略
- 避免弱脱敏：不推荐纯随机替换（丢失统计特征）、不推荐无盐哈希（易被彩虹表破解）、不推荐前端JS脱敏（绕过即失效）
加密怎么落地？别只靠应用层
加密需分层设计，单点防护容易失效：
- 传输层：强制TLS 1.2+，禁用SSLv3及弱密码套件，数据库连接字符串必须含encrypt=true（SQL Server）或sslmode=require（PostgreSQL）
- 存储层：优先用TDE（透明数据加密）保护整个数据库文件；字段级加密用AES-256，密钥交由KMS（如AWS KMS、阿里云KMS）托管，禁止硬编码到SQL脚本或配置文件
- 应用层补充：密码必须bcrypt/scrypt/PBKDF2哈希，绝不存明文；敏感字段读写走加密SDK（如Java的JCE、Python的cryptography），不在SQL语句里拼接解密逻辑
别忘了审计与权限这个“守门人”
再好的脱敏和加密，也挡不住高权限账号滥用：
- 关闭SELECT *，按角色授予最小列权限（如客服只能查脱敏手机号，不能查身份证）
- 启用数据库审计日志，重点捕获含WHERE条件的SELECT、UPDATE、DELETE操作，关联账号与IP
- 定期扫描高危SQL模式（如LIKE '%身份证%'、未参数化的拼接查询），用SQL注入检测工具辅助排查
