第六章-数据库保护_第1页
第六章-数据库保护_第2页
第六章-数据库保护_第3页
第六章-数据库保护_第4页
第六章-数据库保护_第5页
已阅读5页,还剩73页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

第六章数据库保护主要内容:事务的概念并发控制数据库完整性数据库安全性数据库恢复第一节事务的概念事务(Transaction)是数据库恢复与并发控制的基本单位。所谓事务,是一个操作序列,这些操作要么都执行,要么都不执行,是一个不可分割的工作单位。例如,在银行转账工作中,先从一个账号取款,然后向另一个账号存款,这两个操作要么都执行,要么都不执行。所以,这样两个操作应该看成一个事务。事务是数据库维护数据一致性的单位,在每个事务结束时,都能保持数据一致性。第一节事务的概念具体到RDBMS中,事务可以是一条或一组SQL语句。SQL语言提供了以下的事务相关的定义语句:(1)BEGIN

TRANSACTION定义事务的开始;(2)COMMIT

TRANSACTION定义事务的结束,即提交事务,具体是将事务对数据库的更改永久写入磁盘中;(3)ROLLBACK

TRANSACTION定义回滚操作,将事务对数据库所做的所有更改全部还原,数据库返回到事务开始执行前的状态。第一节事务的概念事务包含四个特性,分别是(Atomicity)、一致性(Consistency)、隔离性(Isolation),以及持久性(Durability),这些性质又称为事务的ACID特性。原子性:是指事务包含的多个操作是一个不可分割的整体,这些操作要么全部成功,要么全部失败。事务如果执行成功则其中所有的操作结构都必须应用到数据库,如果执行失败则其中的任一操作都不能对数据库有任何影响。第一节事务的概念一致性:是指事务执行的结果必须使数据库从一个一致性状态变换到另一个一致性状态,也就是说一个事务执行之前和执行之后数据库都必须处于一致性状态。仍然用转账来举例,假设用户A和用户B的存款总数一共是5000元,那么不管A和B之间如何进行转账操作,转账对应的事务结束后两个用户的存款总数应该还是5000元,这就是事务的一致性。第一节事务的概念隔离性:当多个用户并发访问数据库时,一个事务的执行不能被其它事务所干扰。比如操作同一张表时,数据库为每一个用户开启的事务,不能被其他事务的操作所干扰,多个并发事务之间要相互隔离。简单的说,就是达到如下效果:对于任意两个并发的事务T1和T2,对事务T1来说,T2要么在T1开始之前就已经结束,要么在T1结束之后才开始。对事务T2来说也是如此,这样每个事务在执行时都感觉不到其它事务的执行。第一节事务的概念持久性:是指一个事务一旦被提交了,那么对数据库中的数据的改变就是永久的,即便是在以后数据库系统遇到故障的情况下也不会改变或丢失事务提交的结果。在日常运行过程中,事务是数据库系统的基本工作单元,因此保证事务的ACID特性是DBMS的重要任务。可能破坏这些事务特性的因素包括:(1)务正常运行过程中,由于故障、恶意攻击等原因使得事务运行意外终止;(2)事多用户并发访问数据库时,多个事务交叉运行。第二节事务的并发控制数据库是一个共享资源,可以提供多个用户使用。串行执行时,每个时刻只有一个用户程序运行,执行对数据库的存取。一个用户程序的操作可能涉及数据的计算、存取和I/O等,单个操作执行期间,与该操作无关的数据库系统资源将处于闲置状态。为了充分利用数据库资源,发挥数据库共享资源的特点,应该允许多个用户同时访问数据库,称为并发访问。第二节事务的并发控制并发执行的问题在银行系统中的一个活动序列如下:①甲用户查询某账户余额,得到的结果是余额为1000元;②乙用户在同一时间也查询该账户余额(假设甲、乙两人共同拥有该账户),得到的结果也是余额为1000元;③甲用户从账户中取走500元,这时账户余额更新为500元,并写回数据库;④乙用户同时也从账户中取走500元,这时由于乙用户之前已经读出的余额是1000元,因此账户余额更新为500元,并写回数据库。上述操作的结果是甲、乙两人从同一个账户一共取出了1000元,但账户余额仍然显示为500元。第二节事务的并发控制这种情况称为数据库的不一致性。这种不一致性是由甲、乙两人并发操作引起的。在并发操作情况下,对甲、乙两个事务操作序列的调度是随机的。若按上面的调度序列行,甲事务对数据库的修改就丢失了。这是由于最后乙事务修改账户余额并写回数据库,覆盖了甲事务的修改。并发操作带来的数据库不一致性可以分为4类:丢失更新、脏读、不可重复读和幻象读,上例属于其中的丢失更新,只是并发问题的一种。第二节事务的并发控制丢失更新当两个或多个事务操作同一数据,并且基于最初查询的值更新该数据时,就会发生丢失更新问题。脏读并发执行的两个事务中,事务1读取了尚未提交的事务2写入数据库的数据,当事务2由于某种原因进行了回滚,撤销了对数据的修改,则事务1读取的就是不正确的数据,称为脏读。例如当T1、T2两个事务并发执行时,T1从账户中转走500元,这时T2读取账户余额为500元,但T1在转账到另一账户时发

