kingster 17 min read

Oracle Database 23ai 新特性系列 —— 第五期

Oracle Database 23ai/26ai 新特性系列 —— 第五期：AI 时代的全面防护体系

在第四期中，我们聚焦于开发体验革命与空间数据能力的升级。如果说 AI 能力决定了数据库的上限，那么安全体系则决定了其下限——尤其在 AI 智能体、RAG 工作流和自然语言交互等新兴范式正在重构企业数据访问模式的当下，传统的安全模型正面临前所未有的挑战。

Oracle Database 23ai 和 26ai 在安全领域的投入远超常规版本迭代。从内核级的 SQL 防火墙到身份感知的深度数据安全，从抗量子加密到增强的区块链表，一个贯穿数据全生命周期、覆盖传统威胁与 AI 原生风险的安全体系正在形成。本期将系统解读这一安全体系的构建思路与核心特性。

一、SQL Firewall：数据库内核的智能防护

1.1 传统防护的盲区

在 Oracle Database 23ai/26ai 引入 SQL Firewall 之前，数据库安全的防线主要部署在网络层和访问控制层：网络防火墙用于过滤 IP 和端口，数据库层的权限系统用于控制用户对对象的访问。然而，这两种机制都无法有效应对一个日益严峻的威胁——SQL 注入攻击。攻击者利用应用代码中的漏洞，在合法数据库连接中注入恶意 SQL 语句，绕过应用层的访问控制，直接对数据库发起越权操作。

更棘手的是，传统的 Web 应用防火墙（WAF）和网络防火墙对加密流量无能为力，而现代应用几乎全部使用 TLS 加密。当 SQL 语句在加密通道中传输时，外部防火墙看到的只是一串无法解析的密文，无法识别其中是否隐藏着恶意代码。这一盲区正是 SQL 注入攻击最活跃的战场。

1.2 数据库内核级的 SQL 防火墙

SQL Firewall 是 Oracle Database 23ai 中作为 Oracle Database Vault 组件提供的新特性，从 26ai 开始深度集成到数据库内核中。其核心设计思想是在数据库引擎内部对所有传入的 SQL 语句进行实时检查和授权：

SQL Firewall inspects all incoming SQL statements and ensures that only explicitly authorized SQL is run.

SQL Firewall 拦截所有的数据库访问——无论 SQL 语句来自本地连接还是网络连接，无论传输是加密的还是明文的，均被统一检查。它检查的不仅仅是顶层 SQL，还包括存储过程中的 SQL 调用以及相关的数据库对象访问。

1.3 工作流程：学习、授权、阻断

SQL Firewall 的工作流程可概括为三个阶段：

  1. 学习阶段（Capture Phase） ：SQL Firewall 进入“学习模式”，捕获应用程序在正常运行时产生的所有 SQL 语句，记录到一个白名单允许列表（Allow-List）中。
  2. 授权阶段（Enforcement Phase） ：将学习阶段生成的允许列表应用到 SQL Firewall 策略中。管理员可以选择只记录违规 SQL 或直接阻断。
  3. 防护阶段（Protection Phase） ：SQL Firewall 进入“主动防护模式”，仅允许允许列表中的 SQL 语句执行，任何不在白名单中的 SQL 都会被实时阻断。

管理员还可以基于会话上下文（如 IP 地址、操作系统用户名、操作系统程序名）来限制数据库账户的连接方式，进一步降低凭据被盗或滥用的风险。

1.4 典型应用场景

SQL Firewall 最典型的应用场景是应用程序工作负载。在现代应用架构中，前端应用通过统一的服务账户连接数据库，所有用户的数据库操作均通过同一个数据库账户执行。传统的权限模型只能控制“哪个应用账户能访问哪些表”，无法区分“哪个最终用户在做什么操作”。SQL Firewall 通过白名单机制，将应用程序的业务逻辑固化为可执行的 SQL 模式——任何偏离业务逻辑的 SQL（包括注入攻击、异常查询）都将被实时阻断，无论攻击者是否已经获取了服务账户的密码。

1.5 26ai 的增强：白名单的精细化管理

