Tải bản đầy đủ (.pdf) (75 trang)

Chuẩn bị cho kỳ thi cơ bản về DB2 9, Phần 2: Các vấn đề về bảo mật doc

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (312.5 KB, 75 trang )

Chuẩn bị cho kỳ thi cơ bản về DB2 9, Phần 2: Các vấn đề về bảo mật
Graham G. Milne, Chuyên gia DB2, IBM Canada
Tóm tắt: Bài viết này giới thiệu các khái niệm xác thực, quyền xác nhận, và các
đặc quyền vì chúng có liên quan đến DB2® 9. Đây là bài viết thứ hai trong loạt
bảy bài viết giúp bạn chuẩn bị cho bài kiểm tra về các nguyên tắc cơ bản của DB2
9 (730). Bạn cần có các kiến thức cơ bản về các khái niệm cơ sở dữ liệu và bảo
mật hệ điều hành. Đây là bài viết thứ hai trong loạt bảy bài viết để giúp bạn chuẩn
bị cho bài kiểm tra về các nguyên tắc cơ bản của DB2® 9 cho Linux®, UNIX®,
và Windows™.
Trước khi bắt đầu
Về loạt bài viết này
Bạn đã nghĩ tới việc có một chứng chỉ về các khái niệm cơ bản của DB2 (Bài kiểm
tra 730)? Nếu bạn nghĩ như thế thì bạn đã đến đúng chỗ. Loạt bảy bài viết chuẩn bị
cho bài thi đề cập tới tất cả các khái niệm cơ bản các chủ đề mà bạn cần hiểu
trước khi bạn đọc câu hỏi trong bài kiểm tra đầu tiên. Thậm chí nếu bạn không có
ý định lấy chứng chỉ thì loạt bài viết này cũng là một bắt đầu tuyệt vời cung cấp
cho bạn những điều mới mẻ về DB2 9.
Về bài viết này
Trong bài viết này bạn sẽ học về các đặc điểm bảo mật DB2 9, bao gồm thẩm định
quyền và các quyền hạn.
Đây là bài viết thứ hai trong loạt bài viết giúp bạn chuẩn bị cho bài kiểm tra 730
về các nguyên tắc cơ bản của DB2 9. Nội dung bài viết này đề cập đến các mục
tiêu trong phần 2 của bài kiểm tra, phần này có tên là "Bảo mật" ("Security"). Bạn
có thể xem các mục tiêu này tại:


Các điều kiện tiên quyết
Để hiểu các khái niệm được mô tả trong bài viết này, bạn cần phải có kiến thức cơ
bản về các khái niệm cơ sở dữ liệu và hiểu về các đặc điểm của hệ thống bảo mật
của hệ điều hành.



Các yêu cầu của hệ thống
Các ví dụ trong bài viết này là cố định đối với DB2 chạy trên hệ điều hành
Windows™ (với các đặc điểm bảo mật cơ bản). Tuy nhiên, các khái niệm và thông
tin cung cấp cũng tương thích với DB2 chạy trên bất kỳ nền nào.
Bạn không cần một bản sao DB2 9 để hoàn thành bài học này. Tuy nhiên, bạn sẽ
biết được nhiều hơn những gì bài viết cung cấp nếu bạn tải phiên bản thử nghiệm
miễn phí của IBM DB2 9 để làm việc cùng bài viết này.


Cài đặt
Để hoàn thành các bước trong bài viết, bạn cần phải:
1. Đăng nhập vào một máy Windows như một thành viên của nhóm quản trị.
Trong các ví dụ của bài viết này, chúng ta sẽ đăng nhập bằng tài khoản
người dùng là gmilne.
2. Cài đặt DB2 9.
3. Tạo một nhóm mới trên máy đã cài DB2. Bài viết sử dụng tài khoản nhóm
là db2grp1.
4. Tạo một tài khoản người dùng thứ hai trên đó DB2 đã được cài đặt. Trong
bài viết, vì mục đích đó mà chúng ta sẽ dùng tài khoản người dùng là test1.
Lưu ý rằng người dùng test1 không phải là một thành viên trong nhóm quản
trị.

