采用类似于“同级读，同级写”原则的多级安全关系数据模型研究

多级安全（Multilevel security，简称MLS ），是指计算机网络系统可以处理多个不同密级的信息并保证它们的保密性安全的一种解决方案。多级安全系统，满足BLP保密性模型，即用户根据其安全许可（Security Clearance）和知悉范围（Need to Know，简称N2K），满足“不上读”和“不下写”两个安全属性。满足BLP模型的系统被证明其保密性是安全的，即基本安全定理。顾名思义，多级安全系统满足BLP模型，低密级用户不能上读高密级信息，高密级用户不能向低密级系统或网络上写高密级信息。这两种情形都造成了高密级信息向低密级用户的泄漏，是被禁止的情形。

另外，在一般的多级安全关系数据库中，为了对低许可级的主体隐藏高密级的敏感信息，引入了多实例（Polyinstantiation）和伪元组（Cover Story）的概念，使得真实世界的单个实体在一个多级关系表中会产生多个元组，每个元组对应着不同密级的实例，并为每个字段设置相应的密级附加字段，以记录各数据项的密级信息。当不同实例间的数据差异很大时，这样的设计是合理的。然而，研究表明实际应用时，数据库中敏感数据（即需要对低许可级主体隐藏的数据）所占的比例通常仅仅只有约5%，这意味着多实例间的数据差异通常非常小，高密级的元组除个别字段外，绝大部分数据（90%以上）与低密级元组相同[3]，造成数据的大量冗余，而且数据定义与操纵规则相当复杂。

为了解决上述问题，本文提出了一种新的模糊级别的多级安全关系数据库模型，采用类似于“同级读，同级写”的原则，既可以防止“高”许可级用户查看或修改“低”密级的信息，造成信息泄漏；又可以防止“低”许可级主体修改“高”密级的数据，形成隐通道，还可以通过多密级共享元组来减少数据冗余。

1 对基于多实例的多级关系的改进

当不同的元组具有相同的主键，却具有不同的密级时，称为多实例。在给定的格中，对每一个许可级都有一个关系实例，代表该许可级的用户眼中的数据版本。例如，对关系模式R而言，实例RC就是许可级为C的用户所看到的元组的集合。多实例是一个应用多级安全的系统所固有的属性[4-5]。

在SeaView[6]和Jajodia、Sandhu[4-5，7]等人对多级安全数据模型的研究中，对每一个属性定义其相应的密级，并引入了多实例，但由于采用“向下读，向上写”的规则，因此，存在隐匿通道问题。然而根据前面的分析，实际应用中不同密级实例的大部分属性值可能是相同的，甚至可能只是元组密级属性TC值不同而已，造成大量的冗余数据，而且，当许可级较多时，数据的冗余量将会成倍增长。因此，为了进一步减少冗余，本模型再将所有属性值均相同的多个不同密级的元组合并成一个元组，用一种类似于通配符的数据，即安全模式（Security Pattern）来表示这些密级。强制访问控制就是通过对比主体的许可级别和客体的安全模式是否匹配来确定主体是否能够存取客体。

安全模式定义及其运算规则。

因此，一个改进后的多级关系可以定义为：

定义2：设有R（A1，A2，…，An，SP），其中，Ai是定义在域Di上的数据属性，SP表示元组的密级属性，SP的值为安全模式，为所有有权访问该元组的主体所支配。称R为多级关系模式。

可见本模型不仅形式简单，而且由于它保持了标准关系数据库的特点，因此易于在目前常见的DBMS上实现。又由于本模型不同于其他学者提出的模式，不再用属性TC来表示某一个密级别，而是一种称为安全模式的数据来表示多个密级别，只有许可级别与此安全模式匹配的主体才可以访问此元组，类似于“同级读，同级写”的访问控制规则，显然不可能泄漏敏感数据，也不存在隐通道。

2 模型的完整性规则

由于本模型扩展了标准的关系数据模型，引入了元组密级属性，为了保证数据库中数据的完整性和一致性，本模型对标准关系模式的完整性规则进行了增强。

2.1 实体完整性

本模型中，在标准关系模式的基础上增加了表示元组密级的属性SP，标准关系模式的直觉意义上的主键，称外观主键AK（Apparent primary Key），真正的主键是外观主键加元组密级属性（即AK∪SP）。

实体完整性：多级关系R的一个实例r满足实体完整性，当且仅当，对r的所有元组t，若Ai∈AK则t[Ai]≠null且t[SP]≠null。即假定AK是定义在关系模式R上的外观主键，构成AK的所有属性均不能为空，元组的密级属性SP也不能为空。

2.2 参照完整性

参照完整性：R和S为多级关系，S参照了R，AKr为R的外观主键，FKs为S的外键，许可级别为c的主体所支配的R的实例rc和S的实例sc满足参照完整性，对sc的所有元组ts，或者ts[FKs]=null，或者存在tr∈rc且tr[AKr]=ts[FKs]和tr[SP]&ts[SP]&c=c。

