DB2系統目錄視圖存在著一些安全隱患，這會為黑客或者其他不按好心的用戶竊取相關的資料提供了便利，如何才能加強DB2系統目錄的安全性，成為了我們需要迫切解決的問題。

此文章主要向大家描述的是在實際操作中如何讓DB2系統目錄視圖更加安全，在DB2數據庫中系統目錄視圖中主要是保存著數據庫各種對象的一些信息。如表與列的定義、各種對象的特權信息、某個用戶所擁有的特權信息等等都保存在目錄視圖中。

這個設計跟Oracle等數據庫系統類似。

在DB2系統目錄視圖中保存著數據庫各種對象的相關信息。如表與列的定義、各種對象的特權信息、某個用戶所擁有的特權信息等等都保存在目錄視圖中。這個設計跟Oracle等數據庫系統類似。不過在這些目錄視圖的權限設計方面有比較大的差異。

一、系統目錄視圖在安全上的隱患。

在Oracle數據庫中，也有跟系統目錄視圖類似的設計。如將相關的數據庫對象以及權限等信息等存儲在數據字典中。但是對于Oracle數據庫來說，對于這個數據字典相關的視圖做了相關的限制。如在Oracle數據庫中，將數據字典分為user、all、dba三類。一般用戶只能夠使用user或者all數據字典視圖。

也就是說，只能夠查詢到自己擁有的對象或者自己擁有特定權限的對象信息。對于他人建立的對象，或者自己沒有權查詢的對象信息，一般用戶是查詢不到的。只有像具有數據庫管理員等特權的用戶才可以查詢到全部數據庫對象的信息。這在很大程度上保障了數據字典視圖的安全性。

但是對于DB2數據庫的系統目錄視圖，在這方面做的就不是很到位。如默認情況下，在部署DB2數據庫的時候，數據庫會自動創建系統目錄視圖。而在創建這個系統目錄視圖的時候，系統會將這個目錄視圖的select查詢權限賦予給public組。將這個目錄視圖賦予給這個組，就以為這數據庫系統中的用戶都具有查詢這個系統目錄視圖的權限。

即使這個對象不是這個用戶所創建的，或者用戶沒有這個對象的訪問權限，用戶也可以查詢到這個對象的相關信息，如誰創建了這個對象，誰擁有這個對象的哪些權限的信息。當數據庫中數據的保密級別或者商業價值不怎么高的時候，這么設計不怎么會產生安全問題。#p#

但是，用戶使用起來不方便。如數據庫設計的比較復雜，有多個管理員同時維護數據庫系統。此時每個數據庫管理員之需要查詢到自己所創建的或則具有訪問權限的相關信息，而不需要全部的對象信息。顯然憑現在系統目錄視圖的設計，不能夠做到這一點。

但是如果數據庫中的數據商業價值比較高，有很多人虎視眈眈的在打這些數據的注意，此時數據庫系統對于系統目錄視圖的默認權限設計，可能就不怎么合適了。因為目錄視圖中存儲的所有對象信息(包括授權信息)對于所有用戶都是開放的。

這會為黑客或者其他不按好心的用戶竊取相關的資料提供便利。所以對于安全要求高的企業，在部署DB2數據庫的時候，有可能需要更改這些系統目錄視圖的默認權限，以提高目錄視圖中信息的安全性。讓只有相關的人員才能夠看到目錄視圖中的數據庫對象以及權限等相關信息。

二、如何提高系統目錄視圖的安全性?

既然數據庫系統目錄視圖存在一定的安全隱患，那么該如何提高其安全性呢?筆者對此有兩個建議，各位數據庫管理員可以根據自己的需要來選擇使用。

第一個是比較簡單的處理方法，即從public中撤銷對系統默認視圖的select特權。然后給需要訪問這些信息的用戶再授予他們對于這些系統默認視圖的select查詢權限。在DB2數據庫中這些系統目錄視圖也是視圖的一種，所以無論是授權還是撤銷權限都是跟其他任何普通視圖的授予與撤銷權限的方法是一致的。

唯一的區別就是操作用戶權限上的區別。對于普通的視圖，只要視圖的所有者或者具有視圖權限控制的用戶都可以更改視圖的相關權限。而對于DB2系統目錄視圖來說，操作員必須有sysadm或者DBADM的權限，才能夠更改系統目錄視圖的權限。即收回某些用戶的特權，或者重新賦予某些用戶具有對系統目錄視圖的查詢權限。

