数据库 SQL 防火墙：从内核层构建主动防御
在数字化转型背景下，数据是核心资产，但 SQL 注入攻击始终是悬在头顶的隐患。即便开发团队采用预编译或输入过滤，遗留代码、第三方组件漏洞或人为疏忽仍可能留下后门。被动修补往往滞后，我们需要一种更主动的防御手段。
金仓数据库（KingbaseES）V009R002C014 版本内置的 SQL 防火墙提供了一种思路：从数据库内核层构建主动防御，让恶意 SQL 无处遁形。
SQL 注入的原理与风险
SQL 注入的本质是攻击者将恶意代码伪装成正常输入，欺骗数据库执行非预期操作。
例如，登录表单中若未做参数化处理，用户在用户名栏输入 ' OR '1'='1，后台查询语句可能变为：
SELECT * FROM users WHERE OR '1'='1' AND password='xxx'
由于 '1'='1' 恒为真，攻击者可绕过认证获取所有用户信息。更严重的情况如附加 DROP TABLE users;--，可能导致整张表被清空。
传统防御依赖应用层编码习惯，一旦动态 SQL 遗漏参数化，漏洞便产生。而 SQL 防火墙直接在数据库内核层'设卡'，无论应用层是否有疏忽，所有 SQL 语句都必须经过校验才能放行。
三种工作模式：灵活配置防护策略
核心理念是建立合法 SQL 白名单，只允许白名单内的 SQL 执行。系统提供三种模式以适应不同阶段：
- 学习模式：管理员指定监控用户后，系统自动观察并记录这些用户执行的 SQL，将其转化为合法规则。无需手动编写复杂规则，避免人为疏漏。
- 警告模式：上线前开启。所有 SQL 照常执行，但若不在白名单中，系统发出警报并记录日志。安全管理员可根据日志微调白名单，确保业务不受影响。
- 报错模式：测试充分后开启。任何不在白名单的 SQL 会被直接拦截并返回错误，同时写入日志。恶意注入企图将被彻底阻断。
这种分级策略让防护落地更平滑，有效降低误杀风险。
性能与准确率实测
1. 高准确率，近乎零误报
SQL 防火墙读取数据库内核解析结果计算特征值，而非简单字符串匹配。这意味着即使 DML 语句中的常量变化（如不同用户 ID），特征值依然稳定。
实测数据如下：
| 非法 sql 总数 | 900 万 |
| 合法 sql 总数 | 100 万 |
| 被检出的非法 sql 数 | 900 万 |
| 被拦截的合法 sql 数 | 0 |
| 未被检出的非法 sql 数 | 0 |
