分布式数据库系统数据安全（三）强制访问控制

字数 1690阅读 2703评论 0赞 0

[（一）概述](https://www.talkwithtrend.com/Article/254055 "（一）概述")
[（二）自主访问控制](https://www.talkwithtrend.com/Article/254063 "（二）自主访问控制")

**（三）强制访问控制**

自主访问控制存在局限性。其中一个问题是，恶意用户能通过获授权的用户访问未获授权的数据。例如，考虑用户A获授权访问关系R和S，用户B仅获授权访问关系S。如果B设法修改了A使用的应用程序，将R数据写入S，则B能读取未获授权的数据，却并未违反授权规则。

通过同时为主体和数据对象定义不同安全级别，强制访问控制解决了这个问题并进一步改进了安全性。数据库强制访问控制基于著名的Bell和LaPadula模型。该模型是为操作系统安全设计的。在该模型中，主体是代表用户的进程；进程有安全级别，密级来源于用户的安全级别。其最简形式的安全等级是绝密（TS）、机密（S）、保密（C）和无密（U），按安全程度排序为TS>S>C>U。主体以读写模式访问时，服从两条简单规则：
1. 当且仅当level(S)>=l，才允许主体S读安全等级l的对象。
2. 当且仅当class(S)<=l，才允许主体S写安全等级l的对象。

规则1（称为“不向上读”）保护数据免受未获授权的披露，即，给定安全级别的主体只能读同等或更低安全级别的对象。例如，机密级主体不能读绝密级数据。规则2（称为“不向下写”）保护数据免受未获授权的更改，即，给定安全级别的主体只能写同等或更高安全级别的对象。例如，绝密级主体只能写绝密级数据，但不能写机密级数据（因为其可能包含绝密数据）。

在关系型模型中，数据对象可能是关系、元组或属性。因此，关系可以划分成不同保密级别：关系级（即，关系中的所有元组都有相同安全级别）、元组级（即，每个元组有一安全级别）或属性级（即，每个不同的属性值都有一安全级别）。因此，保密的关系称为多级关系，反映出对于不同密级的主体以不同的数据呈现不同的关系。例如，通过给每一元组添加对应安全级别属性，可以表示元组级的多级关系。类似地，通过给每一属性添加对应安全级别，可以表示属性级的多级关系。下图说明基于关系PROJ的多级关系PROJ*，其为属性级。请注意，附加的安全级别属性会大幅增加关系的大小。

PROJ*
![](/home/attachment/202102/02/993931_161223239095407.JPG)
图2 属性级的多级关系PROJ*

整个关系也有安全级别，是其包含的任何数据的最低安全级别。例如，关系PROJ*具有安全级别C。于是，具有与关系相同或更高安全级别的任何主体都可以访问该关系。不过，主体只能访问有安全密级的数据。因此，如果主体没有安全密级，则属性对该主体呈现为空值，关联一个与该主体相同的安全级别。下图展示机密安全级别主体访问关系PROJ*的实例。

PROJ*C
![](/home/attachment/202102/02/993931_161223244898926.JPG)
图3 保密关系PROJ*C

强制访问控制对数据模型影响巨大，因为用户看不到相同的数据，且必须应对难以预料的副作用。主要的副作用称为多实例化，即允许同一对象根据用户的安全级别有不同的属性值。下图说明带有多实例化元组的多关系。

PROJ**
![](/home/attachment/202102/02/993931_161223247849359.JPG)
图4 多实例化的多级关系

主键P3的元组有两个实例化，各有不同安全级别。这可能是由于安全级别C的主体S在图2的关系PROJ*中插入键值为“P3”的元组。因为（保密密级的）S应忽视键值为“P3”（机密密级）的元组，唯一可行的方案是添加相同键值和不同密级的第二个元组。但是，机密密级的用户可能同时看到键值为“P3”的两个元组，并应将此理解为出乎意料的结果。

数据库安全分布式数据库数据库安全

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

分布式数据库系统数据安全（三）强制访问控制

添加新评论0 条评论

作者其他文章

相关文章

相关问题

相关资料