《计算机系统安全》课件第8章

8.1数据库安全概述8.2数据库系统的安全模型与实现策略8.3数据库系统安全机制习题

数据库系统安全控制是指为数据库系统建立的安全保护措施，用以保护数据库系统软件和其中的数据不因偶然或恶意的原因而遭到破坏、更改和泄露。目前，数据库系统安全、网络安全、操作系统安全及协议安全一起构成了信息系统安全的四个最主要的研究领域。

8.1数据库安全概述8.1.1数据库安全目标

虽然数据库系统由于自身的特点，其安全措施在某些方面与其它计算机系统的安全措施有本质的不同，但它对安全的要求与其它计算机系统没有什么区别，其安全要求同样可归纳为完整性、保密性和可用性三类。

(1)数据库的完整性。数据库的完整性是指保证数据库内容的正确性、有效性和一致性。

数据库系统的完整性主要包括物理完整性和逻辑完整性。物理完整性是指保证数据库的数据不会因物理故障(如硬件故障、掉电等)而被破坏。

逻辑完整性是指对数据库逻辑结构的保护，包括数据的语义完整性和操作完整性。数据的语义完整性指数据存取在逻辑上满足完整性约束。数据的操作完整性主要指在并发事务中保证数据库中数据的逻辑一致性。

(2)数据库的保密性。数据库的保密性是指不允许未经授权的用户存取数据。

(3)数据库的可用性。数据库的可用性是指不应拒绝授权用户对数据的访问，同时保证系统的运行效率并提供用户友好的人机交互。

不同领域的应用对这三方面要求的侧重点会有较大的差异。数据库系统的安全除依赖自身内部的安全机制外，还与外部网络环境、应用环境、从业人员素质等因素息息相关。因此，从广义上讲，数据库系统的安全框架可划分为网络系统、宿主操作系统和数据库管理系统三个层次，这三个层次共同构筑了数据库系统的安全体系。8.1.2数据库的安全威胁

随着计算机技术和网络技术的进步，数据库的运行环境也在不断变化。在新的环境中，数据库系统需要面对更多的安全威胁，针对数据库系统的新攻击方法也层出不穷。根据违反数据库安全性所导致的后果，安全威胁可分为以下几类：(1)外围环境威胁。

(2)身份认证威胁。

身份认证威胁包括所有直接对用户标识和身份认证系统构成威胁的因素。身份认证威胁的例子包括：存储在外部服务中的认证信息可能被窃取，使得攻击者可以以合法用户的身份登录，拒绝正确用户登录系统；管理员滥用权力新增、修改、删除用户认证信息，修改系统认证策略等。

(3)访问控制威胁。访问控制威胁包括所有直接对用户授权和访问控制的威胁因素。例如，非授权的信息泄露和非授权的数据修改等都属于访问控制威胁。

非授权的信息泄露指未授权的用户有意或无意地得到信息。通过对授权访问的数据进行推导分析而获取非授权的信息也包含在这一类中。非授权的数据修改包括所有在数据处理和修改过程中违反信息完整性的行为。

(4)数据处理威胁。数据处理威胁包括所有处理数据时的威胁因素。例如，在多级安全数据库中，为解决隐蔽信道问题通常需要提供多实例，这样会破坏系统的完整性约束。

这就属于数据处理威胁。

(5)其它安全威胁。

安全威胁分为有意和无意的。无意的安全威胁主要包括：自然或意外灾害对系统的软/硬件的破坏，系统软/硬件的错误以及人为无意地违反安全策略对数据库系统完整性的破坏，导致拒绝服务和信息泄露。8.1.3数据库的安全需求

面对威胁，数据库的安全维护要针对各种因素和安全需求来制定防范措施，建立安全模型，以保护其资源免受非授权的访问攻击。数据库安全需求大致可分为以下几类:

(1)防止非法数据访问。

这是数据库安全最关键的需求之一,主要指仅允许授权的合法用户访问数据库。

(2)数据分级保护。该需求指依据数据敏感级别进行多级保护。在包含敏感、非敏感混合数据的数据库中，严格控制对敏感数据的访问请求，仅允许经过授权的用户进行合法操作，且不允许其权利传播或转让。

(3)防止推断性攻击。该需求指防止用户通过授权访问的低安全级数据推导出敏感数据。统计型数据库容易受到该

类攻击。

(4)数据库的完整性。该需求涉及到防止更改数据内容的非授权访问、病毒、蓄意破坏或是系统级错误及故障等，主要由DBMS通过访问控制以及备份、恢复机制来执行并完成保护工作。

(5)数据的操作完整性。该需求指在并行事务的模式下，保持数据的逻辑一致性，通常采用并行管理器和加锁机制来完成。

(6)数据的语义完整性。该需求指确保对数据在允许的范围之内进行修改，以保持数据的一致完整性。

(7)审计功能。该需求指提供数据的物理完整性，并记录下对数据的所有存取访问，根据结果进行分析与追踪。8.1.4数据库安全评价标准

随着对安全问题的认识和对安全产品的要求的不断提高，人们在安全技术方面逐步建立了一套安全评估标准，以规范和指导安全信息系统的建立和安全产品的生产，并能较准确地评测产品的安全性能指标。

20世纪70年代初，美国军方率先发起了对多级安全数据库管理系统(MultilevelSecureDatabaseManagementSystem，MLSDBMS)的研究。

20世纪80年代，美国国防部根据军用计算机系统的安全需要，制定了《可信计算机系统安全评估标准》(TrustedComputerSystemEvaluationCriteria，TCSEC)，以及该标准的可信数据库系统的解释(TrustedDatabaseInterpretation，TDI)，形成了最早的信息安全及数据库安全评估体系。TDI作为一种数据库安全评估标准，能够指导开发者在新开发的商用DBMS产品中提供安全特性，即TCSEC中所提出的可信要求。此外，TDI作为一种可度量的评估，还为处理涉密、分级和其它敏感信息的安全数据库系统提供了一种等级评估的方法。

20世纪90年代后期，《信息技术安全评价通用准则》(CommonCriteria，CC)被ISO确立为国际标准，也即确立了现代信息安全标准的框架，这些标准对安全数据库系统的研究及其应用系统的开发都具有重要的指导作用。8.1.5数据库安全研究的发展

国外对计算机安全及数据库安全的研究起步较早，Bell.D.E和LaPadula于1973年提出的著名的BLP模型是最早的一个完全形式化的多级安全模型，是计算机安全理论研究的开端。

随着数据库安全理论和技术的发展，为了满足对安全数据库系统越来越迫切的需求，国外各大数据库厂商纷纷推出了各自的安全数据库产品，如Oracle公司的TrustedOracle、Informix公司的Informix-online、SecureSybase公司的SecureSQLServer等产品。

近几年来，Oracle公司的Oracle9i和Oracle10g从用户认证、访问控制、加密存储和审计策略等方面进一步加强了安全控制功能。基于对安全数据库的需求，我国从20世纪80年代开始进行数据库技术的研究和开发，从90年代初开始进行安全数据库理论的研究和实际系统的研制。20世纪90年代以来，华中理工大学(现华中科技大学)、中国人民大学和东北大学等单位对数据库安全技术进行了研究和实践，并开发出了相应的安全数据库软件，如基本达到B1级安全要求的DM3数据库、COBASE(KingBase)数据库2.0可信版本及OpenBaseSecure等。2003年，中科院信息安全国家重点实验室基于开放源代码的数据库管理系统PostgreSQL开发出安全数据库系统LOIS。总体来讲，我国的研究成果在安全性和可用性上与国外产品还有一定的差距。目前，国内的电信、金融、电力、保险等行业基本上都采用的是Oracle、Sysbase、Informix三大数据库厂商和IBM、微软的低安全级别的数据库产品。8.2.1数据库系统的安全模型

多级安全数据库(MLSDB)是数据库安全研究领域中的重要内容之一。20世纪80年代末至90年代初期，关系数据库系统是应用最为广泛的数据库系统，因此研究的重点集中于如何在数据库系统中实现多级安全，即如何将传统的关系数据库理论与多级安全模型相结合，建立多级安全数据库系统。8.2数据库系统的安全模型与实现策略因此，数据库系统的多级安全模型是以多级关系数据模型为基础的。

关系数据库系统是基于关系数据模型的。关系数据模型自20世纪70年代出现以来已经发展得相当成熟了，但高安全级数据库系统在引入多级安全以增加保密性之后，关系模型中的完整性要求却不会自然得到满足，这造成保存在数据库系统中的信息具有歧义性。因此，传统模式中关系的定义需要修改以支持多级关系，其中关系的完整性约束及关系操作也需要改进，以保证安全性。与传统关系数据模型类似，多级关系数据模型中的三要素为多级关系、多级关系完整性和多级关系操作。

1.多级关系

多级关系扩展了传统关系的概念，除了关系的属性以外，它还包括相关的安全级别属性。

多级访问控制粒度可分为关系级、元组级、属性级与数据项。当控制粒度为数据项时，每一数据项都有安全级标记，且关系中的元组也具有安全标记。因此，关系模式由原来R(A1,

A2,…,

An)扩展为R(A1,

C1,

A2,

C2,…,An,Cn，TC)。与传统关系类似，多级关系包括关系模式(relationscheme)和关系实例(relationinstances)两个部分。

(1)关系模式定义。

定义R(A1,C1,A2,C2,…,An,Cn,TC)

Ai∈Di;Ci∈｛Li,…,Hi｝(Li<Hi);TC=lub｛Ci|Ci≠null,i=1,…,n｝

其中，Ai表示数据属性，Di表示Ai的值域，Ci表示属性Ai的安全级，TC表示元组的安全级，Li表示低安全级，Hi表示高安全级，lub指安全级的最小上界(参见4.1节)，TC等于该元组其他属性安全级的最小上界。

(2)关系实例定义。

定义每一个关系模式都有一组依赖于状态的关系实例：

RC(a1,c1,a2,c2,…,an,cn,TＣ)

对应于一给定的访问级别C，每个关系实例是一组形为(a1,c1,a2,c2,…,an,cn,TC)，且互不相同的记录。其中，ai∈Di,ci∈｛Li,…,Hi｝或ai=null,ci∈｛Li,…,Hi｝;TC=lub｛ci|ci≠null,i=1,…,n｝。由于BLP*-特性的约束(参见本书第4章4.5节)，对于同一个多级关系，不同安全级别的用户所看到的内容并不同,因而在每一个安全级别上都存在一个投影实例。

例如，假设有一个用来描述职员部门薪水情况的关系模式EDS(Employee,Dept,Salary)，其中Employee为主键，密级自高到低依次是绝密(TS)、机密(S)、秘密(C)、公开(U)；划分粒度为数据项；属性TC表示元组的密级。在多级关系EDS中(如表8-1所示)，秘密级用户看见的内容如表8-1所示；而在同样的多级关系中，公开级别的用户看见的内容

如表8-2所示。表8-1多级关系EDS(秘密级视图)假设公开级用户想将第二个元组修改为：“Tom”，“Dept1”，“2000”。此时，尽管在安全级较高的元组中已经存有Tom的相关数据，但为了避免低安全级用户推理出高安全级数据，所以不能拒绝该插入操作。同时为了保持数据的完整性，也不能删除安全级较高的数据。那么，公开级

关系将如表8-3所示。而对安全级为秘密的用户而言，他所看到的信息如表8-4所示。显然，这违反了主键完整性。同理，当安全级较高的用户要求插入一个主码属性值与低安全级主码属性值相同的元组时，也不能拒绝该操作，否则将隐含拒绝服务问题。如果用该元组替换低安全级的元组，则意味着删除低安全级的元组，这将导致信息的推理问题，因此只能插入新的高安全级元组而不修改低安全级的元组。表8-3修改操作后的多级关系EDS(公开级视图)表8-4修改操作后的多级关系EDS(秘密级视图)显然，在多级关系中，如果仍将Employee作为主码,惟一标识每一个元组，那么该操作将违反主键完整性。如上所述，考虑到安全问题，在多级关系中允许存在多个具有相同属性值但其安全级不同的元组，我们把其称为多实例，具体讲可分为下列三类：

(1)多实例关系：是指一种关系，该关系有相同的关系名称，而模式由不同的安全级别来标识。

(2)多实例元组：也称实体多实例，它由主码属性值相同但主码属性安全级不同的元组组成。

(3)多实例元素：也称属性多实例，它由主码属性值和安全级相同，但某些属性的值及其安全级不同的元组组成。利用多实例可以很方便地提供“覆盖层(CoveryStory)”，用于防止信息泄露。但对于高安全级的主体来说，由于所有低安全级的多实例都是可见的，因此，他必须能明确地判断哪一些是真实的。关于多实例语义存在两种解释：一种认为主键相同的不同级别元组反映的是现实世界中相同的对象，只不过其中最多只有一个是真实的，其它的则作为对真实信息的伪装而存在(比较合理的认识是级别越高者越“真实”)；另外一种解释是主键相同的不同级别元组反映的是现实世界中不同的对象。

2.多级关系完整性

(1)实体完整性。

假设AK为R的主关键字。一个多级关系R满足实体完整性，当且仅当R的所有RC实例以及t∈RC满足：

①Ai∈AK→t［Ai］≠null;

②Ai,Aj∈AK→t［Ci］=t［Cj］;

③Ai∈AK,AjAK→t［Ci］≥t［AK］。第一条确保了AK中任何属性值不为空；第二条说明在一个记录中，AK所有属性的级别相同，这便保证了AK在某个访问级要么是完全可见的,要么是完全不可见的；

第三条要求任何非主关键字的数据项的安全级别等于或高于AK的安全级。

(2)空值完整性。

①对任一元组，如果数据属性为空，那么Ai对应的秘密级属性Ci值等于主键的秘密级CAK。

②实例的级别低于属性的级别，使得此属性不可见，从而表现为空。为了区分这两种情况，在关系R中元组之间不允许出现包含关系。元组间的包含关系定义为：对于两元组t和s，如果任何一个属性t［Ai，Ci］≥s［Ai，Ci］或t［Ai］≠null，s［Ai］=null，则称元组t包含元组s。

(3)实例间完整性。

一个多级关系RC满足实例间完整性，当且仅当对于小于此实例安全级别的C′(C′≤C)，存在一个关系RC=δC(RC,C′)满足以下性质：①对于任何t［CAK］≤C′且属于RC的元组t，均有一属于RC′的元组t′且t′［AK，CAK］=t［AK，CAK

］;

②对于不属于主键的属性，有

t［Ai,Ci］t［Ci］≤C′

〈null，t［CAK］〉t［Ci］>C′t［Ai，Ci］=除了由以上方法生成的元组外，RC中不包含其他元组。上式中δ是过滤函数,它将一个多级关系根据不同的访问级别映射为不同的实例，将用户限制在其许可的数据上。第一条确保了元组只在安全级为t［Ci］或更高级别的关系实例中才可见，且其主键值t［AK，CAK］为关系实例中元组t′的主键值；第二条确保了元组t的其它不属于主键的数据项t［Ａi］在安全级为t［Ci］或更高级别的关系实例中是可见的，而在低于它的安全级关系中是null值。同时该函数消除了RC′中所有的包含元组，以得到过滤函数δ的最终结果。表8-5多级关系EDS(公开级视图)

(4)多实例完整性。

多实例完整性禁止在同一安全级上存在多实例。下面介绍多实例完整性定义。

假设A1为R的主关键字，多级关系R满足多实例完整性，当且仅当R的所有RC实例以及t∈RC满足：A1,C1,Ci→Ai。

上述定义表明A1、C1、Ci函数决定了Ai的属性值，即若多个记录有相同的A1、C1、Ci，那么它们的Ai值也是相同的，因此相同级别的数据是不可能多实例的。也就是说，允许在不同安全级之间实现实体多实例化，用于防止信息泄露和推理(如表8-4所示);同时，又禁止在同一安全级上实现实体多实例化，从而避免如表8-8所示的语义模糊问题(无法确认Tom的Salary)。表8-8多级关系EDS(相同级别主键重复)

(5)外码完整性。假设FK是关系R的外码，关系R满足外码完整性当且仅当R的所有RC实例以及t∈RC满足：Ai∈FK,s［Ai］=null或t［Ａi］≠null,Ai,Aj∈FK→t［Ci］=t［Cj］。该定义表明一个记录中FK的所有属性的安全级别相同。

(6)参照完整性。定义FK为参照关系R1的外码，AK1为关系R1的主码；关系R2为被参照关系，AK2为关系R2的主码;多级关系R1、R2的实例r1、r2，满足参照完整性当且仅当：

若元组t1∈r1,t1［FK1］≠null，则一定存在t2∈r2,满足:

t1［FK1］=t2［AK2］∧t1［］≥t2［］∧t1［TC］=t2［TC］该定义表明当关系r1参照关系r2时，其外码的安全级必须大于或等于关系r2主码的安全级，即t=［］≥t2［］，这保证了在参照过程中信息不会由高安全级向低安全级泄露；并且要求t1［TC］=t2［TC］，这表明元组t1只能参照安全级与其相等的元组t2。

