SQL安全加固核心是权限最小化、输入严格过滤、敏感数据脱敏和操作全程可审计：应用账号限表限操作，运维账号需跳板机+双因素认证，审计账号仅只读；防注入必须用参数化查询，动态SQL须白名单校验；敏感字段存储加密、查询脱敏、日志过滤；审计日志接入SIEM并设异常告警。
SQL安全加固不是加个防火墙就完事，核心是控制“谁在什么条件下能访问、操作哪些数据”。重点在于权限最小化、输入严格过滤、敏感信息脱敏和操作全程可审计。
权限管理：按角色分层，拒绝超级用户滥用
数据库账号不能“一权到底”。生产环境应禁用root或sa等高权限账户直接连接应用。建议划分三类角色：
- 应用账号：仅授予业务必需的SELECT/INSERT/UPDATE权限，且限制在指定库、指定表，禁止跨库查询
- 运维账号：拥有DBA级权限，但必须通过跳板机+双因素认证登录，操作需工单审批
- 审计账号：只读权限，仅能访问系统日志表（如mysql.general_log）和审计视图，不可执行任何DML
防止SQL注入：参数化查询是铁律，拼接字符串是红线
所有外部输入（URL参数、表单、HTTP头、Cookie）都必须视为不可信。关键做法：
- 后端代码统一使用预编译语句（PreparedStatement / PDO::prepare），变量走占位符，不拼SQL字符串
- 对已存在的动态SQL场景（如动态排序字段、多条件搜索），采用白名单校验：只允许字段名出现在预设列表中（如['name', 'created_at', 'status']）
- 前端不做“防注入”幻想——JS校验可绕过，服务端才是最后一道门
敏感数据保护：存储加密 + 查询脱敏 + 日志过滤
身份证、手机号、银行卡等字段不能明文落库：
- 存储层：使用TDE（透明数据加密）或列级加密（如MySQL AES_ENCRYPT），密钥由KMS统一托管，不硬编码在配置中
- 查询层：应用返回前对敏感字段做掩码处理（如138****1234），或由数据库视图自动脱敏（CREATE VIEW user_safe AS SELECT id, CONCAT(LEFT(phone,3),'****',RIGHT(phone,4)) AS phone FROM user）
- 日志层：关闭general_log，慢日志中过滤掉含WHERE、VALUES的完整SQL，避免泄露参数值
审计与监控：记录“谁、何时、干了什么”，并设置异常告警
光有日志不够，要能快速定位风险行为：
- 开启数据库审计功能（如MySQL Enterprise Audit Plugin 或 Percona Audit Log），记录登录、权限变更、删表、大批量删除/更新等高危操作
- 将审计日志接入SIEM系统（如ELK或Splunk），设置规则：1小时内同一账号执行5次以上DROP、非工作时间触发TRUNCATE、失败登录超10次等，实时短信/钉钉告警
- 定期导出并人工复核特权账号操作记录，尤其关注凌晨、节假日时段
基本上就这些。不复杂但容易忽略——真正起作用的不是最炫的技术，而是每一条权限是否真最小、每一个输入是否真过滤、每一次删除是否有留痕。
