实现分布授权控制技术

2023-10-28 理论教育版权反馈

【摘要】：在分布式环境中，附加产生的授权控制问题源于对象的分布和其他分布问题。后一种方案的一个假设是，用户是比较固定的、静态的，至少存取分布式数据库的大多数请求发生在同一个节点上。分布授权规则的表示方法与集中制系统的类似，如视图定义一样，它们必须存放在目录里。其他两种情况虽有利于本地访问，但是无法在编译时处理分布授权。视图也看作授权机制中考虑的数据对象。采用用户组方式处理授权可以简化分布式数据库管理。

在分布式环境中，附加产生的授权控制问题源于对象的分布和其他分布问题。这些问题为远程用户授权、分布授权规则管理以及视图与用户组处理等。

分布式DBMS中，给远程用户授权是十分必要的，因为在任意一个站点都可能接受程序启动，而用户可能在一个远端站点。举例来说，对于一个移动电话用户来说，无论他/她在哪里，只要使用其移动电话，移动公司都会从各地运行程序检查其用户信息。为了防止非授权用户远程存取（例如从一个不属于本分布式DBMS的站点），必须存取站点标识用户和授权，这有两种解决方案。

第一种方案是授权用户的信息（用户名和口令）记录在所有节点的目录里。在远端节点启动的本地程序必须声明用户名和口令。

第二种方案是分布式DBMS中的各个节点自己来识别和授权。各个节点自己来认证与授权，节点间有一种互信机制，即一个节点识别用户后，其他节点采信该节点的认证。节点间的通信就使用节点口令来解决。一旦启动节点被授权，就无须再对其远端用户授权。

第一种方案的开销较大，主要是目录管理的开销大，每增加一个新用户，就要实施一个分布操作，在目录中有所记载。但是，用户可以从任意节点存取数据库。

第二种方案在信息无副本时是必然的。当然，也可用在用户信息有副本时的情况。好处是可以让远程访问更有效。如果用户名和口令没有复制，即将其存放在用户访问系统的节点（即Home Site）中。后一种方案的一个假设是，用户是比较固定的、静态的，至少存取分布式数据库的大多数请求发生在同一个节点上。

分布授权规则的表示方法与集中制系统的类似，如视图定义一样，它们必须存放在目录里。存放时可以全复制，也可以部分复制，甚至不复制。后面两种情况中，规则只存放在访问对象分布的节点。全复制的优点是在编译时查询处理的过程中就可以处理授权。但由于是全复制，所以目录管理的开销增加。其他两种情况虽有利于本地访问，但是无法在编译时处理分布授权。(www.chuimin.cn)

视图也看作授权机制中考虑的数据对象。视图是组合对象，由其他基础对象组合而成，因此可以将视图存取的授权翻译成对基础对象存取的授权。如果视图定义和授权规则对所有对象都是全复制的，则翻译相当简单，而且可以在本地处理。如果视图定义（如4.2节里的视图Shanghai_Car）和基础对象定义（如4.2节里的关系Car）存放在不同的节点（如Shanghai_Car在上海，Car在北京），则翻译就困难些。这是显然的，一方面，使用时要访问一个以上的节点；另一方面，节点有自主性，万一存放视图定义或基础对象定义的节点不能用，结果翻译就不能进行。这种情况下，翻译就变成一个完全的分布式操作。某个节点断接，就可能造成翻译失败。视图上的授权依赖于视图创建者对基础对象的访问权限。一种解决方案是在每个基础对象存放的节点记录相关信息。

采用用户组方式处理授权可以简化分布式数据库管理。在集中式DBMS中，“全部用户”称为public。在分布式DBMS中，其用法相同。为了方便，可以指定节点，记作public@sites，表示能访问该节点的全体用户。实际上，public是一个特殊的用户组，其他用户组的定义可以用如下命令来定义：

Def ine GROUP<group_id>AS<l ist of subjec t ids>

显然，这里定义的用户组是public的子集。在分布式环境里，组的管理会碰到一些新问题，即组的成员分布在各个节点；而对数据对象的访问权限可以授权给多个组，它们是分布式的。如果组的信息以及授权规则全复制在所有的节点，则存取权利的推广与集中式数据库系统的类似。当然，维持这种复制的开销是很大的。如果还要维持节点的自主性和分散控制，则更困难。一种解决方案是，要求强加一个存取权利时，要到有组定义的节点上实施远程查询。另一种解决方案是，在每个包含可能被该组用户访问的数据对象的节点上复制组定义。要说明的是，这样做会降低节点的自主性。

总的来说，全复制授权有两大优点：授权控制简单，可以在编译时完成。但是，管理分布式目录的开销较大。

实现分布授权控制技术

相关推荐