Elastic Stack의 수집·검색·시각화

01개념과 구성 요소

• ElasticsearchJSON 문서를 타입·색인 구조에 따라 저장·검색·집계한다.
• 수집·가공Beats·Logstash·ingest pipeline 등이 입력을 이벤트와 의미 있는 필드로 바꾼다.
• KibanaData view와 조회 조건으로 저장된 자료를 탐색·시각화하며 직접 수집기의 역할을 대신하지 않는다.

02JSON 입력을 Discover에서 읽기까지

1. 입력 이벤트 생성Agent나 Logstash input이 자료를 받으며 codec이 JSON 같은 표현을 해석한다.
2. 필드·시간 가공Filter 또는 ingest pipeline이 값을 추출·변환하고 사건 시각을 @timestamp로 해석한다. 실패 태그와 원본을 보존한다.
3. 보호된 출력 연결전송 경로의 TLS 서버 검증과 수집 계정의 인증·index 권한을 적용한다.
4. 문서 저장Mapping과 template이 타입을 정하고 index 또는 data stream의 저장 경로가 문서를 받는다.
5. 검색·표시Kibana의 data view·시간 필드·기간·필터로 문서를 조회한다. 빈 패널이 곧 수집 실패를 뜻하지는 않는다.

03ELK의 세 역할과 데이터 이동

• ELK 역할Elasticsearch·Logstash·Kibana는 입력 이벤트를 가공·저장하고 검색 화면에서 조회하는 흐름을 구성한다. Elasticsearch는 JSON 문서 검색·집계, Logstash는 입력의 파싱·가공·전달, Kibana는 Elasticsearch의 조회·시각화·관리 인터페이스다.
• 탐지 구성이 세 제품을 설치했다는 사실만으로 보안 탐지 규칙과 대응 절차가 완성되는 것은 아니다.
• 가공 위치수집 에이전트가 Elasticsearch로 직접 보낼 수도 있고 Logstash나 ingest pipeline에서 가공할 수도 있다. 어느 구성에서도 원본 필드가 언제 변환되는지와 어떤 시간이 사건 시각인지가 검색 결과를 결정한다.
• 저장소 비교RDBMS도 JSON과 다양한 스키마를 지원할 수 있다. 저장소는 데이터 형태만이 아니라 검색·집계·운영 요구에 맞춰 선택한다.

04Document·Index·Shard·Replica

• Document·Index·ShardDocument는 필드와 값의 JSON 단위이고 index는 문서를 조직하는 논리적 검색·저장 대상이다. index의 데이터를 나눈 primary shard는 분산 배치·검색의 단위이며 replica shard는 primary의 복제본이다.
• Replica와 백업replica를 만든다고 독립 백업 이력이 생기는 것은 아니고 삭제·손상된 논리 변경도 반영될 수 있다.
• 노드 배치“샤드를 다른 서버로 보내면 replica 서버”라는 고정 역할로 외우기보다 노드가 primary와 replica를 배치받고 클러스터가 그 상태를 관리한다고 이해한다. replica 수가 있어도 배치할 다른 적절한 노드가 없으면 할당되지 않을 수 있다.

05Mapping은 필드 타입의 계약

• 타입 계약Elasticsearch가 JSON을 받는다는 것은 모든 필드 타입을 자유롭게 섞어도 된다는 뜻이 아니다. 동일 필드가 한 문서에서는 숫자, 다른 문서에서는 객체라면 mapping 충돌로 거부될 수 있다.
• 검색 의미date·ip·long·keyword·text 등 타입은 가능한 검색·정렬·집계 의미를 결정한다.
• Text·Keywordtext는 analyzer가 토큰으로 나누어 전문 검색에 사용하고 keyword는 식별자·코드처럼 전체 값을 기준으로 필터·집계하는 데 쓰인다. 숫자로 보여도 우편번호나 규칙 ID처럼 산술이 필요 없는 식별자를 숫자 타입으로 고정하면 앞자리 0이나 형식 변화에 문제가 생길 수 있다.
• 동적 필드동적 필드가 무제한 늘면 mapping 관리와 메모리 부담도 커진다.

{
  "properties": {
    "@timestamp": {"type":"date"},
    "message": {"type":"text"},
    "event.outcome": {"type":"keyword"},
    "source.ip": {"type":"ip"},
    "source.port": {"type":"integer"}
  }
}

매핑 개념을 설명하는 부분 예입니다. index template 전체 설정은 아닙니다.

06Analyzer·역인덱스·집계

