2. Oracle安全架构与权限模型

Oracle的安全体系并不是“一个用户对应一个数据库”这么简单。要真正理解权限治理，必须先厘清几个容易混淆的概念：实例（Instance）是内存结构（SGA）与后台进程的集合，负责运算与资源调度；数据库（Database）是磁盘上的物理文件集合，包括数据文件、控制文件、重做日志等；而Schema是数据库内部的一组逻辑对象（表、视图、索引、存储过程等）的命名容器。一个实例可以挂载并打开一个数据库，用户通过实例连接后，实际访问的是数据库中的对象。

关键点在于：用户（User）与Schema并不是同一个东西。在Oracle中，创建用户时会自动创建一个同名Schema，用户是“登录身份”，Schema是“对象归属”。例如执行 CREATE USER app_user IDENTIFIED BY "App#2024" DEFAULT TABLESPACE app_data QUOTA 200M ON app_data; 后，系统会创建用户 APP_USER 及其同名Schema。此后 app_user 创建的表默认落在 APP_USER Schema下，其他用户要访问就必须带Schema前缀，如 APP_USER.ORDERS，或通过同义词（Synonym）简化。

权限分为两大类。系统权限（System Privilege）作用于数据库层面，例如 CREATE SESSION（允许连接）、CREATE TABLE、CREATE ANY TABLE、SELECT ANY TABLE、DROP ANY TABLE 等。其中带 ANY 的权限范围极大，能跨Schema操作，是权限治理中的高风险项。对象权限（Object Privilege）作用于具体对象，例如对 APP_USER.ORDERS 表的 SELECT、INSERT、UPDATE、DELETE，或对存储过程的 EXECUTE。对象权限必须明确指定对象，粒度更细，也更符合最小权限原则。

当用户和权限数量增多时，逐个授权会变得难以维护，于是引入角色（Role）。角色是一组权限的命名集合，可以包含系统权限、对象权限，甚至其他角色。典型做法是：先创建角色 role_readonly，授予 CREATE SESSION 和对若干表的 SELECT，再把该角色授予业务用户。这样权限变更只需调整角色，无需逐个用户修改。Oracle预置了 CONNECT、RESOURCE、DBA 等角色，但生产环境通常建议自定义最小权限角色，而不是直接授予 DBA。

权限的传递与继承是治理中最容易失控的环节。系统权限可以通过 WITH ADMIN OPTION 授予，使被授权者能把该权限再授予他人；对象权限则通过 WITH GRANT OPTION 实现再授权。例如：

-- 系统权限传递：app_admin 可将 CREATE TABLE 再授给他人
GRANT CREATE TABLE TO app_admin WITH ADMIN OPTION;

-- 对象权限传递：允许 app_user 把 ORDERS 的 SELECT 再授出
GRANT SELECT ON app_user.orders TO report_user WITH GRANT OPTION;

-- 角色授予用户
GRANT role_readonly TO app_user;

-- 查看当前用户被授予的系统权限
SELECT privilege FROM user_sys_privs;

-- 查看当前用户拥有的角色
SELECT granted_role, admin_option FROM user_role_privs;

-- 查看对象权限授予情况
SELECT grantee, privilege, grantable
FROM user_tab_privs
WHERE table_name = 'ORDERS';

这里有一个重要区别：系统权限的传递不会因中间用户被删除而级联回收，而对象权限的 WITH GRANT OPTION 在授权链断裂时可能被级联撤销。因此，生产环境应严格限制 WITH ADMIN OPTION 和 WITH GRANT OPTION 的使用，并定期审计 DBA_SYS_PRIVS、DBA_TAB_PRIVS、DBA_ROLE_PRIVS 等视图。

角色还涉及默认角色与非默认角色。用户被授予角色后，默认情况下登录即生效；若设置为非默认角色，则需要 SET ROLE 显式启用。这为“平时最小权限、必要时提权”提供了机制。例如：

-- 将角色设为非默认，登录后不自动生效
ALTER USER app_user DEFAULT ROLE role_readonly;

-- 会话中临时启用高权限角色
SET ROLE role_dml;

-- 查看当前会话已启用角色
SELECT role FROM session_roles;

综合来看，Oracle权限模型可以概括为一条清晰的链路：实例承载会话 → 数据库存储对象 → Schema组织对象 → 用户以身份登录 → 角色聚合权限 → 系统权限管全局、对象权限管具体 → 传递与继承决定权限扩散范围。理解这条链路，才能在后续的权限回收、最小权限设计和审计中做出正确判断。实际治理中，建议遵循三条原则：第一，业务用户只授予必要的对象权限，避免 SELECT ANY TABLE 这类宽泛系统权限；第二，用自定义角色替代直接授权，便于批量调整；第三，对 WITH ADMIN OPTION 和 WITH GRANT OPTION 建立审批与定期复核机制，防止权限在不知情的情况下扩散。