本文中，我将带您浏览 Windows、Unix 和 OS/2 版本的 DB2 UDB v.7.1 中的安全特性，并描述一些可以帮助您最大化安全性的内部控制。
简介
我们面对的这个问题是：数据库安全性话题还没有象测定最短宕机时间世界记录和报告那么引人瞩目。您是在什么时候最后一次读到有关安全令牌和加密的睿智文章的呢?但正如去年大肆宣传的从一些电子商务企业中盗窃信用卡号码的事件所表明的，安全性缺口的确引人瞩目 — 而且能削弱顾客的信心。即便安全性不是最令人激动的主题，对于任何使用数据库管理系统的企业来说，它也是重要顾虑。同时，随着越来越多的企业参与电子空间，把私有数据从公共数据中分离变得尤为重要。
任何给定的公司的数据库系统可能要收集、存储和分析成千上万行信息，这些信息本质上有公共的，也有私有的。由于有这项责任在身，数据库必须使数据库管理员能适当的授权和限制访问。此外，数据库还必须提供防止未授权用户存取机密数据的方法。
但是有时候，数据库安全信息难以获得或理解。尽管您常听说 DB2 通用数据库(DB2 Universal Database，UDB)是多么可扩展、多么健壮，但您多久才会听到一次有关 DB2 的安全特性的细节呢?
因为保护数据库安全是 DBA 最重要的职责之一，所以您不应当试图通过反复试验来学习数据库安全性。保护您的数据库安全涉及：
验证
数据库安全性中最基本的概念之一就是验证，这是一个相当简单的过程，系统通过这个过程来证实用户身份。用户可以通过提供身份证明或验证令牌来响应验证请求。
很可能您已经熟悉这个概念了。如果您曾经被要求出示带照片的 ID(例如，在银行新开帐户时)，那么已经有人向您提出过验证请求了。您出示了驾驶执照(或其它带照片的 ID)从而证明自己的身份。在这种情况下，您的驾驶执照就充当了验证令牌。
图 1. DB2 授权角色
不管您在电影里看到些什么，大部分软件程序不能把未来系统(比如面部识别)用于验证。相反，大多数验证请求要求您提供用户标识和密码。您的用户标识表示您声称自己是被授权可访问该环境的人，密码则将提供您个人的验证证据。当然，这种验证假定您的密码受到很好的保护，而且您是唯一一个知道这个密码的人。
用户验证由 DB2 之外的安全性工具完成，这个工具通常是操作系统的一部分或独立产品。事实上，安全性不仅是数据库问题;操作系统厂商也要花费很多的时间、金钱和心思确保他们的产品是安全的。但是，包括 Microsoft Windows 95 和 98 在内的一些操作系统并没有本地安全机制。如果您使用的是没有安全机制的操作系统，那您可以把环境配置成依靠在更安全的系统上运行的 DB2 服务器来提供这种安全性。例如，您可以使用可靠的客户端选项，我将在文章的后面部分更多的讨论这些选项。
您也可以使用第三方产品(如由 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 客户机选择。
