sql防火墙是内核级规则拦截，非网络设备，运行于数据库进程内部，对每条sql执行前做语法解析与策略匹配；金仓kingbasees v009r002c014通过alter system启用并配置黑白名单，可识别' or '1'='1等恶意语义，即使绕过waf仍有效。
SQL防火墙 不是“最后一道物理防线”，这个说法本身存在概念混淆——数据库防火墙（Database Firewall）和 SQL防火墙（如金仓 KingbaseES 内置的内核级 SQL 防火墙）属于不同层级、不同部署形态的安全组件，不能混为一谈。
SQL防火墙 是内核级规则拦截，不是网络设备
- 它运行在数据库进程内部，对每一条进入执行器前的 SQL 语句做语法解析与策略匹配，不依赖网络位置或流量镜像；
- 比如金仓
KingbaseES V009R002C014的sql_firewall功能，需通过ALTER SYSTEM SET sql_firewall.enabled = on启用，并配合sql_firewall.rules配置黑白名单； - 它能识别
' OR '1'='1这类语义异常，也能拦住带UNION SELECT、EXEC、XP_CMDSHELL的非法组合，哪怕应用层已绕过 WAF、Nginx 或代理层； - 常见误判点：开启后未同步更新白名单，导致合法的动态 SQL（如报表引擎拼接的
ORDER BY ${col}）被误杀，日志里会报ERROR: SQL statement blocked by sql_firewall。
数据库防火墙是串联式网关，本质是中间件
- 它是独立部署的硬件/软件网关，工作在 TCP 层或协议解析层，典型如 Oracle Database Firewall、Imperva SecureSphere；
- 必须把数据库流量显式重定向（如改端口、加代理、DNS劫持）才能生效，一旦绕过该节点（比如直连 DB 端口、运维跳板机未走代理），防护即失效；
- 它能做
SELECT * FROM users WHERE username = 'admin' --这类注释绕过检测，但对加密传输（如 SSL/TLS）或非标准端口上的流量识别能力受限； - 性能影响明显：实测高并发 OLTP 场景下，吞吐下降 15%~30%，延迟增加 2~8ms，且不支持某些高级协议特性（如 PostgreSQL 的流复制协议）。
为什么不能叫“最后一道物理防线”
- “物理防线”暗示不可绕过、硬隔离，但数据库防火墙可被运维直连绕过，
SQL防火墙可被超级用户（postgres/sysdba）禁用或降权规避； - 真正难以绕过的防线是：参数化查询 + 最小权限原则 + 应用层输入过滤。这两者失效后，才轮到数据库侧兜底；
- 金仓等国产数据库把
sql_firewall做进内核，是为弥补历史遗留系统无法改造应用层的现实约束，而非替代基础防护。
关键点其实就一个：没有哪一层能“绝对封死”SQL注入。sql_firewall.enabled 开着不代表万事大吉，规则没覆盖新业务逻辑、管理员账号权限过大、日志没接入 SIEM，都可能让防护形同虚设。
真正起效的，永远是规则+权限+监控三者的闭环，而不是某个名字带“防火墙”的模块。
