DB2 9 基础（730 考试）认证指南，第 2 部分: 安全性

核心提示：DB2 安全数据库安全涉及的问题数据库安全是当今最重要的问题，您的数据库可能允许顾客通过互联网购买产品，DB2 9 基础（730 考试）认证指南，第 2 部分: 安全性，它也可能包含用来预测业务趋势的历史数据；无论是哪种情况，公司都需要可靠的数据库安全计划，第 4 部分: 处理 DB2 数据 DB2 9 基础（730

DB2 安全

数据库安全涉及的问题

数据库安全是当今最重要的问题。您的数据库可能允许顾客通过互联网购买产品，它也可能包含用来预测业务趋势的历史数据；无论是哪种情况，公司都需要可靠的数据库安全计划。

数据库安全计划应该定义：

允许谁访问实例和/或数据库

在哪里以及如何检验用户的密码

用户被授予的权限级别

允许用户运行的命令

允许用户读取和/或修改的数据

允许用户创建、修改和/或删除的数据库对象

DB2 安全机制

DB2 中有三种主要的安全机制，可以帮助 DBA 实现数据库安全计划：身份验证（authentication）、授权（authorization） 和特权（privilege）。

身份验证是用户在尝试访问 DB2 实例或数据库时遇到的第一种安全特性。DB2 身份验证与底层操作系统的安全特性紧密协作来检验用户 ID 和密码。DB2 还可以利用 Kerberos 这样的安全协议对用户进行身份验证。

授权决定用户和/或用户组可以执行的操作以及他们可以访问的数据对象。用户执行高级数据库和实例管理操作的能力由指派给他们的权限决定。在 DB2 中有 5 种不同的权限级别：SYSADM、SYSCTRL、SYSMAINT、DBADM 和 LOAD。

特权的粒度比授权要细，可以分配给用户和/或用户组。特权定义用户可以创建或删除的对象。它们还定义用户可以用来访问对象（比如表、视图、索引和包）的命令。DB2 9 中新增的一个概念是基于标签的访问控制（LBAC），它允许以更细的粒度控制谁有权访问单独的行和/或列。

要为本教程的下一节做好准备，需要在 DB2 实例中创建一个数据库。确保 %DB2INSTANCE% 变量仍然设置为 DB2，然后使用命令 db2sampl drive 创建示例数据库，这里的 drive 是希望创建示例数据库的驱动器的名称。对于本教程中的示例，将在 D: 驱动器上创建示例数据库：

D:SQLLIBBIN> db2sampl d:

客户机、服务器、网关和主机

在考虑整个数据库环境的安全性时，理解术语客户机、服务器、网关 和主机 是相当重要的。数据库环境常常由几台不同的机器组成；必须在所有潜在的数据访问点上保护数据库。在处理 DB2 身份验证时客户机、服务器、网关和主机的概念尤其重要。

下图说明了基本的客户机 - 服务器 - 主机配置。

数据库服务器 是数据库实际所在的机器（在分区的数据库系统上可能是多台机器）。DB2 数据库客户机 是对服务器上的数据库执行查询的机器。这些客户机可以是本地的（驻留在与数据库服务器相同的物理机器上），也可以是远程的（驻留在单独的机器上）。

如果数据库驻留在运行 AS/400（iSeries）或 OS/390（zSeries）的大型机上，它就称为主机 或主机服务器。网关 是一台运行 DB2 Connect 产品的机器。DB2 客户机可以通过网关连接驻留在主机上的 DB2 数据库。网关也称为 DB2 Connect 服务器。安装了 Enterprise Server Edition 产品的系统也内置了 DB2 Connect 功能。

DB2 身份验证

什么时候进行 DB2 身份验证

DB2 身份验证控制数据库安全计划的以下方面：

谁有权访问实例和/或数据库

在哪里以及如何检验用户的密码

在发出 attach 或 connect 命令时，它在底层操作系统安全特性的帮助下完成这个任务。attach 命令用来连接 DB2 实例，connect 命令用来连接 DB2 实例中的数据库。下面的示例展示了 DB2 对发出这些命令的用户进行身份验证的不同方式。这些示例在数据库管理程序配置文件中使用默认的身份验证类型 SERVER。下面的例 3 说明了如何使用 DB2 修改服务器操作系统上的密码。

用创建 DB2 实例时使用的用户 ID 登录到安装 DB2 的机器上。发出以下命令：

db2 attach to DB2

在这里，隐式地执行身份验证。使用登录机器的用户 ID，并假设这个 ID 已经经过了操作系统的检验。

db2 connect to sample user test1 using password
Database Connection Information
Database server　　　　= DB2/NT 9.1.0
SQL authorization ID　 = TEST1
Local database alias　 = SAMPLE　

在这里，显式地执行身份验证。用户 test1 和密码 password 由操作系统进行检验。用户 test1 成功地连接到示例数据库。

db2 connect to sample user test1 using password new chgpass confirm chgpass

与例 2 中一样，用户 ID test1 和密码 password 由操作系统进行检验。然后，操作系统将 test1 的密码从 password 改为 chgpass。因此，如果再次发出例 2 中的命令，它就会失败。

DB2 身份验证类型

DB2 使用身份验证类型 决定在什么地方进行身份验证。例如，在客户机 - 服务器环境中，是客户机还是服务器检验用户的 ID 和密码？在客户机 - 网关 - 主机环境中，是客户机还是主机检验用户的 ID 和密码？

DB2 9 能够根据用户是试图连接数据库，还是执行实例连接和实例级操作，指定不同的身份验证机制。在默认情况下，实例对于所有实例级和连接级请求使用一种身份验证类型。这由数据库管理程序配置参数 AUTHENTICATION 来指定。V9.1 中引入了数据库管理程序配置参数 SRVCON_AUTH。这个参数专门处理对数据库的连接。例如，如果在 DBM CFG 中进行以下设置：

DB2 GET DBM CFG
Server Connection Authentication　　　　　(SRVCON_AUTH) = KERBEROS
Database manager authentication　　　　(AUTHENTICATION) = SERVER_ENCRYPT

那么在连接实例时会使用 SERVER_ENCRYPT。但是在连接数据库时会使用 KERBEROS 身份验证。如果在服务器上没有正确地初始化 KERBEROS，但是提供了有效的用户 ID/密码，那么允许这个用户连接实例，但是不允许他连接数据库。

下表总结了可用的 DB2 身份验证类型。在客户机 - 网关 - 主机环境中，这些身份验证选项在客户机和网关上设置，而不是在主机上。本节将详细讨论如何设置这些选项。请回顾 客户机、服务器、网关和主机 小节。

类型	描述
SERVER	身份验证在服务器上进行。
SERVER_ENCRYPT	身份验证在服务器上进行。密码在客户机上进行加密，然后再发送到服务器。
CLIENT	身份验证在客户机上进行（例外情况见 处理不可信的客户机）。
*KERBEROS	由 Kerberos 安全软件执行身份验证。
*KRB_SERVER_ENCRYPT	如果客户机设置是 KERBEROS，那么由 Kerberos 安全软件执行身份验证。否则使用 SERVER_ENCRYPT。
DATA_ENCRYPT	身份验证在服务器上进行。服务器接受加密的用户 ID 和密码，并对数据进行加密。这个选项的操作方式与 SERVER_ENCRYPT 相同，但是数据也要加密。
DATA_ENCRYPT_CMP	身份验证方式与 DATA_ENCRYPT 相同，但是允许不支持 DATA_ENCRYPT 的老式客户机使用 SERVER_ENCRYPT 身份验证进行连接。在这种情况下，数据不进行加密。如果进行连接的客户机支持 DATA_ENCRYPT，就会进行数据加密，而不能降级到 SERVER_ENCRYPT 身份验证。这个身份验证类型只在服务器的数据库管理程序配置文件中是有效的，而且在客户机或网关实例上使用 CATALOG DATABASE 时是无效的。
GSSPLUGIN	身份验证方式由一个外部 GSS-API 插件决定。
GSS_SERVER_ENCRYPT	身份验证方式由一个外部 GSS-API 插件决定。在客户机不支持服务器的 GSS-API 插件之一的情况下，使用 SERVER_ENCRYPT 身份验证。