生了错误,事务回滚,原有账户余额恢复为1000元,这时T2读取的余额就是错误的。第二节事务的并发控制不可重复读一个事务重新读取前面读取过的数据时,该数据已经被另一个事务修改过,因此无法再现前一次读取的结果,称为不可重复读。例如当T1、T2两个事务并发执行时,T1查询账户余额为1000元,这时T2从账户中转走500元,当T1再次查询账户余额时,得到的账户余额就变成了500元。第二节事务的并发控制幻象读幻象读是不可重复读的特例,是指一个事务重新读取前面读取过的记录集合时,另一个事务向该数据集合中添加或删除了某些记录。例如当T1、T2两个事务并发执行时,T1查询本月交易记录明细,明细中共有10条记录,这时T2进行了转账操作,则增加了一条交易记录,当T1再次查询本月交易记录明细时,就会发现多了一条记录。第二节事务的并发控制(a)丢失修改T1T2T1T2①读余额为1000元③取款500余额为500元②读余额为1000元④取款500①取款500余额为500元③事务回滚余额为1000元②读余额为500元余额为500元(b)脏读T2T1①读余额为1000元②取款500余额为500元③读余额为500元(c)不可重复读T2T1①查交易明细共10条记录②转账

增加1条记录③查交易明细共11条记录(d)幻象读第二节事务的并发控制(2)封锁技术产生上述问题的主要原因是并发操作破坏了事务的隔离性,这时需要进行并发控制。封锁是事务并发控制的一个非常重要的技术。所谓封锁就是一个事务在对某些数据对象进行操作之前,先向系统发出请求,对其上锁。上锁后该事务就对这些数据库对象有了一定的控制,在事务释放申请的锁之前,其它事务不能访问此数据对象。第二节事务的并发控制封锁类型事务对某个数据对象加锁后如何对其进行控制是由封锁类型决定的。基本的封锁类型有两种:排他锁(eXclusivelock,简记为X锁)和共享锁(Share

lock简记为S锁)。排他锁又称为写锁。若事务T对数据对象A加上X锁,则只允许T读取和修改A,其它任何事务都不能再对A加任何类型的锁,直到T释放A上的X锁。共享锁又称为读锁。若事务T对数据对象A加上S锁,则其他事务只能再对A加S锁,而不能加X锁,直到T释放A上的锁。第二节事务的并发控制封锁粒度X锁和S锁都是加在某一个数据对象上的。封锁的对象可以是逻辑单元,也可以是物理单元。例如,在关系数据库中,封锁对象可以是属性值、属性值集合、元组、关系、索引项、整个索引、整个数据库等逻辑单元;也可以是页(数据页或索引页)、块等物理单元。封锁对象可以很大,比如对整个数据库加锁,也可以很小,比如只对某个属性值加锁。封锁对象的大小称为封锁的粒度(granularity)。第二节事务的并发控制封锁粒度与系统的并发度和并发控制的开销密切相关。封锁的粒度越大,系统中能够被封锁的对象就越少,并发度也就越小,但同时系统开销也越小;相反,封锁的粒度越小,系统中能够被封锁的对象就越多,并发度越高,但系统开销也就越大。一般说来,需要处理大量元组的用户事务可以以关系为封锁单元;需要处理多个关系的大量元组的用户事务可以以数据库为封锁单位;而对于一个处理少量元组的用户事务,可以以元组为封锁单位以提高并发度。第二节事务的并发控制封锁协议封锁的目的是为了保证能够正确地调度并发操作。为此,在运用X锁和S锁对一定粒度的数据对象加锁时,还需要约定一些规则。例如,应何时申请X锁或S锁、何时释放等,这些规则称为封锁协议(locking

protocol)。第二节事务的并发控制三级封锁协议对并发操作的不正确调度可能会带来四种数据不一致性:丢失或覆盖更新、脏读、不可重复读和幻象读。三级封锁协议分别在不同程度上解决了这一问题。一级封锁协议:事务T在修改数据R之前必须先对其加X锁,直到事务结束才释放。事务结束包括正常提交和故障回滚。一级封锁协议可以防止丢失修改问题,并保证事务T是可以恢复的。第二节事务的并发控制(a)丢失修改T1T2T1T2①读余额为1000元③取款500余额为500元②读余额为1000元④取款500①取款500余额为500元③事务回滚余额为1000元②读余额为500元余额为500元(b)脏读T2T1①读余额为1000元②取款500余额为500元③读余额为500元(c)不可重复读T2T1①查交易明细共10条记录②转账

