我们面对的这个问题是：数据库安全性话题还没有象测定最短宕机时间世界记录和报告那么引人瞩目。您是在什么时候最后一次读到有关安全令牌和加密的睿智文章的呢？但正如去年大肆宣传的从一些电子商务企业中盗窃信用卡号码的事件所表明的，安全性缺口的确引人瞩目 — 而且能削弱顾客的信心。即便安全性不是最令人激动的主题，对于任何使用数据库管理系统的企业来说，它也是重要顾虑。同时，随着越来越多的企业参与电子空间，把私有数据从公共数据中分离变得尤为重要。

如想获得更多关于 DB2 UDB 安全特性的信息，请参阅 DB2 Administration Guide。

任何给定的公司的数据库系统可能要收集、存储和分析成千上万行信息，这些信息本质上有公共的，也有私有的。由于有这项责任在身，数据库必须使数据库管理员能适当的授权和限制访问。此外，数据库还必须提供防止未授权用户存取机密数据的方法。

但是有时候，数据库安全信息难以获得或理解。尽管您常听说 DB2 通用数据库（DB2 Universal Database，UDB）是多么可扩展、多么健壮，但您多久才会听到一次有关 DB2 的安全特性的细节呢？

因为保护数据库安全是 DBA 最重要的职责之一，所以您不应当试图通过反复试验来学习数据库安全性。保护您的数据库安全涉及：

防止任何人在企业无需知道的情况下对机密数据进行未授权的存取

防止未授权用户恶意删除进行破坏或擅自改变数据

采用审核技术监视用户存取数据

本文中，我将带您浏览 Windows、Unix 和 OS/2 版本的 DB2 UDB v.7.1 中的安全特性，并描述一些可以帮助您最大化安全性的内部控制。

验证

数据库安全性中最基本的概念之一就是验证，这是一个相当简单的过程，系统通过这个过程来证实用户身份。用户可以通过提供身份证明或验证令牌来响应验证请求。

很可能您已经熟悉这个概念了。如果您曾经被要求出示带照片的 ID（例如，在银行新开帐户时），那么已经有人向您提出过验证请求了。您出示了驾驶执照（或其它带照片的 ID）从而证明自己的身份。在这种情况下，您的驾驶执照就充当了验证令牌。

图 1. DB2 授权角色

不管您在电影里看到些什么，大部分软件程序不能把未来系统（比如面部识别）用于验证。相反，大多数验证请求要求您提供用户标识和密码。您的用户标识表示您声称自己是被授权可访问该环境的人，密码则将提供您个人的验证证据。当然，这种验证假定您的密码受到很好的保护，而且您是唯一一个知道这个密码的人。

用户验证由 DB2 之外的安全性工具完成，这个工具通常是操作系统的一部分或独立产品。事实上，安全性不仅是数据库问题；操作系统厂商也要花费很多的时间、金钱和心思确保他们的产品是安全的。但是，包括 Microsoft Windows 95 和 98 在内的一些操作系统并没有本地安全机制。如果您使用的是没有安全机制的操作系统，那您可以把环境配置成依靠在更安全的系统上运行的 DB2 服务器来提供这种安全性。例如，您可以使用可靠的客户端选项，我将在文章的后面部分更多的讨论这些选项。（如想获得更多信息，请参阅 DB2 Administration Guide。）

您也可以使用第三方产品（如由 Open Group 定义的分布式计算环境安全服务（Distributed Computing Environment（DCE）Security Services）来给您的环境添加一层安全层。DB2 可以协调这些外部安全工作与其安全主动性来保护事务或分析环境。

一旦用户身份验证成功，DB2 记下用户的身份标识和其它相关的安全信息，如用户组列表。用户必须使用 SQL 授权名（authorization name）或授权标识（authid）以被 DB2 识别，授权名或授权标识可以与用户标识或映射值相同。这一连接信息将在用户连接期间保留。

验证选项

因为验证可以由操作系统或第三方产品处理，所以 DB2 提供您可以在数据库管理器配置（dbm cfg）文件中使用 AUTHENTICATION 参数设置的不同验证选项。DB2 使用这一参数确定验证应该以何种方式、在何处发生。

dbm cfg AUTHENTICATION 参数的许多设置在逻辑上可以分组为以下四个不同类别：SERVER（服务器）、Client（客户机）、DCE、Kerberos。

服务器验证。该组提供两个主要选项：

SERVER（服务器）缺省安全性机制，指明验证应该使用服务器的操作系统在服务器上发生。如果用户标识和密码是在连接期间指定的，那么 DB2 将调用操作系统函数来验证提交的用户标识和密码。（在基于 Windows 的环境中，用户标识常被称为用户名。用户名和密码合起来常被称为用户账户。）

SERVER_ENCRYPT本质上同缺省选项是一样的，只有一点例外，即从客户机传到服务器的密码是加密的。DB2 在连接时使用单 DES（56 位）密码加密技术和 Diffie-Hellman 算法为加密算法生成密钥。RSA BSAFE 工具箱提供这一支持。

Client（客户机）验证。该组仅有的选项 CLIENT 指明验证将在客户机上发生。如果客户机驻留在原本就具有安全特性的操作系统（例如，AIX）上，那么它就是可信任客户机。通常，除 Microsoft Windows 95 和 98 被认为不可信任之外，所有客户机都是可信任的。

如果服务器接收到来自可信任客户机和不可信任客户机的请求，那么 TRUST_ ALLCLNTS 和 TRUST_CLNTAUTH 选项允许可信任客户机使用客户机验证（client authentication）获得访问权，而不可信任客户机则必须提供密码才能成功验证。请参阅 DB2 Administration Guide以了解细节。

DCE 验证选项。一些管理员愿意实现 DCE 安全性服务，原因是 DCE 提供用户和密码集中式管理，不传送明文密码和用户标识，并且向用户提供单次登录。DB2 使用第三方 DCE 产品来提供对 DCE 安全性服务的集成支持。您可以选择以下两种设置之一：

DCE指明使用 DCE 安全性服务来验证用户。已经登录到 DCE 的 DB2 客户机可以得到一张加密的“票证”，它可以用这张票证向 DB2 服务器证明自己的身份。

DCE_SERVER_ENCRYPT指明服务器将把 DCE 票证或用户标识以及加密的密码当作验证证据接受，由 DB2 客户机选择。

Kerberos 验证选项。Kerberos 这一新的验证机制被作为它与 Microsoft Windows 2000 紧密集成的一部分添加到 DB2 UDB v.7.1 中，单次登录工具就可以完成 DB2 验证。一旦通过验证，用户就不会受到存在于 Kerberos 环境中的任何服务器的再次质疑。这种验证方法只能用于 DB2 客户机和 DB2 服务器都是在 Windows 2000 上运行的情况下。

DCE 和 Kerberos 使用本质上相同的底层技术。当客户机登录到 Kerberos 安全性环境的时候，DB2 客户机可以获取加密的 Kerberos 票证用来向指定的 DB2 服务器证明自己的身份。

您可以选择以下两种设置之一：

KERBEROS指明应当只用 Kerberos 安全性服务来验证用户。

KRB_SERVER_ENCRYPT指明服务器将把 Kerberos 票证或用户标识以及加密密码当作验证证据接受，由 DB2 客户机选择。

授权

通过验证的用户将参加 DB2 安全性的第二层 — 授权。授权是 DB2 借以获得有关通过验证的 DB2 用户的信息（包括用户可以执行的数据库操作和用户可以访问的数据对象）之过程。

您的驾驶执照就是授权文档的绝佳示例。虽然可以把它用于验证目的，但它还授予您驾驶某种类型的车的权力。不仅如此，就驾驶机动车行路而言，您所拥有的某种授权或多或少会给您些特权。

例如，在加拿大的安大略省，G 类驾照给您实际上在任何时间任何地点都可以开车的特权。G 类驾照在驾驶汽车授权等级结构的最上层。级别比它低的 G2 类驾照虽然允许用户在一天中的任何时间驾车，但是有一定的限制。（例如，这种授权体制下的用户在饮用任何含酒精的饮料之后绝不允许驾车。）G2 驾照的下面一级是 G1 驾照，包括许多限制（例如，驾驶员必须有一位 G 类驾照的乘客陪同，不可以在高速公路上或者在天黑以后驾车）。