*这些设置只对 Windows 2000、AIX、Solaris 和 Linux® 操作系统有效。

在服务器上设置身份验证

在数据库服务器上，在数据库管理程序配置（DBM CFG）文件中使用 AUTHENTICATION 参数设置身份验证。请记住，DBM CFG 文件是一个实例级配置文件。因此，AUTHENTICATION 参数影响这个实例中的所有数据库。以下命令演示如何修改这个参数。

要查看配置文件中的身份验证参数：db2 get dbm cfg

要将身份验证参数修改为 server_encrypt：C:PROGRA~1SQLLIBBIN> db2 update dbm cfg using authentication server_encrypt
C:PROGRA~1SQLLIBBIN> db2stop
C:PROGRA~1SQLLIBBIN> db2start

某些身份验证类型（比如 GSSPLUGIN、KERBEROS 和 CLIENT）要求设置其他数据库管理程序配置参数，比如 TRUST_ALLCLNTS、SRV_PLUGIN_MODE 和 SRVCON_PW_PLUGIN。关于这些设置的更多细节见下文。

在网关上设置身份验证

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

在客户机上设置身份验证

我们来考虑两台单独的客户机上的两种情况。我们将一个客户机配置为连接服务器机器上的数据库（DB2 UDB LUW 分布式平台），另一个客户机连接主机上的数据库（例如 DB2 for zSeries）。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 KRB_SERVER_ENCRYPT、DATA_ENCRYPT_CMP 和 GSS_SERVER_ENCRYPT 例外）。

我们假设服务器身份验证类型设置为 SERVER。在客户机上发出以下命令对名为 sample 的服务器数据库进行编目：db2 catalog database sample at node nd1 authentication SERVER

如果没有指定身份验证类型，客户机将默认使用 SERVER_ENCRYPT。

连接主机数据库的客户机：我们假设网关上的身份验证类型设置为 SERVER。如果没有指定身份验证类型，那么在通过 DB2 Connect 访问数据库时假设采用 SERVER_ENCRYPT 身份验证。身份验证在主机数据库服务器上进行。从客户机发出以下命令会导致客户机向网关发送未加密的用户 ID 和密码：db2 catalog database myhostdb at node nd1 authentication SERVER

现在假设网关上的身份验证类型设置为 SERVER_ENCRYPT。身份验证同样在主机数据库服务器上进行。用户 ID 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

处理不可信的客户机

如果服务器或网关将身份验证类型设置为 CLIENT，那么这意味着期望客户机对用户的 ID 和密码进行身份验证。但是，一些客户机的操作系统没有本机安全特性。这种不可信的 客户机包括在 Windows 98 和 Windows ME 上运行的 DB2。DB2 V9.1 不支持 Windows 98 或 Windows ME，但是它支持低版本的客户机，所以仍然可能必须处理不可信的 V8 客户机。

在 DBM CFG 文件中有两个额外参数，用于在服务器或网关身份验证方法设置为 CLIENT，而不可信的客户机试图连接数据库或 DB2 实例时，决定应该在哪里进行身份验证。这些参数是 TRUST_ALLCLNTS 和 TRUST_CLNTAUTH 参数。

当服务器或网关身份验证类型为 CLIENT 时，除了 TRUST_ALLCLNTS 和 TRUST_CLNTAUTH 参数之外，还有两个因素会起作用。第一个因素是用户 ID 和密码是否是显式提供的，第二个因素是进行连接的客户机的类型。有三种 DB2 客户机：

不可信的客户机：如上所述

主机客户机：运行在 zSeries 这样的主机操作系统上的客户机

可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、2000、2003、XP 以及所有形式的 Unix / Linux）上的客户机

当身份验证设置为 CLIENT 时

下表总结了如果服务器的身份验证类型设置为 CLIENT，那么在每种类型的客户机向服务器发出连接命令时将在哪里进行身份验证。

是否提供了 ID/密码？	TRUST_ALLCLNTS	TRUST_CLNTAUTH	不可信的客户机	可信的客户机	主机客户机
No	Yes	CLIENT	CLIENT	CLIENT	CLIENT
No	Yes	SERVER	CLIENT	CLIENT	CLIENT
No	No	CLIENT	SERVER	CLIENT	CLIENT
No	No	SERVER	SERVER	CLIENT	CLIENT
No	DRDAONLY	CLIENT	SERVER	SERVER	CLIENT
No	DRDAONLY	SERVER	SERVER	SERVER	CLIENT
Yes	Yes	CLIENT	CLIENT	CLIENT	CLIENT
Yes	Yes	SERVER	SERVER	SERVER	SERVER
Yes	No	CLIENT	SERVER	CLIENT	CLIENT
Yes	No	SERVER	SERVER	SERVER	SERVER
Yes	DRDAONLY	CLIENT	SERVER	SERVER	CLIENT
Yes	DRDAONLY	SERVER	SERVER	SERVER	SERVER

DRDAONLY 意味着只信任主机客户机，而不管使用 DRDA 进行连接的 DB2 Version 8 客户机。

下面的示例说明如何在服务器和客户机上设置身份验证类型和参数：

在服务器上设置身份验证：

db2 update dbm cfg using authentication client
db2 update dbm cfg using trust_allclnts yes
db2 update dbm cfg using trust_clntauth server
db2stop
db2start

在客户机上设置身份验证：

db2 catalog database sample at node nd1 authentication client

在上面的示例中，如果从任何客户机发出命令db2 connect to sample

那么身份验证在客户机上进行。如果从任何客户机发出命令db2 connect to sample user test1 using password

那么身份验证在服务器上进行。

DB2 的安全插件架构

DB2 V8.2 引入了安全插件的概念。这个概念在 DB2 V9.1 中得到了进一步增强。通过使用标准的 GSS-API 调用，用户可以编写一个安全插件并将对用户 ID 进行身份验证的工作交给一个外部安全程序。这种方式的一个示例是 DB2 本身的 KERBEROS 身份验证。在一台机器上安装 DB2 ESE 或应用程序开发客户机时，安装过程中将有一些示例应用程序代码放入实例目录，如果查看 samplessecurityplugins 目录，就会看到如何编写安全插件的示例。本节将概述如何在 DB2 安全架构中使用插件，但是不讨论如何编写或编译插件本身。

Kerberos 身份验证

Kerberos 身份验证为 DB2 提供了一种无需通过网络发送用户 ID 和密码的用户身份验证方法。Kerberos 安全协议作为第三方身份验证服务执行身份验证，它使用传统的密码术创建一个共享的密钥。这个密钥成为用户的凭证，在请求本地或网络服务时在所有情况下都使用它检验用户的身份。通过使用 Kerberos 安全协议，可以实现对远程 DB2 数据库服务器的单点登录。

首先，讨论如何设置 DB2 来使用 Kerberos 身份验证。如上所述，Kerberos 身份验证在 DB2 中是使用插件架构实现的。默认的 kerberos 插件的源代码在 samples/security/plugins 目录中，称为 IBMkrb5.c。在 DB2 中使用 Kerberos 之前，必须在客户机和服务器上启用和支持 Kerberos。为此，必须满足以下条件：

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。

必须设置适当的主体（Kerberos 中的用户 ID）。

必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。

所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

还可以告诉客户机它正在针对哪个服务器主体进行身份验证。这个选项可以避免 Kerberos 身份验证的第一步，即客户机寻找它要连接的实例的服务器主体。在客户机上对数据库进行编目时可以指定 AUTHENTICATION 参数。它的格式是：DB2 CATALOG DB dbname AT NODE node name AUTHENTICATION KERBEROS TARGET PRINCIPAL
　 service/host@REALM

这一步是可选的。

DB2 CATALOG DB sample AT NODE testnd AUTHENTICATION KERBEROS TARGET PRINCIPAL
　 gmilne/gmilne02.torolab.ibm.com@TOROLAB.IBM.COM

设置 Kerberos 身份验证的下一步是设置服务器。srvcon_gssplugin_list 参数可以设置为支持的 GSS-API 插件的列表，但是只允许有一个 Kerberos 插件。如果这个列表中没有 Kerberos 插件，那么自动地使用默认的 IBMkrb5 插件。如果希望允许所有身份验证（实例连接和数据库连接）使用 Kerberos，那么执行以下命令：

DB2 UPDATE DBM CFG USING AUTHENTICATION KERBEROS
or
DB2 UPDATE DBM CFG USING AUTHENTICATION KRB_SERVER_ENCRYPT

如果只希望 DB2 使用 Kerberos 对数据库连接进行身份验证（对实例连接使用 SERVER），那么执行以下命令：

DB2 UPDATE DBM CFG USING SVRCON_AUTH KERBEROS
or
DB2 UPDATE DBM CFG USING SVRCON_AUTH KRB_SERVER_ENCRYPT

根据实例的位长度（32 或 64 位），DB2 将在实例启动时自动地装载 IBMkrb5 插件。

其他身份验证设置

如果查看 V9.1 实例中的 DBM CFG，会看到影响 DB2 对用户 ID 进行身份验证的方式的各种设置。正如前面提到的，有针对标准操作系统用户 ID 身份验证的设置（CLIENT、SERVER、SERVER_ENCRYPT、DATA_ENCRYPT、DATA_ENCRYPT_CMP），还有将身份验证工作交给外部程序的插件（KERBEROS、KRB_SERVER_ENCRYPT、GSSPLUGIN、GSS_SERVER_ENCRYPT）。本节专门介绍其他一些配置变量如何影响对用户的身份验证。

Client Userid-Password Plugin　　　　　(CLNT_PW_PLUGIN) =
Group Plugin　　　　　　　　　　　　　　 (GROUP_PLUGIN) =
GSS Plugin for Local Authorization　　(LOCAL_GSSPLUGIN) =
Server Plugin Mode　　　　　　　　　　(SRV_PLUGIN_MODE) = UNFENCED
Server List of GSS Plugins　　　(SRVCON_GSSPLUGIN_LIST) =
Server Userid-Password Plugin　　　　(SRVCON_PW_PLUGIN) =
Cataloging allowed without authority　 (CATALOG_NOAUTH) = NO
Bypass federated authentication　　　　　　(FED_NOAUTH) = NO

在上面的列表中，去掉了已经讨论过的参数。

CLNT_PW_PLUGIN	这个参数在客户端的 DBM CFG 中指定。它指定用来进行客户机和本地身份验证的客户机插件的名称。
GROUP_PLUGIN	默认值是空（NULL）。将它设置为用户定义的插件就会调用这个插件进行所有组枚举，而不依赖于操作系统的组查找。这与后面讨论的授权部分相关。
LOCAL_GSSPLUGIN	这个参数指定默认的 GSS-API 插件库的名称，当数据库管理程序配置的身份验证参数值设置为 GSSPLUGIN 或 GSS_SERVER_ENCRYPT 时，这个库用来进行实例级的本地授权。
SRV_PLUGIN_MODE	（YES/NO）这个参数的默认设置是 NO。当改为 YES 时，以 FENCED 模式启动 GSS-API 插件，其工作方式类似于 FENCED 存储过程。FENCED 插件的崩溃不会导致 DB2 实例崩溃。在插件还处于开发阶段时，建议以 fenced 模式运行它们，这样的话插件中的逻辑问题和内存泄漏就不会导致实例崩溃。在确定插件是可靠的之后，应该以 unfenced 模式运行以提高性能。
SRVCON_GSSPLUGIN_LIST	一个插件列表，当使用 KERBEROS、KRB_SERVER_ENCRYPT、GSSPLUGIN 或 GSS_SERVER_ENCRYPT 时，服务器上的数据库管理程序在身份验证期间将使用这些插件。列表中的每个插件应该用逗号（‘,’）分隔，它们之间没有空格。插件按照优先次序列出，首先使用列表中的第一个插件对发送的用户 ID/密码进行身份验证。只有当列出的所有插件都返回了错误时，DB2 才会向用户返回身份验证错误。
SRVCON_PW_PLUGIN	在指定 CLIENT、SERVER 或 SERVER_ENCRYPT 身份验证时，这个参数允许用户修改 DB2 用来检验用户 ID 和密码的默认身份验证方法。在默认情况下，它的值是 NULL，因此使用默认的 DB2 方法。
CATALOG_NOAUTH	（YES/NO）默认值是 NO。将这个参数修改为 YES 就允许不属于 SYSADM、SYSCTRL 或 SYSMAINT 组成员的用户修改机器上的 Database、Node、Admin 和 DCS 编目。如果登录的用户使用不可信客户机（定义见上文），或者登录所用的用户 ID 不允许连接数据库或实例，但是用户又必须在客户机上进行编目，只有在这种情况下这个参数才是有用的。
FED_NOAUTH	如果 fed_noauth 设置为 yes，身份验证设置为 server 或 server_encrypt，联邦设置为 yes，那么在实例上避免进行身份验证。它假设身份验证在数据源上进行。当 fed_noauth 设置为 yes 时系统会发出警告。在客户机和 DB2 服务器上都不进行身份验证。知道 SYSADM 身份验证名称的任何用户都拥有联邦服务器的 SYSADM 权限。

DB2 授权

授权简介

DB2 授权控制数据库安全计划的以下方面：

用户被授予的权限级别

允许用户运行的命令

允许用户读取和/或修改的数据

允许用户创建、修改和/或删除的数据库对象

授权由特权组和高级数据库管理程序（实例级）维护和实用操作组成。在 DB2 可用的 5 种权限中，SYSADM、SYSCTRL 和 SYSMAINT 是实例级权限。这意味着它们的范围包含实例级命令以及针对这个实例中的所有数据库的命令。这些权限只能分配给组；可以通过 DBM CFG 文件分配这些权限。

针对特定数据库的 DBADM 和 LOAD 权限可以分配给用户或用户组。可以使用 GRANT 命令显式地分配这些权限。

以下几节描述如何分配每种权限以及允许拥有此权限的用户执行哪些命令。注意，任何提到组成员关系的地方都假设在操作系统级上已经定义了这些用户和组名。

用户可以通过发出以下命令来判断自己拥有哪些权限和数据库级特权：

db2 get authorizations

获得 SYSADM 权限

DB2 中的 SYSADM 权限就像是 UNIX 上的根权限或 Windows 上的 Administrator 权限。对一个 DB2 实例拥有 SYSADM 权限的用户能够对这个实例、这个实例中的任何数据库以及这些数据库中的任何对象发出任何 DB2 命令。他们还能够访问数据库中的数据以及对其他用户授予或撤消特权或权限。只允许 SYSADM 用户更新 DBM CFG 文件。

SYSADM 权限由 DBM CFG 文件中的 SYSADM_GROUP 参数控制。在 Windows 上，在创建实例时，这个参数设置为 Administrator（但是，如果发出命令 db2 get dbm cfg，它看起来是空的）。在 UNIX 上，它设置为创建这个实例的用户的主组。

因为只允许 SYSADM 用户更新 DBM CFG 文件，所以只有他们能够向其他组授予任何 SYS* 权限。以下示例演示如何向 db2grp1 组授予 SYSADM 权限：db2 update dbm cfg using SYSADM_GROUP db2grp1

请记住，这一修改直到实例停止并重新启动之后才会生效。还要记住，如果您当前不是作为 db2grp1 组的成员登录的，那么就无权重新启动实例！您必须注销并用正确的组中的 ID 重新登录，或者将自己当前的 ID 添加进 db2grp1 组中。

获得 SYSCTRL 权限

拥有 SYSCTRL 权限的用户可以在实例中执行所有管理和维护命令。但是，与 SYSADM 用户不同，他们不能访问数据库中的任何数据，除非他们被授予了访问数据所需的特权。SYSCTRL 用户可以对实例中的任何数据库执行的命令示例如下：

db2start/db2stop

db2 create/drop database

db2 create/drop tablespace

db2 backup/restore/rollforward database

db2 runstats（针对任何表）

db2 update db cfg for database dbname

拥有 SYSADM 权限的用户可以使用以下命令将 SYSCTRL 分配给一个组：

db2 update dbm cfg using SYSCTRL_GROUP group name

获得 SYSMAINT 权限

拥有 SYSMAINT 权限的用户可以发出的命令是拥有 SYSCTRL 权限的用户可以发出的命令的子集。SYSMAINT 用户只能执行与维护相关的任务，比如：

db2start/db2stop

db2 backup/restore/rollforward database

db2 runstats（针对任何表）

db2 update db cfg for database dbname

注意，拥有 SYSMAINT 权限的用户不能创建或删除数据库或表空间。他们也不能访问数据库中的任何数据，除非他们被显式地授予访问数据所需的特权。

如果您拥有 SYSADM 权限，那么可以使用以下命令将 SYSMAINT 权限分配给一个组：

db2 update dbm cfg using SYSMAINT_GROUP group name

获得 DBADM 权限

DBADM 权限是一个数据库级权限，而不是实例级权限。DBADM 用户对一个数据库有几乎完全的控制能力。DBADM 用户不能执行某些维护或管理任务，比如：

drop database

drop/create tablespace

backup/restore database

update db cfg for database db name

但是，他们可以执行以下任务：

db2 create/drop table

db2 grant/revoke（任何特权）

db2 runstats（任何表）

DBADM 用户还被自动地授予对数据库对象及其内容的所有特权。因为 DBADM 权限是一个数据库级权限，所以它可以被分配给用户和用户组。以下命令演示授予 DBADM 权限的不同方法。

db2 create database test

这个命令将数据库 test 上的 DBADM 权限隐式地授予发出此命令的用户。

db2 connect to sample

db2 grant dbadm on database to user tst1

这个命令只能由 SYSADM 用户发出；它向用户 tst1 授予示例数据库上的 DBADM 权限。注意，在授予 DBADM 权限之前，发出这个命令的用户必须连接到示例数据库。

db2 grant dbadm on database to group db2grp1

这个命令将 DBADM 权限授予 db2grp1 组中的每个用户。同样，只有 SYSADM 用户能够发出这个命令。

获得 LOAD 权限

LOAD 权限是一个数据库级权限，所以它可以被分配给用户和用户组。顾名思义，LOAD 权限允许用户对表发出 LOAD 命令。当用大量数据填充表时，LOAD 命令通常用来替代插入或导入命令，它的速度更快。根据您希望执行的 LOAD 操作类型，仅仅拥有 LOAD 权限可能还不够。可能还需要表上的特定特权。

拥有 LOAD 权限的用户可以运行以下命令：

db2 quiesce tablespaces for table

db2 list tablespaces

db2 runstats（任何表）

db2 load insert（必须有表上的插入特权）

db2 load restart/terminate after load insert（必须有表上的插入特权）

db2 load replace（必须有表上的插入和删除特权）

db2 load restart/terminate after load replace（必须有表上的插入和删除特权）

只有拥有 SYSADM 或 DBADM 权限的用户能够对用户或用户组授予或撤消 LOAD 权限。以下示例演示 LOAD 权限如何允许我们的用户使用 LOAD 命令将数据装载进 sales 表中。假设已经发出了命令 db2 connect to sample。

db2 grant load on database to user tst1

db2 grant insert on table sales to user tst1

有了 LOAD 权限和插入特权，tst1 就可以对 sales 表发出 LOAD INSERT 或 LOAD RESTART，或者在 LOAD INSERT 之后发出 TERMINATE。

db2 grant load on database to group grp1

db2 grant delete on table sales to group grp1

db2 grant insert on table sales to group grp1

有了 LOAD 权限以及删除和插入特权，grp1 的任何成员就可以对 sales 表发出 LOAD REPLACE 或 LOAD RESTART，或者在 LOAD REPLACE 之后发出 TERMINATE。

DB2 特权

数据库和对象特权

在前一节中，简要地提到了特权的概念。特权大体上分成两类：数据库级特权（针对数据库中的所有对象）和对象级特权（与特定的对象相关联）。

用户可以拥有的数据库级特权有：

CREATETAB： 用户可以在数据库中创建表。

BINDADD： 用户可以使用 BIND 命令在数据库中创建包。

CONNECT： 用户可以连接数据库。

CREATE_NOT_FENCED： 用户可以创建 unfenced 用户定义函数（UDF）。

IMPLICIT_SCHEMA： 用户可以在数据库中隐式地创建模式，而不需要使用 CREATE SCHEMA 命令。

LOAD： 用户可以将数据装载进表中。

QUIESCE_CONNECT： 用户可以访问处于静默（quiesced）状态的数据库。

CREATE_EXTERNAL_ROUTINE： 用户可以创建供应用程序和数据库的其他用户使用的过程。

数据库对象 包括表、视图、索引、模式和包。幸运的是，大多数对象级特权的意义无需解释。下表总结了这些特权。

特权名称	相关对象	描述
CONTROL	表、视图、索引、包、别名、不同的类型、用户定义函数、序列	提供对对象的全部权限。拥有这种特权的用户还可以向其他用户授予或撤消对对象的特权。
DELETE	表、视图	允许用户从对象中删除记录。
INSERT	表、视图	允许用户通过 INSERT 或 IMPORT 命令将记录插入对象中。
SELECT	表、视图	提供使用选择语句来查看对象内容的能力。
UPDATE	表、视图	允许用户使用更新语句修改对象中的记录。
ALTER	表	允许用户使用更改语句更改对象定义。
INDEX	表	允许用户使用创建索引语句在对象上创建索引。
REFERENCES	表	提供在对象上创建或删除外键约束的能力。
BIND	包	允许用户重新绑定现有的包。
EXECUTE	包、过程、函数、方法	允许用户执行包和例程。
ALTERIN	模式	允许用户修改模式中的对象定义。
CREATEIN	模式	允许用户在模式中创建对象。
DROPIN	模式	允许用户删除模式中的对象。

关于对象级特权的信息存储在系统编目视图中。视图名称是 syscat.tabauth、syscat.colauth、syscat.indexauth、syscat.schemaauth、syscat.routineauth 和 syscat.packageauth。

显式特权

可以使用 GRANT 和 REVOKE 命令显式地 对用户或组授予或撤消特权。我们来看看如何在各种对象上使用这些命令。

作为拥有 Administrator 权限的用户登录 Windows，打开两个 DB2 命令窗口。在这两个窗口中，确保将 db2instance 变量设置为 DB2！

在第一个窗口中发出以下命»¤：db2 connect to sample

现在，在第二个窗口中发出以下命令：db2 connect to sample user test1 using password

请记住，第一个窗口中的命令是由一个拥有 SYSADM 权限的用户发出的。第二个窗口中的命令是由 tst1 发出的，这个用户对示例数据库没有特殊的权限或特权。注意，与示例数据库中的表相关联的模式名是发出 db2sampl 命令的用户的名称。在这些示例中，这个用户是 GMILNE。

现在，在第二个窗口中发出以下命令：db2 select * from gmilne.org

应该会看到以下响应：SQL0551N　"TEST1" does not have the privilege to perform operation "SELECT"
on object "GMILNE.ORG".

为了纠正这种状况，在第一个窗口中发出以下命令：db2 grant select on table gmilne.org to user test1

现在，前面的命令就会成功！接下来，在第二个窗口中发出一个更复杂的命令：db2 insert into gmilne.org values (100, 'Tutorial', 1, 'Eastern', 'Toronto')

同样会看到错误消息：

SQL0551N　"TEST1" does not have the privilege to perform operation　"INSERT"
on object "GMILNE.ORG"

所以，在第一个窗口中输入以下命令：

db2 grant insert on table gmilne.org to group db2grp1

原来失败的 INSERT 命令现在应该会成功完成，因为 test1 是 db2grp1 组的成员。

现在，在第二个窗口中输入以下命令：

db2 drop table gmilne.emp_photo

同样会看到错误消息：

SQL0551N　"TEST1" does not have the privilege to perform operation "DROP TABLE"
on object "GMILNE.EMP_PHOTO".

所以，我们要授予这个特权。在第一个窗口中输入以下命令：db2 grant dropin on schema gmilne to all

DROP TABLE 命令现在应该会成功完成。

既然已经完成了示例，就可以撤消刚才授予的特权。在第一个窗口中发出以下命令：db2 revoke select on table gmilne.org from user test1
db2 revoke insert on table gmilne.org from group db2grp1
db2 revoke dropin on schema gmilne from all

