IBM Guardium Tự động khám phá và phân loại dữ liệu và giám sát trên Oracle Database và SQL database

1. Mục tiêu​

• Tự động phát hiện các CSDL Oracle và SQL Server đang hoạt động trong hệ thống.
• Tự động quét và phân loại dữ liệu nhạy cảm (PCI, PII theo đặc thù Việt Nam) trên cả hai loại CSDL.
• Tự động cập nhật kết quả phân loại vào group và quét lại theo lịch.
• Giám sát mọi truy cập vào dữ liệu đã phân loại: ghi log chi tiết, cảnh báo khi người dùng không được phép truy cập.
• Trực quan hóa kết quả bằng báo cáo và dashboard.

2. Nguyên lý hoạt động​

Quy trình gồm ba giai đoạn, nối với nhau qua group:

Policy và báo cáo tham chiếu tới group chứ không ghi tên bảng cố định, nên bảng nhạy cảm mới được phát hiện ở lần quét định kỳ sẽ được đưa vào giám sát qua group.

3. Mô hình triển khai và chuẩn bị​

3.1. Thành phần hệ thống​

3.2. Dữ liệu và tài khoản kiểm thử​

Schema RETAIL trên Oracle và database RetailDB (schema retail) trên SQL Server có cùng 4 bảng: CUSTOMERS (60 dòng) và EMPLOYEES (20 dòng) chứa số thẻ, CCCD, số điện thoại, email, lương; ORDERS (150 dòng) và PRODUCTS (20 dòng) là bảng đối chứng không nhạy cảm.

SQL Server bật chế độ SQL Server and Windows Authentication, bật giao thức TCP/IP và mở cổng 1433 trên firewall.

3.3. Tạo các group​

Truy cập Setup → Tools and Views → Group Builder, nhấn New và tạo ba group, Application type = Public để dùng chung cho Classifier, Policy Builder và Query-Report Builder:

• Guardium chuẩn hóa tên user thành chữ hoa nên không cần nhập thêm dạng chữ thường.

3.4. Khai báo datasource​

Bước 1: Truy cập Setup → Tools and Views → Datasource Definitions, chọn Application Type = Classifier, nhấn New và nhập:

Bước 2: Nhấn Test connection, kết quả phải báo Connection successful, sau đó nhấn Save.

• Oracle trong lab là non-CDB nên Service name là orcl.
• SQL Server lắng nghe cố định cổng 1433 nên chọn MS SQL SERVER (DataDirect), không chọn bản Dynamic Port. Kết nối được bằng guardium_cls cũng xác nhận SQL Server đã bật Mixed Mode.

4. Giai đoạn 1 – Tự động khám phá CSDL​

4.1. Phát hiện instance qua S-TAP​

Bước 1: Truy cập Manage → Activity Monitoring → S-TAP Control.
Bước 2: Chọn S-TAP của SQLDB01, nhấn biểu tượng Send Command (chữ G), chọn Run Database Instance Discovery, không tích Replace Inspection Engines rồi nhấn Apply. Làm tương tự với S-TAP của oracledb01.

• Không tích Replace Inspection Engines vì tùy chọn này thay Inspection Engine đang chạy bằng cấu hình tự dò, có thể làm S-TAP chuyển sang trạng thái lỗi.

Bước 3: Truy cập Reports → Real-Time Guardium Operational Reports → Discovered Instances để xem kết quả.
Đánh giá: S-TAP phát hiện đúng instance MSSQLSERVER (cổng 1433) trên SQLDB01 và orcl (cổng 1521) trên oracledb01. Dòng cổng 1434 là cổng Dedicated Admin Connection của cùng instance SQL Server, không phải CSDL khác.

4.2. Quét mạng bằng Database Auto-discovery​

Bước 1: Truy cập Discover → Database Discovery → Auto-discovery Configuration, nhấn New, đặt Process name = DISC_LAB_NETWORK.
Bước 2: Thêm hai dòng <IP_MSSQL> và <IP_ORACLE>, mỗi dòng khai các cổng mặc định của SQL Server và Oracle: 1521, 1433, 1522, 1434, 1526. Tích Run probe after scan và Skip host discovery, nhấn Apply.

