ORACLE安全管理在数据库设计与开发中的应用研究.docx
- 文档编号:24279181
- 上传时间:2023-05-26
- 格式:DOCX
- 页数:11
- 大小:21.11KB
ORACLE安全管理在数据库设计与开发中的应用研究.docx
《ORACLE安全管理在数据库设计与开发中的应用研究.docx》由会员分享,可在线阅读,更多相关《ORACLE安全管理在数据库设计与开发中的应用研究.docx(11页珍藏版)》请在冰豆网上搜索。
ORACLE安全管理在数据库设计与开发中的应用研究
摘要
本文介绍了Oracle安全管理的一些知识,包括用户、角色的使用以及安全审计等。
数据安全性是指保护数据以防止非法的使用,避免造成数据有意或无意的丢失、泄露或破坏。
由于数据库系统中集中存放有大量的数据,这些数据又为众多用户所共享,所以安全约束是一个极为突出的问题。
而采用真实数据库用户,存在着权限分配上的难度,特别是用户数和应用表数都很多时,这时必然要使用角色来管理应用权限的分配。
当然不能直接将权限或角色直接分配给用户,否则用户可以不同过应用系统,而采用SQL*PLUS等前端工具进入系统,进行一些没有经过应用系统检查的操作,产生的结果可能不符合应用逻辑。
关键字:
Oracle技术权限用户角色安全管理
目录
一、引言1
二、Oracle安全性能2
2.1合法用户的帐户安全性2
2.2数据库对象的访问安全性2
2.3管理全局权限的系统级安全性2
三、Oracle系统级角色3
3.1CONNECT角色3
3.2RESOURCE角色3
3.3DBA角色4
3.4其它系统级角色4
3.5用户、角色及其权限管理4
四、登陆期间的口令安全5
五、Oracle数据库默认用户管理6
六、安全审计8
6.1登陆审计8
6.2操作审计9
6.3对象审计9
七、结论10
一、引言
数据库安全是系统安全的一个重要方面。
Oracle安全管理是如何进行的?
用户、角色及其权限是如何管理和分配的?
Oracle安装后,会建立几个默认用户,这些用户都是干什么的?
如何进行安全审计的?
对于这些问题,本文将给出答案。
数据库安全性问题一直是围绕着数据库管理员的噩梦,数据库数据的丢失以及数据库被非法用户的侵入使得数据库管理员身心疲惫不堪。
围绕数据库的安全性问题提出了一些安全性策略,希望对数据库管理员有所帮助。
对于数据库数据的安全问题,数据库管理员可以参考有关系统双机热备份功能以及数据库的备份和恢复的资料。
二、Oracle安全性能
2.1合法用户的帐户安全性
要访问一个Oracle数据库中的数据,必须先是访问该数据库的一个帐户。
这个访问可以是直接访问—通过到一个数据库的用户连接—或间接访问。
间接连接访问包括通过在数据库链接中预设权限的访问。
每个帐户必须有一个与其相关的口令。
一个数据库帐户也可以连接到一个操作系统帐户上。
2.2数据库对象的访问安全性
对数据库中一个对象的访问是通过权限(privilege)来完成的。
可以通过grant命令向特定帐户分配访问权限,也可以创建角色(role即权限组)来简化权限的管理。
由于角色可以用口令保护且能被动态地允许和禁止,所以它们给数据库增加了一个附加安全层。
2.3管理全局权限的系统级安全性
可以使用角色来管理对用户有效的系统级命令。
这些命令包括createtable和alterindex等,对于每种数据库对象的操作都是由各自的权限授权的。
例如,一个用户可以被授予CREATETABLE权限,而不是CREATETYPE权限。
可以创建一些自定义的系统级角色,这些角色只向用户授予他们在数据库中所需的权限而不是过多的特权。
CONNECT和RESOURCE角色分别是最终用户和开发人员所要求的基本系统权限。
具有RESOURCE角色的用户还被授予UNLIMITEDTABLESPACE系统权限,使他们在数据库的任何地方都能创建对象。
由于有这个附加权限,所以应限制把RESOURCE角色用于开发和测试环境。
三、Oracle系统级角色
可以使用系统级角色分派以管理数据库的系统级命令。
可以创建自定义的系统级角色或使用数据库自带的角色。
Ocacle8i提供了如下的系统级角色:
3.1CONNECT角色
CONNECT角色不只给予用户能够在数据库中创建会话的权限。
除了CREATESESSION系统权限外,CONNECT角色还给予用户以下权限:
ALTERSESSION、CREATECLUSTER、CREATEDATABASELINK、CREATESEQUENCE、CREATESYNONYM、CREATETABLE和CREATEVIEW等。
然而,用户不具有创建表和簇的能力(这些对象都会占用数据库空间),除非授予用户相应的表空间定额,或被授予RESOURCE角色(在下面讨论)。
通常CONNECT角色已能够满足所有环境中的最终用户。
对于某些开发人员,它也可能满足需求。
例如,如果开发人员并不需要创建诸如进程、包、触发器及各种抽象数据类型等数据库对象,那么CONNECT角色就可以满足他的需要。
如果希望限制应用程序用户的系统权限,可以创建角色APPLICATION_USER——使它只具有CREATESESSI0N权限
3.2RESOURCE角色
RESOURCE角色具有以下系统权限:
CREATECLUSTER、CREATEINDEXTYPE、CREATEOPERATOR、CREATEPROCEDURE、CREATESEQUENCE、CREATETABLE、CREATETRIGGER和CREATETYPE。
具有RESOURCE角色的用户还被授予UNLIMITEDTABLESPACE权限,因此这些用户可超越为他们定义的空间定额。
应该把RESOURCE角色授那些需要创建进程和触发器等PL/SQL对象的开发人员。
如果开发人员使用了ObjectsOption(对象选项),RESOURCE角色将给予他们CREATETYPE权限,该权限允许他们创建和执行类型和方法。
如果想要限制开发人员的权限,可以创建自己的角色并授予它某些系统级权限。
例如,可以限制开发人员创建表和簇的能力,而允许他们创建索引和过程对象。
在这种情况下,便可以创建系统级角色并授予它RESOURCE角中除被拒绝的权限之外的所有系统级权限。
通常,只须在开发阶段授予开发人员RESOURCE角色,而在测试和产品阶段,CONNECT角色就足够了。
如果给予开发人员对产品数据库的RESOURCE访问权,你就将失去对数据库的控制并对你实施改动控制过程的能力有重大影响。
3.3DBA角色
DBA角色拥有带withadminoption的所有系统权限,withadminoption意味着DBA可以授予其他用户系统权限。
在任何开发、测试、产品数据库中,不应授予用户或开发人员DBA角色。
如果在开发中授予了开发人员DBA角色,那么在应用程序交付给产品环境时,开发人员将假设他们仍拥有相同的系统权限而编制他们的应用程序。
如果不能严格限定DBA权限帐号的访问,那么也就不能保证数据库中数据的安全,而这是DBA人员的一项重要任务。
3.4其它系统级角色
当执行整个数据库的导入或导出操作时,在导出和导入期间分别使用IMP_FULL_DATABASE和EXP_FULL_DATABASE角色。
这些角色是DBA角色的一部分,可以使用这些角色授予用户有限的数据库管理权限。
SELECT_CATALOG_ROLE、EXECUTE_CATALOG_ROLE和DELETE_CATALOG_ROLE角色,DELETE_CATALOG_ROLE是这三种角色中最简单的角色。
如果授予用户这个角色,该用户就可以从SYS.AUD$表中删除记录(SYS.AUD$表是写审计记录的表)。
给一个用户授予这个角色,该用户不再需要其他DBA级命令就能从审计跟踪表中删除记录。
使用这种角色可以简化审计跟踪管理进程。
SELECT_CATALOG_ROLE和EXECUTE_CATALOG_ROLE角色授予用户选择或执行可导出的数据字典对象的权限。
不是每个数据库对象在整个系统导出时都要被导出,例如动态性能视图就不导出。
因此,SELECT_CATALOG_ROLE不给予用户从动态性能表中选择的能力,而是给予用户从大多数数据字典中查询的能力。
同样,EXECUTE_CATALOG_ROLE给予用户执行数据字典中部分过程和函数的能力。
3.5用户、角色及其权限管理
建立一个用户,创建一个安全、有用的帐户,并且这个帐户要有充分的权限和正确的缺省设置值。
可以使用createuser命令来创建一个新的数据库帐户。
该帐户创建后,在授权前它没有任何效力,用户甚至不能注册。
四、登陆期间的口令安全
当从一个客户机连接到数据库服务器,或者通过数据库链接从一个数据库连接到另一个数据库时,除非指定其他形式,否则Oracle将以非加密的形式传输输入的口令。
对于Oracle8,可以设置参数来强制Oracle在传输前将口令值加密。
若要启用口令加密,需设置以下参数:
对于客户机,把sqlnet.ora文件中的ORA_ENCRYPT_LOGIN参数设为TRUE
对于服务器,把init.ora文件中的DBLINK_ENCRYPT_LOGIN参数设为TRUE
一旦这些参数被设置(并且关闭和重新启动数据库),口令将以加密的形式在客户机到服务器和服务器到服务器之间传送。
五、Oracle数据库默认用户管理
ORACLE数据库创建的时候,创建了一系列默认的用户和表空间,以下是它们的管理方案(用户名/密码):
SYS/CHANGE_ON_INSTALL或INTERNAL
功用:
系统用户,数据字典所有者,超级权限所有者(SYSDBA)
创建脚本:
$oracle_home/rdbms/admin/sql.bsq和cat*.sql
使用建议:
该用户不能被删除,创建后应立即修改密码
SYSTEM/MANAGER
功用:
数据库默认管理用户,拥有DBA角色权限
创建脚本:
$oracle_home/rdbms/admin/sql.bsq
使用建议:
该用户不能被删除,创建后应立即修改密码
OUTLN/OUTLN
功用:
优化计划的存储大纲用户
创建脚本:
$oracle_home/rdbms/admin/sql.bsq
使用建议:
该用户不能被删除,建议创建后应立即修改密码
SCOTT/TIGER,ADAMS/WOOD,JONES/STEEL,CLARK/CLOTH和
BLAKE/PAPER
功用:
实验、测试用户,含有例表EMP与DEPT等
创建脚本:
$oracle_home/rdbms/admin/utlsampl.sql
使用建议:
该类用户可以被删除,在产品环境建议删除或锁定,可以修改密码
HR/HR(HumanResources),OE/OE(OrderEntry),SH/SH(SalesHistory)
功用:
实验、测试用户,含有例表EMPLOYEES与DEPARTMENTS等
创建脚本:
$oracle_home/demo/schema/mksample.sql
使用建议:
该类用户可以被删除,在产品环境建议删除或锁定,可以修改密码
DBSNMP/DBSNMP
功用:
负责运行Oracle系统的智能代理
创建脚本:
$oracle_home/rdbms/admin/catsnmp.sql
使用建议:
需要修改密码--放置新密码到snmp_rw.ora文件,如果不需要
IntelligentAgents,可以删除
CTXSYS/CTXSYS
功用:
OracleinterMedia管理用户
创建脚本:
$oracle_home/ctx/admin/dr0csys.sql
使用建议:
可选安装用户,若不需要,可不安装
TRACESVR/TRACE
功用:
Oracle跟踪服务用户
创建脚本:
$oracle_home/rdbms/admin/otrcsvr.sql
使用建议:
可选安装用户,若不需要,可不安装
ORDPLUGINS/ORDPLUGINS和ORDSYS/ORDSYS
功用:
ObjectRelationalData(ORD)UserusedbyTimeSeries
创建脚本:
$oracle_home/ord/admin/ordinst.sql
使用建议:
可选安装用户,若不需要,可不安装
DSSYS/DSSYS
功用:
OracleDynamicServicesandSyndicationServer
创建脚本:
$oracle_home/ds/sql/dssys_init.sql
使用建议:
可选安装用户,若不需要,可不安装
MDSYS/MDSYS
功用:
OracleSpatial管理用户
创建脚本:
$oracle_home/ord/admin/ordinst.sql
使用建议:
可选安装用户,若不需要,可不安装
六、安全审计
Oracle数据库具有审计发生在其内部的所有操作的能力。
审计记录可以写入SYS.AUD$表或操作系统的审计跟踪中。
使用操作系统审计跟踪的能力依赖于操作系统。
有三种不同的操作类型可以被审计:
登录企图、对象访问和数据库操作。
若要允许在一个数据库中进行审计,数据库的init.ora文件必须含有AUDIT_TRAIL参数的条目。
AUDIT_TRAIL值为:
NONE:
禁止审计
DB:
启用审计,写入SYS.AUD$表
OS:
启用审计,写入操作系统的审计跟踪(依赖于操作系统)
无论是否设置AUDIT_TRAIL参数,都可以发出以下几节描述的audit命令。
除非使用启用审计的AUDIT_TRAIL值启动数据库,否则它们将不被激活。
如果选择把审计记录存储在SYS.AUD$表中,这个表的记录就应当定期归档,然后表也应被截断。
由于它是在数据字典中,所以该表在SYSTEM表空间中。
如果其记录不进行定期清理就会引起空间问题。
可以给用户授予DELETE_CATALOG_ROLE权限,使其能在SYS.AUD$表中进行删除操作。
6.1登陆审计
每个连接数据库的企图都可被审计。
开始审计登录企图的命令为:
auditsession;
若只是审计成功或失败的连接企图,可使用下列命令之一:
auditsessionwheneversuccessful;
auditsessionwhenevernotsuccessful;
若要禁止会话审计,可使用noaudit命令
noauditsession;
如果审计记录存储于SYS.AUD$表中,这时就可以通过DBA_AUDIT_SESSION数据字典视图来查看该表。
【示例】进行连接失败的审计测试:
1、修改init.ora文件的AUDIT_TRAIL为AUDIT_TRAIL=DB,以将审计记录写入SYS.AUD$表
2、SQL>SHUTDOWNIMMEDIATE;--关闭数据库
3、SQL>STARTUP;--打开数据库
4、SQL>auditsessionwhenevernotsuccessful;--开启审计
5、SQL>CONNsss/hhh--测试
6、SQL>select*fromSYS.AUD$;--查看审计记录,就能看到USERID等于sss的行
7、SQL>noauditsession;--停止审计
6.2操作审计
影响数据库对象(如一个表、数据库链接、表空间、同义词、回滚段、用户或索引)的任何操作都可被审计。
影响对象的可能操作(如create、alter和drop)可以在审计时编成组。
这些命令组可以减少建立和维护审计设置值所需管理工作量。
可以审计所有系统级命令并提供命令组。
例如,若要审计影响角色的所有命令,可输入命令:
auditrole;
若要禁止这个设置值,可输入命令:
noauditrole;
6.3对象审计
除了系统级的对象操作外,还可以审计对象的数据处理操作。
这些操作可能包括对表的选择、插入、更新和删除操作。
这种操作类型的审计方式与前节所描述的操作审计非常相似。
但对象审计附加了一个bysession或byaccess的新子句。
这个子句指定一个审计记录是为每个会话(bysession)写入一次,还是每次访问对象(byaccess)时都写入一次。
例如,如果一个用户对同一个表执行四次不同的更新语句操作,那么byaccess审计就会出现四个审计记录—每次访问表都审计一次。
而用bysession审计同样的情况,只会有一个审计记录。
byaccess审计会动态地增加审计记录。
所以,它通常只是有限地用在判断在一个指定时间间隔中所发生的独立操作数量;测试做完后,审计应恢复到bysession状态。
七、结论
我们在实践中发现,可以采用另一种方式利用角色功能,来防止上面出现的安全“漏洞”。
在这种方式下,用户采用自己的标识和口令注册,但在未得到授权的角色前,是没有操纵数据库的任何权限。
而授权用户使用的角色是埋在应用程序中的,只有应用程序才知道角色的名称和口令,从而激活角色,使用户拥有相应的权限。
在应用系统之外,用户可以连接到Oracle,但没有激活相应的角色,他是不能做任何事情的,而开发人员不知道用户的标识和口令,他没有办法登录到Oracle,即使他能够推算出角色的标识和口令。
在实际应用中,许多系统往往采用假用户(即非数据库用户)身份来管理,而真实用户的身份和登录口令就隐藏在应用系统中,或经过各种压缩加密等处理的配置文件中。
但这样往往留下隐患,只要从分析应用程序入手,最终会分析出系统使用的数据库用户和口令,那么其安全性也就消失了。
另一方面,系统代码是程序员写出来的,如果程序员有破坏意图,这种模式没有一丝的安全,因为他通过自己掌握的代码不经分析就轻而易举的获得登录用的数据库用户和口令。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- ORACLE 安全管理 数据库 设计 开发 中的 应用 研究