Chuẩn bị cho kỳ thi 730 cơ bản về DB2 9, Phần 2: Các vấn đề về bảo mậ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™.

Graham G. Milne, Chuyên gia DB2, IBM Canada

Graham Milne, HBSc. - Khoa học máy tính, là một chuyên gia kỹ thuật cấp cao về DB2 và đã nghiên cứu về DB2 từ năm 1988. Hiện nay, Currently Graham là một giám đốc hỗ trợ giúp đỡ các khách hàng quan trọng. Trước khi làm công việc này, ông là tư vấn viên có thâm niên cho công tác hỗ trợ DB2 ở phòng thí nghiệm phần mềm của IBM tại Roronto



12 06 2009

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: http://www.ibm.com/certify/tests/.

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/Password Supplied?TRUST_ALLCLNTSTRUST_CLNTAUTHUntrusted Client Trusted Client Host Client
No YesCLIENTCLIENTCLIENTCLIENT
No YesSERVERCLIENTCLIENTCLIENT
No NoCLIENTSERVERCLIENTCLIENT
No NoSERVERSERVERCLIENTCLIENT
NoDRDAONLYCLIENTSERVERSERVERCLIENT
NoDRDAONLYSERVERSERVERSERVERCLIENT
Yes YesCLIENTCLIENTCLIENTCLIENT
Yes YesSERVERSERVERSERVERSERVER
Yes NoCLIENTSERVERCLIENTCLIENT
Yes NoSERVERSERVERSERVERSERVER
YesDRDAONLYCLIENTSERVERSERVERCLIENT
YesDRDAONLYSERVERSERVERSERVERSERVER

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/gmilne02.torolab.ibm.com@TOROLAB.IBM.COM

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_PLUGINTham 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_PLUGINMặ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_GSSPLUGINTham 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à NO. Khi chuyển sang YES, các chốt GSS-API được dùng thì sẽ được khởi tạo trong chế độ FENCED tương tự cách FENCED được lưu trữ tiến hành từng bước. Một chốt FENCED "đổ vỡ" (crash) không thể làm cho thể hiện DB2 cũng "đổ vỡ" theo. Trong khi các chốt khác triển khai nên chạy chúng trong chế độ fenced để những sai sót lôgic và bộ nhớ trong các chốt đó sẽ không là "đổ vỡ" các thể hiện. Một khi mà chốt được chỉ định là an toàn nó cần được chạy unfenced vì lý do trình bày.
SRVCON_GSSPLUGIN_LISTMột danh sách các chốt mà hệ quản trị cơ sở dữ liệu trên máy chủ sẽ dùng trong quá trình xác thực khi mà KERBEROS, KRB_SERVER_ENCRYPT, GSSPLUGIN hoặc GSS_SERVER_ENCRYPT được dùng. Mỗi chốt trong danh sách nên được ngăn cách bởi dấu phẩy (',') mà không có dấu cách ở giữa. Các chốt được lên danh sách theo thứ tự ưu tiên, chốt đứng đầu tiên trong danh sách được dùng đầu tiên để xác thực tài khoản và mật khẩu người dùng gửi tới. Chỉ khi tất cả các chốt trong danh sách báo về một lỗi, DB2 mới gửi xác thực lỗi tới người dùng.
SRVCON_PW_PLUGINTham số này cho phép người dùng thay đổi xác thực DB2 mặc định để kiểm tra lại tài khoản và mật khẩu của người dùng khi xác thực CLIENT, SERVER, hoặc SERVER_ENCRYPT được xác định. Mặc định giá trị của nó là rỗng và các phương thức DB2 mặc định được dùng.
CATALOG_NOAUTH(YES/NO) Mặc định NO. Thay đổi tham số này sang YES cho phép người dùng chưa được kiểm tra lại là thành viên của nhóm SYSADM, SYSCTRL, hoặc SYSMAINT thay đổi danh mục cơ sở dữ liệu, nút, Admin và DCS trên máy. Việc này chỉ có ích đối với tình huống máy khách nơi mà người dùng đăng nhập vào máy dùng một máy khách không đủ độ tin cậy (đã định nghĩa ở trên) hoặc đăng nhập với tài khoản người dùng không được phép kết nối với cơ sở dữ liệu hoặc đính kèm với thể hiện mà danh mục phải nhập trên máy khách.
FED_NOAUTHKhi "fed_noauth" được cài là YES, xác thực được cài lên máy chủ hoặc server_encrypt, và "federated" được cài là NO thì xác thực tại thể hiện sẽ bị bỏ qua. Và xác thực sẽ được cho là xảy ra tại gốc dữ liệu. Các thao tác cảnh báo khi "fed_noauth" được cài là YES. Xác thực không được thực hiện tại máy khách hay DB2. Bất kỳ người dùng nào biết tên xác thực SYSADM có thể cho rằng quyền hạn SYSADM dành cho các máy chủ liên kết.

Quyền hạn DB2

Giới thiệu về quyền hạn

Các quyền hạn DB2 kiểm soát các mặt sau trong một kế hoạch bảo mật cơ sở dữ liệu:

  • Mức độ quyền hạn mà người dùng được phép.
  • Các lệnh mà người dùng được thực hiện.
  • Các dữ liệu người dùng được đọc hoặc thay đổi.
  • Các đối tượng cơ sở dữ liệu người dùng được phép tạo ra, thay đổi hoặc loại bỏ.

Quyền hạn được hình thành bởi một nhóm các đặc quyền, quản lý cơ sở dữ liệu mức cao và các thao tác tiện ích (mức thể hiện). Trong năm quyền hạn có ở trong DB2, SYSADM, SYSCTRL, SYSMAINT, và SYSMON là các quyền hạn mức thể hiện (instance-level authorities). Điều này có nghĩa là phạm vi của chúng bao gồm các lệnh cũng như các lệnh ngược lại cơ sở dữ liệu trong thể hiện. Những quyền hạn này chỉ có thể gán cho một nhóm, bạn có thể thực hiện việc gán thông qua tệp DBM CFG.

Các quyền DBADM, LOAD, và SECADM được gán cho một người dùng hoặc một nhóm đối với các cơ sở dữ liệu riêng biệt. Điều này được thể hiện rõ ràng bằng lệnh GRANT.

Những phần sau đây sẽ mô tả cách mỗi quyền hạn được gán và lệnh nào người dùng có quyền hạn đó được phép trình bày. Lưu ý rằng bất kỳ tham chiếu nào tới từng thành viên của nhóm đều ngụ ý rằng người dùng hoặc tên nhóm đã được định nghĩa ở mức hệ điều hành.

Người dùng có thể chỉ định những quyền hạn nào và những đặc quyền mức dữ liệu mà họ có bằng cách phát ra lệnh sau:

db2 get authorizations

Khai thác quyền hạn SYSADM

Quyền hạn SYSADM trong DB2 có thể được so sánh với quyền hạn gốc trên UNIX hoặc quyền quản trị trên Window. Những người dùng có quyền hạn SYSADM đối với thể hiện DB2 có khả năng phát ra bất kỳ lệnh DB2 nào ngược lại với thể hiện, với bất kỳ cơ sở dữ liệu nào trong thể hiện, hay với bất kỳ đối tượng nào trong cơ sở dữ liệu. Họ cũng có khả năng truy cập dữ liệu trong cơ sở dữ liệu và có quyền thay đổi đặc quyền và quyền hạn. Chỉ duy nhất người dùng SYSADM được phép cập nhật tệp DBM CFG.