注意，从组中撤消特权不一定会从这个组的所有成员撤消它。例如，以下命令可以用来从 db2grp1 撤消对 gmilne.org 表的所有特权（CONTROL 除外）：db2 revoke all on table gmilne.org from group db2grp1

但是，test1 用户（他是 db2grp1 的成员）仍然拥有对这个表的选择特权，因为他或她是被直接授予这个特权的。

隐式特权

当发出某些命令时，DB2 可能会自动地授予特权，而不需要像前面看到的那样发出显式的 GRANT 语句。下表总结了会导致数据库管理程序隐式地授予特权的一些命令。注意，当删除创建的对象时，这些特性会隐式地撤消。但是，当显式地撤消更高级的特权时，不会撤消它们。

发出的命令	授予的特权	被授予特权的用户
CREATE TABLE mytable	mytable 上的 CONTROL	发出命令的用户
CREATE SCHEMA myschema	myschema 上的 CREATEIN、ALTERIN 和 DROPIN，以及将这些特权授予其他用户的能力	发出命令的用户
CREATE VIEW myview	myview 上的 CONTROL（只有在用户拥有 myview 定义中引用的所有表和视图上的 CONTROL 特权的情况下）	发出命令的用户
CREATE DATABASE mydb	mydb 的系统编目表上的 SELECT，mydb 上的 IMPLICIT_SCHEMA *	PUBLIC**

*当用户创建数据库时，隐式地授予这个用户这个数据库上的 DBADM 权限。获得 DBADM 权限就会隐式地授予 CONNECT、CREATETAB、BINDADD、IMPLICIT_SCHEMA 和 CREATE_NOT_FENCED 特权。即使撤消了 DBADM 权限，这个用户仍然会保留这些特权。

**PUBLIC 是一个特殊的 DB2 组，其中包括特定数据库的所有用户。与前面讨论过的其他组不同，PUBLIC 不必在操作系统级进行定义。在默认情况下，会向 PUBLIC 授予一些特权。例如，这个组自动接受数据库上的 CONNECT 特权和编目表上的 SELECT 特权。可以对 PUBLIC 组发出 GRANT 和 REVOKE 命令，比如：

db2 grant select on table sysibm.systables to public
db2 revoke select on table sysibm.systables from public

间接特权

当数据库管理器执行包 时，可以间接获得特权。包中包含一个或多个 SQL 语句，这些语句已经转换为 DB2 用来在内部执行它们的格式。换句话说，包中包含可执行格式的多个 SQL 语句。如果包中的所有语句都是静态的，那么用户只需要有包上的 EXECUTE 特权，就能够成功地执行包中的语句。

例如，假设 db2package1 执行以下静态的 SQL 语句：

db2 select * from org
db2 insert into test values (1, 2, 3)

在这种情况下，拥有 db2package1 上的 EXECUTE 特权的用户会间接地获得 org 表上的 SELECT 特权和 test 表上的 INSERT 特权。

基于标签的访问控制

DB2 9 中新增的一个概念是基于标签的访问控制（LBAC）。LBAC 为 DBA 提供了在表的行或列级限制读/写特权的能力。

在以前，进行这种限制的惟一方法是创建一个视图，授权用户使用这个视图，并撤消对基表的访问权。

本教程只演示 LBAC 安全场景的一个示例。关于 LBAC 的更详细解释，请参考 developerWorks 上的 DB2 Label-Based Access Control, a practical guide, Part 1: Understand the basics of LBAC in DB2。

LBAC 由安全管理员 通过创建安全策略来设置。每个表只能由一个安全策略来控制，但是系统中可以有任意数量的安全策略。设置 LBAC 需要几个步骤。必须做的第一件事情是，决定对于您的数据需要什么类型的访问控制。

我们做出以下假设。在您的组织中有三类人。

名称	在组织中的角色
Jane	人力资源执行官
Joe	D11 和 E21 部门的经理
Frank	团队主管 - A00 部门

现在，在组织的数据库中有一个定义职员信息的表。这个表类似于 SAMPLE 数据库中的 EMP 表。它包含关于职员和他们所属的部门的数据。它现在的定义如下：

　　　　　　　　db2 => describe select * from emp
SQLDA Information
sqldaid : SQLDA　　 sqldabc: 896　sqln: 20　sqld: 14
Column Information
sqltype　　　　　　　 sqllen　sqlname.data　　　　　　　　　　sqlname.length
--------------------　------　------------------------------　--------------
452　 CHARACTER　　　　　　6　EMPNO　　　　　　　　　　　　　　　　　　　　5
448　 VARCHAR　　　　　　 12　FIRSTNME　　　　　　　　　　　　　　　　　　 8
453　 CHARACTER　　　　　　1　MIDINIT　　　　　　　　　　　　　　　　　　　7
448　 VARCHAR　　　　　　 15　LASTNAME　　　　　　　　　　　　　　　　　　 8
453　 CHARACTER　　　　　　3　WORKDEPT　　　　　　　　　　　　　　　　　　 8
453　 CHARACTER　　　　　　4　PHONENO　　　　　　　　　　　　　　　　　　　7
385　 DATE　　　　　　　　10　HIREDATE　　　　　　　　　　　　　　　　　　 8
453　 CHARACTER　　　　　　8　JOB　　　　　　　　　　　　　　　　　　　　　3
500　 SMALLINT　　　　　　 2　EDLEVEL　　　　　　　　　　　　　　　　　　　7
453　 CHARACTER　　　　　　1　SEX　　　　　　　　　　　　　　　　　　　　　3
385　 DATE　　　　　　　　10　BIRTHDATE　　　　　　　　　　　　　　　　　　9
485　 DECIMAL　　　　　 9, 2　SALARY　　　　　　　　　　　　　　　　　　　 6
485　 DECIMAL　　　　　 9, 2　BONUS　　　　　　　　　　　　　　　　　　　　5
485　 DECIMAL　　　　　 9, 2　COMM　　　　　　　　　　　　　　　　　　　　 4

组织会定期对规则进行审计。审计指出，职员不应该能够访问机密的数据。规则规定，执行官对所有职员记录有完全的读/写访问权，经理对自己部门的职员记录有读/写访问权，而团队主管只能读取部门中他们领导的职员的记录。

我们要设置 LBAC 安全策略来实现这些规则。

定义安全策略和标签，并将安全标签授予用户

在 EMP 表中添加安全标签列并将安全策略连接到它

定义安全策略和标签

为了定义安全策略和标签，需要 SECADM 权限。

步骤 1a. 创建安全标签组件

首先，需要决定对于这个策略最合适的安全组件类型。在这个示例中，最合适的策略类型是 “TREE”。Tree 策略意味着可以定义一组标签，让子组件拥有它们的父组件的权限的子集。在这个示例中，创建一个名为 “J_DEPT” 的安全组件。

　　　　　　CREATE SECURITY LABEL COMPONENT J_DEPT
　　　　TREE ('HR_EXECUTIVE' ROOT,
　　　　　　　'MAN_D11_E21' UNDER 'HR_EXECUTIVE'
　　　　　　　'A00' UNDER 'HR_EXECUTIVE',
　　　　　　　'B01' UNDER 'HR_EXECUTIVE',
　　　　　　　'C01' UNDER 'HR_EXECUTIVE',
　　　　　　　'D11' UNDER 'MAN_D11_E21',
　　　　　　　'D21' UNDER 'HR_EXECUTIVE',
　　　　　　　'E01' UNDER 'HR_EXECUTIVE',
　　　　　　　'E11' UNDER 'HR_EXECUTIVE',
　　　　　　　'E21' UNDER 'MAN_D11_E21'
　　　　)

上面的布局说明根是 HR_EXECUTIVE，这个执行官领导的所有部门都是它的子组件。

步骤 1b. 定义安全策略

在上面的示例中，设置 LBAC 所需的下一个步骤是定义与上面的安全标签组件相关联的策略。一个安全策略可以使用多个组件。

　　　　　CREATE SECURITY POLICY J_DEPT_POLICY
　　　　　　 COMPONENTS J_DEPT
　　　　　　 WITH DB2LBACRULES
　　　　　　 RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL

步骤 1c. 创建安全标签

