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

1. Khái quát về IBM Guardium​

IBM Guardium là nhóm giải pháp bảo mật dữ liệu của IBM. Guardium Data Protection là thành phần trọng tâm, thực hiện Database Activity Monitoring (DAM): theo dõi hoạt động trên dữ liệu, đánh giá hoạt động theo chính sách và lưu lại bằng chứng kiểm toán. Giải pháp được xây dựng theo nguyên tắc bảo vệ dữ liệu tại nơi dữ liệu được lưu trữ hoặc được truy cập, thay vì chỉ quan sát lưu lượng ở biên mạng. Vì vậy, Guardium có thể giám sát database, kho dữ liệu, nền tảng Big Data, file system, mainframe và dịch vụ dữ liệu trên cloud.
Guardium theo dõi việc sử dụng dữ liệu sau khi kết nối đã được cho phép. Khi một ứng dụng hoặc người dùng truy cập database, giải pháp có thể thu nhận thông tin về phiên kết nối, định danh, máy khách, câu lệnh, đối tượng dữ liệu, lỗi và, tùy phương thức giám sát, thông tin về tập kết quả. Các thông tin này được đối chiếu với chính sách để tạo audit trail, cảnh báo hoặc tín hiệu kiểm soát. Vì thế, Guardium bổ sung lớp quan sát độc lập cho cơ chế xác thực và phân quyền sẵn có của database.

2. Kiến trúc tổng thể​

Guardium gồm ba lớp chức năng: lớp phát sinh hoạt động dữ liệu, lớp thu thập - phân tích, và lớp quản trị - lưu giữ tập trung


Kiến trúc tách riêng đường nghiệp vụ và đường kiểm soát. Với S-TAP, ứng dụng vẫn kết nối thẳng đến database; S-TAP chỉ chuyển bản sao activity về Collector. Vì vậy Collector không trở thành điểm trung chuyển của giao dịch. External S-TAP là ngoại lệ: nó hoạt động theo proxy nên nằm trên đường kết nối và phải được thiết kế dự phòng.

2.1. Các thành phần chính​

Collector là điểm xử lý gần nguồn dữ liệu. Collector nhận activity, phân tích, áp policy, lưu audit ngắn hạn và phát cảnh báo. Đây là thành phần chịu tải xử lý lớn nhất trong kiến trúc DAM.
Aggregator không thu traffic trực tiếp từ database. Các Collector chuyển dữ liệu đã xử lý về Aggregator theo lịch để hợp nhất, lưu giữ dài hạn hơn và chạy báo cáo xuyên nhiều Collector. Sự tách biệt này tránh để truy vấn báo cáo nặng cạnh tranh tài nguyên với việc giám sát thời gian thực.
Central Manager (CM) là mặt phẳng quản trị tập trung: quản lý managed unit, phân phối policy, group và report, quản trị user/role, theo dõi trạng thái Collector, Aggregator và S-TAP. CM không thay Collector phân tích traffic hay Aggregator lưu audit data.
Guardium Installation Manager (GIM) quản lý vòng đời agent. GIM Server chạy trên appliance Guardium; GIM Client được cài tại máy chủ cần quản lý. Nó hỗ trợ phân phối bundle, cài đặt, cập nhật, gỡ bỏ và theo dõi tiến trình S-TAP từ xa

3. Các phương thức thu thập activity data​

3.1. S-TAP: giám sát trực tiếp trên database server​

S-TAP (Software TAP) là agent nhẹ cài trên hệ điều hành của database server. Đây là phương thức phù hợp khi tổ chức quản trị được máy chủ nguồn và nền tảng nằm trong ma trận hỗ trợ. S-TAP quan sát hoạt động giữa client và database, sao chép dữ liệu cần giám sát rồi gửi về Collector; luồng Client–Database vẫn tiếp tục theo kết nối thông thường
Luồng hoạt động gồm bốn bước:
· Client gửi SQL đến database và nhận phản hồi theo đường kết nối bình thường.
· S-TAP thu nhận activity phù hợp với cơ chế cấu hình, sau đó gửi bản sao về Collector.
· Collector giải mã, chuẩn hóa và đối chiếu activity với policy.
· Collector ghi audit log, phát alert, hoặc gửi Control Signal về S-TAP nếu nền tảng và policy hỗ trợ hành động kiểm soát.
S-TAP không phải một kỹ thuật bắt traffic duy nhất. Tùy hệ điều hành, database và kiểu kết nối, S-TAP có thể dùng các cơ chế sau:

K-TAP và A-TAP thường bị nhầm lẫn. K-TAP nhìn thấy truy cập đi qua mạng. Ngược lại, ứng dụng chạy trên chính database server có thể trao đổi qua shared memory mà không tạo traffic mạng; A-TAP tồn tại để bao phủ loại kết nối này. Không nên mặc định bật mọi cơ chế: việc chọn cơ chế phải căn cứ vào phiên bản kernel/database, kiểu mã hóa, support matrix và kiểm thử tải.
Với Db2, Exit Library là thư viện được database gọi khi hoạt động phát sinh. Cách này có thể quan sát tốt các dạng kết nối mà bắt gói tin không thuận lợi. Tuy nhiên, khả năng quan sát stored procedure, masking và hành động kiểm soát thay đổi theo nền tảng; không nên suy diễn mức hỗ trợ của Db2 sang các database khác.

3.2. External S-TAP (E-TAP): giám sát theo proxy​

Đây là phương án khi không thể cài S-TAP trực tiếp trên máy chủ đích, như DBaaS, workload container ngắn hạn hoặc môi trường không có quyền quản trị hệ điều hành.
External S-TAP nằm giữa client và database. Ứng dụng kết nối đến External S-TAP; thành phần này chuyển tiếp kết nối tới database và gửi dữ liệu giám sát cho Collector. Nhờ đó Guardium quan sát được phiên truy cập mà không cần agent trên DB host.
Khác với S-TAP, External S-TAP là thành phần in-line. Nếu proxy không sẵn sàng, đường kết nối ứng dụng có thể bị ảnh hưởng. Kiến trúc cần có load balancer, nhiều instance, health check và failover. Khi database sử dụng TLS, cần làm rõ vị trí quan sát traffic và cơ chế quản lý chứng thư nếu cần giải mã. Vì vậy, External S-TAP là lựa chọn theo ràng buộc triển khai, không phải thay thế mặc định cho S-TAP.
Trong Kubernetes hoặc môi trường container, External S-TAP có thể triển khai dưới dạng container để phù hợp workload co giãn. Khi đó, service discovery, autoscaling, cân bằng tải và sức khỏe proxy phải được thiết kế như một phần của giải pháp, không chỉ là cấu hình Guardium.

3.3. Universal Connector: thu thập native audit log​

Universal Connector (UC) là điểm vào của Guardium cho native audit log. Nó phù hợp khi không thể quan sát traffic bằng S-TAP/External S-TAP hoặc khi nguồn đã cung cấp audit log qua API, object storage, syslog hay dịch vụ log trên cloud. UC nhận event, nhận diện và phân tích cú pháp, sau đó chuyển hoạt động chuẩn hóa tới Collector
UC có hai cách lấy log:
· Push: nguồn hoặc dịch vụ trung gian chủ động đẩy log đến UC.
· Pull: UC định kỳ đọc log từ kho chứa hoặc API nguồn, ví dụ bucket lưu audit log.
Một connector thường gồm ba nhóm plugin: Input plugin lấy dữ liệu thô; Filter/Parse plugin phân tách và ánh xạ dữ liệu thành trường Guardium hiểu được; Output plugin gửi event đã chuẩn hóa tới Collector. Cấu trúc này cho phép mở rộng sang nhiều nguồn có định dạng audit khác nhau
Ưu điểm của UC là không cần agent trên database server. Giới hạn quan trọng là Guardium chỉ phân tích được những gì audit log nguồn cung cấp. Nếu nguồn không ghi SQL đầy đủ, không có client IP hoặc phát log chậm, UC không thể tái tạo phần thông tin thiếu. UC vì vậy phù hợp nhất cho thu thập, cảnh báo và kiểm toán; khả năng chặn tức thời thường không tương đương phương thức quan sát traffic trực tiếp.

3.4. API và Streaming API​

API cung cấp giao diện lập trình cho những tác vụ như tự động hóa triển khai, quản lý cấu hình, cập nhật group và policy, tích hợp với dịch vụ cloud, cũng như truy xuất kết quả báo cáo. Trong thiết kế thực tế, API nên được xem là mặt phẳng điều khiển và tích hợp. GuardAPI/REST API không trực tiếp thay thế cơ chế thu activity; dữ liệu hoạt động vẫn đi vào Guardium chủ yếu qua S-TAP, External S-TAP, UC/native audit hoặc connector chuyên biệt.

4. Xử lý activity tại Collector​

Collector biến traffic hoặc log thô thành bản ghi kiểm toán có thể tìm kiếm. Chuỗi xử lý có thể khái quát thành bốn lớp: Sniffer, Analyzer, Parser và Logger; tên thành phần chi tiết có thể thay đổi theo phiên bản.

Với S-TAP hoặc External S-TAP, Analyzer phải diễn giải traffic/protocol để lấy SQL và ngữ cảnh. Với UC, input thường đã là JSON hoặc log có cấu trúc nên trọng tâm chuyển sang ánh xạ trường, chuẩn hóa và áp policy. Đây là lý do độ chi tiết, độ trễ và khả năng kiểm soát giữa các phương thức không hoàn toàn giống nhau.
Policy quyết định giá trị vận hành của Collector. Rule chỉ ghi mọi câu lệnh `SELECT` sẽ tạo rất nhiều nhiễu. Chính sách hữu ích thường kết hợp nhóm user, database server, application, IP nguồn, loại thao tác, data object, thời gian và ngưỡng hành vi. Ví dụ: cảnh báo khi tài khoản quản trị truy vấn bảng chứa dữ liệu cá nhân từ máy khách ngoài danh sách quản trị trong thời gian không thuộc cửa sổ bảo trì.

5. Aggregation, Central Manager và GIM​

5.1. Aggregation và vòng đời audit data​

Một Collector không nên đồng thời gánh quá nhiều traffic, retention dài hạn và report nặng. Vì vậy, các Collector export dữ liệu đã xử lý tới Aggregator theo lịch, hợp nhất và phục vụ báo cáo ở quy mô doanh nghiệp. Việc chạy report trên Aggregator bảo vệ tài nguyên xử lý của Collector cho nhiệm vụ giám sát.
Chu kỳ chuyển dữ liệu thường đặt ngoài giờ cao điểm, nhưng không nên mặc định là hằng đêm trong mọi hệ thống. Tần suất phải dựa trên yêu cầu báo cáo, dung lượng, bandwidth và thời điểm cần dữ liệu. Chính sách lưu giữ cần xác định:
· Archive: đóng gói và đưa dữ liệu lịch sử ra vùng lưu trữ ngoài.
· Purge: xóa dữ liệu hết hạn khỏi kho hoạt động.
· Restore: nạp lại archive khi cần điều tra hoặc báo cáo.
· Retention: quy định dữ liệu nào được giữ, lưu ở đâu và giữ bao lâu.
Hai chỉ số cần theo dõi độc lập là mức tải inspection/sniffer và mức sử dụng đĩa. Inspection engine quá tải có thể dẫn đến độ trễ hoặc suy giảm khả năng xử lý activity; đĩa đầy làm audit log mới không được ghi. Ngưỡng cảnh báo phải dựa trên baseline và tốc độ tăng tải của từng môi trường, không dùng một con số cố định cho mọi hệ thống.

5.2. Central Manager​

CM giảm chi phí vận hành khi có nhiều Collector/Aggregator. Các chức năng chính gồm phân phối policy và report, quản lý user/role/group, theo dõi managed unit và trạng thái S-TAP, điều phối tác vụ quản trị. Ví dụ, một group chứa các bảng nhân sự nhạy cảm có thể được quản lý tập trung và dùng lại bởi nhiều policy thay vì cấu hình thủ công trên từng Collector.
CM là nơi quản trị, Aggregator là nơi hợp nhất dữ liệu báo cáo và Collector là nơi phân tích activity. Ba vai trò có thể cùng tồn tại trong triển khai nhỏ, nhưng cần tách theo chức năng khi quy mô hoặc tải tăng.

5.3. GIM​

