IBM Guardium IBM Guardium Architecture

I. Tổng quan​

• Guardium được thiết kế để bảo vệ dữ liệu bất kể vị trí, tương thích với nhiều môi trường: on-premises, cloud, hybrid multicloud, với cơ chế quản lý tập trung và thực thi chính sách tập trung.
• Guardium tập trung hóa việc quản lý tất cả các nguồn dữ liệu: databases, big data, files, mainframe và nhiều nguồn dữ liệu đám mây khác nhau.
• Có rất nhiều phương thức triển khai mà bạn có thể sử dụng để giám sát môi trường của mình. Guardium hiện có sẵn dưới dạng thiết bị phần cứng (hardware) hoặc giải pháp phần mềm (software).
• Guardium có thể giám sát chủ động và thụ động, bằng cách sử dụng agent hoặc không cần sử dụng agent: S-TAP, E-TAP, Universal Connectors và Streaming APIs.
  • S-TAP: Là giải pháp dựa trên tác nhân (agent) dùng để giám sát theo thời gian thực các nguồn dữ liệu on-premises.
  • E-TAP: Là giải pháp proxy dựa trên tác nhân (agent) dùng để giám sát theo thời gian thực các nguồn dữ liệu cloud.
  • Universal Connectors: Giám sát thụ động, không cần tác nhân cho cả nguồn dữ liệu cloud và on-premises
  • Streaming APIs: Giám sát thụ động, không cần tác nhân dành riêng cho các nguồn dữ liệu cloud

II. Phân tích cách Guardium giám sát dữ liệu​

1. S-TAP​

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

• Database Client: Người dùng hoặc ứng dụng gửi yêu cầu truy vấn đến cơ sở dữ liệu.
• S-TAP Agent: Một phần mềm nhẹ (lightweight agent) được cài đặt trực tiếp trên máy chủ cơ sở dữ liệu. Nhiệm vụ của nó là "theo dõi" và sao chép lưu lượng truy cập.
• Guardium Collector: Một máy chủ riêng biệt (bao gồm Sniffer và Analysis Engine) nhận dữ liệu từ S-TAP để phân tích chuyên sâu.
• Sniffer: Thành phần nằm trong Collector chịu trách nhiệm nhận dữ liệu từ S-TAP, phân tích giao thức và áp dụng các quy tắc chính sách (policy).

1.2. Luồng hoạt động của dữ liệu​

Bước 1: Giao tiếp Client - Server (Bị chặn)​

Khi Database Client gửi một yêu cầu đến Database Server, hoặc khi Server phản hồi dữ liệu về cho Client, S-TAP Agent sẽ can thiệp vào các request/response

Lưu ý: S-TAP không làm gián đoạn kết nối này mà sao chép dữ liệu mà không làm chậm hệ thống đáng kể.

Ví dụ: Khi Client gửi một câu lệnh SQL

• Dữ liệu đến Database server: Câu lệnh đi thẳng từ Client vào Database Server. Server nhận lệnh, xử lý và trả kết quả về cho Client ngay lập tức.
• Dữ liệu được copy và gửi đến Guardium Collector: Cùng lúc đó, S-TAP gửi một "bản sao" của câu lệnh đó sang Collector.
• Nếu Collector phân tích xong và phát hiện hành vi bất thường
• Nó sẽ gửi lệnh "Control Signal" yêu cầu S-TAP ngắt kết nối của session này
• S-TAP lúc này mới can thiệp vào nhân hệ điều hành để đóng kết nối đó lại.

Bước 2: Sao chép và gửi dữ liệu (S-TAP to Guardium Collector)​

Sau khi thu thập được nội dung giao tiếp (ai đang truy cập, họ đang làm gì, dữ liệu nào bị lấy đi), S-TAP sẽ sao chép các thông tin này và gửi đến Guardium Collector.

Bước 3: Phân tích tại Collector​

Tại máy chủ Guardium:

• Sniffer nhận dữ liệu.
• Analysis Engine (Công cụ phân tích) thực hiện các tác vụ nặng (như phân tích cú pháp SQL, kiểm tra xem có vi phạm chính sách bảo mật hay không).
• Dữ liệu sau đó được ghi nhật ký (log) vào kho lưu trữ nội bộ để phục vụ báo cáo và kiểm toán.