• 역인덱스역인덱스는 토큰에서 그 토큰을 포함하는 문서로 연결한다. “user login failed”라는 문장을 분석한 토큰은 검색어 분석 결과와 대조된다.
• Analyzer사용한 analyzer의 대소문자·언어·토큰화 규칙에 따라 결과가 달라지므로 원문 문자열과 검색 토큰은 같은 객체가 아니다.
• 집계·정렬정확한 값별 집계와 정렬은 필드 타입 및 해당 타입의 저장 구조에 영향을 받는다. 전문 검색에 적합한 message와 source.ip·event.outcome의 집계 목적을 분리하면 탐지 쿼리가 명확해진다.
• 색인 구조모든 데이터를 @timestamp 순서로 정렬해 놓기만 해서 검색이 빨라지는 구조로 설명하지 않는다.

07Logstash input→filter→output

• Input·Filterinput은 파일·네트워크·표준입력 등에서 이벤트를 만들고 codec은 입력 표현을 해석한다. filter는 패턴 추출·타입 변환·시간 파싱·태그 추가를 수행한다.
• Outputoutput은 처리 결과를 Elasticsearch 같은 목적지로 보낸다. 한 파이프라인의 stdout 출력은 처리 결과를 관찰하는 창이며 DB 저장 성공 자체의 증거는 아니다.
• Date 예시아래는 입력 JSON에 있는 event_time을 @timestamp로 해석하는 무해한 예다. ISO8601 시간에서 timezone을 포함한 값과 포함하지 않은 값을 섞으면 해석 기준이 달라질 수 있다.
• 파싱 실패파싱 실패 태그는 정상 검색에서 조용히 제외하지 말고 별도 집계해야 수집량과 유효 이벤트량을 구분할 수 있다.

input { stdin { codec => json } }
filter {
  date { match => ["event_time", "ISO8601"] target => "@timestamp" }
  mutate { add_field => { "lab" => "elastic-training" } }
}
output { stdout { codec => rubydebug } }

원리를 설명하는 가상 학습 예시입니다.

11Grok·구조화 입력과 실패 처리

• Grok·구조화 입력Grok은 정규식 패턴을 이름 붙인 조각으로 결합하여 문자열에서 필드를 추출한다. 일정한 구분자로 분리되는 로그는 다른 파서가 더 단순할 수 있으며, JSON 로그를 받는다면 이미 있는 구조를 다시 임의 정규식으로 분해할 필요가 없다.
• 지원 문법실제 원본 예와 실패 예를 보존하여 어떤 문법을 지원하는지 정의한다.
• 타입·원본파싱 후 포트가 문자열로 남았는지 숫자로 변환되었는지, 빈 값을 0으로 바꾸지 않았는지, 같은 키가 덮어써지지 않았는지가 중요하다. 손실을 줄이려면 event.original 같은 원본 보존 필드와 파서 버전을 연결한다.
• 유효 건수잘못 파싱된 이벤트를 버린 뒤 총 입력 건수만 정상이라고 표시하면 탐지 공백이 숨겨진다.

12Beats·Module·Metricset

• Beats·ModuleFilebeat는 파일 로그, Metricbeat는 시스템 지표, Packetbeat는 네트워크 프로토콜, Auditbeat는 감사·무결성, Heartbeat는 가용성 관찰을 맡는다. Module은 서비스별 수집·처리 설정 묶음이고 Metricset은 그 안의 구체 측정 종류다.
• MetricsetMetricbeat system 모듈의 CPU·memory·filesystem 항목은 같은 호스트의 서로 다른 지표를 만든다.
• Setup·Outputsetup.kibana는 대시보드 등 초기 자산 배치와 관련되고 output.elasticsearch는 이벤트 전송 경로다. Kibana의 화면을 열어 두어야 이벤트가 저장되는 것은 아니다.
• 권한·저장 확인setup 작업의 권한과 지속 수집 계정의 권한을 나눌 수 있다. data stream이 존재한다는 사실만으로 이번 입력이 저장됐다고 결론 내리지 않고 새 문서 시각과 건수까지 연결한다.

13TLS의 서버 검증과 계정 인증

• CA·키 저장소http_ca.crt는 HTTP 계층 서버 인증서를 검증하는 신뢰 CA 자료이며 비밀번호나 서버 개인키가 아니다. http.p12와 transport.p12는 각각 HTTP 연결과 노드 간 통신용 키·인증서 저장소 역할을 가질 수 있다.
• TLS와 계정서버 이름·유효기간·체인·키 소유 증명을 검증한 TLS 채널 안에서 API 계정·키에 대한 인증과 인가가 이어진다.
• SAN·Localhostlocalhost와 127.0.0.1 중 하나가 항상 정답인 것은 아니다. 연결 주소가 인증서 SAN과 일치해야 하고 컨테이너 안의 localhost는 그 컨테이너 문맥을 가리킨다.
• Enrollment TokenEnrollment token은 Kibana 초기 연동에 사용하는 것이며 매번 사용자 로그인에 입력하는 일반 암호가 아니다.

수업 원본 자료

