数据已成为企业核心资产，数据库安全更是重中之重。各类威胁中，SQL 注入因门槛低、隐蔽性强，长期位居 OWASP Top 10 前列。它利用应用逻辑漏洞，将恶意指令伪装成正常参数传入数据库，导致越权访问甚至删库破坏。
虽然预编译、参数化查询是标准做法，但在真实环境中，老旧系统遗留代码、第三方组件漏洞、多团队协作疏漏等问题依然存在。单纯依赖应用层加固往往力不从心。能否从数据库自身出发，构建一层独立可靠的防御体系？金仓数据库 V009R002C014 内置的 SQL 防火墙提供了内核级主动防护思路，让安全从'被动堵漏'转向'主动防御'。
一、SQL 注入：简单却致命的经典威胁
SQL 注入本质是攻击者破坏原有 SQL 语义，使数据库执行非预期指令。由于数据库对提交语句缺乏'意图判断'，只要语法合法便会执行。
典型场景如用户登录接口，后台采用拼接方式构造查询：
SELECT * FROM users WHERE username='输入内容' AND password='输入内容'
若攻击者在用户名输入 ' OR '1'='1，最终执行的 SQL 变为：
SELECT * FROM users WHERE username=''OR'1'='1'AND password='xxx'
'1'='1'恒成立，身份校验失效，攻击者可无需账号密码登录。更严重的注入如 1'; DROP TABLE users;--，可能导致业务表被删除。传统防护依赖开发规范，一旦业务规模扩大，很难保证所有 SQL 都严格遵循安全规范。金仓 SQL 防火墙的思路则不同：不依赖外部系统，直接在数据库内核层对所有 SQL 进行统一校验，从源头阻断非法执行。
二、基于白名单的智能防护：三种模式平滑落地
核心设计是建立合法 SQL 白名单机制：只执行已授权语句，对未知语句告警或拦截。适配不同阶段，提供三种模式：
- 学习模式：上线初期指定用户，系统自动采集分析 SQL，提取特征生成规则集。无需人工编写正则，适合复杂业务快速建立基线。
- 警告模式：规则初步生成后运行。SQL 正常执行，但不在白名单内的语句会被标记、记录日志并触发告警。管理员可分析日志完善白名单，避免业务中断。
- 报错模式：白名单验证后切换至严格防护。不在白名单内的 SQL 直接拒绝执行，返回错误并记录日志。恶意语句因不在合法规则中被拦截。
