SQL系统安全加固核心是“权限最小化+输入强过滤+行为可审计”，需严格分离账号权限、强制参数化查询、守住复杂查询权限边界、开启审计与异常拦截。

SQL系统安全加固不是只靠加个防火墙或改个密码，核心在于“权限最小化+输入强过滤+行为可审计”。真实环境中，80%的SQL注入和越权访问，都源于开发阶段对查询逻辑的过度信任和对用户输入的放任。

严格分离数据库账号权限

生产环境绝不能用root或sa这类超级账号连接应用。应为每个业务模块创建独立账号，并仅授予必要权限：

• 订单服务账号：只允许对orders、order_items表执行SELECT/INSERT/UPDATE（禁止DELETE和DROP）
• 报表后台账号：仅SELECT权限，且限定在视图v_sales_summary上，不暴露原始明细表
• 运维账号：启用WITH GRANT OPTION需审批，临时提权必须走工单并限时回收

参数化查询是铁律，动态拼接是红线

哪怕看起来“只是查个状态”，只要带用户可控输入，就必须用预编译参数。看一个典型翻车案例：

错误写法（PHP）：
$sql = "SELECT * FROM users WHERE username = '" . $_GET['u'] . "'";
攻击者传入 u=admin' -- 即可绕过认证。

正确写法（PDO）：

$stmt = $pdo->prepare("SELECT * FROM users WHERE username = ?");

$stmt->execute([$_GET['u']]);

注意：ORM如MyBatis的#{} 是安全的，${} 是拼接，严禁用于变量值。

复杂查询也要守住安全边界

多表JOIN、子查询、窗口函数本身不危险，但常被用来掩盖越权逻辑。例如：

某后台接口本该只查“本人所属部门数据”，却写了：

SELECT u.name, d.dept_name FROM users u

JOIN departments d ON u.dept_id = d.id

WHERE d.region = (SELECT region FROM users WHERE id = ?)

表面看用了参数，但子查询返回的是当前用户所在大区，而主查询未限制u.dept_id归属——导致能跨部门查人。加固方式是显式加AND u.dept_id IN (SELECT dept_id FROM user_depts WHERE user_id = ?)，把权限判断落到具体资源维度。

开启审计与异常拦截双机制

光靠代码防护不够，数据库层要主动“盯梢”：

• 开启MySQL general_log或SQL Server Audit，记录所有含WHERE、IN、UNION的查询（这些是注入高发模式）
• 用ProxySQL或自研中间件拦截明显恶意特征：如1=1、@@version、sleep(、连续多个嵌套括号
• 对单IP 1分钟内超10次报错的SQL请求自动熔断并告警

基本上就这些。安全不是加功能，是不断剔除信任假设的过程——尤其在写JOIN、写子查询、写存储过程时，多问一句：“这个条件真能挡住非授权数据吗？”