ITPub博客

首页 > Linux操作系统 > Linux操作系统 > DB2数据库的安全机制

DB2数据库的安全机制

原创 Linux操作系统 作者:王飞鹏2011 时间:2013-04-26 11:35:12 1 删除 编辑
关于DB2数据库的安全机制,和电信行业的很多朋友交流过,本文重点介绍。

DB2的安全控制主要目的是保护数据资源,防止不相关的人访问数据库以及因为勿操作对数据库的破坏。在DB2中,安全控制主要使用认证(Authentication)和授权(Authorization)两种机制来实现。

DB2中的认证

认证主要是判断连接数据库的用户是否是合法用户,简单说就是辨认出是谁, 这个过程需要提供用户名和密码。在DB2中并没有存储专门的用户认证信息,认证工作由操作系统或外部机制完成。比如我们发出下面的连接数据库命令:

db2 connect to mydb user db2admin using pwd

这时需要保证db2admin是操作系统中存在的用户,并且密码是pwd,否则无法通过验证。DB2支持不同的认证方法,可参看下表

DB2支持的认证方式

认证类型

含义

SERVER

在数据库服务器机器上进行用户认证。

SERVER_ENCRYPT

在数据库服务器机器上进行用户认证,密码在送到服务器端时需要加密。

CLIENT

在客户端机器上进行用户认证。如果使用了CLIENT,另外两个参数也控制认证在客户端进行还是在服务器端进行。

TRUST_ALLCLNTS决定是否所有客户端机器都是可信的。对于可信的客户端才会在客户端机器进行认证,不可信的需要在服务器端认证,也就是需要提供用户名和密码。

TRUST_CLNTAUTH决定可信客户端如果连接时提供了用户名和密码,认证在客户端进行还是服务器端进行。当然如果没有提供用户名密码,对于可信客户端一定会在客户端进行认证的。

KERBEROS

用户认证由 Kerberos 软件完成。

KRB_SERVER_ENCRYPT

如果客户端设置为KERBEROS 用户认证由KERBEROS 软件完成. 否则使用 SERVER_ENCRYPT

GSS

用户认证由 GSS plug-in完成。

GSS_SERVER_ENCRYPT

用户认证由 GSS plug-in完成,如果客户端不支持GSS,将使用SERVER认证的方法。

DATA_ENCRYPT

除了密码,与数据库交互的数据也进行加密。

 

修改认证模式后需要重启实例才能生效,例如,下面的语句更改认证模式为SERVER_ENCRYPT

db2 update dbm cfg using authentication SERVER_ENCRYPT
db2stop
db2start


DB2中的授权

授权指的是给已经通过认证的用户一定的权利,让他能够访问数据库里的特定对象,不同用户的权利大小是不一样的。在DB2中,授权分为两个层次,一个是管理权限,另一个是特权(privilege)。管理权限是比较高层次的权限,它把包括一组特权和数据库实例以及实用程序的管理权限。而特权则是低层次的针对某一个对象的访问权限。

       在管理权限中包括两大类,一类是实例级的管理权限,另一类是数据库级的管理权限。这两类权限的特点如下表所示:

DB2的管理权限

管理权限类型

涉及权限

特点

授予方法

实例级管理权限

SYSADM

SYSCTRL

SYSMAINT

SYSMON

决定是否有权利进行特定的数据库管理工作,比如执行备份恢复等操作。在这些权限中SYSADM具有最大权限,它不仅能进行实例管理工作,甚至包含了DBADM的权限,可以访问和操作数据库里的数据。

DBM CFG中有四个参数,需要把这四个参数设置成操作系统的组,在组里的用户自动获得相应的管理权限

数据库管理权限

DBADM

SECADM

LOAD

