db9 安全性.docx
- 文档编号:18125023
- 上传时间:2023-08-13
- 格式:DOCX
- 页数:39
- 大小:43.57KB
db9 安全性.docx
《db9 安全性.docx》由会员分享,可在线阅读,更多相关《db9 安全性.docx(39页珍藏版)》请在冰点文库上搜索。
db9安全性
DB2安全
数据库安全涉及的问题
数据库安全是当今最重要的问题。
您的数据库可能允许顾客通过互联网购买产品,它也可能包含用来预测业务趋势的历史数据;无论是哪种情况,公司都需要可靠的数据库安全计划。
数据库安全计划应该定义:
允许谁访问实例和/或数据库
在哪里以及如何检验用户的密码
用户被授予的权限级别
允许用户运行的命令
允许用户读取和/或修改的数据
允许用户创建、修改和/或删除的数据库对象
DB2安全机制
DB2中有三种主要的安全机制,可以帮助DBA实现数据库安全计划:
身份验证(authentication)、授权(authorization)和特权(privilege)。
身份验证是用户在尝试访问DB2实例或数据库时遇到的第一种安全特性。
DB2身份验证与底层操作系统的安全特性紧密协作来检验用户ID和密码。
DB2还可以利用Kerberos这样的安全协议对用户进行身份验证。
授权决定用户和/或用户组可以执行的操作以及他们可以访问的数据对象。
用户执行高级数据库和实例管理操作的能力由指派给他们的权限决定。
在DB2中有5种不同的权限级别:
SYSADM、SYSCTRL、SYSMAINT、DBADM和LOAD。
特权的粒度比授权要细,可以分配给用户和/或用户组。
特权定义用户可以创建或删除的对象。
它们还定义用户可以用来访问对象(比如表、视图、索引和包)的命令。
DB29中新增的一个概念是基于标签的访问控制(LBAC),它允许以更细的粒度控制谁有权访问单独的行和/或列。
要为本教程的下一节做好准备,需要在DB2实例中创建一个数据库。
确保%DB2INSTANCE%变量仍然设置为DB2,然后使用命令db2sampldrive创建示例数据库,这里的drive是希望创建示例数据库的驱动器的名称。
对于本教程中的示例,将在D:
驱动器上创建示例数据库:
D:
SQLLIBBIN>db2sampld:
客户机、服务器、网关和主机
在考虑整个数据库环境的安全性时,理解术语客户机、服务器、网关和主机是相当重要的。
数据库环境常常由几台不同的机器组成;必须在所有潜在的数据访问点上保护数据库。
在处理DB2身份验证时客户机、服务器、网关和主机的概念尤其重要。
下图说明了基本的客户机-服务器-主机配置。
数据库服务器是数据库实际所在的机器(在分区的数据库系统上可能是多台机器)。
DB2数据库客户机是对服务器上的数据库执行查询的机器。
这些客户机可以是本地的(驻留在与数据库服务器相同的物理机器上),也可以是远程的(驻留在单独的机器上)。
如果数据库驻留在运行AS/400(iSeries)或OS/390(zSeries)的大型机上,它就称为主机或主机服务器。
网关是一台运行DB2Connect产品的机器。
DB2客户机可以通过网关连接驻留在主机上的DB2数据库。
网关也称为DB2Connect服务器。
安装了EnterpriseServerEdition产品的系统也内置了DB2Connect功能。
DB2身份验证
什么时候进行DB2身份验证
DB2身份验证控制数据库安全计划的以下方面:
谁有权访问实例和/或数据库
在哪里以及如何检验用户的密码
在发出attach或connect命令时,它在底层操作系统安全特性的帮助下完成这个任务。
attach命令用来连接DB2实例,connect命令用来连接DB2实例中的数据库。
下面的示例展示了DB2对发出这些命令的用户进行身份验证的不同方式。
这些示例在数据库管理程序配置文件中使用默认的身份验证类型SERVER。
下面的例3说明了如何使用DB2修改服务器操作系统上的密码。
用创建DB2实例时使用的用户ID登录到安装DB2的机器上。
发出以下命令:
db2attachtoDB2
在这里,隐式地执行身份验证。
使用登录机器的用户ID,并假设这个ID已经经过了操作系统的检验。
db2connecttosampleusertest1usingpassword
DatabaseConnectionInformation
Databaseserver =DB2/NT9.1.0
SQLauthorizationID =TEST1
Localdatabasealias =SAMPLE
在这里,显式地执行身份验证。
用户test1和密码password由操作系统进行检验。
用户test1成功地连接到示例数据库。
db2connecttosampleusertest1usingpasswordnewchgpassconfirmchgpass
与例2中一样,用户IDtest1和密码password由操作系统进行检验。
然后,操作系统将test1的密码从password改为chgpass。
因此,如果再次发出例2中的命令,它就会失败。
DB2身份验证类型
DB2使用身份验证类型决定在什么地方进行身份验证。
例如,在客户机-服务器环境中,是客户机还是服务器检验用户的ID和密码?
在客户机-网关-主机环境中,是客户机还是主机检验用户的ID和密码?
DB29能够根据用户是试图连接数据库,还是执行实例连接和实例级操作,指定不同的身份验证机制。
在默认情况下,实例对于所有实例级和连接级请求使用一种身份验证类型。
这由数据库管理程序配置参数AUTHENTICATION来指定。
V9.1中引入了数据库管理程序配置参数SRVCON_AUTH。
这个参数专门处理对数据库的连接。
例如,如果在DBMCFG中进行以下设置:
DB2GETDBMCFG
ServerConnectionAuthentication (SRVCON_AUTH)=KERBEROS
Databasemanagerauthentication (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身份验证。
这个身份验证类型只在服务器的数据库管理程序配置文件中是有效的,而且在客户机或网关实例上使用CATALOGDATABASE时是无效的。
GSSPLUGIN
身份验证方式由一个外部GSS-API插件决定。
GSS_SERVER_ENCRYPT
身份验证方式由一个外部GSS-API插件决定。
在客户机不支持服务器的GSS-API插件之一的情况下,使用SERVER_ENCRYPT身份验证。
*这些设置只对Windows2000、AIX、Solaris和Linux®操作系统有效。
在服务器上设置身份验证
在数据库服务器上,在数据库管理程序配置(DBMCFG)文件中使用AUTHENTICATION参数设置身份验证。
请记住,DBMCFG文件是一个实例级配置文件。
因此,AUTHENTICATION参数影响这个实例中的所有数据库。
以下命令演示如何修改这个参数。
要查看配置文件中的身份验证参数:
db2getdbmcfg
要将身份验证参数修改为server_encrypt:
C:
PROGRA~1SQLLIBBIN>db2updatedbmcfgusingauthenticationserver_encrypt
C:
PROGRA~1SQLLIBBIN>db2stop
C:
PROGRA~1SQLLIBBIN>db2start
某些身份验证类型(比如GSSPLUGIN、KERBEROS和CLIENT)要求设置其他数据库管理程序配置参数,比如TRUST_ALLCLNTS、SRV_PLUGIN_MODE和SRVCON_PW_PLUGIN。
关于这些设置的更多细节见下文。
在网关上设置身份验证
使用catalogdatabase命令在网关上设置身份验证。
在这里的示例中,我们将使用名为myhostdb的主机数据库。
要将网关身份验证类型设置为SERVER,应该在网关机器上发出以下命令:
db2catalogdatabasemyhostdbatnodend1authenticationSERVER
db2terminate
注意,身份验证不会在网关本身执行。
在DB2Version8中,身份验证必须在客户机或主机数据库服务器上执行。
在客户机上设置身份验证
我们来考虑两台单独的客户机上的两种情况。
我们将一个客户机配置为连接服务器机器上的数据库(DB2UDBLUW分布式平台),另一个客户机连接主机上的数据库(例如DB2forzSeries)。
连接服务器数据库的客户机:
在针对要连接的数据库的数据库目录项中,客户机身份验证设置必须匹配数据库服务器上的设置(但是KRB_SERVER_ENCRYPT、DATA_ENCRYPT_CMP和GSS_SERVER_ENCRYPT例外)。
我们假设服务器身份验证类型设置为SERVER。
在客户机上发出以下命令对名为sample的服务器数据库进行编目:
db2catalogdatabasesampleatnodend1authenticationSERVER
如果没有指定身份验证类型,客户机将默认使用SERVER_ENCRYPT。
连接主机数据库的客户机:
我们假设网关上的身份验证类型设置为SERVER。
如果没有指定身份验证类型,那么在通过DB2Connect访问数据库时假设采用SERVER_ENCRYPT身份验证。
身份验证在主机数据库服务器上进行。
从客户机发出以下命令会导致客户机向网关发送未加密的用户ID和密码:
db2catalogdatabasemyhostdbatnodend1authenticationSERVER
现在假设网关上的身份验证类型设置为SERVER_ENCRYPT。
身份验证同样在主机数据库服务器上进行。
用户ID和密码在客户机上进行加密,然后再发送到网关,并在网关上进行加密,然后再发送到主机。
这是默认的做法。
处理不可信的客户机
如果服务器或网关将身份验证类型设置为CLIENT,那么这意味着期望客户机对用户的ID和密码进行身份验证。
但是,一些客户机的操作系统没有本机安全特性。
这种不可信的客户机包括在Windows98和WindowsME上运行的DB2。
DB2V9.1不支持Windows98或WindowsME,但是它支持低版本的客户机,所以仍然可能必须处理不可信的V8客户机。
在DBMCFG文件中有两个额外参数,用于在服务器或网关身份验证方法设置为CLIENT,而不可信的客户机试图连接数据库或DB2实例时,决定应该在哪里进行身份验证。
这些参数是TRUST_ALLCLNTS和TRUST_CLNTAUTH参数。
当服务器或网关身份验证类型为CLIENT时,除了TRUST_ALLCLNTS和TRUST_CLNTAUTH参数之外,还有两个因素会起作用。
第一个因素是用户ID和密码是否是显式提供的,第二个因素是进行连接的客户机的类型。
有三种DB2客户机:
不可信的客户机:
如上所述
主机客户机:
运行在zSeries这样的主机操作系统上的客户机
可信客户机:
运行在具有本机安全特性的非主机操作系统(比如WindowsNT、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进行连接的DB2Version8客户机。
下面的示例说明如何在服务器和客户机上设置身份验证类型和参数:
在服务器上设置身份验证:
db2updatedbmcfgusingauthenticationclient
db2updatedbmcfgusingtrust_allclntsyes
db2updatedbmcfgusingtrust_clntauthserver
db2stop
db2start
在客户机上设置身份验证:
db2catalogdatabasesampleatnodend1authenticationclient
在上面的示例中,如果从任何客户机发出命令db2connecttosample
那么身份验证在客户机上进行。
如果从任何客户机发出命令db2connecttosampleusertest1usingpassword
那么身份验证在服务器上进行。
DB2的安全插件架构
DB2V8.2引入了安全插件的概念。
这个概念在DB2V9.1中得到了进一步增强。
通过使用标准的GSS-API调用,用户可以编写一个安全插件并将对用户ID进行身份验证的工作交给一个外部安全程序。
这种方式的一个示例是DB2本身的KERBEROS身份验证。
在一台机器上安装DB2ESE或应用程序开发客户机时,安装过程中将有一些示例应用程序代码放入实例目录,如果查看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插件。
在客户机上,运行以下命令:
DB2UPDATEDBMCFGUSINGCLNT_KRB_PLUGINIBMkrb5
DB2TERMINATE
在这个示例中,使用默认的KERBEROS插件。
如果使用的Kerberos实现需要特殊功能的话,DBA可以修改这个插件来执行特殊功能。
还可以告诉客户机它正在针对哪个服务器主体进行身份验证。
这个选项可以避免Kerberos身份验证的第一步,即客户机寻找它要连接的实例的服务器主体。
在客户机上对数据库进行编目时可以指定AUTHENTICATION参数。
它的格式是:
DB2CATALOGDBdbnameATNODEnodenameAUTHENTICATIONKERBEROSTARGETPRINCIPAL
service/host@REALM
这一步是可选的。
DB2CATALOGDBsampleATNODEtestndAUTHENTICATIONKERBEROSTARGETPRINCIPAL
gmilne/@TOROLAB.IBM.COM
设置Kerberos身份验证的下一步是设置服务器。
srvcon_gssplugin_list参数可以设置为支持的GSS-API插件的列表,但是只允许有一个Kerberos插件。
如果这个列表中没有Kerberos插件,那么自动地使用默认的IBMkrb5插件。
如果希望允许所有身份验证(实例连接和数据库连接)使用Kerberos,那么执行以下命令:
DB2UPDATEDBMCFGUSINGAUTHENTICATIONKERBEROS
or
DB2UPDATEDBMCFGUSINGAUTHENTICATIONKRB_SERVER_ENCRYPT
如果只希望DB2使用Kerberos对数据库连接进行身份验证(对实例连接使用SERVER),那么执行以下命令:
DB2UPDATEDBMCFGUSINGSVRCON_AUTHKERBEROS
or
DB2UPDATEDBMCFGUSINGSVRCON_AUTHKRB_SERVER_ENCRYPT
根据实例的位长度(32或64位),DB2将在实例启动时自动地装载IBMkrb5插件。
其他身份验证设置
如果查看V9.1实例中的DBMCFG,会看到影响DB2对用户ID进行身份验证的方式的各种设置。
正如前面提到的,有针对标准操作系统用户ID身份验证的设置(CLIENT、SERVER、SERVER_ENCRYPT、DATA_ENCRYPT、DATA_ENCRYPT_CMP),还有将身份验证工作交给外部程序的插件(KERBEROS、KRB_SERVER_ENCRYPT、GSSPLUGIN、GSS_SERVER_ENCRYPT)。
本节专门介绍其他一些配置变量如何影响对用户的身份验证。
ClientUserid-PasswordPlugin (CLNT_PW_PLUGIN)=
GroupPlugin (GROUP_PLUGIN)=
GSSPluginforLocalAuthorization (LOCAL_GSSPLUGIN)=
ServerPluginMode (SRV_PLUGIN_MODE)=UNFENCED
ServerListofGSSPlugins (SRVCON_GSSPLUGIN_LIST)=
ServerUserid-PasswordPlugin (SRVCON_PW_PLUGIN)=
Catalogingallowedwithoutauthority (CATALOG_NOAUTH)=NO
Bypassfederatedauthentication (FED_NOAUTH)=NO
在上面的列表中,去掉了已经讨论过的参数。
CLNT_PW_PLUGIN
这个参数在客户端的DBMCFG中指定。
它指定用来进行客户机和本地身份验证的客户机插件的名称。
GROUP_PLUGIN
默认值是空(NULL)。
将它设置为用户定义的插件就会调用这个插件进行所有组枚举,而不依赖于操作系统的组查找。
这与后面讨论的授权部分相关。
LOCAL_GSSPLUGIN
这个参数指定默认的GSS-API插件库的名称,当数据库管理
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- db9 安全性
![提示](https://static.bingdoc.com/images/bang_tan.gif)