Bước 4: Tín hiệu điều khiển (Control Signals)​

Sniffer có thể gửi các tín hiệu điều khiển để ra lệnh cho S-TAP
Các tín hiệu điều khiển cho các chức năng sau:
Lọc thông tin trước khi gửi đến Guardium collector để giảm lưu lượng mạng và giảm tải cho quá trình xử lý trên Guardium collector
Dựa trên chính sách của Guardium collector để:
Chặn các kết nối
Che giấu hoặc lược bỏ thông tin trong tập kết quả -> lọc để loại bỏ các thông tin không mong muốn, hoặc các phiên không được uỷ quyền và không gửi nó đến Guardium collector

1.3. Các đặc điểm quan trọng cần lưu ý​

• Tính nhẹ nhàng (Lightweight): S-TAP được thiết kế để tiêu tốn rất ít tài nguyên trên máy chủ DB. Các công việc tính toán nặng nhọc (như phân tích dữ liệu) đều được chuyển sang máy chủ Guardium Collector để đảm bảo hiệu suất của database không bị ảnh hưởng.
• Tính toàn vẹn: Mọi truy cập vào cơ sở dữ liệu, dù là 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. Điều này giúp ngăn chặn các quản trị viên hệ thống có ý định xấu thực hiện các 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.

1.4. S-TAP hoạt động với 2 submodule: K-TAP, A-TAP​

K-TAP: hoạt động ở kernel, can thiệp vào tất cả giao tiếp giữa client và server khi chúng kết nối với nhau qua Network Layer, giám sát cổng mạng của DBMS (hệ thống quản lý cơ sở dữ liệu)
K-TAP sẽ giám sát gói tin trong cả 2 trường hợp: External Network Application/User và Local Application/user (nếu đi qua Network Layer)
Shared memory: vùng nhớ dùng chung trên RAM, các truy vấn từ Local application/user đến DBMS được xử lý tại đây mà không cần cần qua Network Layer (không cần giao tiếp qua mạng)
A-TAP: truy cập vào Shared memory, giám sát các giao tiếp ở cấp độ ứng dụng giữa các thành phần nội bộ của máy chủ cơ sở dữ liệu. Nó ghi lại các lưu lượng truy cập mà chỉ có thể bắt được tại tầng ứng dụng của máy chủ cơ sở dữ liệu.
A-TAP sử dụng K-TAP làm trung gian (proxy) để chuyển dữ liệu về cho S-TAP.
Tee: Là một cơ chế proxy 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. Tee là một giải pháp thay thế cho K-TAP
PCAP (Packet Capture): Hiếm khi được sử dụng trên các hệ thống UNIX, nhưng có ứng dụng hạn chế trên hệ thống Windows và Linux.
S-TAP có thể nhận data từ exit libraries: Db2 Exit
Với Database platforms: Db2, Guardium cung cấp sự tích hợp chuyên biệt thông qua Db2 Exit module
Module này được cài đặt trực tiếp trên DBMS
Nó tận dụng bộ nhớ dùng chung và mạng để capture và phân tích các hoạt động của database -> cách này giúp Guardium có thể thích ứng với các hệ thống database khác nhau trong khi vẫn duy trì các tiêu chuẩn giám sát nhất quán

Exit Library là một thư viện liên kết động được Db2 tải tự động trong quá trình khởi động. Thư viện Guardium được nhúng vào Db2 thông qua cơ chế Db2_Exit -> sau khi thư viện Guardium được tải thì Db2 Exit có thể giao tiếp trực tiếp với S-TAP và chuyển tất cả lưu lượng truy cập đến Db2 ( dù là lưu lượng mã hoá hay không mã hoá, cả cục bộ và từ xa)
Tuy nhiên Db2 Exit có 1 vài hạn chế sau:
Không hỗ trợ che dấu dữ liệu trước khi gửi đi
Giám sát stored procedures -> tuy nhiên Guardium không biết stored procedures nên -> các lệnh SQL bên trong stored procedures sẽ không được capture

2. E-TAP​

Với môi trường Database service -> sử dụng các container External Tap -> cấu hình để gửi các giám sát về Collector

Với môi trường On-pre host hoặc là Cloud host -> sử dụng Guardium E-TAP host: máy chủ chạy Docker và cài đặt các gói phần mềm E-TAP