从 26ai 开始，SQL Firewall 获得了更精细的管理能力。DBMS_SQL_FIREWALL PL/SQL 包新增了 APPEND_ALLOW_LIST_SINGLE_SQL 过程，允许管理员将单条特定的 SQL 记录从捕获日志或违规日志追加到现有的允许列表中。在之前的版本中，若要添加一条 SQL 到白名单，管理员必须将整个捕获日志全部追加，然后再手动删除不需要的条目——这一改进显著提升了白名单管理的灵活性和效率。

二、Deep Data Security：为 AI 智能体时代设计的细粒度授权

2.1 AI 智能体带来的安全挑战

SQL Firewall 解决了 SQL 注入这一经典威胁，但 AI 智能体时代带来了全新的安全挑战。当企业开始部署 AI 智能体来自动执行数据分析、报告生成、业务流程等任务时，传统的访问控制模型开始失效：

  • 动态生成的 SQL：AI 智能体根据用户的自然语言提问动态构建 SQL 查询。这些 SQL 在开发阶段无法预见，因此无法像传统应用那样提前设置静态的白名单或权限。
  • 高权限服务账户：AI 智能体通常通过高权限的服务账户连接数据库，以便代表不同用户执行多样化任务。但这也意味着一旦智能体被操纵或产生错误，可能导致大规模的数据泄露。
  • 应用层访问控制的局限：传统的权限模型在应用层执行访问控制。当 AI 智能体动态生成 SQL 时，应用层无法预先审查每条 SQL 的安全性。
  • RAG 工作流的挑战：使用向量嵌入进行语义搜索的 RAG 工作流，同样难以通过应用层控制来确保安全。
  • “氛围编码”的安全隐患：AI 辅助的应用开发（即“vibe coding”）可能从训练数据集中复制不安全的授权模式，进一步加剧风险。

2.2 数据库原生的身份感知授权

Oracle Deep Data Security 是 Oracle AI Database 26ai 中推出的下一代数据访问控制系统，其核心创新在于将最终用户的身份信息透明地传递到数据库层，在数据库内核中强制执行细粒度的访问控制。

与传统的 Virtual Private Database（VPD）和 Real Application Security 不同，Deep Data Security 采用声明式的 SQL 策略模型，不再依赖过程化的 PL/SQL 编程和 API 驱动控制。

2.3 核心能力

Deep Data Security 的核心能力可概括为四个层面：

身份感知的访问控制：最终用户和 AI 智能体的身份、角色和属性在运行时被透明地传递到数据库。数据库根据这些上下文信息执行访问控制策略，决定用户和智能体在何种条件下能做什么操作。

细粒度的数据库内授权：支持行级、列级甚至单元格级的安全控制，实现最小权限原则。用户和 AI 智能体只能访问其被授权的数据元素。由于策略在数据库内强制执行，访问控制能够跨多个应用和智能体保持一致。

声明式 SQL 策略：授权策略以声明式的 SQL 语法表达，将访问控制与应用逻辑解耦。当应用和智能体演化时，策略易于更新，减少了开发者在每个应用中重复实现授权逻辑的工作量。工作负载特定的规则也可独立定义，使企业能够在共享 Schema 上安全地扩展 AI 功能，同时不影响传统工作流的正常运行。

受控的特权提升：敏感操作可以临时获得权限提升，且仅限于已批准的工作流。这有助于防止 AI 智能体执行不受限制的数据库读写操作，并消除了共享高权限服务账户的需求。

2.4 与传统授权体系的比较

特性VPD (传统方案)Deep Data Security (26ai)策略定义过程化 PL/SQL 函数声明式 SQL身份传递依赖应用上下文内置身份传播机制AI 智能体支持不支持原生支持审计粒度行/列级保留最终用户身份性能开销函数调用开销数据库内核级优化Deep Data Security 确保即使 AI 智能体被操纵或被注入恶意指令，数据库内核仍会强制执行最终用户的权限边界，从根本上阻止越权数据访问。

三、区块链表：企业级的防篡改审计

