QUẢN LÝ QUYỀN TRUY CẬP THEO NGUYÊN TẮC PHÂN TÁCH NHIỆM VỤ TRÊN ORACLE DATABASE VÀ MICROSOFT SQL SERVER
1. Mục tiêu
- Tách nhiệm vụ trên Guardium giữa quản trị hệ thống (admin), quản lý tài khoản (accessmgr), cấu hình chính sách giám sát (sec_officer) và kiểm toán (auditor_ora, auditor_mss).
- Cấp các mức quyền khác nhau theo chức năng (ứng dụng, báo cáo, menu) và theo dữ liệu (kiểm toán viên chỉ thấy CSDL mình phụ trách).
- Chứng minh DBA có toàn quyền trên Oracle, SQL Server nhưng không xóa được vết kiểm toán trên Guardium; việc dừng S-TAP bị phát hiện.
- Kiểm soát và ghi lại thao tác của chính người quản trị Guardium.
2. Nguyên lý hoạt động
Phân tách nhiệm vụ (Separation of Duties, SoD) yêu cầu người thực hiện, người cấp quyền và người kiểm tra là những người khác nhau, để một cá nhân không thể vừa làm sai vừa xóa dấu vết. Guardium áp dụng nguyên tắc này ở các lớp sau:
Lớp | Cơ chế trên Guardium | Kịch bản |
| Tài khoản đặc biệt | admin quản trị hệ thống nhưng không quản lý được user; accessmgr tạo user, role, gán quyền nhưng không cấu hình giám sát. Hai role này không gán chung cho một user | KB5 |
| Chức năng | Role do accessmgr tạo: Manage Permissions quyết định ứng dụng, report được dùng; Customize Navigation Menu quyết định menu hiển thị | KB1, KB2 |
| Đối tượng | Policy, group, query tự tạo mặc định không cấp cho role nào (No Roles); chủ sở hữu hoặc admin cấp cho role cần dùng | Mục 3.5 |
| Dữ liệu | Data Level Security: user chỉ thấy dữ liệu của máy chủ được gán; role datasec-exempt xem được toàn bộ | KB3 |
| Hạ tầng | S-TAP gửi dữ liệu về Collector ngay khi thu được; Collector là appliance đóng gói, DBA không có tài khoản trên đó | KB4 |
| Giám sát người quản trị | User Activity Audit Trail, System/Security Activities, Guardium Logins ghi thao tác của tài khoản Guardium | KB5 |
- Tài liệu IBM ghi role tự tạo không được ghép với role mặc định, nhưng lab vẫn gán được admin cùng role_secofficer (KB5). Role mới nhận sẵn mọi ứng dụng cấp cho All Roles (Policy Builder, Group Builder, Audit Process Builder…), nên role hạn chế phải gỡ hết rồi thêm lại đúng ứng dụng cần.
- Ẩn mục khỏi menu không thu hồi quyền; chỉ Manage Permissions mới chặn được (KB2).
- Data Level Security chỉ lọc domain Access, Exception, Policy Violations; report về hoạt động của tài khoản Guardium không bị lọc. Không bật đồng thời với Investigation Dashboard.
Hình 1: Nguyên lý phân tách nhiệm vụ và kiểm soát quyền truy cập trên Guardium
3. Cấu hình
3.1. Chuẩn bị
Giao diện Guardium ở https://<IP_GUARDIUM>:8443. Các cửa sổ ẩn danh của cùng một trình duyệt dùng chung phiên, nên mỗi tài khoản dùng một trình duyệt hoặc chế độ riêng: admin trên Chrome, accessmgr trên Chrome ẩn danh, sec_officer trên Edge, kiểm toán viên trên Edge InPrivate.
Bước 1: Đăng nhập admin, kiểm tra S-TAP của oracledb01, SQLDB01 xanh trong Manage → Activity Monitoring → S-TAP Control. Mở Protect → Security Policies → Policy Installation, ghi lại các policy đang cài theo đúng thứ tự. Trong lab đang cài năm policy:
1 POL_AUDIT_DB_CHANGESBước 1: Đăng nhập admin, kiểm tra S-TAP của oracledb01, SQLDB01 xanh trong Manage → Activity Monitoring → S-TAP Control. Mở Protect → Security Policies → Policy Installation, ghi lại các policy đang cài theo đúng thứ tự. Trong lab đang cài năm policy:
2 POL_RT_ACCESS_ALERT
3 POL_NET_LOCAL_CONTROL
4 POL_PROTECT_SENSITIVE_DATA
5 POL_BASIC_DATA_SECURITY
Hình 2: Thứ tự policy đang cài
Bước 2: Mở Setup → Tools and Views → Global Profile, kiểm tra Data level security filtering đang tắt (nút Enable). Trang này không có mục Investigation Dashboard nên không bị xung đột khi bật ở KB3.
Bước 3: Đăng nhập accessmgr, kiểm tra có menu Access → Access Management.
Bước 3: Đăng nhập accessmgr, kiểm tra có menu Access → Access Management.
- accessmgr đăng nhập bằng mật khẩu mặc định đặt lúc cài appliance. Nếu tài khoản bị khóa, SSH bằng cli và chạy unlock accessmgr.
Hình 3: Giao diện quản lý người dùng của accessmgr
3.2. Tạo group và báo cáo cho kiểm toán
Bước 1: Đăng nhập admin, truy cập Setup → Tools and Views → Group Builder, nhấn + và tạo group (Application type = Public):
Tên group | Group Type | Thành viên |
| GRP_SOD_DBA_USERS | Users | SYS, SYSTEM, SA, SQLDB01\ADMINISTRATOR |
Hình 4: Group GRP_SOD_DBA_USERS
Bước 2: Truy cập Reports → Report Configuration Tools → Query-Report Builder, tạo hai query:
Query | Domain; Main Entity; điều kiện | Cột |
| Q_SOD_VIOLATIONS | Policy Violations; Policy Rule Violation; DB User Name NOT LIKE NT SERVICE%, sắp xếp Timestamp giảm dần | Timestamp, Category Name, Access Rule Description, Severity Description, Server IP, Client IP, DB User Name, Full SQL String |
| Q_SOD_DBA_ACTIVITY | Access; SQL; DB User Name IN GROUP GRP_SOD_DBA_USERS, sắp xếp Session Start giảm dần | Session Start, Server IP, Client IP, Network Protocol, DB User Name, OS User, Source Program, Sql |
- Q_SOD_VIOLATIONS chọn Main entity = Policy Rule Violation; Main entity không đổi được sau khi tạo query. Điều kiện NOT LIKE NT SERVICE% bỏ cảnh báo nhiễu của tài khoản dịch vụ NT SERVICE\SQLTELEMETRY mà POL_NET_LOCAL_CONTROL đang cài trong lab sinh 5 phút một lần.
- Q_SOD_DBA_ACTIVITY đọc cột Sql nên có mọi câu S-TAP gửi về của DBA, không phụ thuộc rule.
Hình 5: Hai query Q_SOD_VIOLATIONS và Q_SOD_DBA_ACTIVITY
3.3. Tạo role role_secofficer và role_auditor
Bước 1: Đăng nhập accessmgr, truy cập Access → Access Management → Role Browser, nhấn Add Role, lần lượt tạo role_secofficer và role_auditor.
Hình 6: Hai role mới trong Role Browser
Bước 2: Ở dòng từng role nhấn Manage Permissions. Với ô chọn đầu hộp thoại là Guardium Applications: tích ô tiêu đề của Accessible items, nhấn mũi tên sang trái để chuyển hết sang Inaccessible items, sau đó dùng Filter tìm và chuyển lại các mục theo bảng. Đổi ô chọn sang Reports và làm tương tự. Nhấn OK.
Role | Guardium Applications | Reports |
| role_secofficer | Policy Builder, Policy Install, Installed Policy Viewer, Group Builder, S-Tap Management, Stap Reporting, Stap Verification, Report Builder | Policy Violations, S-TAP Status Monitor, Inactive S-TAPs Since, S-TAP Events |
| role_auditor | Report Builder, Results Viewing, Audit Process To-Do List | Q_SOD_VIOLATIONS, Q_SOD_DBA_ACTIVITY, Inactive S-TAPs Since, User Activity Audit Trail, System/Security Activities, Guardium Logins, All Roles - Application Access |
- Report Builder bắt buộc để mở được report. role_auditor không có Query Builder nên không tạo, sửa được query.
- role_secofficer không có Global Profile, System Configuration, Support, Audit Process To-Do List: đó là việc của admin và của kiểm toán. Không cấp System Configuration, Support cho role này để tách hẳn quản trị hệ thống.
Hình 7: Ứng dụng và report được cấp cho role_secofficer
Hình 8: Ứng dụng và report được cấp cho role_auditor
Bước 3: Ở dòng role_auditor nhấn Customize Navigation Menu. Trong Navigation Menu xóa mọi nhóm trừ Welcome, nhấn + tạo nhóm Audit Reports. Chọn nhóm này, ở Available Tools and Reports tích Audit Process To-Do List và các report của role_auditor, nhấn mũi tên để thêm, rồi nhấn OK. Trang chủ giữ là Welcome.
Hình 9: Navigation Menu của role_auditor
3.4. Tạo tài khoản và gán role
Bước 1: Truy cập Access → Access Management → User Browser, nhấn Add User và tạo ba tài khoản. Mật khẩu tạm tối thiểu 8 ký tự, có chữ hoa, chữ thường, chữ số và ký tự đặc biệt; giữ ô Disabled đang tích, nhấn Add User.
User name | Role | Mật khẩu tạm | Nhiệm vụ |
| sec_officer | role_secofficer | <MK_SEC_OFFICER> | Tạo, cài policy và group; quản lý S-TAP |
| auditor_ora | role_auditor | <MK_AUDITOR_ORA> | Xem báo cáo, ký duyệt; dữ liệu oracledb01 (KB3) |
| auditor_mss | role_auditor | <MK_AUDITOR_MSS> | Xem báo cáo, ký duyệt; dữ liệu SQLDB01 (KB3) |
Hình 10: Ba tài khoản mới trong User Browser
Bước 2: Ở dòng từng user nhấn Roles, tích role theo bảng, bỏ tích user, nhấn Save.
Hình 11: Gán role_secofficer cho sec_officer
Bước 3: Nhấn Edit, bỏ tích Disabled, nhấn Update User. Đăng nhập từng tài khoản và đổi mật khẩu tạm theo yêu cầu.
- Gán role xong mới bỏ Disabled: giao diện của user được dựng theo role ở lần đăng nhập đầu. Bỏ role user để tài khoản không nhận quyền mặc định của người dùng thường.
3.5. Cấp đối tượng và tạo audit process ký duyệt
Bước 1: Đăng nhập admin, mở Protect → Security Policies → Policy Builder for Data. Với từng policy ghi ở mục 3.1: chọn policy, nhấn biểu tượng sửa (bút chì), ở Name and properties nhấn Roles, tích role_secofficer, nhấn OK ở hộp thoại rồi OK để lưu. Làm tương tự với GRP_SOD_DBA_USERS trong Group Builder (nút Roles ở tab General).
- sec_officer cần thấy các policy đang cài để cài lại đúng thứ tự (KB1). Nếu builder không có chức năng Roles, accessmgr cấp bằng Manage Permissions của role_secofficer.
Hình 12: Cấp POL_AUDIT_DB_CHANGES cho role_secofficer
Bước 2: Truy cập Comply → Tools and Views → Audit Process Builder, nhấn New, khai báo theo bảng rồi nhấn Save:
Trường | Giá trị |
| Description | AP_SOD_REVIEW |
| Receivers | Role role_auditor; Action = Sign off; tích Add to to-do list; Email format = None; Distribution sequence = Simultaneous |
| Tasks | Hai task loại Report, chọn User defined: Q_SOD_VIOLATIONS, Q_SOD_DBA_ACTIVITY; khoảng thời gian 1 ngày |
| Schedule | Hằng ngày lúc 08:00 |
- Kết quả audit process gửi cho kiểm toán, không gửi cho sec_officer: người cấu hình chính sách không tự duyệt kết quả của chính sách mình làm.
Hình 13: Audit process AP_SOD_REVIEW: task, người nhận và lịch chạy
4. Kịch bản kiểm thử
Chạy theo thứ tự, ghi lại thời điểm từng kịch bản để lọc báo cáo và đối chiếu ở KB5.
4.1. Kịch bản 1 – Security Officer quản lý chính sách giám sát
sec_officer nhận yêu cầu mới: cảnh báo khi tài khoản quản trị CSDL sửa, xóa dữ liệu hoặc xóa bảng. Rule này được dùng ở KB4.
Bước 1: Đăng nhập sec_officer, ghi lại menu hiển thị. Mở Group Builder, tạo group GRP_SOD_DATA_CMDS (Commands): DELETE, UPDATE, TRUNCATE TABLE, DROP TABLE.
Bước 1: Đăng nhập sec_officer, ghi lại menu hiển thị. Mở Group Builder, tạo group GRP_SOD_DATA_CMDS (Commands): DELETE, UPDATE, TRUNCATE TABLE, DROP TABLE.
Hình 14: Menu của sec_officer và group GRP_SOD_DATA_CMDS
Bước 2: Mở Policy Builder for Data, nhấn New, đặt Name = POL_SOD_PRIVILEGED_ACTIVITY, thêm access rule dưới rồi nhấn OK:
Rule | Điều kiện | Hành động; Continue |
| SOD_ALERT_DBA_CHANGE | Category = Separation of Duties; Severity = High; Database user In Group GRP_SOD_DBA_USERS; Command In Group GRP_SOD_DATA_CMDS | ALERT PER MATCH, LOG FULL DETAILS; bật Continue to next rule |
Hình 15: Policy POL_SOD_PRIVILEGED_ACTIVITY với rule SOD_ALERT_DBA_CHANGE
Bước 3: Mở Policy Installation, cài lại danh sách ở mục 3.1 và chèn policy mới ngay trước POL_PROTECT_SENSITIVE_DATA. Policy đầu chọn Install and override, các policy sau lần lượt chọn Install last; kiểm tra mục Currently Installed Policies:
1 POL_AUDIT_DB_CHANGES2 POL_RT_ACCESS_ALERT
3 POL_NET_LOCAL_CONTROL
4 POL_SOD_PRIVILEGED_ACTIVITY
5 POL_PROTECT_SENSITIVE_DATA
6 POL_BASIC_DATA_SECURITY
- Policy đứng trước POL_PROTECT_SENSITIVE_DATA và rule tích Continue để câu của DBA trên mọi bảng đều tới được rule mà không chặn các rule phía sau. Thực hiện liên tiếp các lần cài vì giữa hai lần cài, rule che, chặn trong POL_PROTECT_SENSITIVE_DATA tạm thời không chạy.
Hình 16: Thứ tự cài đặt policy do sec_officer thực hiện
Bước 4: Thử thao tác ngoài nhiệm vụ: ở ô User Interface Search gõ lần lượt User Browser, Global Profile, Audit Process To-Do List; mở Setup → Tools and Views → Services Status. Ghi lại kết quả.
Hình 17: sec_officer không tìm thấy chức năng ngoài nhiệm vụ, Services Status chỉ có hai dịch vụ
Đánh giá: sec_officer tự tạo group, policy POL_SOD_PRIVILEGED_ACTIVITY và cài lại sáu policy đúng thứ tự (policy mới đứng thứ tư, cài lúc 21:01:46) mà không cần admin. Tìm User Browser, Global Profile, Audit Process To-Do List đều không có kết quả; Services Status chỉ hiện hai dịch vụ.
4.2. Kịch bản 2 – Kiểm toán viên chỉ xem và ký duyệt
Bước 1: Đăng nhập auditor_ora, ghi lại trang chủ và menu. Mở Q_SOD_VIOLATIONS, Q_SOD_DBA_ACTIVITY (lab đặt Start Date 2026-10-18 00:00:00); ghi lại có dòng của cả <IP_ORACLE> và <IP_MSSQL> (chưa lọc theo dữ liệu).
Hình 18: Menu Audit Reports và Q_SOD_DBA_ACTIVITY của auditor_ora khi chưa lọc dữ liệu
Bước 2: Trên report Q_SOD_DBA_ACTIVITY nhấn biểu tượng sửa (bút chì); ở User Interface Search gõ Policy Builder, User Browser; trên trang Welcome bấm ô Vulnerability Assessment. Ghi lại kết quả.
Hình 19: Nút sửa bị khóa, tìm Policy Builder không có kết quả, ô Vulnerability Assessment không phản hồi
Bước 3: Kiểm tra quyền và menu có tách nhau không:
- accessmgr cấp thêm Policy Builder cho role_auditor trong Manage Permissions, không sửa Navigation Menu. auditor_ora đăng nhập lại, gõ Policy Builder vào User Interface Search, mở menu ▼ cạnh tên tài khoản và bấm ô Install Basic Security Monitoring Policy trên trang Welcome.
Hình 20: accessmgr cấp Policy Builder nhưng auditor_ora vẫn không tìm thấy, không tự sửa được menu
- admin mở Customize User/Role, tab Users, chọn auditor_ora, thêm Policy Builder for Data vào nhóm Audit Reports rồi nhấn Save. auditor_ora đăng nhập lại và mở mục này.
Hình 21: admin thêm Policy Builder for Data vào menu, auditor_ora mở được Security Policies
- accessmgr chuyển Policy Builder về Inaccessible items. auditor_ora đăng nhập lại và mở lại mục Policy Builder for Data.
Hình 22: accessmgr thu hồi quyền, auditor_ora bị từ chối dù mục menu còn
- admin xóa mục Policy Builder for Data khỏi menu của auditor_ora, nhấn Save.
Bước 4: admin mở Audit Process Builder, chọn AP_SOD_REVIEW, nhấn Run Once Now. auditor_ora và admin cùng mở Audit Process To-Do List; auditor_ora nhấn View ở dòng AP_SOD_REVIEW, xem kết quả rồi nhấn Sign Results.
Hình 23: Kết quả AP_SOD_REVIEW chỉ gửi cho kiểm toán viên và được ký duyệt
Đánh giá: auditor_ora chỉ có menu Audit Reports (8 mục), không sửa được query. Quyền do accessmgr giữ mới chặn thật: có quyền mà thiếu menu thì không dùng được, có menu mà mất quyền thì bị từ chối. AP_SOD_REVIEW chỉ gửi kiểm toán viên và đã được ký.
4.3. Kịch bản 3 – Phân quyền theo dữ liệu bằng Data Level Security
auditor_ora chỉ được thấy hoạt động trên oracledb01, auditor_mss chỉ thấy SQLDB01; admin xem được toàn bộ khi cần.
Bước 1: Đăng nhập accessmgr. Trong User Browser nhấn Roles ở dòng admin, tích thêm datasec-exempt, nhấn Save.
Bước 1: Đăng nhập accessmgr. Trong User Browser nhấn Roles ở dòng admin, tích thêm datasec-exempt, nhấn Save.
Hình 24: Gán datasec-exempt cho admin
Bước 2: Mở Data Security → User-DB Association (tìm bằng User Interface Search nếu không thấy trong menu). Ở Server & Service Name Suggestion chọn máy chủ, nhấn Go. Trên cây máy chủ chọn nút <IP_ORACLE> (hoặc nhập IP vào ô IP rồi nhấn Find), nhấn Add user, chọn auditor_ora; làm tương tự với <IP_MSSQL> và auditor_mss. Nhấn Update Active User-DB Map.
Hình 25: Gán máy chủ cho auditor_ora và auditor_mss trong User-DB Association
Bước 3: Đăng nhập admin, mở Global Profile, ở Data level security filtering nhấn Enable.
Hình 26: Bật Data level security filtering trong Global Profile
Bước 4: Trên máy quản trị (thư mục Task3), sinh vi phạm mới trên cả hai CSDL bằng INTERN_TEST (rule đang cài trong lab cảnh báo tài khoản không được phép đọc bảng nhạy cảm):
python uc4_ora.py intern_test "SELECT COUNT(*) FROM retail.customers"python uc4_mss.py intern_test -d RetailDB "SELECT COUNT(*) FROM retail.customers"
Bước 5: Chờ khoảng 10 phút. Đăng nhập lại auditor_ora và auditor_mss, mở Q_SOD_VIOLATIONS với khoảng thời gian bao trùm KB2 và bước 4. admin mở cùng report, lần đầu bỏ tích ô Show all, lần sau tích Show all.
- Bảng ánh xạ user – máy chủ được cập nhật 10 phút một lần; nếu kết quả chưa đúng, chờ thêm rồi đăng nhập lại.
- admin phải đăng nhập lại sau khi được gán datasec-exempt thì report mới có ô Show all. Nếu không gán được role này, report của admin trống khi bật lọc; Global Profile không bị lọc nên vẫn tắt được. Giữ lọc bật tới hết KB4.
Hình 27: Q_SOD_VIOLATIONS của auditor_ora và auditor_mss
Hình 28: Report của admin trống, chỉ thấy toàn bộ dữ liệu khi tích Show all
Đánh giá: Khi bật lọc, Q_SOD_VIOLATIONS của auditor_ora chỉ có 4 vi phạm trên oracledb01, của auditor_mss 4 vi phạm trên SQLDB01; admin chỉ thấy đủ 8 khi tích Show all. Gán máy chủ do accessmgr, bật lọc do admin, nên kiểm toán viên không tự mở rộng phạm vi.
4.4. Kịch bản 4 – DBA không xóa được vết kiểm toán
DBA dùng quyền cao nhất trên CSDL để sửa, xóa dữ liệu, tắt kiểm toán gốc của CSDL, rồi dùng quyền quản trị máy chủ dừng S-TAP. Thao tác dữ liệu làm trên bảng sao chép orders_sod để không ảnh hưởng dữ liệu mẫu.
Bước 1: Oracle. SSH vào oracledb01, chuyển sang user oracle, ghi lại thời điểm rồi chạy:
su - oracleBước 1: Oracle. SSH vào oracledb01, chuyển sang user oracle, ghi lại thời điểm rồi chạy:
sqlplus / as sysdba
CREATE TABLE retail.orders_sod AS SELECT * FROM retail.orders;
UPDATE retail.orders_sod SET status = status WHERE ROWNUM <= 5;
DELETE FROM retail.orders_sod WHERE ROWNUM <= 5;
COMMIT;
DROP TABLE retail.orders_sod PURGE;
SELECT policy_name, enabled_option, success, failure
FROM audit_unified_enabled_policies;
NOAUDIT POLICY ora_logon_failures;
AUDIT POLICY ora_logon_failures WHENEVER NOT SUCCESSFUL;
exit
- Câu AUDIT cuối trả lại trạng thái ban đầu theo kết quả câu SELECT; chạy lại câu SELECT sau NOAUDIT và sau AUDIT để kiểm tra. Nếu ORA_LOGON_FAILURES không có trong kết quả thì bỏ hai câu NOAUDIT, AUDIT.
Hình 29: SYS sửa, xóa dữ liệu và tắt, bật lại ORA_LOGON_FAILURES trên Oracle
Bước 2: SQL Server. Trên máy quản trị (thư mục Task3) chạy bằng sa qua TCP; ghi lại kết quả câu SELECT đầu, lệnh cuối trả cấu hình về giá trị đã ghi:
python uc4_mss.py sa "SELECT name, value_in_use FROM sys.configurations `WHERE name IN ('show advanced options','default trace enabled')"
python uc4_mss.py sa -d RetailDB `
"SELECT * INTO retail.orders_sod FROM retail.orders" `
"UPDATE TOP (5) retail.orders_sod SET status = status" `
"DELETE TOP (5) FROM retail.orders_sod" `
"DROP TABLE retail.orders_sod"
python uc4_mss.py sa `
"EXEC sp_configure 'show advanced options', 1; RECONFIGURE" `
"EXEC sp_configure 'default trace enabled', 0; RECONFIGURE"
python uc4_mss.py sa `
"EXEC sp_configure 'default trace enabled', 1; RECONFIGURE" `
"EXEC sp_configure 'show advanced options', <giá trị cũ>; RECONFIGURE"
- Không thử trên customers: sa không thuộc GRP_AUTHORIZED_USERS nên DELETE trên bảng nhạy cảm bị BLOCK_DESTRUCTIVE_TERMINATE đang cài trong lab ngắt phiên.
Hình 30: sa sửa, xóa dữ liệu và tắt default trace trên SQL Server
Bước 3: Dừng tiến trình S-TAP trên oracledb01. Thử bằng user oracle (DBA chỉ có quyền trên CSDL) trước, sau đó bằng root; chờ 1 phút rồi kiểm tra lại:
ps -ef | grep [g]uard_stapps -fp <PPID của guard_stap>
date; kill <PID của guard_stap>
sleep 60; ps -ef | grep [g]uard_stap
Hình 31: Dừng tiến trình S-TAP trên oracledb01 bằng user oracle và bằng root
Bước 4: Dừng hẳn S-TAP trên SQLDB01. SSH bằng tài khoản quản trị, mở PowerShell; chạy câu đánh dấu sod_gap_mss trong lúc S-TAP dừng và sod_after_mss sau khi bật lại:
Get-Date; Stop-Service -Name GUARDIUM_STAP -Force; Get-Service GUARDIUM_STAPsqlcmd -S localhost -E -d RetailDB -No `
-Q "SELECT COUNT(*) AS sod_gap_mss FROM retail.orders"
Start-Service -Name GUARDIUM_STAP; Start-Sleep 90; Get-Date; Get-Service GUARDIUM_STAP
sqlcmd -S localhost -E -d RetailDB -No `
-Q "SELECT COUNT(*) AS sod_after_mss FROM retail.orders"
- Guardium chuẩn hóa câu lệnh và bỏ alias (Q_SOD_DBA_ACTIVITY chỉ ghi select count(*) from "RETAIL"."ORDERS"), nên phân biệt câu sod_gap_mss, sod_after_mss theo thời điểm chạy. Nếu S-TAP không trở lại xanh sau 2 phút, chạy Restart-Service cho dịch vụ S-TAP.
Hình 32: Dừng và bật lại dịch vụ GUARDIUM_STAP trên SQLDB01
Bước 5: Ngay sau bước 2, đăng nhập auditor_ora và auditor_mss, mở Q_SOD_DBA_ACTIVITY, Q_SOD_VIOLATIONS với khoảng thời gian 3 giờ gần nhất. Sau bước 4, mở Inactive S-TAPs Since và Q_SOD_DBA_ACTIVITY của auditor_mss; đăng nhập sec_officer, mở S-TAP Events.
- DBA không có tài khoản trên Guardium nên không sửa, xóa được dữ liệu đã thu. sp_configure còn khớp rule AUD_ADMIN_PROCS (HIGH) đang cài trong lab; DROP TABLE, NOAUDIT, AUDIT hiện trong query Q_CHG_SCHEMA đã có trong lab.
- Inactive S-TAPs Since trống khi S-TAP đã chạy lại, nên không phát hiện được gián đoạn ngắn; dùng S-TAP Events để thấy lần dừng.
Hình 33: Câu lệnh và vi phạm của DBA trong báo cáo của kiểm toán viên
Hình 34: S-TAP Events, Inactive S-TAPs Since và Q_SOD_DBA_ACTIVITY sau khi dừng S-TAP
Đánh giá: Q_SOD_DBA_ACTIVITY ghi đủ câu của SYS, kể cả NOAUDIT; DROP TABLE của SYS, SA bị SOD_ALERT_DBA_CHANGE cảnh báo HIGH. User oracle không dừng được S-TAP, root dừng thì S-TAP tự chạy lại. Dừng S-TAP trên SQLDB01 có trong S-TAP Events nhưng câu chạy lúc dừng bị mất.
4.5. Kịch bản 5 – Kiểm soát chính người quản trị Guardium
Bước 1: Đăng nhập admin, ở User Interface Search gõ User Browser. Đăng nhập accessmgr, mở Protect → Security Policies. Ghi lại kết quả.
Hình 35: admin không quản lý được user, accessmgr không cấu hình được giám sát
Bước 2: accessmgr nhấn Roles ở dòng sec_officer, tích thêm admin (giữ role_secofficer), nhấn Save; mở lại Roles, bỏ role_secofficer, giữ admin và tích thêm accessmgr. Ghi lại thông báo, rồi trả sec_officer về chỉ có role_secofficer và mở lại Roles để kiểm tra.
- Chỉ thử trên sec_officer, không sửa role của admin, accessmgr. Tổ hợp nào lưu được phải gỡ ngay sau khi chụp, vì tài khoản đó đã có quyền admin.
Hình 36: admin cùng role_secofficer lưu được, admin cùng accessmgr bị từ chối, sec_officer trở lại chỉ có role_secofficer
Bước 3: Đăng nhập auditor_ora, mở All Roles - Application Access, so số ứng dụng của role_secofficer, role_auditor với mục 3.3.
Hình 37: All Roles - Application Access: role_secofficer 7, role_auditor 2, role mặc định 38 ứng dụng
Bước 4: Mở User Activity Audit Trail, System/Security Activities, Guardium Logins với khoảng thời gian bao trùm mục 3.3 tới bước 2 (lab dùng 3 giờ gần nhất). Đối chiếu với thời điểm đã ghi: tạo role, user (mục 3.3, 3.4), cài policy của sec_officer (KB1), sửa quyền tạm thời của role_auditor (KB2), gán datasec-exempt và bật lọc dữ liệu (KB3), gán role bị từ chối (bước 2).
- Report hoạt động của tài khoản Guardium không bị Data Level Security lọc nên auditor_ora vẫn thấy đủ. System/Security Activities chỉ ghi tên bảng và giá trị khóa (TURBINE_USER_GROUP_ROLE, ROLE_ID), không ghi tên role, nên phải đối chiếu thêm với Role Browser.
Hình 38: Nhật ký thao tác của tài khoản Guardium
Đánh giá: admin không quản lý user, accessmgr không cấu hình giám sát. Guardium chặn gán admin cùng accessmgr nhưng accessmgr vẫn gán được admin cho sec_officer, nên accessmgr (lab dùng mật khẩu mặc định) là rủi ro lớn nhất. Ba report nhật ký ghi đủ các thao tác này.
Sửa lần cuối: