040. SIEM·로그 수집 — 수집 아키텍처 종합 점검 — 소스에서 저장까지

SIEM SIEM · 보안관제 Soc Wazuh 보안관제 아키텍처점검 종합점검

SIEM · 보안관제 › A. SIEM 구조와 로그 수집 · 40/50편
학습 단계: 저장·파이프라인
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Wazuh 4.x 올인원 / Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

039. SIEM·로그 수집 — 로그 무결성과 중앙 수집의 가치

1. 개념

A영역 전반부(001~039)에서 다룬 내용을 소스 → 수집 → 디코딩 → 분석 → 전송 → 저장의 한 흐름으로 묶어 점검표로 정리합니다. 관제원이 "로그가 안 보인다"는 상황에서 어디서부터 볼지 정하는 기준표입니다.

수집 아키텍처 점검 지도
 [소스]   로그 생성?  (서비스·감사 설정·journald)            ← 009~019
   ↓
 [수집]   에이전트 Active? localfile 등록? syslog 허용?     ← 006~008, 017
   ↓
 [디코딩] 디코더 매칭? 필드 추출? 정규화?                  ← 021~030
   ↓
 [분석]   analysisd 정상? events_dropped 0?                ← 005, 037
   ↓
 [전송]   filebeat/logstash in=out? TLS 정상?               ← 035~038
   ↓
 [저장]   cluster green? 오늘 인덱스? 매핑 충돌? 보존?      ← 031~034
   ↓
 [표시]   인덱스 패턴·시간대·필터                          ← 041~ 이후

핵심: 위에서부터 차례대로 — 건너뛰면 엉뚱한 곳을 고친다

이 점검표는 신규 소스 편입 체크리스트로도 그대로 쓸 수 있습니다. 각 구간을 통과해야 비로소 "수집된다"고 말할 수 있습니다.

2. 왜 중요한가

장애 대응 시 확인 순서를 표준화합니다.
신규 소스 편입 기준을 명확히 합니다.
A영역 지식을 하나의 운영 도구로 묶습니다.

3. 핵심 명령어 / 설정

구간	핵심 확인	대표 장애
소스	원본 로그 생성	감사 설정 변경
수집	Active·Analyzing file	경로 오타·끊김
디코딩	logtest 필드	형식 변경
분석	events_dropped	룰 문법 오류
전송	in=out	필터 병목·인증서 만료
저장	health·오늘 인덱스	디스크 초과

4. 실습 (실습 예시)

# 종합 점검 스크립트 골격 (분석 방법)
echo "[분석] $(sudo /var/ossec/bin/wazuh-control status | grep -c 'is running') daemons running"
echo "[에이전트] $(sudo /var/ossec/bin/agent_control -l | grep -c Disconnected) disconnected"
echo "[드롭] $(sudo grep -oP "events_dropped='\K[0-9]+" /var/ossec/var/run/wazuh-analysisd.state)"
echo "[전송] $(systemctl is-active filebeat)"
echo "[저장] $(curl -sk -u 'admin:<비밀번호>' https://localhost:9200/_cluster/health | grep -oP '"status":"\K[a-z]+')"
echo "[오늘 인덱스] $(curl -sk -u 'admin:<비밀번호>' "https://localhost:9200/_cat/indices/wazuh-alerts-*$(date +%Y.%m.%d)?h=index" | wc -l)"

5. 정상 상태

[분석] 6 daemons running  [에이전트] 0 disconnected  [드롭] 0
[전송] active  [저장] green  [오늘 인덱스] 1

모든 구간 지표가 기준값이면 수집 아키텍처가 정상입니다.

6. 이상 상태

[분석] 6 running  [에이전트] 0  [드롭] 0
[전송] active  [저장] green  [오늘 인덱스] 1
→ 그런데 app01 shopapp 로그만 대시보드에 없음

공통 구간은 모두 정상 → 문제는 특정 소스 구간
소스(원본 생성) → 수집(localfile) → 디코딩 순으로 확인
결과: 앱 업데이트로 로그 경로 변경(/var/log/shopapp/ → /opt/shopapp/logs/)

7. 로그 분석 (분석 방법)

장애 위치 좁히기 흐름입니다(가상의 예시).

[공통 구간 점검] 분석·전송·저장 지표
   ├─ 이상 있음 → 전체 장애 → 해당 구간 복구
   └─ 모두 정상 → 특정 소스 문제
        ↓
   [소스] 원본 로그 경로·생성 확인
   [수집] localfile·Analyzing file
   [디코딩] logtest

범위	의미
전체 소스 영향	공통 구간 장애
특정 소스만	소스·수집·디코딩
특정 호스트만	에이전트·네트워크

"전체냐 일부냐"를 먼저 가르면 확인할 구간이 절반으로 줄어듭니다. 이 질문이 수집 장애 대응의 첫 단계입니다.

8. SOC 관제 포인트

종합 점검 스크립트를 교대 시작 시 실행합니다.
장애 보고에는 어느 구간에서 끊겼는지 명시합니다.
신규 소스 편입 시 구간별 통과 결과를 기록합니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,siem_a,">
  <rule id="110390" level="10">
      <decoded_as>json</decoded_as>
      <field name="check">^siem_health$</field>
      <field name="status">^fail$</field>
      <description>SIEM 종합 점검 실패 구간 존재</description>
    </rule>
</group>

종합 점검 스크립트가 실패 구간을 JSON으로 남기면 이를 경보하는 예시입니다. 실패 구간 이름(stage 필드)을 함께 남기면 대시보드에서 바로 위치를 볼 수 있습니다.

10. 대응 방법

초기 확인 — 공통 구간 지표로 전체·일부 장애를 구분합니다.
범위 확인 — 영향받는 소스·호스트 범위를 확인합니다.
증거 확보 — 구간별 점검 결과를 기록합니다.
차단/조치 — 끊긴 구간을 복구하고 누락 데이터를 확인합니다.
재발 방지 — 종합 점검을 교대 절차·편입 절차에 넣습니다.

11. 핵심 정리

순서	구간
1	소스·수집
2	디코딩·분석
3	전송·저장
첫 질문	전체인가 일부인가
면접 포인트	"로그가 안 보이면 위에서부터 차례로 — 첫 질문은 전체 장애인가 일부 소스인가"

12. 다음 편 예고

다음 편 041. SIEM·로그 수집 — 대시보드 기초 — Discover와 검색 쿼리(DQL·KQL) 에서는 Wazuh 대시보드(OpenSearch Dashboards)와 Kibana의 Discover 화면에서 시간 범위·필드 필터·DQL/KQL 질의로 Alert를 찾는 기본 방법을 다룹니다.

이전 편: 039. SIEM·로그 수집 — 로그 무결성과 중앙 수집의 가치
📚 시리즈 전체 보기: SIEM · 보안관제