3.1 区块链表的核心机制

区块链表（Blockchain Table）是 Oracle Database 21c 引入的一种防篡改、仅能插入的特殊表类型。表中的每一行数据通过加密哈希与前一行链接，形成不可篡改的哈希链。任何对历史数据的修改都会破坏哈希链，被系统的验证过程立即检测。

与去中心化的区块链平台（如 Hyperledger、以太坊）不同，Oracle 的区块链表采用中心化架构——由数据库管理员在受信任的企业环境中运行——但通过哈希链和数字签名机制，实现了与去中心化区块链同等的防篡改能力，同时保持了数据库的性能和管理效率。

3.2 23ai/26ai 的重大增强

23ai 和 26ai 对区块链表进行了多项突破性增强，使其从“防篡改日志”演变为真正的企业级审计基础设施：

V2 哈希版本：23ai/26ai 引入了新的 V2 哈希版本（原版本为 V1），支持更多高级功能，同时保留了与 V1 的兼容性。

用户链（User Chains） ：在早期版本中，区块链表仅支持系统链——每插入一行，系统随机选择一个系统链存放。23ai/26ai 引入了用户链概念，允许基于最多三个用户定义列（NUMBER、CHAR、VARCHAR2、RAW 类型）来组织行链。例如，为银行交易日志按账户号创建用户链，可以针对特定账户号独立验证其交易记录的完整性，无需扫描全表。

行版本化（Row Versions） ：23ai/26ai 允许在区块链表中为同一业务对象保留多个历史版本。系统提供视图 bctable_last$ 用于查看最新的行版本，保障了在防篡改表中使用行版本化能力。

日志历史（Log History） ：这是 23ai/26ai 中最具突破性的增强之一。Flashback Data Archive 的历史表现在可以是区块链表——系统将对一个或多个普通用户表的变更自动记录到区块链日志历史表中，每次变更作为哈希链中的单独行追加。企业无需改造应用即可获得对关键业务表的防篡改审计跟踪。

跨区块链表事务：23ai 新增了跨区块链表的事务能力，支持在复杂业务流中跨越多个区块链表进行一致性操作，这在金融交易、供应链等需要跨多个不可变日志的场景中至关重要。

添加和删除用户列：应用演进过程中，需要对表结构进行修改。23ai/26ai 允许在已创建的区块链表和不可变表上添加和删除列，同时保持已有数据的完整性——被删除列的数据会被保留以维护加密哈希链的连续性。

会签（Countersignature） ：用户可以在签名行时请求数据库会签。会签及其元数据被记录在行中，并返回给调用者，调用者可将其保存在其他数据存储中以实现不可否认性。

3.3 应用场景与核心价值

区块链表的核心价值在于为金融交易日志、医疗存证、供应链溯源等场景提供集中式防篡改审计层。其典型应用包括：

  • 金融合规日志：交易记录、账户操作日志不可篡改，满足监管审计要求
  • 医疗电子病历：影像检查和检验结果不可篡改，保障患者数据完整性
  • 药品追溯：供应链数据只可插入不可删除，满足追溯要求
  • 系统审计日志：登录日志、操作日志禁止任何修改（包括 DBA 管理员）

四、数据脱敏（Data Redaction）的全面增强

4.1 数据脱敏的核心定位

Data Redaction 是 Oracle Advanced Security Option 的一部分，在 Autonomous Database 中免费提供。它在查询运行时选择性遮盖敏感数据（如身份证号、薪资、医疗记录），而保持底层数据不变。通过这种方式，企业可以在不修改应用代码的情况下，为不同用户提供不同粒度的数据视图。

4.2 23ai 的突破性增强

在 23ai 之前，Data Redaction 存在一个关键限制：如果查询涉及被脱敏列的某些 SQL 构造（如 GROUP BY、DISTINCT、ORDER BY、聚合函数、视图等），查询会直接报错 ORA-28094: SQL construct not supported by data reduction，导致应用中断。

