在业界,普遍认为Oracle数据库的安全性要比SQL Server数据库高。下面笔者就来谈谈这两种数据库在安全性设计上面的异同。掌握好这些内容,对于我们进行数据库安全方面的设计与管理,有着举足轻重的作用。
一、角色到用户的授权。
现在很多应用软件,包括数据库系统,都采用了角色到用户的授权体系。也就是说,先给一个角色进行授权,然后再把用户加入到这个角色中,让其拥有这个角色的权限。
如我们在数据库设计的时候,一般至少需要两种角色,一种是系统管理员角色,这种角色具有对数据库系统进行管理,如表的建立与删除、用户的建立与修改等等。另外一种是普通用户的角色,其可以对表进行插入、修改、删除记录等等的操作。然后,我们建立两个帐户,一个是数据库管理员帐户,让其隶属于管理员角色;再建立一个用户帐号,让其归属于用户角色。如此,不用给用户设置特别的权限,他们就从他们的角色中,继承了相关的权限。这就是基于角色-用户的权限管理体系。
这个权限管理体系,两种数据库都是支持的,只不过具体的叫法有差异。
在SQL Sever数据库中,其沿用的是微软操作系统的叫法,把角色称做组。其实,我们在给操作系统定义用户与权限的时候,也是采用这种方法,我们先建立一个组,再给这个组赋予特定的权限,然后,再建立一个用户帐号加入到这个组中即可。虽然两个数据库的叫法不同,但是,其本质是一样的,换汤不换药而已。
两者的差异主要体现在对特定角色的授权方面。
二、角色的授权。
两个数据库虽然在“角色-授权” 方面雷同,但在具体角色权限的分配上,还是有比较大的差异。用一句话来总结,就是Oracle在权限的分配上,要比SQL Server数据库细。Oracle在权限控制方面,基本上可以细化到每个步骤。
如在用户管理上面,Oracle数据库可以把创建用户帐号的权利给某个组,但是,这个组却没有删除帐号的权利。而微软的数据库中,则一般是把用户管理的权限,包括用户创建与删除当作一个权限赋予给某个组,而不能把他们分开。也就是说,一个组若具有用户帐号管理权限的话,其不仅可以创建用户帐号,而且,也可以删除用户帐号。也就是说,微软的SQL Server数据库在权限设计上,没有分得像Oracle那么细。正因为如此,所以Oracle数据库在权限管理上面,要比SQL Server数据库灵活。
不光在帐户管理上如此,数据库很多对象权限的管理,也有类似现象。如对于存储过程的管理,对于表格的管理等等。甲骨文的Oracle数据库在权限划分上,比其他数据库都要细。
三、对用户进行独立授权。
除了可以根据角色进行授权,Oracle数据库还可以在用户帐号的级别上直接跟用户进行授权。在SQL Server数据库上也有类似的功能,但是,光从这方面说,前者要比后者灵活。如Oracle数据库中具有的“ 对象授权”功能,在SQL Server数据库中就无法实现。
1、 在用户口令上,Oracle数据库要比SQL Server数据库安全性更高。
众所周知,用户口令与帐号是数据库安全的第一道保障。如在建立Oracle数据库的用户名的时候,默认情况下,其有密码复杂性验证设置。如果我们在建立用户名的时候,把密码设置成为“123456”,Oracle数据库不会接受。因为它认为纯数字的密码过于简单,容易被破解。而在微软的SQL Server数据库中,默认情况下没有这方面的限制。
2、 用户建立默认权限不同。
这两个数据库都可以至少通过两种方式建立用户名。一是通过图形化的界面建立用户名与帐号。如Oracle数据库可以通过EM,即浏览器建立用户帐号;而SQL Server数据库则可以通过企业管理器建立用户帐号。另外一个是可以通过命令行,也就是说,通过SQL 语句建立用户名。
从SQL Server数据库来说,这两种建立方式没有什么不同。但是,甲骨文的Oracle数据库还是有比较大的差异,主要体现在默认权限的不同。在利用浏览器建立用户帐号的时候,默认就具有连接数据库的权限。而若在命令行中建立用户帐号,除非你明确给其指定其具有连接数据库的权限,否则的话,这个帐户是不能连接到数据库的。
如我们通过命令,建立一个test的用户,其密码为test111。
Create user test identified by test111;
注意 ,这里设置用户名密码的时候,若是纯数字的密码,则数据库不会接受。
然后,我们利用如下语句连接到数据库,看看有什么现象。
Connet test/test111;
此时,数据库会拒绝这个用户登陆到数据库,会提示这个用户没有连接到数据库的权限。除非,我们再利用如下命令,对用户进行授权。
Grant connect to test;
对用户名进行授权后,才能够连接到数据库中去。这一点差异,很多数据库管理员在刚开始接触数据库的时候,特别是先前有SQL Server数据库使用经验的人,一般都不容易搞清楚。结果在学习或者使用的时候,会遇到一些麻烦。笔者因为参加过SQL Server数据库管理员的培训与考试,所以,在后续使用Oracle数据库的时候,对于这一点当时就有点困惑。现在回头想想,Oracle大概是基于安全方面的考虑吧。
3、 对象授权。
假设现在有如下这种情形。
现在有个用户test,其有product表的查询权限。而另外一个用户test1不具有这个表的任何访问权限。现在,test想把product表的查询权限赋予test1,让其也可以查询数据库中的product表。注意,这里的用户test只是普通用户,不是数据库管理员。
这个需求在SQL Server数据库中,是无法实现的,因为用户test没有数据库管理的权限,而只有表查询的权限,其没有权利为其他用户分配这个表的查询权限的权利。但是,在Oracle数据库中,则通过“对象授权” 的方式,可以实现这个需求。
第一步:利用系统管理员帐户,在分配权限的时候,给予“ 对象授权” 的权利。
如先用系统管理员帐户登陆到系统中,然后给用户test查询表product的权利,并启用对象授权模式。具体命令如下:
Grant select on product to test with grant option;
Grant select on product to test就表示用户test具有查询表product的权限;而后面的with grant option则表示对于这个用户开启了“ 对象授权” 的模式。以后,test用户可以把对于表product的查询权限赋予给其他用户。
第二步:利用test用户登陆,然后赋予test1用户表prodcut的查询权限。
Grant select on product to test1;
这个语句就是用户test赋予用户test1表product的查询权利。若我们在给test用户赋予权限的时候,没有启用“对象授权”模式,即没有在后面加入with grant option语句,则在以普通用户test执行这条语句的时候,就会发生错误,提示用户没有这个权限。但是,若我们系统管理员在给test用户分配权限的时候,开启了“对象授权”的模式,则用户test就可以赋予用户test1表查询的权限。不过,这只是针对于特定的表与特定的操作。如果数据库管理员在分配test用户权限的时候,只用了“Grant select on product to test with grant option”这个语句,就表示test用户只能针对表product的查询权限进行再授权。如,现在test1想把表product-bom的查询权限赋予给test1的话,数据库服务器就不允许了,因为其没有这个权利。
这就是对象授权的功能,虽然其破坏了数据库权限管理的统一性,但是,这也提高了数据库权限设计的灵活性,在大型数据库设计的过程中,经常会被用到。
除了对表可以进行对象授权之外,还可以对过程、视图等等也进行对象授权。这里要注意的是,在对象授权的过程中,是需要对每个步骤进行授权。如现在用户test具有表product记录查询、记录更新、记录删除等的权利。但是,其只有表查询权利的“对象授权”。此时,test用户就不能够把这个表的更新、删除等权利赋予给用户test1。因为帐户test对对象进行再授权,只是针对特定的查询操作。
另外,除了对象授权之外,Oracle数据库中还有一个“系统授权”的概念。系统授权跟对象授权类似,只是其针对的是系统管理的权限,如帐户删除或者新建的操作。需要注意的是,系统授权仍然需要分步骤来进行授权。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
相关推荐
-
不安全的Firebase数据库使关键数据面临风险
当开发人员无法对支持其移动应用程序的数据库或云实例执行身份验证时,这里会发生一种最简单且最具破坏性的安全事件。 […]
-
云端SQL Server高可用性最佳做法
与内部部署相比,在云端运行SQL Server可为数据库软件用户提供更多的灵活性和可扩展性,也可能更省钱。但云 […]
-
甲骨文自治数据库亮相 带来云计算新希望
早前甲骨文还不在云计算公司之列,而现在该公司正在迅速弥补其失去的时间。甲骨文的云计算核心是甲骨文自治数据库(O […]
-
2017年12月数据库流行度排行榜 定格岁末排名瞬间
数据库知识网站DB-engines最近更新的2017年12月份数据库流行度排名情况是否能提供更多的看点呢?TechTarget数据库网站将与您分享12月份的榜单排名情况,让我们拭目以待。