Quyền hạn SYSADM được kiểm soát trong tệp DBM CFG thông qua tham số SYSADM_GROUP. Khi thể hiện được tạo ra, tham số này được cài cho người quản trị trên Windows (mặc dù nó có thể bằng rỗng nếu bạn phát ra lệnh db2 get dbm cfg). Trên UNIX, tham số này được cài lên nhóm người dùng thấp nhất tạo ra thể hiện.

Vì người dùng SYSADM là người dùng duy nhất được phép cập nhật DBM CFG, họ cũng là người dùng duy nhất được phép cho bất kỳ nhóm nào khác quyền hạn. Ví dụ sau đây minh họa cách cho quyền SYSADM tới nhóm db2grp1:

 db2 update dbm cfg using SYSADM_GROUP db2grp1

Lưu ý rằng thay đổi này sẽ không ảnh hưởng cho đến khi thể hiện ngừng lại và bắt đầu lại. Cũng nhớ rằng nếu hiện tại bạn không đăng nhập như một thành viên của db2grp1, bạn không có quyền bắt đầu lại thể hiện! Bạn sẽ phải đăng xuất và sau đó đăng nhập lại bằng một tài khoản có ở trong nhóm, hoặc là thêm tài khoản hiện tại của bạn vào db2grp1.

Khai thác quyền hạn SYSCTRL

Người dùng có quyền hạn SYSCTRL có thể trình bày tất cả các lệnh quản trị và lưu giữ trong thể hiện. Tuy nhiên, không giống như người dùng SYSADM họ không thể truy cập bất kỳ dữ liệu nào trong cơ sở dữ liệu trừ khi họ được cho phép các đặc quyền thực hiện điều đó. Đây là các ví dụ các lệnh người dùng SYSCTRL có thể trình bày ngược lại bất kỳ cơ sở dữ liệu này trong thể hiện:

  • db2start/db2stop
  • db2 create/drop database
  • db2 create/drop tablespace
  • db2 backup/restore/rollforward database
  • db2 runstats (against any table)
  • db2 update db cfg for database dbname

Người dùng có quyền hạn SYSADM có thể gán SYSCTRL cho một nhóm, dùng lệnh sau:

db2 update dbm cfg using SYSCTRL_GROUP group name

Khai thác quyền hạn SYSMAINT

Các lệnh mà một người dùng có quyền hạn SYSMAINT có thể phát ra là một tập con của các lệnh mà người dùng có quyền hạn SYSCTRL được phép thực hiện. Người dùng SYSMAINT có thể trình bày các tác vụ có liên quan đến lưu giữ, như là:

  • db2start/db2stop
  • db2 backup/restore/rollforward database
  • db2 runstats (against any table)
  • db2 update db cfg for database dbname

Lưu ý rằng người dùng SYSMAINT không thể tạo hoặc xóa cơ sở dữ liệu hay bảng biểu. Họ không thể truy cập bất kỳ dữ liệu nào trong cơ sở dữ liệu trừ khi họ được cho các đặc quyền để thực hiện điều đó.

Nếu bạn có quyền hạn SYSADM, bạn có thể gán quyền của mình cho một nhóm sử dụng lệnh sau:

db2 update dbm cfg using SYSMAINT_GROUP group name

Khai thác quyền hạn SYSMON

Quyền hạn SYSMON cung cấp khả năng lấy hệ thống cơ sở dữ liệu lưu giữ hình ảnh hiển thị trên màn hình của một hiển thị quản lý cơ sở dữ liệu hoặc cơ sở dữ liệu của hình ảnh màn hình. Quyền hạn SYSMON được gán cho nhóm được xác định bởi tham số cấu hình sysmon_group. Nếu một nhóm được xác định, các thành viên trong nhóm đó sẽ được kiểm soát ngoài hệ quản trị cơ sở dữ liệu thông qua chế độ bảo mật sử dụng trong platform.

Các quyền hạn SYSMON cho phép người dùng thực thi các lệnh sau:

  • GET DATABASE MANAGER MONITOR SWITCHES
  • GET MONITOR SWITCHES
  • GET SNAPSHOT
  • LIST ACTIVE DATABASES
  • LIST APPLICATIONS
  • LIST DCS APPLICATIONS
  • RESET MONITOR
  • UPDATE MONITOR SWITCHES

Quyền hạn SYSMON cho phép người dùng sử dụng APIs như sau:

  • db2GetSnapshot - Lấy chụp nhanh (snapshot)
  • db2GetSnapshotSize - Ước lượng kích thước cần cho bộ đệm đầu ra của db2GetSnapshot()
  • db2MonitorSwitches - Chuyển chế độ giám sát Get/update
  • db2ResetMonitor - Đặt lại chế độ giám sát

Quyền hạn SYSMON cho phép người dùng tất cả các hàm bảng SQL hiển thị màn hình mà không phải chạy SYSPROC.SNAP_WRITE_FILE. SYSPROC.SNAP_WRITE_FILE, lấy hiển thị màn hình và lưu nội dung của nó vào một tệp. Nếu bất kỳ hàm bảng hiển thị màn hình được gọi với tham số nhập là rỗng, nội dung của tệp sẽ được gửi lại chứ không phải là một hiển thị màn hình hệ thống.

Người dùng với các mức quyền hạn SYSADM, SYSCTRL, hoặc SYSMAINT cũng sở hữu quyền hạn SYSMON.

Người dùng có quyền hạn SYSADM có thể gán SYSMON cho một nhóm người dùng theo lệnh sau:

db2 update dbm cfg using SYSMON_GROUP group name

Khai thác quyền hạn DBADM

Quyền hạn DBADM là là một quyền hạn mức dữ liệu chứ không phải quyền hạn mức thể hiện. Nói tóm lại, người dùng DBADM có quyền kiểm soát hoàn toàn đối với cơ sở dữ liệu. Người dùng DBADM không thể trình bày tác vụ quản trị hay lưu giữ như:

  • drop database
  • drop/create tablespace
  • backup/restore database
  • update db cfg for database db name

Tuy nhiên, họ có thể trình bày các tác vụ sau:

  • db2 create/drop table
  • db2 grant/revoke (mọi đặc quyền)
  • db2 runstats (mọi bảng)

Người dùng DBADM cũng được tự động cho phép tất cả các đặc quyền đối với các đối tượng cơ sở dữ liệu và nội dung của nó. Vì quyền hạn DBADM là quyền hạn mức cơ sở dữ liệu nên nó có thể được gán cho từng người dùng hoặc nhóm người dùng. Lệnh sau minh họa các cách khác nhau mà bạn có thể cho quyền hạn DBADM

  • db2 create database test

    Lệnh này cho người dùng có quyền hạn DBADM ngầm trên cơ sở dữ liệu có tên là test để thực thi lệnh.

  • db2 connect to sample
    db2 grant dbadm on database to user tst1

    Lệnh này chỉ được thực hiện bởi người dùng SYSADM, nó cho người dùng tst1 quyền hạn DBADM trên cơ sở dữ liệu mẫu. Chú ý rằng, người phát lệnh cần được kết nối với cơ sở dữ liệu mẫu trước khi cho quyền hạn DBADM.

  • db2 grant dbadm on database to group db2grp1

    Lệnh này cho tất cả người dùng trong nhóm db2grp1 quyền hạn DBADM. Và cũng chỉ người dùng SYSADM có thể thực thi lệnh đó.