23ai 彻底打破了这一限制：
SQL 构造23ai 之前的支持情况23ai 的支持情况直接列选择✅ 支持✅ 支持WHERE 条件中的脱敏列✅ 支持✅ 支持DISTINCT 子句❌ 报错✅ 支持GROUP BY 子句❌ 报错✅ 支持ORDER BY 子句❌ 报错✅ 支持聚合函数（SUM/COUNT/AVG）❌ 报错✅ 支持集合操作（UNION/INTERSECT）❌ 报错✅ 支持视图中的表达式❌ 报错✅ 支持函数索引中的虚拟列❌ 报错✅ 支持（自动脱敏）现在，包含脱敏列的复杂查询可以正常运行，脱敏后的值会在聚合、分组、排序等操作中正确处理，无需重写查询逻辑。这一改进使得 Data Redaction 能够无缝集成到现有业务应用中，显著降低了开发和运维成本。

五、统一审计（Unified Auditing）的 AI 化升级

5.1 统一审计框架的演进

Oracle Database 23ai 中，统一审计（Unified Auditing）经历了一次重大架构升级。统一审计将所有数据库审计记录整合到一个统一的审计跟踪中，替代了早期版本分散在多个表和文件中的审计数据。

5.2 列级审计

23ai 新增了列级审计能力，允许管理员针对表和视图中的特定列创建审计策略。在早期版本中，要审计对某一列的访问，必须在整个表上启用审计。23ai 通过审计策略创建过程中的 ACTIONS 子句，支持指定要审计的列列表：

CREATE AUDIT POLICY employees_pol ACTIONS UPDATE(salary) ON hr.employees;

这一能力显著减少了不必要的审计记录产生的“干扰信息”，使审计策略更具针对性，在满足合规要求的同时控制了审计数据量。

5.3 原生 JSON 审计存储与 AI 分析

23ai 的审计系统将审计事件以原生 JSON 格式存储，新增了 AUDIT_EVENT_JSON 列。这一变化带来了多重价值：

  • 高效查询：支持 JSON 索引和 JSON 函数查询，可在大规模审计数据中快速检索
  • SIEM 集成：JSON 格式输出可直接被主流 SIEM 系统摄取，无需自定义解析
  • AI 增强的异常检测：审计数据可直接通过数据库的向量搜索能力进行分析，自动识别可疑活动模式
  • PDB 自治：在 PDB 级别完全独立的审计策略，支持真正的多租户审计自治

5.4 AI 辅助的保留策略

23ai 引入了 AI 辅助的保留建议功能。系统基于审计数据的访问模式和使用情况，自动建议最佳的数据保留周期，减少了管理员手动管理审计数据清理的工作量。

六、加密体系：从 AES-256 到抗量子安全

6.1 TDE 的全面强化

透明数据加密（TDE）在 23ai 中获得了多项重大增强：

AES-256 成为默认加密算法：在 23ai 中，TDE 列加密和表空间加密的默认算法统一升级为 AES-256。在之前版本中，列加密默认为 AES-192，表空间加密默认为 AES-128。

AES-XTS 表空间加密模式：23ai 支持在 CREATE TABLESPACE 和 ALTER TABLESPACE 语句中使用 AES-XTS（带密文窃取的 XEX 调整模式），这是 NIST 推荐的表空间加密标准。

GCM 列加密模式：列加密模式从 CBC（密码块链接）升级为 GCM（伽罗瓦/计数器模式），提供了认证加密能力。

密钥派生增强：Oracle RMAN 和列密钥的派生现在使用 SHA512/AES，替代了之前的 SHA-1/3DES，显著提升了密钥生成的安全性。

本地自动登录钱包的安全性提升：23ai 中新创建的本地自动登录钱包与创建它的主机（物理或虚拟）紧密绑定，提供了比之前版本更强的安全防护。

6.2 后量子时代的密码学准备

Oracle AI Database 26ai 在密码学层面进行了一次前瞻性的升级，旨在应对量子计算机未来可能对现有加密体系构成的威胁。