E-TAP là một giải pháp thay thế cho S-TAP. Với S-TAP,, bạn phải cài đặt một "agent" trực tiếp lên hệ điều hành của máy chủ cơ sở dữ liệu (DB). Tuy nhiên, E-TAP ra đời để giải quyết các trường hợp không thể cài đặt trực tiếp hoặc việc cài đặt agent không khả thi, bao gồm:

• Database as a Service (DBaaS): Các dịch vụ như AWS RDS, Azure SQL, nơi người dùng không có quyền truy cập vào hệ điều hành của máy chủ DB.
• Môi trường Container: Nơi các database chạy trong Docker hoặc Kubernetes và việc cài agent vào từng container là không khả thi hoặc không tối ưu.

E-TAP chặn lưu lượng truy cập giữa máy khách và máy chủ cơ sở dữ liệu -> chuyển tiếp đến bản sao đến Guardium collector -> để phân tích và áp dụng chính sách -> cũng có thể kiểm soát phiên dữ liệu (xoá bỏ hoặc chấm dứt phiên)
E-TAP là nó hỗ trợ đa dạng loại hình Database:

• Database Service (DBaaS): Như AWS RDS, Azure SQL, Google Cloud SQL (những nơi bạn không có quyền cài agent).
• On-premises host: Các server vật lý truyền thống trong trung tâm dữ liệu của doanh nghiệp.
• Cloud host: Các DB chạy trên máy ảo (VM) trên đám mây.

3. Universal Connector​

Đối với một số nguồn dữ liệu, việc cài đặt S-TAP hoặc E-TAP là không khả thi. Trong những trường hợp này, Guardium sử dụng giải pháp Universal Connector để thu thập dữ liệu.
Universal Connector là một framework mã nguồn mở, trọng lượng nhẹ, được sử dụng để phát triển các plugin cho Guardium. Nó giúp giám sát các nguồn dữ liệu cloud hoặc on-premises bằng cách sử dụng các nhật ký kiểm tra (audit logs) mặc định.
Giải pháp này cho phép Guardium thu thập dữ liệu từ nhật ký hoạt động của nguồn dữ liệu mà không cần cài đặt các S-TAP hay E-TAP.
Universal Connectors có thể được tuỳ chỉnh cho nhiều nguồn dữ liệu khác nhau: MongoDB, MySQL, Amazon S3
Cơ chế hoạt động:
Nhận diện & Phân tích: Universal Connector nhận diện các sự kiện nhận được, phân tích cú pháp (parse) thành một định dạng chuẩn. Sau đó chuyển tiếp chúng đến bộ thu thập dữ liệu (Guardium collector)
Xử lý dữ liệu: Guardium collector sẽ thực hiện các Policy và Analytics với các sự kiện này
Các Universal Connector có thể được cấu hình để cân bằng tải và tự động chuyển đổi dự phòng (failover) sang các Guardium collector khác

4. Streaming APIs​

Các streaming APIs được sử dụng cho hầu hết tất cả các chức năng trên giao diện đồ họa (GUI)
Hầu hết tất cả các chức năng có sẵn trên giao diện người dùng đều được cung cấp thông qua các API.
Sử dụng API để 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 các thông tin tập trung từ Guardium bằng cách sử dụng các API online_report và quick_search

III. Capture data traffic​

1. Agent-based monitoring​

Với Agent-based monitoring, Agent được cài đặt trên nguồn dữ liệu và nằm bên trong nguồn dữ liệu để thu thập tất cả các truy cập và kết nối dữ liệu SQL, phi cấu trúc SQL và các loại dữ liệu khác.
Sau đó, Agent cung cấp dữ liệu cho Guardium collector, để thực hiện phân tích và đối chiếu với các chính sách bảo mật.
Agent thu thập các dữ liệu sau:
• Phiên giao tiếp: Ai hoặc cái gì giao tiếp với cơ sở dữ liệu?
• Yêu cầu: Dữ liệu nào được yêu cầu và ai được quyền truy cập?
• Lỗi: Những ngoại lệ nào đã xảy ra? Ghi lại các lỗi hệ thống hoặc các lần truy cập thất bại (có thể là dấu hiệu của việc dò tìm lỗ hổng).
• Tập kết quả: Dữ liệu nào được trả về cho máy khách? (để kiểm soát việc rò rỉ dữ liệu nhạy cảm).
Công cụ Sniffer sẽ parsing và phân tích lưu lượng truy cập từ các tác nhân. Nó cũng sử dụng các chính sách bảo mật đã được cấu hình để gửi các lệnh điều khiển ngược lại Agent (ngăn chặn hoặc cảnh báo)