Khai thác quyền hạn LOAD

Quyền hạn LOAD cũng được xem là quyền hạn mức cơ sở dữ liệu và do đó có thể được cấp cho cả người dùng và nhóm người dùng. Như tên gọi, quyền hạn LOAD cho phép người dùng thực thi lệnh LOAD ngược lại bảng. Lệnh LOAD được sử dụng đặc biệt như một thay thế để chèn hoặc nhập các lệnh khi hiển thị một bảng có nhiều dữ liệu. Tùy vào loại LOAD mà bạn muốn thực hiện, chỉ có mỗi quyền LOAD không thì không đủ. Các đặc quyền cụ thể trên bảng cũng rất cần thiết.

Lệnh sau có thể được thực hiện bởi người dùng có quyền hạn LOAD:

  • db2 quiesce tablespaces for table
  • db2 list tablespaces
  • db2 runstats (bảng bất kỳ)
  • db2 load insert (cần phải chèn các đặc quyền trên bảng)
  • db2 load restart/terminate after load insert (cần phải chèn các đặc quyền trên bảng)
  • db2 load replace (cần phải chèn và xóa các đặc quyền trên bảng)
  • db2 load restart/terminate after load replace (cần phải chèn và xóa các đặc quyền trên bảng)

Chỉ người dùng có quyền hạn SYSADM hoặc DBADM mới được phép cấp quyền hạn LOAD cho người dùng hoặc nhóm người dùng. Các ví dụ sau minh họa cách quyền hạn LOAD cho phép người dùng LOAD dữ liệu vào bảng có tên là sales. Giả sử câu lệnh db2 connect to sample được thực hiện.

  • db2 grant load on database to user tst1
    db2 grant insert on table sales to user tst1

    Với quyền hạn LOAD và các đặc quyền chèn, tst1 có thể thực hiện LOAD INSERT hoặc LOAD RESTART, hay TERMINATE sau một LOAD INSERT trong bảng sales.

  • db2 grant load on database to group grp1
    db2 grant delete on table sales to group grp1
    db2 grant insert on table sales to group grp1

    Với quyền hạn LOAD, cũng như các đặc quyền xóa và chèn, bất kỳ thành viên nào của grp1 có thể thực hiện LOAD REPLACE hoặc LOAD RESTART, hoặc TERMINATE sau một LOAD REPLACE bảng sales.

Khai thác quyền hạn SECADM

Quyền hạn được xem là quyền hạn mức cơ sở dữ liệu nhưng chỉ có thể cấp cho một người dùng cụ thể bằng một người dùng SYSADM. Một người dùng có SECADM có thể thực hiện các việc sau:

  • Tạo và xóa các thành phần nhãn bảo mật.
  • Tạo và xóa các chính sách bảo mật.
  • Tạo và xóa các nhãn bảo mật.
  • Cấp và rút lại các nhãn bảo mật.
  • Cấp và rút lại các miễn giảm quy tắc LBAC.
  • Cấp và rút lại các đặc quyền người dùng được phép.
  • Thực thi câu lệnh SQL TRANSFER OWNERSHIP trên đối tượng mà bạn không sở hữu.

Không có người dùng nào khác có thể trình bày các hàm này, thậm chí cả SYSADM, trừ khi SECADM được cấp rõ ràng cho người dùng SYSADM. Điều này rất quan trọng bởi vì những khả năng bảo mật này rất mạnh và chỉ nên cấp cho người dùng được định nghĩa là người quản trị việc bảo mật. Xem phần "Kiểm soát truy cập theo nhãn" để biết thêm chi tiết về đặc điểm bảo mật này mới đối với DB2 V9.


Các đặc quyền DB2

Cơ sở dữ liệu và các đặc quyền khác

Trong phần trước, khái niệm về đặc quyền cũng đã được giới thiệu ngắn gọn. Đặc quyền có thể chia làm hai loại chính: đặc quyền mức cơ sở dữ liệu trải rộng trên tất cả các đối tượng trong cơ sở dữ liệu, và đặc quyền mức đối tượng liên quan đến đối tượng cụ thể.

Đặc quyền mức cơ sở dữ liệu mà một người dùng có thể được cấp là:

  • CREATETAB: Người dùng có thể tạo các bảng trong cơ sở dữ liệu.
  • BINDADD: Người dùng có thể tạo các gói trong cơ sở dữ liệu bằng cách sử dụng lệnh BIND.
  • CONNECT: Người dùng có thể kết nối với cơ sở dữ liệu.
  • CREATE_NOT_FENCED: Người dùng có thể tạo ra các hàm unfenced do người dùng định nghĩa (UDFs).
  • IMPLICIT_SCHEMA: Người dùng có thể tạo các giản đồ trong cơ sở dữ liệu mà không sử dụng lệnh CREATE SCHEMA.
  • LOAD: Người dùng có thể tải dữ liệu vào trong bảng.
  • QUIESCE_CONNECT: Người dùng có thể truy cập một cơ sở dữ liệu khi nó ở trong tình trạng tĩnh.
  • CREATE_EXTERNAL_ROUTINE: Người dùng có thể tạo các bước cho người dùng sử dụng bằng các ứng dụng và các người dùng khác thì bằng cơ sở dữ liệu.

Các đối tượng cơ sở dữ liệu bao gồm: bảng, khung nhìn, chỉ mục, giản đồ, và gói. May mắn là hầu hết các đặc quyền mức đối tượng tự giải thích được. Bảng dưới đây tổng kết các đặc quyền này.

Tên đặc quyền Đối tượng tương đương Mô tả
CONTROL Bảng, Khung nhìn, Chỉ mục, Gói, Bí danh, Loại riêng biệt, Hàm người dùng định nghĩa, Chuỗi Cung cấp tất cả các quyền hạn đầy đủ trên đối tượng. Người dùng có đặc quyền này có thể cấp hoặc rút lại các đặc quyền trên đối tượng tới người dùng.
DELETE Bảng, Khung nhìn Cho phép người dùng xóa bản ghi từ đối tượng.
INSERT Bảng, Khung nhìn Cho phép người dùng chèn các bản ghi vào đối tượng thông qua lệnh INSERT hoặc IMPORT.
SELECT Bảng, Khung nhìn Cung cấp khả năng xem nội dung của đối tượng, sử dụng câu lệnh lựa chọn.
UPDATE Bảng, Khung nhìn Cho phép người dùng chỉnh sửa các bản ghi trong đối tượng, sử dụng câu lệnh cập nhật.
ALTER Bảng Cho phép người dùng thay đổi định nghĩa đối tượng, sử dụng câu lệnh chuyển đổi.
INDEX Bảng Cho phép người dùng tạo các chỉ mục trên đối tượng, sử dụng câu lệnh tạo chỉ mục.
REFERENCES Bảng Cung cấp khả năng tạo hoặc loại bỏ các chìa khóa miễn cưỡng trên đối tượng.
BIND Gói Cho phép người dùng kết nối lại các gói đã có.
EXECUTE Gói, Các bước, Hàm, Phương thức Cho phép người dùng loại bỏ các gói và các thường trình.
ALTERIN Giản đồ Cho phép người dùng sửa đổi định nghĩa đối tượng trong giản đồ.
CREATEIN Giản đồ Cho phép người dùng tạo các đối tượng trong giản đồ.
DROPIN Giản đồ Cho phép người dùng loại bỏ đối tượng trong giản đồ.

