Oracle Database 23c引入的SQL防火墙是一种深度集成的安全机制，其核心目标是通过监控和阻止未经授权的SQL语句及SQL注入攻击来加固数据库防线 。与传统的网络层防火墙或外挂WAF（Web应用防火墙）不同，它直接运行在数据库内核中，无需任何外部组件或代理，从而实现了更高效率和更低延迟的防护 。

其工作原理主要基于 “允许列表”（Allow List）模型 。管理员首先为特定数据库用户（通常是应用程序用户） 捕获 其在一个受信任环境（如测试或生产稳定运行期）中执行的所有合法SQL语句及会话上下文（如客户端IP、操作系统用户、程序名） 。随后，基于此捕获结果 生成防火墙策略 ，明确规定该用户“允许执行什么SQL”以及“允许从什么环境连接”。策略启用后，任何偏离该允许列表的SQL语句或连接尝试（即潜在的SQL注入或越权访问）都将被实时 检测、记录并阻止   。

SQL防火墙能够识别多种常见的SQL注入攻击模式，包括但不限于布尔型盲注、报错注入、联合查询注入和堆叠查询注入 。这使其成为对现有安全措施（如最小权限原则、输入验证）的强有力的补充，而非替代 。

环境准备与用户配置示例

在配置SQL防火墙前，需要规划并创建相应的测试用户。典型的测试环境涉及三类角色：

防火墙管理员（FWADMIN） ：负责启用、配置和管理SQL防火墙策略，需要被授予 SQL_FIREWALL_ADMIN 角色 。

模式所有者（SCHEMA_OWNER） ：拥有应用程序表和数据的用户 。

应用程序用户（APP_USER） ：最终执行SQL语句的账户，其行为将被防火墙监控和控制 。

以下SQL脚本展示了如何在一个PDB（如 FREEPDB1 ）中搭建此环境 ：

-- 以SYSDBA身份连接
conn sys/SysPassword1@//localhost:1521/freepdb1 as sysdba
-- 创建防火墙管理员
drop user if exists fwadmin cascade;
create user fwadmin identified by fwadmin;
grant create session to fwadmin;
grant sql_firewall_admin to fwadmin;

配置与使用SQL 防火墙

配置SQL防火墙通常遵循“捕获-生成-启用”的流程，以下是一个分步示例。

步骤1：启用SQL防火墙并开始捕获
首先，以防火墙管理员身份登录并全局启用SQL防火墙功能 。

conn fwadmin/fwadmin@//localhost:1521/freepdb1exec dbms_sql_firewall.enable;

可以通过查询 DBA_SQL_FIREWALL_STATUS 视图确认状态为 ENABLED   。

接着，为需要监控的应用程序用户（ APP_USER_1 ）启动一个捕获会话。 top_level_only => true 参数表示仅捕获直接由用户发出的SQL，而不捕获其调用的存储过程内部的语句（这有助于简化初始策略） 。

begin
  dbms_sql_firewall.create_capture (
    username       => 'APP_USER_1',
    top_level_only => true,
    start_capture  => true);
end;
/

步骤2：模拟合法应用行为
在捕获开启期间，使用 APP_USER_1 用户连接到数据库，并执行其在正常业务中应该使用的所有SQL语句。这一步的目的是建立“允许列表”的基准 。

-- 使用app_user_1连接后执行
select * from schema_owner.t1;
select * from schema_owner.t2;

步骤3：生成并启用防火墙策略
捕获足够长时间以覆盖典型业务周期后（例如，一个完整的业务日或迭代周期），停止捕获并基于捕获到的信息生成允许列表策略 。

-- 停止对APP_USER_1的捕获
exec dbms_sql_firewall.stop_capture('APP_USER_1');
-- 基于捕获的日志生成允许列表
exec dbms_sql_firewall.generate_allow_list('APP_USER_1');
-- 为APP_USER_1启用防火墙策略（启用阻断模式）
exec dbms_sql_firewall.enable_allow_list('APP_USER_1', enforce => dbms_sql_firewall.enforcement_block);

步骤4：测试防火墙效果
策略启用后， APP_USER_1 只能执行已被捕获并加入允许列表的SQL。

•  合法SQL测试 ：再次执行 select * from schema_owner.t1; ，应该成功执行。

•  非法SQL/注入测试 ：尝试执行一个未在捕获期间出现过的SQL，或者一个典型的注入片段，将会被阻止 。

-- 此语句未被捕获，预计将被防火墙阻止
delete from schema_owner.t1;
-- 或尝试一个联合查询注入的变形语句
select * from schema_owner.t1 union select 1 from dual;

执行上述非法语句时，数据库会返回错误，提示违反了SQL防火墙策略。

步骤5：监控与维护
可以通过查询 DBA_SQL_FIREWALL_VIOLATIONS 等视图来监控被阻止的违规行为 。需要注意的是，应用程序会迭代更新，当有新SQL语句需要执行时，必须更新允许列表，否则会被阻止。因此，SQL防火墙的维护是一个持续的过程，最好与CI/CD流程集成 。

重要注意事项与最佳实践

捕获周期需全面 ：捕获应持续足够长的时间，以覆盖应用程序的所有业务变化，包括月度、季度报表等低频操作。否则，新SQL将被错误阻止 。

应用于PDB级别 ：SQL防火墙可以在根容器（CDB）或可插拔数据库（PDB）级别启用，提供了灵活的管控粒度 。

监控模式先行 ：在生产环境全面启用阻断之前，可以先在 仅记录（Audit-Only）模式 下运行一段时间。通过将 ENFORCE 参数设置为 ENFORCEMENT_AUDIT ，可以观察可能被阻止的语句而不实际影响业务，从而验证策略的准确性 。

是补充而非替代 ：SQL防火墙是深度防御策略中的一层，不能替代良好的应用程序设计、最小权限原则和常规的数据库补丁更新 。