您的驾照授权您驾驶机动车并限制您对某些“对象”的访问（例如，如您持有 G2 驾照就不可以在高速公路上开车）。DB2 以非常类似的方式工作。

授权可以被分为两个不同类别：权限和特权。

权限。权限提供一种把特权分组的方法，并对数据库管理器和实用程序进行更高级的维护和操作加以控制。数据库相关权限存储在数据库目录中；系统权限关系到组成员关系，对给定的实例，它存储在数据库管理器配置文件中。DB2 有如下四个预定义的权限级别：SYSADM、SYSCTRL、SYSMAINT 和 DBADM。图 1 说明 DB2 中使用的预定义的授权级别等级系统。SYSADM、SYSCTRL 和 SYSMAINT 在实例级别上操作，范围是整个服务器。每个级别都有自己的按组分的特权和访问规则（与 G 类执照非常相似）。这些权限都是在每个实例的数据库管理器配置文件中被定义的。DBADM 授权级别链接到服务器实例中的特定数据库，并自动把这一权限级别授予创建数据库的用户。DBADM 对数据库及其内的所有对象都拥有所有可能的按组分的特权。缺省情况下，SYSADM 对包括数据库在内的整个系统拥有所有可能的按组分的特权（SYSADM 有隐含的 DBADM 权限）。

DB2 使用不止一个纵向授权流。对于每个用户请求，依据涉及到的对象和操作，可能会需要多次授权检查。授权是使用 DB2 工具执行的。DB2 系统目录中记录了与每个授权名有关联的特权。对通过验证的用户的授权名以及该用户所属的组与记录在案的属于他们的特权进行比较。根据比较结果，DB2 决定是否允许请求的访问。

图 2. 返回给未被授权执行特定命令的用户的出错消息

例如，图 2 展示输入命令运行的结果，该命令要求用户具有特定的授权特权。

DB2 安全性机制阻止 TESTING 用户标识，因为它知道这个用户没有得到执行这样的命令的授权。在这种情况下，TESTING 显然不是 SYSADM，因为该权限级别是执行如图 2 中所示的命令所需要的。

在 DB2 中，您通过分别成为 SYSADM_GROUP、SYSCTRL_GROUP 和 SYSMAINT_GROUP 数据库管理器配置参数指定的组的成员获得 SYSADM、SYSCTRL 和 SYSMAINT 权限。

如想获得所有授予属于 DB2 预定义授权组的用户的授权特权的完整列表，请参考 DB2 Administration Guide。

特权。特权（privilege）定义对授权名的单一许可，从而使用户能够修改或访问数据库资源。特权存储于数据库目录中。虽然权限组预定义了一组可以隐性授予组成员的特权，但是特权是单独的许可。

图 3：DB2 中可用的样本特权

DB2 可以利用由操作系统安全功能维护的用户组。组允许数据库管理员给组指派特权，这样帮助降低数据库系统持所有权的总成本。

例如，如果您要把创建表（CREATETAB）和连接数据库（CONNECT）的特权为 50 个用户开放，那么创建组并给它添加特权要比显式给每个单独的用户授予每种特权更容易。每当您需要添加或撤消特权时，您只要对组操作一次，对组的所有成员都会生效。

通常，动态 SQL 和非数据库对象授权（例如，实例级命令和实用程序）适用于组成员关系。动态 SQL 是非预先安排或即时生成的 SQL。静态 SQL 不适用于组成员关系（除 PUBLIC 组之外）。静态 SQL 在执行之前就为 DB2 所知，而且 DB2 优化器已经生成了 SQL 访问计划并把它作为数据包存储在目录中。

特定用户标识、所有用户自动归属的特定组（PUBLIC）或多个组都可以被授予（或被撤消）每种特权。图 3 是 DB2 提供的一些不同特权的示例。（注意：Table（表）和 View（视图）组中，ALTER、INDEX、REFERENCES 和 UPDATE Column 特权只适用于表。）如想要了解有关这些特权的深入讨论，请参阅 DB2 Administration Guide。

