分类:
2008-05-17 16:52:10
| ||
在三层应用程序中,中间层(例如 WebSphere Application Server 或 Domino)负责运行客户机应用程序的用户身份验证和管理与数据库服务器的交互。中间层的授权 ID 需要拥有与终端用户相关的所有权限,以便执行终端用户所需的任何操作。虽然三层应用程序模型有很多优点,但是,如果将与数据库服务器的所有交互(例如用户请求)都放在中间层,那么会引起下面提到的一些安全问题。 用户身份的丢失: 有些企业想知道访问数据库的所有用户的身份,以便进行访问控制。 用户可说明性(accountability)的减弱: 在数据库安全性中,通过审计说明责任是一项基本原则。对于中间层自身执行的事务与中间层代表某些用户执行的事务,数据库应该能够加以区分。 权限的过度授予: 中间层的授权 ID,应该拥有执行来自所有用户的所有请求所需的一切权限。但是,这会导致安全问题,即让一些不需要访问某些信息的用户得到这些信息的访问权。 安全性的减弱: 除了过度授予权限的问题外,当前的还要求,中间层使用的用于的授权 ID 必须被授予用户请求可能访问的所有资源上的权限。如果中间层授权 ID 被泄漏,那么所有那些资源都将被暴露。
显然,需要用一种机制来确保对于中间层代表用户执行的数据库请求,仅使用实际的用户身份和数据库权限。达到这一目标的最简单的方法是让中间层使用用户 ID 和建立一个新连接,然后由这个新连接重定向用户请求。这种方法虽然简单,但是存在一些缺陷。很多中间层服务器并没有建立一个连接所需的用户的身份验证凭证。为数据库服务器上的每个用户创建一个新的物理连接,显然会带来额外的性能开销。 为了确保对于中间层代表每个用户执行的任何数据库请求,都使用那个用户特定的数据库身份和数据库权限,需要一种更好的方法。为了提高性能,这种方法应允许中间层重用相同的物理连接,而不需要重新在数据库服务器上对用户进行身份验证。这就引出了受信任连接的思想。 使用受信任连接 为了建立一个受信任连接,必须在 DB2 上创建一个称作受信任上下文的新对象,以便在 DB2 与外部实体(例如一个中间件服务器)之间建立信任关系。受信任上下文 的定义包括要使用受信任上下文并被视作一个受信任的连接的特定连接所需满足的标准。 当尝试建立一个受信任连接时,需要一系列的信任,以决定一个特定的上下文是否是受信任的。当第一次创建到服务器的连接时,就建立了该连接与一个受信任上下文之间的关系,并且在该连接尚未断开期间该关系一直存在。当建立一个受信任连接时,通过允许中间层指定一个新的用户 ID,即可将该连接用于不同的授权 ID,而无需对该用户 ID 进行身份验证(见图 2)。
定义一个受信任上下文 受信任上下文是根据系统授权 ID 和一组或多组连接信任属性定义的一种新对象。每个受信任上下文都用一个相关的系统授权 ID 和一组或多组连接信任属性标识,其中每组定义至少一个连接信任属性。 系统授权 ID: 首要的信任属性是用于连接的授权 ID。在用于建立一个连接的任何给定系统授权 ID 与一个特定的受信任上下文之间,总是有一个明显的映射。 连接信任属性: 一组连接信任属性定义一组特征,一个连接要凭借受信任上下文成为受信任连接,必须满足这组特征。只有为受信任上下文的一组属性定义的所有条件都得到满足,使用那组属性作为受信任上下文属性的连接才被视作受信任连接。 PROTOCOL: 通信协议信任属性。该属性控制有哪些网络通信协议可以使用受信任上下文。 ADDRESS: 网络地址信任属性。该属性与 PROTOCOL 属性一起用于控制受信任上下文可以与哪些地址一起使用。这是连接用来与数据库管理器进行通信的实际的客户机 IP 地址和域名。 ENCRYPTION: 网络加密信任属性。该属性为连接指定数据流的最小级别的加密(“networkencryption”)。 AUTHENTICATION: 身份验证信任属性。该属性指定在连接建立期间需要对系统授权 ID 进行的身份验证级别。 假设一个管理员当系统授权 ID 为 NEWTON,且 TCP/IP 地址属性为 9.26.146.201 时,任何连接都被视作受信任连接。那么,该管理员可以像下面这样定义受信任上下文: 例 1. 受信任上下文定义示例
如果从 IP 地址 9.26.146.201 使用 TCP/IP 协议和授权 ID NEWTON 建立一个连接,那么在这个连接的属性和前面定义的受信任上下文 ctxName1 之间存在匹配,而加密则被忽略。 管理员还可以通过使用 ALTER TRUSTED CONTEXT 和 DROP TRUSTED CONTEXT 语句修改和删除受信任上下文对象。 CLI 应用程序中的受信任连接 可以通过以下两种途径为另一个用户建立和切换受信任上下文: 用于 CLI 应用程序的 SQLConnect API 用于 CLI 应用程序的 SQLSetConnectAttr 和 SQLGetConnectAttr API 下面将介绍 CLI 应用程序中用于 SQLSetConnectAttr API 的新的连接属性: SQL_ATTR_USE_TRUSTED_CONTEXT: 表明客户机是否请求一个受信任连接的值。这个值只能在建立连接之前或断开连接之后指定。 SQL_ATTR_TRUSTED_CONTEXT_USERID: 一个字符串,表明当前受信任连接上使用的用户 ID。 SQL_ATTR_TRUSTED_CONTEXT_PASSWORD: 一个字符串,表明应用程序可能为身份验证而设置的密码。除非设置了 SQL_ATTR_TRUSTED_CONTEXT_USERID 属性,否则该属性无效。 下面的例子展示如何在一个 CLI 应用程序中,为用户 ID “newton” 建立到 testdb 数据库的受信任连接。在建立受信任连接之前,应用程序必须使用 SQLSetConnectAttr API 设置 SQL_ATTR_USE_TRUSTED_CONTEXT 属性。在建立受信任连接之后,应用程序将用户切换到受信任上下文中定义的允许的用户。在这个例子中,应用程序通过设置属性 SQL_ATTR_TRUSTED_CONTEXT_USERID,将连接切换到用户 ID “zurbie”。 例 2. 在 CLI 程序中使用受信任连接
|