多级关系的多实例属性及其安全等级

多实例（Polyinstantiation）是指在多级安全数据库管理系统中同时存在多个具有相同主码值的实体。多实例问题首先在SeaView项目中被提出来并加以系统研究。常见的多实例主要有两种：多实例元组和多实例属性。多实例元组是指多实例情况发生在元组一级，而多实例属性则是指多实例情况发生于数据实体一级。相比而言，多实例关系不太常见。

多实例元组的关系包含多个具有相同主码值的元组，这些元组的主码的安全等级不同。例如，表5-13表示的就是多实例元组。在这个例子中，Wname是原数据库关系的主码，Wname有不同的射程和数量。这些信息对一般的用户是保密的，也就是说，要访问真实的信息需要具有一定的安全等级。此时，在多实例元组中，存在着不同安全等级的相同主码值。整个元组的安全等级TC则是这个元组所有数据元素的安全等级的最小上界。在实际的数据库中，TC可以不存储。可以认为表中多实例元组代表着现实中两个不同的实体，也可以认为只代表现实中的单个实体。关系本身并不能指出这两种建模哪种是正确的。

表5-13 多级关系的多实例元组

表5-14表示的是多级关系的多实例属性，各个属性具有各自的安全等级。但是两个具有相同主码值的安全等级是一致的。这两个元组代表了现实中的同一个实体，只是对于不同安全等级的用户他们看到的是不同的射程和数量。

表5-14 属性多实例的多级关系

每种多实例都能以两种方式之一发生：可见和不可见。

1）可见的多实例。当高访问等级的用户想在数据库的一个域上插入数据，而在这个域上已经存在低安全等级的数据时发生。因为直接覆盖原来的数据会导致一个向下的推理通道，使得低访问等级的用户知道高访问等级的用户修改了数据，所以，通过在数据库中创建一个新的元组接收高等级数据，实现向数据库中插入高等级数据。

2）不可见的多实例。情况刚好相反，当低访问等级的用户在数据库中一个已经有高安全等级数据的域上插入一个新的数据时发生。直接覆盖高安全等级的数据肯定是不可行的，而拒绝这个操作同样会引起一个向下的推理通道，使得低访问等级的用户知道高安全等级的数据存在。因此，通过在数据库中创建一个新的元组接收低等级数据，实现向数据库中插入低等级数据。

下面给出几个具体的例子，说明可见多实例和不可见多实例的形成过程，表5-15为假设的最初的表。

表5-15 最初的多级关系

首先说明可见多实例的引入。U级用户将Range更新为1，结果见表5-16。

表5-16 U级用户更新Range

S级用户想将Range更新为2。对于这个更新操作，不能因为已经存在低安全等级的数据而加以拒绝，也不能简单地覆盖原有的数据，采用的处理是引入多实例，其结果见表5-17。

表5-17 S级用户继续更新Range(www.xing528.com)

接着说明不可见多实例的引入。S级用户在表5-15基础上将Range更新为2，结果见表5-18。

表5-18 S级用户更新Range

U级用户将Range更新为1，如果加以拒绝，则会向低等级用户泄露高安全等级数据的存在信息。因此，要引入不可见多实例，更新后的U级实例和S级实例分别见表5-19和5-20。

表5-19 U级用户持续更新Range

表5-20 U级用户持续更新Range后S级实例

引入多实例虽然可以防止隐蔽通道的产生，但是也引起了一些相应问题：数据机密性与数据完整性冲突；增加了数据库的管理难度；增加了对同一现实世界中不同模型理解的困惑，不知道哪个实例的信息是正确、可信的。

例如，表5-17中引入的可见多实例和表5-20中引入的不可见多实例，都是为了防止产生隐蔽通道，防止低等级用户泄露高安全等级数据。表5-17和表5-20中包含两个相同的实例，有不同的属性值，第一个射程为1，第二个为2，这就造成了不一致的问题，无法知道哪个实例的信息是正确、可信的。

目前已经有一些MLS/DBMS采用不同的方法实现了多实例。这些处理方法各有优缺点，适用于不同的要求。在具体的工程实践中，可按照系统不同的要求选择不同的方法。预防多实例的方法不是修改多级安全数据模型，而是要求用户在设计数据库时尽可能多地考虑不引起信息泄露，同时尽量保持实体的唯一性。对多实例问题的处理可采取下面的方法或其组合。

1）使所有的主码可见：主码以关系内可见的最低安全等级标识。

2）根据主码可能的各种安全等级，划分主码的域。

3）限制对多级关系的插入。要求所有的插入由系统最高安全等级的用户实施向下写。

例如，在表5-13描述的多级关系模型（Wname，Range，Quantity）中，假设Wname是主码，安全等级为{U，S}。可规定所有的Wname属性值可见，即所有的Wname属性的安全等级是可见的最低安全等级标签U。这样就避免了引入多实例元组。另外，可以限制多级关系的插入，要求所有的插入由具有系统最高安全等级S的用户来实施下写完成。当引起唯一性问题时，如再次插入一个已经存在的武器，则拒绝执行。这样可避免引起信息泄露，同时保持实体的唯一性，其代价是引起了服务拒绝的问题，在某些环境下，这是允许的。