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

　　用户身份的丢失： 有些企业想知道访问数据库的所有用户的身份，以便进行访问控制。

　　用户可说明性(accountability)的减弱： 在数据库安全性中，通过审计说明责任是一项基本原则。对于中间层自身执行的事务与中间层代表某些用户执行的事务，数据库应该能够加以区分。

　　权限的过度授予： 中间层的授权 ID，应该拥有执行来自所有用户的所有请求所需的一切权限。但是，这会导致安全问题，即让一些不需要访问某些信息的用户得到这些信息的访问权。

　　安全性的减弱： 除了过度授予权限的问题外，当前的方法还要求，中间层使用的用于连接的授权 ID 必须被授予用户请求可能访问的所有资源上的权限。如果中间层授权 ID 被泄漏，那么所有那些资源都将被暴露。

　　

　　图 1. 三层应用程序模型

　　显然，需要用一种机制来确保对于中间层代表用户执行的数据库请求，仅使用实际的用户身份和数据库权限。达到这一目标的最简单的方法是让中间层使用用户 ID 和密码建立一个新连接，然后由这个新连接重定向用户请求。这种方法虽然简单，但是存在一些缺陷。很多中间层服务器并没有建立一个连接所需的用户的身份验证凭证。为数据库服务器上的每个用户创建一个新的物理连接，显然会带来额外的性能开销。

　　为了确保对于中间层代表每个用户执行的任何数据库请求，都使用那个用户特定的数据库身份和数据库权限，需要一种更好的方法。为了提高性能，这种方法应允许中间层重用相同的物理连接，而不需要重新在数据库服务器上对用户进行身份验证。这就引出了受信任连接的思想。

　　使用受信任连接

　　为了建立一个受信任连接，必须在 DB2 上创建一个称作受信任上下文的新对象，以便在 DB2 与外部实体(例如一个中间件服务器)之间建立信任关系。受信任上下文 的定义包括要使用受信任上下文并被视作一个受信任的连接的特定连接所需满足的标准。

　　当尝试建立一个受信任连接时，需要评估一系列的信任属性，以决定一个特定的上下文是否是受信任的。当第一次创建到服务器的连接时，就建立了该连接与一个受信任上下文之间的关系，并且在该连接尚未断开期间该关系一直存在。当建立一个受信任连接时，通过允许中间层指定一个新的用户 ID，即可将该连接用于不同的授权 ID，而无需对该用户 ID 进行身份验证(见图 2)。

　　

　　图 2. 包含受信任上下文的三层应用程序模型

　　定义一个受信任上下文

　　受信任上下文是根据系统授权 ID 和一组或多组连接信任属性定义的一种新对象。每个受信任上下文都用一个相关的系统授权 ID 和一组或多组连接信任属性标识，其中每组定义至少一个连接信任属性。

　　系统授权 ID： 首要的信任属性是用于连接的授权 ID。在用于建立一个连接的任何给定系统授权 ID 与一个特定的受信任上下文之间，总是有一个明显的映射。

　　连接信任属性： 一组连接信任属性定义一组特征，一个连接要凭借受信任上下文成为受信任连接，必须满足这组特征。只有为受信任上下文的一组属性定义的所有条件都得到满足，使用那组属性作为受信任上下文属性的连接才被视作受信任连接。

　　PROTOCOL： 通信协议信任属性。该属性控制有哪些网络通信协议可以使用受信任上下文。