威胁背景：量子计算机利用量子比特和量子叠加原理，能够在某些问题上比传统计算机呈指数级加速。尽管目前的量子计算机（如 Google 的 105-qubit Willow 芯片）尚不足以破解现代加密算法，但研究人员估计量子攻击可能在 5 到 10 年内成为现实。更重要的是，“现在采集，以后解密”（Harvest Now, Decrypt Later）的攻击策略——攻击者当前窃取加密数据并存储，待量子计算机成熟后批量解密——使长期保密数据面临前所未有的风险。

ML-KEM 与混合密钥交换：26ai 支持 NIST 批准的后量子算法 ML-KEM（基于模块格的密钥封装机制）用于密钥交换。从 2026 年 1 月版本开始，26ai 进一步引入了混合密钥交换模式，将 ECDHE（经典的椭圆曲线算法）与 ML-KEM（后量子算法）结合使用：

With hybrid key exchange, session keys come from both an established, proven algorithm (ECDHE) and the latest NIST-approved post-quantum algorithm (ML-KEM).

混合模式的精妙之处在于：系统同时使用两种算法独立生成密钥，再将其组合为最终的会话密钥。只要两种算法中至少有一种保持未被攻破，加密连接就是安全的。这种“双保险”策略同时兼顾了当前的成熟可靠性和未来的抗量子安全性。

端到端的抗量子保护：26ai 的数据保护方案覆盖了数据的全生命周期——静态数据使用 AES-256 加密，传输中的数据通过 TLS 结合 ML-KEM 保护，数字签名则使用 ML-DSA（NIST 批准的模块格数字签名算法）。

6.3 TLS 1.3 与弱加密套件禁用

23ai 默认支持 TLS 1.3 协议。与 TLS 1.2 相比，TLS 1.3 减少了握手过程中的往返次数，提供了更快的连接建立速度和更强的安全性。

同时，23ai 引入了 SSL_ENABLE_WEAK_CIPHERS = FALSE 配置选项，在 sqlnet.ora 文件中控制是否允许弱加密算法。通过禁用已知存在漏洞的弱加密算法，企业可以强制要求所有网络通信使用现代化的强加密标准。

七、网络安全与身份管理增强

7.1 密码长度上限大幅提升

23ai 将数据库账户的密码长度上限从 30 字节大幅提升至 1024 字节。在早期版本中，30 字节的限制在多字节字符集环境下尤为局促，容易导致密码强度不足。1024 字节的上限支持使用长密码短语进行认证，显著增强了抵御暴力破解攻击的能力。

7.2 数据字典保护扩展

23ai 将数据字典保护功能扩展至非 SYS 的 Oracle 模式，进一步强化了对系统元数据的保护。未经授权的用户即使拥有对数据字典视图的访问权限，也无法查看敏感的系统配置信息。

7.3 多因素认证（MFA）支持

从 RU 23.9 开始，Oracle Database 23ai 引入了对多因素认证的原生支持，允许管理员为数据库账户配置 MFA，显著提升了对身份窃取攻击的防御能力。

7.4 Schema 级别权限

23ai 新增了 Schema 级别的系统权限，允许管理员在 Schema 粒度上授予系统权限，而非仅限于整个数据库或单个对象。这在多租户环境和微服务架构中显著简化了权限管理。

7.5 渐进式密码轮换（Gradual Password Rollover）

23ai 引入了渐进式密码轮换机制，允许在密码更新时保留旧密码一段时间，使应用可以平滑过渡到新密码，避免了因应用重启或配置更新不同步导致的连接失败。

八、GoldenGate 23ai 的安全增强

Oracle GoldenGate 23ai 在安全方面也实现了全面升级：

微服务架构的安全性：GoldenGate 23ai 采用全新的微服务架构替代了经典架构，提供简化管理、增强安全性和用户友好界面。

基于证书的安全分发路径：支持使用证书配置源和目标部署之间的安全分发路径，包括服务器证书、私钥和根 CA 证书的配置。

身份提供者集成：GoldenGate 与身份提供者集成，支持安全的通信加密，并确保密码不存储在配置文件中。

JAAS 配置文件的密码加密：支持加密 JAAS 配置文件中的用户 ID 和密码，支持 PLAIN、SCRAM-SHA-256 和 SCRAM-SHA-512 SASL 机制。

