An toàn DB2 UDB, Phần 1: Hiểu cách các tài khoản
người dùng và nhóm tương tác với DB2 UDB
Giới thiệu
Những người mới dùng DB2 UDB thường hay hỏi về các tài khoản người dùng và nhóm cần
thiết cho một bản cài đặt và môi trường hoạt động của DB2 UDB. Trong bài này, bạn sẽ tìm hiểu
về các tương tác chính của DB2 UDB với những người dùng và các nhóm. Bài này mô tả tài
khoản người dùng mà bạn sẽ cần đến khi cài đặt DB2 UDB trên các hệ điều hành Linux, UNIX
và Windows, cũng như các tài khoản bổ sung mà bạn sẽ cần để chạy các quy trình và các dịch vụ
DB2 UDB khác nhau. Bài này cũng đánh giá mô hình an toàn DB2 UDB, bao gồm việc xác thực
người dùng, ủy quyền của người dùng và nhóm, và các siêu người dùng. Bài này áp dụng cho
Phiên bản 8.2 của DB2 UDB cho Linux, UNIX, và Windows; tuy nhiên, nhiều phần trong bài
này cũng có thể áp dụng cho các phiên bản DB2 UDB cũ hơn.
Về đầu trang
Mô hình an toàn DB2 UDB
Mô hình an toàn DB2 UDB gồm hai thành phần chính: xác thực và ủy quyền. Hình 1 đưa ra một
tổng quan về mô hình an toàn DB2 UDB.
Hình 1. Mô hình an toàn DB2 UDB
Xác thực
Việc xác thực là quá trình xác nhận hợp lệ một mã định danh (ID) và mật khẩu đã cấp cho người
dùng khi sử dụng một cơ chế an toàn. Việc xác thực người dùng và nhóm được quản lý trong
một phương tiện ngoài thay cho DB2 UDB, như hệ điều hành, một trình điều khiển miền, hoặc
một hệ thống an toàn Kerberos. Điều này khác với các hệ thống quản lý cơ sở dữ liệu khác (các
DBMS), như Oracle và SQL Server, là ở đây các tài khoản người dùng có thể được định nghĩa
và xác thực trong chính cơ sở dữ liệu đó, cũng như trong một phương tiện bên ngoài như hệ điều
hành.
Bất kỳ lúc nào cung cấp trực tiếp cho DB2 UDB một ID và mật khẩu người dùng như là một
phần của một cá thể đính kèm hoặc yêu cầu kết nối cơ sở dữ liệu, DB2 UDB cố gắng xác nhận
ID và mật khẩu người dùng đó bằng cách sử dụng phương tiện an toàn bên ngoài này. Nếu ID
hoặc mật khẩu người dùng không được cung cấp kèm với yêu cầu, DB2 UDB ngầm sử dụng ID
và mật khẩu người dùng đã được sử dụng để đăng nhập vào máy trạm, nơi tạo ra yêu cầu này.
Giá trị của tham số AUTHENTICATION của cá thể DB2 UDB xác định vị trí xác thực thực tế. Các
lược đồ xác thực khác nhau gồm những người dùng đã xác thực trên chính máy chủ DB2 UDB
đó (bằng cách sử dụng phương tiện chức năng an toàn của máy chủ), trên máy khách (cho phép
truy cập "đăng nhập một lần"), một phương tiện an toàn Kerberos, hoặc một trình cắm thêm GSS
(Generic Security Service – Dịch vụ an toàn chung) do người dùng định nghĩa. Các tùy chọn xác
thực bổ sung gồm khả năng mã hóa các tên và các mật khẩu người dùng, cũng như dữ liệu, khi
chúng truyền trên mạng giữa máy khách và máy chủ. Giá trị mà bạn chọn cho tham số
AUTHENTICATION tùy thuộc vào môi trường cụ thể của bạn cũng như các chính sách an toàn cục
bộ. Để có một mô tả đầy đủ về các lược đồ xác thực khác nhau, hãy tham khảo Tài liệu DB2
UDB. (Xem phần Tài nguyên.)
Ví dụ, Hình 1 cho thấy câu lệnh kết nối được một người dùng có tên là bob sử dụng để nối tới cơ
sở dữ liệu finance (tài chính) bằng mật khẩu bobpsw. Có sáu bước xảy ra trong quá trình xác
thực này:
1. Câu lệnh CONNECT được truyền đến máy chủ DB2 UDB.
2. Nếu vẫn chưa cấu hình trình cắm thêm an toàn, thì sẽ sử dụng trình cắm thêm mặc định.
Khi tham số AUTHENTICATION của cá thể có chứa cơ sở dữ liệu finance được thiết lập là
SERVER (thiết lập mặc định), phương tiện chức năng an toàn trên máy chủ DB2 UDB sẽ
xác thực ID và mật khẩu người dùng được cấp trong yêu cầu kết nối. Trình cắm thêm
mặc định sẽ gửi ID và mật khẩu người dùng tới hệ điều hành để xác nhận hợp lệ.
3. Hệ điều hành xác nhận xem liệu tổ hợp bob/bobpsw có hợp lệ hay không, và trả về thông
tin này cho trình cắm thêm an toàn.
4. Trình cắm thêm an toàn gọi cơ chế an toàn DB2 UDB để truy vấn các bảng danh mục
DB2 UDB cho người dùng bob để xem liệu người dùng có tên đó đã được cấp đặc quyền
CONNECT với cơ sở dữ liệu đó chưa. Theo mặc định, đặc quyền CONNECT được cấp
PUBLIC (CÔNG KHAI), có nghĩa là bất kỳ người dùng nào được xác thực thành công
đều có thể kết nối tới cơ sở dữ liệu này.
5. Cơ chế an toàn DB2 UDB xác nhận hợp lệ người dùng bob, hoặc trả về một lỗi.
6. Trình cắm thêm an toàn trả về cho người dùng một thông báo thành công hay thất bại.
Nếu người dùng không thể xác thực thành công, DB2 UDB từ chối yêu cầu kết nối và trả
về một thông báo lỗi cho ứng dụng khách, tương tự như sau:
Liệt kê 1. DB2 UDB trả về một thông báo cho ứng dụng này khi xác thực người dùng
không thành công
SQL30082N Attempt to establish connection
failed with security
reason "24" ("USERNAME AND/OR PASSWORD
INVALID"). SQLSTATE=08001
Một mục nhập tương tự như sau cũng xuất hiện trong bản ghi nhật ký chẩn đoán DB2 UDB
(db2diag.log) trên máy chủ DB2 UDB:
Liệt kê 2. Thông báo trong bản ghi nhật ký chẩn đoán của DB2 khi xác thực người dùng
không thành công
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
Trên Windows, có thể tìm thấy bản ghi nhật ký chẩn đoán trong thư mục gốc Instance, theo mặc
định là C:\Program Files\IBM\SQLLIB\DB2 . Trên UNIX, theo mặc định, bản ghi này đặt ở
<DB2PATH>/DB2/db2dump, ở đây <DB2PATH> là đường dẫn của chủ sở hữu cá thể.
Nếu bạn luôn gặp phải các thông báo này, hãy bảo đảm rằng người dùng hay ứng dụng nối đến
cơ sở dữ liệu đã cung cấp một ID và mật khẩu người dùng hợp lệ. ID và mật khẩu người dùng
này phải tồn tại trong phương tiện mà việc xác thực người dùng được thiết lập để diễn ra ở đó
(được xác định bởi tham số AUTHENTICATION của cá thể DB2 UDB đích).
Uỷ quyền
Uỷ quyền là quá trình xác định thông tin truy cập và đặc quyền về các đối tượng và các hành
động của cơ sở dữ liệu cụ thể đối với một ID người dùng đã cấp. DB2 UDB lưu trữ và duy trì
thông tin ủy quyền người dùng và nhóm ở bên trong. Mỗi lần bạn gửi đi một lệnh, DB2 UDB
thực hiện kiểm tra ủy quyền để đảm bảo rằng bạn có tập đặc quyền đúng để thực hiện hành động
đó.
Các đặc quyền có thể được cấp cho những người dùng cụ thể hoặc cho các nhóm người dùng.
Thêm nữa, cả hai định nghĩa người dùng và định nghĩa nhóm tự chúng được định nghĩa bên
ngoài DB2 UDB. Những người dùng là một thành viên của một nhóm tự động thừa hưởng các
đặc quyền của nhóm. Các đặc quyền cụ thể được cấp cho một người dùng có tiền lệ hơn các đặc
quyền liên quan với bất kỳ (các) nhóm mà người dùng là một thành viên, và vẫn cứ tồn tại ngay
cả khi sau đó người dùng bị loại khỏi (các) nhóm đó. Có nghĩa là, các đặc quyền trực tiếp đã cấp
cho một người dùng phải trực tiếp bị hủy bỏ.
Hầu hết các đối tượng cơ sở dữ liệu có một tập các đặc quyền liên quan có thể được gán cho
những người dùng và các nhóm, bằng cách sử dụng các câu lệnh SQL GRANT (cấp) và
REVOKE (hủy bỏ). Ví dụ, câu lệnh SQL dưới đây cấp đặc quyền SELECT (chọn) trên bảng có
tên là ADM.ACCTABC cho một người dùng tên là bob:
GRANT SELECT ON TABLE ADM.ACCTABC TO USER BOB
Một khi ban hành câu lệnh này, người dùng bob có thể gửi đi các câu lệnh SELECT để tham
khảo bảng này. Cũng vậy, câu lệnh SQL sau hủy bỏ đặc quyền INSERT (chèn) trên một khung
nhìn (view) tên là ADM.LEGERS từ một nhóm có tên là clerks (các thư ký):
REVOKE INSERT ON VIEW ADM.LEGERS FROM GROUP CLERKS
Bạn chỉ có thể hủy bỏ một đặc quyền đã cấp trước đây. Để biết thông tin chi tiết về tất cả các đặc
quyền của đối tượng cơ sở dữ liệu khác nhau, có thể được cấp cho những người dùng và các
nhóm, hãy tham khảo tài liệu DB2 UDB (xem phần Tài nguyên).
Điều quan trọng cần lưu ý, đặc biệt với những người mới dùng DB2 UDB, câu lệnh GRANT
không kiểm tra sự tồn tại của một tài khoản người dùng hoặc tài khoản của nhóm trong phương
tiện bên ngoài. Điều này có nghĩa là có thể cấp các đặc quyền cho các tài khoản người dùng và
nhóm không tồn tại theo thông tin được lưu trữ trong cơ sở dữ liệu. Điều này gây ra cảm giác sai
lầm rằng các tài khoản người dùng và nhóm có thể được định nghĩa trong DB2 UDB. Ví dụ, nếu
bạn đưa ra câu lệnh sau trong khi kết nối tới cơ sở dữ liệu finance:
GRANT SELECT ON TABLE ADM.TAXCODE TO USER XYZ
ở đây xyz là bất kỳ chuỗi ký tự nào không ánh xạ tới một người dùng hiện có trong phương tiện
an toàn bên ngoài, sau đó DB2 UDB sẽ hiển thị xyz trong các công cụ giao diện người dùng đồ
họa (GUI) của nó hoặc trong một số các bảng danh mục, như được minh họa trong Hình 2. Điều
này không có nghĩa là một người dùng tên là xyz tồn tại hoặc đã được tạo ra.
Hình 2. Các đặc quyền bảng sau khi cấp các đặc quyền cho một người dùng không xác
định
Phần dưới cùng của Hình 1 cho thấy một ví dụ về một kịch bản uỷ quyền. Người dùng có tên là
bob, người trước đó đã kết nối thành công, bây giờ cố gắng thực hiện một câu lệnh SELECT trên
bảng ADM.TAXCODES. DB2 UDB sẽ tìm trong các bảng danh mục của nó để xem liệu người
dùng này đã được cấp phép với câu lệnh SELECT từ bảng này chưa. Do đặc quyền này trước
đây được cấp cho bob, nên DB2 UDB cho phép tiếp tục thực hiện câu lệnh SELECT.
Nếu người dùng không được uỷ quyền thực hiện một hoạt động đối với một đối tượng cụ thể,
DB2 UDB từ chối hoạt động này và trả về một thông báo lỗi đến ứng dụng khách. Ví dụ, nếu
người dùng bob đã cố INSERT (chèn) một hàng vào bảng ADM.TAXCODES, nhưng lại không
có đủ các đặc quyền để làm như vậy, thông báo lỗi sau sẽ được trả về:
Liệt kê 3. DB2 UDB trả về thông báo khi ủy quyền người dùng không thành công
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
Nếu bạn luôn gặp phải các thông báo tương tự, hãy bảo đảm rằng ID người dùng được đưa ra để
nối tới cơ sở dữ liệu có các đặc quyền thích hợp để thực hiện hoạt động đích. Người dùng phải
được cấp trực tiếp đặc quyền đó, là một phần của một nhóm đã được cấp đặc quyền đó, hoặc là
một siêu người dùng.