Thông tin trên các đặc quyền mức đối tượng được lưu giữ trong khung nhìn danh mục hệ thống. Tên khung nhìn là syscat.tabauth, syscat.colauth, syscat.indexauth, syscat.schemaauth, syscat.routineauth, và syscat.packageauth.

Các đặc quyền rõ ràng

Các đặc quyền có thể được cấp và rút lại rõ ràng đối với người dùng và nhóm người dùng, sử dụng lệnh GRANT và REVOKE. Hãy cùng xem thử bạn có thể dùng những lệnh này trên nhiều loại đối tượng như thế nào.

Khi đăng nhập như một người dùng có quyền quản trị trên Windows, đưa hai lệnh DB2 vào 2 cửa sổ. Đảm bảo rằng biến db2instance được cài DB2 trong cả hai cửa sổ!

Từ Cửa sổ 1, thực hiện lệnh sau:

db2 connect to sample

Bây giờ, từ Cửa sổ 2, thực hiện lệnh này:

db2 connect to sample user test1 using password

Hãy nhớ, các lệnh trong cửa sổ 1 được thực hiện bởi một người dùng có quyền hạn SYSADM. Lệnh trong cửa sổ 2 được thực hiện bởi tst1, một người dùng không có quyền hạn hay đặc quyền cụ thể trên một cơ sở dữ liệu mẫu. Lưu ý rằng tên giản đồ liên quan với bảng trong cơ sở dữ liệu mẫu sẽ là tên của người dùng thực hiện lệnh db2sampl. Trong những ví dụ như thế này, người dùng sẽ là GMILNE.

Bây giờ, từ cửa sổ 2, thực hiện lệnh sau:

db2 select * from gmilne.org

Bạn sẽ thấy đáp lại là:

SQL0551N  "TEST1" does not have the privilege to perform operation "SELECT" 
on object "GMILNE.ORG".

Để sửa chữa tình huống này, thực hiện lệnh sau từ cửa sổ 1:

db2 grant select on table gmilne.org to user test1

Bây giờ thì lệnh sẽ nhanh chóng thành công! Tiếp theo hãy thực hiện lệnh táo bạo hơn từ cửa sổ 2:

db2 insert into gmilne.org values (100, 'Tutorial', 1, 'Eastern', 'Toronto')

Và bạn sẽ thấy một thông báo lỗi:

SQL0551N  "TEST1" does not have the privilege to perform operation  "INSERT" 
on object "GMILNE.ORG"

Vì thế nhập lệnh sau vào cửa sổ 1:

db2 grant insert on table gmilne.org to group db2grp1

Lệnh INSERT thất bại sẽ nhanh chóng thành công bởi vì test1 là một thành viên của nhóm db2grp1.

Bây giờ hãy nhập lệnh sau vào cửa sổ 2:

db2 drop table gmilne.emp_photo

Và bạn sẽ thấy một thông báo lỗi:

SQL0551N  "TEST1" does not have the privilege to perform operation "DROP TABLE"
on object "GMILNE.EMP_PHOTO".

Vì thế chúng ta sẽ cấp lại đặc quyền đó. Nhập lệnh sau vào cửa sổ 1:

db2 grant dropin on schema gmilne to all

Bây giờ lệnh DROP TABLE mới có thể thực hiện thành công.

Bây giờ chúng ta đã hoàn thành ví dụ của mình, hãy rút lại tất cả các đặc quyền mà bạn đã cấp. Bạn thực hiện việc này bằng cách thực hiện các lệnh sau từ cửa sổ 1:

db2 revoke select on table gmilne.org from user test1
db2 revoke insert on table gmilne.org from group db2grp1
db2 revoke dropin on schema gmilne from all

Lưu ý là chỉ rút lại các đặc quyền của nhóm, không cần rút lại nó từ tất cả các thành viên của nhóm đó. Ví dụ, lệnh sau có thể được dùng để rút lại tất cả các đặc quyền (trừ CONTROL) từ db2grp1 trên bảng gmilne.org:

db2 revoke all on table gmilne.org from group db2grp1

Tuy nhiên, người dùng test1 (là một thành viên của db2grp1) có thể đã giữ những đặc quyền trên bảng đó vì người đó đã được cấp đặc quyền đó trực tiếp.

Các đặc quyền ngầm

DB2 có thể cấp các đặc quyền một cách tự động khi các lệnh được thực hiện mà không cần thực hiện lệnh GRANT như bạn vừa thấy. Bảng dưới đây tổng kết một số lệnh có kết quả trong các đặc quyền do hệ quản trị dữ liệu cấp ngầm. Lưu ý là những đặc quyền này bị rút lại ngầm khi đối tượng được tạo bị loại bỏ. Tuy nhiên chúng không bị rút lại khi các đặc quyền mức cao bị rút lại.

Lệnh được thực thi Đặc quyền được cấp Người được cấp
CREATE TABLE mytable CONTROL trên mytable Lệnh người dùng thực hiện
CREATE SCHEMA myschema CREATEIN, ALTERIN, DROPIN trên myschema, thêm khả năng cung cấp các đặc quyền này tới người dùng khác Lệnh người dùng thực hiện
CREATE VIEW myview CONTROL trên myview chỉ khi CONTROL được giữ trên bảng và khung nhìn được tham chiếu trong định nghĩa của myview Lệnh người dùng thực hiện
CREATE DATABASE mydb SELECT trên bảng danh mục hệ thống của mydb, IMPLICIT_SCHEMA trên mydb * PUBLIC**

*Khi người dùng tạo một cơ sở dữ liệu, người dùng đó đã cấp ẩn quyền hạn DBADM trên cơ sở dữ liệu đó. Với quyền hạn từ các đặc quyền ẩn CONNECT, CREATETAB, BINDADD, IMPLICIT_SCHEMA, và CREATE_NOT_FENCED. Những đặc quyền này sẽ tồn tại cùng người dùng thậm chí cả khi quyền hạn DBADM bị rút lại.

**PUBLIC là một nhóm DB2 đặc biệt bao gồm tất cả các dữ liệu riêng biệt. Không giống như các nhóm chúng ta đã thảo luận, PUBLIC không phải định nghĩa tại mức hệ điều hành. Có một số các đặc quyền được mặc định cấp cho PUBLIC. Ví dụ, nhóm này nhận được đặc quyền CONNECT trên cơ sở dữ liệu và đặc quyền SELECT trên các bảng danh mục một cách tự động. Lệnh GRANT và REVOKE có thể được cấp ngược với nhóm PUBLIC, tương tự như sau:

db2 grant select on table sysibm.systables to public
db2 revoke select on table sysibm.systables from public

Các đặc quyền gián tiếp

Có thể có các đặc quyền một cách gián tiếp khi các gói được thực hiện bởi hệ điều hành cơ sở dữ liệu. Một gói bao gồm một hoặc nhiều câu lệnh SQL được chuyển sang định dạng mà DB2 loại bỏ chúng từ bên trong. Nói cách khác, một gói bao gồm các câu lệnh trong một định dạng có thể thực hiện được. Nếu tất cả các câu lệnh trong gói là tĩnh thì người dùng chỉ có thể yêu cầu đặc quyền EXECUTE trên gói thực hiện thành công câu lệnh trong gói.

