Chinaunix首页 | 论坛 | 博客
  • 博客访问: 112744
  • 博文数量: 39
  • 博客积分: 2530
  • 博客等级: 少校
  • 技术积分: 355
  • 用 户 组: 普通用户
  • 注册时间: 2008-07-01 17:34
文章分类
文章存档

2011年(1)

2010年(28)

2009年(2)

2008年(8)

我的朋友

分类:

2010-03-02 16:50:34

DB2 9 基础 第 2 部分:DB2 安全性
 
一、DB2 安全
 
        1、数据库安全涉及的问题
       
        数据库安全是当今最重要的问题。您的数据库可能允许顾客通过互联网购买产品,它也可能包含用
       
        来预测业务趋势的历史数据;无论是哪种情况,公司都需要可靠的数据库安全计划。
       
        数据库安全计划应该定义:
       
        ● 允许谁访问实例和/或数据库
       
        ● 在哪里以及如何检验用户的密码
       
        ● 用户被授予的权限级别
       
        ● 允许用户运行的命令
       
        ● 允许用户读取和/或修改的数据
       
        ● 允许用户创建、修改和/或删除的数据库对象
       
        2、DB2 中有三种主要的安全机制,可以帮助 DBA 实现数据库安全计划:身份验证(authentication)、授权(authorization) 和特权(privilege)。
       
        身份验证(authentication)是 用户在尝试访问 DB2 实例或数据库时遇到的第一种安全特性。DB2 身份验证与底层操作系统的安全特性紧密协作来检验用户 ID 和密码。DB2 还可以利用 Kerberos 这样的安全协议对用户进行身份验证。
       
        授权(authorization)决定用户和/或用户组可以执 行的操作以及他们可以访问的数据对象。用户执行高级数据库和实例管理操作的能力由指派给他们的权限决定。在 DB2 中有 5 种不同的权限级别:SYSADM、SYSCTRL、SYSMAINT、DBADM 和 LOAD。
       
        特权(privilege)的粒度比授权要细,可以分配给用户和/ 或用户组。特权定义用户可以创建或删除的对象。它们还定义用户可以用来访问对象(比如表、视图、索引和包)的命令。DB2 9 中新增的一个概念是基于标签的访问控制(LBAC),它允许以更细的粒度控制谁有权访问单独的行和/或列。
       
        3、客户机、服务器、网关和主机
 
        在考虑整个数据库环境的安全性时,理解术语客户机、服务器、网关 和主机 是相当重要的。数据库环境常常由几台不同的机器组成;必须在所有潜在的数据访问点上保护数据库。在处理 DB2 身份验证时客户机、服务器、网关和主机的概念尤其重要。
       
        数据库服务器 是数据库实际所在的机器(在分区的数据库系统上可能是多台机器)。DB2 数据库客户机 是对服务器上的数据库执行查询的机器。这些客户机可以是本地的(驻留在与数据库服务器相同的物理机器上),也可以是远程的(驻留在单独的机器上)。
       
        如果数据库驻留在运行 AS/400(iSeries)或 OS/390(zSeries)的大型机上,它就称为主机 或主机服务器。网关 是一台运行 DB2 Connect 产品的机器。DB2 客户机可以通过网关连接驻留在主机上的 DB2 数据库。网关也称为 DB2 Connect 服务器。安装了 Enterprise Server Edition 产品的系统也内置了 DB2 Connect 功能。
 
