|
鉴于 Oracle 数据库不包含适用于 DDL 的原生锁定机制，您将如何实施该过程？
方法之一是撤消模式拥有者的 create session 系统特权，使其始终无法登录以进行更改。取而代之的是，由有权更改指定模式的对象的应用程序拥有者进行更改。这是一个非常不错的关键数据库对象保护方法，具体体现在它支持为对象更改创建审计跟踪，而其中的跟踪可以追溯到实际用户，而非一般的模式名称。
例如，假设模式为 BANK，表名称为 ACCOUNTS。通过撤消 BANK 的 create session 权限可以禁止其登录数据库。取而代之的是，您允许拥有 create session 权限的 SCOTT 修改 ACCOUNTS。Oracle 用户 SCOTT 实际上由真人用户 Scott 拥有，任何其他人都无法访问此用户 ID。SCOTT 对 ACCOUNTS 所做的任何更改都可以直接归因于用户 Scott，从而使职责性成为安全基础架构可行性的主要组成部分。
通常情况下，要使用该方法锁定程序，您应当撤消 SCOTT 的权限。当需要更改程序时，您可以再次赋予该权限（即允许 SCOTT 更改程序），然后再次撤消该授权。
可以肯定的是，这并不是一个处理安全性的巧妙方法。很快您就会遇到问题 - 权限管理并不像“每个对象一个用户”那样简单。在典型的数据库基础架构中，数以百计的用户将获得数以千计的对象的多种类型的权限。撤消权限将消除复杂的依赖关系并带来令人头痛的管理问题。
一个可管理性更高的解决方案是使用 DDL 触发器。使用此方法，您可以根据需要建立授权，但通过 DDL 触发器控制更改。
例如，假设您想要保护模式 ARUP 中一个名为 SECURE_PKG 的程序包。您将创建一个 DDL 模式触发器，如下所示： 1 create or replace trigger no_pkg_alter
2 before ddl
3 on arup.schema
4 begin
5 if (
6 ora_dict_obj_name = 'SECURE_PKG'
7 and
8 ora_sysevent = 'CREATE'
9 )
10 then
11 raise_application_error (-20001,'Can''t Alter SECURE_PKG');
12 end if;
13 end;
14 /
在第 6 行和第 8 行中，您检查是否对该程序包进行了更改。注意，对程序包的更改是由 create or replace package 语句做出的；因此，检查的事件是 create。如果您要确保表不受更改，可以在该值中使用 alter。在第 11 行中，当程序包被更改时将产生错误。
设置该触发器后，当拥有权限的用户尝试更改此程序包，甚至当对象的拥有者 (ARUP) 尝试通过运行程序包创建脚本重新创建该程序包时： create or replace package secure_pkg
他将收到错误： ERROR at line 1:
ORA-00604:error occurred at recursive SQL level 1
ORA-20001:Can't Alter SECURE_PKG
ORA-06512:at line 8
如果您确实要修改此程序包，可以请求 DBA 通过禁用触发器对它解锁： alter trigger no_pkg_alter disable
/
现在，程序包创建脚本将开始运行。完成运行后，请求 DBA 启用触发器以将其锁定。基础权限保持不变。即便当您允许模式拥有者登录并修改他们所拥有的对象时，该方法也会保护这些对象。此策略支持对更改管理采用一种二人方法。
可能的影响
无，只要每个人都知道当对象准备更改时，DBA 必须解除对象锁定即可。如果您在正式的更改控制过程中加入了此步骤，它将以最主动的方式对可靠性产生影响。
操作计划
- 为所有应锁定的对象创建一个列表。注意，并非所有对象都需要进行如此严格的控制，例如，应用程序所有者为保存中间值而创建的临时表就不需要。
- 根据列表中的所有这些对象名称创建触发器。使该触发器在初始状态下处于禁用状态。不要将此功能添加到现有触发器中。您应该能够独立控制此触发器。
- 标识应解除对象的用户。该用户也许是您。
- 记录应何时锁定和解除锁定对象、工作流等。
- 启用该触发器。
(编辑:aniston)
|
