Oracle Deep Data Security (Deep Sec) 初体验

关于数据安全，之前介绍过的 Oracle RAS 虽然强大，但规则定义还是太复杂，如今 Oracle 推出的 Deep Data Security (Deep Sec) 重新定义了AI智能体时代的数据安全玩法，不但继承了RAS的核心功能，而且其提供的直接使用声明式SQL来配置的方法，也让AI时代的数据安全从此变得既简单又可控。

01 | 前提条件：Oracle AI Database 需升级到23.26.2

因为 Deep Sec 是在 23.26.2 引入的新功能，所以软件版本要求 Oracle AI Database (23.26.2 or later)，目前这个RU已经可以在MOS下载到了。

笔者目前的测试环境还是23.26.1，所以需要下载应用这个补丁：

• Patch 39093711: DATABASE RELEASE UPDATE 23.26.2.0.0

注意：readme中建议用于应用补丁的opatch建议在12.2.0.1.49或以上，执行下面命令查询opatch版本，如果你的opatch版本也不符合要求，可以通过搜索 6880880 下载最新的opatch版本。

$ $ORACLE_HOME/OPatch/opatch version

笔者的opatch版本不满足需求，所以选择下载最新的opatch版本：

OPatch比较小，下载后的文件名为：

• p6880880_230000_Linux-x86-64.zip

然后我们更新opatch，再用新的opatch应用23.26.2的补丁，直接按照readme操作即可。考虑到如今AI时代下，数据库的使用者自身未必都有DBA经验，也未必能找到DBA帮忙，且这种基础环境的操作还是不太建议全权交给AI（因为不同版本补丁是可能有细微差异的，AI可能出错），最终需要真人来确认复核比较稳妥，所以这里列下笔者操作的关键命令参考，完整细节还是参考readme仔细核对：

首先，备份之前的OPatch，解压新的OPatch，确认已成功替换新的opatch版本，操作如下：

[oracle@alfred-aibs-db ~]$ cd $ORACLE_HOME
[oracle@alfred-aibs-db dbhome_1]$ mv OPatch OPatch_bak
[oracle@alfred-aibs-db dbhome_1]$ unzip /u01/media/p6880880_230000_Linux-x86-64.zip 
[oracle@alfred-aibs-db dbhome_1]$ $ORACLE_HOME/OPatch/opatch version
OPatch Version: 12.2.0.1.51

OPatch succeeded.

确认opatch版本已经是目前最新的 OPatch Version: 12.2.0.1.51。

然后使用这个opatch来应用补丁，按照补丁包中的readme说明操作即可，有些参数readme可能忘记标明了，手工根据实际情况，补上即可，笔者环境执行相关命令如下：

unzip p39093711_230000_Linux-x86-64.zip
cd 39093711
$ORACLE_HOME/OPatch/opatch prereq CheckMinimumOPatchVersion -ph /u01/media/39093711
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /u01/media/39093711

确认这些预检查都正常验证通过：

笔者这里单实例，需要停止数据库和监听：

If this is not an Oracle RAC environment, shut down all instances and listeners associated with the Oracle home that you are updating. For more information, see Oracle AI Database Administrator's Guide.

[oracle@alfred-aibs-db 39093711]$ lsnrctl stop
[oracle@alfred-aibs-db 39093711]$ sqlplus / as sysdba
SQL> shutdown immediate;

确认正常关闭后，然后应用补丁：

$ cd /u01/media/39093711
$ $ORACLE_HOME/OPatch/opatch apply

碰到交互式确认的地方，选择y即可，基本都是问你是否确认执行，是否已关闭数据库并准备好打补丁了。

耐心等个几分钟，补丁就应用好了：

下一步继续按readme执行，启库，执行datapatch，这一过程又需要再等几分钟：

[oracle@alfred-aibs-db 39093711]$ sqlplus / as sysdba
SQL> startup
SQL> alter pluggable database all open;
SQL> quit
[oracle@alfred-aibs-db OPatch]$ ./datapatch -sanity_checks
[oracle@alfred-aibs-db OPatch]$ ./datapatch -verbose

执行完成后检查日志有无报错，可以跑下utlrp这个重新编译无效对象：

[oracle@alfred-aibs-db OPatch]$ export PATH=$PATH:$ORACLE_HOME/bin
[oracle@alfred-aibs-db OPatch]$ cd $ORACLE_HOME/rdbms/admin
[oracle@alfred-aibs-db admin]$ $ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -e -b utlrp -d $ORACLE_HOME/rdbms/admin utlrp.sql

确认已升级成功23.26.2：

最后启动下监听，恢复对外服务。

[oracle@alfred-aibs-db admin]$ lsnrctl start

02 | 测试验证Deep Sec的功能效果

本文测试验证当没有IAM集成的场景下，如何利用 Local End User 配置 Deep Sec 的功能，并验证效果：

参考官方文档link：

• https://docs.oracle.com/en/database/oracle/oracle-database/26/ddscg/configure-oracle-deep-data-security-direct-logon-local-end-users.html

① 构造最小示例数据

-- 笔者本次测试用到的PDB：orclpdb1
ALTER SESSION SET CONTAINER = orclpdb1;

-- Create the HR user
-- 注：这里是创建一个"没有密码、无法直接登录"的模式（Schema）用户 HR
CREATE USER hr NO AUTHENTICATION
  DEFAULT TABLESPACE users
  QUOTA UNLIMITED ON users;
 
-- Create the employees table
CREATE TABLE hr.employees (
    employee_id   NUMBER PRIMARY KEY,
    first_name    VARCHAR2(50),
    last_name     VARCHAR2(50),
    email         VARCHAR2(128),
    manager       VARCHAR2(128),
    ssn           VARCHAR2(20),
    salary        NUMBER(10,2),
    phone         VARCHAR2(20)
);

-- 插入示例数据
INSERT INTO hr.employees VALUES
  (100, 'Victoria', 'Williams', 'vwilliams',
   NULL, '219-09-9999', 13000, '555-0100');
 
INSERT INTO hr.employees VALUES
  (200, 'Marvin', 'Anderson', 'manderson',
   'vwilliams', '457-55-5462', 12030, '555-0200');
 
INSERT INTO hr.employees VALUES
  (300, 'Chris', 'Evans', 'cevans',
   'vwilliams', '321-12-4567', 6900, '555-0300');
 
INSERT INTO hr.employees VALUES
  (400, 'Emma', 'Baker', 'ebaker',
   'manderson', '733-02-9821', 8200, '555-0400');
 
INSERT INTO hr.employees VALUES
  (500, 'Taylor', 'Mills', 'tmills',
   'manderson', '558-76-1243', 9000, '555-0500');
 
COMMIT;

示例数据准备好是这样，全表只有5行数据，以方便读者更直观的看到演示效果：

② 创建Local End Users

注意这里的 End User 不是传统意义上的数据库用户。

CREATE END USER "manderson" IDENTIFIED BY "Test_20260513";
CREATE END USER "ebaker" IDENTIFIED BY "Test_20260513";

虽然上面的SQL是在数据库中执行，但其本质区别是这种 End User 用户并没有自己的schema，没有任何的数据库对象实体。只是用于细粒度数据访问：

They receive fine-grained data access through data grants assigned to their data roles.

当一个 End User 登录到数据库，

ORA_END_USER_CONTEXT.username returns their user name.

The data grants in this chapter use predicates that compare this value against the email and manager columns of the hr.employees table. For the predicates to match, the local end-user names you create must match the values stored in those columns.

③ 配置Data Roles

注意这里创建的 Data Role 目前只赋予了连接会话的权限：

-- Create data roles that are managed locally in the database
CREATE DATA ROLE employee_role;
CREATE DATA ROLE manager_role;
 
-- Create a standard database role for connection privileges
CREATE ROLE db_role;
GRANT CREATE SESSION TO db_role;
 