增加1条记录③查交易明细共11条记录(d)幻象读第二节事务的并发控制在一级封锁协议中,如果仅仅是读数据不对其进行修改,是不需要加锁的,所以它不能防止不可重复读和脏读。二级封锁协议:在一级封锁协议的基础上,事务T在读取数据对象A之前必须先对其加S锁,读完后立即释放S锁。二级封锁协议除了可以防止丢失更新,还可进一步防止脏读。第二节事务的并发控制(a)丢失修改T1T2T1T2①读余额为1000元③取款500余额为500元②读余额为1000元④取款500①取款500余额为500元③事务回滚余额为1000元②读余额为500元余额为500元(b)脏读T2T1①读余额为1000元②取款500余额为500元③读余额为500元(c)不可重复读T2T1①查交易明细共10条记录②转账

增加1条记录③查交易明细共11条记录(d)幻象读第二节事务的并发控制在二级封锁协议中,由于读完数据后立即释放S锁,所以它不能避免不可重复读问题。三级封锁协议:在一级封锁协议的基础上,事务T在读取数据对象A之前必须先对其加S锁,直到事务结束才释放。三级封锁协议除了防止丢失更新和读脏数据外,还进一步防止了不可重复读和幻象读。第二节事务的并发控制(a)丢失修改T1T2T1T2①读余额为1000元③取款500余额为500元②读余额为1000元④取款500①取款500余额为500元③事务回滚余额为1000元②读余额为500元余额为500元(b)脏读T2T1①读余额为1000元②取款500余额为500元③读余额为500元(c)不可重复读T2T1①查交易明细共10条记录②转账

增加1条记录③查交易明细共11条记录(d)幻象读第二节事务的并发控制两段封锁协议数据库系统对并发事务中并发操作的调度是随机的,不同的调度可能会产生不同的结果。在计算机中,多个事务的并发执行是正确的,当且仅当其结果与按某一次序串行地执行它们时的结果相同,我们称这种调度策略为可串行化(Serializable)调度。可串行化是并行调度正确性的唯一准则,两段锁(two-phase

locking,简称2PL)协议是为保证并行调度可串行化而提供的封锁协议。第二节事务的并发控制两段封锁协议规定:①

在对任何数据进行读、写操作之前,事务首先要获得对该数据的封锁;②

在释放一个封锁之后,事务不再获得任何其它封锁。所谓“两段”锁的含义是,事务分为两个阶段,第一阶段是获得封锁,也称为扩展阶段,即只能申请锁,不能释放锁。第二阶段是释放封锁,也称为收缩阶段,即只能释放锁,不能申请锁。第二节事务的并发控制例如,事务T1的封锁序列是:Slock

A...

Slock

B…

Xlock

C…

Unlock

B…

Unlock

A…Unlock

C;事务T2的封锁序列是:Slock

A...

Unlock

A…

Slock

B…

Xlock

C…

Unlock

C…Unlock