• Chỉ khai báo IP của các máy lab: khai báo cả dải /24 sẽ quét ra CSDL của các máy khác trong mạng.
• Phải tích Skip host discovery: Windows Server chặn ping nên nếu Guardium ping trước, SQLDB01 bị bỏ qua.

Bước 3: Nhấn Modify Schedule, đặt Start Time = 1 a.m., chọn Every day rồi nhấn Save để quét định kỳ, tự động phát hiện CSDL mới.
Bước 4: Nhấn Run Once Now để quét ngay (probe tự chạy sau khi quét), sau đó mở báo cáo Databases Discovered.
Đánh giá: Quét mạng tìm thấy MSSQL cổng 1433 và Oracle cổng 1521, khớp với kết quả qua S-TAP. Cách này phát hiện được cả CSDL chưa cài S-TAP; từ báo cáo có thể tạo datasource trực tiếp.

4.3. Báo cáo và dashboard tổng quan CSDL​

Bước 1: Truy cập Reports → Report Configuration Tools → Query-Report Builder, chọn domain Discovered Instances (loại CSDL nằm ở cột Protocol) và tạo hai query:

• Q_DB_BY_TYPE: cột Protocol (Field Mode = Value), tích Count, sắp xếp theo Count, điều kiện Port Min <> 1434 để bỏ dòng cổng DAC; hiển thị dạng biểu đồ tròn.
• Q_DB_BY_SERVER: các cột Host, Protocol, Instance name, Port Min, Timestamp (không tích Count), sắp xếp theo Host, cùng điều kiện Port Min <> 1434; hiển thị dạng bảng.

Bước 2: Truy cập My Dashboards → Create New Dashboard, đặt tên DB Discovery Overview và tải lại trang. Mở từng query, chọn Add to Dashboard (chưa có dashboard thì nút này báo No dashboard defined).

5. Giai đoạn 2 – Tự động phân loại dữ liệu nhạy cảm​

Cách 1 dùng bộ rule có sẵn để kiểm tra khả năng nhận diện dữ liệu Việt Nam. Cách 2 tự xây dựng rule và là cấu hình được dùng cho giám sát ở giai đoạn 3.

5.1. Cách 1 – Khảo sát bằng rule GDPR có sẵn​

Bước 1: Truy cập Discover → Classification → Discover Sensitive Data, nhấn New, đặt tên SCN_BUILTIN_BASELINE.
Bước 2: What to discover: chọn policy phân loại có sẵn GDPR (33 rule), không thêm rule tự viết.
Bước 3: Where to search: chọn DS_ORA_ORACLEDB01 và DS_MSSQL_RETAIL.
Bước 4: Run discovery: nhấn Run Now, chờ tiến trình ở trạng thái COMPLETED.
Bước 5: Review report: xem danh sách bảng, cột và rule đã khớp; lọc thử theo cccd và phone.
Đánh giá: Rule GDPR chỉ khớp theo tên cột (FULL_NAME khớp name, fname, lname; HIRE_DATE khớp date là dương tính giả) và không nhận diện được CCCD, số điện thoại Việt Nam trên cả hai CSDL, nên cần tự xây dựng rule ở Cách 2.

5.2. Cách 2 – Tự xây dựng classification policy​

Bước 1: Truy cập Discover → Classification → Discover Sensitive Data, nhấn New và nhập:

• Category là danh sách chọn, không nhận giá trị gõ tay; thêm giá trị mới bằng biểu tượng bút chì.

Bước 2: What to discover: tạo 6 rule trong POL_RETAIL_SENSITIVE_DATA. RULE_CREDIT_CARD thêm từ template Bank Card / Credit Card Number vì rule này kiểm tra thêm thuật toán Luhn; 5 rule còn lại tạo mới bằng nút + với loại Search for Data.

Các tham số chính ở phần Rule Criteria:

• Data Type: rule regex chỉ chọn Text; rule lương chọn thêm Number vì cột lương có kiểu số.
• Continue on match: tích ở mọi rule để các rule sau vẫn được đánh giá khi một rule đã khớp.
• Hit percentage = 50: cột chỉ được kết luận nhạy cảm khi ít nhất 50% mẫu khớp regex, giảm dương tính giả.
• Minimum / Maximum length là kích thước khai báo của cột, không phải độ dài giá trị. CCCD: Minimum = Maximum = 12 (cột VARCHAR(12)). Số điện thoại: Minimum = 10, để trống Maximum (cột VARCHAR(15)).
• Table name like, Column name like để trống ở các rule regex để nhận diện theo nội dung, không phụ thuộc tên cột.
• Regex CCCD bám cấu trúc 12 số: 3 số mã tỉnh, 1 số giới tính/thế kỷ (0–3), 2 số năm sinh, 6 số ngẫu nhiên. Regex số điện thoại nhận các đầu số di động 03x, 05x, 07x, 08x, 09x và dạng 84/+84.

Bước 3: Ở phần Actions của mỗi rule, thêm hai action:
· ACT_<TÊN>_COLS: Add to Group of Object/Fields → GRP_SENSITIVE_COLUMNS, định dạng tên Fully Qualified Name (Schema.Object).
· ACT_<TÊN>_OBJS: Add to Group of Objects → GRP_SENSITIVE_OBJECTS, định dạng tên Like %Name. Thành viên được ghi dạng %customers, khớp được cả customers và retail.customers trong câu SQL.
· RULE_CREDIT_CARD lấy từ template nên không có sẵn action, phải tự thêm.
Bước 4: Where to search: chuyển DS_ORA_ORACLEDB01 và DS_MSSQL_RETAIL sang Selected Datasources, để một classification policy áp dụng cho cả Oracle và SQL Server.

5.3. Chạy phân loại và lên lịch tự động​

Bước 1: Ở Run discovery, nhấn Run Now. Trạng thái chuyển WAITING → RUNNING → COMPLETED; mục Review report chỉ bật khi tiến trình hoàn tất.

• Guardium chạy lần lượt từng job nên có thể chờ lâu ở WAITING; theo dõi trong Guardium Job Queue.

Bước 2: Ở Schedule, chọn Schedule by = Day, Every Day, Start schedule at = 12:00 AM và tích Activate schedule để quét lại lúc 00:00 hằng ngày.

5.4. Kiểm tra kết quả phân loại​

Bước 1: Mở Review report của kịch bản (có thể lọc theo tên cột ở ô Filter) và report Export Sensitive Data To Discovery.
Bước 2: Mở Group Builder, xem thành viên của GRP_SENSITIVE_COLUMNS.

• Thiếu cột phone: RULE_VN_PHONE đặt Maximum length = 12, nhỏ hơn kích thước cột phone VARCHAR(15), nên cột bị loại trước khi so regex.

• Thiếu credit_card: RULE_CREDIT_CARD lấy từ template chưa có action Add to Group, nên cột có trong Review report nhưng không vào group.

Bước 3: Để trống Maximum length của RULE_VN_PHONE, thêm hai action Add to Group cho RULE_CREDIT_CARD, chạy lại phân loại rồi kiểm tra lại group.
Đánh giá: Lần chạy đầu thiếu phone và credit_card do cấu hình rule. Sau khi sửa và chạy lại, bộ rule nhận đúng 9 cột mỗi CSDL (CUSTOMERS: credit_card, cccd, phone, email, salary; EMPLOYEES: cccd, phone, email, luong), không bắt nhầm PRODUCTS, ORDERS, và kết quả tự động vào group.

6. Giai đoạn 3 – Giám sát truy cập dữ liệu nhạy cảm​

6.1. Tạo security policy​

Bước 1: Truy cập Protect → Security Policies → Policy Builder for Data, nhấn New, đặt Policy Description = POL_MONITOR_SENSITIVE_DATA, Category = Security, không chọn Log Flat và Rules on Flat.
Bước 2: Thêm hai access rule theo đúng thứ tự:

6.2. Cài đặt policy​