2. Agent-proxy monitoring​

E-TAP thực hiện chức năng tương tự như S-TAP. Tuy nhiên, nó được triển khai theo cơ chế dựa trên proxy (proxy-based), nghĩa là nó nằm giữa cơ sở dữ liệu và người dùng để giám sát lưu lượng truy cập trong thời gian thực.
Kiến trúc dựa trên proxy hỗ trợ các tác nhân giám sát dữ liệu được container hóa (containerized) (Docker)
Các Agent được triển khai bằng cách sử dụng Kubernetes
Cũng có thể tự động triển khai và tự động mở rộng quy mô các E-TAP trong thời gian thực.

3. Quy trình xử lý của Sniffer đối với các dữ liệu đầu vào từ các Agent-based hoặc Agent-proxy​

Bước 1: Sniffer​

• Chức năng: Nhận dữ liệu, Sắp xếp lưu lượng nhận được.

Bước 2: Analyzer​

• Chức năng: Giải mã lưu lượng thô.
• Chi tiết: Chuyển đổi dữ liệu nhị phân thành các câu lệnh SQL mà con người có thể đọc được
• Áp dụng quy tắc chính sách (Policy): Hệ thống sẽ kiểm tra xem câu lệnh này với các policy rules

Bước 3: Parser​

• Chức năng: Chuẩn hóa hoạt động.
• Chi tiết: Breakdown các câu lệnh SQL thành các thành phần cấu trúc:Verb, Object

Bước 4: Logger​

• Chức năng: Lưu trữ dữ liệu đã xử lý.
• Chi tiết: Ghi lại các truy vấn đã được phân tích và chuẩn hóa vào đĩa cứng (Disk). Các dữ liệu được ghi xuống Disk dựa trên Chính sách (Policy) quy định - chỉ ghi lại những thông tin được cho phép để tối ưu dung lượng bộ nhớ -> phục vụ cho việc kiểm toán (Audit)

4. Universal Connector monitoring (Agentless)​

Native Audit Logs: Nhật ký về mọi hoạt động xảy ra trên Database
Store: Audit logs được đẩy vào một kho lưu trữ
Captured Data: Các thông tin được gửi đến Guardium collector (Sessions, Requests, Errors)
Universal Connector: là cổng tiếp nhận. Nó có khả năng kết nối với nhiều loại nguồn dữ liệu khác nhau mà không cần cài đặt phần mềm (agent) trực tiếp lên máy chủ cơ sở dữ liệu -> chuyển đổi dữ liệu thành format chuẩn universal để Sniffer xử lý được
Sniffer: Lọc và phân loại các hành vi dựa trên chính sách bảo mật.
Push: Logs được gửi đến Universal Connector ngay khi chúng được tạo ra.
Pull: Universal Connector chủ động kết nối vào kho lưu trữ nhật ký của database để "kéo" dữ liệu về theo định kỳ.
Phương pháp này có thể tác động đến hiệu suất database và yêu cầu lưu trữ (storage)

5. Sniffer breakdown - Agentless​

Sniffer (Bộ thu nhận): Dữ liệu này thường ở định dạng là các tài liệu JSON.
Analyzer (Bộ phân tích):Thực hiện áp dụng các quy tắc chính sách (policy rules)
Parser: Chuẩn hóa hoạt động, Breakdown các câu lệnh SQL thành các thành phần cấu trúc:Verb, Object
Logger : Ghi các hoạt động đã được xử lý vào đĩa cứng hoặc gửi chúng đến (ingestion pipeline).
Việc ghi lại này dựa trên chính sách, giúp xác định chính xác những gì cần được thu thập và lưu trữ lâu dài -> phục vụ cho việc báo cáo, kiểm tra (audit) và cảnh báo