Ví dụ, giả sử db2package1 thực hiện các câu lệnh SQL tĩnh sau:

db2 select * from org
db2 insert into test values (1, 2, 3)

Trong trường hợp này, một người dùng có đặc quyền EXECUTE trên db2package1 có thể được cấp gián tiếp quyền SELECT trên bảng hoặc đặc quyền INSERT trên bảng kiểm tra.

Kiểm soát truy cập theo nhãn (Label-based access control)

Điểm mới trên DB2 9 là thuật ngữ kiểm soát truy cập theo nhãn (LBAC). LBAC cung cấp cho DBA khả năng đặc quyền hạn chế đọc/ viết trên mức hàng và cột của một bảng.

Trước đây, cách duy nhất để giới thiệu những hạn chế này là tạo ra khung nhìn, quyền hạn sử dụng khung nhìn thông qua các câu hỏi của người dùng và loại bỏ truy cập tới bảng gốc.

Bài viết này chỉ đề cập đến một ví dụ của tình huống bảo mật LBAC. Để đọc thêm các giải thích về LBAC, hãy xem Kiểm soát truy cập DB2 theo nhãn, hướng dẫn thực hành, Phần 1: Hiểu cơ bản về LBAC trong DB2 trên developerWorks.

LBAC được thiết lập bởi người quản trị bảo mật bằng việc tạo ra các chính sách bảo mật. Mỗi bảng có thể chứa chỉ một chính sách bảo mật nhưng hệ thống có thể có nhiều chính sách bảo mật nếu bạn muốn. Có vài bước cần thiết để thiết lập LBAC. Điều đầu tiên bạn cần làm là chỉ định loại kiểm soát truy cập bạn yêu cầu đối với dữ liệu của bạn.

Hãy giả định như sau. Trong tổ chức của bạn có ba người.

TênNhiệm vụ trong tổ chức
JaneQuản lý nhân sự
JoeGiám đốc phòng D11 và E21
FrankĐội trưởng-Phòng A00

Bây giờ, trong cơ sở dữ liệu tổ chức có một bảng định nghĩa các thông tin của nhân viên. Bảng này sẽ không lấy cơ sở dữ liệu mẫu SAMPLE trong bảng EMP. Định nghĩa đã có của nó là như sau:

				db2 => describe select * from emp

SQLDA Information

 sqldaid : SQLDA     sqldabc: 896  sqln: 20  sqld: 14

 Column Information

 sqltype               sqllen  sqlname.data                    sqlname.length
 --------------------  ------  ------------------------------  --------------
 452   CHARACTER            6  EMPNO                                        5
 448   VARCHAR             12  FIRSTNME                                     8
 453   CHARACTER            1  MIDINIT                                      7
 448   VARCHAR             15  LASTNAME                                     8
 453   CHARACTER            3  WORKDEPT                                     8
 453   CHARACTER            4  PHONENO                                      7
 385   DATE                10  HIREDATE                                     8
 453   CHARACTER            8  JOB                                          3
 500   SMALLINT             2  EDLEVEL                                      7
 453   CHARACTER            1  SEX                                          3
 385   DATE                10  BIRTHDATE                                    9
 485   DECIMAL           9, 2  SALARY                                       6
 485   DECIMAL           9, 2  BONUS                                        5
 485   DECIMAL           9, 2  COMM                                         4

Tổ chức có quy tắc là kiểm toán dựa trên các nền tảng thông thường. Một phần của kiểm toán này chỉ ra rằng các nhân viên không nên có quyền truy cập dữ liệu thực sự bí mật. Quy tắc này quy định rằng các quản lý có quyền truy cập đọc và viết đối với tất cả các bản ghi của nhân viên. Giám đốc có quyền truy cập đọc và viết đối với tất cả các nhận viên trong phòng. Và đội trưởng có truyền truy cập đối với bất kỳ ai trong đội mà họ đứng đầu.

Để thiết lập bảo mật LBAC để các quy tắc này hoạt động

  1. Định nghĩa các chính sách bảo mật và nhãn, và cấp nhãn bảo mật cho các người dùng.
  2. Thay đổi bảng EMP bao gồm phân cột nhãn bảo mật và đưa chính sách bảo mật vào.

Định nghĩa các chính sách bảo mật và nhãn.

Để định nghĩa các chính sách bảo mật và nhãn cần phải có quyền hạn SECADM.

Bước 1a. Tạo thành phần nhãn bảo mật.

Điều đầu tiên bạn cần làm là chỉ định loại thành phần bảo mật để định nghĩa chính sách này. Trong trường hợp này, hợp lý nhất là loại chính sách "TREE". Một cây chính sách nghĩa là bạn có thể định nghĩa một tổ hợp các nhãn như là nhánh cây có các tập hợp con quyền lợi mà nhánh cha phải làm. Trong ví dụ này, tạo một thành phần bảo mật đặt tên là "J_DEPT".

			CREATE SECURITY LABEL COMPONENT J_DEPT
        TREE ('HR_EXECUTIVE' ROOT,
              'MAN_D11_E21' UNDER 'HR_EXECUTIVE'
              'A00' UNDER 'HR_EXECUTIVE',
              'B01' UNDER 'HR_EXECUTIVE',
              'C01' UNDER 'HR_EXECUTIVE',
              'D11' UNDER 'MAN_D11_E21',
              'D21' UNDER 'HR_EXECUTIVE',
              'E01' UNDER 'HR_EXECUTIVE',
              'E11' UNDER 'HR_EXECUTIVE',
              'E21' UNDER 'MAN_D11_E21'
        )

Dàn ý trên chỉ ra rằng gốc cây chính là HR_EXECUTIVE, và tất cả các phòng, ban là tập con dưới mức quản lý đó.

Bước 1b. Định nghĩa chính sách bảo mật

Bước tiếp theo yêu cầu dùng bảo mật LBAC trong ví dụ trên để định nghĩa chính sách liên quan đến thành phần nhãn bảo mật ở trên.

      	CREATE SECURITY POLICY J_DEPT_POLICY
             COMPONENTS J_DEPT
             WITH DB2LBACRULES
             RESTRICT NOT AUTHORIZED WRITE SECURITY LABEL

Bước 1c. Tạo các nhãn bảo mật

Bước thứ ba trong cài đặt chính sách bảo mật là tạo các nhãn bảo mật. Đây là nơi bạn sẽ xác định các nhiệm vụ khác mà mỗi người dùng có. Trong trường hợp này, vì ví dụ khá đơn giản, chỉ có ba nhãn: Quản lý, Giám đốc và Đội trưởng.

      CREATE SECURITY LABEL J_DEPT_POLICY.EXECUTIVE
             COMPONENT J_DEPT 'HR_EXECUTIVE'
             
      CREATE SECURITY LABEL J_DEPT_POLICY.MANAGE_D11_E21
             COMPONENT J_DEPT 'MAN_D11_E21'
             
      CREATE SECURITY LABEL J_DEPT_POLICY.A00
             COMPONENT J_DEPT 'A00'
             
      CREATE SECURITY LABEL J_DEPT_POLICY.B01
             COMPONENT J_DEPT 'B01'
             
      CREATE SECURITY LABEL J_DEPT_POLICY.C01
             COMPONENT J_DEPT 'C01'

      CREATE SECURITY LABEL J_DEPT_POLICY.D11
             COMPONENT J_DEPT 'D11'

      CREATE SECURITY LABEL J_DEPT_POLICY.D21
             COMPONENT J_DEPT 'D21'

      CREATE SECURITY LABEL J_DEPT_POLICY.E01
             COMPONENT J_DEPT 'E01'

      CREATE SECURITY LABEL J_DEPT_POLICY.E11
             COMPONENT J_DEPT 'E11'

      CREATE SECURITY LABEL J_DEPT_POLICY.E21
             COMPONENT J_DEPT 'E21'