任何元组只能参照其他关系（或自身）中存在的元组，且参照及被参照的元组必须受同一许可级别主体支配。

2.3 实例间完整性

实例间完整性反映的是对给定格的所有密级，其对应的各个实例之间的联系和约束。

由于本模型中讨论的是模糊级别的格，采用的是类似于“同级读，同级写”的规则，故不保证一个实体在不同的许可级的关系实例中均可见。如果不可见，则表明本许可级别未被授权存取此实体。但如果实体的两个实例所有属性值均相同时，可用同一个实例来表示，并在此实例的SP属性中将这两个密级合并表示。

此规则要求对于任意许可级别c和任意实体，多级关系R中至多存在一个实例t受许可级别为c的用户支配。

3 读写规则

3.1 读规则

在本模型中，不是为每一密级创建1个元组，而可能是多密级别共享1个元组。每个密级别对应的关系实例的元组为多级关系中可由此许可级主体支配的元组组成。因此本模型中读规则为：用户在其有效的读范围内，读取元组安全模式SP值与主体许可级匹配的元组。如果某AK值对应的所有元组中所有SP值都与主体许可级不匹配，表明此实体的所有信息均对此主体隐藏了。

例1：假设某情报机构使用MLS数据库记录职员的信息。假定系统中密级分为四级分别是a、b、c、d（分别用1000，0100，0010，0001表示）。系统中存在2个多级关系：职员关系Empl与部门关系Dept，外观主键分别为EName和DName，元组如表1、表2所示（其中SP部分的字段对用户是透明的，下同）。

根据上面的读规则，许可级别为的a，b，c，d的用户看到两表的关系实例如表3~表8所示。

不同级别的用户，Empl引用的DName都是Dept中存在的DName，而且是受同许可级的主体支配。可见，不同用户视图都满足参照完整性。同样本例中多级安全数据库满足前述的其他各项完整性约束规则。

3.2 插入操作

情形1：对单个多级关系的插入操作。

（1）检查多级关系的用户视图中是否存在与待插入的外观主键值相同的元组，如果存在则插入失败；否则按步骤（2）进行；

（2）检查多级关系中是否存在各数据项与待插入元组各数据项相同的元组，如果存在则将此元组的SP值sp用sp&c代替（c代表执行插入操作的用户的许可级），插入完成；否则继续下面的步骤。

（3）插入此元组，并将该元组的密级属性置为用户的许可级。

例2：许可级为b的用户执行以下插入语句：insert into Dept values（‘机要’，‘1-101’），插入后的效果如表9所示。

情形2：若是对有外键的多级关系进行插入操作，还要满足参照的完整性。亦即先检查被参照关系的用户视图中是否存在相应AK=fk（fk表示待插入元组的外键值），若存在，则直接按情形1完成插入操作；否则，插入失败。

3.3 更新操作

由于在本模型中，将多个不同的密级元组合并成1个元组，因此，1个元组可能代表多个密级的实例，一个许可级主体的更新操作不应该影响其他许可级的视图。

（1）检查待更新的元组的SP值是否为某单个密级（即二进制数只有一位为1，下同），若是，则表明此次更新不会影响其他许可级的视图，因此可按标准关系模型的更新操作进行；否则，按以下步骤。

（2）先将此元组的SP值sp更新为sp&~c（c表示执行更新操作的主体的许可级，下同），再按“插入操作”插入新元组，新元组各项为待更新的元组的新值。

例4：许可级为b的用户欲执行命令：update dept set addr=‘4-201’ where DName=‘管理’，根据表6可见，元组{管理，3-201，1100}代表了a、b密级的实例。为了不影响a的实例，先将此元组的SP从1100更新为1000，再执行插入操作：insert into dept values（‘管理’，‘4-201’）。

3.4 删除操作

在本模型中，1个元组可能代表多个密级的元组，故删除规则应按下面的步骤进行：

（1）检查待删除元组的SP值是否为某单个密级，若是，则可按标准关系模型的删除操作进行。否则，按以下步骤。

（2）先将此元组的SP值sp更新为sp&~c（c表示执行删除操作的主体的许可级）。

本模型继承了多实例的概念，并作了改进。如果多个实例仅仅只有元组的密级属性不同，则直接将这些实例用1个元组表示，其SP值为这些密级属性的并集，由于实际应用中敏感数据很少，故这种规则在应用中是合理的，从而大大减少了数据的冗余。

本文提出的多级关系数据模型中使用类似“同级读，同级写”的规则，任何许可级的用户都无法看到其他密级的元组（除非与此许可级用户共享该元组），同时，也无法修改其他密级的元组（即使与此许可级用户共享元组，修改也不会影响其他许可级的用户视图），既避免了隐通道，又防止了敏感数据的泄漏。