B;显然,T1在扩展阶段申请了两个S锁和一个X锁,在收缩阶段将这些所全部释放,因此遵守两段封锁协议,而T2在扩展阶段释放了一个S锁,因此破坏了两段封锁协议的规定。第二节事务的并发控制活锁与死锁活锁:事务T1封锁了数据R,事务T2又请求封锁R,于是T2等待。T3也请求封锁R,当T1释放了R上的封锁之后系统首先批准了T3的请求,T2仍然等待。然后T4又请求封锁R,当

T3释放了R上的封锁之后系统又批准了T4的请求,...,T2有可能永远等待,这是活锁的例子。事务T1封锁了数据R1,T2封锁了数据R2,然后T1又请求封锁R2,因T2已封锁了R2,于是T1等待T2释放R2上的锁。接着T2又申请封锁R1,因T1已封锁了R1,T2也只能等待T1释放R1上的锁。因此两事务将永远等待,这是死锁的例子。第三节数据库完整性数据库完整性(DatabaseIntegrity)是指数据库中数据在逻辑上的一致性、正确性、有效性和相容性。数据库完整性由各种各样的完整性约束来保证,完整性约束保证合法用户对数据库进行修改时不会对数据造成意外破坏。实体完整性实体完整性在SQL语句的CREATE

TABLE中用PRIMARYKEY关键字定义。如果是单个属性构成主码,则可以将PRIMARYKEY用于列级约束或者表级约束。如果主码由多个属性构成,则PRIMARY

KEY必须用于表级约束。第三节数据库完整性在使用PRIMARY

KEY定义了关系的主码后,DBMS就按照实体完整性的定义自动进行检查,如果插入一条元组时其主码的值为空或者不唯一,则拒绝插入。为了避免每次插入元组时,都在数据库中扫描所有数据,一般会在主码上建立索引,通过查找索引来确定插入元组的主码值是否唯一。第三节数据库完整性(2)参照完整性参照完整性在SQL语句的CREATE

TABLE中用FOREIGNKEY关键字定义哪些属性为外码,用REFERENCES关键字定义外码参照了哪些关系的主码。由于参照参照被关破系坏操时作,完整性涉及到多个被要参区照分关破系坏操原作因关系,因此当该完整性约束条件是违由约参处照理关系还是被参照关系引插入起元的组,并根无据具体情况采取不拒同绝违插约入处理措施。修改外码值无拒绝修改无删除元组拒绝删除/级联删除/设置为空值无修改主码值拒绝修改/级联修改/设置为空值第三节数据库完整性(3)用户定义完整性用户定义完整性在SQL语句的CREATETABLE中用以下三种关键字来定义属性上的约束条件:①

非空约束NOT

NULL;②

唯一性约束UNIQUE;③

检查约束CHECK(检查属性值是否满足某一布尔型表达式)。当用户插入或修改元组时破坏了上述三类约束条件时,DBMS就拒绝执行这些操作。第三节数据库完整性(4)断言除了上述的几种约束以外,还有一种全局性的约束,称为断言。断言是用于一个或多个表的CHECK约束,需要在表定

义之外独立创建。例如,不允许余额小于零的账户存在,断言如下:CREATE

ASSERTION

assl

CHECK

(NOT

EXISTS

(SELECT

*

FROM

accountWHERE

balance<0));该断言建立后,其定义存放在数据字典中。当银行账户信息变动时,如果插入一条余额小于零的账户,或者将某个账户的余额修改为小于零,则拒绝更新,并给出错误信息。第三节数据库完整性(5)完整性约束命名子句除了上述的完整性约束条件之外,SQL语言还在CREATETABLE语句中提供了完整性约束命名子句CONSTRAINT,用于命名完整性约束条件,其语法结构如下:CONSTRAINT<完整性约束条件名>[PRIMARY

KEY约束表达式|

FOREIGN

KEY约束表达式|

CHECK约束表达式]建立完整性约束后,可以使用ALTERTABLE语句来修改或删除这些约束条件。ALTER

TABLE

R

DROP

CONSTRAINT

C1;ALTER

TABLE

R

ADD

CONSTRAINT

C1

CHECK

(SnoBETWEEN

20000

AND

30000);第三节数据库完整性(6)触发器触发器是一种特殊类型的存储过程,当数据库更新时,相应的触发器就会自动执行,从而确保对数据的操作符合所定义的完整性规则。为了设置触发器,主要是满足两个要求,一是告诉数据库系统,触发器什么时候被触发,即触发条件,二是触发后完成什么动作,即执行的内容。当不再需要一个触发器时,还需要对其进行删除。第三节数据库完整性SQL语言使用CREATETRIGGER语句创建触发器,其语句格式为:CREATE

TRIGGER<触发器名>{BEFORE

|

AFTER}<触发事件>ON<表名>FOR

EACH

{ROW

|

STATEMENT}[WHEN<触发条件>]AS<触发动作>;其中,只有表的创建者才能在表上创建触发器,并且每个表上允许创建的触发器数量是一定的,不能无限创建。第三节数据库完整性触发器分为语句级触发器和行级触发器。语句级触发器(FOREACH

ROW)是由相应的SQL语句执行进行触发,而行级触发器(FOR

EACH

STATEMENT)则是由一行中的数据被更新进行触发。<触发动作>既可以是一个PL/SQL语句块,也可以是调用一个存储过程。对于行级触发器来说,可以在<触发动作>通过

OLD和NEW关键字引用数据更新前和更新后的值。第三节数据库完整性例6.1为emploee关系定义一条行级触发器,要求用户年龄在20以下时,自动改为20,语句如下:CREATE

TRIGGER

Update_ageBEFORE

INSERT

OR

UPDATE

ON

emploeeFOR

EACH

ROWASBEGINIF

NEW.age

<

20

THENNEW.age

=

20;END

IF;END;第三节数据库完整性当一个表上存在多个触发器时,其执行一条SQL语句的过程是:先触发并执行相关的BEFORE触发器,然后执行该SQL语句,最后触发并执行相关的AFTER触发器。对于多个同类触发器,先创建则先执行。删除触发器的语句格式为:DROP