二、DB2 身份验证
       
        1、什么时候进行 DB2 身份验证
 
        DB2 身份验证控制数据库安全计划的以下方面:
 
        ● 谁有权访问实例和/或数据库
       
        ● 在哪里以及如何检验用户的密码
       
        在发出 attach 或 connect 命令时,它在底层操作系统安全特性的帮助下完成这个任务。attach 命令用来连接 DB2 实例,connect 命令用来连接 DB2 实例中的数据库。
       
        [示例]-[更改用户口令]:
       
        db2 connect to DB_Name user UserName using OldPassword new NewPassword confirm NewPassword
       
        2、DB2 身份验证类型
       
        DB2 使用身份验证类型 决定在什么地方进行身份验证。例如,在客户机 - 服务器环境中,是客户机还是服务器检验用户的 ID 和密码?在客户机 - 网关 - 主机环境中,是客户机还是主机检验用户的 ID 和密码?
       
        DB2 9 能够根据用户是试图连接数据库,还是执行实例连接和实例级操作,指定不同的身份验证机制。在默认情况下,实例对于所有实例级和连接级请求使用一种身份验证 类型。这由数据库管理程序配置参数 AUTHENTICATION 来指定。V9.1
       
        3、在 服务器上设置身份验证
 
        在数据库服务器上,在数据库管理程序配置(DBM CFG)文件中使用 AUTHENTICATION 参数设置身份验证。请记住,DBM CFG 文件是一个实例级配置文件。因此,AUTHENTICATION 参数影响这个实例中的所有数据库。
       
        [示例]:
       
        db2 update dbm cfg using authentication server_encrypt
        db2stop
        db2start
       
        4、在网关上设置身份验证
 
        使用 catalog database 命令在网关上设置身份验证。注意,身份验证不会在网关本身执行。
       
        [示例]:
       
        db2 catalog database myhostdb at node nd1 authentication SERVER
        db2 terminate

       
        5、在客户机上设置身份验证
       
        使用 catalog database 命令在客户机上设置身份验证。
       
        注意,如果网关上的身份验证类型设置为 SERVER,那么从客户机发出的命令会导致客户机向网关发送未加密的用户 ID 和密码。
       
        如果网关上的身份验证类型设置为 SERVER_ENCRYP,那么用户 ID 和密码在客户机上进行加密,然后再发送到网关,并在网关上进行加密,然后再发送到主机。这是默认的做法。
       
        [示例]:
       
        db2 catalog database myhostdb at node nd1 authentication SERVER
       
        6、处理不可信的客户机
       
        如果服务器或网关将身份验证类型设置为 CLIENT,那么这意味着期望客户机对用户的 ID 和密码进行身份验证。
       
        DB2 V9.1 不支持 Windows 98 或 Windows ME,但是它支持低版本的客户机,所以仍然可能必须处理不可信的 V8 客户机。在 DBM CFG 文件中有两个额外参数,用于在服务器或网关身份验证方法设置为 CLIENT,而不可信的客户机试图连接数据库或 DB2 实例时,决定应该在哪里进行身份验证。这些参数是 TRUST_ALLCLNTS 和 TRUST_CLNTAUTH 参数。
       
        [示例]:
       
        [服务器端执行]:
       
        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 那么身份验证在服务器上进行。
       
        7、DB2 的安全插件架构
       
        DB2 V8.2 引入了安全插件的概念。这个概念在 DB2 V9.1 中得到了进一步增强。通过使用标准的 GSS-API 调用,用户可以编写一个安全插件并将对用户 ID 进行身份验证的工作交给一个外部安全程序。这种方式的一个示例是 DB2 本身的 KERBEROS 身份验证。
       
        8、Kerberos 身份验证
       
        Kerberos 身份验证为 DB2 提供了一种无需通过网络发送用户 ID 和密码的用户身份验证方法。Kerberos 安全协议作为第三方身份验证服务执行身份验证,它使用传统的密码术创建一个共享的密钥。这个密钥成为用户的凭证,在请求本地或网络服务时在所有情况下都使 用它检验用户的身份。通过使用 Kerberos 安全协议,可以实现对远程 DB2 数据库服务器的单点登录。
       
        在 DB2 中使用 Kerberos 之前,必须在客户机和服务器上启用和支持 Kerberos。为此,必须满足以下条件:
        (1). 客户机和服务器必须属于同一个域(用 Windows 术语来说,是可信域)。
 
        (2). 必须设置适当的主体(Kerberos 中的用户 ID)。
 
        (3). 必须创建服务器的 keytab 文件,实例所有者必须能够读这个文件。

        (4). 所有机器必须有同步的时钟。
 
        9、其他身份验证设置
 
        如果查看 V9.1 实例中的 DBM CFG,会看到影响 DB2 对用户 ID 进行身份验证的方式的各种设置。正如前面提到的,有针对标准操作系统用户 ID 身份验证的设置(CLIENT、SERVER、SERVER_ENCRYPT、DATA_ENCRYPT、DATA_ENCRYPT_CMP),还有将身 份验证工作交给外部程序的插件(KERBEROS、KRB_SERVER_ENCRYPT、GSSPLUGIN、 GSS_SERVER_ENCRYPT)。这里就不做详细讨论了。
阅读(719) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~