Bảo mật DB2
Các khía cạnh của bảo mật cơ sở dữ liệu
Ngày nay, bảo mật có sở dữ liệu là điều tối quan trọng. Dữ liệu cơ sở của bạn có
thể cho phép khách hàng mua các sản phẩm qua mạng, hoặc nó có thể chứa các dữ
liệu đã dùng để tiên đoán về xu hướng kinh doanh và dù vì lý do gì thì công ty của
bạn cũng cần một kế hoạch bảo mật cơ sở dữ liệu thật tốt.
Một kế hoạch bảo mật cơ sở dữ liệu cần hiểu:

 Ai được phép truy cập các thể hiện hay các dữ liệu.
 Mật khẩu người dùng sẽ được kiểm tra ở đâu và như thế nào?
 Giới hạn quyền mà người dùng được phép.
 Các lệnh mà người dùng được thực hiện.
 Dữ liệu mà người dùng được phép đọc hoặc thay đổi.
 Các đối tượng cơ sở dữ liệu mà người dùng được phép tạo ra, thay đổi hoặc
loại bỏ.
Cơ chế bảo mật DB2
Có ba cơ chế bảo mật trong DB2 cho phép một DBA (người quản trị CSDL) thực
hiện một kế hoạch bảo mật cơ sở dữ liệu: xác thực, quyền xác nhận, và các đặc
quyền.
Xác thực là đặc điểm bảo mật đầu tiên bạn sẽ phải giải quyết khi bạn cố truy cập
một thể hiện hoặc cơ sở dữ liệu DB2. Xác thực DB2 làm việc gần với các đặc
điểm bảo mật của hệ điều hành bên dưới để kiểm tra lại tài khoản người dùng và
mật khẩu. DB2 cũng làm việc với các giao thức bảo mật như là Kerberos để xác
thực người dùng.
Quyền xác nhận liên quan đến việc chỉ định các thao tác mà người dùng/ nhóm
người dùng có thể trình bày, và các đối tượng dữ liệu mà họ có thể truy cập. Khả
năng trình bày dữ liệu bậc cao và thao tác quản lý thể hiện của người dùng được
chỉ định bởi các quyền xác nhận mà họ đã được gán cho. Có năm mức xác nhận
khác nhau trong DB2 là SYSADM, SYSCTRL, SYSMAINT, DBADM, và
LOAD.
Các đặc quyền có vẻ cụ thể hơn các xác thực và có thể được gán cho người dùng
hoặc nhóm người dùng. Các đặc quyền cho phép định nghĩa các đối tượng mà
người dùng có thể tạo ra hoặc bỏ đi. Các đặc quyền cũng định nghĩa các lệnh mà
người dùng có thể sử dụng để truy cập đối tượng như là các bảng biểu, các khung
nhìn, các chỉ mục và các gói. Điều mới trong DB2 là khái niệm kiểm soát truy cập
theo nhãn (LBAC) cho phép kiểm soát cụ thể hơn về người dùng nào có thể truy
cập các hàng hoặc cột riêng lẻ nào.
Để chuẩn bị cho phần tiếp theo của bài viết, bạn sẽ cần tạo ra một cơ sở dữ liệu

trong ví dụ DB2. Hãy đảm bảo rằng biến %DB2INSTANCE% vẫn có ở DB2 và
sau đó tạo cơ sở dữ liệu mẫu sử dụng lệnh db2sampl drive (ổ đĩa), dùng tên của ổ
mà bạn muốn tạo mẫu đó. Đối với những ví dụ trong bài viết này bạn sẽ tạo cơ sở
dữ liệu mẫu trên ổ D của chúng ta như sau:
D:\SQLLIB\BIN> db2sampl d:



