IBM Guardium Mô hình triển khai IBM Guardium

Mô hình triển khai IBM GUardium​

I. Mô hình triển khai IBM Guardium​

1. Lý thuyết​

Mỗi topology Guardium gồm hai lớp cần phân biệt: lớp quan sát dữ liệu và lớp quản trị.
S-TAP/External S-TAP quan sát activity ở gần nguồn hoặc trên đường kết nối; Collector xử lý activity; Aggregator hợp nhất dữ liệu; Central Manager quản trị cấu hình. Không nên nhầm luồng SQL nghiệp vụ với luồng audit: ứng dụng vẫn kết nối trực tiếp hệ quản trị cơ sở dữ liệu trong mô hình S-TAP thông thường.

1.1. Agent​

S-TAP (Software TAP) được cài trên database server để quan sát activity và gửi dữ liệu về Collector. IBM yêu cầu S-TAP và inspection engine được cấu hình đúng trước khi áp dụng policy giám sát dữ liệu. S-TAP phù hợp với database host mà tổ chức có thể cài agent và có cửa sổ thay đổi.
GIM (Guardium Installation Manager) giúp cài đặt, cập nhật và quản lý package/parameter của agent từ xa. GIM gồm GIM server trên Guardium appliance và GIM client trên managed server. Nó hỗ trợ vận hành, nhưng không loại bỏ yêu cầu kiểm thử agent và có rollback plan.
External S-TAP là proxy/container cho traffic giữa client và database, có thể dùng với cloud hoặc on-premises database. Nó chuyển một bản traffic tới Collector để analysis/policy. External S-TAP không phải lựa chọn thay thế đơn giản cho S-TAP: remote traffic phải route qua External S-TAP, còn local traffic trên database host cần được thiết kế và quan sát riêng.

1.2. Guardium components​

• Collector: nhận activity từ S-TAP/nguồn phù hợp; phân tích, áp policy, ghi audit, tạo alert và có thể chạy Vulnerability Assessment (VA).
• Aggregator: nhận export từ nhiều Collector để tạo báo cáo và góc nhìn tập trung. Aggregator không nhận S-TAP traffic thay Collector
• Central Manager (CM): quản trị policy, report, query, alert, profile và managed unit. Một Guardium environment có một CM.
• Managed Unit: Collector hoặc Aggregator đã đăng ký với CM để nhận quản trị tập trung.

1.3. Mid-size Architecture (sử dụng S-TAP Agent)​

1.3.1. Mô Hình​

1.3.2. Cấu trúc​

• Nhiều Collector được đặt theo site, vùng mạng hoặc nhóm database. Mỗi Collector nhận activity gần nguồn dữ liệu để giảm network hop và tách tải xử lý.
• Một Aggregator nhận dữ liệu export từ các Collector. Trong LAB mid-size nhỏ, máy Aggregator có thể kiêm Central Manager; ở quy mô cao hơn có thể tách CM theo thiết kế hỗ trợ.
• S-TAP vẫn chỉ định Collector là Guardium host. Aggregator/CM không thay Collector trong đường S-TAP traffic.

1.3.3. Thành phần tối thiểu​

1.3.4. Luồng hoạt động và các port chính​

Lưu ý: Các port 1521 và 1433 chỉ là ví dụ listener phổ biến của Oracle và Microsoft SQL Server. Port cho Central Manager thay đổi theo phiên bản GDP và chế độ central management, vì vậy cần đối chiếu port matrix IBM trước khi mở firewall production.

1.3.5. Khi sử dụng​

• Có nhiều database hoặc nhiều vùng mạng; một Collector không còn đáp ứng tải và report cần được hợp nhất.
• Cần một nơi quản trị policy/report/query, patch/configuration profile và trạng thái managed unit.
• Có khả năng vận hành Aggregator/CM, backup/restore, phân quyền và change management tập trung.

1.4. Basic Stand-alone Architecture (sử dụng S-TAP Agent)​

1.4.1. Mô hình​

1.4.2. Cấu trúc​

• Một Collector duy nhất nhận dữ liệu giám sát hoạt động cơ sở dữ liệu do S-TAP chuyển về, sau đó xử lý policy, lưu audit, sinh alert, hiển thị report/dashboard và có thể chạy Vulnerability Assessment (VA) trong phạm vi LAB.
• Một hoặc nhiều database server có S-TAP. Bắt đầu với một data source trước, sau đó thêm Oracle/SQL Server để kiểm tra khác biệt OS/DBMS.
• Application client hoặc application server tạo query. Lưu lượng SQL nghiệp vụ đi thẳng client → database; Collector nhận bản quan sát do S-TAP gửi về.
• Không có Aggregator/CM trong mô hình basic. Quản trị và report thực hiện trên chính Collector.

1.4.3. Thiết bị và phần mềm cần có​

1.4.4. Cấu hình luồng kết nối​

Bảng kết nối dưới đây áp dụng cho Basic Stand-alone Architecture. Khác với Mid-size Architecture, mô hình này không có Central Manager hoặc Aggregator nên không cần các luồng central management và data transfer giữa các appliance.

1.4.5. Giới hạn​

• Phù hợp: LAB, POC, một site nhỏ, ít data source, mục tiêu học S-TAP, policy, audit và Vulnerability Assessment (VA) cơ bản.
• Giới hạn: Collector vừa xử lý activity vừa lưu/report; không có reporting từ nhiều Collector; policy không có CM lifecycle ở quy mô lớn.
• Không tuyên bố production-ready nếu chưa có sizing theo volume, retention, backup/restore, HA/DR, integration, monitoring health và quy trình vận hành.

1.5. External S-TAP​

1.5.1. Cách triển khai​

External S-TAP intercept traffic giữa client và database, sau đó gửi bản traffic về Collector để analysis và policy. IBM hỗ trợ triển khai bằng Kubernetes/OpenShift hoặc quản lý Docker container thủ công. Trong trường hợp Kubernetes, dịch vụ load balancing cung cấp endpoint mới mà client sử dụng để kết nối database.

1.5.2. Thành phần​

• Client/Application: phải dùng DNS name/endpoint của load balancer hoặc External S-TAP, không kết nối thẳng database nếu muốn remote traffic đi qua lớp này.
• Load balancer: tạo endpoint có thể mở rộng/khả dụng. CN certificate phải khớp DNS name mà client dùng để kết nối.
• External S-TAP container/pod: nhận remote traffic, chuyển tiếp traffic tới database và gửi copy về Collector.
• Database: remote traffic được đi qua proxy; traffic local phải được xử lý riêng bằng S-TAP/cấu hình local phù hợp nếu cần giám sát đầy đủ.
• Collector: nhận traffic từ External S-TAP và áp policy. External S-TAP không dùng GIM.

1.5.3. Điều kiện triển khai​

• Có Kubernetes/OpenShift hoặc Docker host phù hợp, container registry, certificate/CA, load balancer, persistent storage và quản trị secrets nếu topology yêu cầu.
• Thiết kế DNS endpoint, TLS/mutual authentication, routing, health check, proxy protocol và failover trước khi chuyển endpoint ứng dụng.
• Thử một database và một nhóm client trước. Kiểm tra latency, kết nối dài, reconnect, connection pooling và rollback DNS/endpoint.
• Không suy luận External S-TAP quan sát hết mọi traffic: local traffic, protocol/DBMS support và TLS behavior phải được kiểm tra theo IBM Support Matrix hiện hành.

II. IBM Guardium — System Requirements và Pre-requirements​

1. System Requirements​

IBM cung cấp Guardium Data Protection (GDP) dưới dạng hardware offering hoặc software offering.
Software offering là image cài lên phần cứng khách hàng hoặc virtual appliance. Theo IBM Guardium Appliance Technical Requirements 12.2.x, software/virtual appliance yêu cầu nền tảng x86 Intel/AMD; với cài vật lý, IBM dùng nền tảng được RHEL 9.6 64-bit hỗ trợ làm mốc tương thích.

1.1. Appliance vật lý​

• Chỉ dùng x86 Intel/AMD. Không chọn phần cứng cần driver đặc thù hoặc post-install configuration không nằm trong phạm vi IBM hỗ trợ.
• Dùng disk riêng cho GDP. Cài đặt image sẽ xóa, repartition và format disk được chọn; không đặt ISO/VM disk Guardium chung với dữ liệu khác.
• RAID được IBM khuyến nghị; có tối thiểu 25 GB free tại /var. Disk performance ảnh hưởng trực tiếp vào số S-TAP/workload mà Collector chịu được.

1.2. Virtual Appliance​

• IBM liệt kê Red Hat OpenShift Virtualization, Red Hat Enterprise Virtualization, VMware, Microsoft Hyper-V và Nutanix AHV.
• Không overcommit CPU/RAM cho Collector. Khi có traffic qua SPAN/TAP hoặc workload lớn, performance phụ thuộc đáng kể vào resource reservation và virtual network.
• Dùng NIC 1/10 GbE theo workload. Có thể tách interface quản trị, monitoring hoặc failover tùy topology

