數據庫安全涉及的問題
數據庫安全是當今最重要的問題。您的數據庫可能允許顧客通過互聯網購買產品，它也可能包含用來預測業務趨勢的歷史數據；無論是哪種情況，公司都需要可靠的數據庫安全計劃。
數據庫安全計劃應該定義：
允許誰訪問實例和/或數據庫
在哪里以及如何檢驗用戶的密碼
用戶被授予的權限級別
允許用戶運行的命令
允許用戶讀取和/或修改的數據
允許用戶創建、修改和/或刪除的數據庫對象
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
要將身份驗證參數修改為 server_encrypt ：
$ 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 | CLIENT | CLIENT | CLIENT | CLIENT |
| No | Yes | SERVER | CLIENT | CLIENT | CLIENT |
| No | No | CLIENT | SERVER | CLIENT | CLIENT |
| No | No | SERVER | SERVER | CLIENT | CLIENT |
| No | DRDAONLY | CLIENT | SERVER | SERVER | CLIENT |
| No | DRDAONLY | SERVER | SERVER | SERVER | CLIENT |
| Yes | Yes | CLIENT | CLIENT | CLIENT | CLIENT |
| Yes | Yes | SERVER | SERVER | SERVER | SERVER |
| Yes | No | CLIENT | SERVER | CLIENT | CLIENT |
| Yes | No | SERVER | SERVER | SERVER | SERVER |
| Yes | DRDAONLY | CLIENT | SERVER | SERVER | CLIENT |
| Yes | DRDAONLY | SERVER | SERVER | SERVER | SERVER |
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
$db2stop
$db2start
在客戶機上設置身份驗證：
$db2 catalog database sample at node nd1 authentication client
在上面的示例中，如果從任何客戶機發出命令
db2 connect to sample
那么身份驗證在客戶機上進行。如果從任何客戶機發出命令
db2 connect to sample user test1 using password
那么身份驗證在服務器上進行。
DB2的安全插件架構
DB2 V8.2引入了安全插件的概念。這個概念在DB2 V9.1中得到了進一步增強。通過使用標準的 GSS-API 調用，用戶可以編寫一個安全插件并將對用戶 ID 進行身份驗證的工作交給一個外部安全程序。這種方式的一個示例是DB2本身的KERBEROS身份驗證。在一臺機器上安裝 DB2 ESE或應用程序開發客戶機時，安裝過程中將有一些示例應用程序代碼放入實例目錄，如果查看 samples\security\plugins 目錄，就會看到如何編寫安全插件的示例。本節將概述如何在 DB2 安全架構中使用插件，但是不討論如何編寫或編譯插件本身。關于這個主題的詳細描述，請參考 DB2 UDB 安全性: 理解 DB2 Universal Database 安全性插件 。
Kerberos 身份驗證
Kerberos 身份驗證為DB2提供了一種無需通過網絡發送用戶ID和密碼的用戶身份驗證方法。Kerberos安全協議作為第三方身份驗證服務執行身份驗證，它使用傳 統的密碼術創建一個共享的密鑰。這個密鑰成為用戶的憑證，在請求本地或網絡服務時在所有情況下都使用它檢驗用戶的身份。通過使用Kerberos安全協 議，可以實現對遠程DB2數據庫服務器的單點登錄。
首先，討論如何設置DB2來使用Kerberos身份驗證。如上所述，Kerberos身份驗證在DB2 中是使用插件架構實現的。默認的kerberos 插件的源代碼在samples/security/plugins 目錄中，稱為IBMkrb5.c 。在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/gmilne02.torolab.ibm.com@TOROLAB.IBM.COM
設置 Kerberos 身份驗證的下一步是設置服務器。srvcon_gssplugin_list 參數可以設置為支持的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 權限。 |