Các máy khách (clients), máy chủ (servers), cổng vào ra (gateways) và máy chủ
lưu trữ (hosts)
Việc bạn hiểu các khái niệm máy khách, máy chủ, cổng vào ra, và máy chủ phục
vụ rất quan trọng khi chúng ta xem xét sự bảo mật của toàn bộ môi trường cơ sở
dữ liệu. Một môi trường cơ sở dữ liệu bao gồm các máy khác nhau, bạn phải bảo
vệ cơ sở dữ liệu ở bất kỳ điểm truy cập nào. Các khái niệm máy khách, máy chủ,
cổng vào ra và máy chủ lưu trữ đặc biệt quan trọng khi làm việc với xác thực DB2.
Sơ đồ dưới đây sẽ minh hoạ cấu hình cơ bản client-server-host.
Máy chủ cơ sở dữ liệu là một máy (hoặc nhiều máy trong một hệ thống) mà cơ sở
dữ liệu tồn tại một cách tự nhiên ở đó. Máy khách cơ sở dữ liệu DB2 là các máy
được định cấu hình tìm các truy vấn ngược lại với các cơ sở dữ liệu trên máy chủ.
Những máy khách này có thể tồn tại ở ngay trong một máy như máy chủ cơ sở dữ
liệu hoặc có thể ở xa (trong các máy riêng biệt).
Nếu cơ sở dữ liệu nằm trong một hệ thống máy chạy hệ điều hành như AS/400
(iSeries) hay OS/390 (zSeries), thì nó được gọi là một máy chủ lưu trữ hoặc máy
chủ lưu trữ phục vụ. Một cổng vào ra là một máy chạy sản phẩm kết nối DB2.
Thông qua cổng vào ra, máy khách DB2 có thể kết nối với một cơ sở dữ liệu DB2
nằm trên máy chủ lưu trữ. Cổng vào ra cũng được đề cập đến như một máy chủ
lưu trữ kết nối DB2. Hệ thống cùng với bộ cài sản phẩm Enterprise Server Edition
cũng có hàm kết nối DB2 cài sẵn.
.
Xác thực DB2

Khi xác thực DB2
Xác thực DB2 kiểm soát các mặt sau của một kế hoạch bảo mật cơ sở dữ liệu:
 Ai có quyền truy cập thể hiện và/hoặc cơ sở dữ liệu.
 Mật khẩu người dùng sẽ được kiểm tra lại khi nào và như thế nào?
DB2 thực hiện các điều trên nhờ sự hỗ trợ của các đặc điểm bảo mật hệ điều hành
cơ sở khi một lệnh đính kèm hoặc hoặc kết nối được phát ra. Một lệnh đính kèm
được dùng để kết nối với thể hiện DB2 khi một lệnh kết nối được dùng để kết nối
với cơ sở dữ liệu trong thể hiện DB2. Các thể hiện dưới đây đưa bạn đến với các
cách thức khác nhau mà xác thực DB2 là người dùng đang phát ra các lệnh này.
Những thể hiện này dùng loại xác nhận mặc định của máy chủ lưu trữ trong tệp
cấu hình quản lý cơ sở dữ liệu. Ví dụ 3 dưới đây minh họa cách dùng DB2 để thay
đổi mật khẩu trên OS của máy chủ lưu trữ.
Đăng nhập vào máy có cài sẵn DB2 với tên người dùng bạn dùng để tạo thể hiện
DB2. Phát ra các lệnh sau:

db2 attach to DB2

Ở đây, xác thực được thực hiện hoàn toàn. Tài khoản người dùng thường đăng
nhập vào máy đang dùng và giả định là nó đã được hệ điều hành kiểm tra lại.
db2 connect to sample user test1 using password
Database Connection Information
Database server = DB2/NT 9.1.0
SQL authorization ID = TEST1
Local database alias = SAMPLE


Ở đây, xác thực được thực hiện rõ ràng. Người dùng test1 với mật khẩu là
password được hệ điều hành kiểm tra lại. Người dùng test1 kết nối thành công tới
cơ sở dữ liệu mẫu.


db2 connect to sample user test1 using password new chgpass confirm chgpass

Tài khoản người dùng test1 với mật khẩu password được hệ điều hành kiểm tra lại
như trong ví dụ 2. Mật khẩu cho test1 sau đó được hệ điều hành thay đổi từ
password thành chgpass. Và kết quả là lệnh trong ví dụ 2 sẽ thất bại nếu bạn gửi
lại lệnh trên.


