ĐÁ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 DATABASE VÀ MICROSOFT SQL SERVER
1. Mục tiêu
- Thu thập trạng thái phân quyền (user, role, system privilege, object privilege) trên Oracle và SQL Server bằng tính năng Database Entitlement Reports của Guardium.
- Đánh giá quyền của từng tài khoản: có quyền gì, trên đối tượng nào, nhận trực tiếp hay kế thừa qua role, có thuộc nhóm quản trị cao nhất hay không.
- Phát hiện thay đổi quyền giữa các thời điểm (snapshot): cấp mới, thu hồi, gán role quản trị, cấp quyền cho PUBLIC.
- Kết hợp với rule DET_PRIV_ESCALATION để biết ai đã cấp quyền và vào lúc nào.
2. Nguyên lý hoạt động
Entitlement Reports không cần S-TAP: Guardium kết nối JDBC tới CSDL bằng một tài khoản kỹ thuật chỉ đọc catalog phân quyền, chạy câu truy vấn có sẵn và lưu kết quả thành snapshot tại thời điểm chạy.Thành phần | Vai trò |
| Tài khoản kỹ thuật GUARDIUM_ENT | Chỉ đọc view/bảng hệ thống về phân quyền, dùng riêng cho datasource entitlement |
| Datasource Definition | Khai báo kết nối: IP, port, service/database và tài khoản kỹ thuật |
| Custom Table | Mỗi report có sẵn một bảng (ví dụ ORA_OBJECT_PRIVELEGES_BY_DB). Upload Data chạy câu truy vấn trên datasource, ghi kết quả vào bảng kèm SqlGuard Timestamp (thời điểm upload) |
| Custom Domain và report có sẵn | Report entitlement đọc dữ liệu từ custom table; mỗi lần upload tạo một snapshot mới |
| Policy (S-TAP) | Ghi nhận câu lệnh GRANT/REVOKE theo thời gian thực qua rule DET_PRIV_ESCALATION đã có trong lab |
Hai cơ chế bổ sung cho nhau: Entitlement Report trả lời "hiện tại ai có quyền gì" nhưng bỏ sót quyền được cấp rồi thu hồi giữa hai lần upload; policy trả lời "ai đã chạy lệnh cấp quyền, lúc nào, từ đâu" nhưng không cho biết tổng thể quyền đang có.
- Entitlement là thành phần tùy chọn, bật theo product key: nếu Custom Table Builder không có các bảng ORA … và Microsoft SQL Server … thì kiểm tra lại license.
Hình 1: Nguyên lý đánh giá quyền bằng snapshot entitlement kết hợp policy giám sát lệnh phân quyền
3. Mô hình triển khai và chuẩn bị
3.1. Thành phần hệ thống
Thành phần | Tên máy / IP | Vai trò |
| Guardium Collector (đồng thời là Central Manager), v12.0 | <IP_GUARDIUM> | Kết nối JDBC tới CSDL, lưu snapshot và chạy report |
| Oracle Database 19c trên Oracle Linux (non-CDB, service orcl) | oracledb01 / <IP_ORACLE> | CSDL được đánh giá quyền, S-TAP Linux |
| Microsoft SQL Server trên Windows Server (RetailDB, schema retail) | SQLDB01 / <IP_MSSQL> | CSDL được đánh giá quyền, S-TAP Windows |
3.2. Tài khoản sử dụng
Tài khoản | CSDL | Vai trò trong bài |
| GUARDIUM_ENT / guardium_ent (tạo mới) | Oracle / MSSQL | Tài khoản kỹ thuật chỉ đọc catalog, chỉ dùng cho datasource entitlement |
| SYS, SYSTEM / sa | Oracle / MSSQL | SYS tạo GUARDIUM_ENT; SYSTEM và sa thực hiện các lệnh GRANT/REVOKE, kiểm tra quyền trong kịch bản |
| RETAIL | Oracle | Chủ schema, cấp và thu hồi quyền object (grantor) ở kịch bản 1, 3, 6 |
| OPS_TEST, INTERN_TEST | Oracle, MSSQL | Đối tượng kiểm thử được cấp và thu hồi quyền |
- Không dùng sa hay GUARDIUM_CLS cho datasource entitlement và không cấp quyền kiểm thử cho chính GUARDIUM_ENT, để kết quả dễ diễn giải và đúng nguyên tắc cấp quyền tối thiểu.
3.3. Các report sử dụng
Tên report theo giao diện Guardium 12.0 của lab; report SQL Server có thêm tiền tố "Microsoft SQL Server". Gõ từ khóa ở cột Report vào ô Filter của Custom Table Builder hoặc Custom Query-Report Builder để tìm nhanh.
CSDL | Report (từ khóa) | Database | Ý nghĩa |
Oracle | ORA Object privileges | orcl | Quyền trên object cấp cho user/role |
Oracle | ORA Roles Granted | orcl | Role cấp cho user/role |
Oracle | ORA Sys Priv Granted 8 | orcl | System privilege cấp cho user/role |
Oracle | ORA SYSDBA and SYSOPER Accounts | orcl | Tài khoản có SYSDBA/SYSOPER |
Oracle | ORA Object Access By PUBLIC | orcl | Object PUBLIC truy cập được |
Oracle | ORA PUBLIC Exec Priv on SYS Proc | orcl | Thủ tục SYS mà PUBLIC được EXECUTE |
MSSQL | Srv Account of sys/server/security admin | master | Thành viên sysadmin, serveradmin, securityadmin |
MSSQL | Account Of db_owner db_securityadmin Role | RetailDB | Thành viên db_owner, db_securityadmin |
MSSQL | Object Access By PUBLIC | RetailDB | Object public truy cập được |
MSSQL | Role/Sys Privs Granted To User And Role | RetailDB | Role, quyền cấp database của user/role |
MSSQL | Obj Privs By Non-Default Sys User | RetailDB | Quyền trên object cấp cho user không mặc định |
4. Chuẩn bị trên CSDL
4.1. Tạo tài khoản GUARDIUM_ENT trên Oracle
Chạy bằng SYS, kết nối qua listener:sqlplus sys/"<MK_SYS>"@//<IP_ORACLE>:1521/orcl as sysdba
CREATE USER guardium_ent IDENTIFIED BY "<MK_GUARDIUM_ENT>"
DEFAULT TABLESPACE users QUOTA 0 ON users;
GRANT CREATE SESSION TO guardium_ent;
-- View phân quyền
GRANT SELECT ON sys.dba_users TO guardium_ent;
GRANT SELECT ON sys.dba_roles TO guardium_ent;
GRANT SELECT ON sys.dba_role_privs TO guardium_ent;
GRANT SELECT ON sys.dba_sys_privs TO guardium_ent;
GRANT SELECT ON sys.dba_tab_privs TO guardium_ent;
GRANT SELECT ON sys.dba_col_privs TO guardium_ent;
GRANT SELECT ON sys.dba_objects TO guardium_ent;
-- Bảng dictionary và view dùng cho report PUBLIC, SYSDBA/SYSOPER
GRANT SELECT ON sys.obj$ TO guardium_ent;
GRANT SELECT ON sys.user$ TO guardium_ent;
GRANT SELECT ON sys.objauth$ TO guardium_ent;
GRANT SELECT ON sys.table_privilege_map TO guardium_ent;
GRANT SELECT ON sys.v_$pwfile_users TO guardium_ent;
- Grant trên v_$pwfile_users (có gạch dưới), không grant trên synonym v$pwfile_users. Thiếu quyền này thì report ORA SYSDBA and SYSOPER Accounts không có dữ liệu; thiếu obj$, objauth$, user$ thì các report PUBLIC có thể lỗi.
- SYS.USER$ chứa hash mật khẩu: đặt mật khẩu mạnh cho GUARDIUM_ENT, chỉ dùng tài khoản này trong datasource và theo dõi đăng nhập của nó từ IP khác IP Guardium.
sqlplus guardium_ent/"<MK_GUARDIUM_ENT>"@//<IP_ORACLE>:1521/orcl
SQL> SELECT user FROM dual;
SQL> SELECT username, sysdba, sysoper, account_status FROM sys.v_$pwfile_users;
Hình 2: GUARDIUM_ENT đăng nhập thành công và đọc được sys.v_$pwfile_users (SYS có SYSDBA, SYSOPER)
4.2. Tạo tài khoản guardium_ent trên SQL Server
Chạy bằng sa trong SSMS hoặc sqlcmd:USE [master];
CREATE LOGIN [guardium_ent] WITH PASSWORD = N'<MK_GUARDIUM_ENT>',
DEFAULT_DATABASE = [master], CHECK_POLICY = ON;
GRANT VIEW ANY DEFINITION TO [guardium_ent];
CREATE USER [guardium_ent] FOR LOGIN [guardium_ent];
GRANT SELECT ON sys.server_principals TO [guardium_ent];
GRANT SELECT ON sys.database_permissions TO [guardium_ent];
GRANT SELECT ON sys.database_principals TO [guardium_ent];
GRANT SELECT ON sys.all_objects TO [guardium_ent];
GRANT SELECT ON sys.database_role_members TO [guardium_ent];
GRANT SELECT ON sys.columns TO [guardium_ent];
GO
USE [RetailDB];
CREATE USER [guardium_ent] FOR LOGIN [guardium_ent];
GRANT SELECT ON sys.database_permissions TO [guardium_ent];
GRANT SELECT ON sys.database_principals TO [guardium_ent];
GRANT SELECT ON sys.all_objects TO [guardium_ent];
GRANT SELECT ON sys.database_role_members TO [guardium_ent];
GRANT SELECT ON sys.columns TO [guardium_ent];
GO
- VIEW ANY DEFINITION là bắt buộc: thiếu quyền này thì catalog view chỉ trả về chính tài khoản đang truy vấn, các login hệ thống và role cố định (metadata visibility), report sẽ thiếu user và role của người khác.
- Nhóm quyền cấp database phải cấp trên từng database cần đánh giá, kể cả master. Thêm database mới thì lặp lại khối USE [...].
sqlcmd -S <IP_MSSQL>,1433 -U guardium_ent -P "<MK_GUARDIUM_ENT>" -No -C -W `
-Q "SELECT name FROM sys.server_principals WHERE type IN ('S','U') ORDER BY name"
Hình 3: guardium_ent liệt kê được login của các tài khoản khác nhờ quyền VIEW ANY DEFINITION
4.3. Ghi nhận baseline bằng truy vấn trực tiếp
Chạy các truy vấn sau trước kịch bản đầu tiên và lưu kết quả để đối chiếu: report Guardium khớp với truy vấn trực tiếp thì dữ liệu entitlement đáng tin cậy.
Oracle (SYS hoặc GUARDIUM_ENT):SELECT grantee, owner, table_name, privilege, grantable, grantor
FROM dba_tab_privs WHERE grantee IN ('OPS_TEST','INTERN_TEST')
ORDER BY 1,3,4;
SELECT grantee, granted_role, admin_option FROM dba_role_privs
WHERE grantee IN ('OPS_TEST','INTERN_TEST');
SELECT grantee, privilege, admin_option FROM dba_sys_privs
WHERE grantee IN ('OPS_TEST','INTERN_TEST');
SELECT grantee FROM dba_role_privs WHERE granted_role = 'DBA';
SELECT * FROM v$pwfile_users;
SELECT owner, table_name, privilege FROM dba_tab_privs
WHERE grantee = 'PUBLIC' AND owner = 'RETAIL';
SQL Server:
-- Thành viên role quản trị server (master)
SELECT r.name AS server_role, m.name AS member
FROM sys.server_role_members rm
JOIN sys.server_principals r ON rm.role_principal_id = r.principal_id
JOIN sys.server_principals m ON rm.member_principal_id = m.principal_id
WHERE r.name IN ('sysadmin','serveradmin','securityadmin');
USE RetailDB;
-- Thành viên db_owner, db_securityadmin
SELECT r.name AS db_role, m.name AS member
FROM sys.database_role_members rm
JOIN sys.database_principals r ON rm.role_principal_id = r.principal_id
JOIN sys.database_principals m ON rm.member_principal_id = m.principal_id
WHERE r.name IN ('db_owner','db_securityadmin');
-- Object nghiệp vụ cấp cho public
SELECT SCHEMA_NAME(o.schema_id) AS schema_name, o.name,
p.permission_name, p.state_desc
FROM sys.database_permissions p JOIN sys.objects o ON p.major_id = o.object_id
WHERE p.grantee_principal_id = DATABASE_PRINCIPAL_ID('public')
AND o.is_ms_shipped = 0;
Baseline Oracle theo seed script: INTERN_TEST và GUARDIUM_CLS có SELECT trên 4 bảng RETAIL; OPS_TEST có SELECT, INSERT, UPDATE, DELETE trên CUSTOMERS và EMPLOYEES, SELECT trên ORDERS và PRODUCTS. Quyền còn sót từ các lần kiểm thử trước (nếu có) là phát hiện đầu tiên của bài.
5. Cấu hình Guardium
5.1. Tạo datasource
Bước 1: Truy cập Setup → Tools and Views → Datasource Definitions, nhấn + và tạo ba datasource theo bảng dưới.
Name | Database type | Kết nối | User |
| DS_ENT_ORA_ORACLEDB01 | Oracle (DataDirect - Service Name) | <IP_ORACLE>:1521 service orcl | GUARDIUM_ENT |
| DS_ENT_MSSQL_MASTER | MS SQL SERVER (DataDirect) | <IP_MSSQL>:1433 database master | guardium_ent |
| DS_ENT_MSSQL_RETAILDB | MS SQL SERVER (DataDirect) | <IP_MSSQL>:1433 database RetailDB | guardium_ent |
Bước 2: Chọn từng datasource, nhấn Test connection, kiểm tra cả ba có biểu tượng xanh ở cột Status.
Hình 4: Ba datasource DS_ENT_* kết nối thành công (cùng hai datasource phân loại đã có trong lab)
5.2. Cấu hình Upload Data
Bước 1: Truy cập Reports → Report Configuration Tools → Custom Table Builder (một số bản đặt ở Comply → Custom Reporting).
Bước 2: Lọc theo từ khóa ở bảng mục 3.3, chọn bảng, nhấn Upload Data và khai báo theo bảng dưới.
Bước 2: Lọc theo từ khóa ở bảng mục 3.3, chọn bảng, nhấn Upload Data và khai báo theo bảng dưới.
Trường | Giá trị | Ý nghĩa |
| SQL statement, Id column, DML command after upload | Để trống | Bảng entitlement có sẵn câu truy vấn |
| Overwrite | No overwrite | Giữ snapshot cũ để so sánh giữa các thời điểm |
| Default Purge | Tích | Dữ liệu cũ hơn 60 ngày tự xóa theo job purge mặc định |
| Use default schedule | Không tích | Chỉ dùng cho bảng nâng cấp từ phiên bản cũ; lịch đặt bằng Modify Schedule |
| Datasources | Add Datasource | Chọn datasource ở mục 5.1 khớp với cột Database của report ở mục 3.3 |
- Không chọn Per upload hoặc Per datasource: hai tùy chọn này xóa dữ liệu cũ trước mỗi lần upload, chỉ còn snapshot mới nhất, không so sánh được hai mốc thời gian và mất lịch sử phục vụ điều tra.
Bước 3: Nhấn Check/Repair, Verify Datasource rồi Apply.
Hình 5: Cấu hình Upload Data cho ORA Object privileges với Overwrite = No overwrite
Bước 4: Nhấn Run Once Now để lấy snapshot đầu tiên (T0). Lặp lại cho đủ 11 report ở mục 3.3.
- Kiểm chứng ngay sau T0: chạy Run Once Now thêm lần nữa cho ORA Object privileges, mở report và xác nhận có nhiều giá trị SqlGuard Timestamp khác nhau.
Hình 6: ORA Object privileges giữ lại các snapshot cũ (5.176 = 4 × 1.294 dòng)
5.3. Dashboard và query lọc
Bước 1: Truy cập My Dashboards → Create New Dashboard, đặt tên DB Entitlement Review.
Bước 2: Truy cập Reports → Report Configuration Tools → Custom Query-Report Builder, gõ tên report vào ô Filter, chọn report và nhấn Add to Dashboard; lặp lại cho cả 11 report. Report entitlement không có trong Query-Report Builder thường.
Bước 3: Ở mỗi report, mở Customize và đặt Start Date đủ xa (ví dụ NOW -7 DAY). Report lọc theo SqlGuard Timestamp nên khoảng thời gian mặc định ngắn sẽ ẩn các snapshot cũ.
Bước 2: Truy cập Reports → Report Configuration Tools → Custom Query-Report Builder, gõ tên report vào ô Filter, chọn report và nhấn Add to Dashboard; lặp lại cho cả 11 report. Report entitlement không có trong Query-Report Builder thường.
Bước 3: Ở mỗi report, mở Customize và đặt Start Date đủ xa (ví dụ NOW -7 DAY). Report lọc theo SqlGuard Timestamp nên khoảng thời gian mặc định ngắn sẽ ẩn các snapshot cũ.
Hình 7: Dashboard DB Entitlement Review với 11 report entitlement của Oracle và SQL Server
Bước 4: Report có sẵn ở chế độ chỉ đọc. Để lọc, trong Custom Query-Report Builder chọn query của report, nhấn Clone, thêm điều kiện theo bảng dưới, lưu và Add to Dashboard.
Query clone | Clone từ | Điều kiện | Dùng ở |
| Q_ENT_OBJPRIV_OPS | ORA Object privileges | Grantee = OPS_TEST (hoặc tham số runtime); sắp xếp theo SqlGuard Timestamp | KB1, KB3 |
| RETAIL_SUPPORT_ROLE | ORA Roles Granted | Granted Role = RETAIL_SUPPORT_ROLE | KB2 |
| Q_ENT_SYSPRIV_OPS | ORA Sys Priv Granted 8 | GRANTEE = OPS_TEST hoặc RETAIL_SUPPORT_ROLE | KB2, KB3 |
| Q_ENT_ORA_PUBLIC | ORA Object Access By PUBLIC | Owner = RETAIL | KB6 |
| Q_ENT_MSS_PUBLIC | Microsoft SQL Server Object Access By PUBLIC | Schema_Owner = retail | KB6 |
| Q_ENT_ROLES_DBA | ORA Roles Granted | Granted Role = DBA | KB7 |
- Upload Data gắn với custom table, không gắn với query: query clone dùng cùng domain nên đọc chính dữ liệu đã upload, không cần cấu hình upload riêng. Chỉ clone query; clone custom table hoặc custom domain sẽ được bảng rỗng, không có câu truy vấn entitlement.
6. Kịch bản kiểm thử
Các lệnh được chạy từ máy quản trị bằng hai script: uc4_ora.py cho Oracle (thư viện python-oracledb, kết nối qua listener 1521) và uc4_mss.py cho SQL Server (sqlcmd -No -C qua TCP 1433), nên S-TAP ghi nhận được. Script lấy mật khẩu từ file tài khoản lab, không in ra màn hình, và in kèm thời điểm thực thi trước mỗi lệnh. Client IP trong các hình là IP của máy quản trị, đổi từ đuôi .11 sang .1 giữa buổi lab do máy được cấp lại địa chỉ.
python uc4_ora.py <user> "<câu lệnh>" ["<câu lệnh>" ...]python uc4_mss.py <login> [-d <database>] "<câu lệnh>" ["<câu lệnh>" ...]
Sau mỗi thay đổi, chạy Run Once Now trên custom table tương ứng để tạo snapshot mới (mỗi report đọc một bảng riêng nên phải chạy riêng từng bảng), rồi đối chiếu snapshot trước và sau trên report hoặc query lọc, và với Policy rule violations.
6.1. Kịch bản 1 – Oracle: cấp quyền object mới
Chủ schema RETAIL cấp thêm quyền UPDATE trên ORDERS cho OPS_TEST (trước đó chỉ có SELECT). Kiểm tra Guardium ghi nhận đúng thay đổi và biết ai cấp.
Bước 1: Kiểm tra quyền của OPS_TEST trên ORDERS bằng SYSTEM, cấp quyền bằng RETAIL rồi kiểm tra lại:
-- SYSTEM (trước và sau khi cấp)Bước 1: Kiểm tra quyền của OPS_TEST trên ORDERS bằng SYSTEM, cấp quyền bằng RETAIL rồi kiểm tra lại:
SELECT grantee, table_name, privilege, grantor FROM dba_tab_privs
WHERE grantee = 'OPS_TEST' AND table_name = 'ORDERS';
-- RETAIL
GRANT UPDATE ON retail.orders TO ops_test;
Hình 8: RETAIL cấp quyền UPDATE trên ORDERS cho OPS_TEST lúc 18:12:11
Bước 2: Run Once Now cho ORA Object privileges (snapshot T1), mở query Q_ENT_OBJPRIV_OPS (Grantee = OPS_TEST).
Hình 9: Q_ENT_OBJPRIV_OPS: quyền UPDATE chỉ có ở snapshot 18:14:30
Bước 3: Mở Policy rule violations quanh thời điểm cấp quyền.
Hình 10: DET_PRIV_ESCALATION ghi nhận lệnh GRANT lúc 18:12:12
Đánh giá: Guardium phát hiện đúng quyền UPDATE mới của OPS_TEST trên ORDERS ở snapshot ngay sau khi cấp; snapshot cũ vẫn chỉ có SELECT nên thấy rõ trạng thái trước và sau. Policy bổ sung thời điểm, Client IP và câu lệnh GRANT đầy đủ.
6.2. Kịch bản 2 – Oracle: quyền kế thừa qua role
OPS_TEST nhận system privilege SELECT ANY TABLE gián tiếp qua một role mới thay vì được cấp trực tiếp.
Bước 1: SYSTEM kiểm tra role của OPS_TEST, tạo role, cấp SELECT ANY TABLE cho role và gán role cho OPS_TEST; OPS_TEST đăng nhập kiểm tra quyền trong phiên:
-- SYSTEMBước 1: SYSTEM kiểm tra role của OPS_TEST, tạo role, cấp SELECT ANY TABLE cho role và gán role cho OPS_TEST; OPS_TEST đăng nhập kiểm tra quyền trong phiên:
SELECT grantee, granted_role FROM dba_role_privs WHERE grantee = 'OPS_TEST';
CREATE ROLE retail_support_role;
GRANT SELECT ANY TABLE TO retail_support_role;
GRANT retail_support_role TO ops_test;
-- OPS_TEST
SELECT * FROM session_privs WHERE privilege = 'SELECT ANY TABLE';
Hình 11: SYSTEM tạo RETAIL_SUPPORT_ROLE và gán cho OPS_TEST; OPS_TEST có SELECT ANY TABLE trong phiên
Bước 2: Run Once Now cho ORA Roles Granted và ORA Sys Priv Granted 8 (snapshot T2); mở query RETAIL_SUPPORT_ROLE (lọc ORA Roles Granted theo Granted Role = RETAIL_SUPPORT_ROLE) và query Q_ENT_SYSPRIV_OPS (GRANTEE = OPS_TEST hoặc RETAIL_SUPPORT_ROLE).
Hình 12: Query RETAIL_SUPPORT_ROLE (lọc ORA Roles Granted): OPS_TEST và SYSTEM giữ role ở snapshot 18:35:20
Hình 13: Q_ENT_SYSPRIV_OPS: chuỗi OPS_TEST → RETAIL_SUPPORT_ROLE → SELECT ANY TABLE ở snapshot 18:38:45
Bước 3: Mở Policy rule violations quanh thời điểm chạy lệnh.
Hình 14: DET_PRIV_ESCALATION ghi nhận hai lệnh GRANT lúc 18:32:09, không có lệnh CREATE ROLE
Đánh giá: Guardium ghi đúng từng mắt xích OPS_TEST → RETAIL_SUPPORT_ROLE → SELECT ANY TABLE nhưng không tính quyền hiệu lực, người rà soát phải tự lần chuỗi; chỉ lọc theo OPS_TEST dễ đánh giá thấp rủi ro. Policy không cảnh báo lệnh CREATE ROLE vì GRP_PRIV_CMDS thiếu lệnh này.
6.3. Kịch bản 3 – Oracle: thu hồi quyền và so sánh snapshot
Thu hồi các quyền đã cấp ở kịch bản 1 và 2, kiểm tra snapshot mới phản ánh đúng trạng thái hiện hành còn snapshot cũ vẫn được giữ.
Bước 1: Thu hồi quyền rồi kiểm tra lại bằng SYSTEM:
-- SYSTEMBước 1: Thu hồi quyền rồi kiểm tra lại bằng SYSTEM:
REVOKE retail_support_role FROM ops_test;
-- RETAIL
REVOKE UPDATE ON retail.orders FROM ops_test;
-- SYSTEM (kiểm tra)
SELECT grantee, granted_role FROM dba_role_privs WHERE grantee = 'OPS_TEST';
SELECT table_name, privilege FROM dba_tab_privs
WHERE grantee = 'OPS_TEST' AND table_name = 'ORDERS';
Hình 15: Thu hồi role và quyền UPDATE của OPS_TEST, kiểm tra lại lúc 20:51:03
Bước 2: Run Once Now cho ORA Object privileges và ORA Sys Priv Granted 8 (snapshot T3); mở Q_ENT_OBJPRIV_OPS và Q_ENT_SYSPRIV_OPS.
Hình 16: Q_ENT_OBJPRIV_OPS: ORDERS chỉ còn SELECT ở snapshot 20:53:12, UPDATE vẫn lưu ở snapshot 18:14:30
Hình 17: Q_ENT_SYSPRIV_OPS: OPS_TEST không còn RETAIL_SUPPORT_ROLE ở snapshot 21:00:32
Bước 3: Mở Policy rule violations quanh thời điểm thu hồi.
Hình 18: DET_PRIV_ESCALATION ghi nhận hai lệnh REVOKE lúc 20:50:47 và 20:51:01
Đánh giá: Snapshot mới phản ánh đúng việc thu hồi, snapshot cũ vẫn lưu UPDATE trên ORDERS và RETAIL_SUPPORT_ROLE làm bằng chứng quyền từng tồn tại. Role không còn ai giữ nhưng vẫn mang SELECT ANY TABLE là rủi ro, đã được xóa sau kiểm thử.
6.4. Kịch bản 4 – SQL Server: gán sysadmin
Login thường ops_test được đưa vào server role sysadmin, quyền cao nhất trên instance.
Bước 1: sa kiểm tra thành viên sysadmin, gán sysadmin cho ops_test; ops_test đăng nhập kiểm tra:
-- sa (master)Bước 1: sa kiểm tra thành viên sysadmin, gán sysadmin cho ops_test; ops_test đăng nhập kiểm tra:
SELECT m.name AS member FROM sys.server_role_members rm
JOIN sys.server_principals r ON rm.role_principal_id = r.principal_id
JOIN sys.server_principals m ON rm.member_principal_id = m.principal_id
WHERE r.name = 'sysadmin';
ALTER SERVER ROLE sysadmin ADD MEMBER [ops_test];
-- ops_test
SELECT SUSER_SNAME() AS login_name, IS_SRVROLEMEMBER('sysadmin') AS is_sysadmin;
Hình 19: sa kiểm tra sysadmin (6 thành viên) rồi đưa ops_test vào sysadmin; ops_test có is_sysadmin = 1
Bước 2: Run Once Now cho Microsoft SQL Server Srv Account of sys/server/security admin (datasource DS_ENT_MSSQL_MASTER).
Hình 20: ops_test xuất hiện trong danh sách sysadmin ở snapshot 21:05:06
Bước 3: Mở Policy rule violations, sau đó gỡ quyền: ALTER SERVER ROLE sysadmin DROP MEMBER [ops_test];
Hình 21: Policy rule violations từ 18:09 đến 21:09: không có vi phạm cho lệnh ALTER SERVER ROLE
Đánh giá: Entitlement report phát hiện ops_test bị gán sysadmin ở snapshot kế tiếp, nhưng policy không cảnh báo vì GRP_PRIV_CMDS chỉ có ALTER ROLE, thiếu ALTER SERVER ROLE (kịch bản 5 cho thấy S-TAP vẫn ghi nhận bình thường). Cần bổ sung ALTER SERVER ROLE vào group.
6.5. Kịch bản 5 – SQL Server: gán db_owner trong RetailDB
intern_test, tài khoản không được phép theo nghiệp vụ, được thêm vào db_owner của RetailDB. Kịch bản này đối chứng với kịch bản 4 vì lệnh ALTER ROLE có trong GRP_PRIV_CMDS.
Bước 1: sa kiểm tra thành viên db_owner, db_securityadmin (truy vấn ở mục 4.3), thêm intern_test vào db_owner; intern_test đăng nhập kiểm tra:
-- sa (RetailDB)Bước 1: sa kiểm tra thành viên db_owner, db_securityadmin (truy vấn ở mục 4.3), thêm intern_test vào db_owner; intern_test đăng nhập kiểm tra:
ALTER ROLE db_owner ADD MEMBER [intern_test];
-- intern_test
SELECT USER_NAME() AS db_user, IS_ROLEMEMBER('db_owner') AS is_db_owner;
Hình 22: sa thêm intern_test vào db_owner; intern_test có is_db_owner = 1
Bước 2: Run Once Now cho Microsoft SQL Server Account Of db_owner db_securityadmin Role (datasource DS_ENT_MSSQL_RETAILDB).
Hình 23: intern_test xuất hiện trong db_owner ở snapshot 21:12:24
Bước 3: Mở Policy rule violations, sau đó gỡ quyền: ALTER ROLE db_owner DROP MEMBER [intern_test];
Hình 24: DET_PRIV_ESCALATION ghi nhận lệnh ALTER ROLE lúc 21:10:38
Đánh giá: Cả entitlement report và policy đều phát hiện intern_test được thêm vào db_owner, xác nhận nguyên nhân ở kịch bản 4 là policy thiếu lệnh. intern_test có toàn quyền trên RetailDB, kể cả bảng chứa CCCD và số thẻ: rủi ro Cao.
6.6. Kịch bản 6 – Cấp quyền cho PUBLIC trên dữ liệu nhạy cảm
Bảng CUSTOMERS chứa CCCD, số điện thoại và email được cấp SELECT cho PUBLIC trên cả hai CSDL, tức mọi tài khoản đều đọc được.
Bước 1: Kiểm tra quyền PUBLIC trên object nghiệp vụ (truy vấn ở mục 4.3), cấp quyền rồi kiểm tra lại trên từng CSDL:
-- Oracle, RETAILBước 1: Kiểm tra quyền PUBLIC trên object nghiệp vụ (truy vấn ở mục 4.3), cấp quyền rồi kiểm tra lại trên từng CSDL:
GRANT SELECT ON retail.customers TO PUBLIC;
-- SQL Server, sa (RetailDB)
GRANT SELECT ON retail.customers TO public;
Hình 25: Kiểm tra, cấp SELECT trên CUSTOMERS cho PUBLIC rồi kiểm tra lại trên Oracle và SQL Server
Bước 2: Run Once Now cho ORA Object Access By PUBLIC và Microsoft SQL Server Object Access By PUBLIC; mở Q_ENT_ORA_PUBLIC (Owner = RETAIL) và Q_ENT_MSS_PUBLIC (Schema_Owner = retail).
Hình 26: Q_ENT_MSS_PUBLIC và Q_ENT_ORA_PUBLIC chỉ còn một dòng CUSTOMERS | SELECT
Bước 3: Mở Policy rule violations, sau đó thu hồi:
REVOKE SELECT ON retail.customers FROM PUBLIC; -- OracleREVOKE SELECT ON retail.customers FROM public; -- SQL Server
Hình 27: Policy rule violations: lệnh GRANT … TO PUBLIC và các vi phạm Data Exfiltration do upload ORA Object Access By PUBLIC
- Các vi phạm Data Exfiltration từ 21:18:29 đến 21:18:41 trong Hình 27 đến từ IP của Guardium: đó là câu truy vấn upload ORA Object Access By PUBLIC (đọc sys.obj$, sys.user$, sys.objauth$, sys.table_privilege_map) trả về khoảng 41.500 dòng, vượt ngưỡng 5.000 bản ghi một phiên của rule. Đây là dương tính giả do chính tài khoản kỹ thuật; nên loại trừ GUARDIUM_ENT hoặc IP của Guardium khỏi rule bằng một group riêng thay vì tắt rule. Câu truy vấn này cũng cho thấy các bảng dictionary đã cấp cho GUARDIUM_ENT ở mục 4.1 là bắt buộc.
Đánh giá: Query lọc theo schema nghiệp vụ tìm ra đúng quyền rủi ro cao (CUSTOMERS cấp SELECT cho PUBLIC) giữa hàng chục nghìn quyền mặc định. Policy ghi nhận đủ lệnh GRANT trên cả hai CSDL, kèm cảnh báo truy cập dữ liệu nhạy cảm cho lệnh của sa.
6.7. Kịch bản 7 – Cấp rồi thu hồi DBA giữa hai snapshot
Chứng minh giới hạn của snapshot: quyền tồn tại ngắn giữa hai lần upload không được entitlement report ghi nhận.
Bước 1: SYSTEM cấp DBA cho INTERN_TEST, INTERN_TEST kiểm tra role trong phiên, SYSTEM thu hồi ngay rồi kiểm tra lại:
-- SYSTEMBước 1: SYSTEM cấp DBA cho INTERN_TEST, INTERN_TEST kiểm tra role trong phiên, SYSTEM thu hồi ngay rồi kiểm tra lại:
GRANT DBA TO intern_test;
-- INTERN_TEST
SELECT role FROM session_roles WHERE role = 'DBA';
-- SYSTEM
REVOKE DBA FROM intern_test;
SELECT grantee, granted_role FROM dba_role_privs WHERE grantee = 'INTERN_TEST';
Hình 28: INTERN_TEST giữ role DBA trong 7 giây (21:31:44 – 21:31:51)
Bước 2: Run Once Now cho ORA Roles Granted sau khi thu hồi; mở query Q_ENT_ROLES_DBA (Granted Role = DBA).
Hình 29: Q_ENT_ROLES_DBA: chỉ SYS và SYSTEM giữ DBA ở cả hai snapshot
Bước 3: Mở Policy rule violations quanh thời điểm chạy lệnh.
Hình 30: DET_PRIV_ESCALATION ghi nhận GRANT DBA lúc 21:31:45 và REVOKE DBA lúc 21:31:52
Đánh giá: INTERN_TEST giữ DBA 7 giây giữa hai snapshot nên Q_ENT_ROLES_DBA không ghi nhận; chỉ policy lưu lại lệnh GRANT và REVOKE DBA. Entitlement report chỉ phản ánh trạng thái lúc chụp, cần kết hợp policy giám sát lệnh phân quyền.