3.多级关系操作

由于多级关系的特殊性以及为了避免隐通道而采用了多实例技术，因而多级关系模型操作较传统关系模型有所不同。(1)插入操作。多级关系插入操作的一般格式为：

INSERT

INTOR(Ai1［,Ai2,…］)

VALUES(ai1［,ai2,…］)

R表示关系名称；Ai1,Ai2,…表示数据属性名称；ai1,ai2,…表示Ai1,Ai2,…

的数据值，且ai1∈Di1,ai2∈Di2,…,ain∈Din。其功能是将新元组插入指定的关系中。

t［A1,C1］表示关系R中的一个实体，A1表示主码，C1表示A1的安全等级属性。元组t表示将要插入的元组。

当一安全级为C(C∈｛Li,Hi｝的用户进行插入操作时，如果没有元组t′∈R满足t′［A1］=a1∧t′［TC］=C，而且插入的元组满足实体完整性、外码完整性和参照完整性，那么此时才允许该插入操作。其操作结果为：

①如果属性Ai包含在INTO子句的属性列表中，则t［Ai,Ci］=(ai,C)；②如果属性Ai不包含在INTO子句的属性列表中，则t［Ａi,Ci］=(null,C)。

当用户安全级为C且C｛Ｌi,Hi｝时，拒绝该用户的操作请求，因为安全属性的值不能为空，为空表明用户没有操作关系R的权限。

(2)删除数据。删除语句的一般命令形式如下：

DELETE

ＦＲＯＭＲ

［WHEREp

］

R表示关系名称，p表示条件。其功能是从指定表中删除满足WHERE子句条件的所有元组。如果省略WHERE子句，则表示删除表中的全部元组。

当安全级为C的用户对关系R进行删除操作时，由于BLP*-特性的约束，对于元组t∈R，若t［TC］=C且满足p，则删除元组t。由于存在关系间完整性约束，因此在更高级别的关系实例中，该关系也被相应地消除。

(3)修改数据。修改数据的一般命令形式如下：

UPDATER

SETAi1=Si1,［Ai2=Si2,…］

ＷＨＥＲＥp

其功能是修改指定表中满足WHERE子句条件的元组。其中SET子句用于指定修改方法。

当安全级为C的用户对关系R中元组t进行修改操作时，首先找出满足条件的元组，即满足(t［TC］=C∧p的元组。执行该操作时，分两种情况考虑：第一种情况：如果主属性A1不包含在SET子句的属性列表中，而Ai(2≤i≤n)包含在SET子句的属性列表中，则：若t［TC］=C，则t［Ａi,Ci］=(si,C)；第二种情况：主属性Ａ1中的部分属性包含在SET子句的属性列表中，则：因为要求只有用户安全级等于实体安全级时，才允许进行修改，所以只考虑t［C１］=C的元组；并且需判断在关系中是否已存在元组U，它与修改后的结果表示同一实体且元组安全属性值为C(即U［Ａ1］=t［Ａ1］且U［ＴC］=C，t［Ａ1］表示修改后的值)。若存在该元组U，则由于这样会造成语义模糊问题且不满足多实例完整性，因而拒绝该修改操作；若不存在U，则允许该修改操作。8.2.2多级安全数据库实现策略

对于实现多级安全数据库的方法，TDI标准中提出了三种策略：

(1)可信过滤器(TrustedFilter，TF)：对DBMS本身无安全保证，只是在DBMS与用户应用程序之间设置一个可信过滤器，即在原有系统的基础上通过增加安全外壳来实现多级数据库的安全功能。显然，在这种方式下数据库系统的安全性完全依赖于OS。

(2)平衡保障(BalancedAssurance，BA)：在一个安全OS的基础上建立一个安全DBMS，由OS和DBMS来分担安全功能。这种方式下，DBMS的安全在很大程度上依赖于OS。

(3)一致保障(UniformedAssurance，UA)：实现一个安全DBMS来提供所有的安全功能。从DBMS的开发起步，将多级安全模型的安全机制和数据库加密在其内核中实现，与DBMS紧密结合在一起，其安全性较高。这种方式对OS的依赖少，DBMS可以单独评估。

上述三种方法在实现难度上和所提供的安全性能上均依次增强，具体采用哪种实现方法，应根据应用环境的需要，在对多种因素，如安全性、性能、成本等进行权衡考虑后

来确定。在实际应用中可能采取其中一种或多种结构的混合方式。8.3.1用户身份认证

由于数据库用户的安全等级是不同的，因此分配给他们的权限也是不一样的。用户身份认证是安全系统的第一道防线，目的是防止非法用户访问系统。用户身份认证是DBMS对访问者授权的前提，数据库系统必须建立严格的用户认证机制。8.3数据库系统安全机制最简单的方法是口令控制，用户输入ID和密码，系统验证其是否合法。除口令控制外，用户身份认证还可以采用比较复杂的计算过程和函数来完成(具体细节见本书第9章9.2节)。智能卡技术、数字签名技术和生理特征(如指纹、体温、声纹、视网膜纹等)认证技术的迅速发展也为具有更高安全

要求的用户身份认证提供了实用、可行的技术基础。8.3.2访问控制

访问控制的基本任务是防止非法用户进入系统以及合法用户对系统资源的非法使用。在数据库系统中，用户、进程等是访问动作的主体；而客体是数据、表、记录、元组、字段等。

访问控制就是指当主体请求对客体进行访问时，系统根据主体的标识符、安全级和权限以及客体的安全级、访问权限和存取访问的检查规则，决定是否允许主体对客体请求的存取访问方式。

访问控制分为自主访问控制(DiscretionaryAccessControl，DAC)、强制访问控制(MandatoryAccessControl，MAC)和基于角色的访问控制(RoleBasedAccessControl，RBAC)三种类型。

1.自主访问控制(DAC)

当完成系统登录和身份验证后，合法用户成功进入数据库系统。此时，安全保护机制便负责对用户的每一个操作请求进行检查并作出裁决，控制用户的操作，确保合法的用户执行合法的操作。DAC最早出现在20世纪60年代末期的分时系统中，是一种基于客体—用户的所属关系的访问控制，它规定用户必须获取某种权限后才能进行相应的数据库操作，并允许用户把他对客体的访问权授予其他用户或从其他用户那里回收他所授予的访问权。通常利用访问控制矩阵来实现用户对系统的自主访问控制(参见本书第3章3.4节)。例如，如表8-9所示，存在一雇员关系(姓名、工资、部门、经理)。李俊只是普通雇员，他对数据库只有执行SE

LECT查询的权限；而王明是财务主管，他不仅有使用SELECT查询的权限，还有修改雇员工资金额的权限；人事主管孙柯不仅具有SELECT查询权限，而且可以插人或删除雇员信息，并且可以改变雇员所属部门；总经理对所有客体的访问权都是ALL，表示他拥有全部访问权。表8-9访问控制矩阵实例目前的SQL标准对自主存取控制提供了支持，主要通过SQL的GRANT语句和REVOKE语句来实现。例如：雇员的创建者自动获得对该表的所有权限，通过GRANT语句可将这些权限转授给其他用户。

例如：

GRANTALLPRIVILIGES

ON雇员

TO王平

WITHGRANTOPTION;上述语句将表雇员的所有权限授予了总经理王平，其中的子句“WITHGRANTOPTION”子句表示用户王平同时也获得了“授权”的权限，即可以把得到的权限继续授予其他用户。而且，用户将某些权限授给其他用户后，可使用REVOKE语句将权限收回。例如：

REVOKEINSERTON雇员FROM王平CASCADE；

就将表雇员的INSERT权限从用户王平处收回，选项CASCADE表示，如果用户王平将雇员的INSERT权限又转授给了其他用户，那么这些权限也将从其他用户处收回。用户权限定义中的数据对象范围越小，授权子系统就越灵活。例如上面定义的授权定义到了字段级，而有的系统只能对关系授权。授权粒度越细，授权子系统就越灵活，但系统定义与检查权限的开销也会相应地增大。

DAC比较灵活，因此在多种系统和环境中得到了广泛应用。然而由于DAC允许使用者在没有系统管理员干涉的情况下对他们所控制的对象进行权限修改，因而使得DAC容易受到“特洛伊木马”的攻击。例如，用户A创建了文件X且其中含有一些信息，用户B创建了文件Y，由于B是文件Y的所有者，所以他可对Y进行任何操作。这样，他可以授权其他用户对Y进行操作，如授权A对Y进行写操作。现在考虑一段含“特洛伊木马”的程序P，它执行并完成某个特定功能，而且含有一段隐含代码。该代码包括对X的读操作和对Y的写操作。假设A要求执行程序P，这样执行P的进程在P的权限下进行，即所有的访问请求都要与A的授权对比检查，检查A是否有相应的授权。现在特别考虑一下隐含代码的执行，首先，申请对X的读操作，由于A是X的所有者，因此读操作被允许执行。然后，申请对Y的写操作，又由于A有对Y进行写操作的权力，所以写请求也得到满足。结果，在程序P的执行过程中，X的一些信息被读出，然后又被写入Y。因此，尽管B对X没有读权限，但此时通过对Y有读的权限可获取X的信息，即成功进行了一次“特洛伊木马”攻击。造成这一问题的根本原因就在于，这种机制仅仅通过对数据的存取权限来进行安全控制，而数据本身并无安全性标记。利用强制访问控制可以解决这个问题。强制访问控制通过对系统中的主、客体进行分类，然后在此基础上对信息的访问进行控制，来防止“特洛伊木马”的攻击。

2.强制访问控制(MAC)

MAC最早出现在20世纪70年代，80年代得到普遍应用。MAC是一种基于安全级标记的访问控制方法，它是多级安全的标志。在MAC中，DBMS所管理的全部实体被分为主、客体两类，DBMS为它们的每个实例指派一个访问级别。当两个访问级别可比时，主体能访问什么样的数据，由MAC模型通过规则来控制(参见4.5节)。

由于在MAC机制中存取权限不可以转授，所有用户必须遵守由数据库管理员建立的安全规则,因此与DAC相比，MAC机制更严格。

3.基于角色的访问控制(RBAC)

基于角色的访问控制最初是为了处理大型系统中数量庞大的用户管理和权限管理问题而提出的。RBAC在主体和权限之间增加了一个中间桥梁——角色。权限被授予角色，管理员通过指定用户为某特定角色来为用户授权，从而大大简化了授权管理，具有很强的可操作性和可管理性。角色不仅是用户的集合，也是一系列权限的集合，这与传统意义上组(group)的概念不同。一般我们提到组时仅仅表示它是用户的集合。这正是RBAC独特的地方，也是与组的本质区别。

现阶段的RBAC模型通常称为RBAC96，它由四个模型组成，下面分别介绍之。

RBAC96四个模型的关系如图8-1所示，模型中包含的各个要素如图8-2所示。图8-1RBAC96四个模型的关系图图8-2RBAC96模型的构成要素

RBAC核心模型包含了4个基本的静态集合，即用户集(Users)、角色集(Roles)、特权集(Permissions)(包括对象集(Objects)和操作集(Operators))以及一个用于运行过程中动态维护的集合，即会话集(Sessions)。用户集包括系统中可以执行操作的用户，是主动的实体；对象集是系统中被动的实体，包含系统需要保护的信息；操作集是定义在对象上的一组操作，它们构成了一个特权；角色集则是RBAC模型的核心，通过用户分配(UA)和特权分配(PA)使用户与特权关联起来。用户在一个会话期间可能会激活他所属的一系列角色，而这些角色又具有一定的权限许可。图中的实线箭头表示元素间的关系，单箭头表示一对一关系，双箭头表示多对多关系。

·RBAC0模型定义为包含这些基本元素，并且对角色、用户、权限没有任何限制。

·RBAC1在RBAC0的基础上增加了角色层次(Hierarchy)的概念，即角色与角色之间可以有某种继承关系，一个角色可以继承另一个角色的权限。在一个Session中用户不仅具有直接激活角色的权限，还具有该角色所继承的其他角色的权限。

·RBAC2在RBAC0的基础上增加了一些限制条件(Constraints)，允许角色、用户、权限之间有某种限制条件。比如如果一个用户具有了某种角色就不能再具有另外一种角色，如果一个角色拥有了某个权限就不能再拥有另外某个权限等。实际上RBAC1也是RBAC2的一个特例。

·RBAC3是RBAC1和RBAC2的结合。

RBAC属于策略中立型的访问控制模型，既可以实现自主访问控制策略，又可以实现强制访问控制策略。它可以有效缓解传统安全管理处理瓶颈问题，被认为是一种普遍适用的访问控制模型，尤其适用于大型组织的访问控制机制。8.3.3数据库加密

加密技术通常存在于敏感数据的传输过程或交换过程中，随着对数据库中数据安全性要求的提高，加密技术也逐渐被一些数据库管理系统采用。作为对访问控制技术的补充，加密技术进一步增强了系统的安全性。加密技术还可以防范特权用户对机密数据的非法访问。同时，在密钥未泄露的情况下，即便数据库管理系统被攻破，数据被窃，也难以造成泄密。数据库的加密与一般的网络通信加密有很大的不同。在数据库中，记录的长度一般较短，数据的生命周期一般较长，有的是几年甚至几十年，密钥的保存时间也相应较长。因此，数据库系统有其独特的加密方法和密钥管理方法。一般来说，一个好的数据库加密系统应该满足以下几个方面的要求。

(1)与通信加密相比，其信息保存时间长，不可能采取一次一密的方法进行加密，而应选用其他加密方式，使其达到实际不可破译的程度。

(2)实际加密后，存储空间不应明显增大。

(3)加密和解密速度要快，尤其是解密速度要快，使用户感觉不到解密和解密带来的系统性能的变化。

(4)对数据库的加密不应影响系统的原有功能，而应保持对数据库操作(如查询、检索、修改、更新)的灵活性和简便性。

(5)加密后的数据库仍能允许用户以不同的粒度对其进行访问。

(6)灵活的密钥管理机制，加、解密密钥存储安全，使用方便可靠。

1.数据库加密的实现机制

数据库加密的实现机制主要研究执行加密部件在数据库系统中所处的层次和位置，通过对比各种体系结构的运行效率、可扩展性和安全性，求得最佳的系统结构。可考虑在三个不同层次实现对数据库数据的加密，这三个层次分别是OS、DBMS内核层和DBMS外层。

(1)OS层加密。

在OS层无法辨认数据库文件中的数据关系，从而无法产生合理的密钥，对密钥合理的管理和使用也很难。所以，对大型数据库来说，在OS层对数据库文件进行加密很难实现。(2)DBMS内核层加密。

在DBMS内核层实现加密，是指数据在物理存取之前完成加/解密工作。这种方式势必造成DBMS和加密器(硬件或软件)之间的接口需要DBMS开发商的支持。这种加密方式如图8-3所示。图8-3在DBMS内核层实现加密关系图

DBMS内核层加密方式的优点是加密功能强，并且加密功能集成为DBMS的功能，可以实现加密功能与DBMS之间的无缝耦合。对于数据库应用来说，库内加密方式是完全透明的，不需要做任何改动就可以直接使用。库内加密方式的缺点主要有：一是对系统性能影响比较大，由于DBMS除了完成正常的功能外，还要进行加／解密运算，因而加重了数据库服务器的负担；二是密钥管理风险大，加密密钥与库数据一同保存在服务器中，其安全性依赖于DBMS的访问控制机制；三是加密功能依赖于数据库厂商的支持，而DBMS一般只提供有限的加密算法与安全强度供选择，因而其自主性受限。

(3)DBMS外层加密。

DBMS外层加密是将数据库加密系统做成DBMS的一个外层工具(如图8-4所示)，加／解密过程发生在DBMS之外，BMS管理的是密文。加／解密过程可在客户端实现，也可由专门的加密服务器或硬件完成。图中，“定义加密要求工具”模块的主要功能是在创建了一个数据库表后，定义如何对每个数据库表数据进行加密。“数据库应用系统”的功能是完成数据库的定义和操作。数据库加密系统将根据加密要求自动完成对数据库数据的加/解密。图8-4在DBMS外层实现加密关系图库外加密与库内加密方式相比其优势为：由于加／解密过程由客户端或专门的加密服务器实现，因此减少了DBMS的设计复杂度与运行负担；可以将加密密钥与所加密的数据分开保存，加密密钥可以保存在加密服务器中，甚至是硬件中，提高了安全性；有了客户端与服务器的配合，可以实现端到端的网上密文传输。

库外加密的主要缺点是加密后的数据库功能受到一些限制，例如加密后的数据无法正常索引，同时数据加密后也会破坏原有的关系数据的完整性与一致性。

2.数据库加密的粒度

与一般的数据加密技术不同，数据库系统因为具有文件(表)、记录、属性和数据元素等多个层次的概念，所以对数据库信息的加密也就可以分别选用以表、记录、字段作为加密的基本单位的方案。各种加密粒度的特点不同，加密粒度越小，系统灵活性越好且安全性越高，但实现技术也更复杂，对系统的运行效率影响也越大。

(1)表级加密。

表级加密的对象是数据库文件，这种加密方法类似于操作系统中文件加密的方法。即每个表与不同的表密钥运算，形成密文后存储。利用这种方法，数据的共享是通过用户用解密密钥对整个数据库文件进行解密来实现的。即使用户只需查看或修改某一记录，也需要将整个数据库文件解密，这不仅极大地增加了系统的时空开销，而且也无法控制用户对未授权信息的访问。因此，这种方法只适用于能回避这些限制的应用环境。

(2)属性级加密。

属性级加密又称为“域加密”，即以表中的列为单位进行加密。一般而言，此方法适用于属性的个数少于记录的条数，且需要的密钥数相对较少的情况。如果只有少数属性需要加密，那么属性加密是可选的方法。

(3)记录级加密。

一般而言，数据库系统中每条记录所包含的信息都具有一定的封闭性，即从某种程度上讲，它独立完整地存储了一个实体的数据。因此，基于记录的加密技术是最常用的数据库信息加密手段。数据库系统中每条记录在各自密钥的作用下加密成密文并存放于数据库文件中。

记录的查找是通过将需查找的值加密成密文后进行的。该方法的缺点是在解密一个记录的数据时，无法实现对在这个记录中不需要的数据项不解密。

(4)数据项级加密。

数据项级加密以记录中每个字段的值为单位进行加密，数据项是数据库中最小的加密粒度。

采用这种加密粒度，系统的安全性与灵活性最高，但实现技术也最为复杂。这样，不同的数据项使用不同的密钥，相同的明文形成不同的密文，抗攻击能力得到提高。不利的方面是，该方法需要引入大量的密钥，一般要周密设计自动生成密钥的算法，密钥管理的复杂度大大增加，同时系统效率也受到影响。

3.加密算法

加密算法是数据加密的核心。常用的加密算法包括对称密钥算法和公开密钥算法(参见9.2和9.3节)。目前还没有公认的专门针对数据库加密的加密算法，因此一般根据数据库特点选择现有的加密算法来进行数据库加密。对称密钥算法的运算速度比公开密钥算法快，二者相差大约2~3个数量级；并且在公开密钥算法中，每个用户有自己的密钥对，如果不同用户具有不同的数据库加密密钥，将产生异常庞大的数据存储量。因此，在数据库加密中一般采取对称密钥的分组加密算法。

4.密钥管理

加密数据库中的密钥管理比其他系统的密钥管理更为困难与复杂。例如在数据通信加密系统中，通信双方使用的密钥可通过其他安全途径传递。而且，每次通信的会话密钥是动态生成的。而在数据库加密系统中，密钥的某些信息必须存放在机器中。

数据库加密系统一般对不同的加密单元采用不同的密钥，越是细小的加密粒度，所产生的密钥数量越多，密钥管理也就越复杂，带来的密钥管理问题也越多。以加密粒度为数据元素为例，如果不同的数据元素采用同一个密钥，由于同一属性中数据项的取值在一定范围之内，且往往呈现一定的概率分布，攻击者可以不用求原文，而直接通过统计方法即可得到有关的原文信息。另外，数据库客体之间隐含着复杂的逻辑关系，一个逻辑结构可能对应着多个数据库物理客体，所以数据库加密不仅密钥量大，且组织存储工作比较复杂，需要对密钥实现动态管理。因此，良好的密钥管理机制应既可以保证数据库信息的安全，又可以进行快速的密钥交换，以便进行数据解密。对数据库密钥的管理一般有集中密钥管理和多级密钥管理两种体制。集中密钥管理方法是指设立密钥管理中心。在建立数据库时，密钥管理中心负责产生密钥并对数据加密，形成一张密钥表。当用户访问数据库时，密钥管理中心核对用户识别符和用户密钥。通过审核后，由密钥管理中心找到或计算出相应的数据密钥。这种密钥管理方式方便用户使用和管理，但由于这些密钥一般由数据库管理人员控制，因而权限过于集中。目前研究和应用比较多的是多级密钥管理体制。在加密粒度为数据项的三级密钥管理体制中，整个系统使用一个主密钥MK、每个表上的表密钥TK以及各个数据项上的数据密钥等三级密钥结构。表密钥被主密钥加密后以密文形式保存在数据字典中，数据元素密钥由表密钥及数据项所在行、列通过某种函数自动生成，一般不需要保存。在多级密钥体制中，主密钥是加密子系统的关键，多级密钥管理体制的安全性在很大程度上依赖于主密钥的安全性。8.3.4推理控制

1.多级安全数据库系统中的推理问题

推理，即从已知的信息推出新的信息。在安全数据库系统中的推理问题是指如何阻止一个用户推理出未被授权访问的信息。由于数据库中的数据存在各种内在关联，数据用户有可能根据他所允许知道的信息，利用数据之间的内在逻辑联系，推断出某些未被授权访问的信息。这种推理过程称为推理通道。产生推理的原因很多，下面给出最常见的两类：

(1)利用不同级别数据之间的函数依赖进行推理分析。由于数据表的属性之间存在着“函数依赖”与“多值依赖”关系，因此有可能产生推理通道。

【例8-1】

假定某个公司职员的工资是由职员的职务决

定的。该公司数据库存在一个关系模式R(Employee，Rank，Salary)。假设Salary属性的安全级为绝密，Rank属性的安全级为机密。同时，R中存在函数依赖：Rank→Salary。该函数依赖表明在元组t内，对于一个给定的Rank值，总有惟一的Salary值与之对应。对于一个安全级为机密级的用户，如果他知道Rank和Salary值之间存在函数依赖关系，那么他就可以根据职务Rank的信息推理出未授权的Salary信息，从而对数据库的安全构成威胁。产生上述推理通道的根本原因在于：给数据分配密级标签时没有考虑函数依赖Rank→Salary。

(2)执行多次查询，利用查询结果之间的逻辑关系进行推理。

【例8-2】

考虑两种关系：飞机关系P(NAME，ID)

和执行任务关系D(ID，TYPE，DEST)，其中属性NAME表示飞机名称，属性ID表示飞机编号，属性TYPE表示任务的性质，属性DEST表示飞行目的地。两种关系可根据ID属性进行连接运算。按表划分密级，规定飞机关系P中所有记录均为机密级，任务关系D中除DEST属性值为“A区域”的记录为绝密级外，其它记录为机密级。机密级用户可用如下的查询推导出任务关系D的绝密信息：

SELECTEMPLOYEE.NAME

WHEREEMPLOYEE.ID=TRIPS.ID

ANDTRIPS.DEST="PEKING"此查询是标准的“选择—投影—连接”关系运算，查询的结果将暴露出任务关系D的绝密信息。产生上述推理的原因在于关系运算在数据库管理系统中进行时，没有对关系运算中的数据密级进行限制，使低密级用户有可能在关系运算的查询条件中利用高密级数据进行数据推理攻击。

推理与直接泄露(directdisclosure)是有区别的，前者是指必须经过推理来获得信息，后者是指信息被直接泄露给未获授权的用户。推理通道与隐通道也不相同，它基于一组特定的数据值和逻辑蕴涵规则，不需要一个处于高安全级别的主动代理从高安全级向低安全级发送信息。

2.推理通道

推理通道的分类有多种方式。依据低安全级主体能够推测敏感信息的程度可划分为:

(1)演绎推理通道(deductivechannel):

低安全级主体通过演绎推理可以得到敏感信息并能提供形式化证明。

(2)诱导推理通道(abductivechannel):

低安全级主体通过演绎推理可以得到敏感信息，但必须借助一些假设的公理才能证明。

(3)概率性推理通道(probabilisticchannel):

低安全级主体借助一些假定的公理降低敏感信息的不确定性，但不能完全确定出敏感信息的内容。

根据推理通道的存在时间可以将其划分为静态推理通道和动态推理通道：

(1)静态推理通道(staticinferencechannel):

根据低密级信息和约束条件推理出高安全级信息。

(2)动态推理通道(dynamicinferencechannel):

在数据库处于特定状态时才存在的推理通道。

推理通道的存在是多级安全系统中的重大安全隐患，系统必须提供一个机制来检测和排除推理通道。

3.推理控制

推理控制是指推理通道的检测与消除。推理控制问题至今仍处于理论探索阶段，没有一种从根本上解决推理通道的方法，这是由推理通道问题本身的多样性与不确定性所决定的。

目前常用的推理控制方法可以分为四种：语义数据模型方法、形式化方法、多实例方法和查询限制方法。

1)语义数据模型方法

语义数据模型方法常用于数据库设计中的推理控制。在数据库设计阶段要求设计者确定数据库客体，包括数据、元数据以及约束等及其安全级别。对于数据库设计者和用户来讲，不仅要清楚输入到数据库中数据的安全级别，而且要求在为数据指定安全级别时能够预见到潜在的推理通道。在理想情况下，为了阻止所有未经授权的信息泄露，应该遵守多级安全数据库的基本规则：一个数据项的安全级别应该支配所有影响它的数据的安全级别。如果一个数据项的值受不被其安全级支配的数据影响，信息流就会流向其它安全级。现有的技术主要包括使用安全约束在多安全级数据库设计期间为数据库模式指定适当的安全级别,并将安全约束用语义数据模型进行表示。应用语义数据建模技术最早的例子是Hinke的ASDViews工程。在该工程中，在数据库设计中通过构造语义关系图来表示可能的推理通道。其中，数据项被表示为结点，它们之间的关系由连接结点的边表示。如果两个结点之间存在两条路径，一条路径包含了图中所有的边，而另一条路径不包含图上所有的边，那么两结点之间就有可能存在推理通道。然后进一步分析确认是不是真正的推理通道。相应的解决方法是提升边的级别，直到所有的推理通道被关闭。该方法的缺点是提高导致推理问题发生的数据项的安全级的方法在实际中受到限制。另外，多实例也能提供部分解决方法。

2)形式化方法

