DB2数据库应用中使用受信任上下文.doc

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