数据架构师: 保护 DB2 数据

简介： 基于角色的安全性提供了一种途径来保护企业的信息资产，自 DB2 V9.5 for Linux®, UNIX®, and Windows®(LUW) 和 DB2 9 for z/OS® 发布以来即可用。但是，许多用户仍然没弄明白何时使用此功能。在本专栏中，Robert Catterall 阐明角色和可信上下文的用途和优点。 本文来自于IBM Data Management magazine 中文版。

管理DB2特权的更好途径      

最近，高管们常常担忧委托给他们的数据的未授权访问。他们的恐惧变成了现实：最近的一项调查显示，大约 1/3 的受调查者在与他们认为存在数据安全隐患的公司进行交易。这是对能够加强数据访问控制的 DB2 专家具有如此高的期望的原因。

基于角色的安全性是保护企业信息资产的一个不错的方法，而且它可能比您想象的更容易实现。DB2 角色（和它们的近亲 - 可信上下文）自 DB2 9.5 for Linux, UNIX, and Windows (LUW) 和 DB2 9 for z/OS 发布以来即可用。但是，尽管这些 DB2 版本比 3 年前应用更加广泛，但许多用户仍然没弄明白角色和可信上下文的用途和优点。我将在本文中尝试澄清一些事情。

首先，角色和可信上下文的引入并没有引入任何新的 DB2 特权。此安全功能提供了一种新途径来分配和管理特权。它们现在可授给角色，而不是直接分配给用户的授权 ID。您也可以将特权的使用限制到符合既定的可信上下文的可信连接，从而限制所授予特权的范围。

以这种方式管理 DB2 安全性在处理常见的客户端/服务器计算场景时特别有用：一个在 Java 或 .NET（或某种其他）应用服务器上运行的应用程序发出将在 DB2 数据库服务器上执行的 SQL 语句（在 DB2 for z/OS 环境中，SQL 语句将可能流经 Distributed Data Facility (DDF)）。各个用户可在应用服务器上对自身进行验证，但应用程序本身会向 DB2 提供一个将硬编码到程序中的通用授权 ID 和密码。

如果 SQL 语句是在 DB2 服务器上动态准备的，就像使用 JDBC、ODBC 或 ADO.NET 等数据库结构的程序一样，应用程序的通用授权 ID 必须被授予目标对象上的表特权 (SELECT, INSERT, UPDATE, DELETE)，才能成功地执行语句。

但是许多 程序员可能知道应用程序的 DB2 授权 ID 和密码，因为前面已经提到，这些信息嵌入到程序代码中。某个人然后可以使用该 ID 和它的特权从应用程序外部访问数据库中的数据，严重减弱安全性。

一种有用的类比

使用真实示例类比说明。我最大的女儿获得驾驶执照还不到一年，如果我可以使用 DB2 角色和可信上下文等来管理她的驾驶情况，我就可以更好地控制她对我们汽车的使用。我可以进行一些设置，以便她只能在家到学校的路段上享受驾驶特权，而且只能驾驶面包车（不是运动型轿车）。当然，这对我而言只是一个梦，从我女儿的角度讲可能是一场噩梦。

使用角色和可信上下文

但是如果您使用新功能模式下的 DB2 9 或 DB2 10 for z/OS，您可以在 DB2 中完成类似的功能。DB2 9.5 for LUW、9.7 和更新版本的管理员拥有相同的能力：无需向一个通用的授权 ID 授予执行应用程序的动态 SQL 语句所需的一组特权，可以将特权授予一个角色。

现在，仅仅将特权授给一个角色几乎没用。为什么？因为 DB2 无法知道谁可以使用角色的特权，或者可在何种条件下使用该角色。

这时就需要定义可信上下文了。可信上下文将角色的特权享用限制到通过为 DB2 提供了一个特定授权 ID（称为 “系统” 授权 ID）应用程序，从特定应用服务器（由 IP 地址标识）连接到 DB2 的用户。