第二個方法實現起來比較復雜，但是比較實用。簡單的說，就是按照Oracle數據庫系統的解決方式，將系統目錄視圖分為三類。第一類是user系統目錄視圖。即在查詢系統目錄視圖的時，以當前用戶為查詢條件，在系統目錄視圖中反映出來的是用戶自己建立的對象。其他用戶建立的對象，即使這個用戶具有查詢或者其他更加高級的權限，在這個視圖中也無法顯示出來。

這對于用戶維護自己創建的對象比較方便。第二類視圖是ALL視圖。這個視圖在運行時，也是以當前用戶為查詢條件。不過在這個視圖中主要反映兩類信息。一是反映用戶自己所創建的對象，二是當前用戶具有查詢等相關權限的對象信息。也就說，只要用戶有權查詢的對象都會在這個類別的系統目錄視圖中列出來。#p#

第三類視圖是DBA視圖，即顯示所有數據庫對象以及相關的授權信#p#息。這類視圖只有數據庫管理員才有查詢權限，其他用戶不具有這個視圖的查詢權限。分類分好后，可以先取消所有用戶對系統目錄視圖Select權限。注意在授權的時候，不是將系統目錄視圖的查詢權限賦予給其他的用戶。

而是以系統目錄視圖為基本對象，在此基礎上再根據上面的分類來建立對應的視圖。然后在授權的時候，筆者是將這些新建立的視圖權限賦予給相關的用戶。也就說，用戶并不是直接查詢系統目錄視圖，而是通過查詢數據庫管理員所建立的視圖來查詢DB2系統目錄視圖中的相關內容。

這不僅可以在系統目錄視圖與用戶之間多建立一道安全的屏障，而且還可以實現對目錄視圖內容更加精細的控制。為了操作上的方便，筆者建議將建立視圖和賦予權限的語句保存下來。以后若需要重新部署數據庫，或者數據庫管理員跳槽后需要維護一個新的DB2數據庫系統，那么可以直接通過這個語句來重建相關的視圖。

如果DB2數據庫部署比較簡單，只有一個數據庫管理員的話，那么只需要采用第一種簡便的處理方式既可。但是如果DB2數據庫應用比較復雜，有多個數據庫管理員各司其職，共同負責數據庫應用的時候，筆者建議采用第二種處理方式。添加了過濾條件之后，即可以保障系統目錄視圖數據的安全，還方便了用戶的操作。

此時即使某個數據庫管理員的帳號與密碼被泄露，那么其最終受影響的也只有這個數據庫管理員創建或者擁有查詢等權限的對象。而不會將其他用戶創建的對象或者這個用戶具有查詢等權限的對象信息泄露給其他人。其實這第二種方案只是第一次操作的時候比較復雜。

以后還有機會再次維護數據庫系統的話，只需要直接執行第一次保存下來的SQL語句即可。所以不少有經驗的數據庫管理員，還都是比較樂于使用第二種解決方案的。因為對于他們來說，可能第二種解決方案比第一種解決方案更加的簡單，使用起來更加的方便。

三、當心統計信息泄露機密。

在系統目錄視圖中，有些列是統計信息列。這些列也比較危險。因為記錄在DB2系統目錄視圖中的某些統計系會含有可能是用戶環境中的敏感信息的數據。如果這些包含用戶環境中的敏感信息泄露的話，會給黑客等非法攻擊者攻擊數據庫提供方便。

這些敏感信息有時候就是他們攻擊數據庫的鑰匙。為此對于這些敏感信息，最好需要采取額外的保密措施。如即使這些統計信息用戶有權查看，因為這個對象就是用戶創建的。但是如果數據庫管理員認為這個敏感信息對于用戶參與數據庫的維護工作沒有實際的價值，那么最好也屏蔽這些信息。

即通過在列級別上控制用戶查詢這個列的權限。或者說在重定義目錄視圖的時候，有意思的像用戶屏蔽這些敏感的信息。最后這些敏感的信息只有數據庫管理員一個人可以查詢。這可以作為以上兩個解決方案的輔助措施，來共同保障DB2系統目錄視圖的安全。