GIM giải quyết bài toán vận hành S-TAP ở quy mô lớn.
GIM Server phân phối bundle; GIM Client nhận bundle, cài đặt, cập nhật cấu hình, kiểm tra tiến trình và báo trạng thái.
Tài liệu IBM quy định cổng và TLS cho liên lạc giữa GIM Server và GIM Client; cần đối chiếu đúng phiên bản Guardium khi cấu hình firewall.
GIM không thu traffic thay S-TAP và không thay Collector áp policy. Luồng chính cần phân biệt rõ là: CM/GIM quản lý agent; S-TAP gửi activity đến Collector; Collector chuyển audit data đến Aggregator.

6. Các topology triển khai​

6.1. Mô hình đơn giản​

Một Collector quản lý một nhóm database cùng khu vực và nhiều S-TAP.
Đây là topology cơ bản cho nhiều database trong một data center, phù hợp phòng lab, thử nghiệm hoặc phạm vi nhỏ.
Hạn chế là cùng appliance phải chia sẻ tài nguyên giữa xử lý, lưu trữ và report

6.2. Mô hình tập trung nhiều Collector​

Nhiều Collector được phân bố theo data center, vùng mạng hoặc nhóm nguồn; một Aggregator hợp nhất audit data và CM điều phối policy.
Đây là mô hình cân bằng giữa khả năng mở rộng và quản trị thống nhất: Collector gần nguồn, Aggregator phục vụ retention/report.

6.3. Mô hình theo miền nghiệp vụ​

Mỗi vùng như Nhân sự, Tài chính hoặc Bán hàng có thể có Collector/Aggregator riêng để tách audit data, thời hạn lưu và báo cáo;
CM chung vẫn quản trị policy thống nhất. Mô hình này phù hợp khi audit data có yêu cầu sở hữu, tuân thủ hoặc báo cáo riêng.

6.4. Hybrid cloud​

7. Báo cáo, Query Builder và tích hợp phản ứng​

Guardium sử dụng query và report để biến audit data thành bằng chứng vận hành. Một truy vấn thường xác định domain, entity chính, các cột hiển thị và điều kiện lọc. Group được dùng để duy trì tập IP, user, server hoặc data object có thể dùng lại trong nhiều policy/query. Khi danh sách máy quản trị thay đổi, chỉ cần cập nhật group thay vì sửa từng report.
Nếu report không có dữ liệu, nên kiểm tra lần lượt time range, điều kiện query/group, trạng thái S-TAP hoặc connector, việc Collector nhận activity, rồi đến lịch aggregation nếu report chạy trên Aggregator. Cách kiểm tra này giúp phân biệt lỗi dữ liệu chưa về với lỗi lọc quá chặt.
Alert cần được liên thông với SIEM, SOAR hoặc ticketing để gắn với mức ưu tiên, người chịu trách nhiệm và hành động tiếp theo. Nên sử dụng report mẫu làm điểm xuất phát, sau đó clone và hiệu chỉnh theo tài sản dữ liệu, vai trò và yêu cầu tuân thủ của tổ chức.

8. Nguyên tắc thiết kế​

· Chọn phương thức theo nguồn dữ liệu: S-TAP phù hợp khi có quyền cài agent; External S-TAP giải quyết giới hạn quyền nhưng tạo thành phần in-line; UC phụ thuộc chất lượng native audit log.
· Đối chiếu support matrix trước khi triển khai: K-TAP, A-TAP, Exit Library, TLS inspection, masking và control signal không được hỗ trợ giống nhau trên mọi nền tảng.
· Thiết kế policy theo ngữ cảnh nghiệp vụ: kết hợp user, application, client, data object, thời gian và loại thao tác để giảm alert noise.
· Tách tải monitoring khỏi reporting: đưa report xuyên nhiều Collector và retention dài hạn về Aggregator; theo dõi cả inspection utilization lẫn disk utilization.
· Thiết kế dự phòng cho proxy và quản trị: External S-TAP cần health check/failover; CM và GIM cần quy tắc mạng, chứng thư và quyền truy cập phù hợp.
· Kiểm thử bằng kịch bản thật: bao gồm truy cập ứng dụng, DBA dùng công cụ quản trị, local/shared-memory connection, TLS, failover và mất kết nối Collector.