因为执行由应用程序发出的动态 SQL 语句所需的特权分配给了一个角色，而不是一个 ID，所以应用程序的通用授权 ID 没什么用处（没有提供访问 DB2 数据的方式），除非它拥有前面提及的特权的角色。而且它只能在用于从应用服务器连接到 DB2，而且该服务器的 IP 地址是可信上下文的一个属性时才能拥有这些特权，该可信上下文指定了使用角色的条件。这样，安全性就比无论 “来自” 何种连接类型，应用程序的通用 ID 都拥有可享受的特权时高得多使安全得多。

但是请等，还没完！

这里有许多选择：

• 如果您使用 IBM WebSphere Application Server，可以将数据库属性 propagateClientIdentityUsingTrustedContext 设置为 “true”，向 DB2 发送终端用户的身份。
• 应用程序可以使用针对 JDBC（比如 getDB2Connection）、CLI（SQL_ATTR_TRUSTED_CONTEXT_USERID 属性和SQLSetConnectAddr 函数）以及 .NET（其中连接字符串关键词 UserID 对应于终端用户）的应用编程接口（API）来建立到 DB2 的可信连接，使用不同的终端用户 ID 重用可信连接，以及将该终端用户 ID 发送到 DB2 服务器。
• 如果请求者是 DB2 for z/OS 系统，您可以在请求方的通信数据库中（具体来讲在 SYSIBM.USERNAMES 表中）提供可信连接的 “系统” 授权 ID。在重用可信连接时，终端用户的 ID 将发送到 DB2 服务器。

此功能不仅可用于将角色的特权限制到特定可信连接的指定用户，还可用于获取包含终端用户的个人 ID 的 DB2（和 Resource Access Control Facility，RACF）审计信息。即使这些用户通过应用程序连接到 DB2 也可以正常工作，在建立与 DB2 的链接时这些应用程序本身可以提供一个通用授权 ID。

如果您将终端用户 ID 从应用服务器发送到 DB2，您可以获得与给定可信上下文关联的角色相关的详细信息。例如，一个可信上下文可能有一个默认角色 ROLE_A。假设为其定义可信上下文的应用程序将终端用户身份发送到 DB2，您可以通过在 CREATE TRUSTED CONTEXT 语句上指定WITH USE FOR SMITH ROLE ROLE_B，表明另一个角色 ROLE_B 可供终端用户 SMITH 用于可信的连接。如果您需要验证信息（比如密码），SMITH 才能使用ROLE_B，您可以将 WITH AUTHENTICATION 添加到前面的 WITH USE FOR 子句中。

请注意，当您省略 CREATE TRUSTED CONTEXT 的 WITH USE FOR 子句时，就好象您指定了WITH USE FOR PUBLIC WITHOUT AUTHENTICATION。这意味着与可信上下文关联的默认角色的特权可用于使用有可信上下文定义的可信连接的任何个人。

您甚至可以在可信上下文定义中指定，请求者必须使用安全套接字层 (SSL) 加密协议与 DB2 通信。只需将 ENCRYPTION 'HIGH' 用作可信上下文的一个属性。（ENCRYPTION 'LOW' 对应于 64 位的 DRDA 加密。）

现在，关于可信上下文，有两个重要事项需要记住：

• 对于大型机 DB2 服务器，也可以为通过一个批量作业或一个已启动任务与 DB2 建立的本地连接定义可信上下文。
• 可以设置可信上下文，将上下文的默认角色用作使用该角色的特权创建的任何对象的所有者。

结束语

当用户依据既定的可信上下文，建立与 DB2 子系统的可信连接时，他或她拥有关联的角色的特权，以及 任何直接授给他或她的 ID 的特权。这里要注意的是：只有在 DB2 特权没有广泛地授给用户的 DB2 授权 ID 时，角色和可信上下文才能限制这些特权的享用。假设您将开始REVOKE 以前在逐步使用角色和可信上下文期间授给个人用户 ID（和/或 RACF（或等效的）组 ID）特权。

设置基于角色的安全性比大部分人所想的更轻松。只要组织希望更好地控制他们的信息，就会存在越来越严格地控制 DB2 提供的数据资产的需求。这是未来的发展趋势。现在掌握了它，您将走在时代的前沿。