设置安全策略的第三步是创建安全标签。在这里将指定每个用户具有的不同角色。因为这个示例非常简单，只有三个标签，Executive、Manager 和 Team Lead。

　　　CREATE SECURITY LABEL J_DEPT_POLICY.EXECUTIVE
　　　　　　 COMPONENT J_DEPT 'HR_EXECUTIVE'
　　　　　　
　　　CREATE SECURITY LABEL J_DEPT_POLICY.MANAGE_D11_E21
　　　　　　 COMPONENT J_DEPT 'MAN_D11_E21'
　　　　　　
　　　CREATE SECURITY LABEL J_DEPT_POLICY.A00
　　　　　　 COMPONENT J_DEPT 'A00'
　　　　　　
　　　CREATE SECURITY LABEL J_DEPT_POLICY.B01
　　　　　　 COMPONENT J_DEPT 'B01'
　　　　　　
　　　CREATE SECURITY LABEL J_DEPT_POLICY.C01
　　　　　　 COMPONENT J_DEPT 'C01'
　　　CREATE SECURITY LABEL J_DEPT_POLICY.D11
　　　　　　 COMPONENT J_DEPT 'D11'
　　　CREATE SECURITY LABEL J_DEPT_POLICY.D21
　　　　　　 COMPONENT J_DEPT 'D21'
　　　CREATE SECURITY LABEL J_DEPT_POLICY.E01
　　　　　　 COMPONENT J_DEPT 'E01'
　　　CREATE SECURITY LABEL J_DEPT_POLICY.E11
　　　　　　 COMPONENT J_DEPT 'E11'
　　　CREATE SECURITY LABEL J_DEPT_POLICY.E21
　　　　　　 COMPONENT J_DEPT 'E21'　　　　　　

在下一步中，将定义与这些标签相关联的实际权限。

步骤 1d. 根据标签授予权限

下面的步骤描述对表数据授予权限的过程。权限可以是 ALL ACCESS、WRITE ACCESS 或 READ ACCESS。如果这些权限都没有授予一个用户，那么这个用户就不能访问任何表数据。请记住，执行官有完全的访问权，经理对自己的部门有完全的访问权，而团队主管对他们领导的部门成员有读访问权。

db2 grant security label J_DEPT_POLICY.A00 to user Frank for read access
db2 grant security label J_DEPT_POLICY.MANAGE_D11_E21 to user Joe for all access
db2 grant security label J_DEPT_POLICY.EXECUTIVE to user Jane for all access

在用户上设置以上标签，就会根据步骤 1a 中的树定义来分配权限。因为用户 Joe 被标为 MANAGE_D11_E21 并获得所有权限，他将能够读写那些安全标记为 J_DEPT_POLICY.D11 或 J_DEPT_POLICY.E21 的行（因为它们是他的子组件）。

步骤 2. 修改 EMP 表

在修改 EMP 表时，必须创建一个额外的列来存储安全标签。这个列的类型是 “DB2SECURITYLABEL”。您可以修改 SAMPLE 数据库中现有的 EMP 表。为此，必须使用在这个策略中被授予根级特权的用户，在这个示例中就是用户 Jane。还必须先从 SAMPLE 数据库删除 MQT 表 ADEFUSR。

CONNECT TO SAMPLE
　 Database Connection Information
Database server　　　　= DB2/NT 9.1.0
SQL authorization ID　 = GMILNE
Local database alias　 = SAMPLE　
DROP TABLE ADEFUSR
CONNECT RESET
CONNECT TO SAMPLE USER Jane USING password
ALTER TABLE EMP
　　　　ADD COLUMN DEPT_TAG DB2SECURITYLABEL
　　　　ADD SECURITY POLICY J_DEPT_POLICY

如果从 EMP 表进行选择，就会看到刚定义的新列。因为是用在 EXECUTIVE 级上定义的用户执行这一修改，添加的所有安全标记都是 EXECUTIVE。为了改变这一情况，需要更新这个表。