TRIGGER<触发器名>ON<表名>;第四节数据库安全性数据库安全属于计算机安全研究领域的一个分支,包括数据库系统运行安全和数据库系统信息安全两个部分。通用安全标准美国国防部于1983年推出了历史上第一个计算机安全评价标准——《可信计算机系统评测准则》(Trusted

ComputerSystem

Evaluation

Criteria,TCSEC)。在此基础上,美国政府同加拿大及欧共体又进一步共同提出了“信息技术安全评价通用准则”(The

Common

Criteriafor

Information

Technology

security

Evaluation,CC),目的是建立一个各国都能接受的通用的信息安全产品和系统的安全性评估准则。第四节数据库安全性TCSEC标准在用户登录、授权管理、访问控制、审计跟踪、隐蔽通道分析、可信通路建立、安全检测、生命周期保障、文档写作等各方面,均提出了规范性要求,并根据所采用的安全策略、系统所具备的安全功能将系统分为四类7个安全级别。D类只包含一个级别——D级,是安全性最低的级别。不满足任何较高安全可信性的系统全部划入D级。该级别说明整个系统都是不可信任的。第四节数据库安全性C类为自主保护类(DiscretionaryProtection)。该类的安全特点在于系统的对象可由其主体自定义访问权。自主保护类依据安全从低到高又分为C1、C2两个安全等级。C1级:又称自主安全保护(DiscretionarySecurityProtecti级。用户必须通过用户注册名和口令系统识别,这种组合用来确定每个用户对程序和信息拥有什么样的访问权限,存在一定的自主访问控制机制(DAC)。C2级:又称受控制的访问控制级。它具有以用户为单位的DAC机制,且引入了审计机制。第四节数据库安全性B类为强制保护类(MandatoryProtection)。该类的安全特点在于由系统强制的安全保护。在强制保护模式中,每个系统对象(如文件、目录等资源)及主体(如系统管理员、用户、应用程序)都有自己的安全标签(Security

Label),系统依据主体和对象的安全标签赋予他对访问对象的访问权限。强制保护类依据安全从低到高又分为B1、B2、B3三个安全等级。第四节数据库安全性A类为验证设计(VerifyDesign)类:最高的安全级别,它包含了一个严格的设计、控制和验证过程。设计必须是从数学上经过验证的,而且必须进行隐蔽通道和可信任分布的分析。可信任分布(TrustedDistribution)的含义是,硬件和软件在传输过程中已经受到保护,不可能破坏安全系统。验证保护类只有一个安全等级,即A1级。A1级要求具有系统形式化顶层设计说明(FTDS),并形式化验证FTDS与形式化模型的一致性,以及用形式化技术解决隐蔽通道问题等。第四节数据库安全性CC开发的目的是使各种安全评估结果具有可比性,在安全性评估过程中为信息系统及其产品的安全功能和保证措施提供一组通用要求,并确定一个可信级别。应用CC的结果是,可使用户确定信息系统及安全产品对他们的应用来说是否足够安全、使用中的安全风险是否可以容忍。要评估的信息系统和产品被称为评估对象(TOE),如操作系统、分布式系统、网络及其应用等。第四节数据库安全性CC由三部分组成,包括:第一部分:简介和一般模型。它定义了IT安全评估的通用概念和原理,提出了评估的通用模型。它还提出了一些概念,这些概念可用来表达IT安全目的,用于选择和定义IT安全要求、书写系统与产品的高层规范。第二部分:安全功能要求。它建立了一系列功能组件,作为表示TOE功能要求的标准方法。第三部分:安全保证要求。它建立了一系列保证组件,作为表示TOE保证要求的标准方法。它也定义了保护轮廓(PP)和安全目标(ST)的评估准则,提出了评估保证级别,即评估TOE保证的CC预定义等级。所谓PP是指一组独立实现的、满足特定用户需求的TOE安全要求,而ST则是指作为指定的TOE评估基础的一组安全要求和规范。第四节数据库安全性(2)数据库安全机制用户标识与鉴别:最外层的防护措施,它保证合法的用户才能进入数据库系统。具体方式是让用户提供能够鉴别自己身份的相关信息,常见的方法是由用户提供用户名或者用户标识号(UID)来表名身份,同时提供口令信息以供系统进行核实。访问控制(Access

Control,AC):显式地定义用户的访问权限(访问能力及范围),这些定义存储在数据字典中,在用户进行实际操作时,DBMS对照数据字典中的定义来判断操作的合法性,并拒绝非法操作,从而控制用户和程序对数据库的操作。访问控制保证只有授权用户才能访问数据库中相应的数据,防止了非授权用户对数据的访问。第四节数据库安全性当前常见的DBMS产品一般都支持TCSEC标准中C2级的自主访问控制(DAC),部分产品还支持B1级中的强制访问控制(MAC)。自主访问控制(Discretionary

Access

Control,DAC)是基于主体(用户)身份或者主体所属组的身份或者二者的结合,对客体(数据对象)访问操作进行限制的一种方法,其粒度是单个用户。在自主访问控制技术中,用户对数据的访问控制主要是基于对用户身份的鉴别和访问规则来确定。并且,对某个信息资源拥有某种权限的用户可以把该权限授予其他用户,即选择与其他用户共享数据资源。第四节数据库安全性在关系数据库中,自主访问控制的客体除了数据之外,还有数据库模式、基本表、视图和索引等。客体操作权限数据库模式CREATE基本表CREATE,

ALTER视图CREATE索引CREATE表中的数据SELECT,

INSERT,

UPDATE,

DELETE,

REFERENCES,ALL

PRIVILEGES属性列SELECT,

INSERT,

UPDATE,

REFERENCES,

ALLPRIVILEGES第四节数据库安全性SQL语言使用GRANT语句赋予用户一定的操作权限,其语法结构如下:GRANT<权限>[,<权限>…]ON<客体类型><客体名>[,<客体类型><客体名>…]

TO<用户>[,<用户>…][WITH

GRANT

OPTION];其中,如果使用了WITH

GRANT

OPTION,则得到相应权限的用户还可以把该权限赋予其他用户,但不能进行循环授权。第四节数据库安全性例6.2向用户U1授予user表的查询权限,并允许其将该权限再授予其他用户,语句如下:GRANT

SELECTON

TABLE

userTO

U1WITH

GRANT

OPTION;例6.3向所有用户授予user表的所有操作权限,语句如下:GRANT

ALL

PRIVILEGESON

TABLE

userTO

PUBLIC;第四节数据库安全性在授予权限后,可以通过REVOKE语句收回权限,其语法结构如下:REVOKE<权限>[,<权限>…]ON<客体类型><客体名>[,<客体类型><客体名>…]

FROM<用户>[,<用户>…][CASCADE

|

RESTRICT];其中,CASCADE表示级联回收权限,RESTRICT表示限制回收,即指定用户将权限赋予其他用户时,不能直接回收该用户的权限。一般情况下,RESTRICT为默认选项。第四节数据库安全性例6.3级联收回用户U1在user表上的查询权限,语句如下:REVOKE

SELECTON

TABLE

userFROM

U1;这一操作将一并收回用户U1在user表上的查询权限。第四节数据库安全性SQL语言使用CREATE

ROLE来创建角色,然后使用GRANT和REVOKE语句来赋予和回收角色的权限,其语法结构分别如下。创建角色:CREATE

ROLE<角色名>;为角色授予权限:GRANT<权限>[,<权限>…]ON<客体类型><客体名>TO<角色>[,<角色>…];第四节数据库安全性为用户或角色授予角色权限,一个角色的权限等于直接授予该角色的权限和其他角色授予该角色的权限:GRANT<角色>[,<角色>…]TO<用户>[,<角色>…]

[WITH

ADMIN

OPTION];收回角色的权限:REVOKE<权限>[,<权限>…]ON<客体类型><客体名>FROM<角色>[,<角色>…];第四节数据库安全性例6.5创建角色R1,语句如下:CREATE

ROLE

R1;刚创建好的角色没有任何权限,这时使用GRANT语句为其分配权限。例6.6为角色R1授予user表的所有操作权限,语句如下:GRANT

ALL

PRIVILEGESON

TABLE

userTO

R1;角色的权限还可以进一步赋予其他用户或角色。第四节数据库安全性例6.7为用户U6、U7授予角色R1的权限,语句如下:GRANT

R1TO

U6,

U7WITH

ADMIN

OPTION;由于指定了WITH

ADMIN

OPTION,则得到权限的角色或用户还可以进一步将权限赋予其他角色。可以使用REVOKE语句来回收角色的权限。例6.8对用户U6收回角色R1的权限,语句如下:REVOKE

R1FROM

U6;第四节数据库安全性强制访问控制(Mandatory

Access

Control,MAC)的基本思想是通过给主体和客体指定安全级,并根据安全级匹配规则来确定主体能够访问的客体范围。主体的安全级反映主体的可信度,称为许可证级别。客体的安全级反映客体的敏感度,称为敏感度标记。主、客体的安全级都被分为不同等级,如秘密、机密、绝密等。MAC中为了保证信息的机密性,要求:(1)无向上读,不允许低安全级的主体读取高安全级的客体信息;(2)无向下写,不允许高安全级的信息写入低安全级的区域,或者说不允许高安全级用户向低安全级的客体写入信息。上述规则保证了信息的不会从高安全级别流向低安全级别。第四节数据库安全性除了授权机制以外,使用视图机制也可以限制用户对数据的访问。为不同用户定义不同的视图,使得每个用户的访问范围限制在相应的视图之内,可以为数据库提供一定程度的安全保护,同时也实现了数据库的逻辑独立性。但视图机制所能提供的保护精细度有限,一般达不到实际应用的要求,因此常常与访问控制机制结合使用。首先使用视图机制对用户和数据进行初步划分,然后再使用访问控制机制做进一步细分。第四节数据库安全性加密技术是一种防止数据泄露的技术。它的核心技术是密码学,密码学是研究密码系统或通信安全的一门学科,它又分为密码编码学和密码分析学。任何一个加密系统都是由明文、密文、算法和密钥组成。其中,明文是原始的或未加密的数据,通过加密算法对其进行加密,加密算法的输入信息为明文和密钥。密文是明文加密后的格式,是加密算法的输出信息。加密算法是公开的,而密钥则是不公开的。密文不应为无密钥的用户理解,用于数据的存储以及传输。密钥,是由数字、字母或特殊符号组成的字符串,用它控制数据加密、解密的过程。第四节数据库安全性前面讨论的安全机制从不同方面对可能存在的恶意攻击行为进行了防护,但任何系统都不可能做到百分之百安全。当系统安全遭到破坏时,根据操作记录分析原因,找出相关责任人也是非常重要的一项任务,这项任务由安全审计来完成。在TCSEC标准中,达到C2以上级别的系统必须具备审计功能。安全审计是一种对数据库系统的监视措施,对哪些用户对哪些数据进行了什么操作进行记录,并将记录结果存放在审计日志中。根据审计日志,系统可以对安全事故进行权责追查。审计功能通常耗费较多的系统资源,因此在实际应用中需要根据情况来选择是否开启、什么时候开启审计功能。第四节数据库安全性SQL语言使用AUDIT语句来设置审计功能,相应的NOAUDIT语句取消审计功能。例6.9对user表上的数据插入和修改操作开启审计功能,语句如下:AUDIT

INSERT,

UPDATEON

user;例6.10对user表的修改操作开启审计功能,语句如下:AUDIT

ALTERON

user;例6.11取消user表的修所有审计功能,语句如下:NO

AUDIT

ALTER,INSERT,UPDATEON

user;第五节数据库恢复数据库恢复技术的主要内容包括两方面,了解造成数据库中数据损坏或丢失的故障类型,以及针对这些故障的恢复措施。数据库系统中常见的故障类型有三种,包括事务内部故障、系统故障和存储设备(介质)故障。事务故障可分为预期的和非预期的,其中大部分的故障都是非预期的。预期的事务故障是指可以通过事务程序本身发现的故障,非预期的事务故障是不能由事务程序处理的故障。第五节数据库恢复系统故障及其恢复系统故障是指系统在运行过程中,由于某种原因,造成系统停止运转,致使所有正在运行的事务都以非正常方式终止,要求系统重新启动。存储介质故障主要指数据库在运行过程中,由于磁头碰撞、磁盘损坏、强磁干扰、天灾人祸等情况,导致外存储设备损坏,使得数据库中的数据部分或全部丢失。第五节数据库恢复对于各种各样的故障类型,恢复技术通过预先存储的冗余数据来重建数据库,其中涉及到两个关键问题,一是如何建立冗余数据,二是如何通过冗余数据来重建数据库。其中,问题一涉及到数据转储技术,问题二涉及到数据库日志文件。数据转储也称为数据备份,是指由DBA定期将整个数据库从本地系统存储设备复制到另一存储设备进行保存的过程。转储得到的备份数据称为后备副本。第五节数据库恢复一般来说,数据转储分为静态转储和动态转储两类。静态转储是在系统中无运行事务时进行转储,转储开始时数据库处于一致状态,转储期间不允许对数据库的任何存取、修改活动。动态转储可以与用户事务并发执行,转储期间允许对数据库进行存取或修改。第五节数据库恢复数据库日志文件是用于记录事务对数据库所做的更新操作的文件,是日志记录的有序集合。其中,一般的日志记录的内容包括:各个事务的开始标记(BEGIN

TRANSACTION)、各个事务的结束标记(COMMITTRANSACTION/ROLLBACK

TRANSACTION),以及各个事务的所有更新操作。在数据库系统的运行过程中,每条事务的执行都会导致生成一条新的日志记录。在事务的更新操作对数据库修改生效之前,必须先将相应的日志记录写入到日志文件中(先写日志,后提交事务)。第五节数据库恢复事务故障恢复事务故障分为预期的事务故障和非预期的事务故障。对于预期的事务故障,相应的恢复方法是将事务回滚,撤销对数据库的修改。对于非预期的事务内部故障,恢复方法是强制回滚事务,在保证该事务对其他事务没有影响的条件下,利用日志文件撤销(UNDO)其对数据库的修改。第五节数据库恢复系统故障恢复系统故障导致数据库不一致的情况有两种:一种是某些未完成事务对数据库的更新已写入物理数据库中,另一种是某些已提交事务对数据库的更新结果还保留在缓冲区中,尚未写到物理数据库中。对于这两种情况,恢复操作需要撤销故障发生时所有未提交的事务,重做所有已提交的事务。具体的说,需要查找该事务对应的所有更新日志记录,并根据记录内容将数据库中的相应数据项恢复到更新前的值。第五节数据库恢复存储设备故障恢复当存储设备发生故障时,数据库中的部分或全部数据丢失,同时日志文件也丢失了。这时需要借助于数据转储技术的后备副本进行数据库恢复,具体是先装入最近一次转储的副本,如果是动态转储,还要同时装入转储过程中记录的日志文件,将数据库恢复到离故障发生时刻最近的一致性状态上。然后,根据转储时刻起到故障发

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论