数据安全已成为企业核心资产，但 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;--，附加在输入后，查询如 SELECT * FROM users WHERE，如果应用层没有做好过滤，整张表可能瞬间灰飞烟灭。
传统防御手段（如预编译）固然有效，但完全依赖开发人员的编码习惯，一旦某个动态 SQL 遗漏了参数化，漏洞便应运而生。而金仓数据库 SQL 防火墙，直接在数据库内核层'设卡查验'，无论应用层是否有疏忽，所有 SQL 语句都必须经过它的'法眼'才能放行。
三种模式，灵活配置防护策略
它的核心理念很简单：只让'好人'通行，拒绝'坏人'闯入。通过建立合法 SQL 白名单，系统只允许白名单内的 SQL 正常执行，任何不在白名单的语句都会被警告或拦截。
金仓 SQL 防火墙设计了三种工作模式，可以灵活配置：
学习模式：管理员指定需要监控的用户后，系统自动'观察'并学习这些用户执行的所有 SQL，将它们记录为合法规则。无需手动编写复杂的规则，避免了人为疏漏。
警告模式：正式上线前，可以先开启警告模式。此时，所有 SQL 都会被执行，但若某条 SQL 不在白名单中，系统会发出警报并记录日志。安全管理员可以根据日志微调白名单，确保业务不受影响。
报错模式：经过充分测试后，开启报错模式，真正开启防护。任何不在白名单的 SQL 都会被直接拦截并返回错误，同时写入日志。恶意 SQL 注入的企图将彻底破产。
你可以根据实际场景直接选用不同模式，让防护策略的落地更平滑、可控，再也不用担心误杀正常业务。
性能与准确率实测
高准确率，近乎零误报
SQL 防火墙会全面检查所有数据库连接执行的 SQL 语句，且无法被绕过，只有白名单内的合法 SQL 可以正常执行。同时，SQL 防火墙直接读取数据库内核解析 SQL 的结果来计算特征值，而非简单匹配字符串。这意味着，即使 DML 语句中的常量千变万化（比如查询不同的用户 ID），特征值仍然稳定不变，不会误判。
为验证 SQL 防火墙的拦截能力，我们通过对 100 万条合法 SQL，和 900 万条非法 SQL 进行多轮实测：
| 指标 | 数值 |
|---|
