💭 Minji's Archive

[2SeC] SIEM 구성 전 배경지식

December 03, 2025

2SeC 프로젝트에서는 IaC 기반 AWS 인프라 위에 실습용 웹 서비스(DVWA/Juice Shop)를 구성하고, 다양한 보안 로그를 수집·저장·모니터링할 수 있는 SIEM 환경을 구축하는 것”이 1차 목표이다. 이후 2차 확장 목표로 LLM 기반 SOAR 기능 및 CTI 연동까지 고려하고 있다.

Sprint 1: 웹서비스 배포 + SIEM 구축 Sprint 2: SIEM 환경에서 위협 침투 로그 생성 -> 이벤트 모니터링 까지가 MVP Sprint 3: 시간 보고 CTI 연동 + LLM 연동 + 트러블슈팅 + 발표자료 제작 등등…

이렇게 구성했고, 나는 SIEM 엔지니어 + CTI 플랫폼 구성을 담당하기로 했다.

SIEM 엔지니어가 반드시 준비해야 하는 사전 배경지식

1. AWS 인프라 및 로그 생태계

SIEM은 로그를 중심으로 움직이기 때문에 아래 항목들은 이해해야 한다.

1. AWS 기본 구성 요소

1) EC2, VPC, Subnet, 보안그룹 구조

1-1) VPC, Subnet, Routing의 큰 그림: VPC(가상 네트워크) -> Subnet(구역) -> 라우팅&게이트웨이 -> 인스턴스(EC2 등)

(1) VPC

  • AWS에서 제공하는 사용자의 “전용 가상 네트워크”이고, IP 대역을 가지고 그 안에 여러 Subnet을 나눔.
  • 인터넷과 직접 연결되지 않고 IGW, NAT 등을 통해 이루어짐.
  • IGW: VPC와 인터넷을 연결. Public Subnet과 연결
  • NAT Gateway: Private Subnet에서 아웃바운드로 인터넷으로 나갈 때 사용
  • VPC 단위로 VPC Flow Logs를 켤 수 있음 -> 네트워크 흐름 분석의 기본 단위

(2) Subnet: VPC 내부를 더 잘게 나눈 “구역”

  • Public Subnet: 인터넷 게이트웨이(IGW)를 통해 외부와 통신 가능한 구역
  • Private Subnet: 직접 인터넷에 안 나가는 구역 (DB, 내부 시스템)
  • Route Table: 서브넷의 길 안내서. 어느 서브넷이 외부와 통신 가능한지, 우회 가능성 등을 아키텍처 레벨에서 이해하는 데 필요함.
  • 공격 트래픽이 어느 Subnet으로 들어왔는지, DB 있는 Private Subnet까지 도달했는지 등을 Flow Logs로 분석 가능.

1-2) EC2와 보안 그룹

  • EC2: AWS에서 제공하는 가상머신. ENI(Elastic Network Interface, 네트워크 인터페이스)를 통해 VPC/Subnet에 붙음
  • Security Group(SG): EC2 등에 붙는 가상 방화벽. 인바운드/아웃바운드 규칙을 설정해야 함. Stateful(상태 저장) 방화벽으로, 인바운드 허용 시 관련 아웃바운드 자동 허용 등의 특성이 있음.
  • SG 설정이 허술하면 공격 표면이 넓어짐.
  • VPC Flow Logs와 함께 보면 “허용/차단된 트래픽 패턴”을 간접적으로 추적할 수 있음.

1-3) ALB 사용 시 로그 흐름

  • ALB를 쓰는 경우 트래픽 흐름: Client -> ALB(공인 IP/도메인) -> Target Group -> EC2 인스턴스들
  • 클라이언트는 ALB의 DNS으로 접속함.
  • ALB가 라운드 로빈/라우팅 규칙에 따라 백엔드 EC2로 트래픽 전달
  • 이 과정에서 ALB Access Logs 남기게 설정 가능

  • ALB Access Log에 담기는 주요 정보:

    • 요청 시간
    • 클라이언트 IP
    • Target(백엔드) IP/Port
    • 요청된 URL, HTTP Method, 응답 코드
    • 지연 시간 (응답까지 걸린 시간)

  • SIEM 관점에서는:

    • 웹 공격 패턴 탐지의 1차 데이터 소스
    • 특정 IP에서 비정상적인 요청 반복 여부, 특정 URL에 대한 brute-forcing 시도 등을 볼 수 있음
    • 백엔드 EC2 로그(Apache/Nginx)와 조합하면 스토리라인 재구성에 유리함.

**1-4) ** IAM 권한 모델 및 CloudTrail 구조 (1) IAM: AWS의 권한 시스템

  • User, Group, Role, Policy (JSON 기반 권한 정의)
  • Role: EC2, Lambda 등의 리소스에 부여해서 AWS API 호출 권한을 위임함.
  • 보안/로그 관점에서 중요한 이유는 침해사고 시 “누가 어떤 AWS API를 호출했는지 추적”할 수 있기 때문이다.

(2) CloudTrail

  • AWS API 호출 기록을 남기는 서비스 (ex: EC2 START/STOP, IAM policy 변경, S2 버킷 정책 수정)

  • 기록 내용

    • 호출 주체(사용자, 역할, 서비스)
    • 호출한 API 이름
    • 호출 시각, 소스 IP, 지역
    • 요청/응답 파라미터 일부

  • 구조적:

    • 각 리전별로 이벤트 생성
    • Trail 생성하면 로그를 S3에 저장하고, CloudWatch Logs로도 전송이 가능함.
  • SIEM 관점에서는 AWS 계정 내부에서의 행위를 추적하는 핵심 소스로 작용함.

1-5) S3 버킷 + 수명주기 정책 (1) S3 (Simple Storage Service)

  • 객체 스토리지 (파일 저장소)
  • ALB Access Logs / CloudTrail Logs를 저장하는 위치

2. AWS 로그 유형

2-1) CloudTrail (API 호출)

  • AWS 계정 내에서 발생하는 관리형 이벤트 + 선택적으로 데이터 이벤트 기록
  • 주요 필드: eventTime, eventName, userIdentity, sourceIPAddress, requestParameters / responseElements (어떤 리소스 대상으로)
  • 계정 탈취 감지: 낯선 IP/Region에서 로그인 후 이상한 API 호출
  • 권한 상승/설정 변경 탐지
  • 데이터 유출 징후: S3 GetObject 반복 요청, ListBuckets 패턴 갑자기 증가

2-2) VPC Flow Logs (네트워크 단위 트래픽 흐름 기록)

  • VPC/Subnet/ENI 단위에서 통과하는 네트워크 트래픽 메타데이터를 기록
  • 패킷 내용(페이로드)는 보지 않고 메타데이터만 확인
  • srcaddr/dstaddr, srcport/dstport, protocol, action, bytest/packets, start/end, interface-id
  • 포트스캔 감지: 한 IP에서 여러 포트로 SYN 시도 (Accept/Reject 패턴)
  • 비정상 통신: Private Subnet의 DB에서 인터넷 쪽 특정 IP로 나가는 이상한 트래픽
  • 정책 검증: 원래 차단되어야 할 포트인데 ACCEPT가 뜨는 경우 -> SG/NACL 설정 문제

2-3) ALB/NLB Access Logs

  • HTTP 레벨 정보가 풍부하고 공격 패턴 분석에 적합함
  • 주요 정보: 요청 시간, 클라이언트 IP, Target IP/Port, 요청 라인(method, URL, HTTP version), 응답 코드, User-Agent, 리스폰스/타겟 처리 시간
  • 웹 공격 탐지: URL, QueryString에 포함된 특수 패턴
  • 브루트포스 로그인: 특정 IP에서 /login같은 URL로 401/403 반복
  • 특정 User-Agent 기반의 봇/스크립트 트래픽

  • NLB Access Logs

    • NLB는 L4 레벨 로드밸런서라 L7 정보(URI 등)은 없음
    • 기본적으로 어느 IP가 어느 포트로 연결했는지 정도의 정보
    • 웹 공격 패턴 탐지에는 ALB가 훨씬 유리함

2-4) CloudWatch Logs

  • AWS 서비스나 애플리케이션 로그를 모아서 저장하는 중앙 로그 서비스
  • EC2에 CloudWatch Agent 설치 -> OS/애플리케이션 로그를 CloudWatch Logs로 전송
  • Lambda, API Gateway, RDS 등은 기본적으로 CloudWatch Logs와 연동됨

  • 구조:

    • Log Group: 애플리케이션 또는 서비스 단위의 “로그 묶음”
    • Log Stream: 인스턴스/컨테이너 등 세부 단위
  • 다양한 로그의 중간 허브 역할 (ex: CloudTrail -> CloudWatch Logs -> 구독으로 SIEM/ELK로 전송)
  • Metric Filter 설정으로 특정 패턴을 카운트화

2. 웹 공격 패턴

  • SQL Injection
  • Command Injection
  • Brute-Force
  • LFI/RFI -> 특이한 파일 경로 접근
  • CSRF -> Referer/Origin 패턴 기반 탐지
  • XSS -> 특수문자 + 스크립트 삽입 흔적

3. ELK 스택 및 OpenSearch 구조

핵심 구성요소

  • ElasticSearch / OpenSearch: 인덱싱 및 검색
  • Logstash / Filebeat: 로그 수집 및 전송
  • Kibana / OpenSearch Dashboards: 시각화, 검색, 대시보드, 알림

필수 기술적 개념

  • Index: 로그 저장 단위
  • Mapping: 필드 데이터 타입 정의
  • Query DSL: 검색 쿼리 작성 방법
  • Dashboard: 분석용 시각화
  • Alerting Rule: 특정 조건 발생 시 슬랙/웹훅 알림

4. 로그 파이프라인 흐름에 대한 이해

우리 프로젝트 같은 경우 DVWA -> Filebeat -> Logstash -> ElasticSearch -> Dashboard (-> Alerting) 전체 흐름을 트러블슈팅 할 수 있어야 함

5. 탐지 룰 (Sigma, Elastic Query)

기본 역량

  • Sigma Rule 작성 구조 이해
  • Windows/Linux 로그 구조 이해
  • 웹 서버 로그 필드 구조 이해 (Apache, Nginx)
  • 패턴 기반 탐지 및 “False Positive 튜닝”

실제 프로젝트에서의 업무 흐름

1. SIEM 아키텍처 확정

  • OpenSearch vs ELK Stack? -> ELK Stack 사용 예정
  • SIEM 아키텍처 다이어그램 그려보기

2. 로그 수집 경로 설계

  • DVWA/Juice Shop에서 생성될 로그들의 흐름을 정리:

    • 웹 서버 로그 위치 확인 (EC2 내부)
    • Filebeat 설치 및 모듈 설정
    • 수집 포맷(JSON, plain text, Nginx module)
    • S3 장기 저장 여부 결정
    • OpenSearch 인덱스 정책 설정

  • 로그 파이프라인 설계 문서 작성하기

3. Filebeat / Logstash 설치 및 세팅

  • EC2에 filebeat 설치
  • Filebeat.yml 수정해 수집할 로그 경로 설정
  • OpenSearch/ElasticSearch 연결 테스트
  • 인덱스 자동 생성 정책 설정
  • 파싱 테스트
  • 로그가 SIEM으로 잘 들어오는지, 필드 타입이 깨지지 않고 들어오는지 확인

4. 공격 로그 생성 및 분석

  • 공격 전 baseline 로그 캡처
  • 공격 후 로그 변화 분석
  • 공격 한 번당 로그 패턴 수집
  • 공격 -> 로그 -> 의미 해석 순서로 분석
  • 공격 시나리오별 로그 패턴 분석 문서 작성

5. 탐지 룰 (Sigma/Elastic Rule) 작성

  • 로그 패턴 정리 -> 탐지 조건 식으로 변환

6. 대시보드 구성 (Kibana / OpenSearch Dashboards)

7. Alerting 설정