920 likes | 1.1k Views
第 7 章 数据库安全与保护. 7.1 数据库的安全性. 7.1.1 数据库安全性的含义 数据库的安全性 是指保护数据库,防止因用户非法使用数据库造成数据泄露、更改或破坏。 安全性问题有许多方面,其中包括七个方面: (1) 法律、社会和伦理方面的问题,例如请求查询信息的人是不是有合法的权力。 (2) 物理控制方面的问题,例如计算机机房是否应该加锁或用其他方法加以保护。. (3) 政策方面的问题,如确定存取原则,允许指定 用户存取指定数据。 (4) 运行方面的问题,如使用口令时,如何使口令保密。
E N D
7.1 数据库的安全性 7.1.1 数据库安全性的含义 • 数据库的安全性是指保护数据库,防止因用户非法使用数据库造成数据泄露、更改或破坏。 • 安全性问题有许多方面,其中包括七个方面: (1)法律、社会和伦理方面的问题,例如请求查询信息的人是不是有合法的权力。 (2)物理控制方面的问题,例如计算机机房是否应该加锁或用其他方法加以保护。
(3)政策方面的问题,如确定存取原则,允许指定 用户存取指定数据。 • (4)运行方面的问题,如使用口令时,如何使口令保密。 • (5)硬件控制方面的问题,如CPU是否提供任何安全性方面的功能。
(6)操作系统安全性方面的问题,如在主存储器和数据文件用过以后,操作系统是否把它们的内容清除掉。 • (7)数据库系统本身的安全性方面的问题。本章主要讨论的就是数据库系统本身的安全性问题,主要考虑安全保护的策略,尤其是控制访问的策略。
用户 DBMS OS DB 7.1.2 数据库安全控制的一般方法 • 安全性控制就是要尽可能地杜绝所有可能的数据库非法访问,不管它们是有意的还是无意的。 用户标识和鉴别 存取控制 操作系统安全保护 密码存储 图7.1 计算机系统的安全模型
(1)用户标识和鉴定 用户标识和鉴定(Identification & Authentication)是系统提供的最外层安全保护措施。标识和鉴定一个用户最常用的方法是用一个用户名或用户标识号来标明用户身份,通过用户名和口令来鉴定用户的方法简单易行,但用户名与口令容易被人窃取,因此还可以用更复杂的方法。例如,利用用户的个人特征。
(2)存取控制 数据库系统中,为了保证用户只能访问他有权存取的数据,必须预先对每个用户定义存取权限。存取权限是由两个要素组成的:数据对象和操作类型。在数据库系统中,定义存取权限称为授权(Authorization)。衡量授权机制是否灵活的一个重要指标是授权粒度,即可以定义的数据对象的范围。授权粒度越细,授权子系统就越灵活,能够提供的安全性就越完善。
(3)视图机制 关系数据库系统中,就是为不同的用户定义不同的视图,通过视图机制把要保密的数据对无权存取这些数据的用户隐藏起来,从而自动地对数据提供一定程度的安全保护。
(4)审计 审计功能是一种监视措施,它跟踪记录有关数据的访问活动。审计功能一般主要用于安全性要求较高的部门。 (5)数据加密 数据加密是防止数据库中的数据在存储和传输中失密的有效手段。加密方法主要有两种:替换方法和置换方法.
7.1.3 SQL Server的用户与安全性管理 Microsoft SQL Server 的安全性是非常牢靠的,任何用户企图访问数据库中的数据之前,必须要通过四道关卡,图 7.2表示出了这四个环节。
用户登录请求 NT 操作系统 SQL Server数据库服务器 数据库对象 SQL Server数据库 图7.2 SQL Server的四个环节
1.进入Microsoft SQL Server服务器 • Microsoft SQL Server有两种鉴别模式: Windows NT/2000鉴别和Microsoft SQL Server鉴别。 2. 访问Microsoft SQL Server数据库 • 一般来说,访问Microsoft SQL Server数据库需经过以下三个步骤:
在Microsoft SQL Server服务器上建立服务器登录标识。 • 在数据库中建立用户帐号、角色并设置用户访问权限。 角色是数据库访问权限的管理单位,其成员继承角色的访问权限。 角色共分两种:服务器角色和数据库角色。
服务器角色负责整个Microsoft SQL Server服务器的访问权限,而数据库角色只负责某个数据库的访问权限。数据库角色可再往下分为三类:固定数据库角色、公共角色和自定义数据库角色,而服务器角色只包含固定服务器角色。
①固定服务器角色 • SYSTEM ADMINISTRATORS(sysadmin):该角色权限最大,能执行任何操作,包括否决其他固定服务器角色。 • DATABASECREATORS (dbcreator):该角色能创建和修改数据库。 • DISK ADMINISTRATORS (diskadmin):该角色负责管理磁盘文件。 • PROCESS ADMINISTRATORS(processadmin):该角色管理运行在Microsoft SQL Server上的不同进程。 • SECURITY ADMINISTRATORS(securityadmin):该角色管理服务器注册。 • Server ADMINISTRATORS(Serveradmin):该角色设置服务器配置。 • SETUP ADMINISTRATORS(setupadmin):该角色安装Microsoft SQL Server同步复制和管理扩展过程。
②固定数据库角色 • DATABASE OWNER (db_owner):该角色拥有某个数据库的所有权限,能执行其他数据库角色的操作。 • DATABASE ACCESSADMINISTRATOR(db_accessadmin):该角色管理某个数据库的用户帐号。 • DATABASE SECURITY ADMINISTRATOR(db_securityadmin):该角色管理数据库的用户帐号和角色以及语句和对象权限。 • DATABASE BACKUPOPERATOR(db_dumpoperator):该角色负责备份数据库的工作。
③公共角色 每一个数据库都有一个公共角色,每创建一个新的用户帐号时,此帐号自动拥有该角色。不能对该角色添加或修改用户帐号,对其唯一的操作是为它分配权限。 ④自定义数据库角色 自定义数据库角色同固定数据库角色一样,管理多个用户的相同权限。
⑤应用程序角色 该角色不分配给任何用户,而是分配给某一个运行在Microsoft SQL Server上的应用程序。 设置应用程序角色的原因有两点: 一是限制访问数据库所使用的应用程序; 二是提高Microsoft SQL Server服务器的运 行性能,避免在此服务器上运行其他程序。
(3) 设置语句和对象权限 用户可获得的权限主要有: ①对象权限 • 元组:SELECT、UPDATE • 视图:SELECT、UPDATE、DELETE、INSERT • 存储过程:EXECUTE
②语句权限 • 创建数据库:CREATE DATABASE • 创建关系属性的默认值:CREATE DEFAULT • 创建存储过程:CREATE PROCEDURE • 创建关系中属取值性规则:CREATE RULE • 创建视图:CREATE VIEW • 备份数据库:BACKUP DATABASE • 备份事务日志:BACKUP TRANSACTION
3. 安全性控制命令 (1)增加SQL Server用户 可以执行系统存储过程sp_add1ogin,它的格式 如下: Sp_addloginlogin_id[,passwd[,defdb[,deflanguage]]] (2) 增加数据库用户 sp_adduser login_id[,username[,grpname]] (3) 创建用户组 sp_addgroup grpname (4) 用户口令 sp_password old_passwd ,new_passwd[,login_id]
7.2完整性控制 7.2.1数据库完整性的含义 • 数据库的完整性是指数据的正确性、有效性和相容性,防止错误的数据进入数据库造成无效操作。
数据的完整性与安全性是数据库保护的两个不同方面。安全性是防止用户非法使用数据库,包括恶意破坏数据和越权存取数据。完整性则是防止合法用户使用数据库时向数据库中加入不合语义的数据。也就是说,安全性措施的防范对象是非法用户和非法操作,完整性措施的防范对象是不合语义的数据。数据的完整性与安全性是数据库保护的两个不同方面。安全性是防止用户非法使用数据库,包括恶意破坏数据和越权存取数据。完整性则是防止合法用户使用数据库时向数据库中加入不合语义的数据。也就是说,安全性措施的防范对象是非法用户和非法操作,完整性措施的防范对象是不合语义的数据。
7.2.2 完整性规则的组成 完整性规则主要由以下三部分构成: (1)触发条件:规定系统什么时候使用规则来检查数据。 (2)约束条件:规定系统检查用户发出的操作请求违背了什么样的完整性约束条件。 (3)违约响应:规定系统如果发现用户的操作请求违背了完整性约束条件,应该采取一定的动作来保证数据的完整性,即违约时要做的事情。
根据完整性检查的时间不同,可把完整性约束分为立即执行约束(Immediate Constraints)和延迟执行约束(Deferred Constraints)。 • 一条完整性规则可以用一个五元组(D,O,A,C,P)来形式化地表示。其中:
·D(data)代表约束作用的数据对象; • ·O(operation)代表触发完整性检查的数据库操作,即当用户发出什么操作请求时需要检查该完整性规则,是立即检查还是延迟检查; • ·A(assertion)代表数据对象必须满足的断言或语义约束,这是规则的主体; • ·C(condition)代表选择A作用的数据对象值的谓词; • ·P(procedure)代表违反完整性规则时触发执行的操作过程。
7.2.3 完整性约束条件的分类 • 完整性约束从约束条件使用的对象分为值的约束和结构的约束。值的约束即对数据类型、数据格式、取值范围和空值等进行规定。 • 完整性约束从约束对象的状态分为静态约束和动态约束。
7.2.4 触发器(Trigger) 1. 触发器组成 (1)事件:指对数据库进行的插入、删除、修改等操作。触发器可以响应这些事件,在适合的条件及恰当的时间内执行指定的动作。 (2)条件:触发器测试给定的条件,若条件成立,则执行相应的动作,否则什么也不执行。 (3)动作:动作是一系列的操作,这些操作可以撤消触发器发生的事件,可以是与事件相关的操作,也可以是与事件无关的其他操作。
2. 触发器的作用 • 触发器的主要作用是实现由主码和外码所不能保证的、复杂的参照完整性和数据的一致性 • 触发器还有其他许多不同的功能: (1) 强化约束(Enforce Restriction)。 (2) 级联操作 (Cascaded Operation)。 (3) 存储过程的调用(Stored Procedure Invocation)。
3. 触发器类型 从触发的元组来分有语句级触发器和元组级触发器。前者可以在语句执行前或执行后被触发,后者在每个触发语句影响的元组触发一次。 从触发的时间来分还有Before和After的两种形式,分别在Insert、update及delete之前或之后执行。 Microsoft SQL Server支持两种触发器:After触发器与Instead of触发器。
下面以SQL Server 2000为例,介绍用 Transact-SQL 定义触发器的方法。 定义触发器的基本语法: CREATE TRIGGER〈触发器名〉 ON {〈表名〉 | 〈视图名〉} {FOR|AFTER|INSTEAD OF} [INSERT][,][UPDATE][,][DELETE] AS 〈 SQL 语句〉
例7.1 创建一个名为Ins_student的触发器,要求在向"学生"表插入元组后引发该触发器,检查所插入的元组中系编号是否出现在"院系"表中,如果在"院系"表中找不到相应的系编号,则提示用户"系编号输入有误",并且回滚事务。 解: CREATE TRIGGER Ins_student ON S AFTER INSERT /*触发器在插入元 组后被引发*/
AS IF (SELECT COUNT (*) FROM D,Inserted WHERE D.Dnum = inserted.Dnum)=0 BEGIN PRINT '系编号输入有误!' ROLLBACK TRANSACTION END
为了验证我们创建的触发器是否发挥作用,我们可以再写一条SQL语句来插入一条新的学生信息,并故意将该学生的系编号设为院系表中没有的一个,比如8。插入数据的SQL语句如下:为了验证我们创建的触发器是否发挥作用,我们可以再写一条SQL语句来插入一条新的学生信息,并故意将该学生的系编号设为院系表中没有的一个,比如8。插入数据的SQL语句如下: INSERT INTO S VALUES('S010','王港','男',34,'87609876','8') 执行结果: 系编号输入有误! 可见我们创建的触发器Ins_student正常地发挥了作用。
例7.2建立一个名为Ins_teacher 的触发器,在向" 教师" 表插入记录时引发该触发器,检查所插入元组中教师的工资是否大于1000元且小于10000元,若不是则提示用户“工资必须大于1000元,小于10000 元”,并且回滚事务。 解: CREATE TRIGGER Ins_teacher ON T AFTERINSERT
AS IF(SELECT COUNT (*) FROM Inserted WHERETsalary <=1000 OR Tsalary>=10000) >0 BEGIN PRINT '工资必须大于1000元 , 小于10000元 !' ROLLBACK TRANSACTION END
插入一个老师信息,设定工资为800元,测试该触发器的SQL语句如下:插入一个老师信息,设定工资为800元,测试该触发器的SQL语句如下: INSERT INTO T VALUES(’T010’, ’成洁’, ’女’, ’1965-5-3’, ’讲师’,800, ’87654903’, ’2’) 执行结果: 工资必须大于1000元 , 小于10000元 ! 可见,触发器Ins_teacher也正常地发挥了作用。
7.3并发控制与封锁 7.3.1 事务 • 定义 事务(transaction)是构成单一逻辑工作单元 的操作集合 。 • 性质 • 原子性(Atomicity):事务是一个不可分割的工作单元 。 • 一致性(Consistency) :即数据不会应事务的执行而遭受破坏 。
隔离性(Isolation) :在多个事务并发执行时,系统应保证与这些事务先后单独执行时的结果一样 。 • 持久性(Durability) :一个事务一旦完成全部操作后,它对数据库的所有更新应永久地反映在数据库中。
例子:事务及其性质 问题:设银行数据库中有一转账事务T,从账号A转一笔款子($50)到账号B。 相应的事务: T:read(A); A:=A–50; write(A); read(B); B:=B + 50; write(B). • 原子性(A,B同时被修改或同时保持原值) • 一致性(A+B的值不变) • 隔离性 • 持久性
例7.3 假设某公司在华东地区设立了一个配送中心,负责向其在上海、杭州和南京的分公司输原料。现在要从配送中心发送数量为 Quantity 、编号为 Gno1 的商品到其在上海的分公司。设配送中心的商品库存信息存放在 CenterInventory( Gno ,QTY, …)关系中 , 而上海分公司的商品库存信息存放在 ShanghaiInventory(Gno,QTY, …)关系中,其中 Gno和 QTY属性分别代表商品编号及其库存量。试编写一事务Tl完成相关操作。
解: ... /* 读出配送中心关于商品Gno1 的库存量QTY */ EXEC SQL SELECT QTY INTO:MQTY FROM CenterInventory WHERE Gno=:Gno1; /* 从配送中心商品库存信息 CenterInventory 表中减去 Gno1 商品的库存量*/
EXEC SQL UPDATE CenterInventory SET QTY=QTY - :quantity WHERE Gno=:Gno1; IF (MQTY<quantity) {print("库存不足 , 不能配送 !"); ROLLBACK TRANSACTION; /* 恢复事务 , 撤消所有操作串 */ }
ELSE {/* 从上海商品库存信息 ShanghaiInventory表中增加 Gno1 商品的库存量 */ EXEC SQL UPDATE ShanghaiInventory SET QTY=QTY+:quantity WHERE Gno=:Gno1; COMMIT TRANSACTION:/* 提交事务 */ }
7.3.2 并发操作与数据的不一致性 并发操作可能带来的数据不一致性情况有三种: 丢失修改、读过时数据和读“脏”数据。
7.3.3 封锁 (1)排它锁和共享锁 排它锁和共享锁是最基本的封锁方式.如果事务T 对数据对象Y 加上了排它锁(记为 X 锁),那么T 既可以读取 Y ,也可以更新Y 。如果事务T 对数据对象Y 加上了共享锁( 记为S 锁),那么T 可以读取Y,但不能更新Y。
封锁的粒度 • 封锁对象的大小称为封锁的粒度(granularity) • 封锁的对象 • 逻辑单元:属性值、属性值集合、元组、关系、索引项、整个索引、整个数据库 • 物理单元:页(数据页或索引页)、块 • 封锁粒度与系统并发度和并发控制开销密切相关。粒度越大,系统中能被封锁的对象就越少,并发度就越小,但同时系统的开销也就越小;相反,粒度越小,并发度越高,系统开销越大
(2)封锁协议 所谓封锁协议就是在对数据对象加锁、持锁和释放锁时所约定的一些规则。 • 一级封锁协议 一级封锁协议规定事务T 在更新数据对象以前,必须对该数据对象加排它锁,并且直到事务T 结束时才可以释放该锁。利用一级封锁协议可以防止丢失更新问题的发生.
二级封锁协议 二级封锁协议规定事务T 在更新数据对象以前必须对数据对象加X 锁,且直到事务T 结束时才可以释放该锁,还规定事务T 在读取数据对象以前必须先对其加S 锁,读完后即可释放S 锁。可以防止丢失更新问题,还可以防止未提交依赖问题,但却不能防止不一致性分析问题。
三级封锁协议 三级封锁协议规定事务T 在更新数据对象以前,必须对数据对象加X 锁,且直到事务T 结束时才可以释放该锁,还规定事务T 在读取数据对象以前必须先对其加S 锁,该S 锁也必须在事务T 结束时才可释放。可以防止丢失更新和未提交依赖问题,此外还可以防止不一致性分析问题的发生。