在 Oracle Database Vault 中Realms如何工作?-之路教程

←闪回恢复区 (FRA) 中的空目录不会被删除

如何在 Oracle Database 18c 中取消 SQL 查询→

Realms属性

以下是Realms的属性：

名称：Realms的名称。
这个是用来以后参考的。
它区分大小写。
描述：Realms的描述。
状态：启用或者禁用。
如果禁用，则无效。
状态默认为启用。
审计选项：Realms的审计选项可以设置为以下值之一：

审计已禁用
失败审计（默认）
成败审计

在非统一审计环境中，Database Vault 将审计跟踪写入 DVSYS.AUDIT_TRAIL$ 表。
如果我们启用了统一审核，则此设置不会捕获审核记录。
相反，我们必须创建并启用审计策略来捕获此信息。

Realm Secured Objects：受模式保护的模式对象和角色的列表
Realm Authorizations：授权用户或者角色的列表。
这定义了哪些用户能够访问受Realms保护的对象。

使用Realms的好处

使用Realms来保护一组数据库对象或者角色免受其他特权用户的侵害。

例如，DBA 拥有广泛的权限，例如 SELECT ANY TABLE 或者 DROP ANY TABLE。这些用户可以读取或者销毁他们不一定需要访问的数据。最好将对该数据的访问限制为应用程序用户和应用程序 DBA。
可以定义一个Realms来限制访问。我们可以定义Realms，向其中添加受保护的对象，并添加允许访问Realms下对象的用户。
Realms还可以限制可以授予Realms内对象权限的用户集。例如，这将适用于对包授予 EXECUTE、对视图授予 SELECT 以及对角色授予 GRANT。
Realms还有助于满足 PCI、SOX、HIPAA 和其他需要基于需要知道的基础授予对敏感数据的访问权限的合规性要求。
强制域可用于响应网络威胁，在分析威胁之前阻止所有访问。
从 DBA 保护对象
在此示例中，SALES_DBA 用户已被设置为 Sales 应用程序的数据库管理员。相应地，该用户被分配了 DBA 角色，这意味着该角色拥有许多强大的权限，包括 DROP ANY TABLE。通常，SALES_DBA 将能够删除数据库中的任何表，包括其他模式（例如 HR）中的表。
步骤 1展示了该应用程序 DBA 如何删除属于另一个应用程序的表。

SQL> CONNECT sales_dba/password
SQL> DROP TABLE hr.bonus_it;
Table dropped.

在步骤 2 中，leo_dvowner 用户使用 Database Vault Administrator 创建Realms并保护该Realms中的所有 HR 表。
然后，在步骤 3 中，同一个 SALES_DBA 用户尝试删除同一个（现已恢复）的 HR 表，但无法删除。相反，将返回Realms冲突错误，并且 DROP TABLE 命令失败。

SQL> DROP TABLE hr.bonus_it;
ORA-47401: Realm Violation for drop table
    on HR.BONUS_IT

Realms对非成员的影响
如果用户不是Realms授权的成员，则该用户可以访问受Realms保护的对象的唯一方法是将相关对象权限授予他或者她。如果对象在域中受到保护，则用户不能依赖系统特权（例如 SELECT ANY TABLE）来访问对象。
此外，用户不能依赖他们拥有正在访问的模式这一事实。如果架构在域中受保护，并且架构所有者不是该域的成员，则架构所有者不能在他们自己的架构中删除、更改或者创建对象。为了提供这种访问，模式所有者可以被授权进入Realms。其他用户可以被授予 DV_REALM_OWNER 角色或者模式对象的直接对象级权限。授权必须由已经是Realms成员（特别是所有者）的用户完成。
保护角色
以下步骤说明了如何使用Realms保护角色：

用户创建 BENNIES 角色。

SQL> CREATE ROLE bennies;
Role created.

leo_dvowner 用户使用 Database Vault Administrator (DVA) 来保护Realms中的 BENNIES 角色。
leo_dvowner 用户使用 DVA 添加 HR 作为该Realms的参与者。
HR 用户尝试授予角色，但因违反Realms而失败。这是因为 HR 用户是Realms中的参与者，而不是所有者。

SQL> grant bennies to sh;
ORA-47401: Realm Violation for grant role privilege on NULL.NULL

leo_dvowner 用户使用 DVA 将 HR 用户更改为Realms中的所有者而不是参与者。
HR 用户现在可以授予角色。

SQL> GRANT bennies TO sh;
Grant succeeded.

HR 用户也可以撤销角色。

SQL> REVOKE bennies FROM sh;
Revoke succeeded.