db2 => select EMPNO, FIRSTNME, LASTNAME, WORKDEPT, SALARY,
varchar(SECLABEL_TO_CHAR('J_DEPT_POLICY',DEPT_TAG),30) from gmilne.emp
EMPNO　FIRSTNME　　 LASTNAME　　　　WORKDEPT SALARY　　　6
------ ------------ --------------- -------- ----------- ------------------------------
000010 CHRISTINE　　HAAS　　　　　　A00　　　　152750.00 HR_EXECUTIVE
000020 MICHAEL　　　THOMPSON　　　　B01　　　　 94250.00 HR_EXECUTIVE
000030 SALLY　　　　KWAN　　　　　　C01　　　　 98250.00 HR_EXECUTIVE
000050 JOHN　　　　 GEYER　　　　　 E01　　　　 80175.00 HR_EXECUTIVE
000060 IRVING　　　 STERN　　　　　 D11　　　　 72250.00 HR_EXECUTIVE
000070 EVA　　　　　PULASKI　　　　 D21　　　　 96170.00 HR_EXECUTIVE
000090 EILEEN　　　 HENDERSON　　　 E11　　　　 89750.00 HR_EXECUTIVE
000100 THEODORE　　 SPENSER　　　　 E21　　　　 86150.00 HR_EXECUTIVE
000110 VINCENZO　　 LUCCHESSI　　　 A00　　　　 66500.00 HR_EXECUTIVE
000120 SEAN　　　　 O'CONNELL　　　 A00　　　　 49250.00 HR_EXECUTIVE
000130 DELORES　　　QUINTANA　　　　C01　　　　 73800.00 HR_EXECUTIVE
000140 HEATHER　　　NICHOLLS　　　　C01　　　　 68420.00 HR_EXECUTIVE
000150 BRUCE　　　　ADAMSON　　　　 D11　　　　 55280.00 HR_EXECUTIVE
000160 ELIZABETH　　PIANKA　　　　　D11　　　　 62250.00 HR_EXECUTIVE
000170 MASATOSHI　　YOSHIMURA　　　 D11　　　　 44680.00 HR_EXECUTIVE
000180 MARILYN　　　SCOUTTEN　　　　D11　　　　 51340.00 HR_EXECUTIVE
000190 JAMES　　　　WALKER　　　　　D11　　　　 50450.00 HR_EXECUTIVE
000200 DAVID　　　　BROWN　　　　　 D11　　　　 57740.00 HR_EXECUTIVE
000210 WILLIAM　　　JONES　　　　　 D11　　　　 68270.00 HR_EXECUTIVE
000220 JENNIFER　　 LUTZ　　　　　　D11　　　　 49840.00 HR_EXECUTIVE
000230 JAMES　　　　JEFFERSON　　　 D21　　　　 42180.00 HR_EXECUTIVE
000240 SALVATORE　　MARINO　　　　　D21　　　　 48760.00 HR_EXECUTIVE
000250 DANIEL　　　 SMITH　　　　　 D21　　　　 49180.00 HR_EXECUTIVE
000260 SYBIL　　　　JOHNSON　　　　 D21　　　　 47250.00 HR_EXECUTIVE
000270 MARIA　　　　PEREZ　　　　　 D21　　　　 37380.00 HR_EXECUTIVE
000280 ETHEL　　　　SCHNEIDER　　　 E11　　　　 36250.00 HR_EXECUTIVE
000290 JOHN　　　　 PARKER　　　　　E11　　　　 35340.00 HR_EXECUTIVE
000300 PHILIP　　　 SMITH　　　　　 E11　　　　 37750.00 HR_EXECUTIVE
000310 MAUDE　　　　SETRIGHT　　　　E11　　　　 35900.00 HR_EXECUTIVE
000320 RAMLAL　　　 MEHTA　　　　　 E21　　　　 39950.00 HR_EXECUTIVE
000330 WING　　　　 LEE　　　　　　 E21　　　　 45370.00 HR_EXECUTIVE
000340 JASON　　　　GOUNOT　　　　　E21　　　　 43840.00 HR_EXECUTIVE
200010 DIAN　　　　 HEMMINGER　　　 A00　　　　 46500.00 HR_EXECUTIVE
200120 GREG　　　　 ORLANDO　　　　 A00　　　　 39250.00 HR_EXECUTIVE
200140 KIM　　　　　NATZ　　　　　　C01　　　　 68420.00 HR_EXECUTIVE
200170 KIYOSHI　　　YAMAMOTO　　　　D11　　　　 64680.00 HR_EXECUTIVE
200220 REBA　　　　 JOHN　　　　　　D11　　　　 69840.00 HR_EXECUTIVE
200240 ROBERT　　　 MONTEVERDE　　　D21　　　　 37760.00 HR_EXECUTIVE
200280 EILEEN　　　 SCHWARTZ　　　　E11　　　　 46250.00 HR_EXECUTIVE
200310 MICHELLE　　 SPRINGER　　　　E11　　　　 35900.00 HR_EXECUTIVE
200330 HELENA　　　 WONG　　　　　　E21　　　　 35370.00 HR_EXECUTIVE
200340 ROY　　　　　ALONZO　　　　　E21　　　　 31840.00 HR_EXECUTIVE
　42 record(s) selected.
update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','A00')) where WORKDEPT='A00'
update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','B01')) where WORKDEPT='B01'
update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','C01')) where WORKDEPT='C01'
update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','D11')) where WORKDEPT='D11'
update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','D21')) where WORKDEPT='D21'
update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','E01')) where WORKDEPT='E01'
update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','E11')) where WORKDEPT='E11'
update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','E21')) where WORKDEPT='E21'
db2 => select EMPNO, FIRSTNME, LASTNAME, WORKDEPT, SALARY,
varchar(SECLABEL_TO_CHAR('J_DEPT_POLICY',DEPT_TAG),30) from emp
EMPNO　FIRSTNME　　 LASTNAME　　　　WORKDEPT SALARY　　　6
------ ------------ --------------- -------- ----------- ------------------------------
000010 CHRISTINE　　HAAS　　　　　　A00　　　　152750.00 A00
000020 MICHAEL　　　THOMPSON　　　　B01　　　　 94250.00 B01
000030 SALLY　　　　KWAN　　　　　　C01　　　　 98250.00 C01
000050 JOHN　　　　 GEYER　　　　　 E01　　　　 80175.00 E01
000060 IRVING　　　 STERN　　　　　 D11　　　　 72250.00 D11
000070 EVA　　　　　PULASKI　　　　 D21　　　　 96170.00 D21
000090 EILEEN　　　 HENDERSON　　　 E11　　　　 89750.00 E11
000100 THEODORE　　 SPENSER　　　　 E21　　　　 86150.00 E21
000110 VINCENZO　　 LUCCHESSI　　　 A00　　　　 66500.00 A00
000120 SEAN　　　　 O'CONNELL　　　 A00　　　　 49250.00 A00
000130 DELORES　　　QUINTANA　　　　C01　　　　 73800.00 C01
000140 HEATHER　　　NICHOLLS　　　　C01　　　　 68420.00 C01
000150 BRUCE　　　　ADAMSON　　　　 D11　　　　 55280.00 D11
000160 ELIZABETH　　PIANKA　　　　　D11　　　　 62250.00 D11
000170 MASATOSHI　　YOSHIMURA　　　 D11　　　　 44680.00 D11
000180 MARILYN　　　SCOUTTEN　　　　D11　　　　 51340.00 D11
000190 JAMES　　　　WALKER　　　　　D11　　　　 50450.00 D11
000200 DAVID　　　　BROWN　　　　　 D11　　　　 57740.00 D11
000210 WILLIAM　　　JONES　　　　　 D11　　　　 68270.00 D11
000220 JENNIFER　　 LUTZ　　　　　　D11　　　　 49840.00 D11
000230 JAMES　　　　JEFFERSON　　　 D21　　　　 42180.00 D21
000240 SALVATORE　　MARINO　　　　　D21　　　　 48760.00 D21
000250 DANIEL　　　 SMITH　　　　　 D21　　　　 49180.00 D21
000260 SYBIL　　　　JOHNSON　　　　 D21　　　　 47250.00 D21
000270 MARIA　　　　PEREZ　　　　　 D21　　　　 37380.00 D21
000280 ETHEL　　　　SCHNEIDER　　　 E11　　　　 36250.00 E11
000290 JOHN　　　　 PARKER　　　　　E11　　　　 35340.00 E11
000300 PHILIP　　　 SMITH　　　　　 E11　　　　 37750.00 E11
000310 MAUDE　　　　SETRIGHT　　　　E11　　　　 35900.00 E11
000320 RAMLAL　　　 MEHTA　　　　　 E21　　　　 39950.00 E21
000330 WING　　　　 LEE　　　　　　 E21　　　　 45370.00 E21
000340 JASON　　　　GOUNOT　　　　　E21　　　　 43840.00 E21
200010 DIAN　　　　 HEMMINGER　　　 A00　　　　 46500.00 A00
200120 GREG　　　　 ORLANDO　　　　 A00　　　　 39250.00 A00
200140 KIM　　　　　NATZ　　　　　　C01　　　　 68420.00 C01
200170 KIYOSHI　　　YAMAMOTO　　　　D11　　　　 64680.00 D11
200220 REBA　　　　 JOHN　　　　　　D11　　　　 69840.00 D11
200240 ROBERT　　　 MONTEVERDE　　　D21　　　　 37760.00 D21
200280 EILEEN　　　 SCHWARTZ　　　　E11　　　　 46250.00 E11
200310 MICHELLE　　 SPRINGER　　　　E11　　　　 35900.00 E11
200330 HELENA　　　 WONG　　　　　　E21　　　　 35370.00 E21
200340 ROY　　　　　ALONZO　　　　　E21　　　　 31840.00 E21
　42 record(s) selected.

在更新之后，我们来看看各个用户能够做什么。使用 Executive 用户 ID Jane 连接数据库。首先执行与前面一样的选择语句：

db2 => select EMPNO, FIRSTNME, LASTNAME, WORKDEPT, SALARY,
varchar(SECLABEL_TO_CHAR('J_DEPT_POLICY',DEPT_TAG),30) from gmilne.emp
EMPNO　FIRSTNME　　 LASTNAME　　　　WORKDEPT SALARY　　　6
------ ------------ --------------- -------- ----------- ------------------------------
000010 CHRISTINE　　HAAS　　　　　　A00　　　　152750.00 A00
000020 MICHAEL　　　THOMPSON　　　　B01　　　　 94250.00 B01
000030 SALLY　　　　KWAN　　　　　　C01　　　　 98250.00 C01
000050 JOHN　　　　 GEYER　　　　　 E01　　　　 80175.00 E01
000060 IRVING　　　 STERN　　　　　 D11　　　　 72250.00 D11
000070 EVA　　　　　PULASKI　　　　 D21　　　　 96170.00 D21
000090 EILEEN　　　 HENDERSON　　　 E11　　　　 89750.00 E11
000100 THEODORE　　 SPENSER　　　　 E21　　　　 86150.00 E21
000110 VINCENZO　　 LUCCHESSI　　　 A00　　　　 66500.00 A00
000120 SEAN　　　　 O'CONNELL　　　 A00　　　　 49250.00 A00
000130 DELORES　　　QUINTANA　　　　C01　　　　 73800.00 C01
000140 HEATHER　　　NICHOLLS　　　　C01　　　　 68420.00 C01
000150 BRUCE　　　　ADAMSON　　　　 D11　　　　 55280.00 D11
000160 ELIZABETH　　PIANKA　　　　　D11　　　　 62250.00 D11
000170 MASATOSHI　　YOSHIMURA　　　 D11　　　　 44680.00 D11
000180 MARILYN　　　SCOUTTEN　　　　D11　　　　 51340.00 D11
000190 JAMES　　　　WALKER　　　　　D11　　　　 50450.00 D11
000200 DAVID　　　　BROWN　　　　　 D11　　　　 57740.00 D11
000210 WILLIAM　　　JONES　　　　　 D11　　　　 68270.00 D11
000220 JENNIFER　　 LUTZ　　　　　　D11　　　　 49840.00 D11
000230 JAMES　　　　JEFFERSON　　　 D21　　　　 42180.00 D21
000240 SALVATORE　　MARINO　　　　　D21　　　　 48760.00 D21
000250 DANIEL　　　 SMITH　　　　　 D21　　　　 49180.00 D21
000260 SYBIL　　　　JOHNSON　　　　 D21　　　　 47250.00 D21
000270 MARIA　　　　PEREZ　　　　　 D21　　　　 37380.00 D21
000280 ETHEL　　　　SCHNEIDER　　　 E11　　　　 36250.00 E11
000290 JOHN　　　　 PARKER　　　　　E11　　　　 35340.00 E11
000300 PHILIP　　　 SMITH　　　　　 E11　　　　 37750.00 E11
000310 MAUDE　　　　SETRIGHT　　　　E11　　　　 35900.00 E11
000320 RAMLAL　　　 MEHTA　　　　　 E21　　　　 39950.00 E21
000330 WING　　　　 LEE　　　　　　 E21　　　　 45370.00 E21
000340 JASON　　　　GOUNOT　　　　　E21　　　　 43840.00 E21
200010 DIAN　　　　 HEMMINGER　　　 A00　　　　 46500.00 A00
200120 GREG　　　　 ORLANDO　　　　 A00　　　　 39250.00 A00
200140 KIM　　　　　NATZ　　　　　　C01　　　　 68420.00 C01
200170 KIYOSHI　　　YAMAMOTO　　　　D11　　　　 64680.00 D11
200220 REBA　　　　 JOHN　　　　　　D11　　　　 69840.00 D11
200240 ROBERT　　　 MONTEVERDE　　　D21　　　　 37760.00 D21
200280 EILEEN　　　 SCHWARTZ　　　　E11　　　　 46250.00 E11
200310 MICHELLE　　 SPRINGER　　　　E11　　　　 35900.00 E11
200330 HELENA　　　 WONG　　　　　　E21　　　　 35370.00 E21
200340 ROY　　　　　ALONZO　　　　　E21　　　　 31840.00 E21
　42 record(s) selected.

