IBM Guardium Tổng quan kiến trúc của giải pháp IBM Guardium

• On-premises: hệ quản trị cơ sở dữ liệu (DBMS) truyền thống chạy trên máy chủ vật lý hoặc máy ảo trong trung tâm dữ liệu của doanh nghiệp.
• Cloud: các dịch vụ cơ sở dữ liệu dạng DBaaS trên nền tảng đám mây (AWS RDS/Aurora, Azure SQL, Google Cloud SQL,...).
• Hybrid Multicloud: kết hợp linh hoạt giữa hạ tầng tại chỗ và nhiều nền tảng đám mây khác nhau, kể cả các workload container hóa (Kubernetes, OpenShift).

B. CHI TIẾT CÁC THÀNH PHẦN HẠ TẦNG​

1. S-TAP (Software TAP) - Cánh tay nối dài trên Database Server​

• Bước 1 – Giao tiếp Client/Server: khi Client gửi câu lệnh SQL, dữ liệu vẫn đi thẳng đến Database Server và Server trả kết quả về ngay lập tức; S-TAP chỉ sao chép (không chặn) lưu lượng này.
• Bước 2 – Sao chép và gửi dữ liệu: S-TAP gửi bản sao nội dung giao tiếp (ai truy cập, thao tác gì, dữ liệu nào bị lấy đi) sang Guardium Collector.
• Bước 3 – Phân tích tại Collector: Sniffer nhận dữ liệu, Analysis Engine phân tích cú pháp SQL và đối chiếu chính sách bảo mật, sau đó ghi log vào kho lưu trữ nội bộ phục vụ báo cáo, kiểm toán.
• Bước 4 – Tín hiệu điều khiển (Control Signal): nếu phát hiện vi phạm chính sách, Collector gửi Control Signal yêu cầu S-TAP can thiệp vào nhân hệ điều hành để ngắt kết nối, lọc bớt lưu lượng trước khi gửi (giảm tải mạng/Collector), chặn kết nối, hoặc che giấu/lược bỏ thông tin nhạy cảm trong tập kết quả.

• Tính nhẹ nhàng: các công việc tính toán nặng (data analyst) được chuyển sang Guardium Collector để đảm bảo hiệu suất database không bị ảnh hưởng.
• Tính toàn vẹn: mọi truy cập, dù từ xa qua mạng hay truy cập trực tiếp tại máy chủ (local access), đều bị S-TAP ghi lại, giúp ngăn chặn quản trị viên có ý định xấu thực hiện thao tác ngoài kiểm soát.
• Tách biệt nhiệm vụ: việc tách rời khâu thu thập (S-TAP) và khâu phân tích (Collector) giúp hệ thống bảo mật hoạt động ổn định và có khả năng mở rộng tốt hơn.

• K-TAP (Kernel TAP): Là một kernel module được cài vào hệ điều hành trong quá trình cài đặt S-TAP, hoạt động ở tầng nhân (Kernel Level). K-TAP hook (can thiệp) vào cơ chế giao tiếp mạng giữa Client và Server, cho phép giám sát cả lưu lượng đến từ bên ngoài (External Network Application/User) lẫn lưu lượng nội bộ (Local Application/User), miễn là chúng đi qua ngăn xếp mạng (network stack) của hệ điều hành.
• A-TAP (Application TAP): Hoạt động ở tầng ứng dụng (Application/User Level), chuyên giám sát giao tiếp qua vùng nhớ dùng chung (Shared Memory) — vùng nhớ RAM nơi các truy vấn từ Local Application/User đến DBMS được xử lý mà không cần đi qua Network Layer, nên K-TAP không thể quan sát trực tiếp. A-TAP là thành phần phụ thuộc vào K-TAP (dependent on K-TAP): nó thu thập dữ liệu ở tầng ứng dụng rồi sử dụng K-TAP làm trung gian (proxy) để chuyển tiếp dữ liệu về S-TAP/Collector, chủ yếu dùng cho các DBMS như Db2, Informix hoặc Oracle (kết nối kiểu Bequeath/ASO).

• Tee: cơ chế proxy thay thế cho K-TAP, giúp đọc và chuyển tiếp lưu lượng từ các máy khách cục bộ đến máy chủ cơ sở dữ liệu khi K-TAP không khả dụng trên một số kernel đặc thù.
• Network TAP / Packet Capture (PCAP): thu thập gói tin ở tầng mạng vật lý; hiếm khi được dùng trên hệ UNIX nhưng có ứng dụng hạn chế trên một số hệ Windows và Linux, thường dùng khi không thể cài agent trực tiếp trên máy chủ có tải cao.
• Db2 Exit (Exit Library): cơ chế tích hợp chuyên biệt cho nền tảng Db2 z/OS/LUW. Exit Library là một thư viện liên kết động được Db2 tự động tải trong quá trình khởi động thông qua cơ chế Db2_Exit; sau khi được tải, nó giao tiếp trực tiếp với S-TAP và chuyển toàn bộ lưu lượng truy cập Db2 (mã hoá hoặc không, cục bộ hoặc từ xa) tận dụng cả bộ nhớ dùng chung lẫn mạng. Tuy nhiên Db2 Exit có hai hạn chế đáng lưu ý: (1) không hỗ trợ che dấu dữ liệu (masking) trước khi gửi đi, và (2) không giám sát được các câu lệnh SQL bên trong stored procedures vì Guardium không có khả năng "nhìn" vào logic bên trong stored procedures.