对所有种类的操作和对象的访问都由特权控制。您必须先拥有做某事的特权，DB2 才会允许您做这件事。

访问控制方法

现在您懂得了 DB2 如何管理验证和授权，让我们看一下 DB2 为了更强大的访问控制而综合这些选项所提供的框架。访问控制方法用于创建信息内容的子集，从而用户可以只查看或存取与其需要相关的数据。您可以在 DB2 中使用许多不同的访问控制方法。访问控制是为您在数据库中所进行的一切操作而存在的。

请考虑一下表 1 中视图的行。您也许希望公司里的所有用户都有权访问 L_Name、F_Name、Phone、email 和 Title 这些列。但是，为了尽可能降低垃圾邮件的风险，您也许希望通过 Web 访问公司目录的用户只能看到 L_Name、F_Name 和 Phone 这几列。最后，人力资源部的雇员应该有权访问这张表中的所有行。DB2 访问控制提供对于在 DB2 中保护您的数据和提供对数据的行级别访问非常重要的框架。

使用数据包的访问控制。数据包是与一条或多条 SQL 语句有关的信息集合，这是 DB2 内 SQL 的基本访问控制点。数据包中包括诸如优化器生成的访问计划和授权模型等信息。向数据库引擎发出的任何语句都会和特定数据包有关。

在创建数据包的时候，它就被绑定到具有特定特权的数据库。创建数据包的人一定有执行数据包中所有静态 SQL 语句所需要的特权。运行数据包的用户也一定有这个数据包的 EXECUTE 特权，但是他们不一定有执行数据包中包含的所有静态语句的一对一的特权。例如，没有 CREATETAB 特权，用户就不能在数据库中创建表。但是，有特权运行包含静态 CREATE TABLE 语句的数据包的用户可以以这种方式创建表。数据包在控制用户对数据库对象的访问权方面起了关键作用。

使用视图的访问控制。视图是另一种主要限制对数据的低级（也称为“行级”）存取的访问控制方法。通过使用视图，您就可以对 SQL 语句隐藏驻留在原始表中的敏感信息的行和列。您可以通过根据视图授予特权使用户可以存取信息。因为这些特权只适用于视图，不会影响基本表，所以用户的存取范围仅限于视图，而该视图是通过创建所需表中数据的子集生成的。WITH CHECK 选项甚至提供更多的安全性，因为它不会让特定的 SQL 语句改变用户在视图中没有特权读取的那些行。

表 1. 视图中的一行

L_Name F_Name Phone e-mail Title Salary Bonus Total Salary

Godfrey Mike 2447337 mk@money.com Mgr $23,000 $122,000 $145,000

使用触发器的访问控制。通过使用触发器，您就可以创建更复杂的安全机制，无论什么时候只要特定事件发生，安全机制就会被激活。表的 INSERT 语句就是一个示例事件，它可用于触发触发器。此外，触发器可以在特定事件之前或之后触发以提供更具活力的安全性审核。如果用户的语句没有通过触发器内的安全性审核，则从触发器主体内发出的错误将会防止表被修改。

使用 USER 专用寄存器的访问控制。DB2 提供的专用寄存器名为 USER，其中包含用于在当前会话连接数据库的用户标识。您可以在视图中使用专用寄存器中存储的值来针对特定的用户定制视图。通过使用专用寄存器，您可以使基于表的视图因用户而异。您也可以把这一技术应用于触发器和 SQL 语句。

审核功能

DB2 的审核工具使您可以维持对发生在实例内的事件的审核跟踪。成功的数据存取尝试监视和后续分析可以使数据访问控制方面得到改进，并最终防止恶意或无意非授权存取数据。然后，就可以从这些记录下来的事件中提取出一份报告供分析。 DB2 Administration Guide 中详细介绍了审核。

请信任数据库

DB2 的许多功能和机制使您甚至可以把最安全和最隐私的数据托付给数据库引擎。当您的数据由 DB2 存储和管理的时候，您可以对您的企业将在可扩展、健壮而且安全的环境中运行充满自信。另外，如果您负责数据库安全，那就意味着在晚上您可以睡得更香。

更多信息请查看IT技术专栏