Các loại xác thực DB2
Các loại xác thực được DB2 dùng để chỉ định khi xác thực xảy ra. Ví dụ, trong
môi trường một máy khách-máy chủ (client-server), máy khách hay máy chủ sẽ
kiểm tra lại tài khoản và mật khẩu người dùng? Trong môi trường máy khách-
cổng vào ra-máy chủ lưu trữ (client-gateway-host), liệu máy khách hay máy chủ
lưu trữ sẽ kiểm tra lại tài khoản và mật khẩu người dùng?
DB2 9 có khả năng xác định các cơ chế bảo mật khác nhau tùy thuộc vào liệu
người dùng có cố kết nối với cơ sở dữ liệu hay trình bày các thể hiện đính kèm và
các thể hiện mức thao tác. Thông qua mặc định, thể hiện được thiết lập để dùng
một loại xác thực cho tất cả các mức của thể hiện cũng như mức yêu cầu kết nối.
Điều này được xác định bằng tham số cấu hình quản lý dữ liệu
AUTHENTICATION. Tham số cấu hình quản lý dữ liệu SRVCON_AUTH được
giới thiệu trong V9.1. Tham số này giải quyết việc kết nối tới cơ sở dữ liệu. Vì thế,
ví dụ là nếu bạn có tập hợp sau trong DBM CFG của bạn:
DB2 GET DBM CFG
Server Connection Authentication (SRVCON_AUTH) = KERBEROS
Database manager authentication (AUTHENTICATION) =
SERVER_ENCRYPT


Thì các tệp đính kèm vào thể hiện sẽ dùng SERVER_ENCRYPT. Dẫu sao kết nối
tới cơ sở dữ liệu có thể dùng xác thực KERBEROS. Nếu KERBEROS ban đầu

không phải dành cho máy chủ nhưng một tài khoản người dùng còn hiệu lực kèm
mật khẩu được cung cấp thì người dùng sẽ được phép đính kèm vào thể hiện
nhưng không được phép truy cập dữ liệu.
Bảng sau tổng kết các loại xác thực DB2. Trong một môi trường máy khách-cổng-
máy chủ lưu trữ, những lựa chọn xác thực này được lập trong máy khách và cổng
vào ra chứ không phải trong máy chủ lưu trữ. Trong phần này chúng ta sẽ thảo
luận kỹ hơn về việc lập các lựa chọn này. Xem Máy khách, máy chủ, cổng vào ra,
và máy chủ lưu trữ để biết thêm chi tiết.
Loại Mô tả
Máy chủ (SERVER) Xác thực xảy ra trong máy chủ.
SERVER_ENCRYPT
Xác thực xảy ra trong máy chủ. Mật khẩu được mã
hóa ở máy khách trước khi được gửi tới máy chủ.
Máy khách (CLIENT)
Xác thực xảy ra trong máy khách (xem Giải quyết
các máy khách không chính xác đối với các trường
hợp ngoại lệ).
*KERBEROS
Xác thực được trình bày bởi phần mềm bảo mật
Kerberos.
*KRB_SERVER_ENCRYPT

Xác thực được trình bày bởi phần mềm bảo mật
Kerberos nếu máy khách có cài KERBEROS. Nếu
không, SERVER_ENCRYPT sẽ được dùng.
DATA_ENCRYPT
Xác thực xảy ra trong máy chủ. Máy chủ chấp nhận
tài khoản và mật khẩu người dùng được mã hóa, và
sẽ mã hóa dữ liệu. Điều này cũng xảy ra tương tự
như SERVER_ENCRYPT, ngoại trừ dữ liệu cũng

được mã hóa.
DATA_ENCRYPT_CMP
Xác thực tương tự với DATA_ENCRYPT, ngoại
trừ việc hệ thống này cho phép các máy khách cũ
mà không cung cấp hệ thống DATA_ENCRYPT để
kết nối được phép dùng xác thực
SERVER_ENCRYPT. Trong trường hợp này dữ
liệu sẽ không bị mã hóa. Nếu khách hàng kết nối
cung cấp DATA_ENCRYPT thì sẽ phải mã hóa dữ
liệu, và không thể đánh giá thấp đối với xác thực
SERVER_ENCRYPT. Loại xác thực này chỉ có
hiệu lực trong tệp cấu hình quản lý cơ sở dữ liệu và
không có hiệu lực khi dùng một lệnh CATALOG
DATABASE trên thể hiện máy khách hoặc cổng
vào ra.
GSSPLUGIN
Xác thực được kiểm soát bởi một đầu cắm ngoài
GSS-API.
GSS_SERVER_ENCRYPT
Xác thực được kiểm soát bởi một đầu cắm ngoài
GSS-API. Trong trường hợp máy khách không
cung cấp một trong các đầu cắm ngoài GSS-API
của máy chủ lưu trữ, thì xác thực
SERVER_ENCRYPT được dùng.
*Những cài đặt này chỉ có hiệu lực với các hệ điều hành Windows 2000, AIX,
Solaris và Linux®
.


