ĐÁNH GIÁ QUYỀN NGƯỜI DÙNG TRÊN TÀI KHOẢN CSDL VÀ BÁO CÁO QUYỀN TRUY CẬP CSDL TRÊN ORACLE VÀ MICROSOFT SQL SERVER QUA IBM GUARDIUM
PHẦN 1: TỔNG QUAN VÀ MỤC TIÊU
1.1. Mục tiêu bài Lab
Thông qua tính năng Database Entitlement Reports của IBM Guardium, bài thực nghiệm nhằm xác định và đánh giá chính xác quyền hạn (privilege/role) mà từng tài khoản người dùng đang sở hữu trên hệ quản trị cơ sở dữ liệu Oracle và Microsoft SQL Server, phục vụ công tác rà soát quyền định kỳ (entitlement review) và bảo đảm nguyên tắc cấp quyền tối thiểu (least privilege).1.2. Nguyên lý hoạt động
Khác với lab Active Threat Analytics — dựa trên dữ liệu hoạt động do S-TAP thu thập theo thời gian thực, tính năng Entitlement Reports không cần S-TAP.Guardium kết nối trực tiếp (JDBC/ODBC) đến CSDL bằng một tài khoản kỹ thuật (service account) chỉ có quyền đọc catalog hệ thống, để lấy "ảnh chụp" (snapshot) toàn bộ user, role và quyền hạn tại một thời điểm.
Cơ chế báo cáo sử dụng tính năng Custom Domain của Guardium để liên kết dữ liệu quyền lấy trực tiếp từ CSDL với các report Entitlement dựng sẵn (predefined).
Mỗi lần chạy "Upload Data" sẽ tạo ra một snapshot mới, cho phép so sánh quyền hạn giữa các thời điểm để phát hiện thay đổi bất thường.
1.3. Các Report chính cần thu thập
Trên Oracle: quyền hệ thống/role gán cho user (kể cả kế thừa qua role), object mà PUBLIC có quyền truy cập, tài khoản có quyền SYSDBA/SYSOPER.Trên Microsoft SQL Server: role/quyền hệ thống gán cho user và role (kèm cờ WITH GRANT OPTION), tài khoản thuộc nhóm db_owner/db_securityadmin, tài khoản có quyền sysadmin/serveradmin/securityadmin, object mà PUBLIC có quyền truy cập.
PHẦN 2: MÔ HÌNH THỰC NGHIỆM VÀ CẤU HÌNH HỆ THỐNG
2.1. Sơ đồ luồng thực hiện
2.2. Các bước cấu hình tiền đề trên Guardium
Bước 1: Tạo tài khoản kỹ thuật tối thiểu quyền: Trên Oracle và MSSQL, tạo một DB account riêng chỉ có quyền SELECT trên các view hệ thống chứa thông tin phân quyền:Oracle cần quyền trên DBA_TAB_PRIVS, DBA_ROLE_PRIVS, DBA_SYS_PRIVS, DBA_USERS, DBA_COL_PRIV S;
MSSQL cần quyền trên sys.database_permissions, sys.database_principals, sys.server_principals, sys.database_role_members.
Đây là tài khoản Guardium dùng để "read" quyền, không phải tài khoản S-TAP.
Bước 2: Tải script cấp quyền mẫu từ Guardium:
Trên Guardium CLI (SSH, user guardcli1), chạy lệnh fileserver <IP> <thời gian> để bật file server tạm thời.
Mở trình duyệt tới https://<IP_guardium>:8445, vào thư mục log/debug-logs/gdmmonitor_scripts/ để tải script grant tương ứng cho Oracle và MSSQL.
Lựa chọn script phù hợp với DB Server:
Bước 3: Tạo Datasource Definition cho từng CSDL:
Vào Setup > Tools and Views > Datasource Definitions, tạo một datasource riêng cho Oracle và một cho MSSQL: khai báo IP, port, tên DB/service, và tài khoản kỹ thuật ở Bước 1.
Nhấn Test Connection để xác nhận kết nối thành công.
Kết quả kết nối 2 DB thành công
Bước 4: Chọn Entitlement Domain và cấu hình Data Upload:
Vào Report > Report Configuration Tools > Custom Table Builder, chọn domain Entitlement tương ứng cho các kịch bản
Với mỗi report muốn dùng, bấm Upload Data, sau đó Add Datasource để gắn datasource đã tạo ở Bước 3.
Bước 5: Chạy Upload Data lần đầu để lấy snapshot: Bấm "Run Once Now" để Guardium kết nối và lấy snapshot quyền đầu tiên. Có thể cấu hình thêm lịch chạy định kỳ (khuyến nghị 6-24 giờ/lần cho môi trường lab).
PHẦN 3: THỰC HIỆN CHI TIẾT THEO TỪNG KỊCH BẢN
3.1. Kịch bản 1: Cấp quyền mới trên Oracle
A. Mục tiêu và Kịch bản mô phỏng: Mô phỏng DBA cấp thêm quyền SELECT trên bảng RETAIL.EMPLOYEE cho một user để kiểm tra khả năng ghi nhận thay đổi quyền của Entitlement Report.B. Các bước thực hiện:
Bước 1: Trên Oracle, thực thi lệnh cấp quyền:
Bước 2: Thực hiện cấu hình Upload Data của report "ORA object privileges", bấm "Run Once Now" để tạo snapshot mới.
Bước 3: Mở report, lọc theo user, so sánh 2 mốc thời gian (snapshot) để xác nhận quyền SELECT trên RETAIL.EMPLOYEE đã xuất hiện.
C. Kết luận và Đánh giá kịch bản 1: Nếu quyền mới xuất hiện đúng ở snapshot sau thời điểm GRANT, Entitlement Report đã ghi nhận chính xác sự thay đổi phân quyền, cho phép đối chiếu với quy trình change management (đã GRANT đúng thẩm quyền/đúng phê duyệt hay chưa).
3.2. Kịch bản 2: Gán quyền sysadmin trên MSSQL
A. Mục tiêu và Kịch bản mô phỏng: Mô phỏng một user MSSQL được (vô tình or cố ý) gán vào server role sysadmin, quyền cao nhất trên instance để kiểm tra khả năng cảnh báo của report.B. Các bước thực hiện:
Bước 1: Trên MSSQL, thực thi lệnh gán role:
Bước 2: Chạy lại Upload Data cho report "Account of sys/server/security admin".
*Lưu ý: report này chỉ trả kết quả đúng khi datasource trỏ vào database master.
Bước 3: Mở report, xác nhận guard_reader xuất hiện trong danh sách tài khoản có quyền sysadmin.
C. Kết luận và Đánh giá kịch bản 2: Đây là dấu hiệu rủi ro cao nhất cần ưu tiên điều tra/cảnh báo ngay, vì tài khoản sysadmin có toàn quyền trên server MSSQL.
3.3. Kịch bản 3: Thu hồi quyền (REVOKE) trên Oracle
A. Mục tiêu và Kịch bản mô phỏng: Mô phỏng thu hồi một role đã cấp trước đó, kiểm tra Entitlement Report có phản ánh đúng trạng thái quyền hiện tại (không chỉ cộng dồn lịch sử).B. Các bước thực hiện:
Bước 1: Trên Oracle, thực thi lệnh thu hồi role:
REVOKE HR_ANALYST_ROLE FROM USER_B;
Bước 2: Chạy lại Upload Data cho report "ORA roles granted".
[Chèn ảnh chụp màn hình: chạy lại Upload Data sau khi REVOKE]
Bước 3: Mở report, lọc theo mốc thời gian mới nhất, xác nhận role HR_ANALYST_ROLE không còn xuất hiện với USER_B.
[Chèn ảnh chụp màn hình: report "ORA roles granted" sau khi REVOKE]
C. Kết luận và Đánh giá kịch bản 3: Snapshot mới nhất phản ánh đúng trạng thái quyền hiện hành; các snapshot cũ vẫn được lưu lại, phục vụ điều tra/forensics khi cần đối chiếu quyền tại một thời điểm quá khứ.
3.4. Kịch bản 4: Rà soát object mà PUBLIC có quyền truy cập
A. Mục tiêu và Kịch bản mô phỏng: Rà soát toàn hệ thống để tìm các object (bảng/view) đang cấp quyền cho PUBLIC, một cấu hình rủi ro cao vì mọi user hợp lệ trên CSDL đều có thể truy cập.B. Các bước thực hiện:
Bước 1: Chạy lại Upload Data cho report "Object Access By PUBLIC" lần lượt cho SQL Server.
Bước 2: Mở report Microsoft SQL server object access by public" (MSSQL).
Bước 3: Lọc/loại trừ các object hệ thống mặc định, chỉ giữ lại các object nghiệp vụ (như schema FINANCE).
Kết quả sau khi lọc: (hệ thống mặc định k cho lọc, còn clone mới thì nó không có danh sách trong phần upload data)
Bước 4: Đối chiếu danh sách với chính sách bảo mật dữ liệu nội bộ để xác định object nào cần thu hồi quyền PUBLIC. (hiện tại với môi trường lab thì chưa thể thực hiện được bước này do thiếu dữ liệu nội bộ thật)
C. Kết luận và Lưu ý kỹ thuật: Entitlement Report chỉ phản ánh quyền tại thời điểm snapshot gần nhất; nếu quyền được cấp và thu hồi giữa hai lần Upload Data, sự kiện đó sẽ không được ghi nhận. Vì vậy với các hệ thống có yêu cầu audit chặt chẽ, nên kết hợp thêm chính sách Policy giám sát các lệnh GRANT/REVOKE theo thời gian thực, thay vì chỉ dựa vào Entitlement Report.
PHẦN 4: PHÂN TÍCH TỔNG HỢP VÀ KẾT LUẬN
4.1. Bảng tổng hợp các Report chính đã sử dụng
| Hệ thống | Tên Report (Guardium) | Ý nghĩa |
| Oracle | ORA roles granted | Role được cấp cho user/role, kể cả kế thừa |
| Oracle | ORA system privileges granted | Quyền hệ thống cấp cho user/role |
| Oracle | ORA SYSDBA and SYSOPER accounts | Tài khoản có quyền quản trị cao nhất |
| MSSQL | Role/system privileges granted to user and role | Role, quyền hệ thống gán cho user/role |
| MSSQL | Database accounts of db_owner and db_securityadmin role | Tài khoản sở hữu/toàn quyền trên database |
| MSSQL | Account with sysadmin, server admin, security admin | Tài khoản có quyền cao nhất trên instance |
| MSSQL | Object access by public | Object mà PUBLIC có quyền truy cập |
4.2. Kết luận
Thông qua việc kết nối trực tiếp và định kỳ lấy snapshot dữ liệu phân quyền từ Oracle và Microsoft SQL Server, tính năng Database Entitlement Reports của IBM Guardium cho phép tổ chức xác định chính xác ai đang có quyền gì, trên đối tượng nào, do ai cấp, phục vụ trực tiếp cho công tác rà soát quyền định kỳ, tuân thủ nguyên tắc cấp quyền tối thiểu, và là bằng chứng đối chiếu quan trọng khi kết hợp với các lab giám sát hoạt động thời gian thực (Active Threat Analytics, Change Audit) đã thực hiện trước đó.
Sửa lần cuối: