- 广告位，联系QQ703528
- 广告位，联系QQ703528
- 广告位，联系QQ703528
- 广告位，联系QQ703528
- 广告位，联系QQ703528
- 广告位，联系QQ703528
- 热点通告：
DB2 身份验证控制数据库安全计划的以下方面：
字串9
在发出 attach 或 connect 命令时，它在底层操作系统安全特性的帮助下完成这个任务。attach 命令用来连接 DB2 实例，connect 命令用来连接 DB2 实例中的数据库。下面的示例展示了 DB2 对发出这些命令的用户进行身份验证的不同方式。这些示例在数据库管理程序配置文件中使用默认的身份验证类型 SERVER。下面的例 3 说明了如何使用 DB2 修改服务器操作系统上的密码。 字串8
用创建 DB2 实例时使用的用户 ID 登录到安装 DB2 的机器上。发出以下命令：
db2 attach to DB2
字串6
在这里，隐式地执行身份验证。使用登录机器的用户 ID，并假设这个 ID 已经经过了操作系统的检验。
字串1
db2 connect to sample user test1 using password 字串1
Database Connection Information 字串5
Database server = DB2/NT 9.1.0
字串1
SQL authorization ID = TEST1
字串3
Local database alias = SAMPLE 字串2
在这里，显式地执行身份验证。用户 test1 和密码 password 由操作系统进行检验。用户 test1 成功地连接到示例数据库。 字串8
db2 connect to sample user test1 using password new chgpass confirm chgpass 字串7
与例 2 中一样，用户 ID test1 和密码 password 由操作系统进行检验。然后，操作系统将 test1 的密码从 password 改为 chgpass。因此，如果再次发出例 2 中的命令，它就会失败。
字串6
DB2 身份验证类型
字串1
DB2 使用身份验证类型 决定在什么地方进行身份验证。例如，在客户机 - 服务器环境中，是客户机还是服务器检验用户的 ID 和密码?在客户机 - 网关 - 主机环境中，是客户机还是主机检验用户的 ID 和密码?
字串1
DB2 9 能够根据用户是试图连接数据库，还是执行实例连接和实例级操作，指定不同的身份验证机制。在默认情况下，实例对于所有实例级和连接级请求使用一种身份验证类型。这由数据库管理程序配置参数 AUTHENTICATION 来指定。V9.1 中引入了数据库管理程序配置参数 SRVCON_AUTH。这个参数专门处理对数据库的连接。例如，如果在 DBM CFG 中进行以下设置： 字串4
DB2 GET DBM CFG 字串7
Server Connection Authentication (SRVCON_AUTH) = KERBEROS 字串1
Database manager authentication (AUTHENTICATION) = SERVER_ENCRYPT
那么在连接实例时会使用 SERVER_ENCRYPT。但是在连接数据库时会使用 KERBEROS 身份验证。如果在服务器上没有正确地初始化 KERBEROS，但是提供了有效的用户 ID/密码，那么允许这个用户连接实例，但是不允许他连接数据库。 字串8
下表总结了可用的 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 身份验证。 |
字串8
*这些设置只对 Windows 2000、AIX、Solaris 和 Linux® 操作系统有效。 字串7
在服务器上设置身份验证 字串7
在数据库服务器上，在数据库管理程序配置(DBM CFG)文件中使用 AUTHENTICATION 参数设置身份验证。请记住，DBM CFG 文件是一个实例级配置文件。因此，AUTHENTICATION 参数影响这个实例中的所有数据库。以下命令演示如何修改这个参数。
字串8
要查看配置文件中的身份验证参数： db2 get dbm cfg
要将身份验证参数修改为 server_encrypt： C:\PROGRA~1\SQLLIB\BIN> db2 update dbm cfg using authentication server_encrypt
C:\PROGRA~1\SQLLIB\BIN> db2stop 字串7
C:\PROGRA~1\SQLLIB\BIN> db2start 字串1
某些身份验证类型(比如 GSSPLUGIN、KERBEROS 和 CLIENT)要求设置其他数据库管理程序配置参数，比如 TRUST_ALLCLNTS、SRV_PLUGIN_MODE 和 SRVCON_PW_PLUGIN。
在网关上设置身份验证 字串7
使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。 字串8
要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令： 字串9
db2 catalog database myhostdb at node nd1 authentication SERVER 字串2
db2 terminate
注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。在客户机上设置身份验证
字串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 字串3
如果没有指定身份验证类型，客户机将默认使用 SERVER_ENCRYPT。
字串8
连接主机数据库的客户机：我们假设网关上的身份验证类型设置为 SERVER。如果没有指定身份验证类型，那么在通过 DB2 Connect 访问数据库时假设采用 SERVER_ENCRYPT 身份验证。身份验证在主机数据库服务器上进行。从客户机发出以下命令会导致客户机向网关发送未加密的用户 ID 和密码： 字串6
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 客户机。 字串1
在 DBM CFG 文件中有两个额外参数，用于在服务器或网关身份验证方法设置为 CLIENT，而不可信的客户机试图连接数据库或 DB2 实例时，决定应该在哪里进行身份验证。这些参数是 TRUST_ALLCLNTS 和 TRUST_CLNTAUTH 参数。 字串6
当服务器或网关身份验证类型为 CLIENT 时，除了 TRUST_ALLCLNTS 和 TRUST_CLNTAUTH 参数之外，还有两个因素会起作用。第一个因素是用户 ID 和密码是否是显式提供的，第二个因素是进行连接的客户机的类型。有三种 DB2 客户机：
不可信的客户机：如上所述
字串9
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统(比如 Windows NT、2000、2003、XP 以及所有形式的 Unix / Linux)上的客户机
字串3
当身份验证设置为 CLIENT 时
下表总结了如果服务器的身份验证类型设置为 CLIENT，那么在每种类型的客户机向服务器发出连接命令时将在哪里进行身份验证。 字串5
| 是否提供了 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 客户机。
字串6
下面的示例说明如何在服务器和客户机上设置身份验证类型和参数：
字串1
在服务器上设置身份验证：
db2 update dbm cfg using authentication client 字串5
db2 update dbm cfg using trust_allclnts yes 字串1
db2 update dbm cfg using trust_clntauth server 字串2
db2stop
字串2
db2start
字串3
在客户机上设置身份验证： 字串9
db2 catalog database sample at node nd1 authentication client 字串2
在上面的示例中，如果从任何客户机发出命令 db2 connect to sample
字串4
那么身份验证在客户机上进行。如果从任何客户机发出命令 db2 connect to sample user test1 using password
字串2
那么身份验证在服务器上进行。 字串4
DB2 的安全插件架构
DB2 V8.2 引入了安全插件的概念。这个概念在 DB2 V9.1 中得到了进一步增强。通过使用标准的 GSS-API 调用，用户可以编写一个安全插件并将对用户 ID 进行身份验证的工作交给一个外部安全程序。这种方式的一个示例是 DB2 本身的 KERBEROS 身份验证。在一台机器上安装 DB2 ESE 或应用程序开发客户机时，安装过程中将有一些示例应用程序代码放入实例目录，如果查看 samples\security\plugins 目录，就会看到如何编写安全插件的示例。本节将概述如何在 DB2 安全架构中使用插件，但是不讨论如何编写或编译插件本身。 字串8
Kerberos 身份验证 字串3
Kerberos 身份验证为 DB2 提供了一种无需通过网络发送用户 ID 和密码的用户身份验证方法。Kerberos 安全协议作为第三方身份验证服务执行身份验证，它使用传统的密码术创建一个共享的密钥。这个密钥成为用户的凭证，在请求本地或网络服务时在所有情况下都使用它检验用户的身份。通过使用 Kerberos 安全协议，可以实现对远程 DB2 数据库服务器的单点登录。 字串7
首先，讨论如何设置 DB2 来使用 Kerberos 身份验证。如上所述，Kerberos 身份验证在 DB2 中是使用插件架构实现的。默认的 kerberos 插件的源代码在 samples/security/plugins 目录中，称为 IBMkrb5.c。在 DB2 中使用 Kerberos 之前，必须在客户机和服务器上启用和支持 Kerberos。为此，必须满足以下条件：
1、客户机和服务器必须属于同一个域(用 Windows 术语来说，是可信域)。
字串9
2、必须设置适当的主体(Kerberos 中的用户 ID)。 字串2
3、必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。 字串5
4、所有机器必须有同步的时钟。 字串4
可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。
字串4
为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令： 字串1
DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
字串7
DB2 TERMINATE 字串5
在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。
字串2
还可以告诉客户机它正在针对哪个服务器主体进行身份验证。这个选项可以避免 Kerberos 身份验证的第一步，即客户机寻找它要连接的实例的服务器主体。在客户机上对数据库进行编目时可以指定 AUTHENTICATION 参数。它的格式是： DB2 CATALOG DB dbname AT NODE node name AUTHENTICATION KERBEROS TARGET PRINCIPAL
字串9
service/host@REALM
这一步是可选的。
DB2 CATALOG DB sample AT NODE testnd AUTHENTICATION KERBEROS TARGET PRINCIPAL
字串9
gmilne/gmilne02.torolab.ibm.com@TOROLAB.IBM.COM 字串4
设置 Kerberos 身份验证的下一步是设置服务器。srvcon_gssplugin_list 参数可以设置为支持的 GSS-API 插件的列表，但是只允许有一个 Kerberos 插件。如果这个列表中没有 Kerberos 插件，那么自动地使用默认的 IBMkrb5 插件。如果希望允许所有身份验证(实例连接和数据库连接)使用 Kerberos，那么执行以下命令： 字串9
DB2 UPDATE DBM CFG USING AUTHENTICATION KERBEROS
or
DB2 UPDATE DBM CFG USING AUTHENTICATION KRB_SERVER_ENCRYPT 字串7
如果只希望 DB2 使用 Kerberos 对数据库连接进行身份验证(对实例连接使用 SERVER)，那么执行以下命令： 字串4
DB2 UPDATE DBM CFG USING SVRCON_AUTH KERBEROS
or
DB2 UPDATE DBM CFG USING SVRCON_AUTH KRB_SERVER_ENCRYPT 字串3
根据实例的位长度(32 或 64 位)，DB2 将在实例启动时自动地装载 IBMkrb5 插件。 字串1
其他身份验证设置
字串4
如果查看 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) =
字串5
Group Plugin (GROUP_PLUGIN) =
GSS Plugin for Local Authorization (LOCAL_GSSPLUGIN) =
字串3
Server Plugin Mode (SRV_PLUGIN_MODE) = UNFENCED
字串3
Server List of GSS Plugins (SRVCON_GSSPLUGIN_LIST) =
Server Userid-Password Plugin (SRVCON_PW_PLUGIN) = 字串5
Cataloging allowed without authority (CATALOG_NOAUTH) = NO 字串6
Bypass federated authentication (FED_NOAUTH) = NO
在上面的列表中，去掉了已经讨论过的参数。
字串5
CLNT_PW_PLUGIN这个参数在客户端的 DBM CFG 中指定。它指定用来进行客户机和本地身份验证的客户机插件的名称。 字串8
GROUP_PLUGIN默认值是空(NULL)。将它设置为用户定义的插件就会调用这个插件进行所有组枚举，而不依赖于操作系统的组查找。这与后面讨论的授权部分相关。
LOCAL_GSSPLUGIN这个参数指定默认的 GSS-API 插件库的名称，当数据库管理程序配置的身份验证参数值设置为 GSSPLUGIN 或 GSS_SERVER_ENCRYPT 时，这个库用来进行实例级的本地授权。 字串6
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 方法。
字串7
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 权限。
您的位置: