IBM QRadar Structure

QRadar의 구조는 단순합니다.

 

올인원 콘솔이 있고

콘솔에 연결된 이벤트 프로세서 또는 플로우 프로세서

콘솔 또는 프로세서에 연결된 이벤트 콜렉터 또는 플로우 콜렉터(비슷하지만 다른 말로 QNI)

데이터 노드가 각 지점마다 연결될 수 있습니다.

 

콘솔과 프로세서는 HA 고가용성으로 Primary, Secondary로 이중화를 할 수 있습니다.

 

HA를 뺀 구조도는 대충 이렇게 그려집니다.

데이터노드를 프로세서에 붙일 수도, 콘솔에 붙일 수 있습니다.

 

QRadar는 라이센스만 지원한다면 최대 96TB까지 이벤트를 실시간 분석할 수 있습니다.

그리고 CVE 기반의 취약점을 자동으로 진단하고 거의 모든 기능을 UI로만 관리할 수 있습니다.

 

이제 그림에 나온 각 장비의 역할을 알아볼까요?

• Event Collector: 이벤트 로그 수집, 전달
• Event Processor: 수집된 이벤트 로그를 받아서 분석, 파싱, 정규화
• QFlow 또는 QRadar Network Insight: 트래픽 수집, 전달
• Flow Processor: 수집된 트래픽을 받아서 파싱, 정규화
• Data Node: 이벤트나 트래픽을 저장만 해두는 공간
• All-in-one Console: 사용자 인터페이스와 실시간 이벤트 로그 및 트래픽 뷰 제공, Report, Offense, Asset 등 기능제공

 

장비를 알아봤으니 Daemon 서비스도 알아봅시다.

 

• tomcat: httpd 서비스, GUI에 내용 표시 (웹이 말썽이면 tomcat 재시작)
• hostcontext: 콘솔 및 관리 대상 호스트에서 실행되는 기본 프로세스, 모든 핵심 QRadar 프로세스 제어(tomcat, postgres, ariel, qflow 등)
• hostservices: 데몬 동작, 메세지 큐, QRadar 구성요소와 PostgreSQL 사이의 통신 지원
• ariel: DB 검색, 검색 ID 및 결과 조회
• ariel_proxy_server: 프로세스 검색
• ariel_query_server: sql cursor 포맷을 사용해 ariel_proxy_server에 결과 반환, 호스트 요청 수집
• ecs-ec-ingress: 이벤트 데이터 수집
• ecs-ec: 이벤트 데이터의 파싱 및 정규화
• ecs-ep: Rules, Routing, 이벤트 저장 및 분석

 

이 구조를 알아야 OSI 7 layer처럼 엉뚱한 곳에 시간낭비를 하는 일이 줄어듭니다.

 

초보인 제가 더 알아야하는 구조인 것이지요..