广工数据库实验报告数据库安全性.docx
- 文档编号:24317980
- 上传时间:2023-05-26
- 格式:DOCX
- 页数:42
- 大小:2.17MB
广工数据库实验报告数据库安全性.docx
《广工数据库实验报告数据库安全性.docx》由会员分享,可在线阅读,更多相关《广工数据库实验报告数据库安全性.docx(42页珍藏版)》请在冰豆网上搜索。
广工数据库实验报告数据库安全性
实验四数据库安全性
一实验目的
1.加深对数据安全性的理解。
2.研究具体DBMS提供的安全性技术并实践。
二实验平台
操作系统:
Windows7-64位
数据库软件:
SQLServer2008
三实验准备
研究具体DBMS所支持的安全性技术。
并综述下列内容:
1.数据库安全性概念
数据库的安全性是指保护数据库以防止不合法的使用所造成的数据泄露、更
改或破坏。
2.具体DBMS的数据库安全性措施
数据库的安全一直是广大用户密切关注的一个问题,现有数据库安全主要通
过九个措施来实现:
包括用户标识和鉴定、存取控制问题、定义视图、数据
加密、多级保护体制、限界、对象重用、审计和日志、攻击检测等
四实验内容及要求
实践具体DBMS所支持的安全性技术
1.用户、权限和角色机制实践
当用户登录数据库系统时,如何确保只有合法的用户才能登录到系统中?
这是一个最基本的安全性问题,也是数据库管理系统提供的基本功能。
在MicrosoftSQLServer2008系统中,通过身份验证模式和主体解决这个问题。
(1)身份验证模式
MicrosoftSQLServer2008系统提供了两种身份验证模式:
Windows身份验证模式和混合模式。
Windows身份验证模式:
在该模式中,用户通过Windows用户账户连接SQLServer时,使用Windows操作系统中的账户名和密码。
混合模式:
在混合模式中,当客户端连接到服务器时,既可能采取Windows身份验证,也可能采取SQLServer身份验证。
(2)主体
主体是可以请求系统资源的个体或组合过程。
SQLServer2008系统有多种不同的主体,不同主体之间的关系是典型的层次结构关系,位于不同层次上的主体其在系统中影响的范围也不同。
位于层次比较高的主体,其作用范围比较大;位于层次比较低的主体,其作用范围比较小。
Windows级别的主体
∙Windows域登录名
∙Windows本地登录名
SQLServer级的主体
∙SQLServer登录名
数据库级的主体
∙数据库用户
∙数据库角色
∙应用程序角色
SQLServersa登录名
SQLServersa登录名是服务器级的主体。
默认情况下,该登录名是在安装实例时创建的。
在SQLServer2005和SQLServer2008中,sa的默认数据库为master。
这是对早期版本的SQLServer的行为的更改。
public数据库角色
每个数据库用户都属于public数据库角色。
当尚未对某个用户授予或拒绝对安全对象的特定权限时,则该用户将继承授予该安全对象的public角色的权限。
INFORMATION_SCHEMA和sys
每个数据库都包含两个实体:
INFORMATION_SCHEMA和sys,它们都作为用户出现在目录视图中。
这两个实体是SQLServer所必需的。
它们不是主体,不能修改或删除它们。
基于证书的SQLServer登录名
名称由双井号(##)括起来的服务器主体仅供内部系统使用。
关于服务器登录名,服务器角色,数据库用户,数据库角色,数据库架构的关系:
登录名一定属于某些角色,默认为public。
数据库用户对应于服务器登录名以便登录者可以操作数据库。
根据权限需求可把数据库用户划分为一个数据库角色。
数据库用户和数据库角色均持有数据库架构。
数据库架构,类似于数据库对象的命名空间,用户通过架构访问数据库对象。
关系图更加清晰:
实验用例:
SQLServer的用户和权限机制实践步骤:
1.以系统管理员的身份登录到SQLServer
2.创建数据库用户user1
在创建数据库用户之前,了解到用户名和登录名是一对一的关系。
即一个用户对
应一个登陆名,同样一个登陆名也是对应一个用户名,这里假设数据库用户user1对应
登陆名zhangfaguang,这里并没有指定default_schema,默认使用dbo作为架构。
数据库用户由登录名映射而来,直接在数据库中创建用户而不指定登录名是无法通过
的。
如图:
所以先创建一个登录:
createloginzhangfaguangwithpassword='123456'
然后创建数据库用户user1:
createuseruser1forloginzhangfaguang
此外,若有要求把默认架构设置为schema_3110006015,则:
createuseruser1forloginzhangfaguangwithdefault_schema=schema_3110006015
企业管理器:
进入安全性,新建登录名,然后设置登录名和密码。
企业管理器:
进入数据库,右击安全性,找到用户,右键选择新建用户
用户、登陆、架构的三者关系:
user1是登陆zhangfaguang的一个用户,
user1的默认架构为dbo(实验四-安全性数据库)
3.分别通过SQLServer的工具和SQL语言授予数据库用户user1在学生课程数据库上的CREATETABLE权限
SQL语句:
grantcreatetabletouser1
企业管理器:
找到要设置语句权限的数据库,即实验四-安全性数据库。
如图:
然后单击右键,进入属性,打开“权限”,把创建表的“授予”框格打上勾。
权限测试:
createtabletest_create
(
test_snochar(10)
)
执行结果:
成功生成test_create表。
4.分别通过SQLServer的工具和SQL语言授予数据库用户user1在Student表上的SELECT、DELETE权限
SQL语句:
grantselectonstudenttouser1
grantdeleteonstudenttouser1
企业管理器:
进入【实验四-安全性】数据库,右击安全性,右键用户选择属性,添加安全对象。
然后搜索dbo架构的所有对象。
最后把授予的选择和删除权勾上即可。
5.以user1的身份登录SQLServer,选择Student表,分别进行SELECT和INSERT操作,对比操作结果。
刚开始无法登录:
查阅了关于错误信息的提示发现是服务器身份验证未开启混合登录模式。
修改之后要
重启SQL服务才可以使修改生效,重启电脑之后解决了这个问题。
SELECT权限验证:
select*fromstudent
执行结果:
查询成功。
还可以尝试检索未授权查询Course表的内容。
select*fromcourse
执行结果:
系统拒绝执行。
INSERT权限验证:
insertintostudent(sno,sname,sex,sage,sdept)
values('s5','Lambo','男','23','IS')
执行结果:
系统拒绝执行。
DELETE权限验证:
deletefromstudentwheresno='s2'
执行结果:
成功删除对应元组
删除前后对比图:
还可以尝试删除未授权的Course表的元组
deletefromcoursewherecno='c2'
执行结果:
系统拒绝删除
6.收回授予user1的相关权限
收回用户user1在Student表上的SELECT、DELETE权限
revokeselect,deleteonstudentfromuser1
权限检测:
select*fromstudent
执行结果:
系统拒绝执行。
deletefromstudentwheresno='s3'
执行结果:
系统拒绝执行。
角色机制:
1、固定服务器角色
固定服务器角色是服务器级别的主体,它们的作用范围是整个服务器。
固定服务器角色已经具备了执行指定操作的权限,可以把其他登录名作为成员添加到固
定服务器角色中,这样该登录名可以继承固定服务器角色的权限。
SQLServer2008的服务器角色:
2、数据库角色
三种类型的数据库角色:
固定数据库角色:
微软提供的作为系统一部分的角色;
用户定义的标准数据库角色:
由用户自己定义的角色,将Windows用户以一组自义
权限分组;
应用程序角色:
用来授予应用程序专门的权限,而非授予用户组或者单独用户。
1)固定数据库角色
2)用户自定义数据库角色
在实验四-安全性数据库角色中新建一个数据库角色test_role。
上面是运用企业管理器的可视化操作直接创建了数据库角色,这里同样可以用SQL语句
实现。
SQL语句:
createroletest_role2
执行结果:
成功生成对应的数据库角色。
创建了角色后,我们可以给角色授权。
操作权限包括:
授予权限(GRANT):
授予权限以执行相关的操作。
通过角色,所有该角色的成员继承此权限。
撤销权限(REVOKE):
撤销授予的权限,但不会显示阻止用户或角色执行操作。
用户或角色仍然能继承其他角色的GRANT权限。
拒绝权限(DENY):
显式拒绝执行操作的权限,并阻止用户或角色继承权限,该语句优先于其他授予的权限。
关于角色权限的操作案例(均在“实验四-安全性”数据库操作):
1、授予角色“test_role”对”数据库-安全性”数据库中“student”表的delete、insert、
update权限。
SQL语句:
grantdelete,insert,update
onstudent
totest_role
执行结果:
命令成功完成。
当然,我们也可以用企业管理器的可视化操作执行,首先找出角色test_role,然后右键
选择进入属性,打开安全对象,找到Student表,最后授予相应的权利。
2、把用户user1添加到角色test_role中。
SQL语句:
sp_addrolemember'test_role','user1'
企业管理器:
进入角色属性,然后添加角色成员。
3、把角色test_role授予test_role2。
使test_role2具有角色test_role的全部权限。
SQL语句:
granttest_roletotest_role2
这个是教材上的语法,与SQLServer2008有所不同。
改用:
sp_addrolemember'test_role','test_role2'
执行结果:
成功添加。
4、在角色test_role的基础上增加对Student表的SELECT权限并收回DELETE权限。
SQL语句:
grantselectonstudenttotest_role
revokedeleteonstudentfromtest_role
执行结果:
成功增加了SELECT权限和收回了删除权限。
5、拒绝角色test_role对Student表的SELECT,DELETE权限,再让SELECT权限生效。
SQL语句:
denyselect,deleteonstudenttotest_role
grantselectonstudenttotest_role
执行结果:
执行成功。
3、应用程序角色
应用程序角色允许用户为特定的应用程序创建密码保护的角色。
创建一个程序角色:
createapplicationroleapp1withpassword='123456'
企业管理器:
对着“应用程序角色”新建程序角色,输入角色名称、架构和密码即可。
应用程序角色授权与数据据角色授权相同,可参考上面的例子,故不再详细叙述。
2.视图机制实践
视图,简单来说就是一种虚拟表,和真实的数据表一样,视图包含了一系列带有名称的行数据。
视图机制把要保密的数据对无权存取这些数据的用户隐藏起来,从而自动地对数据提供一定程度的安全保护。
视图机制更主要的功能在于提供数据独立性,其安全保护功能太不精细,往往远不能达到应用系统的要求。
在实际应用中通常是视图机制与授权机制配合使用,首先用视图机制屏蔽掉一部分保密数据,然后在视图上面再进一步定义存取权限。
这时视图机制实际上间接实现了支持存取谓词的用户权限定义。
实验案列:
建立IS系所开设的课程的视图,把对该视图的SELECT和UPDATE权限授予用户user1,
把所有权限授予user1。
建立视图:
createviewIS_course
as
select*
Fromcourse
wherecdept='IS'
执行结果:
成功生成视图。
授予权限:
grantselect,updateonIS_coursetouser1
执行结果:
成功授权。
grantallprivilegestouser2
执行结果:
ALL权限已不再推荐使用,并且只保留用于兼容性目的。
它并不表示对实
体定义了ALL权限。
(SQLSERVER2008不允许SQL语句赋值全部授权)
解决方法:
运用企业管理器的可视化操作,把所要授予的权限打勾即可。
权限验证:
用户user1登录zhangfaguang。
然后查询和修改“数据库-安全性”数据库的视图IS_course的数据。
查询:
select*fromIS_course
执行结果:
命令执行成功。
验证结果:
用户uer1拥有了对视图IS_course的查询权限。
更改:
已知C1课程的学分为4,把这门课的学分修改成5。
updateIS_coursesetcredit=5wherecno='c1'
执行结果:
(1行受影响)
验证结果:
用户uer1拥有了对视图IS_course的更新权限。
收回用户user1的对视图IS_course的SELECT权限。
回收权限:
revokeselectonIS_coursefromuser1
执行结果:
命令已成功完成
回收权限验证:
用户user1登录zhangfaguang,然后查询“数据库-安全性”数据库的
视图IS_course的数据。
select*fromIS_course
执行结果:
拒绝了对对象'IS_course'(数据库'实验四-安全性',架构'dbo')的SELECT权
限。
验证结果:
成功收回uer1对视图IS_course的查询权限。
3.数据加密实践
加密是指通过使用密钥或密码对数据进行模糊处理的过程。
在SQLServer中,加密并不能替代其他的安全设置,比如防止未被授权的人访问数据库或是数据库实例所在的Windows系统,甚至是数据库所在的机房,而是作为当数据库被破解或是备份被窃取后的最后一道防线。
通过加密,使得未被授权的人在没有密钥或密码的情况下所窃取的数据变得毫无意义。
SQLServer2008中引入了透明数据加密(TDE),所谓的透明数据加密,就是加密在数据库中进行,但从程序的角度来看就好像没有加密一样,和列级加密不同的是,TDE加密的级别是整个数据库。
使用TDE加密的数据库文件或备份在另一个没有证书的实例上是不能附加或恢复的。
数据加密一般分为两大类,对称加密和非对称加密。
对称加密是那些加密和解密使用同一个密钥的加密算法。
非对称加密是指加密和解密使用不同密钥的加密算法,用于加密的密钥称之为公钥,用于解密的密钥称之为私钥。
由于SQLServer的加密机制比较复杂,为了方便理解,这里先介绍SQLServer中的加密层次结构。
如图:
从上图可以获取以下几点重要信息:
1、在SQLServer中,加密是分层级的.根层级的加密保护其子层级的加密。
2、每一个数据库实例都拥有一个服务主密钥,这个密钥是整个实例的根密钥,在实例安装的时候自动生成,其本身由Windows提供的数据保护API进行保护。
3、在服务主密钥之下的是数据库主密钥,这个密钥由服务主密钥进行加密。
这是一个数据库级别的密钥。
可以用于为创建数据库级别的证书或非对称密钥提供加密。
每一个数据库只能有一个数据库主密钥。
实验案例:
先创建一个数据主密钥:
createmasterkeyencryptionbypassword='123456'
然后使用数据库密钥创建对称密钥,非对称密钥和证书:
创建证书:
createcertificatezhengshu
encryptionbypassword='123456'
withsubject='安全证书',/*证书主题*/
start_date='11/11/2012',/*证书生效日期*/
expiry_date='11/11/2013'/*证书过期日期*/
注意格式:
with后面含多个字句时用逗号分开。
创建对称密钥:
createsymmetrickeyyes_key
withalgorithm=des/*对称加密算法des*/
encryptionbypassword='123456'
注意格式:
create语句先连接加密算法再附上密码。
创建非对称密钥:
createasymmetrickeynot_yes_key
withalgorithm=rsa_1024/*非对称加密算法rsa_1024*/
encryptionbypassword='123456';
查询企业管理器是否生成对应证书和密钥,如图:
此外,对称密钥不仅可以通过密码创建,还可以通过其它对称密钥,非对称密钥和证书创建。
(从加密层次结构图可看出)
例如:
由证书加密对称密钥:
createsymmetrickeyyes_key
withalgorithm=aes_192
encryptionbycertificatezhengshu;
由对称密钥加密对称密钥
opensymmetrickeyyes_key
decryptionbypassword='123456'
createsymmetrickeyyes_key2
withalgorithm=aes_192
encryptionbysymmetrickeyyes_key;
注意:
用对称密钥A加密对称密钥B时要先打开A,然后A再加密B。
由非对称密钥加密对称密钥:
createsymmetrickeyyes_key
withalgorithm=aes_192
encryptionbyasymmetrickeynot_yes_key;
SQLServer中的数据列加密:
SQLServer在2005引入了列加密的功能。
使得可以利用证书,对称密钥和非对称密钥对特定的列进行加密。
在具体的实现上,根据加密解密的方式不同,内置了4对函数用于加密解密:
1、EncryptByCert()和DecryptByCert()
∙利用证书对数据进行加密和解密
2、EncryptByAsymKey()和DecryptByAsymKey()
∙利用非对称密钥对数据进行加密和解密
3、EncryptByKey()和DecryptByKey()
∙利用对称密钥对数据进行加密和解密
4、EncryptByPassphrase()和DecryptByPassphrase()
∙利用密码字段产生对称密钥对数据进行加密和解密
此外,加密或解密的列首先需要转换成Varbinary类型。
已知有QQ信息表一张,现在准备把QQ密码即mima这一列值加密。
如图所示:
解决这个加密问题需要两大步骤,第一步先要实现需要加密的列的类型转换和建立和原表列名相同的空表;第二步则开始往空表导入原表数据,同时对“mima”列加密。
第一步:
由于密码不是Varbinary类型,所以先要将mima列转为Varbinary类型。
通过SelectInto新建QQ信息表,命名为new_qq_xinxi。
selectname,qq,new_mima=CONVERT(varbinary(200),mima)--选择信息和转换类型
intonew_qq_xinxifromqq_xinxiwhere1=0
这里选择使用Selectinto语句是为了方便把qq_xinxi表的列名导入新表,同时把需要加密的列即mima列的类型转换为Varbinary类型。
而where字句的作用是不导入旧表的数据信息,纯属建立只含列名的空表。
(即条件where1=0从原表中筛选出0个元组)
第二步:
开始利用对称密钥加密:
--在创建好对称密钥后,使用前必须显式打开,再进行加密操作。
opensymmetrickeyyes_key--yes_key为之前创建的对称密钥
decryptionbypassword='123456'--打开密钥
--利用对称密钥加密数据并插入新建的表
insertnew_qq_xinxi
(
name,
qq,
new_mima
)
selectall
name,
qq,
new_mima=EncryptByKey(KEY_GUID('yes_key'),mima)--把mima列按对称加密方式进行加密。
fromqq_xinxi--从旧表导入其他非加密数据。
执行结果:
(3行受影响)
如图所示:
当然也可以用SQL语句验证密码列是否可被查询到:
select*
fromnew_qq_xinxi
执行结果:
密码列同样显示空值,即无法被查询到。
如图:
上面的两个步骤实现了对密码列的对称加密,当然也可以进行相应解密查询。
解密前同样先打开密钥:
opensymmetrickeyyes_key
decryptionbypassword='123456'
然后解密:
selectname,qq,
new_mima=convert(char(20),decryptbykey(new_mima))
fromnew_qq_xinxi
执行结果:
查询已成功执行。
成功获取了密码明文,如图:
在解密的时候曾多次遇到无法恢复的情况,经分析是由两种情况所致。
一:
解密的时候忘了打开对应的密钥
二:
使用SELECT语句查询的时候,密文转换格式写错。
例如把covert字句中的类型定义写成了密码列的新定义varbinary,把解密键的内容写成mima,导致无法解密。
密文转换其实不难,关键在于理解如何正确使用密钥给对应列加密,还有利用对应的转换函数。
透明数据加密(SQLServer2008的特色加密)
透明数据加密(简称TDE)可对数据和日志文件执行实时I/O加密和解密。
这种加密使用数据库加密密钥(DEK),该密钥存储在数据库启动记录中以供恢复时使用。
DE
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 数据库 实验 报告 安全性
![提示](https://static.bdocx.com/images/bang_tan.gif)