总结与预告

在本系列第五期中，我们系统解读了 Oracle Database 23ai/26ai 在安全领域的全面升级：
特性分类核心能力版本SQL Firewall数据库内核级 SQL 注入防护、白名单机制、会话上下文限制23ai / 26aiDeep Data SecurityAI 智能体身份感知授权、行/列/单元格级安全、声明式 SQL 策略26ai区块链表V2 哈希版本、用户链、行版本化、日志历史、跨表事务、会签23ai / 26ai数据脱敏聚合函数/分组/排序/视图全面支持、函数索引自动脱敏23ai (23.6+)统一审计列级审计、原生 JSON 存储、AI 异常检测、PDB 自治23aiTDE 加密AES-256 默认、XTS 表空间模式、GCM 列模式、钱包主机绑定23ai抗量子加密ML-KEM 密钥交换、混合密钥交换（ECDHE + ML-KEM）26aiTLS 1.3默认启用、更快的握手、更强的安全性23ai多因素认证MFA 原生支持23ai (23.9+)GoldenGate 安全微服务架构、证书分发路径、密码加密、身份提供者集成23ai从传统 SQL 注入到 AI 智能体的身份欺骗，从经典 AES 加密到抗量子密码学的前瞻布局，Oracle Database 23ai/26ai 的安全体系展现了清晰的演进路径：将安全防线从网络层和访问控制层，深入到数据库内核和 AI 工作流的每一个环节。

安全不是某个单一特性可以解决的问题，而是需要在架构的每一个层面系统性构建的能力。SQL Firewall 解决了“谁能执行什么 SQL”的问题，Deep Data Security 解决了“AI 智能体代表谁能访问哪些数据”的问题，区块链表解决了“数据被篡改后如何被检测”的问题，数据脱敏和审计解决了“合规与隐私保护”的问题，抗量子加密则解决了“未来十年数据如何保持机密”的问题。这六道防线共同构成了一个面向 AI 时代的端到端数据安全防护体系。

系列总结：本系列五期内容系统涵盖了 Oracle Database 23ai/26ai 在 AI 能力、开发体验、机器学习、安全防护等维度的核心新特性。从 AI Vector Search 的语义搜索革命，到 JSON Relational Duality 的文档-关系融合；从数据库内机器学习的零数据迁移 AI，到 True Cache 的智能缓存架构；从 JavaScript 存储过程的开发民主化，到 Deep Data Security 的 AI 智能体访问控制——Oracle 正在将数据库从一个被动的数据容器，重塑为主动的、具备 AI 原生能力的融合数据平台。

参考资料
[1] Oracle AI Database SQL Firewall Documentation (docs.oracle.com)

[2] Introducing Oracle Deep Data Security (blogs.oracle.com)

[3] Blockchain Table Enhancements in Oracle Database 23ai/26ai (oracle-base.com)

[4] Oracle AI Database Blockchain New Features (docs.oracle.com)

[5] Hands-on with Data Redaction enhancements in Oracle Database 23ai (blogs.oracle.com)

[6] Data Redaction Enhancements in Oracle Database 23ai/26ai (oracle-base.com)

[7] DB 23ai Unified Auditing 概览 (www.oracle.com)

[8] 23ai Unified Auditing Feature and Best Practices (doyensys.com)

[9] Transparent Data Encryption Guide (docs.oracle.com)

[10] Oracle 23ai 数据库新的安全增强功能 (www.modb.pro)

[11] Hybrid-mode quantum-resistant support in Oracle AI Database 26ai (blogs.oracle.com)

[12] Securing Oracle AI Database 26ai for the Quantum Era (blogs.oracle.com)

[13] Oracle Database 23ai Security New Features (www.aioug.org)

[14] 23-Oracle 23 ai 区块链表（Blockchain Table） (blog.csdn.net)

[15] Oracle GoldenGate Release Notes (docs.oracle.com)

[16] Oracle 23c | 23ai Overview for DBAs (RelationalDBDesign)

No comments yet

Continue reading