Metricbeat와 Elasticsearch의 TLS 신뢰 관계

원본 크기로 보기 ↗

이 자료에서 읽어낼 것

1. 서버 인증서가 왼쪽으로 전달됨 → 클라이언트가 서버 신원을 검증한다.
2. http_ca.crt → 서버 개인키가 아닌 신뢰 CA 자료다.
3. 단순화된 원본 학습도로 실제 TLS 메시지 전체와 계정 인증을 생략한다.

14Keystore·전용 계정·출력 권한

• KeystoreLogstash·Beats keystore는 비밀값을 보관하고 설정에서 참조할 수 있게 한다. keystore를 쓴다고 아무 사용자나 읽을 수 있는 설정·파일 권한 문제가 사라지는 것은 아니다.
• 수집 계정실습에서 사용한 최고 권한 계정은 간단한 연동 확인을 위한 것이며 지속 수집에는 필요한 index에 대한 제한된 권한을 부여한다.
• 실패 단계연결 오류는 DNS·TCP·TLS·계정 인증·index 권한·mapping의 단계로 나뉜다. TLS를 통과해 403을 받았다면 네트워크가 완전히 끊긴 것과 다른 문제다.
• 검증 우회 금지인증서 검증을 끄거나 관리자 비밀번호를 설정 파일에 복사하는 것을 일반적인 해결책으로 삼지 않는다.

15Data stream·Template·보존 정책

• Template·Data StreamTemplate은 이름 패턴에 맞는 mapping·설정·data stream 구성을 정의하는 틀이다. data stream은 시계열성 문서의 여러 backing index를 하나의 이름으로 다루도록 하며 rollover와 보존 정책이 저장량을 관리한다.
• 날짜 Index날짜가 붙은 모든 index가 자동으로 data stream인 것은 아니다.
• 수명주기단순 날짜별 index 출력과 ILM을 통한 수명주기 관리는 별도 설정이다. 학습용 출력이 작동했다는 의미와 운영 보존이 정해졌다는 의미를 분리한다.
• 보존 용량보존 기간·replica·압축·원본 크기·필드 수는 필요한 디스크를 바꾸며, 오래된 자료를 삭제하는 시점과 법적·업무적 보존 요구는 별도의 운영 결정이다.

16Discover에서 세 건의 수업 로그 읽기

• 세 교육 메시지원본 캡처는 elk-basic data view와 Last 7 days 기간에서 Documents (3)을 보여 준다.
• 조회 증거 범위“ELK 첫 번째 테스트 로그”, “사용자 로그인 성공”, “결제 처리 중 오류 발생”이라는 교육 메시지에 @timestamp, lab, message, event.original, _index가 함께 보인다. 이는 텍스트가 이벤트로 저장되어 조회되었다는 증거이며 실제 로그인·결제 시스템의 장애 기록이라는 뜻은 아니다.
• Data ViewData view는 대상 index·data stream을 조회하는 논리적 설정이고 그 자체가 데이터를 수집하지 않는다. 문서가 있어도 기간·시간 필드·필터·권한이 다르면 화면에 나타나지 않는다.
• 시간·필터대시보드 패널이 비어 있을 때 저장 실패와 조회 범위 불일치를 구분하려면 먼저 Discover에서 문서와 필드를 직접 읽는다.

수업 원본 자료

Discover에서 확인한 세 건의 교육 로그

원본 크기로 보기 ↗

이 자료에서 읽어낼 것

1. Documents (3) → 선택한 기간과 data view에서 세 이벤트가 조회된다.
2. message와 event.original → 표시용 문장과 원본을 함께 읽을 수 있다.
3. _index elk-basic-2026.08.31 → 문서의 저장 대상이 표시된다.
4. 교육 메시지 세 건의 조회 결과이며 운영 시스템의 실제 사고 통계가 아니다.

17검색 문법과 상관분석의 전제

• KQL·ES|QL 비교KQL은 주로 필터 표현, ES|QL은 파이프 형태의 조회·변환·집계 언어이다. SPL이나 SQL과 단순 문자열 치환으로 동일해지지 않는다.
• 필드 의미같은 질문을 비교하려면 시간 범위, 누락 필드, 다중 값, 중복 이벤트 기준을 맞춘다. event.category=authentication과 event.outcome=failure를 쓰려면 수집 파서가 그 의미를 정확히 채워야 한다.
• ECSECS는 공통 필드 의미를 제공하지만 모든 사용자 JSON이 자동으로 ECS가 되지는 않는다. 출발지와 목적지, 사건 발생 시각과 수신 시각, 호스트 이름과 고유 ID를 일관되게 해석해야 여러 데이터가 관계를 가진다.
• 관계의 재현로그를 많이 저장한 것보다 그 관계를 재현 가능한 쿼리로 설명하는 것이 관제의 다음 단계다.