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