Cài đặt xác thực trên máy chủ

Xác thực được cài trên cơ sở dữ liệu máy chủ trong tệp cấu hình quản lý cơ sở dữ
liệu (DBM CFG) dùng tham số AUTHENTICATION. Lưu ý, tệp DBM CFG là
một tệp cấu hình mức thể hiện. Do đó, tham số AUTHENTICATION ảnh hưởng
tới tất cả các cơ sở dữ liệu trong thể hiện. Lệnh sau đây minh họa cách mà tham số
được thay đổi.
Để xem tham số xác thực trong tệp cấu hình:
db2 get dbm cfg

Để thay đổi tham số xác thực cho server_encrypt:
C:\PROGRA~1\SQLLIB\BIN> db2 update dbm cfg using authentication
server_encrypt
C:\PROGRA~1\SQLLIB\BIN> db2stop
C:\PROGRA~1\SQLLIB\BIN> db2start


Các loại xác thực như là GSSPLUGIN, KERBEROS, và CLIENT cần cài các
tham số cấu hình quản lý dữ liệu như TRUST_ALLCLNTS,
SRV_PLUGIN_MODE, và SRVCON_PW_PLUGIN. Xem thêm chi tiết trong các
cài đặt dưới đây.


Cài đặt xác thực cho cổng vào ra
Xác thực được cài đặt vào cổng vào ra bằng cách dùng lệnh danh mục cơ sở dữ
liệu. Trong các ví dụ dưới đây, chúng ta sẽ dùng một cơ sở dữ liệu máy chủ lưu trữ
được đặt tên là myhostdb.
Để cài đặt loại xác thực của cổng vào ra gửi tới SERVER, bạn có thể phát ra lệnh
sau trên cổng vào ra:
db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate



Lưu ý là xác thực không bao giờ được trình bày trên cổng vào ra. Trong DB2
phiên bản 8, xác thực luôn xuất hiện ở trên máy khách hoặc trên cơ sở dữ liệu máy
chủ lưu trữ phục vụ.


Thiết lập xác thực trên máy khách
Hãy xem xét hai kịch bản trên hai máy khách tách biệt nhau. Chúng ta sẽ định cấu
hình là một máy kết nối với cơ sở dữ liệu trên một máy chủ (nền tảng phân phối
DB2 UDB LUW), và một máy kết nối với cơ sở dữ liệu trên một máy chủ lưu trữ
(ví dụ như DB2 cho zSeries).
 Máy khách kết nối với một cơ sở dữ liệu máy chủ: Cài đặt xác nhận máy
khách trong thư mục cơ sở dữ liệu nhập vì cơ sở dữ liệu đang được kết nối
phải phù hợp với cơ sở dữ liệu của cơ sở dữ liệu máy chủ (ngoại lệ là các
trường hợp KRB_SERVER_ENCRYPT, DATA_ENCRYPT_CMP, và
GSS_SERVER_ENCRYPT).
Hãy giả sử rằng loại xác thực cho máy chủ được cài trên máy chủ. Lệnh sau
sẽ được phát từ máy khách tới danh mục cơ sở dữ liệu máy chủ có tên là
spamle:
db2 catalog database sample at node nd1 authentication SERVER

Nếu loại xác thực không cụ thể thì máy khách sẽ dùng
SERVER_ENCRYPT như mặc định.
 Máy khách kết nối với cơ sở dữ liệu của máy chủ lưu trữ: Chúng ta giả
định rằng loại xác thực trên cổng vào ra được cài trên SERVER. Nếu một
loại xác thực không được xác định thì xác thực SERVER_ENCRYPT được
thừa nhận khi truy cập một cơ sở dữ liệu bằng kết nối DB2. Xác thực sẽ xẩy
ra trên máy chủ lưu trữ cơ sở dữ liệu. Câu lệnh sau được phát ra từ máy
khách sẽ buộc máy khách gửi bản giải mã mật khẩu và tài khoản người
dùng tới cổng vào ra.


db2 catalog database myhostdb at node nd1 authentication SERVER