强制Realms和对象权限
默认情况下，拥有或者拥有对象权限的用户可以在没有明确Realms授权的情况下访问受Realms保护的对象。但是，我们可以通过将Realms配置为强制Realms来配置Realms以防止这些用户访问对象。
在 Oracle Database 12c 中，如果我们需要阻止用户使用对象权限访问受Realms保护的对象，则可以创建强制Realms。对于这个Realms，用户只有在他们是Realms授权的成员时才能访问受Realms保护的对象。因此，被授予Realms安全对象的对象特权的用户和Realms安全对象的模式所有者需要是Realms的成员才能访问Realms安全对象。
我们还可以使用强制性Realms来应对网络威胁，在分析威胁之前阻止所有访问。
使用强制域进行保护
Realms保护 HR 模式。 HR 用户能够选择 HR 模式中受保护表的行，因为所有者始终被授予对其对象的 OBJECT 特权。由于此特权并不总是理想的情况，因此我们决定禁止 HR 用户从其自己的表中选择数据。我们可以将 HR_REALM 更新为强制性，也可以创建强制性Realms并保护敏感对象。
用例：

HR 能够选择在 HR_REALM 常规Realms中保护的 EMPLOYEES 表行。

SQL> select last_name from hr.employees;
LAST_NAME
---------
SMITH
JONES

Leo_dvownwer 使 HR_REALM Realms成为必需。
HR 无法查看 EMPLOYEES 表行。

SQL> select last_name from hr.employees;
select * from hr.employees
*
ERROR at line 1:
ORA-01031: insufficient privileges

强制域的特征

当对象受常规域和强制域保护时，将应用更安全的规则。
如果同一个对象上有多个强制域，我们必须在所有强制域上授权用户或者角色，然后用户才能访问受保护的对象。
如果角色受强制Realms保护，则除了Realms所有者之外，不能向受保护角色授予或者撤销任何特权。

在修补期间保护敏感数据

在补丁升级期间，数据库管理员可能需要直接访问受Realms保护的对象，以便对该对象执行补丁。
如果同一Realms中的表包含敏感数据，例如社会安全号码，我们可以使用强制Realms来保护这些表在补丁升级期间不被管理员访问。

当管理员打完补丁不再需要访问对象时，可以关闭强制域保护，让应用程序正常运行。
这样，即使 DBA 可以作为应用程序模式所有者登录，强制Realms也可以在修补期间提供针对 DBA 的保护。

Realms视图

包含Realms信息的视图是：

DBA_DV_REALM ：每个Realms在这里用一行表示。

NAME ：Realms的名称
描述：Realms的描述
AUDIT_OPTIONS ：一个数字，指示何时完成审计：
0：从不审计
1：失败审计
3：成功或者失败的审计
ENABLED ：Realms是否启用。该值可以是 Y 或者 N。

DBA_DV_REALM_OBJECT ：该视图包含受Realms保护的对象列表。

REALM_NAME ：Realms的名称
OWNER : Realms保护对象的所有者
OBJECT_NAME ：受保护对象的名称
OBJECT_TYPE : 受保护对象的类型

DBA_DV_REALM_AUTH ：该视图中表示Realms授权。

REALM_NAME ：Realms的名称
GRANTEE ：被授权访问受Realms保护的对象的用户或者角色
AUTH_RULE_SET_NAME ：规则集必须评估为 TRUE 以便被授权者访问受Realms保护的对象
AUTH_OPTIONS ：指示被授予者是否能够授予在此Realms中受保护的任何角色：
参与者：无法授予
所有者 : 能够授予

DVSYS.DV$REALM 视图描述了用于创建Database Vault Realms的设置，例如已分配了哪些审核选项、该Realms是否为强制Realms等。

预定义报告

Realms审计报告审计：Realms保护和Realms授权操作生成的记录。这有助于对规则集进行故障排除和监控失败的授权尝试。Realms违规也显示在此报告中。此报告将显示数据库帐户何时尝试对未授权执行该操作的Realms对象执行操作。配置Realms时，我们可以为Realms操作设置审核选项。
Realms授权配置：列出授权配置信息，例如不完整或者禁用的规则集，或者可能影响Realms的不存在的被授予者或者所有者。
规则集配置问题报告：列出没有定义或者启用规则的规则集，这可能会影响使用它们的Realms。
对象权限报告：列出Realms影响的对象权限。
权限管理 - 摘要报告：提供有关Realms的受赠者和所有者的信息。
敏感对象报告：列出命令规则影响的对象。

在运行时保护敏感数据

在运行时，应用程序数据存储在许多不同模式的表中。
建议我们使用单用户应用程序（例如运行时架构）来访问这些表，以便维护数据的完整性和准确性。
当应用程序数据分散在许多不同的模式中时，模式所有者以及具有对象权限的用户如果直接登录数据库也可以更改数据。

要确保没有用户可以在不运行运行时模式过程的情况下更新表，请使用Realms来保护表。
这样，只有授权用户的程序才能访问它们。
由于常规Realms不会阻止对象所有者和对象特权用户，因此请使用强制Realms来阻止他们，如幻灯片中的步骤 1 和 2.
只有授权用户才能访问这些表。

欢迎来到之路教程(on itroad-com)

涉及Realms的任务