-- Grant the connection privileges to the data role used for direct logon
GRANT db_role TO employee_role;
GRANT db_role TO manager_role;

将上面创建好的 Data Role 再赋给对应的终端用户：

终端用户 manderson 拥有两个 Data Role；

终端用户 ebaker 拥有一个 Data Role；

-- Grant data roles to Marvin (manager and employee)
GRANT DATA ROLE manager_role TO "manderson";
GRANT DATA ROLE employee_role TO "manderson";
 
-- Grant the employee data role to Emma
GRANT DATA ROLE employee_role TO "ebaker";

④ 配置Data Access Control

这个是重头戏，关于数据访问授权的详细规则具体如何设定全都在这部分，之前的RAS就是各种调用复杂的内部定义，如今在 Deep Sec 中只需要声明式的SQL即可实现，具体定义的内容也容易让人理解。

Define data grants to control which rows and columns each end user can access. In data grant predicates, ORA_END_USER_CONTEXT.username returns the end user's name from the current end-user security context.

创建一个数据授权（Data Grant），允许员工仅查看他们自己的记录。

CREATE DATA GRANT hr.employees_own_record
  AS SELECT
  ON hr.employees
  WHERE email = ORA_END_USER_CONTEXT.username
  TO employee_role;

创建一个数据授权，允许经理查看其直系下属的记录（但不包括 SSN 字段）。

CREATE DATA GRANT hr.manager_direct_reports
  AS SELECT (ALL COLUMNS EXCEPT ssn)
  ON hr.employees
  WHERE manager = ORA_END_USER_CONTEXT.username
  TO manager_role;

⑤ 测试验证Deep Sec的效果

分别使用不同的 END USER 登录，验证Deep Sec实现的细粒度数据访问效果。

我们主要关注，不同 END USER 登录，ORA_END_USER_CONTEXT.username 值的变化，以及同样查询 hr.employees 的记录差异：

相同的测试SQL如下，方便直接拷贝：

SELECT ORA_END_USER_CONTEXT.username FROM dual;

SET LINESIZE 120
SET TRIMSPOOL ON
SET PAGESIZE 50

COL FIRST_NAME FORMAT A10
COL LAST_NAME  FORMAT A10
COL EMAIL      FORMAT A20
COL MANAGER    FORMAT A15
COL SSN        FORMAT A11
COL SALARY     FORMAT 99999.9
COL PHONE      FORMAT A12

SELECT * FROM hr.employees;

场景1：使用 manderson 终端用户登录测试：

sqlplus '"manderson"'/Test_20260513@//localhost:1521/ORCLPDB1

从场景1的结果可以看到， manderson 终端用户登录进来后，ORA_END_USER_CONTEXT.username 值是 manderson，查询员工表，能看到自己的记录，同时能看到所有下属的记录，但无法看到下属的SSN字段值。

场景2：使用 ebaker 终端用户登录测试：

sqlplus '"ebaker"'/Test_20260513@//localhost:1521/ORCLPDB1

从场景2的结果可以看到， ebaker 终端用户登录进来后，ORA_END_USER_CONTEXT.username 值是 ebaker，查询员工表，只能看到自己的记录。

符合我们之前的定义规则。

03 | 快速部署Deep Sec的方法

上面为了让用户能看清楚每一步都做了什么，是分步骤演示执行的。

如果用户已经了解Deep Sec的机制，想快速通过集成SQL脚本，一键部署或清理测试环境，官方也有提供示例脚本，可以直接使用或者根据自己实际情况修改。

A.1 Scripts for Direct Logon with Local End Users

• https://docs.oracle.com/en/database/oracle/oracle-database/26/ddscg/scripts-direct-logon-local-end-users.html#GUID-0FDC326F-98B0-4443-8E1A-8CB1F3BC8B03

至此，Oracle Deep Data Security (Deep Sec) 初体验已完成，后续有时间再具体看下如何将 Deep Sec 和 AI应用结合起来使用。