So sánh Analyzer trong quá trình Sniffer : Agentless vs Agent-based / Proxy-based
Mô hình Agentless: Dữ liệu đầu vào thường là các tệp nhật ký (logs) đã được định dạng sẵn (thường là JSON) từ các dịch vụ Cloud hoặc Universal Connector. Các nhật ký này đã là văn bản có cấu trúc rõ ràng.
Mô hình Agent/Proxy-based: Dữ liệu đầu vào là lưu lượng mạng thô (raw traffic) dưới dạng mã nhị phân (010001 110110) được capture trực tiếp từ đường truyền giữa ứng dụng và cơ sở dữ liệu cần phải Decodes raw traffic, Extracts SQL để đưa dữ liệu về dạng cấu trúc SQL

6. Universal Connector framework and plugins​

Data Sources: MongoDB, AWS S3, rất nhiều nguồn dữ liệu khác tuỳ chỉnh (Oracle, Azure)
Guardium Universal Connector: xử lý dữ liệu thô thành dữ liệu có cấu trúc thông qua các Plugin
Input Plugin: Tiếp nhận dữ liệu thô từ nguồn.
Filter/Parse Plugin: Phân tách và định dạng lại dữ liệu (Parsing) để Guardium có thể hiểu được.
-> Mỗi loại nguồn có một bộ plugin riêng biệt
Output Plugin: Sau khi dữ liệu từ các nguồn khác nhau đã được chuẩn hóa, đẩy qua output plugin Guardium Sniffing: Kiểm tra, phân tích nội dung dữ liệu.
Policy Correlation: Đối chiếu với các chính sách bảo mật để phát hiện vi phạm (ví dụ: truy cập trái phép, rò rỉ dữ liệu).

7. Aggregation and central managers​

Mỗi Guardium Collector có giới hạn lưu lượng truy cập nhất định -> khi vượt quá giới hạn traffic -> ảnh hưởng đến việc lưu trữ dữ liệu, dữ liệu có thể bị mất mát
Trong nhiều mô hình cần thiết kế, có nhiều Guardium Collectors.
Số lượng Guardium Collectors phụ thuộc vào số lượng CPU trên từng database server, khối lượng traffic cần giám sát
Chức năng quản lý tập trung (Central Manager) và tổng hợp dữ liệu (Aggregation) dùng để quản lý các môi trường có nhiều Guardium Collectors.
Aggregation: Tổng hợp dữ liệu từ nhiều Collector.
Central Manager: Quản lý tập trung (điều khiển cấu hình, chính sách cho toàn bộ hệ thống).

7.1. Aggregation​

Aggregator là một loại thiết bị riêng biệt; không trực tiếp thu thập lưu lượng truy cập từ các database server.
Thay vào đó, Collector sẽ gửi dữ liệu mà nó đã phân tích đến Aggregator theo định kỳ, thường là hàng đêm.
Sau đó, Aggregator sẽ hợp nhất dữ liệu từ tất cả các Collector vào database nội bộ của chính Aggregator -> người dùng có thể xem toàn bộ dữ liệu từ nhiều Collector tại một vị trí trung tâm.
Collectors -> Aggregator: Các Collector (H1, H2, H3, H4) gửi dữ liệu về Aggregator theo một lịch trình đã định sẵn (scheduled basis).
Reports <- Aggregator: Các báo cáo (Reports) sẽ được trích xuất trực tiếp từ Aggregator thay vì truy vấn từng Collector riêng lẻ.
Giảm tải hiệu năng cho Collector: Việc chạy các báo cáo (queries) phức tạp thường tốn rất nhiều tài nguyên. Khi thực hiện việc này trên Aggregator, các Collector sẽ không bị ảnh hưởng đến hiệu suất hoạt động chỉ tập trung thực hiện các nhiệm vụ cốt lõi là giám sát (monitoring) và thực thi chính sách (policy enforcement)
Aggregator có cả phiên bản phần cứng (IBM x3550) và phần mềm được cài đặt trên hardware hoặc virtual machines

7.2. Central managers​

Giám sát trạng thái hoạt động của cả Collectors và Aggregators.
Hiển thị trạng thái của các S-TAP (phần mềm giám sát cài trên database) trên toàn doanh nghiệp.
Quản lý việc vá lỗi (patch management) tập trung cho toàn bộ các thiết bị trong mạng lưới.
Chính sách bảo mật: Đẩy các chính sách bảo mật thống nhất xuống tất cả các Collector được quản lý.
Quản lý người dùng: Tập trung hóa việc phân quyền, vai trò, nhóm và người dùng hệ thống.
Thiết lập các quy trình báo cáo và kiểm tra tập trung.

