扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
安全性插件是动态可装载库,当 DB2 UDB 进行身份验证或者从组成员中查找某个用户的时候,便调用这些库。在 8.2 版之前,这些操作是由 DB2 UDB 之外的设施管理的,例如操作系统、域管理器或 Kerberos 安全性系统。图 1 提供的场景说明了在 8.2 版之前 DB2 UDB 安全性的工作原理。
图 1 说明了 4 个安全性场景:
connect to mydb user raul using raulpsw
,以连接到位于 DB2 数据库服务器 Aries
上的数据库 mydb
。DB2 客户机与服务器通信,协商采用何种身份验证方法。为简单起见,我们假设客户机使用服务器返回的身份验证方法。在图中,AUTHENTICATION 被设置为 SERVER。这意味着,服务器(I)上的操作系统将通过检查提供的用户 ID 和密码是否与存储在操作系统安全性数据库中的值匹配,来进行身份验证。一旦用户通过身份验证,DB2 将从操作系统获得组成员信息。从此以后,DB2 不再在以后的检查中使用用户 ID 或密码;相反,DB2 将使用授权 ID(authID)。通常,authID 是用户 ID 的大写版本。 RAUL
连接到数据库 mydb
的情况下发出的。在这个例子中,内部的 DB2 安全性设施审核 DB2 编目表,以确认 authID RAUL
被授予对表 KEVIN.TABLE1
执行 SELECT 操作的权限,以此来执行授权(authorization) 检查。如果 authID RAUL
和 PUBLIC 没有被授予这种权限,DB2 将检查该用户是否为几个特殊的组(例如 SYSADM、SYSCTRL、SYSMAINT 或 SYSMON)的成员。对于这些组中的每一个组,都有数据库管理器配置(dbm cfg)参数,可以将这些参数设置为一个操作系统组的值。在连接时,DB2 从操作系统中获取用户的组信息,并缓存在内存中。然后,DB2 审核这个缓存的数据(II),以检查 authID RAUL
是否为这些组中某个组的成员。例如,如果 authID 是 SYSADM 组的成员,那么 SELECT 可以继续,否则将返回一条错误消息(SQLCODE -551)。 RAUL
是否有对 KEVIN.TABLE1
表的 SELECT 权限。如果 authID RAUL
和 PUBLIC 没有该权限,将进行组成员检查。在连接时,DB2 从客户机获得组成员信息,并缓存在服务器上。 db2inst1
发出命令 db2stop。DB2 检查当前登录进来的用户是否属于 SYSADM_GROUP、SYSCTRL_GROUP 或 SYSMAINT_GROUP 中定义的组。(IV)如果用户 ID 属于以上任何一个组,那么 db2stop 命令将得以执行。否则,将返回一条错误消息。取决于实例级操作,用户可能必须属于 SYSADM、SYSCTRL、SYSMAINT 或 SYSMON 中的一个组。 在以上每个场景中,都调用了操作系统来进行安全性检查。而从 8.2 版开始,以上每种情况都可以使用安全性插件。因而,不必总是调用操作系统,在场景 1 中可以调用服务器和组插件,在场景 2 中可以调用组插件,在场景 3 和场景 4 中可以调用客户机和组插件。
这个例子介绍了三种类型的安全性插件:
服务器身份验证插件在数据库服务器上执行身份验证。它还用于检查一个 authID 是否为插件所知。例如,考虑 SQL 语句 grant select on table user1.t1 to FOO
,DB2 不知道 FOO 是用户还是组。在这种情况下,DB2 询问所有服务器端插件和组成员插件,以检查 FOO 是用户还是组,或者两者都是,或者无法确定,从而可以对该 SQL 语句作出响应。
客户机身份验证插件在客户机上执行身份验证。在执行实例级命令(例如 db2start
、db2stop
、db2trc
、update dbm cfg
等)时,它还用于执行实例级本地授权。因此,常常可以看到在一个数据库服务器上同时指定了客户机身份验证插件和服务器身份验证插件。
组插件在客户机和数据库服务器上执行组成员查找。它还用于检查一个 authID 是否为插件所知。
每个安全性插件由一组 API 组成,需要实现这些 API。DB2 提供安全性插件基础设施和一些缺省的安全性插件。定制的安全性插件的实现则有待您来决定。(
如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。