27、利用RBAC元模型监控数据库访问约束

利用RBAC元模型监控数据库访问约束

在数据库管理中，确保应用程序遵循组织的动态基于角色的访问控制（RBAC）策略至关重要。本文将详细介绍如何利用RBAC元模型监控数据库访问约束，包括具体步骤、操作方法和性能评估等内容。

整体流程概述

整个流程主要包括以下五个关键步骤：
1. 从数据库中检索与RBAC相关的信息。
2. 应用组织的RBAC策略。
3. 根据RBAC策略验证数据库权限。
4. 为动态方面生成测试用例。
5. 对动态RBAC策略进行运行时验证。

下面将对每个步骤进行详细讨论。

从数据库中检索与RBAC相关的信息

为了验证更通用的安全设置（即RBAC策略）与数据库中实际存在的权限是否一致，需要将具体权限提供给验证工具。为此，开发了一个SQL RBAC适配器，用于读取数据库模式、定义的权限，必要时还可读取当前数据库状态。

以下是从关系数据库元素到RBAC元模型元类的映射表：
| 元素 | 目录项 | RBAC元模型类 |
| — | — | — |
| 表 | information schema.tables | ResourceType |
| 列 | information schema.columns | ResourceProperty |
| 用户 | pg user | User |
| 角色 | pg group | Role |
| 权限类型 | 固定值（INSERT等） | Action |
| 表权限 | information schema.table privileges | TypePermission |
| 元组 | | Resource |
| 值 | | ResourcePropertyValue |

注：带*的元素需要特殊处理。

该表只是一个简要概述，用于说明映射的概念，并未包含所有相关信息。例如，未提供角色成员关系和角色层次结构的信息，这些关系通常通过使用相应关系的外键信息来映射。

可以通过查询数据库信息模式（如SQL标准中定义的）来检索ResourceType、ResourceProperty和TypePermission元类的信息。每个返回的元组都被视为映射元类的一个新实例。

以下是操作步骤：
1. 使用SQL RBAC适配器读取数据库模式、定义的权限和当前数据库状态。
2. 根据上述映射表，将数据库元素映射到RBAC元模型类。
3. 通过查询数据库信息模式检索相关元类信息。

应用组织的RBAC策略

在这一步中，开发人员需要将组织的RBAC策略融入到监控信息中，这些策略可能无法在使用的数据库系统中直接表达。例如，数据库系统通常不支持基于访问历史的动态职责分离（SoD）的RBAC概念。

为了应用这些更通用的策略，开发人员需要修改在步骤1中读取的RBAC元模型实例。具体操作如下：
1. 设置现有元模型元素（如角色）的属性值。
2. 通过创建规则对象定义新规则。
3. 链接实例以满足组织需求。

需要注意的是，开发人员只需配置提供的规则实例，无需用OCL编写策略规则，因为这些规则已在元模型中定义。此外，虽然只展示了一个策略（DynamicSoD）的示例，但元模型设计人员可以轻松将其他策略集成到RBAC元模型中。

例如，假设组织规则将Clerk和Supervisor两个角色定义为互斥（静态SoD），开发人员需要创建一个MutualExclusive关联类的实例来关联这两个角色。更高级的策略可以通过创建DynamicSoD类的实例来定义，例如“如果用户批准了一张支票，则不允许她验证它”的动态SoD约束。

以下是操作步骤：
1. 修改步骤1中读取的RBAC元模型实例。
2. 设置元模型元素的属性值。
3. 创建规则对象定义新规则。
4. 链接实例以满足组织需求。

根据RBAC策略验证数据库权限

在将具体的数据库设置与RBAC策略成功合并后，开发人员可以验证策略相对于当前数据库配置的有效性。需要注意的是，在这一步中无法验证动态策略，因为监控数据不包含过去事件的信息，但可以验证一些有用的静态策略。

例如，大多数数据库系统不允许管理员为角色指定最大用户数量，而组织策略可能有这样的限制，此时可以通过验证来检查是否符合要求。RBAC元模型包含了用OCL指定的多个扩展RBAC策略类型的不变式，包括用户可以成为成员的最大角色数量、互斥角色和角色层次结构等。

使用验证工具USE可以发现这些不变式的违反情况。USE会根据上一步创建的系统状态评估给定的不变式，如果某个约束失败，USE会提供丰富的功能来发现违反的元素。这一阶段的结果可以为数据库管理员提供如何更改所检查数据库的安全设置的建议。

此外，还可以验证给定工作流是否在当前数据库权限下可执行。例如，要验证一张支票是否可以先被批准然后被验证，可以通过定义一个不变式来实现。该不变式要求对名为cheque的资源类型的同一资源进行两个访问操作：一个用于更新资源属性approved，另一个用于更新属性validated。将这个不变式和其他设置（如每种类型的实例数量的边界）提供给模型验证器，模型验证器会尝试找到一个相对于默认RBAC约束和附加不变式有效的对象图。

以下是操作步骤：
1. 将数据库设置与RBAC策略合并。
2. 使用USE工具验证静态策略的不变式。
3. 若约束失败，使用USE工具发现违反的元素。
4. 为验证工作流定义不变式。
5. 将不变式和其他设置提供给模型验证器。
6. 模型验证器尝试找到有效的对象图。

流程图

graph LR
    A[从数据库中检索与RBAC相关的信息] --> B[应用组织的RBAC策略]
    B --> C[根据RBAC策略验证数据库权限]
    C --> D[为动态方面生成测试用例]
    D --> E[对动态RBAC策略进行运行时验证]

以上就是利用RBAC元模型监控数据库访问约束的上半部分内容，下半部分将继续介绍为动态方面生成测试用例和对动态RBAC策略进行运行时验证的具体内容，以及相关的性能评估和总结。

利用RBAC元模型监控数据库访问约束

为动态方面生成测试用例

模型验证器也可用于生成测试用例。此任务对之前的方法稍作修改：不再提供有效工作流的信息，而是使用模型验证器寻找不满足给定约束（如定义动态职责分离（SoD）策略的不变式）的解决方案。模型验证器直接支持对不变式的否定，因为这在模型查找的多个检查任务中很有用。

以支票示例生成的测试用例如下：模型验证器在图5所示的对象图基础上添加了多个实例。具体来说，模型验证器添加了三个访问对象，每个对象代表用户bob对资源类型为cheque的资源或资源属性的访问。第一次访问（时间=2）使用INSERT操作（a3）创建资源r1，随后出现违反图6所示动态SoD规则的访问序列，分别在时间28更新approved属性，在时间32更新validated属性。

这些生成的测试用例可视为违反给定高级策略的基本执行序列。具体的工作流执行可能使用不同的应用程序，这取决于实际的应用环境。因此，安全官员需要将生成的基本访问操作映射到业务工作流以执行测试用例。

操作步骤如下：
1. 使用模型验证器对不变式进行否定，寻找不满足给定约束的解决方案。
2. 模型验证器扩展对象图，添加代表资源访问的实例。
3. 安全官员将生成的基本访问操作映射到业务工作流以执行测试用例。

对动态RBAC策略进行运行时验证

到目前为止，我们仅考虑了数据库的当前状态。但通过使用监控插件，也可以进行动态验证。这需要数据库管理系统提供通知机制，允许应用程序注册感兴趣的事件，如INSERT、UPDATE和DELETE操作。

例如，SQL Server 2005提供的Microsoft Notification Services，从SQL Server 2008开始，这些服务集成到了SQL Server Reporting Services中；PostgreSQL可以使用非标准SQL命令NOTIFY构建通知基础设施。这些机制的通知都是异步发送的，由于我们的方法旨在识别策略违规而非防止违规，这种异步行为非常合适，且能减少运行中应用程序的开销，因为验证可以独立进行。

使用配置好的基础设施，监控器可以在事件发生时通知USE工具，USE工具会根据已执行命令的历史记录验证所有定义的RBAC策略规则。此历史记录从接收到的第一个命令开始逐步构建，之前执行的命令无法考虑。因此，要验证完整的工作流，需要在运行时验证任务中整体执行该工作流。

这种运行时验证方法的一个好处是可以检查单个应用程序或使用同一数据源的多个应用程序中RBAC策略的正确实现，因为策略评估是在数据库层进行的。

操作步骤如下：
1. 配置数据库管理系统的通知机制，允许应用程序注册感兴趣的事件。
2. 监控器在事件发生时通知USE工具。
3. USE工具根据命令历史记录验证RBAC策略规则。
4. 整体执行工作流以验证其完整性。

可行性研究

为了初步了解该方法能够处理的数据库规模，我们提取了不同大小的数据库信息，并生成了10,000个访问操作。然后对结构进行了完整验证，即检查提取的对象图是否符合多重性约束和元模型中存在的（OCL）不变式。同时，我们使用不同数量的RBAC策略规则进行了验证，规则数量从7条到28条不等。

以下是性能评估结果：
| #Rec. | #Inst. | #Links read | 结构验证时间（秒） | | | | 不变式验证时间（秒） | | | |
| — | — | — | — | — | — | — | — | — | — | — |
| | | | 7条规则 | 14条规则 | 21条规则 | 28条规则 | 7条规则 | 14条规则 | 21条规则 | 28条规则 |
| 74,964 | 638,897 | 75,009 | 52 | 1 | 1 | 1 | 4.7 | 8.8 | 12.1 | 15.5 |
| （Windows 7） | | | （53） | （1.6） | （1.6） | （1.6） | （6.4） | （11.5） | （17.4） | （23.1） |
| 89,222 | 769,329 | 89,267 | 60 | 1.4 | 1.4 | 1.3 | 5 | 9.6 | 12.7 | 16.8 |
| 112,366 | 986,206 | 112,409 | 78 | 1.6 | 1.6 | 1.5 | 4.7 | 8.7 | 12.8 | 17.1 |

从结果可以看出，该方法能够在大约20秒内对中等规模的数据库（约100,000个元组，考虑10,000个访问操作）和大约30条动态SoD规则进行RBAC策略验证。数据库状态的创建和不变式的验证时间都呈线性增长，而且考虑到这些时间代表的是对整个系统状态的验证，测量的持续时间仍然是可以接受的。

目前，USE与RBAC监控器结合使用时内存消耗较大。使用1GB堆空间时，只能处理包含约75,000条记录的第一个数据库状态。不过，由于RBAC监控器目前为了性能原因保留了所有读取的数据库行的副本，这个数字是可以提高的，USE作为独立应用程序或库仍然可以处理更多实例。

总结

利用UML和OCL模型监控器对关系数据库中的RBAC进行监控，可以检测到如组织策略中指定的动态互斥角色的违规情况。通过可行性研究，我们发现该方法能够对中等规模的数据库和一定数量的访问操作进行有效监控，并且可以检查指定策略与实际工作流的一致性。特别是在基于访问历史的动态SoD约束方面，该方法具有一定的优势。但在实际应用中，还需要考虑内存消耗等问题，进一步优化性能。

流程图

graph LR
    A[为动态方面生成测试用例] --> B[对动态RBAC策略进行运行时验证]
    B --> C[可行性研究]
    C --> D[总结]