让DB2系统目录视图转危为安的方案

　　此文章主要向大家描述的是在实际操作中如何让DB2系统目录视图更加安全，在DB2数据库中系统目录视图中主要是保存着数据库各种对象的一些信息  。如表与列的定义、各种对象的特权信息、某个用户所拥有的特权信息等等都保存在目录视图中  。

　　这个设计跟Oracle等数据库系统类似  。

　　在DB2系统目录视图中保存着数据库各种对象的相关信息  。如表与列的定义、各种对象的特权信息、某个用户所拥有的特权信息等等都保存在目录视图中  。这个设计跟Oracle等数据库系统类似  。不过在这些目录视图的权限设计方面有比较大的差异  。

　　一、系统目录视图在安全上的隐患  。

　　在Oracle数据库中，也有跟系统目录视图类似的设计  。如将相关的数据库对象以及权限等信息等存储在数据字典中  。但是对于Oracle数据库来说，对于这个数据字典相关的视图做了相关的限制  。如在Oracle数据库中，将数据字典分为user、all、dba三类  。一般用户只能够使用user或者all数据字典视图  。

　　也就是说，只能够查询到自己拥有的对象或者自己拥有特定权限的对象信息  。对于他人建立的对象，或者自己没有权查询的对象信息，一般用户是查询不到的  。只有像具有数据库管理员等特权的用户才可以查询到全部数据库对象的信息  。这在很大程度上保障了数据字典视图的安全性  。

　　但是对于DB2数据库的系统目录视图，在这方面做的就不是很到位  。如默认情况下，在部署DB2数据库的时候，数据库会自动创建系统目录视图  。而在创建这个系统目录视图的时候，系统会将这个目录视图的select查询权限赋予给public组  。将这个目录视图赋予给这个组，就以为这数据库系统中的用户都具有查询这个系统目录视图的权限  。

　　即使这个对象不是这个用户所创建的，或者用户没有这个对象的访问权限，用户也可以查询到这个对象的相关信息，如谁创建了这个对象，谁拥有这个对象的哪些权限的信息  。当数据库中数据的保密级别或者商业价值不怎么高的时候，这么设计不怎么会产生安全问题  。

　　但是，用户使用起来不方便  。如数据库设计的比较复杂，有多个管理员同时维护数据库系统  。此时每个数据库管理员之需要查询到自己所创建的或则具有访问权限的相关信息，而不需要全部的对象信息  。显然凭现在系统目录视图的设计，不能够做到这一点  。

　　但是如果数据库中的数据商业价值比较高，有很多人虎视眈眈的在打这些数据的注意，此时数据库系统对于系统目录视图的默认权限设计，可能就不怎么合适了  。因为目录视图中存储的所有对象信息(包括授权信息)对于所有用户都是开放的  。

　　这会为黑客或者其他不按好心的用户窃取相关的资料提供便利  。所以对于安全要求高的企业，在部署DB2数据库的时候，有可能需要更改这些系统目录视图的默认权限，以提高目录视图中信息的安全性  。让只有相关的人员才能够看到目录视图中的数据库对象以及权限等相关信息  。

　　二、如何提高系统目录视图的安全性?

　　既然数据库系统目录视图存在一定的安全隐患，那么该如何提高其安全性呢?笔者对此有两个建议，各位数据库管理员可以根据自己的需要来选择使用  。

　　第一个是比较简单的处理方法，即从public中撤销对系统默认视图的select特权  。然后给需要访问这些信息的用户再授予他们对于这些系统默认视图的select查询权限  。在DB2数据库中这些系统目录视图也是视图的一种，所以无论是授权还是撤销权限都是跟其他任何普通视图的授予与撤销权限的方法是一致的  。

　　唯一的区别就是操作用户权限上的区别  。对于普通的视图，只要视图的所有者或者具有视图权限控制的用户都可以更改视图的相关权限  。而对于DB2系统目录视图来说，操作员必须有sysadm或者DBADM的权限，才能够更改系统目录视图的权限  。即收回某些用户的特权，或者重新赋予某些用户具有对系统目录视图的查询权限  。

