Oracle 26ai SQL Firewall 入门与白名单匹配

Oracle 26ai 把 SQL Firewall 做进了数据库内核。它给数据库账号建立一份允许执行的 SQL 和可信连接路径清单，应用发来的请求不在清单里，可以只记日志，也可以直接拦截。

这个功能不依赖数据库前面的代理，也不需要修改客户端。本地连接、网络连接、明文和加密流量都会经过检查，PL/SQL 中发出的 SQL 也在范围内。策略按数据库用户生效， CDB root 和 PDB 都可以配置。

对应用服务账号比较有意义。账号口令泄露后，攻击者即使连上数据库，只要执行的 SQL 或连接来源不在白名单里，就会留下违规记录，必要时还可以直接阻断。

它主要检查什么

SQL Firewall 检查两类信息。一类是 SQL 语句本身；另一类是连接会话上下文，包括客户端 IP 、操作系统用户和操作系统程序名。不匹配的 SQL 会记录到 DBA_SQL_FIREWALL_VIOLATIONS ，阻断时通常返回 ORA-47605: SQL Firewall violation 。

白名单为什么不按完整 SQL 比较

先看一个例子。下面两条查询只是客户号不同：

SELECT order_no

FROM   orders

WHERE  customer_id = 1001;

SELECT order_no

FROM   orders

WHERE  customer_id = 1002;

SQL Firewall 捕获时会把字面量归一化， 1001 和 1002 会被替换成占位符，留下同一种 SQL 形态。因此不需要为每个客户号分别增加规则。

这种匹配的方式适合参数值变化、SQL 结构稳定的应用。如果程序根据用户选择动态拼接列名、连接方式或 WHERE 条件，那么每改一次结构，就可能需要重新采集或补充白名单。同一个 SQL 从不同 IP 、操作系统用户或程序发起，也会得到不同的判断结果。

策略怎么生成

SQL Firewall 不能根据表结构自动猜出一份完整白名单。一般要先采集正常业务 SQL ，再根据捕获结果生成允许列表。管理员启用功能，并为目标账号启动捕获：

EXEC DBMS_SQL_FIREWALL.ENABLE;

BEGIN

  DBMS_SQL_FIREWALL.CREATE_CAPTURE(

    username       => 'APP_USER',

    top_level_only => FALSE,

    start_capture  => TRUE);

END;

/

APP_USER 是演示账号。 top_level_only 为 FALSE 时，会同时采集用户直接执行的 SQL 和 PL/SQL 单元中发出的 SQL 。采集阶段要把登录、查询、报表、批处理和异常分支都跑一遍。

业务流量采集完成后，停止捕获并生成白名单：

EXEC DBMS_SQL_FIREWALL.STOP_CAPTURE ('APP_USER');

EXEC DBMS_SQL_FIREWALL.GENERATE_ALLOW_LIST ('APP_USER');

刚生成的白名单不要急着阻断。可以先启用策略，但把 block 设为 FALSE ，让不在清单里的请求继续执行，同时记录违规：

BEGIN

  DBMS_SQL_FIREWALL.ENABLE_ALLOW_LIST(

    username => 'APP_USER',

    enforce  => DBMS_SQL_FIREWALL.ENFORCE_ALL,

    block    => FALSE);

END;

/

观察一段时间后再打开阻断。SQL Firewall 只记录成功执行的 SQL ，如果采集时漏掉某个批处理或接口分支，直接启用阻断很容易把正常业务拦掉。

适合哪些账号先用

适合先试的通常是 SQL 形态稳定、连接来源明确的应用服务账号。这类账号每天执行的语句变化不大，白名单维护量可控，即使账号凭据泄露，攻击者也很难从陌生地址执行新的 SQL 。

临时分析账号就不太适合一上来覆盖。它们每天可能产生大量不同结构的 SQL ，白名单需要不断补充，误拦和运维成本都会上来。

另外要注意，SQL Firewall 虽然已经做进数据库内核，但仍属于需要取得许可的功能。它能补充最小权限、 TDE 、统一审计和 Database Vault ，但不会修正应用里拼接 SQL 的代码。