Trong bước tiếp theo bạn sẽ định nghĩa các quyền thực tế liên quan đến những nhãn này.

Bước 1d. Cấp quyền cho các nhãn

Các bước sau phác thảo các bước cấp quyền cho dữ liệu bảng. Quyền có thể là ALL ACCESS, WRITE ACCESS hoặc READ ACCESS. Nếu không có quyền nào được cấp cho người dùng thì người dùng đó sẽ không có khả năng truy cập bất kỳ dữ liệu nào. Nhớ là các quản lý có quyền truy cập cao nhất, giám đốc có quyền truy cập cao nhất trong phòng của họ và các đội trưởng có quyền truy cập tới tất cả các thành viên trong phòng mà họ quản lý.

db2 grant security label J_DEPT_POLICY.A00 to user Frank for read access
db2 grant security label J_DEPT_POLICY.MANAGE_D11_E21 to user Joe for all access
db2 grant security label J_DEPT_POLICY.EXECUTIVE to user Jane for all access

Dán các nhãn trên vào người dùng sẽ xếp tầng các quyền truy cập dựa theo các định nghĩa trong bước 1a. Bởi vì người dùng Joe có nhãn là MANAGE_D11_E21, và được cung cấp tất cả các quyền, người đó sẽ có thể đọc và viết các hàng có đuôi bảo mật của J_DEPT_POLICY.D11 hoặc J_DEPT_POLICY.E21 (vì đó là các tập con của anh ta).

Bước 2: Chỉnh sửa bảng EMP

Khi chỉnh sửa bảng EMP bạn phải tạo một cột phụ để lưu nhãn bảo mật. Đây là loại "DB2SECURITYLABEL". Bạn sẽ chỉnh sửa bảng EMP đã có trong cơ sở dữ liệu SAMPLE. Để thực hiện điều này bạn phải dùng một người dùng được cấp mức đặc quyền gốc trong chính sách, vì thế trong trường hợp này người dùng đo là Jane. Bạn cũng phải loại bỏ MQT ra khỏi bảng ADEFUSR từ cơ sở dữ liệu mẫu.

CONNECT TO SAMPLE

   Database Connection Information

 Database server        = DB2/NT 9.1.0
 SQL authorization ID   = GMILNE
 Local database alias   = SAMPLE  

DROP TABLE ADEFUSR

CONNECT RESET

CONNECT TO SAMPLE USER Jane USING password

ALTER TABLE EMP
		ADD COLUMN DEPT_TAG DB2SECURITYLABEL
		ADD SECURITY POLICY J_DEPT_POLICY

Nếu bạn chọn bảng EMP, bạn sẽ nhìn thấy cột phụ được định nghĩa. Bởi vì bạn trình bày các sửa đổi bằng một định nghĩa người dùng trên mức EXECUTIVE, tất cả các đuôi bảo mật đều phải được thêm như là EXECUTIVE. Để thay đổi điều này bạn cần cập nhật bảng.

db2 => select EMPNO, FIRSTNME, LASTNAME, WORKDEPT, SALARY, 
varchar(SECLABEL_TO_CHAR('J_DEPT_POLICY',DEPT_TAG),30) from gmilne.emp

EMPNO  FIRSTNME     LASTNAME        WORKDEPT SALARY      6
------ ------------ --------------- -------- ----------- ------------------------------
000010 CHRISTINE    HAAS            A00        152750.00 HR_EXECUTIVE
000020 MICHAEL      THOMPSON        B01         94250.00 HR_EXECUTIVE
000030 SALLY        KWAN            C01         98250.00 HR_EXECUTIVE
000050 JOHN         GEYER           E01         80175.00 HR_EXECUTIVE
000060 IRVING       STERN           D11         72250.00 HR_EXECUTIVE
000070 EVA          PULASKI         D21         96170.00 HR_EXECUTIVE
000090 EILEEN       HENDERSON       E11         89750.00 HR_EXECUTIVE
000100 THEODORE     SPENSER         E21         86150.00 HR_EXECUTIVE
000110 VINCENZO     LUCCHESSI       A00         66500.00 HR_EXECUTIVE
000120 SEAN         O'CONNELL       A00         49250.00 HR_EXECUTIVE
000130 DELORES      QUINTANA        C01         73800.00 HR_EXECUTIVE
000140 HEATHER      NICHOLLS        C01         68420.00 HR_EXECUTIVE
000150 BRUCE        ADAMSON         D11         55280.00 HR_EXECUTIVE
000160 ELIZABETH    PIANKA          D11         62250.00 HR_EXECUTIVE
000170 MASATOSHI    YOSHIMURA       D11         44680.00 HR_EXECUTIVE
000180 MARILYN      SCOUTTEN        D11         51340.00 HR_EXECUTIVE
000190 JAMES        WALKER          D11         50450.00 HR_EXECUTIVE
000200 DAVID        BROWN           D11         57740.00 HR_EXECUTIVE
000210 WILLIAM      JONES           D11         68270.00 HR_EXECUTIVE
000220 JENNIFER     LUTZ            D11         49840.00 HR_EXECUTIVE
000230 JAMES        JEFFERSON       D21         42180.00 HR_EXECUTIVE
000240 SALVATORE    MARINO          D21         48760.00 HR_EXECUTIVE
000250 DANIEL       SMITH           D21         49180.00 HR_EXECUTIVE
000260 SYBIL        JOHNSON         D21         47250.00 HR_EXECUTIVE
000270 MARIA        PEREZ           D21         37380.00 HR_EXECUTIVE
000280 ETHEL        SCHNEIDER       E11         36250.00 HR_EXECUTIVE
000290 JOHN         PARKER          E11         35340.00 HR_EXECUTIVE
000300 PHILIP       SMITH           E11         37750.00 HR_EXECUTIVE
000310 MAUDE        SETRIGHT        E11         35900.00 HR_EXECUTIVE
000320 RAMLAL       MEHTA           E21         39950.00 HR_EXECUTIVE
000330 WING         LEE             E21         45370.00 HR_EXECUTIVE
000340 JASON        GOUNOT          E21         43840.00 HR_EXECUTIVE
200010 DIAN         HEMMINGER       A00         46500.00 HR_EXECUTIVE
200120 GREG         ORLANDO         A00         39250.00 HR_EXECUTIVE
200140 KIM          NATZ            C01         68420.00 HR_EXECUTIVE
200170 KIYOSHI      YAMAMOTO        D11         64680.00 HR_EXECUTIVE
200220 REBA         JOHN            D11         69840.00 HR_EXECUTIVE
200240 ROBERT       MONTEVERDE      D21         37760.00 HR_EXECUTIVE
200280 EILEEN       SCHWARTZ        E11         46250.00 HR_EXECUTIVE
200310 MICHELLE     SPRINGER        E11         35900.00 HR_EXECUTIVE
200330 HELENA       WONG            E21         35370.00 HR_EXECUTIVE
200340 ROY          ALONZO          E21         31840.00 HR_EXECUTIVE

  42 record(s) selected.