　　第二个方法实现起来比较复杂，但是比较实用  。简单的说，就是按照Oracle数据库系统的解决方式，将系统目录视图分为三类  。第一类是user系统目录视图  。即在查询系统目录视图的时，以当前用户为查询条件，在系统目录视图中反映出来的是用户自己建立的对象  。其他用户建立的对象，即使这个用户具有查询或者其他更加高级的权限，在这个视图中也无法显示出来  。

　　这对于用户维护自己创建的对象比较方便  。第二类视图是ALL视图  。这个视图在运行时，也是以当前用户为查询条件  。不过在这个视图中主要反映两类信息  。一是反映用户自己所创建的对象，二是当前用户具有查询等相关权限的对象信息  。也就说，只要用户有权查询的对象都会在这个类别的系统目录视图中列出来  。

　　第三类视图是DBA视图，即显示所有数据库对象以及相关的授权信息  。这类视图只有数据库管理员才有查询权限，其他用户不具有这个视图的查询权限  。分类分好后，可以先取消所有用户对系统目录视图Select权限  。注意在授权的时候，不是将系统目录视图的查询权限赋予给其他的用户  。

　　而是以系统目录视图为基本对象，在此基础上再根据上面的分类来建立对应的视图  。然后在授权的时候，笔者是将这些新建立的视图权限赋予给相关的用户  。也就说，用户并不是直接查询系统目录视图，而是通过查询数据库管理员所建立的视图来查询DB2系统目录视图中的相关内容  。

　　这不仅可以在系统目录视图与用户之间多建立一道安全的屏障，而且还可以实现对目录视图内容更加精细的控制  。为了操作上的方便，笔者建议将建立视图和赋予权限的语句保存下来  。以后若需要重新部署数据库，或者数据库管理员跳槽后需要维护一个新的DB2数据库系统，那么可以直接通过这个语句来重建相关的视图  。

　　如果DB2数据库部署比较简单，只有一个数据库管理员的话，那么只需要采用第一种简便的处理方式既可  。但是如果DB2数据库应用比较复杂，有多个数据库管理员各司其职，共同负责数据库应用的时候，笔者建议采用第二种处理方式  。添加了过滤条件之后，即可以保障系统目录视图数据的安全，还方便了用户的操作  。

　　此时即使某个数据库管理员的帐号与密码被泄露，那么其最终受影响的也只有这个数据库管理员创建或者拥有查询等权限的对象  。而不会将其他用户创建的对象或者这个用户具有查询等权限的对象信息泄露给其他人  。其实这第二种方案只是第一次操作的时候比较复杂  。

　　以后还有机会再次维护数据库系统的话，只需要直接执行第一次保存下来的SQL语句即可  。所以不少有经验的数据库管理员，还都是比较乐于使用第二种解决方案的  。因为对于他们来说，可能第二种解决方案比第一种解决方案更加的简单，使用起来更加的方便  。

　　三、当心统计信息泄露机密  。

　　在系统目录视图中，有些列是统计信息列  。这些列也比较危险  。因为记录在DB2系统目录视图中的某些统计系会含有可能是用户环境中的敏感信息的数据  。如果这些包含用户环境中的敏感信息泄露的话，会给黑客等非法攻击者攻击数据库提供方便  。

　　这些敏感信息有时候就是他们攻击数据库的钥匙  。为此对于这些敏感信息，最好需要采取额外的保密措施  。如即使这些统计信息用户有权查看，因为这个对象就是用户创建的  。但是如果数据库管理员认为这个敏感信息对于用户参与数据库的维护工作没有实际的价值，那么最好也屏蔽这些信息  。

　　即通过在列级别上控制用户查询这个列的权限  。或者说在重定义目录视图的时候，有意思的像用户屏蔽这些敏感的信息  。最后这些敏感的信息只有数据库管理员一个人可以查询  。这可以作为以上两个解决方案的辅助措施，来共同保障DB2系统目录视图的安全  。