TỰ ĐỘNG GHI NHẬN CÁC THAY ĐỔI LIÊN QUAN ĐẾN NGƯỜI DÙNG VÀ CSDL TRÊN ORACLE DATABASE VÀ MICROSOFT SQL SERVER
1. Mục tiêu
- Ghi nhận tự động, theo thời gian thực mọi thay đổi tài khoản, phân quyền (tạo, sửa, xóa user, login, role; GRANT, REVOKE, DENY; đổi mật khẩu, khóa và mở khóa tài khoản) và thay đổi cấu trúc CSDL (bảng, view, thủ tục, schema, cấu hình kiểm toán) trên Oracle Database và Microsoft SQL Server.
- Mỗi thay đổi trả lời được câu hỏi kiểm toán: ai thực hiện, từ máy nào, bằng chương trình nào, lúc nào, trên máy chủ và CSDL nào, câu lệnh đầy đủ là gì.
- Cảnh báo ngay thay đổi rủi ro cao: gán DBA, sysadmin, db_owner, quyền ANY, WITH ADMIN/GRANT OPTION, sửa cấu trúc bảng nhạy cảm, phân quyền qua thủ tục hệ thống hoặc dynamic SQL.
- Tự động tổng hợp báo cáo thay đổi hằng ngày bằng Audit Process, xuất PDF/CSV và yêu cầu người phụ trách ký duyệt.
- Kiểm tra độ phủ: xác định các cách thay đổi có thể lọt khỏi giám sát và biện pháp bù.
2. Nguyên lý hoạt động
S-TAP sao chép mọi câu lệnh client gửi tới CSDL về Collector. Collector tách câu lệnh thành lệnh (SQL Verb) và đối tượng (Object), rồi đối chiếu với rule của các policy đang cài theo thứ tự cài đặt.
Thành phần | Vai trò |
| S-TAP trên oracledb01, SQLDB01 | Sao chép lưu lượng SQL giữa client và CSDL gửi về Collector, không phụ thuộc cơ chế audit của CSDL |
| Bộ phân tích cú pháp trên Collector | Tách câu lệnh thành SQL Verb (CREATE USER, GRANT, ALTER TABLE…) và Object; ghi dạng rút gọn (giá trị thay bằng ?) vào domain Access |
| Policy POL_AUDIT_DB_CHANGES | Rule LOG FULL DETAILS / LOG MASKED DETAILS ghi từng câu lệnh kèm thời điểm chính xác (MASKED thì giá trị thay bằng ?); rule ALERT PER MATCH ghi vi phạm vào domain Policy Violations |
| Query-Report Builder, dashboard | Báo cáo thay đổi theo người dùng, máy chủ, loại lệnh; đối chiếu độ phủ |
| Audit Process | Chạy báo cáo định kỳ, xuất PDF/CSV, gửi người nhận và yêu cầu ký duyệt |
Hai giới hạn cần nắm:
- Guardium chỉ thấy câu lệnh trên kết nối mà S-TAP thu thập được. Lệnh do CSDL tự thực thi bên trong (dynamic SQL trong PL/SQL hay T-SQL, thủ tục lưu trữ, job) không đi qua kết nối thành câu riêng (kịch bản 8).
- Rule theo Command so khớp tên lệnh Guardium ghi nhận; tên khác thành viên của group thì rule không khớp. Q_CHG_COVERAGE (mục 4.5) dùng để tìm lệnh bị sót.
Hình 1: Nguyên lý ghi nhận thay đổi tài khoản và cấu trúc CSDL bằng policy POL_AUDIT_DB_CHANGES
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> | Chạy policy ghi nhận thay đổi, lưu vết kiểm toán, báo cáo và Audit Process |
| Oracle Database 19c trên Oracle Linux (non-CDB, service orcl) | oracledb01 / <IP_ORACLE> | CSDL được giám sát, S-TAP Linux |
| Microsoft SQL Server trên Windows Server (RetailDB, schema retail) | SQLDB01 / <IP_MSSQL> | CSDL được giám sát, S-TAP Windows |
3.2. Tài khoản sử dụng
Tài khoản | CSDL | Vai trò trong bài |
| SYSTEM | Oracle | DBA thực hiện thay đổi tài khoản, phân quyền (kết nối qua listener); kịch bản 9 dùng SYS (/ as sysdba) |
| RETAIL | Oracle | Chủ schema, thực hiện thay đổi cấu trúc bảng; thuộc GRP_AUTHORIZED_USERS |
| sa | MSSQL | DBA thực hiện thay đổi login, role, cấu trúc |
| DEV_TEST / dev_test (tạo trong kịch bản) | Oracle, MSSQL | Tài khoản mới, bị thay đổi quyền trong các kịch bản |
| OPS_TEST | MSSQL | Được cấp rồi thu hồi quyền trên bảng tạm ở kịch bản 7 |
4. Cấu hình Guardium
4.1. Kiểm tra S-TAP và Inspection Engine
Bước 1: Truy cập Manage → Activity Monitoring → S-TAP Control, kiểm tra S-TAP của oracledb01 và SQLDB01 ở trạng thái xanh.
Bước 2: Mở phần Inspection Engines của từng S-TAP: oracledb01 có engine Oracle cổng 1521, SQLDB01 có engine MS SQL Server cổng 1433.
Bước 3: Ghi lại giá trị DB Install Dir và Process Name của engine Oracle để đối chiếu ở kịch bản 9. Trên lab: DB Install Dir = /u01/app/oracle/product/19.0.0/dbhome_1, Process Name = /u01/app/oracle/product/19.0.0/dbhome_1/bin/oracle.
Bước 2: Mở phần Inspection Engines của từng S-TAP: oracledb01 có engine Oracle cổng 1521, SQLDB01 có engine MS SQL Server cổng 1433.
Bước 3: Ghi lại giá trị DB Install Dir và Process Name của engine Oracle để đối chiếu ở kịch bản 9. Trên lab: DB Install Dir = /u01/app/oracle/product/19.0.0/dbhome_1, Process Name = /u01/app/oracle/product/19.0.0/dbhome_1/bin/oracle.
Hình 2: Hai S-TAP ở trạng thái xanh và Inspection Engine Oracle của oracledb01 trong S-TAP Control
4.2. Tạo group
Truy cập Setup → Tools and Views → Group Builder, nhấn + và tạo ba group sau (Application type = Public):
Tên group | Group Type | Thành viên |
| GRP_CHG_USER_PRIV_CMDS | COMMANDS | GRANT, REVOKE, DENY, CREATE USER, ALTER USER, DROP USER, CREATE ROLE, ALTER ROLE, DROP ROLE, CREATE PROFILE, ALTER PROFILE, DROP PROFILE, CREATE LOGIN, ALTER LOGIN, DROP LOGIN, CREATE SERVER ROLE, ALTER SERVER ROLE, DROP SERVER ROLE, ALTER AUTHORIZATION |
| GRP_CHG_DDL_CMDS | COMMANDS | CREATE TABLE, ALTER TABLE, DROP TABLE, TRUNCATE TABLE, RENAME, CREATE VIEW, ALTER VIEW, DROP VIEW, CREATE INDEX, DROP INDEX, CREATE PROCEDURE, ALTER PROCEDURE, DROP PROCEDURE, CREATE FUNCTION, ALTER FUNCTION, DROP FUNCTION, CREATE TRIGGER, ALTER TRIGGER, DROP TRIGGER, CREATE PACKAGE, CREATE PACKAGE BODY, DROP PACKAGE, CREATE SYNONYM, DROP SYNONYM, CREATE SCHEMA, ALTER SCHEMA, DROP SCHEMA, CREATE DATABASE, ALTER DATABASE, DROP DATABASE, ALTER SYSTEM, AUDIT, NOAUDIT, CREATE SERVER AUDIT, ALTER SERVER AUDIT, DROP SERVER AUDIT |
| GRP_CHG_ADMIN_PROCS | OBJECTS | %sp_addlogin, %sp_droplogin, %sp_password, %sp_addsrvrolemember, %sp_dropsrvrolemember, %sp_addrolemember, %sp_droprolemember, %sp_adduser, %sp_dropuser, %sp_grantdbaccess, %sp_revokedbaccess, %sp_change_users_login, %sp_configure |
- Không dùng lại GRP_PRIV_CMDS đã có trong lab vì group này thiếu DROP USER, DENY, CREATE/DROP ROLE và các lệnh server role; giữ nguyên GRP_PRIV_CMDS để không đổi hành vi của rule DET_PRIV_ESCALATION đang cài.
- Thành viên group lệnh phải trùng tên SQL Verb Guardium ghi nhận; sau mỗi kịch bản, dùng Q_CHG_COVERAGE (mục 4.5) để đối chiếu và bổ sung tên còn thiếu.
- GRP_CHG_ADMIN_PROCS có dấu % phía trước vì Guardium có thể ghi tên thủ tục kèm schema (sys.sp_addsrvrolemember), giống GRP_SENSITIVE_OBJECTS đã có trong lab.
- Không tạo group IP máy chủ vì Collector chỉ nhận dữ liệu từ hai S-TAP; khi giám sát thêm máy chủ ngoài phạm vi thì thêm điều kiện Server IP In Group.
Hình 3: Ba group GRP_CHG_* trong Group Builder
4.3. Tạo policy POL_AUDIT_DB_CHANGES
Bước 1: Truy cập Protect → Security Policies → Policy Builder for Data, nhấn New, đặt Policy Description = POL_AUDIT_DB_CHANGES.
Bước 2: Thêm bảy access rule theo bảng dưới. Ở mọi rule đặt Category = DB Change Audit và tích Continue to next rule.
Bước 2: Thêm bảy access rule theo bảng dưới. Ở mọi rule đặt Category = DB Change Audit và tích Continue to next rule.
# | Rule | Điều kiện | Hành động |
1 | AUD_LOG_USER_PRIV | Command In Group GRP_CHG_USER_PRIV_CMDS | LOG MASKED DETAILS |
2 | AUD_LOG_SCHEMA | Command In Group GRP_CHG_DDL_CMDS | LOG FULL DETAILS |
3 | AUD_ADMIN_PROCS | Object In Group GRP_CHG_ADMIN_PROCS | LOG FULL DETAILS + ALERT PER MATCH (HIGH) |
4 | AUD_ALERT_ORA_HIGH_PRIV | Command In Group GRP_CHG_USER_PRIV_CMDS; SQL Pattern = P1 | ALERT PER MATCH (HIGH) |
5 | AUD_ALERT_MSS_HIGH_PRIV | Command In Group GRP_CHG_USER_PRIV_CMDS; SQL Pattern = P2 | ALERT PER MATCH (HIGH) |
6 | AUD_ALERT_SENSITIVE_DDL | Command In Group GRP_CHG_DDL_CMDS; Object In Group GRP_SENSITIVE_OBJECTS | ALERT PER MATCH (MED) |
7 | AUD_ALERT_DYNAMIC_SQL | SQL Pattern = P3 | LOG FULL DETAILS + ALERT PER MATCH (HIGH) |
Các mẫu SQL Pattern (nhập liền trên một dòng):
Mẫu | SQL Pattern | Khớp với |
P1 | [Dd][Bb][Aa][ ,]| [Aa][Nn][Yy] |[Oo][Pp][Tt][Ii][Oo][Nn] | GRANT/REVOKE DBA, SYSDBA; quyền … ANY …; WITH ADMIN OPTION, WITH GRANT OPTION |
P2 | [Ss][Yy][Ss][Aa][Dd][Mm][Ii][Nn]|[Ss][Ee][Cc][Uu][Rr][Ii][Tt][Yy][Aa][Dd][Mm][Ii][Nn]|[Dd][Bb]_[Oo][Ww][Nn][Ee][Rr]|[Cc][Oo][Nn][Tt][Rr][Oo][Ll] [Ss][Ee][Rr][Vv][Ee][Rr] | sysadmin, securityadmin, db_securityadmin, db_owner, CONTROL SERVER |
P3 | ([Ii][Mm][Mm][Ee][Dd][Ii][Aa][Tt][Ee]|[Ee][Xx][Ee][Cc][Uu][Tt][Ee][Ss][Qq][Ll]|[Ee][Xx][Ee][Cc] *[(]) *N?'(GRANT|REVOKE|DENY|CREATE|ALTER|DROP|grant|revoke|deny|create|alter|drop) | EXECUTE IMMEDIATE '…', EXEC('…'), sp_executesql N'…' có chuỗi bắt đầu bằng lệnh thay đổi |
- Continue to next rule ở mọi rule: policy này được cài đầu tiên (mục 4.4); nếu dừng ở đây, các rule che, chặn và phát hiện của các policy cài sau sẽ không chạy.
- Tách ghi nhận và cảnh báo: rule 1–3 ghi mọi thay đổi làm vết kiểm toán, rule 3–7 chỉ cảnh báo thay đổi rủi ro cao để tránh quá tải cảnh báo. CREATE USER, GRANT, REVOKE thông thường đã có cảnh báo DET_PRIV_ESCALATION trong POL_PROTECT_SENSITIVE_DATA đang cài.
- LOG MASKED DETAILS cho lệnh tài khoản: Guardium ghi câu lệnh nhưng thay giá trị chuỗi bằng ?, để mật khẩu trong CREATE LOGIN … PASSWORD = '…' không nằm trong vết kiểm toán; GRANT, REVOKE không chứa giá trị nên không mất thông tin. Riêng mật khẩu thì Guardium tự che thành ***, kể cả ở cột Sql của Q_CHG_COVERAGE và ở vi phạm DET_PRIV_ESCALATION (kịch bản 1, 2, 5), không phụ thuộc rule này.
- Câu lệnh lỗi (ví dụ mật khẩu không đạt chính sách) được ghi vào domain Exception kèm câu SQL; bật che giá trị bằng lệnh CLI store snif_mask_sql_value on, kiểm tra bằng show snif_mask_sql_value.
- Rule 3 và 7 dùng LOG FULL DETAILS để giữ tham số thủ tục (tên login, role) và chuỗi lệnh dynamic SQL; trên lab Full Sql của lời gọi thủ tục SQL Server vẫn hiện tham số dạng ? (kịch bản 6).
- P1, P2 đi kèm Command In Group để không bắt nhầm truy vấn nội bộ của SSMS như IS_SRVROLEMEMBER('sysadmin'). P1 viết [Dd][Bb][Aa][ ,] để không khớp tên view DBA_USERS, DBA_ROLE_PRIVS khi cấp quyền đọc các view này cho GUARDIUM_ENT; " [Aa][Nn][Yy] " có dấu cách hai bên để không khớp tên như COMPANY.
- SQL Pattern phân biệt chữ hoa, chữ thường nên mỗi ký tự viết dạng [Xx] như rule DET_SQLI_PATTERN đang cài. P3 chỉ khớp chuỗi lệnh viết toàn hoa hoặc toàn thường; câu sp_executesql N'SELECT …' mà ứng dụng dùng cho truy vấn có tham số không bị bắt.
Hình 4: Rule 2–7 của POL_AUDIT_DB_CHANGES trong Policy Builder
Bước 3: Nhấn Save.
Hình 5: POL_AUDIT_DB_CHANGES với 7 rule trong danh sách policy
4.4. Cài đặt policy theo đúng thứ tự
Install and Override gỡ POL_PROTECT_SENSITIVE_DATA và POL_BASIC_DATA_SECURITY đang cài, nên phải cài lại hai policy này ngay sau đó. Không dùng Install last cho POL_AUDIT_DB_CHANGES: policy sẽ đứng sau BLOCK_DESTRUCTIVE_TERMINATE (không tích Continue), câu ALTER TABLE bị chặn trên bảng nhạy cảm không tới được rule ghi nhận. Policy ghi nhận phải đứng đầu.
Bước 1: Truy cập Protect → Security Policies → Policy Installation, chọn POL_AUDIT_DB_CHANGES, chọn Install and override.
Bước 2: Chọn POL_PROTECT_SENSITIVE_DATA, chọn Install last.
Bước 3: Chọn POL_BASIC_DATA_SECURITY, chọn Install last.
Bước 1: Truy cập Protect → Security Policies → Policy Installation, chọn POL_AUDIT_DB_CHANGES, chọn Install and override.
Bước 2: Chọn POL_PROTECT_SENSITIVE_DATA, chọn Install last.
Bước 3: Chọn POL_BASIC_DATA_SECURITY, chọn Install last.
- Thực hiện liên tiếp bước 1 đến bước 3: trong khoảng này các rule che và chặn của POL_PROTECT_SENSITIVE_DATA tạm thời không hoạt động.
- Mỗi lần sửa POL_AUDIT_DB_CHANGES hoặc thêm thành viên vào group, cài lại theo đúng ba bước này.
- Rule bỏ qua phiên tải nặng (từ 500 lệnh/phút) của POL_BASIC_DATA_SECURITY làm S-TAP ngừng gửi cả phiên; thêm điều kiện loại trừ tài khoản quản trị cho rule đó để script thay đổi hàng loạt vẫn được ghi nhận.
Bước 4: Kiểm tra khung Currently Installed Policies: POL_AUDIT_DB_CHANGES ở vị trí 1 (7 rule), POL_PROTECT_SENSITIVE_DATA ở vị trí 2, POL_BASIC_DATA_SECURITY ở vị trí 3. Kiểm tra lại S-TAP Control vẫn xanh.
Hình 6: Thứ tự cài đặt ba policy trong Policy Installation
4.5. Báo cáo và dashboard
Truy cập Reports → Report Configuration Tools → Query-Report Builder, tạo các query sau:
Query | Domain | Cột | Điều kiện |
| Q_CHG_USER_PRIV | Access | Timestamp (entity Full SQL), Full Sql, Server Type, Server IP, Service Name, DB User Name, OS User, Client IP, Source Program, SQL Verb, Object Name (hai cột cuối hiển thị dạng Count of SQL Verb, Count of Object Name) | SQL Verb IN GROUP GRP_CHG_USER_PRIV_CMDS; sắp xếp theo Timestamp giảm dần |
| Q_CHG_SCHEMA | Access | Như Q_CHG_USER_PRIV | SQL Verb IN GROUP GRP_CHG_DDL_CMDS |
| Q_CHG_ADMIN_PROCS | Access | Như Q_CHG_USER_PRIV | Object Name LIKE GROUP GRP_CHG_ADMIN_PROCS |
| Q_CHG_VIOLATIONS | Policy Violations | Timestamp, Access Rule Description, Severity Description, Server IP, DB User Name, Client IP, Full SQL String | Category Name = DB Change Audit |
| Q_CHG_COVERAGE | Access | Server IP, DB User Name, SQL Verb, Sql, Object Name (hiển thị dạng Count of Object Name); tích Count (cột Total access) | DB User Name = tham số khi chạy (SYSTEM, SA, RETAIL…); không lọc theo group |
- Q_CHG_USER_PRIV, Q_CHG_SCHEMA, Q_CHG_ADMIN_PROCS đọc cột Full Sql nên chỉ có câu đã được rule LOG … DETAILS ghi; Q_CHG_COVERAGE đọc cột Sql (dạng rút gọn) nên có mọi câu S-TAP gửi về, kể cả câu không khớp rule nào.
- Đối chiếu độ phủ: câu thay đổi có trong Q_CHG_COVERAGE mà không có trong Q_CHG_USER_PRIV / Q_CHG_SCHEMA là do tên SQL Verb chưa có trong group: thêm đúng giá trị ở cột SQL Verb vào group rồi cài lại policy (mục 4.4).
- Câu lệnh bị CSDL từ chối vẫn có trong các query trên; để biết thay đổi có thành công không, đối chiếu cùng thời điểm với query lỗi SQL Q_SRV_SQL_ERRORS đã có trong lab.
Bước 1: Tạo dashboard tại My Dashboards → Create New Dashboard, đặt tên DB Change Audit, mở từng query và chọn Add to Dashboard.
Bước 2: Ở mỗi report, mở Customize và đặt khoảng thời gian bao trùm lúc kiểm thử.
Bước 2: Ở mỗi report, mở Customize và đặt khoảng thời gian bao trùm lúc kiểm thử.
Hình 7: Dashboard DB Change Audit với năm report
4.6. Tự động gửi báo cáo bằng Audit Process
Bước 1: Truy cập Comply → Tools and Views → Audit Process Builder, nhấn New và khai báo theo bảng dưới.
Trường | Giá trị |
| Description | AP_DB_CHANGE_AUDIT |
| Receivers | admin (hoặc nhóm Security Team), Action Required = Sign off, bỏ tích Continuous, Email = Links only |
| Tasks | Bốn task loại Report: Q_CHG_USER_PRIV, Q_CHG_SCHEMA, Q_CHG_ADMIN_PROCS, Q_CHG_VIOLATIONS. Ở mỗi task đặt QUERY_FROM_DATE = NOW -1 DAY, QUERY_TO_DATE = NOW, tích Export PDF và Export CSV |
| Schedule | Hằng ngày (Repeats every day) |
Hình 8: Cấu hình Audit Process AP_DB_CHANGE_AUDIT với bốn task Report
Bước 2: Nhấn Save, sau đó nhấn Run Once Now để kiểm tra.
Bước 3: Mở To-Do List, mở kết quả của AP_DB_CHANGE_AUDIT, xem từng task, tải file PDF/CSV và nhấn Sign off.
Bước 3: Mở To-Do List, mở kết quả của AP_DB_CHANGE_AUDIT, xem từng task, tải file PDF/CSV và nhấn Sign off.
- Khoảng thời gian của task bằng chu kỳ lịch chạy (1 ngày) để mỗi thay đổi nằm trong một kỳ báo cáo, không trùng lặp giữa các kỳ.
- Gửi email cần cấu hình SMTP tại Setup → Tools and Views → Alerter. Lab chưa cấu hình nên kiểm tra kết quả qua To-Do List.
- Muốn lưu CSV ra máy chủ khác (SIEM, lưu trữ dài hạn), dùng chức năng Results Export của Guardium.
5. Kịch bản kiểm thử
Mọi lệnh chạy qua listener/TCP (trừ kịch bản 9). Ghi lại thời điểm chạy từng kịch bản để lọc báo cáo; sau mỗi kịch bản mở dashboard DB Change Audit và Q_CHG_COVERAGE để đối chiếu. Trên SQL Server, mỗi câu kết thúc bằng GO để thành một batch riêng, tức một dòng riêng trong báo cáo.
Kết nối dùng chung (sqlplus chạy trên oracledb01, sqlcmd chạy trên máy quản trị; nhập mật khẩu khi được hỏi):sqlplus system@//<IP_ORACLE>:1521/orcl
sqlplus retail@//<IP_ORACLE>:1521/orcl
sqlcmd -S <IP_MSSQL>,1433 -U sa -No -C
KB | CSDL | Thay đổi | Thực hiện bởi |
1 | Oracle | Tạo user, cấp role và DBA | SYSTEM |
2 | Oracle | Khóa, đổi mật khẩu và mở khóa tài khoản, thu hồi DBA | SYSTEM |
3 | Oracle | Thêm, xóa cột trên bảng nhạy cảm EMPLOYEES | RETAIL; SYSTEM để kiểm chứng thứ tự policy |
4 | Oracle | Sao chép bảng CUSTOMERS bằng CREATE TABLE … AS SELECT, xóa bản sao | RETAIL |
5 | MSSQL | Tạo login, gán sysadmin, tạo user | sa |
6 | MSSQL | Phân quyền bằng thủ tục hệ thống | sa |
7 | MSSQL | Tạo bảng, cấp và thu hồi quyền, sửa, làm rỗng, xóa bảng | sa |
8 | Cả hai | Phân quyền qua dynamic SQL | SYSTEM, sa |
9 | Cả hai | Thay đổi qua kết nối cục bộ | SYS (/ as sysdba), tài khoản Windows |
5.1. Kịch bản 1 – Oracle: tạo user và cấp quyền
DBA tạo tài khoản mới rồi cấp quyền vượt mức cần thiết (DBA).
Bước 1: Kết nối bằng SYSTEM và chạy:
CREATE USER dev_test IDENTIFIED BY "<MK_DEV_TEST>";Bước 1: Kết nối bằng SYSTEM và chạy:
GRANT CONNECT, RESOURCE TO dev_test;
GRANT DBA TO dev_test;
Hình 9: SYSTEM tạo dev_test và cấp quyền qua sqlplus
Bước 2: Mở Q_CHG_USER_PRIV, Q_CHG_VIOLATIONS và report Policy Violations.
Hình 10: Q_CHG_USER_PRIV ghi nhận ba câu lệnh của kịch bản 1
Hình 11: Policy rule violations có AUD_ALERT_ORA_HIGH_PRIV cho GRANT DBA và ba DET_PRIV_ESCALATION
Bước 3: Mở Q_CHG_COVERAGE với DB User Name = SYSTEM, đối chiếu tên SQL Verb Guardium ghi cho ba câu lệnh.
Đánh giá: Guardium ghi nhận đủ ba câu lệnh kèm người thực hiện, máy và chương trình; chỉ GRANT DBA sinh cảnh báo AUD_ALERT_ORA_HIGH_PRIV, GRANT CONNECT, RESOURCE chỉ được ghi nhận. Mật khẩu trong CREATE USER được che dạng ***, không lộ trong vết kiểm toán.
Đánh giá: Guardium ghi nhận đủ ba câu lệnh kèm người thực hiện, máy và chương trình; chỉ GRANT DBA sinh cảnh báo AUD_ALERT_ORA_HIGH_PRIV, GRANT CONNECT, RESOURCE chỉ được ghi nhận. Mật khẩu trong CREATE USER được che dạng ***, không lộ trong vết kiểm toán.
5.2. Kịch bản 2 – Oracle: thay đổi tài khoản và thu hồi quyền
Mô phỏng chuỗi thao tác thường gặp khi chiếm tài khoản: khóa, đặt lại mật khẩu và mở khóa tài khoản; sau đó thu hồi quyền DBA đã cấp ở kịch bản 1.
Bước 1: Kết nối bằng SYSTEM và chạy:
ALTER USER dev_test ACCOUNT LOCK;Bước 1: Kết nối bằng SYSTEM và chạy:
ALTER USER dev_test IDENTIFIED BY "<MK_DEV_TEST_MOI>" ACCOUNT UNLOCK;
REVOKE DBA FROM dev_test;
Bước 2: Kết nối bằng DEV_TEST với mật khẩu mới (nhập khi được hỏi) để xác nhận thay đổi có hiệu lực:
sqlplus dev_test@//<IP_ORACLE>:1521/orclSQL> SELECT role FROM session_roles;
Hình 12: session_roles của dev_test sau khi thu hồi DBA
Bước 3: Mở Q_CHG_USER_PRIV, Q_CHG_VIOLATIONS và report Policy Violations. Tùy chọn: Run Once Now report entitlement ORA Roles Granted.
Hình 13: Q_CHG_USER_PRIV ghi nhận hai câu ALTER USER và câu REVOKE DBA
Hình 14: Access policy violations có AUD_ALERT_ORA_HIGH_PRIV cho REVOKE DBA và ba DET_PRIV_ESCALATION
Đánh giá: Guardium ghi nhận đủ các thao tác khóa, đặt lại mật khẩu, mở khóa và thu hồi DBA, mật khẩu mới được che; REVOKE DBA cũng bị cảnh báo AUD_ALERT_ORA_HIGH_PRIV. Việc dev_test từng có DBA chỉ còn dấu vết trong Q_CHG_USER_PRIV, snapshot quyền (entitlement) chỉ thấy trạng thái cuối.
5.3. Kịch bản 3 – Oracle: thay đổi cấu trúc bảng nhạy cảm
Chủ schema thêm rồi xóa một cột trên RETAIL.EMPLOYEES, bảng chứa CCCD và lương theo kết quả phân loại dữ liệu (classification).
Bước 1: Kết nối bằng RETAIL và chạy:
ALTER TABLE retail.employees ADD (salary_bonus NUMBER(10,2));Bước 1: Kết nối bằng RETAIL và chạy:
ALTER TABLE retail.employees DROP COLUMN salary_bonus;
Bước 2: Mở Q_CHG_SCHEMA và Q_CHG_VIOLATIONS.
Hình 15: Q_CHG_SCHEMA với các câu ALTER TABLE trên retail.employees, gồm cả câu của bước 3 và bước 4
Hình 16: Q_CHG_VIOLATIONS với các vi phạm AUD_ALERT_SENSITIVE_DDL của hai lần chạy kịch bản 3
Bước 3: Kiểm chứng thứ tự policy: trên máy quản trị, chạy bằng SYSTEM qua script Python uc4_ora.py câu ALTER TABLE, tiếp theo là câu chờ 5 giây và câu SELECT để kiểm tra phiên; sau đó mở Q_CHG_SCHEMA và report Policy Violations:
python uc4_ora.py system "ALTER TABLE retail.employees ADD (chk_col NUMBER(1))" "BEGIN DBMS_SESSION.SLEEP(5); END; --" "SELECT 1 FROM dual"
Hình 17: Câu ALTER TABLE của SYSTEM chạy xong, câu SELECT sau đó báo kết nối bị đóng (DPY-4011)
Hình 18: Q_CHG_SCHEMA ghi nhận câu ALTER TABLE của SYSTEM từ máy quản trị
Hình 19: Access policy violations có BLOCK_DESTRUCTIVE_TERMINATE cho cùng câu lệnh
Bước 4: Xóa cột kiểm chứng bằng RETAIL:
ALTER TABLE retail.employees DROP COLUMN chk_col;Đánh giá: Mọi câu ALTER TABLE trên EMPLOYEES đều được ghi nhận và cảnh báo AUD_ALERT_SENSITIVE_DDL. Câu của SYSTEM (không thuộc GRP_AUTHORIZED_USERS) bị BLOCK_DESTRUCTIVE_TERMINATE ngắt phiên nhưng đã thực thi và vẫn có trong Q_CHG_SCHEMA, chứng tỏ POL_AUDIT_DB_CHANGES được đánh giá trước rule chặn BLOCK_DESTRUCTIVE_TERMINATE.
5.4. Kịch bản 4 – Oracle: sao chép dữ liệu nhạy cảm sang bảng mới
Thay đổi cấu trúc có thể là bước chuẩn bị lấy dữ liệu: tạo bản sao bảng nhạy cảm dưới tên khác để né các rule gắn với tên bảng gốc.
Bước 1: Kết nối bằng RETAIL, tạo bản sao, đếm số dòng rồi xóa bản sao:
CREATE TABLE retail.cust_export AS SELECT * FROM retail.customers;Bước 1: Kết nối bằng RETAIL, tạo bản sao, đếm số dòng rồi xóa bản sao:
SELECT COUNT(*) FROM retail.cust_export;
DROP TABLE retail.cust_export PURGE;
Hình 20: RETAIL tạo, đếm và xóa bảng cust_export
Bước 2: Mở Q_CHG_SCHEMA, Q_CHG_VIOLATIONS và Q_CHG_COVERAGE (DB User Name = RETAIL).
Hình 21: Q_CHG_SCHEMA ghi nhận CREATE TABLE … AS SELECT và DROP TABLE trên cust_export
Hình 22: Q_CHG_VIOLATIONS có AUD_ALERT_SENSITIVE_DDL cho câu CREATE TABLE … AS SELECT
Hình 23: Q_CHG_COVERAGE của RETAIL ghi câu CREATE TABLE … AS SELECT thành hai dòng SQL Verb CREATE TABLE và SELECT
Đánh giá: Guardium ghi nhận việc sao chép CUSTOMERS sang CUST_EXPORT và cảnh báo AUD_ALERT_SENSITIVE_DDL dù câu được tách thành CREATE TABLE và SELECT. Rủi ro cao: bản sao chứa dữ liệu nhạy cảm nhưng không thuộc GRP_SENSITIVE_OBJECTS; nếu bảng được giữ lại, cần chạy lại classification.
5.5. Kịch bản 5 – SQL Server: tạo login và nâng quyền
Quản trị viên tạo login mới, cấp quyền vượt mức cần thiết (sysadmin) và tạo user cho login.
Bước 1: Kết nối bằng sa và chạy (câu cuối gỡ sysadmin ngay sau khi gán):
CREATE LOGIN dev_test WITH PASSWORD = N'<MK_DEV_TEST>', CHECK_POLICY = ON;Bước 1: Kết nối bằng sa và chạy (câu cuối gỡ sysadmin ngay sau khi gán):
GO
ALTER SERVER ROLE sysadmin ADD MEMBER dev_test;
GO
CREATE USER dev_test FOR LOGIN dev_test;
GO
ALTER ROLE db_datareader ADD MEMBER dev_test;
GO
ALTER SERVER ROLE sysadmin DROP MEMBER dev_test;
GO
Hình 24: sa tạo login dev_test, gán rồi gỡ sysadmin bằng sqlcmd
Bước 2: Mở Q_CHG_USER_PRIV, Q_CHG_VIOLATIONS, Q_CHG_COVERAGE (DB User Name = SA) và report Policy Violations.
Hình 25: Q_CHG_USER_PRIV ghi nhận năm câu lệnh của sa, mật khẩu hiển thị dạng ***
Hình 26: Q_CHG_VIOLATIONS có hai vi phạm AUD_ALERT_MSS_HIGH_PRIV khi gán và gỡ sysadmin
Hình 27: Q_CHG_COVERAGE của SA với SQL Verb Guardium ghi cho từng câu
Hình 28: Policy rule violations của kịch bản 5, không có DET_PRIV_ESCALATION cho ALTER SERVER ROLE
- Nếu không có dòng ALTER SERVER ROLE: xem cột SQL Verb của câu này trong Q_CHG_COVERAGE, thêm đúng giá trị vào GRP_CHG_USER_PRIV_CMDS, cài lại policy (mục 4.4) rồi chạy lại câu ALTER SERVER ROLE.
Đánh giá: Guardium ghi nhận đủ năm câu, mật khẩu trong CREATE LOGIN được che; AUD_ALERT_MSS_HIGH_PRIV cảnh báo cả lúc gán và gỡ sysadmin. Rule này bù cho DET_PRIV_ESCALATION, vốn không cảnh báo ALTER SERVER ROLE vì GRP_PRIV_CMDS thiếu lệnh này.
5.6. Kịch bản 6 – SQL Server: phân quyền bằng thủ tục hệ thống
SQL Server vẫn giữ các thủ tục cũ như sp_addsrvrolemember, sp_addrolemember (Microsoft khuyến nghị thay bằng ALTER SERVER ROLE, ALTER ROLE). Câu gọi thủ tục không phải lệnh GRANT hay ALTER ROLE nên rule theo Command bỏ sót.
Bước 1: Kết nối bằng sa và chạy:
EXEC sp_addsrvrolemember 'dev_test', 'securityadmin';Bước 1: Kết nối bằng sa và chạy:
GO
EXEC sp_dropsrvrolemember 'dev_test', 'securityadmin';
GO
USE RetailDB;
GO
EXEC sp_addrolemember 'db_owner', 'dev_test';
GO
EXEC sp_droprolemember 'db_owner', 'dev_test';
GO
Bước 2: Mở Q_CHG_USER_PRIV, Q_CHG_ADMIN_PROCS, Q_CHG_VIOLATIONS và Q_CHG_COVERAGE (DB User Name = SA).
Hình 29: Q_CHG_ADMIN_PROCS ghi nhận các lời gọi thủ tục (cặp db_owner chạy hai lần), tham số hiển thị dạng ?
Hình 30: Q_CHG_VIOLATIONS có vi phạm AUD_ADMIN_PROCS kèm tên login và role
- Tùy chọn: gán role bằng giao diện SSMS (Security → Logins → Properties → Server Roles) và xem Q_CHG_COVERAGE để biết câu lệnh thực tế SSMS gửi xuống.
Đánh giá: AUD_ADMIN_PROCS là rule duy nhất bắt được kiểu phân quyền này, mỗi lời gọi thủ tục có một cảnh báo HIGH. Hạn chế: Full Sql trong Q_CHG_ADMIN_PROCS hiển thị tham số dạng ?, tên login và role chỉ xem được ở Full SQL String của Q_CHG_VIOLATIONS.
5.7. Kịch bản 7 – SQL Server: thay đổi cấu trúc, thu hồi quyền và xóa bảng
Tạo bảng tạm retail.orders_tmp rồi phân quyền, sửa cấu trúc, thu hồi quyền, làm rỗng và xóa bảng; dùng bảng tạm để không làm mất dữ liệu mẫu của lab.
Bước 1: Kết nối bằng sa và chạy:
USE RetailDB;Bước 1: Kết nối bằng sa và chạy:
GO
CREATE TABLE retail.orders_tmp (order_id INT PRIMARY KEY, note NVARCHAR(100));
GO
GRANT SELECT ON retail.orders_tmp TO ops_test;
GO
ALTER TABLE retail.orders_tmp ADD created_at DATETIME2;
GO
REVOKE SELECT ON retail.orders_tmp FROM ops_test;
GO
TRUNCATE TABLE retail.orders_tmp;
GO
DROP TABLE retail.orders_tmp;
GO
Hình 31: Tạo, phân quyền, sửa, làm rỗng và xóa bảng orders_tmp bằng sqlcmd
Bước 2: Mở Q_CHG_SCHEMA, Q_CHG_USER_PRIV và Q_CHG_VIOLATIONS.
Hình 32: Q_CHG_SCHEMA ghi nhận bốn câu trên orders_tmp
Hình 33: Q_CHG_USER_PRIV ghi nhận GRANT và REVOKE trên orders_tmp
Hình 34: Policy rule violations có DET_PRIV_ESCALATION cho GRANT và REVOKE
Đánh giá: Toàn bộ vòng đời bảng tạm và cặp GRANT, REVOKE đều được ghi nhận. ORDERS_TMP không phải bảng nhạy cảm nên không có cảnh báo AUD_ALERT_SENSITIVE_DDL, đúng thiết kế phân tầng ở mục 4.3; GRANT, REVOKE chỉ có cảnh báo DET_PRIV_ESCALATION.
5.8. Kịch bản 8 – Lẩn tránh bằng dynamic SQL
Lệnh phân quyền được đặt trong chuỗi và CSDL tự thực thi bên trong; trên kết nối chỉ có câu gọi bên ngoài (khối BEGIN … END hoặc EXEC).
Bước 1: Oracle, kết nối bằng SYSTEM và chạy:
BEGIN EXECUTE IMMEDIATE 'GRANT SELECT ANY TABLE TO dev_test'; END;Bước 1: Oracle, kết nối bằng SYSTEM và chạy:
/
SELECT privilege FROM dba_sys_privs WHERE grantee = 'DEV_TEST';
BEGIN EXECUTE IMMEDIATE 'REVOKE SELECT ANY TABLE FROM dev_test'; END;
/
Hình 35: SYSTEM cấp và thu hồi SELECT ANY TABLE qua EXECUTE IMMEDIATE
Bước 2: SQL Server, kết nối bằng sa và chạy:
EXEC('ALTER SERVER ROLE securityadmin ADD MEMBER dev_test');GO
SELECT IS_SRVROLEMEMBER('securityadmin', 'dev_test');
GO
EXEC sp_executesql N'ALTER SERVER ROLE securityadmin DROP MEMBER dev_test';
GO
Hình 36: Gán và gỡ securityadmin qua EXEC() và sp_executesql
Bước 3: Mở Q_CHG_USER_PRIV, Q_CHG_VIOLATIONS và Q_CHG_COVERAGE (DB User Name = SYSTEM, rồi SA).
Hình 37: Q_CHG_VIOLATIONS của kịch bản 8 với các vi phạm AUD_ALERT_DYNAMIC_SQL, AUD_ALERT_ORA_HIGH_PRIV và AUD_ALERT_MSS_HIGH_PRIV
Đánh giá: Cả bốn câu dynamic SQL đều bị AUD_ALERT_DYNAMIC_SQL cảnh báo kèm nguyên chuỗi lệnh bên trong; AUD_ALERT_ORA_HIGH_PRIV, AUD_ALERT_MSS_HIGH_PRIV bắt thêm ba câu. Hạn chế: P3 không bắt lệnh nằm trong biến hay thủ tục tạo sẵn; khi đó dựa vào CREATE PROCEDURE trong Q_CHG_SCHEMA và snapshot quyền (entitlement).
5.9. Kịch bản 9 – Thay đổi qua kết nối cục bộ
DBA thường đăng nhập thẳng vào máy chủ CSDL và kết nối cục bộ: Oracle dùng sqlplus / as sysdba (giao thức bequeath), SQL Server dùng shared memory. Các kết nối này không đi qua cổng TCP 1521/1433.
Bước 1: Oracle: SSH vào oracledb01 bằng user oracle và chạy:
sqlplus / as sysdbaBước 1: Oracle: SSH vào oracledb01 bằng user oracle và chạy:
SQL> CREATE USER local_test IDENTIFIED BY "<MK_LOCAL_TEST>";
SQL> DROP USER local_test;
Hình 38: Tạo và xóa local_test qua sqlplus / as sysdba trên oracledb01
Bước 2: SQL Server: đăng nhập SQLDB01 bằng tài khoản Administrator, mở cmd và chạy qua shared memory (tiền tố lpc:, xác thực Windows):
sqlcmd -S lpc:SQLDB01 -E -No -Q "CREATE LOGIN local_test WITH PASSWORD = N'<MK_LOCAL_TEST>'"sqlcmd -S lpc:SQLDB01 -E -No -Q "DROP LOGIN local_test"
Hình 39: Tạo và xóa login local_test qua shared memory trên SQLDB01
Bước 3: Mở Q_CHG_USER_PRIV và Q_CHG_COVERAGE trong khoảng thời gian vừa chạy.
Hình 40: Q_CHG_USER_PRIV ghi nhận các câu chạy qua kết nối cục bộ trên cả hai CSDL
Đánh giá: Cả hai kết nối cục bộ đều được ghi nhận, mật khẩu được che: lệnh của SYS qua bequeath, với DB Install Dir = ORACLE_HOME đúng tài liệu IBM (Hình 2), và lệnh của SQLDB01\ADMINISTRATOR qua shared memory. Đây là kênh tài khoản quyền cao nhất thường dùng nên cần giám sát.
6. Truy vết một thay đổi
Chọn dòng GRANT DBA của kịch bản 1 trong Q_CHG_USER_PRIV và trả lời các câu hỏi kiểm toán:
Câu hỏi | Trường dữ liệu | Kết quả |
| Ai thực hiện? | DB User Name, OS User | SYSTEM; OS User = ORACLE |
| Từ đâu? | Client IP, Source Program | <IP_ORACLE> (sqlplus chạy trên oracledb01); SQLPLUS |
| Lúc nào? | Timestamp | Thời điểm chạy lệnh, chính xác tới giây |
| Trên đâu? | Server IP, Server Type, Service Name | <IP_ORACLE>, ORACLE, ORCL |
| Làm gì? | SQL Verb, Object Name, Full Sql | GRANT DBA TO dev_test |
| Có thành công? | Q_SRV_SQL_ERRORS cùng thời điểm | Không có lỗi: thành công; có ORA-01031: bị từ chối |
| Trạng thái sau đó? | Report entitlement ORA Roles Granted | DEV_TEST → DBA nếu snapshot chạy giữa kịch bản 1 và 2 |
Hai nguồn dữ liệu bổ sung cho nhau: report entitlement cho biết trạng thái quyền tại các thời điểm snapshot, Q_CHG_USER_PRIV cho biết từng hành động thay đổi. Quyền DBA cấp ở kịch bản 1 và thu hồi ở kịch bản 2 có thể không có trong snapshot entitlement nào, nhưng luôn có đủ hai dòng GRANT, REVOKE trong Q_CHG_USER_PRIV.