Tài liệu An toàn DB2 UDB, Phần 2: Hiểu các trình cắm thêm an toàn của DB2 cho Linux, UNIX và Windows

An toàn DB2 UDB, Phần 2: Hiểu các trình cắm thêm an

toàn của DB2 cho Linux, UNIX và Windows

Các trình cắm thêm an toàn DB2 — Bức tranh tổng thể

Các trình cắm thêm an toàn là các thư viện có thể tải một cách động mà DB2 gọi ra khi thực hiện

xác thực hoặc tra tìm thành viên nhóm cho người dùng. Trước phiên bản 8.2, một phương tiện

bên ngoài thay cho DB2 đã quản lý các hoạt động này, ví dụ như hệ điều hành, một bộ điều

khiển miền, hoặc một hệ thống an toàn Kerberos. Hình 1 cung cấp các kịch bản minh họa cách

an toàn DB2 đã làm việc trước phiên bản 8.2. Các phần tiếp theo mô tả những gì đã thay đổi với

phiên bản 8.2.

Hình 1. Các kịch bản an toàn

Hình 1 minh họa bốn kịch bản an toàn:

1. Các cân nhắc về an toàn khi kết nối với một cơ sở dữ liệu từ một hệ thống máy

khách đến một hệ thống máy chủ

Ở phía bên trái của Hình 1, một người dùng đã ban hành câu lệnh connect to mydb

user raul using raulpsw (kết nối với người dùng mydb là raul bằng cách sử dụng

raulpsw) từ cửa sổ Bộ xử lý dòng lệnh (CLP) của một hệ thống máy khách DB2 để kết

nối với cơ sở dữ liệu mydb, lưu trú trên máy chủ DB2 Aries. Máy khách DB2 giao tiếp

với máy chủ và thỏa thuận sử dụng phương thức xác thực nào. Để đơn giản, chúng ta hãy

giả sử máy khách sử dụng phương thức xác thực do máy chủ trả về. Trong hình này,

AUTHENTICATION được thiết lập cho SERVER. Điều này có nghĩa là hệ điều hành

máy chủ (I) sẽ thực hiện xác thực bằng cách kiểm tra xem ID và mật khẩu người dùng đã

cấp có phù hợp theo các giá trị được lưu trữ trong cơ sở dữ liệu an toàn của hệ điều hành

không. Một khi người dùng được xác thực, DB2 sẽ lấy thông tin thành viên nhóm từ hệ

điều hành. Từ thời điểm tiếp theo, DB2 sẽ không còn sử dụng ID hoặc mật khẩu người

dùng cho bất kỳ việc kiểm tra nào nữa, thay vào đó, DB2 sẽ sử dụng ID ủy quyền

(authID). Nói chung, một authID là phiên bản chữ hoa của một ID người dùng.

2. Các cân nhắc về an toàn khi thực hiện các câu lệnh SQL sau khi kết nối vào cơ sở

dữ liệu

Phần dưới cùng bên trái của Hình 1 cho thấy một câu lệnh SELECT được ban hành trong

lúc đã kết nối với cơ sở dữ liệu mydb bằng authID là RAUL. Trong trường hợp này,

phương tiện chức năng an toàn DB2 bên trong thực hiện kiểm tra ủy quyền bằng cách

xem lại các bảng Catalog của DB2 để xác nhận rằng authID RAUL đã được cấp đặc quyền

SELECT từ bảng KEVIN.TABLE1. Nếu authID RAUL và PUBLIC (công khai) vẫn chưa

được cấp đặc quyền này, DB2 sẽ kiểm tra xem người dùng này có là một phần của một

trong các nhóm đặc biệt như SYSADM, SYSCTRL, SYSMAINT hoặc SYSMON không.

Có các tham số (dbm cfg) cấu hình của trình quản lý cơ sở dữ liệu cho mỗi nhóm, và bạn

có thể thiết lập các tham số này tới giá trị của một nhóm hệ điều hành. Vào lúc kết nối,

thông tin nhóm về người dùng được lấy ra từ hệ điều hành và lưu trữ trong bộ nhớ nhanh.

Sau đó DB2 sẽ kiểm tra xem authID RAUL có là một phần của một trong các nhóm này

không bằng cách xem lại dữ liệu (II) đã lưu trong bộ nhớ nhanh này. Ví dụ, nếu authID là

một phần của nhóm SYSADM, câu lệnh SELECT có thể tiếp tục, ngược lại sẽ trả về một

thông báo lỗi (SQLCODE -551).

3. Các cân nhắc về an toàn khi thực hiện an toàn tại máy khách

Nếu AUTHENTICATION đã được thiết lập tới CLIENT trong Hình 1, hệ điều hành ở

máy tính khách này sẽ thực hiện xác thực (III). Việc kiểm tra ủy quyền với câu lệnh

SELECT sẽ được thực hiện như trước: DB2 sẽ xác minh xem authID RAUL có đặc quyền

SELECT với bảng KEVIN.TABLE1 trong các bảng cơ sở dữ liệu DB2 Catalog không. Nếu

authID RAUL và PUBLIC không có đặc quyền này, thì thực hiện kiểm tra thành viên

nhóm. Vào lúc kết nối, thông tin thành viên nhóm từ máy khách được chuyển đến và lưu

trữ trong bộ nhớ nhanh tại máy chủ.

4. Các cân nhắc về an toàn khi ban hành các lệnh mức cá thể