我们必须在添加对象之前创建Realms。
这可以在不同的工具中完成。
全部使用 DVSYS 模式中 DBMS_MACADM 包的 CREATE_REALM 过程。
编辑Realms使我们能够更改为Realms定义的任何内容。
这也是保护Realms（RENAME_REALM、UPDATE_REALM）下对象的方法。
创建Realms保护的对象时，我们将对象置于Realms的保护之下。
我们指定要添加的一个或者多个对象的所有者。
属于不同用户、不同类型的对象可以在同一Realms下。
我们可以对所有对象类型或者特定类型（例如 TABLE 或者 CLUSTER）使用“%”。
同样，我们可以使用“%”作为对象名称（ADD_OBJECT_TO_REALM、DELETE_OBJECT_FROM_REALM）。
要向Realms添加授权，请定义被授权者（被授权的用户或者角色名称）和类型：参与者或者所有者（相当于 WITH ADMIN 选项）（ADD_AUTH_TO_REALM、UPDATE_REALM_AUTH、DELETE_AUTH_FROM_REALM）。
向Realms添加授权时，还可以指定授权规则集。
必须满足此规则集才能允许访问受Realms保护的对象。
Database Vault 删除Realms的配置，包括Realms授权。
它不会删除用于Realms授权的规则集（DELETE_REALM、DELETE_REALM_CASCADE）。

在 Oracle Database Vault 中Realms如何工作?

当 SQL 语句由 Database Vault 处理时，会检查它是否存在Realms冲突。
步骤如下：

SQL 语句是否影响由Realms保护的对象？
如果是，则转至步骤 2.
如果否，则Realms不影响 SQL 语句。
转到步骤 7.
该Realms是强制性Realms吗？
如果是，则转至步骤4.
如果是常规Realms，则转至步骤3.
数据库账号是否使用系统权限执行SQL语句？
如果是，则转至步骤 4.
如果否，则转至步骤 6.
如果会话仅对 SELECT、EXECUTE 和 DML 语句具有相关对象的对象特权，则不会强制实施Realms保护。
Realms防止对受Realms保护的对象或者角色使用任何系统特权。
请记住，如果 O7_DICTIONARY_ACCESSIBILITY 初始化参数已设置为 TRUE，则非 SYS 用户可以访问 SYS 架构对象。
为了提高安全性，请确保将 O7_DICTIONARY_ACCESSIBILITY 设置为 FALSE 。
数据库帐户是Realms所有者还是Realms参与者？
如果是，则转到步骤5.
否则，会发生Realms冲突，并且不允许该语句成功。
如果命令是受Realms保护的角色的 GRANT 或者 REVOKE，或者是受Realms保护的对象的对象特权的 GRANT 或者 REVOKE，则会话必须直接或者通过角色间接授权为Realms所有者.
数据库账户的realm授权是否有条件地基于规则集？
如果是，则转至步骤 6.
如果否，则转至步骤 7.
规则集是否评估为 TRUE？
如果是，则转至步骤7.
如果否，则存在Realms冲突，SQL 语句不允许成功。
命令规则是否阻止命令执行？
如果是，则存在命令规则违规且 SQL 语句失败。
如果否，则不存在违反Realms或者命令规则且命令成功。

强制域的好处

下面列出了强制性Realms的好处：

可以阻止对象所有者和对象特权用户。
为访问控制提供更灵活的配置。
在补丁升级期间添加一层保护。
在运行时保护表。
通过防止更改已配置的角色来允许冻结安全设置。
甚至为通过应用程序帐户的连接添加另外的多因素授权检查。

Oracle 定义的Realms

默认Realms已启用并在失败时进行审核。

Oracle Database Vault：保护 Database Vault DVSYS、DVF 和 LBACSYS 模式中的配置和角色信息。
Database Vault 帐户管理：为管理和创建数据库帐户和数据库配置文件的管理员定义Realms。此Realms保护 DV_ACCTMGR 和 CONNECT 角色。此Realms的所有者可以授予或者撤销用户的 CREATE SESSION 权限。
Oracle Enterprise Manager ：保护用于监视和管理的 Oracle Enterprise Manager 帐户（DBSNMP 用户和 OEM_MONITOR 角色）。
Oracle 默认模式保护Realms：保护与 Oracle 特性（例如 Oracle OLAP、Oracle Spatial 和 Oracle Text）一起使用的角色和模式。
Oracle 系统权限和角色管理Realms：保护所有用于从 Oracle 数据库导出和导入数据的敏感角色。此Realms还包含必须授予系统特权的用户的授权。用户 SYS 是此Realms的唯一默认所有者。只有此Realms的所有者才能将受保护的角色授予其他用户。
Oracle 默认组件保护Realms：保护 SYSTEM 和 OUTLN 模式。该Realms的授权用户是用户 SYS 和 SYSTEM。

日期：2020-09-17 00:11:20 来源：oir作者：oir

←闪回恢复区 (FRA) 中的空目录不会被删除

如何在 Oracle Database 18c 中取消 SQL 查询→