Oracle安全全接触（下）
2009-11-27 21:43
288 查看
·向密码文件中增加、删除用户:
当初始化参数REMOTE_LOGIN_PASSWORDFILE设置为EXCLUSIVE时，系统允许除INTERNAL/SYS以外的其他用户以管理员身份从远端或本机登录到Oracle数据库系统，执行数据库管理工作;这些用户名必须存在于密码文件中，系统才能识别他们。由于不管是在创建数据库实例时自动创建的密码文件，还是使用工具ORAPWD.EXE手工创建的密码文件，都只包含INTERNAL/SYS用户的信息;为此，在实际操作中，可能需要向密码文件添加或删除其他用户帐号。
由于仅被授予SYSOPER/SYSDBA系统权限的用户才存在于密码文件中，所以当向某一用户授予或收回SYSOPER/SYSDBA系统权限时，他们的帐号也将相应地被加入到密码文件或从密码文件中删除。由此，向密码文件中增加或删除某一用户，实际上也就是对某一用户授予或收回SYSOPER/SYSDBA系统权限。
要进行此项授权操作，需使用SYSDBA权限(或INTERNAL帐号)连入数据库，且初始化参数REMOTE_LOGIN_PASSWORDFILE的设置必须为EXCLUSIVE。具体操作步骤如下:
创建相应的密码文件;
设置初始化参数REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE;
使用SYSDBA权限登录: CONNECT SYS/internal_user_passsword AS SYSDBA;
启动数据库实例并打开数据库;
创建相应用户帐号，对其授权(包括SYSOPER和SYSDBA): 授予权限:GRANT SYSDBA TO user_name;
收回权限:REVOKE SYSDBA FROM user_name;
现在这些用户可以以管理员身份登录数据库系统了;
·使用密码文件登录:
有了密码文件后，用户就可以使用密码文件以SYSOPER/SYSDBA权限登录Oracle数据库实例了，注意初始化参数REMOTE_LOGIN_PASSWORDFILE应设置为EXCLUSIVE或SHARED。任何用户以SYSOPER/SYSDBA的权限登录后，将位于SYS用户的Schema之下，以下为两个登录的例子:
1. 以管理员身份登录:
假设用户scott已被授予SYSDBA权限，则他可以使用以下命令登录:
CONNECT scott/tiger AS SYSDBA
2. 以INTERNAL身份登录:
CONNECT INTERNAL/INTERNAL_PASSWORD
·密码文件的维护:
1. 查看密码文件中的成员:
可以通过查询视图V$PWFILE_USERS来获取拥有SYSOPER/SYSDBA系统权限的用户的信息，表中SYSOPER/SYSDBA列的取值TRUE/FALSE表示此用户是否拥有相应的权限。这些用户也就是相应地存在于密码文件中的成员。
2. 扩展密码文件的用户数量:
当向密码文件添加的帐号数目超过创建密码文件时所定的限制(即ORAPWD.EXE工具的MAX_USERS参数)时，为扩展密码文件的用户数限制，需重建密码文件，具体步骤如下:
a) 查询视图V$PWFILE_USERS，记录下拥有SYSOPER/SYSDBA系统权限的用户信息;
关闭数据库;
c) 删除密码文件;
d) 用ORAPWD.EXE新建一密码文件;
e) 将步骤a中获取的用户添加到密码文件中。
3. 修改密码文件的状态:
密码文件的状态信息存放于此文件中，当它被创建时，它的缺省状态为SHARED。可以通过改变初始化参数REMOTE_LOGIN_PASSWORDFILE的设置改变密码文件的状态。当启动数据库事例时，Oracle系统从初始化参数文件中读取REMOTE_LOGIN_PASSWORDFILE参数的设置;当加载数据库时，系统将此参数与口令文件的状态进行比较，如果不同，则更新密码文件的状态。若计划允许从多台客户机上启动数据库实例，由于各客户机上必须有初始化参数文件，所以应确保各客户机上的初始化参数文件的一致性，以避免意外地改变了密码文件的状态，造成数据库登陆的失败。
4. 修改密码文件的存储位置:
密码文件的存放位置可以根据需要进行移动，但作此修改后，应相应修改系统注册库有关指向密码文件存放位置的参数或环境变量的设置。
5. 删除密码文件:
在删除密码文件前,应确保当前运行的各数据库实例的初始化参数REMOTE_LOGIN_PASSWORDFILE皆设置为NONE。在删除密码文件后，若想要以管理员身份连入数据库的话，则必须使用操作系统验证的方法进行登录。
但是管理员都觉得乏味，因为在管理员中流行一种很简单的加密办法--就是经常，很频繁地修改自己的密码。可是，每次修改都跟打一次仗似的--因为更新程序并不是每个人都愿意做的事情。
那么有没有什么简单点的办法呢?请往下看:
模型:Oracle7.3;开发工具evelope2000。收费系统(在数据库中的名称是SFYY)，其Client端分散在市区的数个营业点，通过城域网与主机(小型 机)相连。
过程:
·在收费小型机Oracle系统的system用户(DBA)下，创建新用户test;
create user test
identified by carton
default tablespace dataspace1
quota 100K
·对test用户授以权限;
grant create session to test;
grant resource to test;
·在test用户下建立一个存储函数mmtranslate,它其实是一个加密程序。下面是一个简 单的例子。
function mmtranslate(m varchar2)
return varchar2
as
i number(2);
kk varchar2(10);
begin
kk:=′′;
i:=1;
loop
if i
if instr(′1234567890′,substr(m,i,1),1,1)>0 then
kk:=kk||chr(100+to_number(substr(m,i,1)));
elseif instr(‘wxyz‘,substr(m,i,1),1,1)>0 then
kk:=kk||chr(-8+ascii(substr(m,i,1)));
else
kk:=kk||chr(4+ascii(substr(m,i,1)));
end if;
else
exit;
end if;
i:=i+1;
end loop;
return kk;
exception
when others then
return ′-1′;
end;
·在test用户下建表mmtest并插入记录:
create table mmtest
(usnamevarchar2(6),------用户名称
mimavarchar2(6)------加密前的密码);
insert into mmtest values( ‘sfyy‘,‘eds2‘);
commit;
·执行以下语句
SQL>select mmtranslate(‘eds2‘) from dual;
MMTRANSLATE(‘EDS2‘)
----------------------------------------
ihwf
利用DBA权限更改sfyy的密码为上面语句的执行结果:
alter user sffy
identified by ihwf; ;
·修改应用程序，对于开发环境是Develope2000的程序来说，主要是修改主程序的on-lo gon触发器:
declare
mm varchar2(6);
begin
logon(‘test‘,‘carton‘);
select mima into mm from mmtest where usname=‘sfyy‘;
mm:=mmtranslate(mm);
logout;
logon(‘sfyy‘,mm);
end;
然后再利用触发器WHEN-NEW-FROM-INSTANCE执行Callfrom或Newform等 命令，进入业务处理程序。这个主程序应当仅仅由管理员来掌握,编译之后将执行文件下发 到各收费点的Clien端。
·在System用户下，利用Oracle提供的pupbld.sql,建立表Productuserprofile,执行下面这样的命令，限制在非开发状态Sql命令的使用,例如
insert into productuserprofile
(product,userid,attribute,charvalue) values
(‘SQL*Plus‘,‘TEST‘,‘CONNECT‘,‘DISABLED‘);
insert into productuserprofile
(product,userid,attribute,charvalue) values
(‘SQL*Plus‘,‘SFYY‘,‘DELETE‘,‘DISABLED‘);这样，在SQL状态下，根本无法连接到TEST用户，而在 sfyy用户下，delete命令将不能执行。当然，DBA可以改变这些设置。
当然了，这个仅仅是属于一种“应用技巧”，但是足可以把那些每天忙于更新系统的管理员舒服好几天了。但是另一方面，还要加强对源程序的管理，在Client端只存放执行程序。加强审计，发现异常现象，及时处理。这样才可以做到更高一层的“安全”。
在下面，我主要是向大家介绍一个REM对GHXXB制立数据库触发子,密码的加密程序。
REM 对GHXXB制立数据库触发子(当INSERT OR UPDATE GHXXB时触发)
drop trigger scjmmm;
create or replace trigger scjmmm
before insert or update of mm On ghxxb For each Row
Begin
:new.mm:=ENCRYPT(:new.mm,:NEW.GH,TO_CHAR(SYSDATE,‘SS‘));
End;
/
---------------------------密码的加密程序ENCRYPT----------------------
Create or Replace
Function ENCRYPT (Inpass In Varchar2,IN_GH In Varchar2,IN_SS In Varchar2)
Return Varchar2 Is
bcs varchar2(20);
bcs1 number;
cs number;
jg number;
m_gh VARCHAR2(4);
m_mm VARCHAR2(20);
Begin
m_gh:=IN_GH;
m_mm:=INPASS;
cs:=TO_NUMBER(IN_SS);
If cs
bcs:=substr(to_char(ascii(substr(m_gh,1,1))),1,2);
If bcs
m_gh:=substr(m_gh,2);
Loop EXIT WHEN nvl(length(m_gh),0)=0 ;
bcs:=bcs||substr(to_char(ascii(substr(m_gh,1,1))),-1,1);
m_gh:=substr(m_gh,2);
End loop;
Loop EXIT WHEN nvl(length(m_mm),0)=0 ;
bcs:=bcs||substr(to_char(ascii(substr(m_mm,1,1))),-1,1);
m_mm:=substr(m_mm,2);
End loop;
bcs1:=to_number(bcs);
jg:=cs*bcs1;
Loop EXIT WHEN length(to_char(jg))>13;
jg:=jg*cs ;
End loop;
RETURN(IN_SS||substr(to_char(jg),1,14));
End;
/
总结上面的东西，我们仅仅是从自身做起，知道了怎么维护Oracle数据库安全这个话题的“皮毛”。可是，对于这个似乎永远也说不完的话题，我们光知道怎么从内部“防御”就够了吗?不要忘了，在外面，还有一群虎视耽耽的“hacker”在盯着你的数据库--因为这里面有他们想要的东西。
所以，请大家关注好下一个话题:
§2.不被“hacker”入侵的几个建议
我们的目标是:没有蛀牙!(开个玩笑~!呵呵)其实应该是:它应尽可能地堵住潜在的各种漏洞，防止非法用户利用它们侵入数据库系统。对于数据库数据的安全问题，数据库管理员可以参考有关系统双机热备份功能以及数据库的备份和恢复的资料。
以下就数据库系统不被非法用户侵入这个问题作进一步的阐述。
·组和安全性:在操作系统下建立用户组也是保证数据库安全性的一种有效方法。Oracle程序为了安全性目的一般分为两类:一类所有的用户都可执行，另一类只DBA可执行。在Unix环境下组设置的配置文件是/etc/group，关于这个文件如何配置，请参阅Unix的有关手册，以下是保证安全性的几种方法:
(1)在安装Oracle Server前，创建数据库管理员组(DBA)而且分配root和Oracle软件拥有者的用户ID给这个组。DBA能执行的程序只有710权限。在安装过程中SQL*DBA系统权限命令被自动分配给DBA组。
(2)允许一部分Unix用户有限制地访问Oracle服务器系统
，增加一个由授权用户组的Oracle组，确保给Oracle服务器实用例程Oracle组ID，公用的可执行程序，比如SQL*Plus，SQL*forms等，应该可被这组执行，然后该这个实用例程的权限为710，它将允许同组的用户执行，而其他用户不能。
(3)改那些不会影响数据库安全性的程序的权限为711。(注:在我们的系统中为了安装和调试的方便，Oracle数据库中的两个具有DBA权限的用户Sys和System的缺省密码是manager。为了您数据库系统的安全，我们强烈建议您该掉这两个用户的密码，具体操作如下:
在SQL*DBA下键入:
alter user sys indentified by password;
alter user system indentified by password;
其中password为您为用户设置的密码。
·Oracle服务器实用例程的安全性:
以下是保护Oracle服务器不被非法用户使用的几条建议:
(1) 确保$ORACLE_HOME/bin目录下的所有程序的拥有权归Oracle软件拥有者所有;
(2) 给所有用户实用便程(sqiplus,sqiforms,exp,imp等)711权限，使服务器上所有的用户都可访问Oracle服务器;
(3) 给所有的DBA实用例程(比如SQL*DBA)700权限。Oracle服务器和Unix组当访问本地的服务时，您可以通过在操作系统下把Oracle服务器的角色映射到Unix的组的方式来使用Unix管理服务器的安全性，这种方法适应于本地访问。
在Unix中指定Oracle服务器角色的格式如下:
ora_sid_role[_dla]
其中 sid 是您Oracle数据库的oracle_sid;
role 是Oracle服务器中角色的名字;
d (可选)表示这个角色是缺省值;a (可选)表示这个角色带有WITH ADMIN选项，您只可以把这个角色授予其他角色，不能是其他用户。
以下是在/etc/group文件中设置的例子:
ora_test_osoper_d:NONE:1:jim,narry,scott
ora_test_osdba_a:NONE:3:pat
ora_test_role1:NONE:4:bob,jane,tom,mary,jim
bin: NONE:5:root,oracle,dba
root:NONE:7:root
词组“ora_test_osoper_d”表示组的名字;词组“NONE”表示这个组的密码;数字1表示这个组的ID;接下来的是这个组的成员。前两行是Oracle服务器角色的例子，使用test作为sid，osoper和osdba作为Oracle服务器角色的名字。osoper是分配给用户的缺省角色，osdba带有WITH ADMIN选项。为了使这些数据库角色起作用，您必须shutdown您的数据库系统，设置Oracle数据库参数文件initORACLE_SID.ora中os_roles参数为True，然后重新启动您的数据库。如果您想让这些角色有connect internal权限，运行orapwd为这些角色设置密码。当您尝试connect internal时，您键入的密码表示了角色所对应的权限。
·SQL*DBA命令的安全性:
如果您没有SQL*PLUS应用程序，您也可以使用SQL*DBA作SQL查权限相关的命令只能分配给Oracle软件拥有者和DBA组的用户，因为这些命令被授予了特殊的系统权限。
(1) startup
(2) shutdown
(3) connect internal
·数据库文件的安全性:
Oracle软件的拥有者应该这些数据库文件($ORACLE_HOME/dbs/*.dbf)设置这些文件的使用权限为0600:文件的拥有者可读可写，同组的和其他组的用户没有写的权限。
Oracle软件的拥有者应该拥有包含数据库文件的目录，为了增加安全性，建议收回同组和其他组用户对这些文件的可读权限。
·网络安全性:
当处理网络安全性时，以下是额外要考虑的几个问题。
(1) 在网络上使用密码在网上的远端用户可以通过加密或不加密方式键入密码，当您用不加密方式键入密码时，您的密码很有可能被非法用户截获，导致破坏了系统的安全性。
(2) 网络上的DBA权限控制您可以通过下列两种方式对网络上的DBA权限进行控制:
A 设置成拒绝远程DBA访问;
B 通过orapwd给DBA设置特殊的密码。
·建立安全性策略:
系统安全性策略
(1)管理数据库用户:数据库用户是访问Oracle数据库信息的途径，因此，应该很好地维护管理数据库用户的安全性。按照数据库系统的大小和管理数据库用户所需的工作量，数据库安全性管理者可能只是拥有create，alter，或drop数据库用户的一个特殊用户，或者是拥有这些权限的一组用户，应注意的是，只有那些值得信任的个人才应该有管理数据库用户的权限。
(2) 用户身份确认:数据库用户可以通过操作系统，网络服务，或数据库进行身份确认，通过主机操作系统进行用户身份认证的优点有:
A 用户能更快，更方便地联入数据库;
B 通过操作系统对用户身份确认进行集中控制:如果操作系统与数据库用户信息一致，Oracle无须存储和管理用户名以及密码;
C 用户进入数据库和操作系统审计信息一致。
(3) 操作系统安全性
A 数据库管理员必须有create和delete文件的操作系统权限;
B 一般数据库用户不应该有create或delete与数据库相关文件的操作系统权限;
C 如果操作系统能为数据库用户分配角色，那么安全性管理者必须有修改操作系统帐户安全性区域的操作系统权限。
·数据的安全性策略:
数据的生考虑应基于数据的重要性。如果数据不是很重要，那么数据的安全性策略可以稍稍放松一些。然而，如果数据很重要，那么应该有一谨慎的安全性策略，用它来维护对数据对象访问的有效控制。
·用户安全性策略:
(1) 一般用户的安全性:
A 密码的安全性:如果用户是通过数据库进行用户身份的确认，那么建议使用密码加密的方式与数据库进行连接。这种方式的设置方法如下:
在客户端的oracle.ini文件中设置ora_encrypt_login数为true;
在服务器端的initORACLE_SID.ora文件中设置dbling_encypt_login参数为true。
B 权限管理:对于那些用户很多，应用程序和数据对象很丰富的数据库，应充分利用“角色”这个机制所带的方便性对权限进行有效管理。对于复杂的系统环境，“角色”能大大地简化权限的理。
(2) 终端用户的安全性:
您必须针对终端用户制定安全性策略。例如，对于一个有很多用户的大规模数据库，安全性管理者可以决定用户组分类为这些用户组创建用户角色，把所需的权限和应用程序角色授予每一个用户角色，以及为用户分配相应的用户角色。当处理特殊的应用要求时，安全性管理者也必须明确地把一些特定的权限要求授予给用户。您可以使用“角色”对终端用户进行权限管理。
·数据库管理者安全性策略:
(1) 保护作为sys和system用户的连接:
当数据库创建好以后，立即更改有管理权限的sys和system用户的密码，防止非法用户访问数据库。当作为sys和system用户连入数据库后，用户有强大的权限用各种方式对数据库进行改动。
(2) 保护管理者与数据库的连接:
应该只有数据库管理者能用管理权限连入数据库，当以sysdba或startup，shutdown，和recover或数据库对象(例如create,drop，和delete等)进行没有任何限制的操作。
(3) 使用角色对管理者权限进行管理
·应用程序开发者的安全性策略:
(1) 应用程序开发者和他们的权限数据库应用程序开发者是唯一一类需要特殊权限组完成自己工作的数据库用户。开发者需要诸如create table,create，procedure等系统权限，然而，为了限制开发者对数据库的操作，只应该把一些特定的系统权限授予开发者。
(2) 应用程序开发者的环境:
A 程序开发者不应与终端用户竞争数据库资源;
B 用程序开发者不能损害数据库其他应用产品。
(3) free和controlled应用程序开发应用程序开发者有一下两种权限:
A free development
应用程序开发者允许创建新的模式对象，包括table,index,procedure,package等，它允许应用程序开发者开发独立于其他对象的应用程序。
B controlled development
应用程序开发者不允许创建新的模式对象。所有需要table,indes procedure等都由数据库管理者创建，它保证了数据库管理者能完全控制数据空间的使用以及访问数据库信息的途径。但有时应用程序开发者也需这两种权限的混和。
(4) 应用程序开发者的角色和权限数据库安全性管理者能创建角色来管理典型的应用程序开发者的权限要求。
A create系统权限常常授予给应用程序开发者，以至于他们能创建他的数据对象。
B 数据对象角色几乎不会授予给应用程序开发者使用的角色。
(5) 加强应用程序开发者的空间限制作为数据库安全性管理者，您应该特别地为每个应用程序开发者设置以下的一些限制:
A 开发者可以创建table或index的表空间;
B 在每一个表空间中，开发者所拥有的空间份额。应用程序管理者的安全在有许多数据库应用程序的数据库系统中，您可能需要一应用程序管理者，应用程序管理者应负责起以下的任务:
a)为每一个应用程序创建角色以及管理每一个应用程序的角色;
b)创建和管理数据库应用程序使用的数据对象;
c)需要的话，维护和更新应用程序代码和Oracle的存储过程和程序包。
我相信有了以上的这些建议，作为一个Oracle的管理者绝对可以做好他本职的工作了。可是，我们再怎么努力，都始终得面对这样一个现实，那就是Oracle毕竟是其他人开发的，而我们却在使用。所以，Oracle到底有多少漏洞--我想这个不是你和我所能解决的。不过既然作为一篇讨论Oracle数据安全的文章，我认为有必要把漏洞这一块也写进去，毕竟这也是“安全”必不可少的一部分。呵呵!
所以……
【Oracle漏洞举例】:
·Oracle9iAS Web Cache远程拒绝服务攻击漏洞(2002-10-28)
·Oracle 8.1.6的oidldapd中的漏洞
·Oracle 9iAS OracleJSP 泄漏JSP文件信息漏洞
·Linux ORACLE 8.1.5漏洞
想必我没有理由再往下举了，因为读者肯定已经从其他有效的途径得到了关于Oracle漏洞的最新情报。我这里就不再赘述了。
总而言之一句话--“Oracle数据安全是一个博大而又精深的话题;如果你没有耐心，就永远不会得到它的精髓之所在。”
·向密码文件中增加、删除用户:
当初始化参数REMOTE_LOGIN_PASSWORDFILE设置为EXCLUSIVE时，系统允许除INTERNAL/SYS以外的其他用户以管理员身份从远端或本机登录到Oracle数据库系统，执行数据库管理工作;这些用户名必须存在于密码文件中，系统才能识别他们。由于不管是在创建数据库实例时自动创建的密码文件，还是使用工具ORAPWD.EXE手工创建的密码文件，都只包含INTERNAL/SYS用户的信息;为此，在实际操作中，可能需要向密码文件添加或删除其他用户帐号。
由于仅被授予SYSOPER/SYSDBA系统权限的用户才存在于密码文件中，所以当向某一用户授予或收回SYSOPER/SYSDBA系统权限时，他们的帐号也将相应地被加入到密码文件或从密码文件中删除。由此，向密码文件中增加或删除某一用户，实际上也就是对某一用户授予或收回SYSOPER/SYSDBA系统权限。
要进行此项授权操作，需使用SYSDBA权限(或INTERNAL帐号)连入数据库，且初始化参数REMOTE_LOGIN_PASSWORDFILE的设置必须为EXCLUSIVE。具体操作步骤如下:
创建相应的密码文件;
设置初始化参数REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE;
使用SYSDBA权限登录: CONNECT SYS/internal_user_passsword AS SYSDBA;
启动数据库实例并打开数据库;
创建相应用户帐号，对其授权(包括SYSOPER和SYSDBA): 授予权限:GRANT SYSDBA TO user_name;
收回权限:REVOKE SYSDBA FROM user_name;
现在这些用户可以以管理员身份登录数据库系统了;
·使用密码文件登录:
有了密码文件后，用户就可以使用密码文件以SYSOPER/SYSDBA权限登录Oracle数据库实例了，注意初始化参数REMOTE_LOGIN_PASSWORDFILE应设置为EXCLUSIVE或SHARED。任何用户以SYSOPER/SYSDBA的权限登录后，将位于SYS用户的Schema之下，以下为两个登录的例子:
1. 以管理员身份登录:
假设用户scott已被授予SYSDBA权限，则他可以使用以下命令登录:
CONNECT scott/tiger AS SYSDBA
2. 以INTERNAL身份登录:
CONNECT INTERNAL/INTERNAL_PASSWORD
·密码文件的维护:
1. 查看密码文件中的成员:
可以通过查询视图V$PWFILE_USERS来获取拥有SYSOPER/SYSDBA系统权限的用户的信息，表中SYSOPER/SYSDBA列的取值TRUE/FALSE表示此用户是否拥有相应的权限。这些用户也就是相应地存在于密码文件中的成员。
2. 扩展密码文件的用户数量:
当向密码文件添加的帐号数目超过创建密码文件时所定的限制(即ORAPWD.EXE工具的MAX_USERS参数)时，为扩展密码文件的用户数限制，需重建密码文件，具体步骤如下:
a) 查询视图V$PWFILE_USERS，记录下拥有SYSOPER/SYSDBA系统权限的用户信息;
关闭数据库;
c) 删除密码文件;
d) 用ORAPWD.EXE新建一密码文件;
e) 将步骤a中获取的用户添加到密码文件中。
3. 修改密码文件的状态:
密码文件的状态信息存放于此文件中，当它被创建时，它的缺省状态为SHARED。可以通过改变初始化参数REMOTE_LOGIN_PASSWORDFILE的设置改变密码文件的状态。当启动数据库事例时，Oracle系统从初始化参数文件中读取REMOTE_LOGIN_PASSWORDFILE参数的设置;当加载数据库时，系统将此参数与口令文件的状态进行比较，如果不同，则更新密码文件的状态。若计划允许从多台客户机上启动数据库实例，由于各客户机上必须有初始化参数文件，所以应确保各客户机上的初始化参数文件的一致性，以避免意外地改变了密码文件的状态，造成数据库登陆的失败。
4. 修改密码文件的存储位置:
密码文件的存放位置可以根据需要进行移动，但作此修改后，应相应修改系统注册库有关指向密码文件存放位置的参数或环境变量的设置。
5. 删除密码文件:
在删除密码文件前,应确保当前运行的各数据库实例的初始化参数REMOTE_LOGIN_PASSWORDFILE皆设置为NONE。在删除密码文件后，若想要以管理员身份连入数据库的话，则必须使用操作系统验证的方法进行登录。
但是管理员都觉得乏味，因为在管理员中流行一种很简单的加密办法--就是经常，很频繁地修改自己的密码。可是，每次修改都跟打一次仗似的--因为更新程序并不是每个人都愿意做的事情。
那么有没有什么简单点的办法呢?请往下看:
模型:Oracle7.3;开发工具evelope2000。收费系统(在数据库中的名称是SFYY)，其Client端分散在市区的数个营业点，通过城域网与主机(小型 机)相连。
过程:
·在收费小型机Oracle系统的system用户(DBA)下，创建新用户test;
create user test
identified by carton
default tablespace dataspace1
quota 100K
·对test用户授以权限;
grant create session to test;
grant resource to test;
·在test用户下建立一个存储函数mmtranslate,它其实是一个加密程序。下面是一个简 单的例子。
function mmtranslate(m varchar2)
return varchar2
as
i number(2);
kk varchar2(10);
begin
kk:=′′;
i:=1;
loop
if i
if instr(′1234567890′,substr(m,i,1),1,1)>0 then
kk:=kk||chr(100+to_number(substr(m,i,1)));
elseif instr(‘wxyz‘,substr(m,i,1),1,1)>0 then
kk:=kk||chr(-8+ascii(substr(m,i,1)));
else
kk:=kk||chr(4+ascii(substr(m,i,1)));
end if;
else
exit;
end if;
i:=i+1;
end loop;
return kk;
exception
when others then
return ′-1′;
end;
·在test用户下建表mmtest并插入记录:
create table mmtest
(usnamevarchar2(6),------用户名称
mimavarchar2(6)------加密前的密码);
insert into mmtest values( ‘sfyy‘,‘eds2‘);
commit;
·执行以下语句
SQL>select mmtranslate(‘eds2‘) from dual;
MMTRANSLATE(‘EDS2‘)
----------------------------------------
ihwf
利用DBA权限更改sfyy的密码为上面语句的执行结果:
alter user sffy
identified by ihwf; ;
·修改应用程序，对于开发环境是Develope2000的程序来说，主要是修改主程序的on-lo gon触发器:
declare
mm varchar2(6);
begin
logon(‘test‘,‘carton‘);
select mima into mm from mmtest where usname=‘sfyy‘;
mm:=mmtranslate(mm);
logout;
logon(‘sfyy‘,mm);
end;
然后再利用触发器WHEN-NEW-FROM-INSTANCE执行Callfrom或Newform等 命令，进入业务处理程序。这个主程序应当仅仅由管理员来掌握,编译之后将执行文件下发 到各收费点的Clien端。
·在System用户下，利用Oracle提供的pupbld.sql,建立表Productuserprofile,执行下面这样的命令，限制在非开发状态Sql命令的使用,例如
insert into productuserprofile
(product,userid,attribute,charvalue) values
(‘SQL*Plus‘,‘TEST‘,‘CONNECT‘,‘DISABLED‘);
insert into productuserprofile
(product,userid,attribute,charvalue) values
(‘SQL*Plus‘,‘SFYY‘,‘DELETE‘,‘DISABLED‘);这样，在SQL状态下，根本无法连接到TEST用户，而在 sfyy用户下，delete命令将不能执行。当然，DBA可以改变这些设置。
当然了，这个仅仅是属于一种“应用技巧”，但是足可以把那些每天忙于更新系统的管理员舒服好几天了。但是另一方面，还要加强对源程序的管理，在Client端只存放执行程序。加强审计，发现异常现象，及时处理。这样才可以做到更高一层的“安全”。
在下面，我主要是向大家介绍一个REM对GHXXB制立数据库触发子,密码的加密程序。
REM 对GHXXB制立数据库触发子(当INSERT OR UPDATE GHXXB时触发)
drop trigger scjmmm;
create or replace trigger scjmmm
before insert or update of mm On ghxxb For each Row
Begin
:new.mm:=ENCRYPT(:new.mm,:NEW.GH,TO_CHAR(SYSDATE,‘SS‘));
End;
/
---------------------------密码的加密程序ENCRYPT----------------------
Create or Replace
Function ENCRYPT (Inpass In Varchar2,IN_GH In Varchar2,IN_SS In Varchar2)
Return Varchar2 Is
bcs varchar2(20);
bcs1 number;
cs number;
jg number;
m_gh VARCHAR2(4);
m_mm VARCHAR2(20);
Begin
m_gh:=IN_GH;
m_mm:=INPASS;
cs:=TO_NUMBER(IN_SS);
If cs
bcs:=substr(to_char(ascii(substr(m_gh,1,1))),1,2);
If bcs
m_gh:=substr(m_gh,2);
Loop EXIT WHEN nvl(length(m_gh),0)=0 ;
bcs:=bcs||substr(to_char(ascii(substr(m_gh,1,1))),-1,1);
m_gh:=substr(m_gh,2);
End loop;
Loop EXIT WHEN nvl(length(m_mm),0)=0 ;
bcs:=bcs||substr(to_char(ascii(substr(m_mm,1,1))),-1,1);
m_mm:=substr(m_mm,2);
End loop;
bcs1:=to_number(bcs);
jg:=cs*bcs1;
Loop EXIT WHEN length(to_char(jg))>13;
jg:=jg*cs ;
End loop;
RETURN(IN_SS||substr(to_char(jg),1,14));
End;
/
总结上面的东西，我们仅仅是从自身做起，知道了怎么维护Oracle数据库安全这个话题的“皮毛”。可是，对于这个似乎永远也说不完的话题，我们光知道怎么从内部“防御”就够了吗?不要忘了，在外面，还有一群虎视耽耽的“hacker”在盯着你的数据库--因为这里面有他们想要的东西。
所以，请大家关注好下一个话题:
§2.不被“hacker”入侵的几个建议
我们的目标是:没有蛀牙!(开个玩笑~!呵呵)其实应该是:它应尽可能地堵住潜在的各种漏洞，防止非法用户利用它们侵入数据库系统。对于数据库数据的安全问题，数据库管理员可以参考有关系统双机热备份功能以及数据库的备份和恢复的资料。
以下就数据库系统不被非法用户侵入这个问题作进一步的阐述。
·组和安全性:在操作系统下建立用户组也是保证数据库安全性的一种有效方法。Oracle程序为了安全性目的一般分为两类:一类所有的用户都可执行，另一类只DBA可执行。在Unix环境下组设置的配置文件是/etc/group，关于这个文件如何配置，请参阅Unix的有关手册，以下是保证安全性的几种方法:
(1)在安装Oracle Server前，创建数据库管理员组(DBA)而且分配root和Oracle软件拥有者的用户ID给这个组。DBA能执行的程序只有710权限。在安装过程中SQL*DBA系统权限命令被自动分配给DBA组。
(2)允许一部分Unix用户有限制地访问Oracle服务器系统
，增加一个由授权用户组的Oracle组，确保给Oracle服务器实用例程Oracle组ID，公用的可执行程序，比如SQL*Plus，SQL*forms等，应该可被这组执行，然后该这个实用例程的权限为710，它将允许同组的用户执行，而其他用户不能。
(3)改那些不会影响数据库安全性的程序的权限为711。(注:在我们的系统中为了安装和调试的方便，Oracle数据库中的两个具有DBA权限的用户Sys和System的缺省密码是manager。为了您数据库系统的安全，我们强烈建议您该掉这两个用户的密码，具体操作如下:
在SQL*DBA下键入:
alter user sys indentified by password;
alter user system indentified by password;
其中password为您为用户设置的密码。
·Oracle服务器实用例程的安全性:
以下是保护Oracle服务器不被非法用户使用的几条建议:
(1) 确保$ORACLE_HOME/bin目录下的所有程序的拥有权归Oracle软件拥有者所有;
(2) 给所有用户实用便程(sqiplus,sqiforms,exp,imp等)711权限，使服务器上所有的用户都可访问Oracle服务器;
(3) 给所有的DBA实用例程(比如SQL*DBA)700权限。Oracle服务器和Unix组当访问本地的服务时，您可以通过在操作系统下把Oracle服务器的角色映射到Unix的组的方式来使用Unix管理服务器的安全性，这种方法适应于本地访问。
在Unix中指定Oracle服务器角色的格式如下:
ora_sid_role[_dla]
其中 sid 是您Oracle数据库的oracle_sid;
role 是Oracle服务器中角色的名字;
d (可选)表示这个角色是缺省值;a (可选)表示这个角色带有WITH ADMIN选项，您只可以把这个角色授予其他角色，不能是其他用户。
以下是在/etc/group文件中设置的例子:
ora_test_osoper_d:NONE:1:jim,narry,scott
ora_test_osdba_a:NONE:3:pat
ora_test_role1:NONE:4:bob,jane,tom,mary,jim
bin: NONE:5:root,oracle,dba
root:NONE:7:root
词组“ora_test_osoper_d”表示组的名字;词组“NONE”表示这个组的密码;数字1表示这个组的ID;接下来的是这个组的成员。前两行是Oracle服务器角色的例子，使用test作为sid，osoper和osdba作为Oracle服务器角色的名字。osoper是分配给用户的缺省角色，osdba带有WITH ADMIN选项。为了使这些数据库角色起作用，您必须shutdown您的数据库系统，设置Oracle数据库参数文件initORACLE_SID.ora中os_roles参数为True，然后重新启动您的数据库。如果您想让这些角色有connect internal权限，运行orapwd为这些角色设置密码。当您尝试connect internal时，您键入的密码表示了角色所对应的权限。
·SQL*DBA命令的安全性:
如果您没有SQL*PLUS应用程序，您也可以使用SQL*DBA作SQL查权限相关的命令只能分配给Oracle软件拥有者和DBA组的用户，因为这些命令被授予了特殊的系统权限。
(1) startup
(2) shutdown
(3) connect internal
·数据库文件的安全性:
Oracle软件的拥有者应该这些数据库文件($ORACLE_HOME/dbs/*.dbf)设置这些文件的使用权限为0600:文件的拥有者可读可写，同组的和其他组的用户没有写的权限。
Oracle软件的拥有者应该拥有包含数据库文件的目录，为了增加安全性，建议收回同组和其他组用户对这些文件的可读权限。
·网络安全性:
当处理网络安全性时，以下是额外要考虑的几个问题。
(1) 在网络上使用密码在网上的远端用户可以通过加密或不加密方式键入密码，当您用不加密方式键入密码时，您的密码很有可能被非法用户截获，导致破坏了系统的安全性。
(2) 网络上的DBA权限控制您可以通过下列两种方式对网络上的DBA权限进行控制:
A 设置成拒绝远程DBA访问;
B 通过orapwd给DBA设置特殊的密码。
·建立安全性策略:
系统安全性策略
(1)管理数据库用户:数据库用户是访问Oracle数据库信息的途径，因此，应该很好地维护管理数据库用户的安全性。按照数据库系统的大小和管理数据库用户所需的工作量，数据库安全性管理者可能只是拥有create，alter，或drop数据库用户的一个特殊用户，或者是拥有这些权限的一组用户，应注意的是，只有那些值得信任的个人才应该有管理数据库用户的权限。
(2) 用户身份确认:数据库用户可以通过操作系统，网络服务，或数据库进行身份确认，通过主机操作系统进行用户身份认证的优点有:
A 用户能更快，更方便地联入数据库;
B 通过操作系统对用户身份确认进行集中控制:如果操作系统与数据库用户信息一致，Oracle无须存储和管理用户名以及密码;
C 用户进入数据库和操作系统审计信息一致。
(3) 操作系统安全性
A 数据库管理员必须有create和delete文件的操作系统权限;
B 一般数据库用户不应该有create或delete与数据库相关文件的操作系统权限;
C 如果操作系统能为数据库用户分配角色，那么安全性管理者必须有修改操作系统帐户安全性区域的操作系统权限。
·数据的安全性策略:
数据的生考虑应基于数据的重要性。如果数据不是很重要，那么数据的安全性策略可以稍稍放松一些。然而，如果数据很重要，那么应该有一谨慎的安全性策略，用它来维护对数据对象访问的有效控制。
·用户安全性策略:
(1) 一般用户的安全性:
A 密码的安全性:如果用户是通过数据库进行用户身份的确认，那么建议使用密码加密的方式与数据库进行连接。这种方式的设置方法如下:
在客户端的oracle.ini文件中设置ora_encrypt_login数为true;
在服务器端的initORACLE_SID.ora文件中设置dbling_encypt_login参数为true。
B 权限管理:对于那些用户很多，应用程序和数据对象很丰富的数据库，应充分利用“角色”这个机制所带的方便性对权限进行有效管理。对于复杂的系统环境，“角色”能大大地简化权限的理。
(2) 终端用户的安全性:
您必须针对终端用户制定安全性策略。例如，对于一个有很多用户的大规模数据库，安全性管理者可以决定用户组分类为这些用户组创建用户角色，把所需的权限和应用程序角色授予每一个用户角色，以及为用户分配相应的用户角色。当处理特殊的应用要求时，安全性管理者也必须明确地把一些特定的权限要求授予给用户。您可以使用“角色”对终端用户进行权限管理。
·数据库管理者安全性策略:
(1) 保护作为sys和system用户的连接:
当数据库创建好以后，立即更改有管理权限的sys和system用户的密码，防止非法用户访问数据库。当作为sys和system用户连入数据库后，用户有强大的权限用各种方式对数据库进行改动。
(2) 保护管理者与数据库的连接:
应该只有数据库管理者能用管理权限连入数据库，当以sysdba或startup，shutdown，和recover或数据库对象(例如create,drop，和delete等)进行没有任何限制的操作。
(3) 使用角色对管理者权限进行管理
·应用程序开发者的安全性策略:
(1) 应用程序开发者和他们的权限数据库应用程序开发者是唯一一类需要特殊权限组完成自己工作的数据库用户。开发者需要诸如create table,create，procedure等系统权限，然而，为了限制开发者对数据库的操作，只应该把一些特定的系统权限授予开发者。
(2) 应用程序开发者的环境:
A 程序开发者不应与终端用户竞争数据库资源;
B 用程序开发者不能损害数据库其他应用产品。
(3) free和controlled应用程序开发应用程序开发者有一下两种权限:
A free development
应用程序开发者允许创建新的模式对象，包括table,index,procedure,package等，它允许应用程序开发者开发独立于其他对象的应用程序。
B controlled development
应用程序开发者不允许创建新的模式对象。所有需要table,indes procedure等都由数据库管理者创建，它保证了数据库管理者能完全控制数据空间的使用以及访问数据库信息的途径。但有时应用程序开发者也需这两种权限的混和。
(4) 应用程序开发者的角色和权限数据库安全性管理者能创建角色来管理典型的应用程序开发者的权限要求。
A create系统权限常常授予给应用程序开发者，以至于他们能创建他的数据对象。
B 数据对象角色几乎不会授予给应用程序开发者使用的角色。
(5) 加强应用程序开发者的空间限制作为数据库安全性管理者，您应该特别地为每个应用程序开发者设置以下的一些限制:
A 开发者可以创建table或index的表空间;
B 在每一个表空间中，开发者所拥有的空间份额。应用程序管理者的安全在有许多数据库应用程序的数据库系统中，您可能需要一应用程序管理者，应用程序管理者应负责起以下的任务:
a)为每一个应用程序创建角色以及管理每一个应用程序的角色;
b)创建和管理数据库应用程序使用的数据对象;
c)需要的话，维护和更新应用程序代码和Oracle的存储过程和程序包。
我相信有了以上的这些建议，作为一个Oracle的管理者绝对可以做好他本职的工作了。可是，我们再怎么努力，都始终得面对这样一个现实，那就是Oracle毕竟是其他人开发的，而我们却在使用。所以，Oracle到底有多少漏洞--我想这个不是你和我所能解决的。不过既然作为一篇讨论Oracle数据安全的文章，我认为有必要把漏洞这一块也写进去，毕竟这也是“安全”必不可少的一部分。呵呵!
所以……
【Oracle漏洞举例】:
·Oracle9iAS Web Cache远程拒绝服务攻击漏洞(2002-10-28)
·Oracle 8.1.6的oidldapd中的漏洞
·Oracle 9iAS OracleJSP 泄漏JSP文件信息漏洞
·Linux ORACLE 8.1.5漏洞
想必我没有理由再往下举了，因为读者肯定已经从其他有效的途径得到了关于Oracle漏洞的最新情报。我这里就不再赘述了。
总而言之一句话--“Oracle数据安全是一个博大而又精深的话题;如果你没有耐心，就永远不会得到它的精髓之所在。”
到软件公司学IT技术http://www.tsp2c.cn/
当初始化参数REMOTE_LOGIN_PASSWORDFILE设置为EXCLUSIVE时，系统允许除INTERNAL/SYS以外的其他用户以管理员身份从远端或本机登录到Oracle数据库系统，执行数据库管理工作;这些用户名必须存在于密码文件中，系统才能识别他们。由于不管是在创建数据库实例时自动创建的密码文件，还是使用工具ORAPWD.EXE手工创建的密码文件，都只包含INTERNAL/SYS用户的信息;为此，在实际操作中，可能需要向密码文件添加或删除其他用户帐号。
由于仅被授予SYSOPER/SYSDBA系统权限的用户才存在于密码文件中，所以当向某一用户授予或收回SYSOPER/SYSDBA系统权限时，他们的帐号也将相应地被加入到密码文件或从密码文件中删除。由此，向密码文件中增加或删除某一用户，实际上也就是对某一用户授予或收回SYSOPER/SYSDBA系统权限。
要进行此项授权操作，需使用SYSDBA权限(或INTERNAL帐号)连入数据库，且初始化参数REMOTE_LOGIN_PASSWORDFILE的设置必须为EXCLUSIVE。具体操作步骤如下:
创建相应的密码文件;
设置初始化参数REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE;
使用SYSDBA权限登录: CONNECT SYS/internal_user_passsword AS SYSDBA;
启动数据库实例并打开数据库;
创建相应用户帐号，对其授权(包括SYSOPER和SYSDBA): 授予权限:GRANT SYSDBA TO user_name;
收回权限:REVOKE SYSDBA FROM user_name;
现在这些用户可以以管理员身份登录数据库系统了;
·使用密码文件登录:
有了密码文件后，用户就可以使用密码文件以SYSOPER/SYSDBA权限登录Oracle数据库实例了，注意初始化参数REMOTE_LOGIN_PASSWORDFILE应设置为EXCLUSIVE或SHARED。任何用户以SYSOPER/SYSDBA的权限登录后，将位于SYS用户的Schema之下，以下为两个登录的例子:
1. 以管理员身份登录:
假设用户scott已被授予SYSDBA权限，则他可以使用以下命令登录:
CONNECT scott/tiger AS SYSDBA
2. 以INTERNAL身份登录:
CONNECT INTERNAL/INTERNAL_PASSWORD
·密码文件的维护:
1. 查看密码文件中的成员:
可以通过查询视图V$PWFILE_USERS来获取拥有SYSOPER/SYSDBA系统权限的用户的信息，表中SYSOPER/SYSDBA列的取值TRUE/FALSE表示此用户是否拥有相应的权限。这些用户也就是相应地存在于密码文件中的成员。
2. 扩展密码文件的用户数量:
当向密码文件添加的帐号数目超过创建密码文件时所定的限制(即ORAPWD.EXE工具的MAX_USERS参数)时，为扩展密码文件的用户数限制，需重建密码文件，具体步骤如下:
a) 查询视图V$PWFILE_USERS，记录下拥有SYSOPER/SYSDBA系统权限的用户信息;
关闭数据库;
c) 删除密码文件;
d) 用ORAPWD.EXE新建一密码文件;
e) 将步骤a中获取的用户添加到密码文件中。
3. 修改密码文件的状态:
密码文件的状态信息存放于此文件中，当它被创建时，它的缺省状态为SHARED。可以通过改变初始化参数REMOTE_LOGIN_PASSWORDFILE的设置改变密码文件的状态。当启动数据库事例时，Oracle系统从初始化参数文件中读取REMOTE_LOGIN_PASSWORDFILE参数的设置;当加载数据库时，系统将此参数与口令文件的状态进行比较，如果不同，则更新密码文件的状态。若计划允许从多台客户机上启动数据库实例，由于各客户机上必须有初始化参数文件，所以应确保各客户机上的初始化参数文件的一致性，以避免意外地改变了密码文件的状态，造成数据库登陆的失败。
4. 修改密码文件的存储位置:
密码文件的存放位置可以根据需要进行移动，但作此修改后，应相应修改系统注册库有关指向密码文件存放位置的参数或环境变量的设置。
5. 删除密码文件:
在删除密码文件前,应确保当前运行的各数据库实例的初始化参数REMOTE_LOGIN_PASSWORDFILE皆设置为NONE。在删除密码文件后，若想要以管理员身份连入数据库的话，则必须使用操作系统验证的方法进行登录。
但是管理员都觉得乏味，因为在管理员中流行一种很简单的加密办法--就是经常，很频繁地修改自己的密码。可是，每次修改都跟打一次仗似的--因为更新程序并不是每个人都愿意做的事情。
那么有没有什么简单点的办法呢?请往下看:
模型:Oracle7.3;开发工具evelope2000。收费系统(在数据库中的名称是SFYY)，其Client端分散在市区的数个营业点，通过城域网与主机(小型 机)相连。
过程:
·在收费小型机Oracle系统的system用户(DBA)下，创建新用户test;
create user test
identified by carton
default tablespace dataspace1
quota 100K
·对test用户授以权限;
grant create session to test;
grant resource to test;
·在test用户下建立一个存储函数mmtranslate,它其实是一个加密程序。下面是一个简 单的例子。
function mmtranslate(m varchar2)
return varchar2
as
i number(2);
kk varchar2(10);
begin
kk:=′′;
i:=1;
loop
if i
if instr(′1234567890′,substr(m,i,1),1,1)>0 then
kk:=kk||chr(100+to_number(substr(m,i,1)));
elseif instr(‘wxyz‘,substr(m,i,1),1,1)>0 then
kk:=kk||chr(-8+ascii(substr(m,i,1)));
else
kk:=kk||chr(4+ascii(substr(m,i,1)));
end if;
else
exit;
end if;
i:=i+1;
end loop;
return kk;
exception
when others then
return ′-1′;
end;
·在test用户下建表mmtest并插入记录:
create table mmtest
(usnamevarchar2(6),------用户名称
mimavarchar2(6)------加密前的密码);
insert into mmtest values( ‘sfyy‘,‘eds2‘);
commit;
·执行以下语句
SQL>select mmtranslate(‘eds2‘) from dual;
MMTRANSLATE(‘EDS2‘)
----------------------------------------
ihwf
利用DBA权限更改sfyy的密码为上面语句的执行结果:
alter user sffy
identified by ihwf; ;
·修改应用程序，对于开发环境是Develope2000的程序来说，主要是修改主程序的on-lo gon触发器:
declare
mm varchar2(6);
begin
logon(‘test‘,‘carton‘);
select mima into mm from mmtest where usname=‘sfyy‘;
mm:=mmtranslate(mm);
logout;
logon(‘sfyy‘,mm);
end;
然后再利用触发器WHEN-NEW-FROM-INSTANCE执行Callfrom或Newform等 命令，进入业务处理程序。这个主程序应当仅仅由管理员来掌握,编译之后将执行文件下发 到各收费点的Clien端。
·在System用户下，利用Oracle提供的pupbld.sql,建立表Productuserprofile,执行下面这样的命令，限制在非开发状态Sql命令的使用,例如
insert into productuserprofile
(product,userid,attribute,charvalue) values
(‘SQL*Plus‘,‘TEST‘,‘CONNECT‘,‘DISABLED‘);
insert into productuserprofile
(product,userid,attribute,charvalue) values
(‘SQL*Plus‘,‘SFYY‘,‘DELETE‘,‘DISABLED‘);这样，在SQL状态下，根本无法连接到TEST用户，而在 sfyy用户下，delete命令将不能执行。当然，DBA可以改变这些设置。
当然了，这个仅仅是属于一种“应用技巧”，但是足可以把那些每天忙于更新系统的管理员舒服好几天了。但是另一方面，还要加强对源程序的管理，在Client端只存放执行程序。加强审计，发现异常现象，及时处理。这样才可以做到更高一层的“安全”。
在下面，我主要是向大家介绍一个REM对GHXXB制立数据库触发子,密码的加密程序。
REM 对GHXXB制立数据库触发子(当INSERT OR UPDATE GHXXB时触发)
drop trigger scjmmm;
create or replace trigger scjmmm
before insert or update of mm On ghxxb For each Row
Begin
:new.mm:=ENCRYPT(:new.mm,:NEW.GH,TO_CHAR(SYSDATE,‘SS‘));
End;
/
---------------------------密码的加密程序ENCRYPT----------------------
Create or Replace
Function ENCRYPT (Inpass In Varchar2,IN_GH In Varchar2,IN_SS In Varchar2)
Return Varchar2 Is
bcs varchar2(20);
bcs1 number;
cs number;
jg number;
m_gh VARCHAR2(4);
m_mm VARCHAR2(20);
Begin
m_gh:=IN_GH;
m_mm:=INPASS;
cs:=TO_NUMBER(IN_SS);
If cs
bcs:=substr(to_char(ascii(substr(m_gh,1,1))),1,2);
If bcs
m_gh:=substr(m_gh,2);
Loop EXIT WHEN nvl(length(m_gh),0)=0 ;
bcs:=bcs||substr(to_char(ascii(substr(m_gh,1,1))),-1,1);
m_gh:=substr(m_gh,2);
End loop;
Loop EXIT WHEN nvl(length(m_mm),0)=0 ;
bcs:=bcs||substr(to_char(ascii(substr(m_mm,1,1))),-1,1);
m_mm:=substr(m_mm,2);
End loop;
bcs1:=to_number(bcs);
jg:=cs*bcs1;
Loop EXIT WHEN length(to_char(jg))>13;
jg:=jg*cs ;
End loop;
RETURN(IN_SS||substr(to_char(jg),1,14));
End;
/
总结上面的东西，我们仅仅是从自身做起，知道了怎么维护Oracle数据库安全这个话题的“皮毛”。可是，对于这个似乎永远也说不完的话题，我们光知道怎么从内部“防御”就够了吗?不要忘了，在外面，还有一群虎视耽耽的“hacker”在盯着你的数据库--因为这里面有他们想要的东西。
所以，请大家关注好下一个话题:
§2.不被“hacker”入侵的几个建议
我们的目标是:没有蛀牙!(开个玩笑~!呵呵)其实应该是:它应尽可能地堵住潜在的各种漏洞，防止非法用户利用它们侵入数据库系统。对于数据库数据的安全问题，数据库管理员可以参考有关系统双机热备份功能以及数据库的备份和恢复的资料。
以下就数据库系统不被非法用户侵入这个问题作进一步的阐述。
·组和安全性:在操作系统下建立用户组也是保证数据库安全性的一种有效方法。Oracle程序为了安全性目的一般分为两类:一类所有的用户都可执行，另一类只DBA可执行。在Unix环境下组设置的配置文件是/etc/group，关于这个文件如何配置，请参阅Unix的有关手册，以下是保证安全性的几种方法:
(1)在安装Oracle Server前，创建数据库管理员组(DBA)而且分配root和Oracle软件拥有者的用户ID给这个组。DBA能执行的程序只有710权限。在安装过程中SQL*DBA系统权限命令被自动分配给DBA组。
(2)允许一部分Unix用户有限制地访问Oracle服务器系统
，增加一个由授权用户组的Oracle组，确保给Oracle服务器实用例程Oracle组ID，公用的可执行程序，比如SQL*Plus，SQL*forms等，应该可被这组执行，然后该这个实用例程的权限为710，它将允许同组的用户执行，而其他用户不能。
(3)改那些不会影响数据库安全性的程序的权限为711。(注:在我们的系统中为了安装和调试的方便，Oracle数据库中的两个具有DBA权限的用户Sys和System的缺省密码是manager。为了您数据库系统的安全，我们强烈建议您该掉这两个用户的密码，具体操作如下:
在SQL*DBA下键入:
alter user sys indentified by password;
alter user system indentified by password;
其中password为您为用户设置的密码。
·Oracle服务器实用例程的安全性:
以下是保护Oracle服务器不被非法用户使用的几条建议:
(1) 确保$ORACLE_HOME/bin目录下的所有程序的拥有权归Oracle软件拥有者所有;
(2) 给所有用户实用便程(sqiplus,sqiforms,exp,imp等)711权限，使服务器上所有的用户都可访问Oracle服务器;
(3) 给所有的DBA实用例程(比如SQL*DBA)700权限。Oracle服务器和Unix组当访问本地的服务时，您可以通过在操作系统下把Oracle服务器的角色映射到Unix的组的方式来使用Unix管理服务器的安全性，这种方法适应于本地访问。
在Unix中指定Oracle服务器角色的格式如下:
ora_sid_role[_dla]
其中 sid 是您Oracle数据库的oracle_sid;
role 是Oracle服务器中角色的名字;
d (可选)表示这个角色是缺省值;a (可选)表示这个角色带有WITH ADMIN选项，您只可以把这个角色授予其他角色，不能是其他用户。
以下是在/etc/group文件中设置的例子:
ora_test_osoper_d:NONE:1:jim,narry,scott
ora_test_osdba_a:NONE:3:pat
ora_test_role1:NONE:4:bob,jane,tom,mary,jim
bin: NONE:5:root,oracle,dba
root:NONE:7:root
词组“ora_test_osoper_d”表示组的名字;词组“NONE”表示这个组的密码;数字1表示这个组的ID;接下来的是这个组的成员。前两行是Oracle服务器角色的例子，使用test作为sid，osoper和osdba作为Oracle服务器角色的名字。osoper是分配给用户的缺省角色，osdba带有WITH ADMIN选项。为了使这些数据库角色起作用，您必须shutdown您的数据库系统，设置Oracle数据库参数文件initORACLE_SID.ora中os_roles参数为True，然后重新启动您的数据库。如果您想让这些角色有connect internal权限，运行orapwd为这些角色设置密码。当您尝试connect internal时，您键入的密码表示了角色所对应的权限。
·SQL*DBA命令的安全性:
如果您没有SQL*PLUS应用程序，您也可以使用SQL*DBA作SQL查权限相关的命令只能分配给Oracle软件拥有者和DBA组的用户，因为这些命令被授予了特殊的系统权限。
(1) startup
(2) shutdown
(3) connect internal
·数据库文件的安全性:
Oracle软件的拥有者应该这些数据库文件($ORACLE_HOME/dbs/*.dbf)设置这些文件的使用权限为0600:文件的拥有者可读可写，同组的和其他组的用户没有写的权限。
Oracle软件的拥有者应该拥有包含数据库文件的目录，为了增加安全性，建议收回同组和其他组用户对这些文件的可读权限。
·网络安全性:
当处理网络安全性时，以下是额外要考虑的几个问题。
(1) 在网络上使用密码在网上的远端用户可以通过加密或不加密方式键入密码，当您用不加密方式键入密码时，您的密码很有可能被非法用户截获，导致破坏了系统的安全性。
(2) 网络上的DBA权限控制您可以通过下列两种方式对网络上的DBA权限进行控制:
A 设置成拒绝远程DBA访问;
B 通过orapwd给DBA设置特殊的密码。
·建立安全性策略:
系统安全性策略
(1)管理数据库用户:数据库用户是访问Oracle数据库信息的途径，因此，应该很好地维护管理数据库用户的安全性。按照数据库系统的大小和管理数据库用户所需的工作量，数据库安全性管理者可能只是拥有create，alter，或drop数据库用户的一个特殊用户，或者是拥有这些权限的一组用户，应注意的是，只有那些值得信任的个人才应该有管理数据库用户的权限。
(2) 用户身份确认:数据库用户可以通过操作系统，网络服务，或数据库进行身份确认，通过主机操作系统进行用户身份认证的优点有:
A 用户能更快，更方便地联入数据库;
B 通过操作系统对用户身份确认进行集中控制:如果操作系统与数据库用户信息一致，Oracle无须存储和管理用户名以及密码;
C 用户进入数据库和操作系统审计信息一致。
(3) 操作系统安全性
A 数据库管理员必须有create和delete文件的操作系统权限;
B 一般数据库用户不应该有create或delete与数据库相关文件的操作系统权限;
C 如果操作系统能为数据库用户分配角色，那么安全性管理者必须有修改操作系统帐户安全性区域的操作系统权限。
·数据的安全性策略:
数据的生考虑应基于数据的重要性。如果数据不是很重要，那么数据的安全性策略可以稍稍放松一些。然而，如果数据很重要，那么应该有一谨慎的安全性策略，用它来维护对数据对象访问的有效控制。
·用户安全性策略:
(1) 一般用户的安全性:
A 密码的安全性:如果用户是通过数据库进行用户身份的确认，那么建议使用密码加密的方式与数据库进行连接。这种方式的设置方法如下:
在客户端的oracle.ini文件中设置ora_encrypt_login数为true;
在服务器端的initORACLE_SID.ora文件中设置dbling_encypt_login参数为true。
B 权限管理:对于那些用户很多，应用程序和数据对象很丰富的数据库，应充分利用“角色”这个机制所带的方便性对权限进行有效管理。对于复杂的系统环境，“角色”能大大地简化权限的理。
(2) 终端用户的安全性:
您必须针对终端用户制定安全性策略。例如，对于一个有很多用户的大规模数据库，安全性管理者可以决定用户组分类为这些用户组创建用户角色，把所需的权限和应用程序角色授予每一个用户角色，以及为用户分配相应的用户角色。当处理特殊的应用要求时，安全性管理者也必须明确地把一些特定的权限要求授予给用户。您可以使用“角色”对终端用户进行权限管理。
·数据库管理者安全性策略:
(1) 保护作为sys和system用户的连接:
当数据库创建好以后，立即更改有管理权限的sys和system用户的密码，防止非法用户访问数据库。当作为sys和system用户连入数据库后，用户有强大的权限用各种方式对数据库进行改动。
(2) 保护管理者与数据库的连接:
应该只有数据库管理者能用管理权限连入数据库，当以sysdba或startup，shutdown，和recover或数据库对象(例如create,drop，和delete等)进行没有任何限制的操作。
(3) 使用角色对管理者权限进行管理
·应用程序开发者的安全性策略:
(1) 应用程序开发者和他们的权限数据库应用程序开发者是唯一一类需要特殊权限组完成自己工作的数据库用户。开发者需要诸如create table,create，procedure等系统权限，然而，为了限制开发者对数据库的操作，只应该把一些特定的系统权限授予开发者。
(2) 应用程序开发者的环境:
A 程序开发者不应与终端用户竞争数据库资源;
B 用程序开发者不能损害数据库其他应用产品。
(3) free和controlled应用程序开发应用程序开发者有一下两种权限:
A free development
应用程序开发者允许创建新的模式对象，包括table,index,procedure,package等，它允许应用程序开发者开发独立于其他对象的应用程序。
B controlled development
应用程序开发者不允许创建新的模式对象。所有需要table,indes procedure等都由数据库管理者创建，它保证了数据库管理者能完全控制数据空间的使用以及访问数据库信息的途径。但有时应用程序开发者也需这两种权限的混和。
(4) 应用程序开发者的角色和权限数据库安全性管理者能创建角色来管理典型的应用程序开发者的权限要求。
A create系统权限常常授予给应用程序开发者，以至于他们能创建他的数据对象。
B 数据对象角色几乎不会授予给应用程序开发者使用的角色。
(5) 加强应用程序开发者的空间限制作为数据库安全性管理者，您应该特别地为每个应用程序开发者设置以下的一些限制:
A 开发者可以创建table或index的表空间;
B 在每一个表空间中，开发者所拥有的空间份额。应用程序管理者的安全在有许多数据库应用程序的数据库系统中，您可能需要一应用程序管理者，应用程序管理者应负责起以下的任务:
a)为每一个应用程序创建角色以及管理每一个应用程序的角色;
b)创建和管理数据库应用程序使用的数据对象;
c)需要的话，维护和更新应用程序代码和Oracle的存储过程和程序包。
我相信有了以上的这些建议，作为一个Oracle的管理者绝对可以做好他本职的工作了。可是，我们再怎么努力，都始终得面对这样一个现实，那就是Oracle毕竟是其他人开发的，而我们却在使用。所以，Oracle到底有多少漏洞--我想这个不是你和我所能解决的。不过既然作为一篇讨论Oracle数据安全的文章，我认为有必要把漏洞这一块也写进去，毕竟这也是“安全”必不可少的一部分。呵呵!
所以……
【Oracle漏洞举例】:
·Oracle9iAS Web Cache远程拒绝服务攻击漏洞(2002-10-28)
·Oracle 8.1.6的oidldapd中的漏洞
·Oracle 9iAS OracleJSP 泄漏JSP文件信息漏洞
·Linux ORACLE 8.1.5漏洞
想必我没有理由再往下举了，因为读者肯定已经从其他有效的途径得到了关于Oracle漏洞的最新情报。我这里就不再赘述了。
总而言之一句话--“Oracle数据安全是一个博大而又精深的话题;如果你没有耐心，就永远不会得到它的精髓之所在。”
·向密码文件中增加、删除用户:
当初始化参数REMOTE_LOGIN_PASSWORDFILE设置为EXCLUSIVE时，系统允许除INTERNAL/SYS以外的其他用户以管理员身份从远端或本机登录到Oracle数据库系统，执行数据库管理工作;这些用户名必须存在于密码文件中，系统才能识别他们。由于不管是在创建数据库实例时自动创建的密码文件，还是使用工具ORAPWD.EXE手工创建的密码文件，都只包含INTERNAL/SYS用户的信息;为此，在实际操作中，可能需要向密码文件添加或删除其他用户帐号。
由于仅被授予SYSOPER/SYSDBA系统权限的用户才存在于密码文件中，所以当向某一用户授予或收回SYSOPER/SYSDBA系统权限时，他们的帐号也将相应地被加入到密码文件或从密码文件中删除。由此，向密码文件中增加或删除某一用户，实际上也就是对某一用户授予或收回SYSOPER/SYSDBA系统权限。
要进行此项授权操作，需使用SYSDBA权限(或INTERNAL帐号)连入数据库，且初始化参数REMOTE_LOGIN_PASSWORDFILE的设置必须为EXCLUSIVE。具体操作步骤如下:
创建相应的密码文件;
设置初始化参数REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE;
使用SYSDBA权限登录: CONNECT SYS/internal_user_passsword AS SYSDBA;
启动数据库实例并打开数据库;
创建相应用户帐号，对其授权(包括SYSOPER和SYSDBA): 授予权限:GRANT SYSDBA TO user_name;
收回权限:REVOKE SYSDBA FROM user_name;
现在这些用户可以以管理员身份登录数据库系统了;
·使用密码文件登录:
有了密码文件后，用户就可以使用密码文件以SYSOPER/SYSDBA权限登录Oracle数据库实例了，注意初始化参数REMOTE_LOGIN_PASSWORDFILE应设置为EXCLUSIVE或SHARED。任何用户以SYSOPER/SYSDBA的权限登录后，将位于SYS用户的Schema之下，以下为两个登录的例子:
1. 以管理员身份登录:
假设用户scott已被授予SYSDBA权限，则他可以使用以下命令登录:
CONNECT scott/tiger AS SYSDBA
2. 以INTERNAL身份登录:
CONNECT INTERNAL/INTERNAL_PASSWORD
·密码文件的维护:
1. 查看密码文件中的成员:
可以通过查询视图V$PWFILE_USERS来获取拥有SYSOPER/SYSDBA系统权限的用户的信息，表中SYSOPER/SYSDBA列的取值TRUE/FALSE表示此用户是否拥有相应的权限。这些用户也就是相应地存在于密码文件中的成员。
2. 扩展密码文件的用户数量:
当向密码文件添加的帐号数目超过创建密码文件时所定的限制(即ORAPWD.EXE工具的MAX_USERS参数)时，为扩展密码文件的用户数限制，需重建密码文件，具体步骤如下:
a) 查询视图V$PWFILE_USERS，记录下拥有SYSOPER/SYSDBA系统权限的用户信息;
关闭数据库;
c) 删除密码文件;
d) 用ORAPWD.EXE新建一密码文件;
e) 将步骤a中获取的用户添加到密码文件中。
3. 修改密码文件的状态:
密码文件的状态信息存放于此文件中，当它被创建时，它的缺省状态为SHARED。可以通过改变初始化参数REMOTE_LOGIN_PASSWORDFILE的设置改变密码文件的状态。当启动数据库事例时，Oracle系统从初始化参数文件中读取REMOTE_LOGIN_PASSWORDFILE参数的设置;当加载数据库时，系统将此参数与口令文件的状态进行比较，如果不同，则更新密码文件的状态。若计划允许从多台客户机上启动数据库实例，由于各客户机上必须有初始化参数文件，所以应确保各客户机上的初始化参数文件的一致性，以避免意外地改变了密码文件的状态，造成数据库登陆的失败。
4. 修改密码文件的存储位置:
密码文件的存放位置可以根据需要进行移动，但作此修改后，应相应修改系统注册库有关指向密码文件存放位置的参数或环境变量的设置。
5. 删除密码文件:
在删除密码文件前,应确保当前运行的各数据库实例的初始化参数REMOTE_LOGIN_PASSWORDFILE皆设置为NONE。在删除密码文件后，若想要以管理员身份连入数据库的话，则必须使用操作系统验证的方法进行登录。
但是管理员都觉得乏味，因为在管理员中流行一种很简单的加密办法--就是经常，很频繁地修改自己的密码。可是，每次修改都跟打一次仗似的--因为更新程序并不是每个人都愿意做的事情。
那么有没有什么简单点的办法呢?请往下看:
模型:Oracle7.3;开发工具evelope2000。收费系统(在数据库中的名称是SFYY)，其Client端分散在市区的数个营业点，通过城域网与主机(小型 机)相连。
过程:
·在收费小型机Oracle系统的system用户(DBA)下，创建新用户test;
create user test
identified by carton
default tablespace dataspace1
quota 100K
·对test用户授以权限;
grant create session to test;
grant resource to test;
·在test用户下建立一个存储函数mmtranslate,它其实是一个加密程序。下面是一个简 单的例子。
function mmtranslate(m varchar2)
return varchar2
as
i number(2);
kk varchar2(10);
begin
kk:=′′;
i:=1;
loop
if i
if instr(′1234567890′,substr(m,i,1),1,1)>0 then
kk:=kk||chr(100+to_number(substr(m,i,1)));
elseif instr(‘wxyz‘,substr(m,i,1),1,1)>0 then
kk:=kk||chr(-8+ascii(substr(m,i,1)));
else
kk:=kk||chr(4+ascii(substr(m,i,1)));
end if;
else
exit;
end if;
i:=i+1;
end loop;
return kk;
exception
when others then
return ′-1′;
end;
·在test用户下建表mmtest并插入记录:
create table mmtest
(usnamevarchar2(6),------用户名称
mimavarchar2(6)------加密前的密码);
insert into mmtest values( ‘sfyy‘,‘eds2‘);
commit;
·执行以下语句
SQL>select mmtranslate(‘eds2‘) from dual;
MMTRANSLATE(‘EDS2‘)
----------------------------------------
ihwf
利用DBA权限更改sfyy的密码为上面语句的执行结果:
alter user sffy
identified by ihwf; ;
·修改应用程序，对于开发环境是Develope2000的程序来说，主要是修改主程序的on-lo gon触发器:
declare
mm varchar2(6);
begin
logon(‘test‘,‘carton‘);
select mima into mm from mmtest where usname=‘sfyy‘;
mm:=mmtranslate(mm);
logout;
logon(‘sfyy‘,mm);
end;
然后再利用触发器WHEN-NEW-FROM-INSTANCE执行Callfrom或Newform等 命令，进入业务处理程序。这个主程序应当仅仅由管理员来掌握,编译之后将执行文件下发 到各收费点的Clien端。
·在System用户下，利用Oracle提供的pupbld.sql,建立表Productuserprofile,执行下面这样的命令，限制在非开发状态Sql命令的使用,例如
insert into productuserprofile
(product,userid,attribute,charvalue) values
(‘SQL*Plus‘,‘TEST‘,‘CONNECT‘,‘DISABLED‘);
insert into productuserprofile
(product,userid,attribute,charvalue) values
(‘SQL*Plus‘,‘SFYY‘,‘DELETE‘,‘DISABLED‘);这样，在SQL状态下，根本无法连接到TEST用户，而在 sfyy用户下，delete命令将不能执行。当然，DBA可以改变这些设置。
当然了，这个仅仅是属于一种“应用技巧”，但是足可以把那些每天忙于更新系统的管理员舒服好几天了。但是另一方面，还要加强对源程序的管理，在Client端只存放执行程序。加强审计，发现异常现象，及时处理。这样才可以做到更高一层的“安全”。
在下面，我主要是向大家介绍一个REM对GHXXB制立数据库触发子,密码的加密程序。
REM 对GHXXB制立数据库触发子(当INSERT OR UPDATE GHXXB时触发)
drop trigger scjmmm;
create or replace trigger scjmmm
before insert or update of mm On ghxxb For each Row
Begin
:new.mm:=ENCRYPT(:new.mm,:NEW.GH,TO_CHAR(SYSDATE,‘SS‘));
End;
/
---------------------------密码的加密程序ENCRYPT----------------------
Create or Replace
Function ENCRYPT (Inpass In Varchar2,IN_GH In Varchar2,IN_SS In Varchar2)
Return Varchar2 Is
bcs varchar2(20);
bcs1 number;
cs number;
jg number;
m_gh VARCHAR2(4);
m_mm VARCHAR2(20);
Begin
m_gh:=IN_GH;
m_mm:=INPASS;
cs:=TO_NUMBER(IN_SS);
If cs
bcs:=substr(to_char(ascii(substr(m_gh,1,1))),1,2);
If bcs
m_gh:=substr(m_gh,2);
Loop EXIT WHEN nvl(length(m_gh),0)=0 ;
bcs:=bcs||substr(to_char(ascii(substr(m_gh,1,1))),-1,1);
m_gh:=substr(m_gh,2);
End loop;
Loop EXIT WHEN nvl(length(m_mm),0)=0 ;
bcs:=bcs||substr(to_char(ascii(substr(m_mm,1,1))),-1,1);
m_mm:=substr(m_mm,2);
End loop;
bcs1:=to_number(bcs);
jg:=cs*bcs1;
Loop EXIT WHEN length(to_char(jg))>13;
jg:=jg*cs ;
End loop;
RETURN(IN_SS||substr(to_char(jg),1,14));
End;
/
总结上面的东西，我们仅仅是从自身做起，知道了怎么维护Oracle数据库安全这个话题的“皮毛”。可是，对于这个似乎永远也说不完的话题，我们光知道怎么从内部“防御”就够了吗?不要忘了，在外面，还有一群虎视耽耽的“hacker”在盯着你的数据库--因为这里面有他们想要的东西。
所以，请大家关注好下一个话题:
§2.不被“hacker”入侵的几个建议
我们的目标是:没有蛀牙!(开个玩笑~!呵呵)其实应该是:它应尽可能地堵住潜在的各种漏洞，防止非法用户利用它们侵入数据库系统。对于数据库数据的安全问题，数据库管理员可以参考有关系统双机热备份功能以及数据库的备份和恢复的资料。
以下就数据库系统不被非法用户侵入这个问题作进一步的阐述。
·组和安全性:在操作系统下建立用户组也是保证数据库安全性的一种有效方法。Oracle程序为了安全性目的一般分为两类:一类所有的用户都可执行，另一类只DBA可执行。在Unix环境下组设置的配置文件是/etc/group，关于这个文件如何配置，请参阅Unix的有关手册，以下是保证安全性的几种方法:
(1)在安装Oracle Server前，创建数据库管理员组(DBA)而且分配root和Oracle软件拥有者的用户ID给这个组。DBA能执行的程序只有710权限。在安装过程中SQL*DBA系统权限命令被自动分配给DBA组。
(2)允许一部分Unix用户有限制地访问Oracle服务器系统
，增加一个由授权用户组的Oracle组，确保给Oracle服务器实用例程Oracle组ID，公用的可执行程序，比如SQL*Plus，SQL*forms等，应该可被这组执行，然后该这个实用例程的权限为710，它将允许同组的用户执行，而其他用户不能。
(3)改那些不会影响数据库安全性的程序的权限为711。(注:在我们的系统中为了安装和调试的方便，Oracle数据库中的两个具有DBA权限的用户Sys和System的缺省密码是manager。为了您数据库系统的安全，我们强烈建议您该掉这两个用户的密码，具体操作如下:
在SQL*DBA下键入:
alter user sys indentified by password;
alter user system indentified by password;
其中password为您为用户设置的密码。
·Oracle服务器实用例程的安全性:
以下是保护Oracle服务器不被非法用户使用的几条建议:
(1) 确保$ORACLE_HOME/bin目录下的所有程序的拥有权归Oracle软件拥有者所有;
(2) 给所有用户实用便程(sqiplus,sqiforms,exp,imp等)711权限，使服务器上所有的用户都可访问Oracle服务器;
(3) 给所有的DBA实用例程(比如SQL*DBA)700权限。Oracle服务器和Unix组当访问本地的服务时，您可以通过在操作系统下把Oracle服务器的角色映射到Unix的组的方式来使用Unix管理服务器的安全性，这种方法适应于本地访问。
在Unix中指定Oracle服务器角色的格式如下:
ora_sid_role[_dla]
其中 sid 是您Oracle数据库的oracle_sid;
role 是Oracle服务器中角色的名字;
d (可选)表示这个角色是缺省值;a (可选)表示这个角色带有WITH ADMIN选项，您只可以把这个角色授予其他角色，不能是其他用户。
以下是在/etc/group文件中设置的例子:
ora_test_osoper_d:NONE:1:jim,narry,scott
ora_test_osdba_a:NONE:3:pat
ora_test_role1:NONE:4:bob,jane,tom,mary,jim
bin: NONE:5:root,oracle,dba
root:NONE:7:root
词组“ora_test_osoper_d”表示组的名字;词组“NONE”表示这个组的密码;数字1表示这个组的ID;接下来的是这个组的成员。前两行是Oracle服务器角色的例子，使用test作为sid，osoper和osdba作为Oracle服务器角色的名字。osoper是分配给用户的缺省角色，osdba带有WITH ADMIN选项。为了使这些数据库角色起作用，您必须shutdown您的数据库系统，设置Oracle数据库参数文件initORACLE_SID.ora中os_roles参数为True，然后重新启动您的数据库。如果您想让这些角色有connect internal权限，运行orapwd为这些角色设置密码。当您尝试connect internal时，您键入的密码表示了角色所对应的权限。
·SQL*DBA命令的安全性:
如果您没有SQL*PLUS应用程序，您也可以使用SQL*DBA作SQL查权限相关的命令只能分配给Oracle软件拥有者和DBA组的用户，因为这些命令被授予了特殊的系统权限。
(1) startup
(2) shutdown
(3) connect internal
·数据库文件的安全性:
Oracle软件的拥有者应该这些数据库文件($ORACLE_HOME/dbs/*.dbf)设置这些文件的使用权限为0600:文件的拥有者可读可写，同组的和其他组的用户没有写的权限。
Oracle软件的拥有者应该拥有包含数据库文件的目录，为了增加安全性，建议收回同组和其他组用户对这些文件的可读权限。
·网络安全性:
当处理网络安全性时，以下是额外要考虑的几个问题。
(1) 在网络上使用密码在网上的远端用户可以通过加密或不加密方式键入密码，当您用不加密方式键入密码时，您的密码很有可能被非法用户截获，导致破坏了系统的安全性。
(2) 网络上的DBA权限控制您可以通过下列两种方式对网络上的DBA权限进行控制:
A 设置成拒绝远程DBA访问;
B 通过orapwd给DBA设置特殊的密码。
·建立安全性策略:
系统安全性策略
(1)管理数据库用户:数据库用户是访问Oracle数据库信息的途径，因此，应该很好地维护管理数据库用户的安全性。按照数据库系统的大小和管理数据库用户所需的工作量，数据库安全性管理者可能只是拥有create，alter，或drop数据库用户的一个特殊用户，或者是拥有这些权限的一组用户，应注意的是，只有那些值得信任的个人才应该有管理数据库用户的权限。
(2) 用户身份确认:数据库用户可以通过操作系统，网络服务，或数据库进行身份确认，通过主机操作系统进行用户身份认证的优点有:
A 用户能更快，更方便地联入数据库;
B 通过操作系统对用户身份确认进行集中控制:如果操作系统与数据库用户信息一致，Oracle无须存储和管理用户名以及密码;
C 用户进入数据库和操作系统审计信息一致。
(3) 操作系统安全性
A 数据库管理员必须有create和delete文件的操作系统权限;
B 一般数据库用户不应该有create或delete与数据库相关文件的操作系统权限;
C 如果操作系统能为数据库用户分配角色，那么安全性管理者必须有修改操作系统帐户安全性区域的操作系统权限。
·数据的安全性策略:
数据的生考虑应基于数据的重要性。如果数据不是很重要，那么数据的安全性策略可以稍稍放松一些。然而，如果数据很重要，那么应该有一谨慎的安全性策略，用它来维护对数据对象访问的有效控制。
·用户安全性策略:
(1) 一般用户的安全性:
A 密码的安全性:如果用户是通过数据库进行用户身份的确认，那么建议使用密码加密的方式与数据库进行连接。这种方式的设置方法如下:
在客户端的oracle.ini文件中设置ora_encrypt_login数为true;
在服务器端的initORACLE_SID.ora文件中设置dbling_encypt_login参数为true。
B 权限管理:对于那些用户很多，应用程序和数据对象很丰富的数据库，应充分利用“角色”这个机制所带的方便性对权限进行有效管理。对于复杂的系统环境，“角色”能大大地简化权限的理。
(2) 终端用户的安全性:
您必须针对终端用户制定安全性策略。例如，对于一个有很多用户的大规模数据库，安全性管理者可以决定用户组分类为这些用户组创建用户角色，把所需的权限和应用程序角色授予每一个用户角色，以及为用户分配相应的用户角色。当处理特殊的应用要求时，安全性管理者也必须明确地把一些特定的权限要求授予给用户。您可以使用“角色”对终端用户进行权限管理。
·数据库管理者安全性策略:
(1) 保护作为sys和system用户的连接:
当数据库创建好以后，立即更改有管理权限的sys和system用户的密码，防止非法用户访问数据库。当作为sys和system用户连入数据库后，用户有强大的权限用各种方式对数据库进行改动。
(2) 保护管理者与数据库的连接:
应该只有数据库管理者能用管理权限连入数据库，当以sysdba或startup，shutdown，和recover或数据库对象(例如create,drop，和delete等)进行没有任何限制的操作。
(3) 使用角色对管理者权限进行管理
·应用程序开发者的安全性策略:
(1) 应用程序开发者和他们的权限数据库应用程序开发者是唯一一类需要特殊权限组完成自己工作的数据库用户。开发者需要诸如create table,create，procedure等系统权限，然而，为了限制开发者对数据库的操作，只应该把一些特定的系统权限授予开发者。
(2) 应用程序开发者的环境:
A 程序开发者不应与终端用户竞争数据库资源;
B 用程序开发者不能损害数据库其他应用产品。
(3) free和controlled应用程序开发应用程序开发者有一下两种权限:
A free development
应用程序开发者允许创建新的模式对象，包括table,index,procedure,package等，它允许应用程序开发者开发独立于其他对象的应用程序。
B controlled development
应用程序开发者不允许创建新的模式对象。所有需要table,indes procedure等都由数据库管理者创建，它保证了数据库管理者能完全控制数据空间的使用以及访问数据库信息的途径。但有时应用程序开发者也需这两种权限的混和。
(4) 应用程序开发者的角色和权限数据库安全性管理者能创建角色来管理典型的应用程序开发者的权限要求。
A create系统权限常常授予给应用程序开发者，以至于他们能创建他的数据对象。
B 数据对象角色几乎不会授予给应用程序开发者使用的角色。
(5) 加强应用程序开发者的空间限制作为数据库安全性管理者，您应该特别地为每个应用程序开发者设置以下的一些限制:
A 开发者可以创建table或index的表空间;
B 在每一个表空间中，开发者所拥有的空间份额。应用程序管理者的安全在有许多数据库应用程序的数据库系统中，您可能需要一应用程序管理者，应用程序管理者应负责起以下的任务:
a)为每一个应用程序创建角色以及管理每一个应用程序的角色;
b)创建和管理数据库应用程序使用的数据对象;
c)需要的话，维护和更新应用程序代码和Oracle的存储过程和程序包。
我相信有了以上的这些建议，作为一个Oracle的管理者绝对可以做好他本职的工作了。可是，我们再怎么努力，都始终得面对这样一个现实，那就是Oracle毕竟是其他人开发的，而我们却在使用。所以，Oracle到底有多少漏洞--我想这个不是你和我所能解决的。不过既然作为一篇讨论Oracle数据安全的文章，我认为有必要把漏洞这一块也写进去，毕竟这也是“安全”必不可少的一部分。呵呵!
所以……
【Oracle漏洞举例】:
·Oracle9iAS Web Cache远程拒绝服务攻击漏洞(2002-10-28)
·Oracle 8.1.6的oidldapd中的漏洞
·Oracle 9iAS OracleJSP 泄漏JSP文件信息漏洞
·Linux ORACLE 8.1.5漏洞
想必我没有理由再往下举了，因为读者肯定已经从其他有效的途径得到了关于Oracle漏洞的最新情报。我这里就不再赘述了。
总而言之一句话--“Oracle数据安全是一个博大而又精深的话题;如果你没有耐心，就永远不会得到它的精髓之所在。”
到软件公司学IT技术http://www.tsp2c.cn/
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- Oracle安全数据系统架构全接触(3)
- Oracle安全全接触
- Oracle安全数据系统架构全接触(4)
- Oracle安全数据系统架构全接触
- Oracle安全全接触（上）
- Oracle安全数据系统架构全接触(1)
- Oracle安全全接触
- Oracle安全全接触
- Oracle安全全接触
- Oracle安全数据系统架构全接触(2)
- Oracle教程之管理安全和资源（一）--Oracle策略文件
- Oracle安全 - SCN的可能最大值与耗尽问题
- 7 Oracle 管理用户和安全
- oracle基本语句（第四章、数据库安全管理）
- Oracle 起步日记（19）——安全管理、角色管理
- oracle数据安全面面观
- 【多图】近距离接触甲骨文总裁马克赫德，Oracle在上海香格里拉酒店数据中心优化专题研讨会
- Oracle EBS密码安全的攻与防
- zabbix监控oracle安全指标
- spring-mybaits-oracle项目初接触