DB2数据库的安全机制

关于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

 

DBADM和LOAD是通过GRANT和REVOKE语句授予和撤销的，如果我们想把DBADM权限授予db2test，我们可以执行下面的命令：

GRANT DBADM ON DATABASE TO USER db2test

 

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

REVOKE DBADM ON DATABASE FROM USER db2test

 

除了管理权限，还有一些针对具体数据库对象的特权，这些特权也是通过GRANT和REVOKE语句授予和撤销的，授予对象可以是一个用户，一个用户组，或者全部用户（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不同于当前用户，用户需要SYSADM或DBADM权限	CONTROL	无
模式（Schema）	SYSADM DBADM IMPLICIT_SCHEMA	Schema的拥有者	CREATEIN ALTERIN DROPIN

 

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

isis:db2lde 2> db2 "select substr（tabname,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 record（s） 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，这时如果我用USER1在IP为192.0.2.1的机器上连接数据库，会自动使用这个连接上下文，USER1自动获得manager权限。如果我们用不同的用户或者在不同的IP上连接数据库则提示没能建立可信连接（这时只建立了一个普通连接）。在建立可信连接以后可以不用重新认证的切换到USER3，如果要切换到USER2，则需要提供密码，这样我们就可以把三层架构中的终端用户直接和DB2中的用户对应起来，从而方便审计和数据库授权工作。关于建立可信连接和切换用户，在不同的API（JDBC/ODBC/CLI/.NET等）中都有相应支持，可以查询相关API的文档，这里不就再赘述了。

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

转载于:http://blog.itpub.net/25714482/viewspace-759316/