資料庫安全是當今最重要的問題。您的資料庫可能允許顧客通過網際網路購買産品，它也可能包含用來預測業務趨勢的曆史資料；無論是哪種情況，公司都需要可靠的資料庫安全計劃。
資料庫安全計劃應該定義：
允許誰通路執行個體和/或資料庫
在哪裡以及如何檢驗使用者的密碼
使用者被授予的權限級别
允許使用者運作的指令
允許使用者讀取和/或修改的資料
允許使用者建立、修改和/或删除的資料庫對象
db2安全機制
db2中有三種主要的安全機制，可以幫助 dba 實作資料庫安全計劃：身份驗證（authentication）、授權（authorization） 和特權（privilege）。
身份驗證是使用者在嘗試通路db2執行個體或資料庫時遇到的第一種安全特性。db2身份驗證與底層作業系統的安全特性緊密協作來檢驗使用者id和密碼。db2還可以利用kerberos這樣的安全協定對使用者進行身份驗證。
授權決定使用者和/或使用者組可以執行的操作以及他們可以通路的資料對象。使用者執行進階資料庫和執行個體管理操作的能力由指派給他們的權限決定。在 db2 中有5種不同的權限級别：sysadm、sysctrl、sysmaint、dbadm和load。
特權的粒度比授權要細，可以配置設定給使用者和/或使用者組。特權定義使用者可以建立或删除的對象。它們還定義使用者可以用來通路對象（比如表、視圖、索引和包）的指令。db2 9中新增的一個概念是基于标簽的通路控制（lbac），它允許以更細的粒度控制誰有權通路單獨的行和/或列。
客戶機、伺服器、網關和主機
資料庫環境常常由幾台不同的機器組成；必須在所有潛在的資料通路點上保護資料庫。在處理 db2 身份驗證時客戶機、伺服器、網關和主機的概念尤其重要。
資料庫伺服器是資料庫實際所在的機器（在分區的資料庫系統上可能是多台機器）。db2資料庫客戶機是對伺服器上的資料庫執行查詢的機器。這些客戶機可以是本地的（駐留在與資料庫伺服器相同的實體機器上），也可以是遠端的（駐留在單獨的機器上）。
如果資料庫駐留在運作as/400（iseries）或os/390（zseries）的大型機上，它就稱為主機或主機伺服器。
網關是一台運作db2 connect産品的機器。db2客戶機可以通過網關連接配接駐留在主機上的db2資料庫。
網關也稱為db2 connect伺服器。安裝了 enterprise server edition産品的系統也内置了db2 connect功能。
db2身份驗證
db2 身份驗證控制資料庫安全計劃的以下方面：
誰有權通路執行個體和/或資料庫
在發出attach或connect指令時，它在底層作業系統安全特性的幫助下完成這個任務。attach指令用來連接配接db2執行個體，connect指令用來連接配接db2執行個體中的資料庫。下面的示例展示了db2對發出這些指令的使用者進行身份驗證的不同方式。具體如下
用建立 db2 執行個體時使用的使用者id登入到安裝 db2 的機器上。發出以下指令：
$ db2 attach to db2inst1
instance attachment information
instance server = db2/linux 9.7.5
authorization id = db2inst1
local instance alias = db2inst1
在這裡，隐式地執行身份驗證。使用登入機器的使用者id，并假設這個id已經經過了作業系統的檢驗。
$ db2 connect to sample user db2inst1 using a
database connection information
database server = db2/linux 9.7.5
sql authorization id = db2inst1
local database alias = sample
在這裡，顯式地執行身份驗證。使用者db2inst1和密碼a由作業系統進行檢驗。使用者db2inst1成功地連接配接到示例資料庫。
db2 connect to sample user test1 using password new chgpass confirm chgpass
與上例中一樣，使用者id db2inst1和密碼password由作業系統進行檢驗。然後，作業系統将db2inst1的密碼從a改為chgpass。是以，如果再次發出例 2 中的指令，它就會失敗。
db2身份驗證類型
db2使用身份驗證類型決定在什麼地方進行身份驗證。例如，在客戶機---伺服器環境中，是客戶機還是伺服器檢驗使用者的 id和密碼？在客戶機---網關---主機環境中，是客戶機還是主機檢驗使用者的id和密碼？
db2 9能夠根據使用者是試圖連接配接資料庫，還是執行執行個體連接配接和執行個體級操作，指定不同的身份驗證機制。在預設情況下，執行個體對于所有執行個體級和連接配接級請求使用一種身份驗證類型。這由資料庫管理程式配置參數authentication來指定。v9.1 中引入了資料庫管理程式配置參數 srvcon_auth。這個參數專門處理對資料庫的連接配接。例如，如果在dbm cfg 中進行以下設定：
$ db2 get dbm cfg|grep -i auth
server connection authentication (srvcon_auth) = kerberos
database manager authentication (authentication) = server_encrypt
那麼在連接配接執行個體時會使用server_encrypt。但是在連接配接資料庫時會使用kerberos身份驗證。如果在伺服器上沒有正确地初始化kerberos，但是提供了有效的使用者id/密碼，那麼允許這個使用者連接配接執行個體，但是不允許他連接配接資料庫。
下表總結了可用的 db2 身份驗證類型。在客戶機---網關---主機環境中，這些身份驗證選項在客戶機和網關上設定，而不是在主機上。本節将詳細讨論如何設定這些選項。
類型
描述
server
身份驗證在伺服器上進行。
server_encrypt
身份驗證在伺服器上進行。密碼在客戶機上進行加密，然後再發送到伺服器。
client
*kerberos
由 kerberos 安全軟體執行身份驗證。
*krb_server_encrypt
如果客戶機設定是 kerberos，那麼由 kerberos 安全軟體執行身份驗證。否則使用 server_encrypt。
data_encrypt
身份驗證在伺服器上進行。伺服器接受加密的使用者 id 和密碼，并對資料進行加密。這個選項的操作方式與 server_encrypt 相同，但是資料也要加密。
data_encrypt_cmp
身份驗證方式與 data_encrypt 相同，但是允許不支援 data_encrypt 的老式客戶機使用 server_encrypt 身份驗證進行連接配接。在這種情況下，資料不進行加密。如果進行連接配接的客戶機支援 data_encrypt，就會進行資料加密，而不能降級到 server_encrypt 身份驗證。這個身份驗證類型隻在伺服器的資料庫管理程式配置檔案中是有效的，而且在客戶機或網關執行個體上使用 catalog database 時是無效的。
gssplugin
身份驗證方式由一個外部 gss-api 插件決定。
gss_server_encrypt
身份驗證方式由一個外部 gss-api 插件決定。在客戶機不支援伺服器的 gss-api 插件之一的情況下，使用 server_encrypt 身份驗證。
注意：這些設定隻對 windows 2000、aix、solaris 和 linux® 作業系統有效。
在伺服器上設定身份驗證
在資料庫伺服器上，在資料庫管理程式配置（dbm cfg）檔案中使用 authentication 參數設定身份驗證。請記住，dbm cfg檔案是一個執行個體級配置檔案。是以，authentication參數影響這個執行個體中的所有資料庫。以下指令示範如何修改這個參數。
要檢視配置檔案中的身份驗證參數：
$db2 get dbm cfg
要将身份驗證參數修改為 <code>server_encrypt</code> ：
$ db2 update dbm cfg using authentication server
$db2stop
$db2start
注：雖然更新完系統資料庫參數後，直接執行 db2 get dbm cfg|grep -i auth可以看到系統資料庫參數已經修改完畢。但是為使其生效，還是需要重新開機執行個體。
某些身份驗證類型（比如gssplugin、kerberos 和 client）要求設定其他資料庫管理程式配置參數，比如 trust_allclnts、srv_plugin_mode 和 srvcon_pw_plugin。關于這些設定的更多細節見下文。
在網關上設定身份驗證
使用catalog database指令在網關上設定身份驗證。在這裡的示例中，我們将使用名為myhostdb 的主機資料庫。
要将網關身份驗證類型設定為 server，應該在網關機器上發出以下指令：
db2 catalog database myhostdb at node nd1 authentication server
db2 terminate
注意，身份驗證不會在網關本身執行。在db2 version 8中，身份驗證必須在客戶機或主機資料庫伺服器上執行。
在客戶機上設定身份驗證
我們來考慮兩台單獨的客戶機上的兩種情況。我們将一個客戶機配置為連接配接伺服器機器上的資料庫（db2 udb luw 分布式平台），另一個客戶機連接配接主機上的資料庫（例如 db2 for zseries）。
連接配接伺服器資料庫的客戶機： 在針對要連接配接的資料庫的資料庫目錄項中，客戶機身份驗證設定必須比對資料庫伺服器上的設定（但是 krb_server_encrypt、data_encrypt_cmp 和 gss_server_encrypt 例外）。
我們假設伺服器身份驗證類型設定為 server。在客戶機上發出以下指令對名為 sample 的伺服器資料庫進行編目：
$db2 catalog database sample at node nd1 authentication server
注：如果沒有指定身份驗證類型，客戶機将預設使用 server_encrypt。
連接配接主機資料庫的客戶機： 我們假設網關上的身份驗證類型設定為server。如果沒有指定身份驗證類型，那麼在通過 db2 connect通路資料庫時假設采用server_encrypt身份驗證。身份驗證在主機資料庫伺服器上進行。從客戶機發出以下指令會導緻客戶機向網關發送未加密的使用者 id 和密碼：
db2 catalog database myhostdb at node nd1 authentication server
現在假設網關上的身份驗證類型設定為server_encrypt。身份驗證同樣在主機資料庫伺服器上進行。使用者id和密碼在客戶機上進行加密，然後再發送到網關，并在網關上進行加密，然後再發送到主機。這是預設的做法。
處理不可信的客戶機
如果伺服器或網關将身份驗證類型設定為client，那麼這意味着期望客戶機對使用者的id和密碼進行身份驗證。但是，一些客戶機的作業系統沒有本機安全特性。這種不可信的客戶機包括在windows 98和windows me上運作的db2。db2 v9.1不支援 windows 98 或 windows me，但是它支援低版本的客戶機，是以仍然可能必須處理不可信的v8客戶機。
在 dbm cfg 檔案中有兩個額外參數，用于在伺服器或網關身份驗證方法設定為client，而不可信的客戶機試圖連接配接資料庫或db2執行個體時，決定應該在哪裡進行身份驗證。這些參數是 trust_allclnts和trust_clntauth 參數。
當伺服器或網關身份驗證類型為client 時，除了trust_allclnts和 trust_clntauth 參數之外，還有兩個因素會起作用。第一個因素是使用者 id 和密碼是否是顯式提供的，第二個因素是進行連接配接的客戶機的類型。有三種db2客戶機：
不可信的客戶機 ：如上所述
主機客戶機 ：運作在 zseries 這樣的主機作業系統上的客戶機
可信客戶機 ：運作在具有本機安全特性的非主機作業系統（比如 windows nt、2000、2003、xp 以及所有形式的 unix / linux）上的客戶機
當身份驗證設定為 client 時
下表總結了如果伺服器的身份驗證類型設定為 client，那麼在每種類型的客戶機向伺服器發出連接配接指令時将在哪裡進行身份驗證。
是否提供了 id/密碼？
trust_allclnts
trust_clntauth
不可信的客戶機
可信的客戶機
主機客戶機
no
yes
<code>client</code>
<code>server</code>
<code>drdaonly</code>
drdaonly 意味着隻信任主機客戶機，而不管使用 drda 進行連接配接的 db2 version 8 客戶機。
下面的示例說明如何在伺服器和客戶機上設定身份驗證類型和參數：
在伺服器上設定身份驗證：
$db2 update dbm cfg using authentication client
$db2 update dbm cfg using trust_allclnts yes
$db2 update dbm cfg using trust_clntauth server
在客戶機上設定身份驗證：
$db2 catalog database sample at node nd1 authentication client
在上面的示例中，如果從任何客戶機發出指令
db2 connect to sample
那麼身份驗證在客戶機上進行。如果從任何客戶機發出指令
db2 connect to sample user test1 using password
那麼身份驗證在伺服器上進行。
kerberos 身份驗證
kerberos 身份驗證為db2提供了一種無需通過網絡發送使用者id和密碼的使用者身份驗證方法。kerberos安全協定作為第三方身份驗證服務執行身份驗證，它使用傳統的密碼術建立一個共享的密鑰。這個密鑰成為使用者的憑證，在請求本地或網絡服務時在所有情況下都使用它檢驗使用者的身份。通過使用kerberos安全協定，可以實作對遠端db2資料庫伺服器的單點登入。
首先，讨論如何設定db2來使用kerberos身份驗證。如上所述，kerberos身份驗證在db2 中是使用插件架構實作的。預設的kerberos 插件的源代碼在<code>samples/security/plugins</code> 目錄中，稱為<code>ibmkrb5.c</code> 。在db2 中使用kerberos之前，必須在客戶機和伺服器上啟用和支援 kerberos。為此，必須滿足以下條件：
1、客戶機和伺服器必須屬于同一個域（用 windows 術語來說，是可信域）。
2、必須設定适當的主體（kerberos 中的使用者 id）。
3、必須建立伺服器的keytab檔案，執行個體所有者必須能夠讀這個檔案。
4、所有機器必須有同步的時鐘。
可以在 kerberos 産品附帶的文檔中找到關于設定 kerberos 的更多資訊。
為了在 db2 中啟用 kerberos 身份驗證，必須先告訴客戶機在哪裡尋找将使用的kerberos 插件。在客戶機上，運作以下指令：
db2 update dbm cfg using clnt_krb_plugin ibmkrb5
db2 terminate
在這個示例中，使用預設的 kerberos 插件。如果使用的kerberos實作需要特殊功能的話，dba可以修改這個插件來執行特殊功能。
還可以告訴客戶機它正在針對哪個伺服器主體進行身份驗證。這個選項可以避免kerberos身份驗證的第一步，即客戶機尋找它要連接配接的執行個體的伺服器主體。在客戶機上對資料庫進行編目時可以指定authentication參數。它的格式是：
db2 catalog db dbname at node node name authentication kerberos target principal service/host@realm
這一步是可選的。
db2 catalog db sample at node testnd authentication kerberos target principal gmilne/[email protected]
設定 kerberos 身份驗證的下一步是設定伺服器。<code>srvcon_gssplugin_list</code> 參數可以設定為支援的gss-api插件的清單，但是隻允許有一個kerberos 插件。如果這個清單中沒有kerberos 插件，那麼自動地使用預設的ibmkrb5插件。如果希望允許所有身份驗證（執行個體連接配接和資料庫連接配接）使用kerberos，那麼執行以下指令：
db2 update dbm cfg using authentication kerberos
或者
db2 update dbm cfg using authentication krb_server_encrypt
如果隻希望 db2 使用 kerberos 對資料庫連接配接進行身份驗證（對執行個體連接配接使用 server），那麼執行以下指令：
db2 update dbm cfg using svrcon_auth kerberos
db2 update dbm cfg using svrcon_auth krb_server_encrypt
根據執行個體的位長度（32 或 64 位），db2将在執行個體啟動時自動地裝載 ibmkrb5 插件。
其他身份驗證設定
如果檢視 v9.1 執行個體中的dbm cfg，會看到影響db2對使用者id進行身份驗證的方式的各種設定。正如前面提到的，有針對标準作業系統使用者id身份驗證的設定（client、server、server_encrypt、data_encrypt、data_encrypt_cmp），還有将身份驗證工作交給外部程式的插件（kerberos、krb_server_encrypt、gssplugin、 gss_server_encrypt）。本節專門介紹其他一些配置變量如何影響對使用者的身份驗證。
client userid-password plugin (clnt_pw_plugin) =
group plugin (group_plugin) =
gss plugin for local authorization (local_gssplugin) =
server plugin mode (srv_plugin_mode) = unfenced
server list of gss plugins (srvcon_gssplugin_list) =
server userid-password plugin (srvcon_pw_plugin) =
cataloging allowed without authority (catalog_noauth) = no
bypass federated authentication (fed_noauth) = no
在上面的清單中，去掉了已經讨論過的參數。
clnt_pw_plugin
這個參數在用戶端的 dbm cfg 中指定。它指定用來進行客戶機和本地身份驗證的客戶機插件的名稱。
group_plugin
預設值是空（null）。将它設定為使用者定義的插件就會調用這個插件進行所有組枚舉，而不依賴于作業系統的組查找。這與後面讨論的授權部分相關。
local_gssplugin
這個參數指定預設的 gss-api 插件庫的名稱，當資料庫管理程式配置的身份驗證參數值設定為gssplugin 或 gss_server_encrypt 時，這個庫用來進行執行個體級的本地授權。
srv_plugin_mode
（yes/no） 這個參數的預設設定是 no。當改為 yes 時，以 fenced 模式啟動 gss-api 插件，其工作方式類似于 fenced 存儲過程。fenced 插件的崩潰不會導緻 db2 執行個體崩潰。在插件還處于開發階段時，建議以 fenced 模式運作它們，這樣的話插件中的邏輯問題和記憶體洩漏就不會導緻執行個體崩潰。在确定插件是可靠的之後，應該以 unfenced 模式運作以提高性能。
srvcon_gssplugin_list
一 個插件清單，當使用 kerberos、krb_server_encrypt、gssplugin 或 gss_server_encrypt 時，伺服器上的資料庫管理程式在身份驗證期間将使用這些插件。清單中的每個插件應該用逗号（‘,’）分隔，它們之間沒有空格。插件按照優先次序列出，首先 使用清單中的第一個插件對發送的使用者 id/密碼進行身份驗證。隻有當列出的所有插件都傳回了錯誤時，db2 才會向使用者傳回身份驗證錯誤。
srvcon_pw_plugin
在指定 client、server 或 server_encrypt 身份驗證時，這個參數允許使用者修改 db2 用來檢驗使用者 id 和密碼的預設身份驗證方法。在預設情況下，它的值是 null，是以使用預設的 db2 方法。
catalog_noauth
（yes/no） 預設值是 no。将這個參數修改為 yes 就允許不屬于 sysadm、sysctrl 或 sysmaint 組成員的使用者修改機器上的 database、node、admin 和 dcs 編目。如果登入的使用者使用不可信客戶機（定義見上文），或者登入所用的使用者 id 不允許連接配接資料庫或執行個體，但是使用者又必須在客戶機上進行編目，隻有在這種情況下這個參數才是有用的。
fed_noauth
如 果 fed_noauth 設定為 yes，身份驗證設定為 server 或 server_encrypt，聯邦設定為 yes，那麼在執行個體上避免進行身份驗證。它假設身份驗證在資料源上進行。當 fed_noauth 設定為 yes 時系統會發出警告。在客戶機和 db2 伺服器上都不進行身份驗證。知道sysadm身份驗證名稱的任何使用者都擁有聯邦伺服器的 sysadm 權限。
參考至：http://www.ibm.com/developerworks/cn/education/data/db2-cert7302/section3.html
本文原創，轉載請注明出處、作者
如有錯誤，歡迎指正
作者：czmmiao 文章出處：http://czmmiao.iteye.com/blog/1379077
![Mac｜Windows系統本地照片自動上傳到伺服器[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)