圖 1. DB2 UDB 安全模型 身份驗證 身份驗證就是使用安全機制驗證所提供用戶 ID 和口令的過程。用戶和組身份驗證由 DB2 UDB 外部的設施治理，比如操作系統、域控制器或者 Kerberos 安全系統。這和其他數據庫治理系統（DBMS）是不同的，如 Oracle 和 SQL Server，后者既可以在數據庫本身中定義和驗證用戶帳戶，也可在外部設施（如操作系統）中完成。 一旦用戶 ID 和口令作為實例附件或數據庫連接請求的一部分明確地提供給 DB2 UDB，DB2 UDB 就會嘗試使用該外部安全設施驗證用戶 ID 和口令。假如請求中沒有提供用戶 ID 和口令，則 DB2 UDB 隱含使用登錄到發出請求的工作站時所用的用戶 ID 和口令。 實際的驗證位置由 DB2 UDB 實例參數 AUTHENTICATION 的值決定。有不同的身份驗證方案，包括讓用戶在 DB2 UDB 服務器上驗證（使用服務器的安全設施）、在客戶機上驗證（答應 “單點登錄” 訪問）、使用 Kerberos 安全設施驗證，或者用戶定義的通用安全服務（Generic Security Service，GSS）插件驗證。其他身份驗證選項包括當用戶名和口令以及數據在客戶機和服務器之間的網絡上傳遞時進行加密。為 AUTHENTICATION 參數選擇的值依靠于具體環境和本地安全策略。關于各種身份驗證方案的完整描述，請參閱 DB2 UDB 文檔。 比如，圖 1 中的連接語句供用戶 bob 使用口令 bobpsw 連接到 finance 數據庫。身份驗證過程包括七個步驟： CONNECT 語句傳遞給 DB2 UDB 服務器。 12345678910下一頁 假如沒有明確配置安全插件，則使用默認的安全插件。假如包含 finance 數據庫的實例的 AUTHENTICATION 參數設為 SERVER（默認設置），連接請求中的用戶 ID 和口令則由 DB2 UDB 服務器上的安全設施驗證。默認插件將用戶 ID 和口令發送給操作系統進行驗證。操作系統確認bob/bobpsw 組合是否有效，把該信息返回給安全插件。安全插件激活 DB2 UDB 安全機制，對用戶 bob 查詢 DB2 UDB 目錄表，看看該用戶是否被授予了該數據庫的 CONNECT 權限。默認情況下，CONNECT 特權被授予 PUBLIC，就是說任何通過身份驗證的用戶都能連接到數據庫。DB2 UDB 安全機制驗證用戶 bob 或者返回錯誤。 安全插件把成功或者失敗的消息返回給用戶。假如用戶沒有通過身份驗證，DB2 UDB 就會拒絕連接請求，并向客戶機應用程序返回錯誤消息，如下所示： 清單 1. 用戶身份驗證失敗時 DB2 UDB 返回應用程序的消息:SQL30082N Attempt to establish connection failed with security
reason "24" ("USERNAME AND/OR PASSWord
INVALID"). SQLSTATE=08001 DB2 UDB 服務器上的 DB2 UDB 診斷日志（db2diag.log）中也會出現類似于下面這樣的記錄： 清單 2. 用戶身份驗證失敗時 DB2 診斷日志中的消息:2005-07-09-16.18.33.546000-240 I729347H256
LEVEL: Severe
PID : 3888
TID : 604
FUNCTION: DB2 Common, Security,
Users and Groups, secLogMessage, PRobe:20
DATA #1 : String, 44 bytes
check password failed with rc = -2146500502 在 Windows 上，診斷日志可以在數據庫實例主目錄中找到，默認為 C:Program FilesIBMSQLLIBDB2。在 UNIX 上默認位置是 /DB2/db2dump，其中 是實例所有者的路徑。 上一頁1234567下一頁 假如碰到這樣的消息，一定要確認連接到數據庫的用戶或應用程序是否提供了合法的用戶 ID 和口令。該用戶 ID 和口令必須存在于執行用戶身份驗證的設施中（由目標 DB2 UDB 實例的 AUTHENTICATION 參數決定）。 授權 授權是決定指定用戶 ID 對特定數據庫對象和動作的訪問和特權信息的過程。DB2 UDB 在內部存儲和維護用戶/組的授權信息。每當提交一個命令時，DB2 UDB 執行授權檢查以保證您有執行該動作的正確特權。 特權可以授予特定的用戶或者用戶組。用戶和組的定義本身同樣在 DB2 UDB 外部定義。作為組成員的用戶自動繼續該組的特權。授予用戶的特定權限優先于和該用戶參與的任何組關聯的特權，并且一直有效，即使后來從組中刪除了用戶。就是說，明確授予用戶的特權必須明確收回。 多數數據庫對象都由一組相關的權限，可使用 SQL 語句 GRANT 和 REVOKE 分配給用戶和組。比如，下面的 SQL 語句將 ADM.ACCTABC 表的 SELECT 權限授予用戶 bob：GRANT SELECT ON TABLE ADM.ACCTABC TO USER BOB。 一旦發出該語句，用戶 bob 就可以提交引用該表的 SELECT 語句。類似的，下面的 SQL 語句從 clerks 組收回 ADM.LEGERS 視圖的 INSERT 權限：REVOKE INSERT ON VIEW ADM.LEGERS FROM GROUP CLERKS。 只能收回以前授予的權限。關于能夠授予用戶和組的各種數據庫對象特權的具體信息，請參閱 DB2 UDB 文當。 必須指出，非凡是對 DB2 UDB 新用戶，GRANT 語句不會檢驗用戶和組帳戶是否存在于外部設施中。這意味著，可以把權限和數據庫中存儲的信息授予不存在的用戶和組帳戶。這就造成了一種錯誤的印象，即可以在 DB2 UDB 中定義用戶和組。比方說，連接到 finance 數據庫時可以發出下面的語句： 上一頁12345678下一頁 GRANT SELECT ON TABLE ADM.TAXCODE TO USER XYZ。 其中的 xyz 是一個任意的字符串，沒有映射為外部安全設施中的已有用戶，然后 DB2 UDB 就會在其 GUI 工具或者某些目錄表中顯示 xyz，如圖 2 所示。但這并不意味著存在或創建了名為 xyz 的用戶。
圖 2. 向未定義用戶授權后的表特權 圖 1 下方顯示了一個授權場景的例子。這個用戶叫 bob，已經成功連接到數據庫，現在嘗試對表 ADM.TAXCODES 執行 SELECT 語句。DB2 UDB 查看其目錄表，看看該用戶是否被授予了這個表的 SELECT 權限。因為此權限已經授予 bob，DB2 UDB 答應執行 SELECT 語句。 假如用戶未經授權而對某個對象執行一種操作，DB2 UDB 就會拒絕操作并向客戶機應用程序返回錯誤信息。比方說，假如用戶 bob 嘗試向 ADM.TAXCODES 表中插入一行，但是沒有足夠的權限，就會返回下面的錯誤消息： 清單 3. 用戶授權失敗時 DB2 UDB 返回的消息:DB21034E The command was processed
as an SQL statement because it
was not a valid Command Line
Processor command. During SQL
processing it returned:
SQL0551N "BOB" does not
have the privilege to perform
Operation "INSERT" on object "ADM.TAXCODES".
SQLSTATE=42501 假如碰到類似的消息，一定要確認連接到數據庫所提供的用戶 ID 是否具有執行目標操作的適當權限。必須明確授予該用戶此特權，或者該用戶屬于擁有該特權的組，或者該用戶是超級用戶。 超級用戶 上一頁123456789下一頁 可以為某些用戶組分配特定的實例和數據庫權限。DB2 UDB 定義了超級用戶授權的層次結構（SYSADM、SYSCTRL、SYSMAINT、SYSMON），每一種都具有執行治理操作子集的能力，比如創建數據庫、迫使用戶離開系統和對數據庫進行備份。關于授權級別的具體討論請參閱 DB2 UDB 文當（參見 參考資料）。 可以使用相關的實例級參數配置實例的授權（SYSADM_GRP、SYSCTRL_GRP、SYSMAIN_GRP、SYSMON_GRP）。每個參數可以設置為具有該授權的用戶組名（在 DB2 UDB 外部定義）。 比如，假如定義組 snrdba 包含所有高級 DBA 用戶帳戶，就可使用下面的命令將 SYSADM_GRP 實例參數值設為 snrdba，從而使所有這些用戶成為 SYSADM 超級用戶: 清單 4. 更新 SYSADM_GRP 實例參數UPDATE DBM CFG USING SYSADM_GRP snrdba
db2stop
db2start snrdba 組中的所有用戶都將擁有和 SYSADM 授權級別關聯的全部特權，從而能夠執行授權級別所需要的全部治理任務。 以這種方式定義授權就可以區分 DB2 UDB 治理員和系統/網絡治理員。比如，DBA 可能要求擁有 DB2 UDB 實例的全部治理授權，但不需要本地機器或網絡的治理授權。在這種情況下，可以將該 DBA 的用戶帳戶添加到對系統/網絡沒有完全訪問權限、但是對 DB2 UDB 實例有完全訪問權限的組，只要在 SYSADM_GRP 實例參數中指定該組名即可。 在 Windows 上的 DB2 UDB 默認安裝中，這些實例級超級用戶授權參數（SYSADM_GRP、SYSCTRL_GRP、SYSMAIN_GRP、SYSMON_GRP)）的值默認設為 NULL。這意味著超級用戶權限被授予屬于本地 Administrators 組的所有合法帳戶。我們強烈建議明確將這些參數值改為合法的組名，以便防止未授權的訪問。在 linux 和 UNIX 安裝中，這不是一個大問題，因為 NULL 值默認為實例所有者的基本組，而基本組在安裝后只包含實例所有者的用戶 ID。 上一頁12345678910下一頁 還可以為用戶分配一組數據庫級的授權。數據庫授權使用標準的 SQL GRANT 和 REVOKE 語句。關于這些數據庫授權級別的更多信息，請參閱 DB2 UDB 文檔（參見 參考資料）。 DB2 UDB 系統命令，如 db2、db2ilist、db2start、db2stop、db2iupdt 等，都是操作系統可執行文件。因此，運行這些命令的安全機制以文件的操作系統權限為基礎。這些文件的權限在 DB2 UDB 安裝時設置。 DB2 UDB 用戶和組帳戶命名規則 在 DB2 UDB 中，用戶和組帳戶必須遵守表 1 和 2 中所述的命名規則。這些限制是在定義帳戶的外部設施中起作用的限制之外增加的。
表 1. 平臺約束和限制 限制 Windows Linux/UNIX (1) Windows NT®、Windows 2000®、Windows xp® 和 Windows Server® 2003 現在實際上限制為 20 個字符。 (2) 假如不使用 Client 身份驗證，對于連接到 Windows NT、Windows 2000、Windows XP 和 Windows Server 2003 的非 Windows 32 位客戶機，在明確指定用戶名和口令時支持使用超過 8 個字符的用戶名。
表 2 顯示了對所有平臺的命名限制。 (3) DB2 UDB 內部使用名為 PUBLIC 的偽組，可以為其授權或者收回特權。PUBLIC 不是外部安全設施中定義的真正的組。它是把特權授予通過身份驗證的任何用戶的一種方式。 (4) 還有其他一些非凡字符也能使用，這取決于操作系統和在哪里使用 DB2 UDB。但是為了避免不一致性和潛在的問題，在數據庫中命名對象時不要使用其他非凡字符。 上一頁234567891011下一頁 用默認用戶 ID（如 db2admin）安裝 DB2 UDB 并使用弱口令（或者根本沒有）可能將系統置于風險中。很多計算機病毒、蠕蟲和特洛伊木馬的設計都利用了弱口令。比方說，很多這類程序都嘗試使用常見口令如 “password”、“123456”、“111111”、“db2admin” 等獲得對系統的訪問。因此不要使用簡單的口令很重要。 在驗證用戶時口令也很重要。比如，在 Linux 和 UNIX 操作系統上，未定義口令被作為 NULL 處理。沒有定義口令的任何用戶都被視作使用 NULL 口令。從操作系統的角度來看，這是一種匹配，用戶經過驗證后就能連接到數據庫。 DB2 UDB 安裝需要和創建的用戶/組帳戶 DB2 UDB 需要一個具有治理權的用戶帳戶來執行安裝。該用戶所需要的具體權限依靠于安裝 DB2 UDB 的平臺。默認情況下，DB2 UDB 在安裝過程中要創建多個用戶和組帳戶。這些帳戶用于 “擁有” 和啟動在服務器上運行的各種 DB2 UDB 服務和進程。 這一節介紹在 Windows、Linux 和 UNIX 環境中安裝 DB2 UDB 所需要的用戶特權。還說明在 DB2 UDB 默認安裝過程中創建的各種用戶和組。 Microsoft Windows 操作系統上需要的用戶和組帳戶： 假如在 Windows 操作系統上安裝 DB2 UDB，將需要下列用戶帳戶： 1、Installation 用戶帳戶。 2、DB2 Administration Server（DAS）用戶帳戶 。 3、DB2 UDB 實例所有者用戶帳戶。 Installation 用戶帳戶： 在運行 DB2 安裝向導之前，需要定義一個安裝用戶帳戶。該帳戶可以是一個本地或域用戶帳戶。該帳戶必須屬于要進行安裝的機器上的 Administrators 組。假如使用域帳戶，安裝帳戶必須屬于將要創建其他安裝用戶帳戶的域的 Domain Administrators 組。也可使用內置的 LocalSystem 帳戶進行 DB2 UDB Enterprise Server Edition 之外的其他所有產品的安裝。 上一頁3456789101112下一頁 可以在安裝之前定義其他用戶帳戶，也可以讓 DB2 安裝向導為您創建。所有用戶帳戶名必須遵守系統的命名規則和 DB2 UDB 命名規則。 DB2 Administration Server 用戶帳戶： DB2 Administration Server（DAS）需要使用本地或域帳戶。DAS 是一種非凡的服務，支持 GUI 工具并幫助完成治理任務。DAS 有一個分配的用戶帳戶，在 DB2 UDB 加載時用于啟動該服務。在 DB2 安裝向導中，其中有一個屏幕（如圖 3 所示）提示選擇用于啟動 DAS 服務的用戶帳戶。
圖 3. 在 DB2 安裝向導中指定 DAS 用戶帳戶 可以在安裝 DB2 UDB 之前創建該用戶帳戶，然后在這里指定，也可以讓 DB2 安裝向導為您創建該帳戶。默認情況下，向導將創建一個名為 db2admin 的新帳戶（但是可以隨意命名）。DAS 用戶帳戶也必須屬于執行安裝的機器上的 Administrators 組。假如讓 DB2 安裝向導創建新的域用戶帳戶，用于執行安裝的用戶帳戶必須有創建域用戶帳戶的權限。 安裝向導創建該帳戶時自動授予下列用戶權限: 1、作為操作系統的一部分。 2、調試程序。 3、創建 token 對象。 4、增加配額。 5、鎖定內存頁。 6、作為服務登錄。 7、代替進程級的 token。 假如創建或指定了不同的帳戶，一定要保證該帳戶具有上述用戶權限。為了保證正確設置了這些權限，打開 Windows 控制面板（Start > Settings > Control Panel）并雙擊 Administrative Tools 圖標。雙擊 Local Security Policy 圖標。對于上面列出的每種策略，保證該用戶包含在授權的用戶和組列表中。提供的口令不正確可能造成 DB2 UDB 啟動過程中不能加載某些服務，有可能禁止執行特定的操作。 上一頁45678910111213下一頁 在安裝過程中，還要告訴 DB2 安裝向導使用同一個帳戶（及指定給 DAS 的帳戶）擁有和啟動其他所有 DB2 UDB 服務。為此，一定要選中 “Use the same user name and password for the remaining DB2 UDB services（其他 DB2 UDB 服務使用同一用戶名和口令）” 復選框（參見 圖 3）。假如沒有選中該復選框，向導就會提示選擇擁有和啟動創建的默認實例的用戶帳戶。其他所有 DB2 UDB 服務將使用內置的 Windows LocalSystem 帳戶啟動。 還要保證 DAS 用戶帳戶對環境中每個 DB2 UDB 系統具有 SYSADM 權限，這樣在需要的時候可以啟動或停止其他實例。默認情況下，在 Windows 環境中安裝 DB2 UDB 后，屬于 Administrators 組的任何用戶都具有 SYSADM 權限。DAS 服務名稱為 DB2DAS - DB2DAS00。 DB2 UDB 實例所有者用戶帳戶： 要擁有和啟動 DB2 UDB 實例，需要一個本地或域帳戶。可以在安裝 DB2 UDB 之前創建 DB2 UDB 實例所有者用戶帳戶，也可以讓 DB2 安裝向導來創建。假如讓 DB2 安裝向導創建新的域用戶帳戶，執行安裝使用的用戶帳戶必須具有創建域用戶帳戶的權限。該用戶帳戶也必須是執行安裝的機器上 Administrators 組的成員。DB2 安裝向導創建該帳戶時自動授予下列用戶權限： 作為操作系統的一部分： 調試程序、創建 token 對象、增加配額、鎖定內存頁、作為服務登錄、代替進程級的 token。 假如創建或指定了不同的帳戶，一定要賦予該帳戶上述用戶權限。為了保證正確設置了這些權限，打開 Windows 控制面板（Start > Settings > Control Panel）并雙擊 Administrative Tools 圖標。雙擊 Local Security Policy 圖標。對于上面列出的每種策略，保證該用戶包含在授權的用戶和組列表中。提供的口令不正確會造成 DB2 UDB 啟動過程中無法加載服務，有可能禁止執行特定的動作。 上一頁567891011121314下一頁 在默認 Windows 安裝中將自動創建一個名為 DB2 的實例。可以分別使用 db2icrt 和 db2idrop 工具程序創建其他實例或刪除已有的實例。這些工具放在 DB2PATHsqllibin 目錄中，其中 DB2PATH 是安裝 DB2 UDB 的位置。運行這些工具程序必須使用具有本地 Administrator 權限的用戶帳戶。假如創建實例時通過參數提供用戶帳戶和口令，那么將使用該帳戶擁有和啟動該服務。假如沒有提供用戶帳戶和口令，則使用 LocalSystem 帳戶。比如，下面的命令將創建一個新實例 devinst，并賦予 LocalSystem 帳戶擁有和啟動該實例進程的權限： 清單 5. 在 Windows 中創建新的 DB2 UDB 實例db2icrt devinst。 修改帳戶信息： 安裝后可以修改與每個 DB2 UDB 服務關聯的用戶帳戶。此外，從 DB2 UDB Version 8.2 開始，可以使用內置的 LocalSystem Account（LSA）帳戶啟動 DB2 UDB 服務。在使用嚴格口令策略的系統上，使用 LSA 可能比較有利，因為 LSA 沒有關聯的口令。比如在有些環境中，要求用戶每兩個月換一次口令，否則其帳戶就會被暫時鎖住。這一策略要求修改指定用戶帳戶的口令來啟動 DB2 UDB 服務。假如配置成啟動某些服務的用戶帳戶被鎖住，或者用戶帳戶的口令被修改了，但是沒有在服務啟動屬性配置中更新，這些服務將無法啟動。 在將任何 DB2 UDB 服務從專門的用戶帳戶移交給 LocalSystem 帳戶之前，必須考慮到 LocalSystem 帳戶不能訪問 LAN 共享，因為不能在其他計算機上驗證身份。因此必須保證 DB2 UDB 系統不使用其他機器上的任何文件資源。 在 LocalSystem Account（LSA）上下文中運行的應用程序使用本地的 DB2 UDB 隱式連接。假如開發在該帳戶下運行的應用程序，必須知道 DB2 UDB 關于對象模式名以 “SYS” 開頭的限制。假如應用程序包含創建 DB2 UDB 對象的語句，應該這樣寫： 上一頁6789101112131415下一頁 新聞熱點
疑難解答