update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','A00')) where WORKDEPT='A00'

update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','B01')) where WORKDEPT='B01'

update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','C01')) where WORKDEPT='C01'

update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','D11')) where WORKDEPT='D11'

update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','D21')) where WORKDEPT='D21'

update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','E01')) where WORKDEPT='E01'

update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','E11')) where WORKDEPT='E11'

update emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','E21')) where WORKDEPT='E21'

db2 => select EMPNO, FIRSTNME, LASTNAME, WORKDEPT, SALARY, 
varchar(SECLABEL_TO_CHAR('J_DEPT_POLICY',DEPT_TAG),30) from emp

EMPNO  FIRSTNME     LASTNAME        WORKDEPT SALARY      6
------ ------------ --------------- -------- ----------- ------------------------------
000010 CHRISTINE    HAAS            A00        152750.00 A00
000020 MICHAEL      THOMPSON        B01         94250.00 B01
000030 SALLY        KWAN            C01         98250.00 C01
000050 JOHN         GEYER           E01         80175.00 E01
000060 IRVING       STERN           D11         72250.00 D11
000070 EVA          PULASKI         D21         96170.00 D21
000090 EILEEN       HENDERSON       E11         89750.00 E11
000100 THEODORE     SPENSER         E21         86150.00 E21
000110 VINCENZO     LUCCHESSI       A00         66500.00 A00
000120 SEAN         O'CONNELL       A00         49250.00 A00
000130 DELORES      QUINTANA        C01         73800.00 C01
000140 HEATHER      NICHOLLS        C01         68420.00 C01
000150 BRUCE        ADAMSON         D11         55280.00 D11
000160 ELIZABETH    PIANKA          D11         62250.00 D11
000170 MASATOSHI    YOSHIMURA       D11         44680.00 D11
000180 MARILYN      SCOUTTEN        D11         51340.00 D11
000190 JAMES        WALKER          D11         50450.00 D11
000200 DAVID        BROWN           D11         57740.00 D11
000210 WILLIAM      JONES           D11         68270.00 D11
000220 JENNIFER     LUTZ            D11         49840.00 D11
000230 JAMES        JEFFERSON       D21         42180.00 D21
000240 SALVATORE    MARINO          D21         48760.00 D21
000250 DANIEL       SMITH           D21         49180.00 D21
000260 SYBIL        JOHNSON         D21         47250.00 D21
000270 MARIA        PEREZ           D21         37380.00 D21
000280 ETHEL        SCHNEIDER       E11         36250.00 E11
000290 JOHN         PARKER          E11         35340.00 E11
000300 PHILIP       SMITH           E11         37750.00 E11
000310 MAUDE        SETRIGHT        E11         35900.00 E11
000320 RAMLAL       MEHTA           E21         39950.00 E21
000330 WING         LEE             E21         45370.00 E21
000340 JASON        GOUNOT          E21         43840.00 E21
200010 DIAN         HEMMINGER       A00         46500.00 A00
200120 GREG         ORLANDO         A00         39250.00 A00
200140 KIM          NATZ            C01         68420.00 C01
200170 KIYOSHI      YAMAMOTO        D11         64680.00 D11
200220 REBA         JOHN            D11         69840.00 D11
200240 ROBERT       MONTEVERDE      D21         37760.00 D21
200280 EILEEN       SCHWARTZ        E11         46250.00 E11
200310 MICHELLE     SPRINGER        E11         35900.00 E11
200330 HELENA       WONG            E21         35370.00 E21
200340 ROY          ALONZO          E21         31840.00 E21

  42 record(s) selected.

Sau khi bạn cập nhật, hãy xem từng người dùng riêng lẻ có thể thực hiện được điều gì. Bạn sẽ kết nối với cơ sở dữ liệu bằng cách sử dụng mật khẩu người dùng quản trị Jane. Bắt đầu bằng một câu lệnh lựa chọn tương tự được trình bày trước đây:

db2 => select EMPNO, FIRSTNME, LASTNAME, WORKDEPT, SALARY, 
varchar(SECLABEL_TO_CHAR('J_DEPT_POLICY',DEPT_TAG),30) from gmilne.emp

EMPNO  FIRSTNME     LASTNAME        WORKDEPT SALARY      6
------ ------------ --------------- -------- ----------- ------------------------------
000010 CHRISTINE    HAAS            A00        152750.00 A00
000020 MICHAEL      THOMPSON        B01         94250.00 B01
000030 SALLY        KWAN            C01         98250.00 C01
000050 JOHN         GEYER           E01         80175.00 E01
000060 IRVING       STERN           D11         72250.00 D11
000070 EVA          PULASKI         D21         96170.00 D21
000090 EILEEN       HENDERSON       E11         89750.00 E11
000100 THEODORE     SPENSER         E21         86150.00 E21
000110 VINCENZO     LUCCHESSI       A00         66500.00 A00
000120 SEAN         O'CONNELL       A00         49250.00 A00
000130 DELORES      QUINTANA        C01         73800.00 C01
000140 HEATHER      NICHOLLS        C01         68420.00 C01
000150 BRUCE        ADAMSON         D11         55280.00 D11
000160 ELIZABETH    PIANKA          D11         62250.00 D11
000170 MASATOSHI    YOSHIMURA       D11         44680.00 D11
000180 MARILYN      SCOUTTEN        D11         51340.00 D11
000190 JAMES        WALKER          D11         50450.00 D11
000200 DAVID        BROWN           D11         57740.00 D11
000210 WILLIAM      JONES           D11         68270.00 D11
000220 JENNIFER     LUTZ            D11         49840.00 D11
000230 JAMES        JEFFERSON       D21         42180.00 D21
000240 SALVATORE    MARINO          D21         48760.00 D21
000250 DANIEL       SMITH           D21         49180.00 D21
000260 SYBIL        JOHNSON         D21         47250.00 D21
000270 MARIA        PEREZ           D21         37380.00 D21
000280 ETHEL        SCHNEIDER       E11         36250.00 E11
000290 JOHN         PARKER          E11         35340.00 E11
000300 PHILIP       SMITH           E11         37750.00 E11
000310 MAUDE        SETRIGHT        E11         35900.00 E11
000320 RAMLAL       MEHTA           E21         39950.00 E21
000330 WING         LEE             E21         45370.00 E21
000340 JASON        GOUNOT          E21         43840.00 E21
200010 DIAN         HEMMINGER       A00         46500.00 A00
200120 GREG         ORLANDO         A00         39250.00 A00
200140 KIM          NATZ            C01         68420.00 C01
200170 KIYOSHI      YAMAMOTO        D11         64680.00 D11
200220 REBA         JOHN            D11         69840.00 D11
200240 ROBERT       MONTEVERDE      D21         37760.00 D21
200280 EILEEN       SCHWARTZ        E11         46250.00 E11
200310 MICHELLE     SPRINGER        E11         35900.00 E11
200330 HELENA       WONG            E21         35370.00 E21
200340 ROY          ALONZO          E21         31840.00 E21

  42 record(s) selected.

