前言
SQL 注入是数据库安全领域最顽固的威胁之一。即便开发团队严格执行预编译与输入过滤，遗留代码、第三方组件或偶发的人为疏忽，依然可能留下可被利用的突破口。面对这一长期存在的安全隐患，单纯依赖应用层的'亡羊补牢'已难以为继。
金仓数据库（KingbaseES）内置的 SQL 防火墙提供了一种数据库内生的主动防护方案——它不依赖应用层代码修复，而是直接从内核层识别并阻断恶意 SQL，让安全团队从'疲于补漏'真正转向'规则先行'。
一、SQL 注入原理：攻击者如何'钻空子'
理解 SQL 注入的原理，是理解防火墙价值的前提。
SQL 注入就像不速之客通过门缝溜进房子：攻击者将恶意代码伪装成正常输入，诱导数据库执行意料之外的操作。
典型案例一：绕过身份认证
用户登录表单中输入用户名 ' OR '1'='1，原本的查询语句就会被篡改为：
SELECT * FROM users WHERE username='' OR '1'='1' AND password='xxx'
由于 '1'='1' 恒为真，认证逻辑被完全绕过，攻击者无需密码即可获取所有用户数据。
典型案例二：破坏性操作
在输入中附加 ; DROP TABLE users;--，查询变为：
SELECT * FROM users WHERE id='1; DROP TABLE users;--'
整张数据表可能就此被删除，造成不可逆的数据损失。
传统防御的局限性
查询参数化（预编译）是目前最主流的防注入手段，通过变量绑定将数据与指令分离，从根本上阻断注入路径。然而，这一方案高度依赖开发者的编码习惯——一旦存在动态拼接 SQL 的遗漏场景，漏洞便随之而来。相比之下，SQL 防火墙部署在数据库端，对所有连接的 SQL 进行全局检查，能够有效弥补应用层防护的盲区。
二、SQL 防火墙原理：白名单驱动的主动防护
SQL 防火墙的核心逻辑清晰而有效：学习合法 SQL，构建白名单，只放行已知安全的语句。
具体来说，防火墙会在学习阶段收集业务系统实际执行的 SQL 语句，提取其结构特征并形成白名单规则库。一旦进入防护模式，任何不在白名单内的 SQL——无论来自注入攻击还是异常操作——都将被识别并处理。
金仓 SQL 防火墙提供三种可灵活切换的工作模式：
学习模式 防火墙根据安全管理员的配置，自动采集指定用户执行的 SQL 语句，提取特征值并写入白名单规则库，无需人工逐条录入。
警告模式 防火墙实时监测所有连接即将执行的 SQL。若 SQL 不在白名单内，语句仍会执行，但防火墙会同步向用户发出警报并写入日志。该模式通常用于上线前的验证阶段，帮助安全管理员评估白名单覆盖是否完整，并据此调整规则。
报错模式 防火墙实时拦截所有不在白名单内的 SQL，阻止其执行，同时向用户返回错误信息并记录日志。这是正式防护阶段的推荐模式，实现对非法 SQL 的硬性阻断。
三种模式形成了'学习 → 验证 → 防护'的完整闭环，兼顾灵活性与安全性。