2. E-TAP (External S-TAP) - Giải pháp cho môi trường Container và Cloud​

​

• Tình huống áp dụng: các dịch vụ DBaaS (AWS RDS, Azure SQL, Google Cloud SQL) nơi người dùng không có quyền quản trị hệ điều hành; hoặc môi trường container hóa (Docker, Kubernetes/OpenShift) cần khả năng tự động mở rộng (auto-scaling).
• Cơ chế triển khai: với môi trường Database service, E-TAP được triển khai dưới dạng container độc lập cấu hình gửi giám sát về Collector; với môi trường on-premises hoặc cloud host, sử dụng một E-TAP host riêng - máy chủ chạy Docker và cài đặt các gói phần mềm E-TAP. Khi triển khai qua Kubernetes, các agent này còn hỗ trợ tự động triển khai và tự động mở rộng quy mô (auto-scaling) trong thời gian thực.

3. Universal Connector - Linh hoạt và Agentless​

​

• Cơ chế Push: nguồn dữ liệu chủ động đẩy log đến Universal Connector ngay khi log được sinh ra.
• Cơ chế Pull: Universal Connector chủ động kết nối đến kho lưu trữ log (ví dụ S3 bucket, syslog server) để định kỳ lấy dữ liệu về; cách này có thể tác động đến hiệu suất database và yêu cầu thêm dung lượng lưu trữ.

4. Streaming API - Tự động hoá qua giao diện lập trình​

​

• Tự động hóa việc triển khai và các thiết lập cấu hình.
• Định nghĩa các nguồn dữ liệu (datasources), cập nhật dữ liệu cho các nhóm (groups) và thiết lập các bộ máy kiểm tra (inspection engines).
• Tích hợp với các hệ thống bên ngoài như AWS và Azure.
• Sử dụng các chức năng của REST API để cập nhật dữ liệu cho các nhóm và tái cài đặt các chính sách (policies).
• Trích xuất thông tin tập trung từ Guardium thông qua các API online_report và quick_search.

5. Collector và Sniffer - Bộ não xử lý dữ liệu​

​

• Sniffer (thu nhận): tiếp nhận và sắp xếp luồng dữ liệu nhị phân từ S-TAP/E-TAP, hoặc dữ liệu có cấu trúc (JSON) từ các nguồn agentless.
• Analyzer (phân tích): giải mã lưu lượng thô thành câu lệnh SQL. Với dữ liệu từ agent/proxy, Analyzer phải giải mã (decode) dữ liệu nhị phân sang SQL có thể đọc được; với dữ liệu agentless, bước này đơn giản hơn vì dữ liệu vốn đã có cấu trúc (thường là JSON). Sau đó, hệ thống đối chiếu với Security Policy đang áp dụng để quyết định có ghi log, cảnh báo, hay gửi Control Signal (Terminate/Mask) hay không.
• Parser (chuẩn hóa): tách câu lệnh SQL thành các thành phần có cấu trúc, ví dụ Verb (hành động, như SELECT/UPDATE) và Object (như tên bảng) để phục vụ truy vấn báo cáo sau này.
• Logger (ghi nhật ký): lưu trữ dữ liệu đã chuẩn hóa xuống đĩa cục bộ của Collector (hoặc gửi đến một ingestion pipeline), phục vụ mục đích kiểm toán và báo cáo trong ngắn hạn. Việc ghi lại dựa trên chính sách, chỉ ghi những thông tin được cho phép để tối ưu dung lượng lưu trữ.

6. Aggregator và Central Manager (CM) - Quản trị và lưu trữ tập trung​

​