以及更新命令：

db2 => update gmilne.emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','E01'))
where WORKDEPT='E01' DB20000I　The SQL command completed successfully.

可以看到，Jane 对表中的所有数据有完全的访问权。现在，看看 Joe 可以看到的内容。首先进行选择。

db2 => select EMPNO, FIRSTNME, LASTNAME, WORKDEPT, SALARY,
varchar(SECLABEL_TO_CHAR('J_DEPT_POLICY',DEPT_TAG),30) from gmilne.emp
EMPNO　FIRSTNME　　 LASTNAME　　　　WORKDEPT SALARY　　　6
------ ------------ --------------- -------- ----------- ------------------------------
000060 IRVING　　　 STERN　　　　　 D11　　　　 72250.00 D11
000100 THEODORE　　 SPENSER　　　　 E21　　　　 86150.00 E21
000150 BRUCE　　　　ADAMSON　　　　 D11　　　　 55280.00 D11
000160 ELIZABETH　　PIANKA　　　　　D11　　　　 62250.00 D11
000170 MASATOSHI　　YOSHIMURA　　　 D11　　　　 44680.00 D11
000180 MARILYN　　　SCOUTTEN　　　　D11　　　　 51340.00 D11
000190 JAMES　　　　WALKER　　　　　D11　　　　 50450.00 D11
000200 DAVID　　　　BROWN　　　　　 D11　　　　 57740.00 D11
000210 WILLIAM　　　JONES　　　　　 D11　　　　 68270.00 D11
000220 JENNIFER　　 LUTZ　　　　　　D11　　　　 49840.00 D11
000320 RAMLAL　　　 MEHTA　　　　　 E21　　　　 39950.00 E21
000330 WING　　　　 LEE　　　　　　 E21　　　　 45370.00 E21
000340 JASON　　　　GOUNOT　　　　　E21　　　　 43840.00 E21
200170 KIYOSHI　　　YAMAMOTO　　　　D11　　　　 64680.00 D11
200220 REBA　　　　 JOHN　　　　　　D11　　　　 69840.00 D11
200330 HELENA　　　 WONG　　　　　　E21　　　　 35370.00 E21
200340 ROY　　　　　ALONZO　　　　　E21　　　　 31840.00 E21
　17 record(s) selected.

看到了吗？他只能看到 D11 和 E21 部门的信息。如果他试图选择不允许他访问的表数据，那么会发生什么：

db2 => select EMPNO, FIRSTNME, LASTNAME, WORKDEPT, SALARY,
varchar(SECLABEL_TO_CHAR('J_DEPT_POLICY',DEPT_TAG),30)
from gmilne.emp where empno='000130'
EMPNO　FIRSTNME　　 LASTNAME　　　　WORKDEPT SALARY　　　6
------ ------------ --------------- -------- ----------- ------------------------------
　0 record(s) selected.

在前面 Jane 进行选择的结果中我们看到，有一个职员的 empno 是 000130，但是不允许 Joe 看到它。

现在是最后一个测试，对于用户 Frank 的测试。

首先，运行与前两个用户相同的选择：

db2 => select EMPNO, FIRSTNME, LASTNAME, WORKDEPT, SALARY,
varchar(SECLABEL_TO_CHAR('J_DEPT_POLICY',DEPT_TAG),30) from gmilne.emp
EMPNO　FIRSTNME　　 LASTNAME　　　　WORKDEPT SALARY　　　6
------ ------------ --------------- -------- ----------- ------------------------------
000010 CHRISTINE　　HAAS　　　　　　A00　　　　152750.00 A00
000110 VINCENZO　　 LUCCHESSI　　　 A00　　　　 66500.00 A00
000120 SEAN　　　　 O'CONNELL　　　 A00　　　　 49250.00 A00
200010 DIAN　　　　 HEMMINGER　　　 A00　　　　 46500.00 A00
200120 GREG　　　　 ORLANDO　　　　 A00　　　　 39250.00 A00
　5 record(s) selected.

在这里可以看到，Frank 只能看到部门中他领导的用户的相关信息。我们来看看在他尝试进行更新时会发生什么：

db2 => update gmilne.emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','A00'))
where WORKDEPT='A00'DB21034E　The command was processed as an SQL statement
because it was not a valid Command Line Processor command.　During SQL processing it
returned:
SQL20402N Authorization ID "FRANK" does not have the LBAC credentials to
perform the "UPDATE" operation on table "EMPLOYEE".　SQLSTATE=42519

尽管他尝试更新的记录是在自己的部门中，但是访问安全策略只允许他对表进行读访问。我们的业务需求已经得到了满足。

结束语

既然您已经学完了本教程，您应该对以下主题有了基本理解：

DB2 安全计划的元素：您应该了解整个 DB2 环境的结构，包括客户机、服务器、网关和主机。还应该了解了身份验证、授权和特权。

DB2 身份验证类型：您应该知道如何使用 db2 update dbm cfg using authentication type 命令在服务器上设置身份验证类型，以及使用 db2 catalog database 命令在网关和客户机上设置身份验证类型。

DB2 权限：您应该了解 SYSADM、SYSCTRL 和 SYSMAINT 权限（在 DBM CFG 文件中设置）以及 DBADM 和 LOAD 权限（通过 GRANT 命令设置，使用 REVOKE 命令撤消）的基本知识。您应该明确地知道每种权限允许运行什么命令。

DB2 特权：您应该了解不同类型的特权以及它们允许用户做什么。特权的例子包括 CONTROL、INSERT、DELETE、CREATEIN、DROPIN、REFERENCES 和 SELECT。还应该知道如何显式（GRANT/REVOKE 命令）、隐式或（只针对包）间接地获得/撤消特权。另外，应该基本了解基于标签的访问控制，以及如何基于这个新的安全概念定义不同类型的策略。

本系列其他教程推荐

DB2 9 基础（730 考试）认证指南，第 1 部分: DB2 规划 1

DB2 9 基础（730 考试）认证指南，第 1 部分: DB2 规划 2

DB2 9 基础（730 考试）认证指南，第 3 部分: 访问 DB2 数据

DB2 9 基础（730 考试）认证指南，第 4 部分: 处理 DB2 数据

DB2 9 基础（730 考试）认证指南，第 5 部分: 处理 DB2 对象

DB2 9 基础（730 考试）认证指南，第 6 部分: 数据并发性

DB2 9 基础（730 考试）认证指南，第 7 部分: XQuery 简介