8. Guardium configurations​

Mô hình bao gồm nhiều collectors được quản lý bởi một Aggregators và Central Managers
Collectors giám sát nhiều nguồn dữ liệu khác nhau
Trong quy mô nhỏ chỉ có 1 Aggregators & Central Managers:
Aggregators phải hợp nhất các dữ liệu kiểm toán để phân tích trên toàn doanh nghiệp
Central Managers điều phối việc thực thi chính sách, báo cáo và đảm bảo các tiêu chuẩn an ninh được duy trì trên tất cả các môi trường đang được giám sát




Aggregators dành riêng cho các mục đích/lĩnh vực khác nhau: sale, HR.
Mỗi Aggregators thu thập các dữ liệu có liên quan, cho phép lập báo cáo và tuân thủ các quy định phù hợp với từng phòng ban khác nhau
Central Managers vẫn giám sát toàn bộ hệ thống, đảm bảo các policy được thực thi



Nhiều bộ Aggregators và Collectors được gán cho các chức năng kinh doanh khác nhau, tách riêng Central Manager
Central Manager chỉ chuyên trách các chức năng quản lý tập trung
Ví dụ: Sale và HR đều có Aggregators và Collectors riêng biệt và được quản lý chung bởi 1 Central Managers -> mô hình này hỗ trợ kiểm soát và báo cáo chi tiết cho yêu cầu nội bộ

IV. GIM - Guardium Installation Manager​

1. Khái niệm​

Guardium Installation Manager (GIM) để cài đặt và duy trì các thành phần của Guardium (ví dụ các Agent được cài đặt như S-TAP) trên các máy chủ được quản lý/máy chủ cần giám sát (các máy database server hoặc file systems)

Thành phần GIM bao gồm một GIM server (được cài đặt sẵn như một phần của hệ thống Guardium, được tích hợp sẵn trong Central Manager hoặc Collector ) và một GIM client (phải được cài đặt trên các máy chủ lưu trữ cơ sở dữ liệu hoặc hệ thống tệp mà bạn muốn giám sát).

2. Cơ chế hoạt động​

GIM client là một tập hợp các tập lệnh Perl chạy trên mỗi máy chủ được quản lý. Sau khi cài đặt, nó phối hợp với GIM server để thực hiện các tác vụ sau:

• 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.
• 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.

Ví dụ: Bạn có thể dùng GIM để cài đặt các mô-đun S-TAP và duy trì chúng luôn ở phiên bản mới nhất.

Cổng kết nối: GIM client sử dụng cổng 8444/8446 để giao tiếp với GIM server.
Giao diện điều khiển: Bạn có thể sử dụng GIM server thông qua giao diện người dùng (UI) của Guardium hoặc qua giao diện dòng lệnh (CLI).
Gói phần mềm: Các mô-đun phần mềm triển khai qua GIM được đóng gói dưới dạng GIM bundles

Lưu ý: Trong hệ thống Guardium, bất kỳ thiết bị nào (cho dù nó đóng vai trò là Central Manager (CM), Collector, hay Aggregator) thì khi cài hệ điều hành Guardium lên, bản thân nó đã có sẵn code của GIM Server rồi. bạn vào giao diện Web, tìm mục Setup -> Tools and Views -> GIM Control Panel
Nếu bạn dùng GIM trên từng Collector, sẽ bị rơi vào trạng thái "Quản lý phân tán" mà mình đã giải thích ở câu trước (phải đăng nhập từng Collector để quản lý Agent).
Thông thường sẽ cấu hình để GIM Client trên tất cả các Database Server trỏ thẳng về IP của Central Manager (GIM server)

3. Giám sát tiến trình​

GIM client giám sát các tiến trình đã cài đặt trên các máy chủ cơ sở dữ liệu

• Kiểm tra heartbeat của mỗi tiến trình mỗi phút một lần.
• Cập nhật thay đổi trạng thái về GIM server (hiển thị trên bảng Process Monitoring trong vòng 3 phút).
• Trạng thái của chính GIM client sẽ được cập nhật dựa trên khoảng thời gian (polling) server và gửi thông điệp “alive message”.

4. Backup & Restore​

GIM Failover được cấu hình trên các client phục vụ cho trường hợp backup hoặc restore