from dba_source where upper(text) like '%PASSWORD%' or upper(text) like '%ENC%' or upper(text) like '%DEC%' or upper(text) like '%SECRET%' or upper(text) like '%PASS%' /
这可能会提供一些线索来帮助您标识可能要检查的代码段。 标识所有此类代码后,应使用 wrap 实用程序包装它并运行包装代码。 可能的影响 不存在任何可能的影响。 但您应该知道一个非常重要的问题: 包装是单项进行的;您可以包装明文代码,但不能从包装代码中创建明文。 因此,应将明文代码保存在某个安全的位置以便进一步编辑。 如果丢失明文代码,则将永远无法更改代码。
操作计划
标识包含机密数据的代码。 如果在 Oracle9i 中,则 |
|
将值分解为多个部分并将每个部分嵌套在短语中。 创建一个变量以提取短语中的各个部分。 重新构造代码中的值。 |
否则 |
|
不执行任何操作。 |
ENDIF 从明文中创建脚本文件。 包装脚本。 运行包装脚本。 |
2.7 将派生授权转换为直接授权
背景 授予权限时,可以选择使用 with grant option 子句,以便被授权者可以进一步授予权限。 以下是一个有关授予用户 A 拥有的表 TAB1 的权限的示例。 Step1
Connect A/******
Grant select on tab1 to B;
Step 2
Connect B/******
Grant select on a.tab1 to C;
用户收到错误 ORA-01031:insufficient privileges
原因是用户 B 无权授予它本身从某个用户那里收到的权限。 但在第 1 步中,如果语句为 Grant select on tab1 to b with grant option;
则用户 B 将有权进一步授予该权限,且第 2 步将成功。
同样,B 也可以使用 grant option 将该权限授予 C,而 C 随后可以将该权限授予 D,依此类推。
表面看来它似乎是一个不错的规划。 最初所有者 A 不必担心向哪个用户授予或撤销权限;该过程是按需进行自我管理的。 那么,问题是什么呢?
来看看以下情形: Connect A/*****
Revoke select on tab1 from B.
注意,C 从 B 那里获得它对 TAB1 的权限,而并非从 A 那里直接获得;因此,如果 B 丢失了这些权限,那么 C 的权限将如何? C 也将丢失它的权限,这是因为该权限是一个派生的权限。
我们进一步假设 A 已经向 C 直接授予了对 TAB1 的 select 权限。 C 现在对 TAB1 有两个权限,一个来自 B,一个来自 A。当您撤销某个权限时,另一个权限仍然有效,从而使您错误地认为该权限不存在。
尽管该过程表面看来很不错,但实际上缺产生混淆和安全漏洞,并带来难于跟踪的错误。 一种更有意义的做法是在无中间方的情况下直接授予权限。
策略 您的目标是标识哪些权限是通过其他用户授予的,然后直接授予权限。 可以从视图 DBA_TAB_PRIVS 中清楚地看到这些权限,其中的列 grantor 显示了授予权限的用户。 SQL> col grantee format a15
SQL> col privilege format a15
SQL> col owner format a20
SQL> col table_name format a20
SQL> select grantee, privilege, owner, table_name
2 from dba_tab_privs
3* where grantor != owner
4 /
下面显示了一个简单的输出。 PUBLIC EXECUTE XDB.DBMS_XMLSCHEMA SYS
PUBLIC EXECUTE XDB.XDB_PRIVILEGES SYS
PUBLIC EXECUTE XDB.DBMS_XMLSCHEMA_INT SYS
APP1 SELECT ANANDA.MP RUSER
前三行可以忽略,在这三行中授权是由用户 SYS 向角色 PUBLIC 发出的。 该权限是模式 XDB 拥有的程序包 DBMS_XMLSCHEMA 的权限。 作为由 Oracle 提供的特殊程序包,这样做是允许的;但应注意第四行。 由 ANANDA 拥有的表 MP 是由 RUSER 授予的,因此应对其进行更正。 修复方法其实很简单: 将该对象的 select 直接授予 APP1,即使 RUSER 拥有 with grant option 权限。
执行该操作有两种方法:
- 对象拥有者直接授予该权限。
- SYS 这样的超级用户授予该权限。
第二种方法更易于实施。 SYS 用户实际上并不继承授权;它通过使用系统权限 grant any object privilege 授予权限。 当 SYS 使用以下代码授予权限时: grant select on a.tab1 to c;
GRANTOR 列将显示 A 而不是 SYS;这正是您所需要的。 set lines 300
set pages 0
spool grant_direct.sql
select 'grant '||privilege||' on '||owner||
'.'||table_name||' to '||grantee||';'
from dba_tab_privs
where grantor != owner
/
spool off
现在,运行文件 grant_direct.sql 以直接授予权限。
成功授予权限后,必须撤销间接授予的权限。 该操作无法在单个语句中实现,原因是您还必须以授权者的身份连接。 break on conn skip 2
select 'connect '||grantor conn,
'revoke '||privilege||' on '||owner||
'.'||table_name||' from '||grantee||';' line
from dba_tab_privs
where GRANTOR != 'SYS'
and grantor != owner
order by 1,2
/
将该脚本假脱机到某个文件,编辑该脚本以为每个用户提供口令,然后执行它以撤销授权。 可能的影响 有两个可能的影响。 首先,由于您要撤销权限并重新授予它们,因此可能由于无法重新授予权限而引起错误。 因此,必须在此更改的前后获得权限快照以确保成功。 使用以下脚本查找权限: SQL> select grantee, privilege, owner, table_name
2 from dba_tab_privs
3* where grantor != owner
4 /
在更改的前后运行该脚本,保存输出,然后比较它们以确保权限保持原样。
第二个可能的影响更明显。 授予和撤销周期将使这些对象的游标在库缓存中无效并将迫使对游标进行重新分析,从而将临时降低性能。
此外,某些相关对象将失效。 由于再次授予了权限,因此对象在被引用时将正常编译,但您可能需要采取某个主动式操作并事先重新编译它们。 操作计划
- 查找由其他用户使用 grantable 选项授予的权限。
- 撤销权限。
- 在不使用 grant 选项的情况下重新授予权限。
- 检查无效对象并重新编译它们。
(编辑:aniston)
|