决定是否能对数据库数据进行管理,创建数据库对象,导入等操作。SECADM负责数据库安全相关的操作,比如管理可信上下文和基于标签的访问控制(LBAC

使用GRANT把相应权限授予用户或者组

 

比如在数据库服务器中存在用户db2test,它所在组为group1。如果我们想把SYSCTRL

授予db2test, 我们应该使用下面语句:

db2 update dbm cfg using SYSCTRL_GROUP group1
db2stop
db2start

 

DBADMLOAD是通过GRANTREVOKE语句授予和撤销的,如果我们想把DBADM权限授予db2test,我们可以执行下面的命令:

GRANT DBADM ON DATABASE TO USER db2test

 

如果我们想撤销db2test用户的DBADM权限,我们需要执行下面命令:

REVOKE DBADM ON DATABASE FROM USER db2test

 

除了管理权限,还有一些针对具体数据库对象的特权,这些特权也是通过GRANTREVOKE语句授予和撤销的,授予对象可以是一个用户,一个用户组,或者全部用户(PUBLIC)比如,通过下面命令把EMPLOYEE表的SELECT权限授予HERON

GRANT SELECT ON EMPLOYEE TO USER HERON

 

如果需要撤销SELECT特权可以执行:

REVOKE SELECT ON EMPLOYEE FROM GROUP HERON

 

其实对于数据库任何对象的访问都会有相应权限进行保护。我们可通过下表看到创建或控制某个对象所需要的权限。

创建或控制DB2对象所需要的权限

数据库对象

重建对象所需权限

控制对象所需权限

与对象相关的权限

数据库(Database

SYSADM

SYSCTRL

DBADM

CONNECT

BINDADD

CREATETAB

NOFENCE

IMPLICIT_SCHEMA

包(Package

BINDADD

CONTROL

BIND

EXECUTE

表(Table (表)

视图(View)(视图)

CREATEAB (表)

CONTROL (视图)

SELECT(视图)

CONTROL

SELECT (表/视图)

INSERT (表/视图)

DELETE (表/视图)

UPDATE (表/视图)

ALTER (表)

INDEX (表)

REFERENCES(表)

索引(Index

INDEX

CONTROL

别名(Alias

如果Schema不同于当前用户,用户需要SYSADMDBADM权限

 

CONTROL

模式(Schema

SYSADM

DBADM

IMPLICIT_SCHEMA

Schema的拥有者

CREATEIN

ALTERIN

DROPIN

 

有关权限的信息存储在系统编目表(SYSCAT)中,我们可以通过下面的SQL语句看到所有与权限相关的系统编目表。

isis:db2lde 2> db2 "select substrtabname,1,20 from syscat.tables where tabschema='SYSCAT' and tabname like '%AUTH'"

1

--------------------

COLAUTH

DBAUTH

INDEXAUTH

LIBRARYAUTH

PACKAGEAUTH

PASSTHRUAUTH

ROUTINEAUTH

SCHEMAAUTH

SEQUENCEAUTH

TABAUTH

TBSPACEAUTH

XSROBJECTAUTH

 

  12 records selected.

 

 可信上下文

在三层环境中,在客户端-中间件-数据库这样的三层架构的应用环境中,用户的认证和授权机制变得有一些复杂。通常,中间件会取代客户端连接数据库服务器。

一种实现方法是,我们在中间件服务器上使用同一个连接用户去连接数据库,这会带来若干问题:

 很难获得用户身份信息。这样会影响数据库的可审计性,因为数据库服务器无法得知是哪个应用用户在连接数据库。

 连接用户拥有过多权限。由于缺乏用户身份信息,为了满足所有用户的请求,连接用会拥有过多的权限,一旦连接用户被攻破,访问数据库信息将畅通无阻。

 对用户的任何更改都会影响所有应用用户。由于使用一个连接用户,一旦某个应用对连接用户进行改变,都会影响到所有应用。

另一种实现方法是,我们把客户端的用户信息传递给中间件,中间件使用这些信息代理客户端去连接数据库,针对不同用户请求建立不同连接。这也会带来一些问题:

中间件服务器本身缺乏用户认证的能力。

 性能受到影响。由于中间件服务器要代理客户端去连接数据库,为不同的用户创建不同连接会有一定的性能开销。

 降低可维护性。在用户经过中间件服务器认证后,还需要经过数据库服务器的认证,这样一个用户的密码保存在不同地方,增加了运维的复杂性,并且也无法实现单点登陆。

为了解决数据库认证在三层环境中遇到的问题,从DB2 V9.5开始引入了可信上下文的特性。可信上下文提供了一种手段,用于简便、有效地把最终用户在三层环境中的身份传播给数据库服务器。我们一旦建立了可信上下文,就可以实现在同一个连接里切换用户。比如,我们可以建立下面一个可信上下文,需要注意的是可信上下文的建立需要SECADM权限。请看如下例子。

CREATE TRUSTED CONTEXT CTX1

    BASED UPON CONNECTION USING SYSTEM AUTHID USER1

    ATTRIBUTES (ADDRESS   '192.0.2.1')  

    DEFAULT ROLE manager  

  WITH USE FOR USER2 WITH AUTHENTICATION,  

               USER3 WITHOUT AUTHENTICATION

               ENABLE 

我们在例子中建立一个可信上下文CTX1,这时如果我用USER1IP192.0.2.1的机器上连接数据库,会自动使用这个连接上下文,USER1自动获得manager权限。如果我们用不同的用户或者在不同的IP上连接数据库则提示没能建立可信连接(这时只建立了一个普通连接)。在建立可信连接以后可以不用重新认证的切换到USER3,如果要切换到USER2,则需要提供密码,这样我们就可以把三层架构中的终端用户直接和DB2中的用户对应起来,从而方便审计和数据库授权工作。关于建立可信连接和切换用户,在不同的APIJDBC/ODBC/CLI/.NET等)中都有相应支持,可以查询相关API的文档,这里不就再赘述了。

Normal 0 7.8 磅 0 2 false false false EN-US ZH-CN X-NONE

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25714482/viewspace-759316/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
暂无介绍

注册时间:2011-04-27

最新文章