函数依赖定义如下：

设

R

是一个关系模式，U代表关系R的属性集,X、Y是U的子集。

对于任何关系

R

的实例r,r

中不存在具有同样的X属性值且同时具有不同的Y值的两个元组，即如果t［X］=s［Y］，则t［Y］=s［Y］，则称Y函数依赖于X，记作X→Y。如果一个函数依赖对于低安全级别的用户而言是已经知道的，则会产生推理问题。如例8-1所述，由于职务与薪水之间存在函数依赖关系，且低安全级用户知道这个函数依赖的存在，那么他就可以根据职务Rank的信息推理出未授权的Salary信息。

Su和Ozsoyoglu给出了消除函数依赖和多值依赖推理的形式化算法。在该算法中，函数依赖的安全级粒度是属性级，多值依赖的安全级粒度是记录级。对于函数依赖推理，采用提高属

性的安全级的算法来消除推理通道；对于多值依赖推理，该算法的核心思想是把存在多值依赖推理的关系实例中的某些元组的安全级升高，经过元组的安全级调整后，新的关系实例不再存在多值依赖推理。

3)多实例方法

如前所述，多实例允许数据库中存在关键字相同但安全级别不同的元组，即把安全级别作为主关键字的一部分。这样，即使数据库中存在高安全级别的元组，也允许低安全级别的数据插入，从而解决了利用主关键字的完整性进行推理的问题。多实例方法的缺点是使数据库失去了实体完整性，同时增加了数据库中数据关系的复杂性。

4)