分布式数据库BLP安全模型介绍

 

多级安全BLP模型

1 基本概念

主体( Subject ) ：引起信息流动或改变系统状态的主动实体。如用户 ,程序,进程等。

客体( Object ) ：蕴含或接收信息的被动实体 , 信息的载体。如DB、表、元组、视图、操作等。

安全级(Security Level)：主体和客体的访问特权 , 一般主体安全级表示主体对客体敏感信息的操作能力, 客体安全级表示客体信息的敏感度。

 

自主型访问控制(Discretionary Access Control)：是基于一种访问控制规则实现主体对客体的访问。这种控制规则是自主的，自主是指某一主体能直接或间接的将访问权或访问权的某些子集授予其他主体。用户对信息的控制是基于用户的鉴别和存取访问规则的确定。

强制型访问控制(Mandatory Access Control)：通过无法回避的存取限制来防止各种直接的或间接的攻击。系统给主体分配了不同的安全属性，并通过主体和客体的安全属性的匹配比较决定是否允许访问继续进行。

2 自主型访问控制(Discretionary Access Control)

自主型访问控制基于用户的身份和访问控制规则。自主保护策略管理用户的存取，这些信息是 以用户的身份和授权为基础的，它们详细说明了对于系统中的每一个用户(或用户组)和每一个客体，允许用户对客体的存取模式(例如读，写或执行)。根据指定的授权，用户存取客体的每一个要求都被检查。如果存在授权状态，则用户可以按指定的模式存取客体，存取被同意，否则被拒绝。DAC之所以被称为自主的，是因为它允许用户将其访问权力赋予其它的用户。 而且对于一个客体的否定授权高于对同一客体的肯定授权。自主策略的灵活性使它们适合于多种系统和应用。由于这些原因，在多种执行中，自主策略被广泛地应用，尤其在商业的和工业的环境中。

2.1 自主访问控制的实现

自主访问控制的实现主要有三种方式 :1.访问控制表(ACL);2 .访问能力表(Capability) 3.授权关系表。综合以上三种存取控制方法的优缺点，访问控制表的方法以其在权限的授予和回收的方面的高效率，在商业软件中得到了广泛应用。

文件存取控制表：

文件存取控制表

ACL的数据控制类型：

ACL 的数据控制类型

3 强制型访问控制

3.1 BLP模型

D.E.Bell和 L.J.La Padula 于1973年模拟军事安全策略创建的计算机系统安全模型, 74年改进, 76年用于Multics操作系统。

1.      

Bell- LaPadula模型是存取控制模型中典型的一种，它用多级安全的概念对主体和客体的安全进行分级和标记，并同时采用了 自主存取控制和强制存取控制的策略。强制策略以系统中主体和客体的等级为基础控制数据的存取。与客体关联的安全级别反映了包含在客体内的信息的敏感性。与用户关联的安全级别，也称为许可权反映了用户的可信赖性。不同安全级的主体对客体的存取有一系列性质约束。其中最著名的是简单安全性 (禁止向上读)和*一性质(禁止向下写)。

BLP模型的基本思想是 :确保信息不向下流动，从而保证系统内的信息是安全的。 BLP模型的信息不向下流动是通过下面两个规则来保证的:

(1) 简单安全特性:当一个主体的安全级支配另一个客体的安全级时，主体才‘具有对客体进行“读”操作的权限 :

(2) * 一特性:当客体的安全级支配主体的安全级时，主体才具有对客体进行“写”操作的权限。

 BLP模型图 :

BLP 模型

满足了上述两个规则即控制了系统中信息的流动，保证所有安全级别上的主体只能访问其具有访问权限的客体，从而保证信息不会向下流动。此外，系统还有一个自主安全规则 :

(3) ds 规则:每个存取必须出现在存取矩阵中，即一个主体只能在获得了所需的授权后才能执行相应的存取。

mn1 … mnn

m11 … m1n

存取矩阵：

 

 

 

 

 

 

 

 

 

MAC 部分由简单安全特性和*-特性组成，通过安全级来强制性约束主体对客体的访问。

DAC 通过访问控制矩阵按用户的意愿限制主体对客体的访问。

3.2 BLP模型实现

