从「亡羊补牢」到「规则先行」：金仓数据库 SQL 防火墙实战解析
SQL 注入是数据库安全最顽固的威胁之一。即便开发团队严格执行预编译与输入过滤，遗留代码、第三方组件或人为疏忽依然可能留下突破口。金仓数据库（KingbaseES）V009R002C014 内置的 SQL 防火墙提供了一种数据库内生的主动防护方案——不依赖应用层代码修复，直接从内核层识别并阻断恶意 SQL，让安全团队从「疲于补漏」转向「规则先行」。
一、SQL 注入原理
SQL 注入就像不速之客通过门缝溜进房子：攻击者将恶意代码伪装成正常输入，诱导数据库执行意外操作。
典型攻击示例
场景 1：绕过登录认证
用户在登录表单输入 ' OR '1'='1 作为用户名，原本安全的查询被篡改为恒真条件，绕过所有认证：
-- 正常查询
SELECT * FROM users WHERE username = 'alice' AND password = 'secret';
-- 注入后：OR '1'='1' 恒为真，直接绕过认证，返回所有用户数据
SELECT * FROM users WHERE username = '' OR '1'='1' AND password = 'anything';
场景 2：删表破坏
攻击者在 ID 参数中注入 1; DROP TABLE users;--，利用分号执行第二条 DDL 语句：
-- 正常查询
SELECT * FROM users WHERE id = '42';
-- 注入后：分号分隔出第二条语句，整张表被删除
SELECT * FROM users WHERE id = '1'; DROP TABLE users; --';
场景 3：联合查询拖库
通过 UNION 拼接查询敏感系统表，批量获取账号信息：
-- 注入 UNION，将系统用户信息拼入结果集
SELECT id, name FROM products WHERE id = '0' UNION SELECT usename, passwd FROM pg_shadow; --';
传统防御的局限
预编译（参数化查询）是最常见的应对手段，能有效绑定变量、阻止注入：
-- 安全写法：$1/$2 为绑定变量，注入字符串无法改变语句结构
PREPARE login_stmt AS SELECT * FROM users WHERE username = $1 AND password = $2;
EXECUTE login_stmt('alice', 'secret');
但预编译依赖开发者在每一处数据库调用中正确实施。一旦存在遗留的动态 SQL 拼接、第三方 ORM 漏洞或开发者疏漏，防线就会出现缺口。相比之下，SQL 防火墙在数据库端全局检查，无论应用层是否做了防护，均能兜底拦截。
二、SQL 防火墙原理概述
SQL 防火墙的核心功能是防止数据库执行非法 SQL，且不影响合法 SQL 的正常执行。防火墙会学习合法 SQL 并组成白名单，启用防护后只允许白名单内的 SQL 正常执行。当攻击者利用 SQL 注入等漏洞试图执行恶意语句时，防火墙识别并拦截不在白名单内的 SQL，预防注入或恶意操作。
防火墙读取 KingbaseES 对 SQL 的解析结果计算特征值。DML 语句中的常量（如 WHERE id = 1 与 WHERE id = 99）不影响特征值，因此不会因业务数据变化产生误报。
金仓 SQL 防火墙分为三种模式，可灵活配置：
| 模式 | 行为 | 适用场景 |
|---|---|---|
| 学习模式 | 自动将执行的 SQL 记录为白名单规则 | 初次部署，采集合法业务 SQL |
| 警告模式 | SQL 正常执行，非白名单 SQL 写入告警日志 | 测试白名单完整性，观察覆盖情况 |
| 报错模式 | 非白名单 SQL 被阻断，返回错误并写日志 | 正式上线，全面拦截非法请求 |
三、核心优势
1. 99.99% 准确率
SQL 防火墙对所有数据库连接的所有 SQL 进行全量检查，无法被绕过。只有白名单内的合法 SQL 可以正常执行；执行不在白名单内的非法 SQL 会发出警告或被拦截报错。同时，防火墙读取 KingbaseES 对 SQL 的解析结果计算特征值，DML 类 SQL 中的常量不影响特征值计算，对读写操作的具体数值不敏感，大幅降低误报率。
为验证拦截能力，我们对 100 万条合法 SQL 和 900 万条非法 SQL 进行多轮实测：
| 指标 | 数量 |
|---|---|
| 合法 SQL 总数 | 100 万 |
| 非法 SQL 总数 | 900 万 |
| 被检出的非法 SQL | 900 万（检出率 100%） |
| 被误拦的合法 SQL | 0 |
| 未被检出的非法 SQL | 0 |
综合准确率：99.99%
2. 性能稳定，损耗极低
作为 KingbaseES 原生集成的内部插件，无需开发者进行额外的复杂操作，也不会导致性能大幅损耗，更不会存在生态适配问题。我们在 100 个会话并发执行 500 条不同 SQL 的场景下，测试数据库每秒的吞吐量，经过多轮测试，发现损耗在 6% 以下，性能损耗主要来自 SQL 重复查询。
警告模式性能表现：
| 非法 SQL 占比 | 0% | 1% | 3% | 5% | 10% |
|---|---|---|---|---|---|
| 性能损耗 | -5.61% | -5.55% | -5.99% | -5.66% | -5.67% |
报错模式性能表现：
非法 SQL 会在执行之前被拦截并报错，但仍算入吞吐量，所以非法 SQL 占比越高，测得的吞吐量越大属于正常现象。
| 非法 SQL 占比 | 0% | 1% | 3% | 5% | 10% |
|---|---|---|---|---|---|
| 性能损耗 | -5.70% | -2.83% | -1.48% | +0.07% | +4.94% |
3. 两步完成配置，自动建立白名单
管理员只需指定学习哪些用户的 SQL，然后由 SQL 防火墙在学习模式下自动获取 SQL 规则即可，无需手动制定详细规则，避免因人为失误导致白名单规则难以全面覆盖，增加误报或漏报的风险。同时支持按用户级防护，更加灵活。
四、配置操作演示
以下以 KingbaseES V009R002C014 为例，展示 SQL 防火墙的完整配置流程。
第一步：启用插件
-- 在 kingbase.conf 中添加预加载库（需重启数据库生效）
-- shared_preload_libraries = 'sql_firewall'
-- 重启后，在目标数据库中创建扩展
CREATE EXTENSION sql_firewall;
第二步：进入学习模式，采集白名单
-- 使用安全管理员身份操作
-- 为目标用户开启学习模式
SELECT sql_firewall.set_firewall_mode('app_user', 'learning');
-- 查看当前各用户防火墙状态
SELECT * FROM sql_firewall.status();
学习期间让业务系统正常运行，防火墙自动采集合法 SQL 作为白名单。
第三步：切换警告模式，验证白名单
-- 切换为警告模式，观察是否有合法业务 SQL 被误报
SELECT sql_firewall.set_firewall_mode('app_user', 'warning');
-- 查看告警日志，确认非白名单 SQL 的来源
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');
若告警日志中无误报，说明白名单已覆盖全部合法业务 SQL，可进入下一步。
第四步：切换报错模式，正式防护
-- 正式上线，开启拦截
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 防火墙将复杂的 SQL 防护功能简化为「学习、警告、报错」三种模式，能够自动学习规则，并根据规则校验、拦截 SQL 语句。这将被动的、滞后的防护与补救，转变为主动学习、可管理的规则与全面的校验拦截，实现风险前置预防。