1.3. Tài nguyên baseline trên mỗi appliance​

2. Pre-requirements​

Pre-requirements là các điều kiện hạ tầng, thông tin cấu hình và quyền truy cập phải được chuẩn bị trước khi cài IBM Guardium hoặc kết nối Guardium với database. Nếu thiếu các điều kiện này, image Guardium vẫn có thể cài xong nhưng S-TAP, GIM, Vulnerability Assessment (VA) hoặc giao diện quản trị có thể không kết nối hay hoạt động ổn định.

2.1. Kết nối mạng và địa chỉ máy chủ​

• Chốt IP tĩnh, subnet mask, gateway, hostname/domain, DNS server và NTP server cho từng appliance Guardium, database server và admin workstation. Đây là nhóm thông tin IBM yêu cầu chuẩn bị trước khi cài đặt.
• Các máy phải liên lạc được theo đúng topology đã chọn. Basic Stand-alone cần đường truyền giữa database server và Collector. Mid-size cần bổ sung đường truyền Collector–Aggregator và Central Manager–managed unit.
• Lập firewall request theo cặp source–destination cụ thể. Mỗi rule cần có owner, mục đích, thời hạn nếu là rule tạm và bằng chứng kiểm thử; không dùng rule Any–Any.

2.2. Đồng bộ thời gian (NTP)​

• Guardium appliance, database server và nguồn log liên quan phải đồng bộ thời gian và timezone. Audit record sai lệch thời gian làm khó đối chiếu truy vấn, alert và sự cố giữa Guardium, DBMS và SIEM.
• GDP 12.x sử dụng chronyd. Việc đổi timezone có thể làm restart dịch vụ nội bộ và tạm dừng monitoring trong vài phút, vì vậy nên hoàn tất trước khi đưa S-TAP vào giám sát.

2.3. Database, S-TAP và kế hoạch thay đổi​

• Kiểm tra DBMS version, OS, kernel/architecture, S-TAP package, GIM package và data source support trước khi cài. Ghi rõ instance/service name, listener port, mã hóa kết nối, connection pool và owner của database.
• Lập maintenance window, test case và rollback plan trước khi cài hoặc nâng cấp S-TAP/inspection engine. Bắt đầu bằng một database và policy hẹp để xác nhận activity được ghi nhận đúng.
• Đối với Vulnerability Assessment (VA): tạo account assessment riêng, test kết nối, chạy assessment nhỏ, xác minh finding cùng DBA và quét lại sau remediation

3. Port Requirements​

Port Requirements xác định chính xác cổng nào được mở giữa thành phần nguồn và thành phần đích. Không phải mọi cổng trong bảng đều dùng cho mọi LAB. Chỉ chọn dòng phù hợp với hệ điều hành của S-TAP, chế độ TLS, việc có dùng GIM, topology Basic/Mid-size và port listener thực tế của database.

3.1. Các nhóm cổng:​

• Cổng quản trị 8443/TCP TLS: admin workstation dùng để truy cập Guardium Web UI. Chỉ cho phép subnet quản trị; không công bố Web UI ra Internet công cộng.
• S-TAP trên Linux/UNIX: 16018/TCP TLS là kênh mã hóa nên ưu tiên. 16016/TCP là kênh không mã hóa và cần mở hai chiều nếu dùng, vì nó phục vụ đăng ký, heartbeat, data traffic và một số thao tác do Collector khởi tạo.
• S-TAP trên Windows: 9801/TCP là S-TAP TLS dùng protocol V8; 9800/TCP là bản không TLS. Các cổng 9500/9501 thuộc protocol V7 cũ, chỉ xem xét khi môi trường đang cấu hình theo protocol đó; không tự đưa vào LAB mới.
• GIM: Guardium appliance chạy GIM server lắng nghe 8445/TCP; database server/GIM client dùng 8446/TCP để kết nối TLS tới GIM server. Chỉ mở khi thực sự dùng GIM để quản lý agent.
• CAS (Configuration Audit System): 16017/TCP là không TLS và 16019/TCP là TLS. Đây là cổng cho CAS, không phải cổng S-TAP mặc định; không mở nếu LAB không dùng CAS.
• S-TAP pooling: 16020/TCP và 16021/TCP TLS chỉ áp dụng cho pooling trên UNIX/Linux. Chúng không phải cổng đăng ký managed unit.

3.2. Ma trận cổng cho LAB on-premises​