当客户与服务器相连后，客户每发送一个 SQL语句给服务器，服务器首先分析、解释该语句，然后经分布式事务处理分解成其他站点上的消息发送给站点。当在某个站点上的用户要访问某个数据库对象时，首先经过强制访问控制安全检查，同时记录审计信息 :再经过自主访问控制检查，确认是否有访问权限，同时也记录审计信息 ;然后经资源分配，进入访问具体的元组对象时，再做“向下读”、“同级写”强制访问控制检查，通过后面作具体的数据操作，并记录审计信息。

现有的 DBMS产品实现的客体标记粒度基本都为元组级。

3.3 BLP模型局限性

BLP模型产生于七十年代。直觉上，该模式是为了适应于军方信息系统中依据军衔、职

务以及军队内部的组织层次。其缺点主要是它太严格，以至于在某些环境下不能应用。例如，在一个商用系统中，并不是总能为用户分配一个允许密级，或为数据分配一个敏感级别。因此当前的一种趋势是将强制存取控制策略和自主存取策略结合起来建立安全模型。

机密性、完整性和可用性是多级安全数据库必须具备的三要素，然而 BLP模型在机密性、数据完整性和可用性方面都存在缺陷。总结对该模型的理论研究的不同的观点，一般认为，模型的局限性有如下几个方面 :

首先，BLP模型机密性不高。根据BLP模型的“向下读，向上写”原则，低安全级主体不能读取高密级数据却可以修改高密级数据，这样敏感信息的机密性得不 到保证。

其次，高密级数据的数据完整性得不到保证。低安全级用户能够窜改高密级数 据，因此高密级的数据有可能变成“垃圾”数据，所以高密级数据的数据完整性难 以保证。

再次，BLP模型可用性差。“向下读，向上写”的策略能够有效地防止低密级用户获取敏感信息， 同时也限制了高密级用户向非敏感客体写数据的合理要求，降 低了系统的可用性。 当低级别进程向高级别进程发送一段数据后，虽然不违背模型的原则，但由于不能“下写”，高级别的进程就无法向低级别的进程发送诸如回应信息，而对于低级别的进程来说，它永远无法知道它所发送的信息是否正确地转送到了目的地，信息就如同送到了一个“黑洞”中。

4 基于多级安全性分类级别标记的强制访问控制

4.1 BLP模型的安全特性

BLP 模型从形式化的角度描述了安全系统中所允许的信息流动路径。1991年Jajodia和Sandhu提出基于多级安全性分类级别标记的多级安全数据库。把用户和数据分为若干个安全级别， 并禁止信息从高处流向低处。

典型的安全性级别分类：绝密-TS(Top Secret)、机密-S(Secret)、可信-C(confidential)、和无分类-U(Unclassified)。

   一个安全数据库系统，包括主体安全集合 S ，客体集合 O 对 S 中的每个主体 s 和 O 中的每个客体 o ，存在固定的安全类 SC(s),SC(o) 。

   具有一下两个特性：

  （ 1 ）简单安全特性：当且仅当 SC(o) ≤ SC(s) 时，主体 s 才可以读客体 o （下读）

  （ 2 ）＊－特性：当且仅当 SC(s) ≤ SC(o) 时主体 s 才可以写客体 o （上写）

原因：一个拥有 TS(Top Secret) 许可证级别的用户（主体），可能会制作一个拥有 TS 安全分类级别的客体拷贝，随后把它作为一个新的客体以安全性分类级别 U(unclassified) 写回，这就使得原来为安全分类级别 TS 的这个客体，在整个系统中都变成可见的了。

4.2 多级安全数据库

行和列作为对象：将关系R(A1, A2,…, An)扩展为R(A1, C1, A2, C2,…, An, Cn, TC)。 并且每个每个元组 T(Tuple) 的值是 T 中所有分类属性值中的最高值。

视在码：是一个属性的集合。它由常规关系中的主码形成。对于拥有不同许可证级别的主体，所包含的数据是不一样。

1 Employee关系：(设Name是视在码)

Name	Salary	JobPerformance	TC
Smith(U)	40000(C)	Fair(S)	S
Brown(C)	80000(S)	Good(C)	S

  