Và lệnh cập nhật:

db2 => update gmilne.emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','E01')) 
where WORKDEPT='E01' DB20000I  The SQL command completed successfully.

Bạn có thể thấy, Jane có quyền cập nhật cao nhất đối với tất cả các dữ liệu có trong bảng. Bây giờ hãy xem Joe có thể nhìn thấy những gì. Đầu tiên lại chọn.

db2 => select EMPNO, FIRSTNME, LASTNAME, WORKDEPT, SALARY, 
varchar(SECLABEL_TO_CHAR('J_DEPT_POLICY',DEPT_TAG),30) from gmilne.emp

EMPNO  FIRSTNME     LASTNAME        WORKDEPT SALARY      6
------ ------------ --------------- -------- ----------- ------------------------------
000060 IRVING       STERN           D11         72250.00 D11
000100 THEODORE     SPENSER         E21         86150.00 E21
000150 BRUCE        ADAMSON         D11         55280.00 D11
000160 ELIZABETH    PIANKA          D11         62250.00 D11
000170 MASATOSHI    YOSHIMURA       D11         44680.00 D11
000180 MARILYN      SCOUTTEN        D11         51340.00 D11
000190 JAMES        WALKER          D11         50450.00 D11
000200 DAVID        BROWN           D11         57740.00 D11
000210 WILLIAM      JONES           D11         68270.00 D11
000220 JENNIFER     LUTZ            D11         49840.00 D11
000320 RAMLAL       MEHTA           E21         39950.00 E21
000330 WING         LEE             E21         45370.00 E21
000340 JASON        GOUNOT          E21         43840.00 E21
200170 KIYOSHI      YAMAMOTO        D11         64680.00 D11
200220 REBA         JOHN            D11         69840.00 D11
200330 HELENA       WONG            E21         35370.00 E21
200340 ROY          ALONZO          E21         31840.00 E21

  17 record(s) selected.

Ta thấy rằng anh ta chỉ nhình thấy những thông tin từ phòng D11 và E21. Hãy xem điều gì xảy ra khi anh ta cố chọn thông tin ở trong bảng mà anh ta không được quyền nhìn thấy:

db2 => select EMPNO, FIRSTNME, LASTNAME, WORKDEPT, SALARY, 
varchar(SECLABEL_TO_CHAR('J_DEPT_POLICY',DEPT_TAG),30) 
from gmilne.emp where empno='000130'

EMPNO  FIRSTNME     LASTNAME        WORKDEPT SALARY      6
------ ------------ --------------- -------- ----------- ------------------------------

  0 record(s) selected.

Bạn đã biết từ lựa chọn trước khi làm ví dụ với Jane là có một nhân viên có mã số nhân viên 000130, nhưng Joe lại không được phép nhìn thấy thông tin này.

Bây giờ, một kiểm tra cuối cùng với Frank.

Đầu tiên, chọn tương tự như hai người dùng trên:

db2 => select EMPNO, FIRSTNME, LASTNAME, WORKDEPT, SALARY, 
varchar(SECLABEL_TO_CHAR('J_DEPT_POLICY',DEPT_TAG),30) from gmilne.emp

EMPNO  FIRSTNME     LASTNAME        WORKDEPT SALARY      6
------ ------------ --------------- -------- ----------- ------------------------------
000010 CHRISTINE    HAAS            A00        152750.00 A00
000110 VINCENZO     LUCCHESSI       A00         66500.00 A00
000120 SEAN         O'CONNELL       A00         49250.00 A00
200010 DIAN         HEMMINGER       A00         46500.00 A00
200120 GREG         ORLANDO         A00         39250.00 A00

  5 record(s) selected.

Trong trường hợp này bạn có thể thấy Frank chỉ có thể nhìn thấy thông tin về những người dùng trong văn phòng mà anh ta quản lý. Hãy xem điều gì xảy ra khi anh ta cố cập nhật:

db2 => update gmilne.emp set DEPT_TAG=(SECLABEL_BY_NAME('J_DEPT_POLICY','A00')) 
where WORKDEPT='A00'DB21034E  The command was processed as an SQL statement 
because it was not a valid Command Line Processor command.  During SQL processing it 
returned:
SQL20402N Authorization ID "FRANK" does not have the LBAC credentials to
perform the "UPDATE" operation on table "EMPLOYEE".  SQLSTATE=42519

Mặc dù anh ta cố cập nhật một bản ghi trong văn phòng của anh ta, bạn đã tạo bảo mật truy cập của anh ta là chỉ được phép đọc trên bảng. Như vậy việc chúng ta làm hoàn toàn thỏa mãn.


Tổng kết

Bạn đã đọc xong bài viết này, bạn hẳn đã có những hiểu biết về những chủ đề sau:

Các thành phần của một kế hoạch bảo mật DB2: Bạn cần hiểu cấu trúc của toàn bộ môi trường DB2 bao gồm máy khách, máy chủ, cổng vào ra và máy chủ lưu trữ. Bạn cũng cần hiểu về xác thực, quyền hạn và các đặc quyền.

Các loại xác thực DB2: Bạn cần phải biết cách cài đặt các loại xác thực bằng việc dùng lệnh db2 update dbm cfg using authentication type trên máy chủ, và sử dụng lệnh db2 catalog database trên cổng vào ra và máy khách.

Các quyền hạn DB2: Bạn cần hiểu những kiến thức nền tảng về các quyền hạn SYSADM, SYSCTRL, SYSMAINT, và SYSMON được cài trên tệp DBM CSG. Bạn cũng cần hiểu những điểm cơ bản về các quyền hạn DBADM, LOAD, và SECADM, được cài bằng việc sử dụng lệnh GRANT và rút lại bằng việc sử dụng lệnh REVOKE. Hơn nữa, bạn nên biết lệnh nào cho mỗi quyền hạn được phép thực hiện.

Các đặc quyền DB2: Bạn cần hiểu các loại đặc quyền khác nhau và các đặc quyền đó cho phép người dùng làm gì. Ví dụ, CONTROL, INSERT, DELETE, CREATEIN, DROPIN, REFERENCES, và SELECT. Bạn cũng biết cách cấp và rút lại đặc quyền dứt khoát (GRANT/REVOKE), ẩn (chỉ dành cho các gói), và gián tiếp. Hơn nữa bạn cũng đã có kiến thức cơ bản về kiểm soát truy cập theo nhãn, và cách định nghĩa các loại chính sách khác nhau dựa trên khái niệm bảo mật mới này.

Để truy cập bài viết khác trong loạt bài này, đánh dấu loạt bài loạt bài chuẩn bị cho bài thi 731 của DB2 9 DBA.

Tài nguyên

Học tập

Lấy sản phẩm và công nghệ

  • Tải miễn phí phiên bản thử nghiệm của DB2 9.
  • Tải DB2 Express-C, một phiên bản miễn phí của DB2 Express Edition, nó có những đặc tính, chức năng cơ bản giống như DB2 Express Edition và cung cấp nền tảng vững chắc cho việc xây dựng và triển khai ứng dụng.

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Information Management
ArticleID=396432
ArticleTitle=Chuẩn bị cho kỳ thi 730 cơ bản về DB2 9, Phần 2: Các vấn đề về bảo mật
publish-date=06122009