Bước 1: Truy cập Protect → Security Policies → Policy Installation, chọn POL_MONITOR_SENSITIVE_DATA, chọn Install & Override.

• Collector đang cài policy mặc định Default – Ignore Data Activity for Unknown Connections. Nếu chỉ cài thêm phía sau (Install last), traffic có thể bị policy này bỏ qua trước khi tới các rule giám sát.

Bước 2: Kiểm tra S-TAP Control: cả hai S-TAP vẫn ở trạng thái xanh sau khi cài policy.

6.3. Tạo báo cáo truy cập dữ liệu nhạy cảm​

Bước 1: Truy cập Reports → Report Configuration Tools → Query-Report Builder, chọn domain Access, Main entity = Object, tạo query Q_SENSITIVE_DATA_ACCESS:

• Các trường: Session Start, Client IP, Server IP, Server Type, DB User Name, Source Program, Object Name, Sql, SQL Verb.
• Điều kiện: Object Name LIKE GROUP GRP_SENSITIVE_OBJECTS (không dùng IN GROUP vì thành viên group ở dạng mẫu %customers).
• Sắp xếp theo Session Start giảm dần.

Bước 2: Thêm report vào dashboard.

6.4. Sinh truy cập kiểm thử​

Các lệnh chạy ngay trên máy chủ CSDL nhưng luôn kết nối qua IP và cổng (TCP), không dùng sqlplus / as sysdba hay Shared Memory, để S-TAP ghi nhận được. Vì vậy Client IP trong báo cáo trùng với Server IP.
Oracle (trên oracledb01, user oracle):
-- Kịch bản 1: user hợp lệ truy cập bảng nhạy cảm
sqlplus retail/"<MK_RETAIL>"@//<IP_ORACLE>:1521/orcl
SQL> SELECT full_name, phone, credit_card FROM retail.customers WHERE ROWNUM <= 5;

-- Kịch bản 2: user không được phép truy cập bảng nhạy cảm
sqlplus intern_test/"<MK_INTERN_TEST>"@//<IP_ORACLE>:1521/orcl
SQL> SELECT full_name, cccd, credit_card FROM retail.customers WHERE ROWNUM <= 5;
SQL Server (PowerShell trên SQLDB01):
# Kịch bản 1: user hợp lệ truy cập bảng nhạy cảm
sqlcmd -S <IP_MSSQL>,1433 -d RetailDB -U retail_app -P "<MK_RETAIL_APP>" -No -Q "SELECT TOP 5 full_name, phone FROM retail.customers"

# Kịch bản 2: user không được phép truy cập bảng nhạy cảm
sqlcmd -S <IP_MSSQL>,1433 -d RetailDB -U intern_test -P "<MK_INTERN_TEST>" -No -Q "SELECT TOP 5 cccd, credit_card FROM retail.customers"

• -No cho phép kết nối không bắt buộc mã hóa; thiếu tùy chọn này, sqlcmd (ODBC Driver 18) báo lỗi "certificate chain was issued by an authority that is not trusted" với chứng chỉ tự ký. Không dùng -C vì kết nối vẫn được mã hóa TLS và S-TAP có thể không đọc được câu lệnh.

6.5. Kiểm tra kết quả giám sát​

Bước 1: Mở report Q_SENSITIVE_DATA_ACCESS.
· Cột Sql hiển thị câu lệnh đã chuẩn hóa, giá trị được thay bằng dấu ?.
Bước 2: Mở báo cáo Access policy violations, lọc theo rule ALERT_UNAUTHORIZED_SENSITIVE_ACCESS. Alerter (email/syslog) chưa được cấu hình trong lab nên cảnh báo được kiểm tra qua báo cáo này.
Đánh giá: Policy ghi log truy cập bảng nhạy cảm của cả user hợp lệ và INTERN_TEST, nhưng chỉ cảnh báo INTERN_TEST (Severity 10) trên cả hai CSDL. Policy chỉ giám sát nên INTERN_TEST vẫn đọc được dữ liệu; muốn chặn cần thu hồi quyền hoặc dùng S-GATE TERMINATE.