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/