金仓 SQL 防火墙落地指南：学习、警告、阻断三步配置

预编译固然能避免这类问题，但前提是每个数据库调用都正确实现了绑定变量。如果代码里有动态拼接 SQL 的地方，预编译就帮不上忙。防火墙在数据库端做全局兜底，不管应用层漏没漏，都能检查。

防火墙如何工作

防火墙的核心是白名单。它先学习正常业务的 SQL，生成基于语法特征的规则。DML 语句里的常量（比如 WHERE id = 1 和 WHERE id = 99）并不影响特征值，所以不会因为数据变化而误拦。防火墙有三种模式：

实测效果：几乎零漏报

官方对 100 万条合法 SQL 和 900 万条非法 SQL 进行了多轮测试，结果很干脆：

宣称准确率 99.99%，实际基本等于 100%。

性能损耗方面，在 100 个并发连接、每条连接执行 500 种不同 SQL 的压力场景下，开销稳定在 6% 以内。警告模式下，无论非法 SQL 占比怎么变化，损耗都在 -5.5% 到 -6% 之间；阻断模式下，非法 SQL 占比越高，额外开销反而越小（因为非法语句提前终止，不消耗执行资源）。

警告模式性能数据：

阻断模式性能数据：

注意阻断模式下损耗出现正值是因为测试将非法请求也计入了吞吐，实际合法 SQL 性能并未下降。

配置只需四步

下面以 KingbaseES V009R002C014 为例，操作很直接。

1. 启用插件

在 kingbase.conf 里加上 shared_preload_libraries = 'sql_firewall'，然后重启数据库。接下来在目标库创建扩展：

CREATE EXTENSION sql_firewall;

2. 学习模式

以安全管理员身份，为目标用户开启学习：

SELECT sql_firewall.set_firewall_mode('app_user', 'learning');
-- 查看状态
SELECT * FROM sql_firewall.status();

让业务系统正常运行一段时间，防火墙会自动采集白名单。

3. 警告模式验证

切换到警告模式，检查有没有合法 SQL 被误报：

SELECT sql_firewall.set_firewall_mode('app_user', 'warning');
-- 查看最近的告警
SELECT username, query, fired_at FROM sql_firewall.firewall_log ORDER BY fired_at DESC LIMIT 20;

如果出现误报，手工把对应 SQL 加入白名单：

SELECT sql_firewall.add_rule('app_user', 'SELECT id, name FROM orders WHERE user_id = $1');

确认无误报后进入下一步。

4. 阻断模式上线

SELECT sql_firewall.set_firewall_mode('app_user', 'enforcing');

这时可以尝试一条注入语句，验证是否被拦截：

SELECT * FROM users WHERE username = '' OR '1'='1';
-- ERROR: sql_firewall: query is not in the whitelist

思路转变

SQL 防火墙把被动应急变成主动防御，白名单管理也比想象中省心。对数据库安全来说，多一层内核级防护总是值得的，尤其当应用层防护链条存在不确定因素时。