2具有许可证级别C的用户看到的Employee关系： (select * from Employee)

Name	Salary	JobPerformance	TC
Smith(U)	40000(C)	Null(C)	C
Brown(C)	Null(C)	Good(C)	C

3具有许可证级别U的用户看到的Employee关系： (select * from Employee)

Name	Salary	JobPerformance	TC
Smith(U)	Null(U)	Null(U)	U

 

4 Smith元组的多重实例：

一个带有许可证级别C的用户发出如下SQL:

   Update Employee Set JobPerformance = ‘Excellent’ Where Name = ‘Smith’

Name	Salary	JobPerformance	TC
Smith(U)	40000(C)	Fair(S)	S
Smith(U)	40000(C)	Excellent(C)	C
Brown(C)	80000(S)	Good(C)	C

 

如果一个 S 级别的用户要更新 Brown 的 JobPerformance 怎么办？

通过研究我们发现，用户需要的读写权限往往不相同，一般要求读权限要比写权限大。因此，需要将读写权限分开 (相应地读写范围也要分开)来提高系统的可用性。例如，可以定义一个读权限为S，写权限为C的用户来完成UPDATE。

4.3 多级安全数据库系统中的多实例问题

所谓的多实例 (Polyinstantiation),是指在DBMS中同时存在多个具有相同主键的同层次客体，它们的安全级别是不同的。在数据库系统中，实体完整性要求主键唯一标识关系中的一个元组，并且不能为空。但在多级安全语义下，主键的唯一性要求成为系统最为明显的 (信号)隐蔽通道的来源。如低级别主体在插入某元组时获得主键冲突的信息时，他就可以判断有高级别的同主键元组存在。自然地，避免产生这类隐蔽通道的方法就是对关系的主键进行扩展，使之包括元组的安全标记，成为实际主键 .将用户定义的主键称为显式主键，当一个多级关系包含多个具有相同显式主键的元组时，则称发生了多实例。因此，在多级关系中，真正的主键是显式主键与元组安全标记的复合。但由于不同的客体标记粒度，复合主键的具体形式还有一些变化。

一般认为，高级别的多实例元组代表的是真实世界的描述。而低级别元组则是 该事实的封皮(Cover Story)。总体而言，多实例的目的是为了执行多级安全策略，阻止隐蔽通道的发生。但多实例会在 DBMS中导致严重的复杂性和多义性(数据语义不确定性)，这一点在多级数据模型中表现最为明显。

4.4 多实例的商用系统解决方案

三种 DBMS产品:Informix, Sybase和ORACLE，它们实现的客体标记粒度都为元组级，它们在处理多实例问题的时候各有特点下面简要分析如下 :

Informix的元组主键自动包括元组安全标记。因此，多实例情况可能发生并且不能抑止，对高级别主体和低级别主体导致的多实例没有进行特殊处理，对多实例没有提供消除的选项，问题的解决需要应用开发者根据应用逻辑的需要进行处理。

Sybase提供元组级标记，处理方式于 Informix相同。

ORACLE提供了一种较为完善的机制。 ORACLE可以运行于两种模式之下。在 DBMS MAC模式下，DBMS同时管理不同级别数据，元组安全标记可以包含到元组的实际主键中也可以不包含进去。为此， ORACLE提供了表一级的多实例选项。该选项打开时，元组主键包括元组的安全标记，允许多实例发生。并且，元组安全标记一旦被包含进元组主键，它就不能从中移出 ;选项关闭时，元组标记不包含进元组的主键中，阻止多实例发生。在后一种选择情况下，会导致高级别主体插入的拒绝和隐蔽通道问题。

参考文献：

[1] 马骏 空间数据Sec-VBta安全构件生成器的设计和实现 2003.5

[2] 程万军 多级安全数据库管理系统的研究与实现 2003.5

[3] 武立福 多级安全数据库系统的研究与实现 2004.1

[4] 陆晓华 安全数据库管理系统Softbase（X）的研究和实现 2002.5

 

 

附录：

B={S, O, A}

S: Subject

O: Object

A: Access

A={r, w, e, a}

 read, write, execute, add

M: Matrix

F: Function

 

C: Current

H: Hierarchical

R: Request

D: Decision