• Aggregator: là một loại thiết bị riêng biệt, không trực tiếp thu thập traffic từ database. Thay vào đó, các Collector gửi dữ liệu đã phân tích về Aggregator theo lịch trình định sẵn (thường hằng đêm) để hợp nhất (merge) vào cơ sở dữ liệu nội bộ của Aggregator, phục vụ lưu trữ dài hạn và báo cáo ở quy mô toàn doanh nghiệp. Các báo cáo nên được trích xuất trực tiếp từ Aggregator thay vì từng Collector riêng lẻ, vì các truy vấn báo cáo phức tạp thường tốn nhiều tài nguyên — chạy trên Aggregator giúp Collector không bị ảnh hưởng hiệu suất và chỉ tập trung vào nhiệm vụ cốt lõi là giám sát và thực thi chính sách. Aggregator có cả phiên bản phần cứng (ví dụ IBM x3550) lẫn phần mềm cài trên hardware hoặc máy ảo.
• Central Manager (CM): là điểm quản trị tập trung duy nhất cho toàn bộ hệ thống Guardium. Các chức năng chính gồm: giám sát trạng thái hoạt động của cả Collector và Aggregator; hiển thị trạng thái S-TAP trên toàn doanh nghiệp trên một màn hình (Enterprise S-TAP view); quản lý bản vá tập trung (Patch Management); đẩy các chính sách bảo mật thống nhất xuống tất cả Collector được quản lý; quản lý người dùng, vai trò và phân quyền (User và Role Management); và thiết lập các quy trình báo cáo, kiểm tra tập trung.

• Mô hình tập trung: nhiều Collector giám sát các nguồn dữ liệu khác nhau nhưng chỉ dùng chung một Aggregator và một Central Manager; Aggregator hợp nhất toàn bộ dữ liệu kiểm toán để phân tích ở quy mô doanh nghiệp, còn Central Manager điều phối việc thực thi chính sách, báo cáo và đảm bảo tiêu chuẩn an ninh trên toàn bộ môi trường.
• Mô hình theo phòng ban: mỗi bộ phận (ví dụ Sale, HR) có Aggregator riêng để thu thập dữ liệu liên quan, phục vụ lập báo cáo và tuân thủ quy định phù hợp với từng phòng ban, trong khi một Central Manager duy nhất vẫn giám sát toàn bộ hệ thống và đảm bảo policy được thực thi nhất quán.
• Mô hình tách biệt hoàn toàn: từng chức năng kinh doanh (ví dụ Sale, HR) có cả Aggregator lẫn Collector riêng, còn Central Manager được tách riêng và chỉ chuyên trách các chức năng quản lý tập trung. Mô hình này hỗ trợ kiểm soát và báo cáo chi tiết theo yêu cầu nội bộ của từng đơn vị.

7. GIM (Guardium Installation Manager)​

​

• Kiểm tra các bản cập nhật cho phần mềm đã cài đặt trên database server hoặc file systems.
• Truyền tải và cài đặt phần mềm mới; gỡ bỏ phần mềm khi không còn cần thiết.
• Cập nhật các tham số phần mềm.
• Giám sát sức khoẻ và dừng các tiến trình đang chạy trên máy chủ cơ sở dữ liệu.

C. QUY TRÌNH VẬN HÀNH VÀ QUẢN LÝ DỮ LIỆU​

1. Chu kỳ dữ liệu hằng đêm (Export / Import)​

• Retention trên Collector: thường lưu trữ dữ liệu trong thời gian ngắn (vài ngày) để phục vụ phân tích/báo cáo nhanh; thời gian cụ thể phụ thuộc cấu hình và dung lượng đĩa.
• Retention trên Aggregator: lưu trữ dài hạn hơn nhiều (thường vài tháng đến hàng năm) tùy theo yêu cầu tuân thủ (compliance) và chính sách nội bộ của tổ chức.

2. Phân biệt các chỉ số sử dụng tài nguyên (Utilization)​

3. Archive, Purge và Restore​

D. THIẾT LẬP BÁO CÁO VÀ QUERY BUILDER​

1. Quy trình tạo truy vấn bằng Query Builder​

• Chọn Domain: ví dụ chọn "Access" (miền dữ liệu liên quan đến phiên truy cập).
• Đặt Query Name: ví dụ "Trusted Sessions Report".
• Chọn Main Entity: ví dụ "Session" (hoặc Session/Session Attributes tùy phiên bản Guardium).
• Chọn Columns: chọn các cột cần hiển thị, ví dụ Client IP, DB User Name, Server IP...
• Thiết lập Conditions: dùng Query Conditions kết hợp với Groups để lọc dữ liệu.

2. Xử lý lỗi "No Data Found"​

• Time Range: vào Edit Mode để mở rộng khoảng thời gian truy vấn (ví dụ từ 3 giờ lên 1 năm) nhằm loại trừ khả năng do khung thời gian quá hẹp.
• Query Logic: kiểm tra các điều kiện lọc (Conditions) xem có quá khắt khe, mâu thuẫn nhau, hoặc sai Domain/Entity hay không.
• Nguồn dữ liệu: xác nhận S-TAP/agent liên quan có đang hoạt động và thực sự gửi traffic về Collector hay không.

3. Tối ưu hóa với báo cáo mẫu​