Tại máy chủ trong Hình 1, chủ sở hữu cá thể DB2 là db2inst1 đưa ra lệnh db2stop. DB2

kiểm tra xem người dùng đã đăng nhập hiện tại có thuộc nhóm được định nghĩa trong

SYSADM_GROUP, SYSCTRL_GROUP, hoặc SYSMAINT_GROUP (IV) không. Nếu

ID người dùng thuộc về bất kỳ một trong các nhóm này, lệnh db2stop sẽ thực hiện thành

công. Nếu không, sẽ trả về một thông báo lỗi. Tùy thuộc vào hoạt động mức cá thể, người

dùng có thể là một phần của các nhóm SYSADM, SYSCTRL, SYSMAINT hoặc

SYSMON.

Trong mỗi kịch bản, hệ điều hành được gọi để thực hiện các việc kiểm tra an toàn. Bắt đầu với

phiên bản 8.2, có thể sử dụng các trình cắm thêm an toàn trong mỗi tình huống này. Thay vì luôn

gọi hệ điều hành, có thể gọi một trình cắm thêm máy chủ và nhóm trong kịch bản 1, có thể gọi

một trình cắm thêm nhóm trong kịch bản 2, và có thể gọi các trình cắm thêm máy khách và

nhóm trong kịch bản 3 và 4.

Ví dụ này giới thiệu ba thể loại trình cắm thêm an toàn:

 Trình cắm thêm an toàn xác thực phía máy chủ (trình cắm thêm xác thực phía máy chủ).

 Trình cắm thêm an toàn xác thực phía máy khách (trình cắm thêm xác thực phía máy

khách).

 Trình cắm thêm an toàn tra tìm thành viên nhóm (trình cắm thêm nhóm).

Trình cắm thêm xác thực máy chủ thực hiện xác thực trên máy chủ cơ sở dữ liệu. Nó cũng được

sử dụng để kiểm tra xem trình cắm thêm có biết authID không. Ví dụ, hãy xem xét câu lệnh SQL

grant select on table user1.t1 to FOO, (cấp chọn trên bảng user1.t1 cho FOO), ở đây

DB2 không biết liệu FOO có là một người dùng hoặc nhóm không. Trong trường hợp này, DB2

tra cứu tất cả các trình cắm thêm phía máy chủ và các trình cắm thêm thành viên nhóm để kiểm

tra xem FOO có là một người dùng, một nhóm, không rõ, hoặc cả hai không, để nó có thể đáp

ứng cho phù hợp với câu lệnh SQL.

Trình cắm thêm xác thực máy khách thực hiện xác thực trên máy khách. Nó cũng được dùng để

thực hiện xác thực cục bộ mức cá thể trên máy chủ cơ sở dữ liệu khi thực hiện các lệnh mức cá

thể (chẳng hạn như db2start, db2stop, db2trc, update dbm cfg, và v.v..) Vì vậy, phổ biến là

xem cả hai trình cắm thêm xác thực máy khách và trình cắm thêm xác thực máy chủ được chỉ rõ

trên một máy chủ cơ sở dữ liệu.

Trình cắm thêm nhóm thực hiện tra tìm thành viên nhóm trên cả máy khách lẫn máy chủ cơ sở

dữ liệu. Nó cũng được dùng để kiểm tra xem trình cắm thêm có biết authID không.

Mỗi trình cắm thêm an toàn có chứa một tập các API mà bạn cần thực hiện. DB2 cung cấp cơ sở

hạ tầng của trình cắm thêm an toàn và một số trình cắm thêm an toàn mặc định. Để dành việc

thực hiện trình cắm thêm an toàn tùy chỉnh cho bạn tự quyết định.

Về đầu trang

Các ưu điểm của việc sử dụng trình cắm thêm an toàn

Các ưu điểm chính của việc sử dụng cơ chế an toàn mới của DB2 là tính linh hoạt và tính mở

rộng mà các trình cắm thêm an toàn có thể cung cấp. Bạn có thể tùy chỉnh các cơ chế an toàn để

đáp ứng các nhu cầu cá nhân của bạn, thay vì dựa vào một phương tiện chức năng tiêu chuẩn như

hệ điều hành. Ví dụ, trước phiên bản 8.2, bất kỳ người dùng hệ điều hành nào đã đăng nhập vào

hệ thống đều có thể ban hành một câu lệnh kết nối mà không cần vượt qua kiểm tra ID và mật

khẩu người dùng (được gọi là một kết nối ngầm định), và giả sử ID người dùng có đặc quyền

CONNECT của DB2, thì anh ta có thể kết nối thành công. Với các trình cắm thêm, bạn có thể

thay đổi hành vi này sao cho không cho phép kết nối ngầm định.

LDAP là một ví dụ khác. LDAP hiện không được hỗ trợ như là một phương thức xác thực trong

DB2; tuy nhiên, bạn luôn có thể thực hiện nó bằng cách sử dụng một trình cắm thêm an toàn.

Một ví dụ đơn giản được trình bày sau trong bài viết này, khi sử dụng Microsoft Active

Directory (Thư mục tích cực của Microsoft) để thực hiện xác thực dựa trên LDAP.

Các trình cắm thêm an toàn được thực hiện cho mỗi cá thể, do đó bạn có thể tạo ra các cá thể

khác nhau, và có các công cụ trình cắm thêm an toàn khác nhau. Hình 2 cho thấy tính linh hoạt

và tính mở rộng được cung cấp bằng cách sử dụng các trình cắm thêm an toàn.