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


在三层应用程序模型中,中间层(例如 WebSphere Application Server 或 Domino)负责运行客户机应用程序的用户身份验证和管理与数据库服务器的交互。中间层的授权 ID 需要拥有与终端用户相关的所有权限,以便执行终端用户所需的任何操作。虽然三层应用程序模型有很多优点,但是,如果将与数据库服务器的所有交互(例如用户请求)都放在中间层,那么会引起下面提到的一些安全问题。

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

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

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

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

图 1. 三层应用程序模型

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

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

  • 1
  • 2
  • 3
  • 4
  • 下一页
【内容导航】
第1页:DB2 数据库应用中使用受信任上下文 第2页:使用受信任连接
第3页:定义一个受信任上下文 第4页:CLI 应用程序中的受信任连接

相关内容