Bây giờ, giả định rằng xác thực được cài trên SERVER_ENCRYPT ở cổng
vào ra. Lại một lần nữa xác thực xảy ra trên máy chủ lưu trữ cơ sở dữ liệu.
Mật khẩu và tài khoản người dùng được mã hóa trên máy khách trước khi
được gửi tới cổng vào ra và mã hóa trên cổng vào ra trước khi được gửi tới
máy chủ lưu trữ dữ liệu. Đây là một hành động mặc định.


Đối phó với máy khách không đủ độ tin cậy
Nếu máy chủ hoặc cổng vào ra có tổ hợp xác thực trong CLIENT thì có nghĩa là
máy khách đó sẽ xác thực tài khoản và mật khẩu người dùng. Tuy nhiên một vài
máy khách có thể không có hệ điều hành có các đặc điểm bảo mật cục bộ. Những
máy khách không đủ độ tin cậy này bao gồm máy khách DB2 chạy trên Window
98 và Window ME. DB2 V9.1 không hỗ trợ Window 98 và Window ME nhưng
nó hỗ trợ các máy khách bậc thấp và cũng phải đối phó với các máy khách không
đủ độ tin cậy V8.
Có hai loại tham số thêm vào trong tệp DBM CFG thường chỉ định khi nào thì xác
thực nên xảy ra và khi phương pháp xác thực máy chủ và máy chủ lưu trữ được
cài vào CLIENT và các máy khách không đủ độ tin cậy đang cố kết nối tới cơ sở
dữ liệu hoặc được đính kèm vào thể hiện DB2. Đây chính là các tham số
TRUST_ALLCLNTS và TRUST_CLNTAUTH.
Khi loại xác thực máy chủ hoặc cổng vào ra là CLIENT thì sẽ có hai yếu tố khác
thêm vào các tham số TRUST_ALLCLNTS và TRUST_CLNTAUTH. Yếu tố đầu
tiên là liệu tài khoản và mật khẩu người dùng có được cung cấp cụ thể rõ ràng hay
không, và yếu tố thứ hai là loại kết nối của máy khách. Có ba loại khách hàng
DB2 là:
 Máy khách không đủ độ tin cậy: như mô tả trên.
 Các máy khách hoạt động trên máy chủ lưu trữ: Máy khách chạy trên

hệ điều hành máy chủ lưu trữ như là zSeries.
 Máy khách đủ độ tin cậy: Máy khách chạy trên hệ điều hành không có
máy chủ lưu trữ mà có các đặc điểm bảo mật như là Windows NT, 2000,
2003, XP và tất cả các dạng của Unix/Linux.


Khi xác thực được cài lên CLIENT
Bảng kê dưới đây tổng hợp các điểm xác thực diễn ra khi một lệnh kết nối hoặc
đính kèm được phát ra từ mỗi máy khách tới một máy chủ có loại xác thực được
cài trên CLIENT.
User
ID/Passwo
rd
Supplied?

TRUST_ALLCLN
TS
TRUST_CLNTAU
TH
Untrust
ed
Client
Truste
d
Client
Host
Client
No Yes CLIENT CLIENT

CLIEN

T
CLIEN
T
No Yes SERVER CLIENT

CLIEN
T
CLIEN
T
No No CLIENT
SERVE
R
CLIEN
T
CLIEN
T
No No SERVER
SERVE
R
CLIEN
T
CLIEN
T
No DRDAONLY CLIENT
SERVE
R
SERVE
R
CLIEN
T

No DRDAONLY SERVER
SERVE
R
SERVE
R
CLIEN
T
Yes Yes CLIENT CLIENT

CLIEN
T
CLIEN
T
Yes Yes SERVER
SERVE
R
SERVE
R
SERVE
R
Yes No CLIENT
SERVE
R
CLIEN
T
CLIEN
T
Yes No SERVER
SERVE
R

SERVE
R
SERVE
R
Yes DRDAONLY CLIENT
SERVE
R
SERVE
R
CLIEN
T
Yes DRDAONLY SERVER
SERVE
R
SERVE
R
SERVE
R
DRDAONLY chỉ đề cập tới các máy khách thuộc máy chủ lưu trữ, mặc dù thực tế
là DB2 phiên bản 8 kết nối máy khách cũng sử dụng DRDA.
Các ví dụ dưới đây minh hoạ các loại cài đặt xác thực và tham số trên máy chủ và
máy khách:
Cài đặt xác thực trên máy chủ:
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



Cài đặt xác thực trên máy khách:
db2 catalog database sample at node nd1 authentication client

Trong ví dụ trước, nếu lệnh
db2 connect to sample

được phát ra từ bất kỳ máy khách nào, xác thực sẽ xảy ra trên máy khách đó. Nếu
lệnh
db2 connect to sample user test1 using password

được phát ra từ bất kỳ máy khách nào, thì xác thực sẽ xẩy ra trên máy chủ.


Cấu trúc chốt bảo mật của DB2
DB2 V8.2 giới thiệu khái niệm cấu trúc chốt bảo mật cho DB2. Khái niệm này nổi
bật nhiều tính năng trong DB2 V9.1. Dùng lệnh gọi chuẩn GSS-AIP, người dùng
có thể viết một chốt bảo mật và thông qua việc xác thực tài khoản người dùng tới
một chương trình bảo mật rõ ràng. Một ví dụ cho việc này chính là xác thực
KERBEROS của DB2. Khi bạn cài đặt DB2 ESE hoặc ứng dụng phát triển máy
khách trên một phần của máy, mã ứng dụng mẫu của cài đặt đó sẽ được đặt trong
thư mục thể hiện của bạn. Nếu bạn nhìn vào thư mục samples\security\plugins
bạn sẽ thấy trong các ví dụ này cách mã hoá các chốt bảo mật. Phần này sẽ phác
thảo cách dùng các chốt trong cấu trúc bảo mật DB2 nhưng không bao quát cách
mã hoá hoặc biên soạn chính các chốt. Để hiểu thêm chi tiết về vấn đề này hãy
xem Bảo mật DB2 phần 2: Hiểu về chốt bảo mật tổng quát DB2.


Xác thực Kerberos
Xác thực Kerberos cung cấp cho DB2 cách xác thực người dùng mà không cần gửi
tài khoản và mật khẩu người dùng trên mạng. Giao thức bảo mật Kerberos trình

bày xác thực như một dịch vụ xác thực thứ ba bằng việc sử dụng mật mã quy ước
để tạo ra khóa bí mật chia sẻ. Chìa khóa này sẽ trở thành chứng thư người dùng và
được dùng để kiểm tra lại nhận dạng của người dùng trong tất cả các trường hợp
mà dịch vụ cục bộ hoặc diện rộng được yêu cầu. Sử dụng giao thức xác thực
Kerberos cho phép người dùng đăng nhập vào một máy chủ cơ sở dữ liệu DB2 từ
xa.
Đầu tiên, hãy xem lại quá trình cài đặt DB2 để sử dụng xác thực Kerberos. Như đề
cập ở trên, xác thực Kerberos được cài đặt trên DB2, dùng cấu trúc chốt. Mã
nguồn cho chốt Kerberos mặc định được cung cấp trong thư mục
samples/security/plugins, gọi là IBMkrb5.c. Trước khi Kerberos làm việc cho
DB2, Kerberos phải được cho phép và hỗ trợ trên cả máy khách lẫn máy chủ. Để
thực hiện điều này, chúng ta phải có những điều kiện sau:
1. Máy khách và máy chủ phải thuộc về một phạm vi chung (tên miền tin cậy
trong thuật ngữ Windows).
2. Các nguyên tắc phù hợp phải được cài đặt (tài khoản người dùng trên
Kerberos).
3. Tệp keytab của máy chủ phải được tạo và đọc được bởi chính các thể hiện.
4. Tất cả các máy phải được đồng bộ hóa về thời gian.
Bạn có thể tìm thêm thông tin về cài đặt Kerberos trong tài liệu đi kèm với sản
phẩm cài đặt Kerberos.
Để cho phép DB2 sử dụng xác thực KERBEROS, trước tiên bạn phải chỉ cho máy
khách vị trí của chốt Kerberos mà bạn đang dùng. Trên máy khách bạn chạy lệnh
sau:
DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE


Trong ví dụ này, chốt Kerberos mặc định được sử dụng. Chốt Kerberos cũng có
thể được DBA thay đổi để trình bày các hàm đặc biệt nếu nó nhận được yêu cầu từ
Kerberos đang được sử dụng.

Chốt Kerberos cũng có khả năng báo cho máy khách biết chính xác nguyên tắc
máy chủ nào mà nó đang chứng minh ngược lại. Lựa chọn này là bước đầu tiên
của xác thực Kerberos khi máy khách phải tìm ra nguyên tắc máy chủ của các thể
hiện mà nó đang kết nối tới. Tham số AUTHENTICATION có thể được xác định
khi một danh mục có trong cơ sở dữ liệu trên máy khách. Định dạng của nó là:
DB2 CATALOG DB dbname AT NODE node name AUTHENTICATION
KERBEROS TARGET PRINCIPAL
service/host@REALM

Bước này mang tính lựa chọn.
DB2 CATALOG DB sample AT NODE testnd AUTHENTICATION
KERBEROS TARGET PRINCIPAL
gmilne/


Bước tiếp theo để cài đặt xác thực Kerberos là cài đặt máy chủ. Tham số
srvcon_gssplugin_list có thể được cài đặt cùng một danh sách các chốt GSS-API
khác nhau, nhưng bạn chỉ được phép có một chốt Kerberos. Nếu không có chốt
Kerberos nào trong danh sách thì chốt mặc định IBMkrb5 sẽ được dùng tự động.
Nếu bạn định cho phép tất cả các xác thực (cài đặt phần đính kèm cũng như kết
nối cơ sở dữ liệu) được sử dụng Kerberos, thực hiện như sau:
DB2 UPDATE DBM CFG USING AUTHENTICATION KERBEROS
hay
DB2 UPDATE DBM CFG USING AUTHENTICATION
KRB_SERVER_ENCRYPT


Nếu bạn chỉ muốn DB2 sử dụng xác thực kết nối cơ sở dữ liệu đầu vào (và sử
dụng SERVER các lệnh cài đặt đầu vào), điền theo lệnh sau:
DB2 UPDATE DBM CFG USING SVRCON_AUTH KERBEROS

hay
DB2 UPDATE DBM CFG USING SVRCON_AUTH
KRB_SERVER_ENCRYPT


Phụ thuộc vào độ rộng của bit (32 hoặc 64 bit) của thể hiện, DB2 sẽ tự động tải
IBMkrb5 khi thể hiện được bắt đầu.


Các cài đặt xác thực khác
Nếu bạn nhìn vào thể hiện của DBM CFG phiên bản 9.1, bạn sẽ nhìn thấy các cài
đặt khác nhau ảnh hưởng đến cách DB2 xác thực tài khoản người dùng. Như đã đề
cập ở trên có rất nhiều cài đặt cho xác thực tài khoản người dùng OS chuẩn
(CLIENT, SERVER, SERVER_ENCRYPT, DATA_ENCRYPT,
DATA_ENCRYPT_CMP), và các chốt để đưa xác thực tới chương trình mở rộng
(KERBEROS, KRB_SERVER_ENCRYPT, GSSPLUGIN,
GSS_SERVER_ENCRYPT). Phần này đặc biệt giải quyết một số biến cấu hình
mà có ảnh hưởng tới cách một người dùng được xác thực.
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

Trong bản danh sách trên, các tham số được đề cập tới đã được loại bỏ.
CLNT_PW_PLUGIN
Tham số này được xác định trên máy khách DBM

CFG. Nó cụ thể hóa tên của chốt máy khách được
dùng cho máy khách và xác thực cục bộ.
GROUP_PLUGIN
Mặc định cho giá trị này là rỗng (NULL). Cài đặt
GROUP_PLUGIN vào tên của chốt người dùng
được định nghĩa sẽ thể hiện ra rằng chốt cho tất cả
các bảng liệt kê nhóm thay vì phụ thuộc vào
nhóm tìm kiếm hệ điều hành. Điều này liên quan
chặt chẽ tới phần "quyền hạn" sẽ được thảo luận
chi tiết ở sau.
LOCAL_GSSPLUGIN
Tham số này xác định tên của thư viện chốt GSS
API mặc định được dùng cho mức độ thể hiện
quyền hạn cục bộ khi một giá trị của tham số cấu
hình quản lý cơ sở dữ liệu xác thực được cài đặt
trong GSSPLUGIN hoặc
GSS_SERVER_ENCRYPT.
SRV_PLUGIN_MODE
(YES/NO) Cài đặt mặc định cho tham số này là

×