DB2安全管理的相关概念(原创)

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

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

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

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

用户被授予的权限级别

允许用户运行的命令

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

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

db2安全机制 

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

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

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

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

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

数据库环境常常由几台不同的机器组成；必须在所有潜在的数据访问点上保护数据库。在处理 db2 身份验证时客户机、服务器、网关和主机的概念尤其重要。

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

如果数据库驻留在运行as/400（iseries）或os/390（zseries）的大型机上，它就称为主机或主机服务器。

网关是一台运行db2 connect产品的机器。db2客户机可以通过网关连接驻留在主机上的db2数据库。

网关也称为db2 connect服务器。安装了 enterprise server edition产品的系统也内置了db2 connect功能。 

db2身份验证

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

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

在发出attach或connect命令时，它在底层操作系统安全特性的帮助下完成这个任务。attach命令用来连接db2实例，connect命令用来连接db2实例中的数据库。下面的示例展示了db2对发出这些命令的用户进行身份验证的不同方式。具体如下

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

$ db2 attach to db2inst1

   instance attachment information

 instance server        = db2/linux 9.7.5

 authorization id       = db2inst1

 local instance alias   = db2inst1 

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

$ db2 connect to sample user db2inst1 using a

   database connection information

 database server        = db2/linux 9.7.5

 sql authorization id   = db2inst1

 local database alias   = sample 

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

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

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

db2身份验证类型 

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

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

$ db2 get dbm cfg|grep -i auth

 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 

要将身份验证参数修改为 <code>server_encrypt</code> ：

$ db2 update dbm cfg using authentication server 

$db2stop

$db2start 

注：虽然更新完注册表参数后，直接执行 db2 get dbm cfg|grep -i auth可以看到注册表参数已经修改完毕。但是为使其生效，还是需要重启实例。

某些身份验证类型（比如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

<code>client</code>

<code>server</code>

<code>drdaonly</code>

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 

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

$db2 catalog database sample at node nd1 authentication client 

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

db2 connect to sample 

那么身份验证在客户机上进行。如果从任何客户机发出命令

db2 connect to sample user test1 using password 

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

kerberos 身份验证

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

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

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

2、必须设置适当的主体（kerberos 中的用户 id）。 

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

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

可以在 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/[email protected] 

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

db2 update dbm cfg using authentication kerberos 

或者

db2 update dbm cfg using authentication krb_server_encrypt 

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

db2 update dbm cfg using svrcon_auth kerberos 

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 权限。

参考至：http://www.ibm.com/developerworks/cn/education/data/db2-cert7302/section3.html

本文原创，转载请注明出处、作者

如有错误，欢迎指正

邮箱:[email protected]

作者：czmmiao  文章出处：http://czmmiao.iteye.com/blog/1379077