보안 로그 파이프라인의 최소 요건: 많이 모으기보다 쓸 수 있게 남기기

로그 저장량이 커져도 사고 대응이 빨라지지 않는 이유는 필요한 문맥이 빠져 있기 때문이다. 로그인 실패 수천 건이 있어도 어느 계정·기기·세션이 성공으로 이어졌는지 연결할 수 없고, 관리자가 설정을 바꿨다는 이벤트가 있어도 이전 값과 승인 티켓이 없으면 영향 범위를 판단하기 어렵다. 반대로 모든 요청 본문과 개인정보를 저장하면 비용과 유출 위험만 커진다.

좋은 로그 파이프라인은 “무엇을 저장할까”보다 “어떤 결정을 내려야 하는가”에서 시작한다. 계정 탈취, 권한 상승, 대량 조회, 정책 변경, 배포 변조 같은 우선 시나리오를 고르고, 각 시나리오를 확인하는 데 필요한 이벤트와 필드를 역산한다.

먼저 답해야 할 조사 질문

최소한 다음 질문에 정해진 시간 안에 답할 수 있어야 한다.

• 누가 어떤 인증 수단으로 언제 접근했는가.
• 어떤 계정·테넌트·자산·데이터 객체가 대상이었는가.
• 요청은 어느 기기·세션·네트워크·서비스 경로에서 왔는가.
• 허용·거부·오류 중 결과는 무엇이었고 이유 코드는 무엇인가.
• 정책·권한·설정의 이전 값과 이후 값은 무엇인가.
• 하나의 사용자 행동이 WAF, 게이트웨이, 애플리케이션, 데이터베이스에서 어떻게 이어졌는가.
• 이벤트가 생성되지 않았거나 늦게 도착한 구간은 어디인가.

질문에 답하지 못하는 로그는 보존 기간을 늘리기 전에 스키마와 생성 지점을 고쳐야 한다.

공통 이벤트 스키마의 최소 필드

영역	필드 예시	설계 주의점
시간	event_time, ingested_at, timezone	생성 시각과 수집 시각을 분리한다
주체	actor_id, actor_type, tenant_id	표시 이름보다 불변 내부 ID를 사용한다
인증	session_id, auth_method, mfa_result	비밀번호·토큰 원문은 저장하지 않는다
행동	action, event_category, reason_code	자유문장만 쓰지 말고 표준 값을 둔다
대상	resource_type, resource_id, data_class	민감 원문 대신 참조·분류를 남긴다
결과	outcome, status_code, error_class	성공·거부·시스템 실패를 구분한다
경로	source_ip, device_id, service, region	프록시 체인의 신뢰 경계를 명확히 한다
상관관계	request_id, trace_id, parent_event_id	서비스 간 전달과 중복을 검증한다
변경	change_id, old_value_hash, new_value_hash	민감 설정 원문은 별도 보호 저장소에 둔다
스키마	schema_version, producer_version	파서 변화와 하위 호환을 관리한다

필드 이름을 통일하는 목적은 예쁜 대시보드가 아니라 서로 다른 제품의 이벤트를 한 타임라인에 놓기 위해서다. 공급자 원본 이벤트는 보존하고, 정규화된 공통 필드를 별도 계층에서 생성하면 파서 오류를 되돌리기 쉽다.

최소 파이프라인 구조

이벤트 생성 → 로컬 버퍼·전송 → 수집 입구 → 원본 보관 → 파싱·정규화 → 보강 → 탐지·검색 → 장기 보존

각 단계는 다음 실패를 고려해야 한다.

• 애플리케이션이 로그를 생성하지 않음
• 에이전트 또는 네트워크 장애로 전송이 끊김
• 큐가 가득 차 이벤트가 삭제됨
• 스키마 변경으로 파싱 실패
• 보강 데이터 지연으로 잘못된 탐지
• 저장소 권한 오류로 조회·보존 실패
• 시간 동기화 오류로 타임라인 왜곡

파이프라인 자체의 상태를 애플리케이션 상태와 같은 수준으로 모니터링한다. 마지막 이벤트 시각, 예상 대비 이벤트 수, 지연 백분위, 파싱 실패, 중복률, 폐기량을 소스별로 봐야 한다.

“로그가 없음”을 탐지하는 방법

보안 이벤트는 공격이 없으면 0일 수 있어 단순 정적 임계값이 어렵다. 다음 방법을 조합한다.

• 소스별 하트비트 이벤트를 주기적으로 생성한다.
• 평일·시간대별 기준선과 비교해 갑작스러운 감소를 찾는다.
• 인증 성공 수와 애플리케이션 세션 생성 수처럼 독립 지표를 대조한다.
• 테스트 계정으로 합성 이벤트를 만들고 탐지 규칙까지 종단 검증한다.
• 배포 시 예상 스키마 샘플을 계약 테스트한다.
• 원본 저장 건수와 정규화 저장 건수의 차이를 경보한다.

공격자는 탐지를 피하려고 감사 설정을 끄거나 로그 저장소 권한을 바꿀 수 있다. 따라서 감사 로깅 비활성화, 수집 정책 변경, 보존 기간 축소, 파서 배포도 고위험 관리 이벤트로 남겨야 한다.

민감정보를 덜 남기고도 유용하게 만드는 법

• 액세스 토큰, 세션 쿠키, 비밀번호, 비밀 키는 명시적으로 차단한다.
• 요청·응답 본문 전체 대신 필드 존재 여부, 길이, 분류, 해시를 사용한다.
• 사용자 ID와 고객 식별정보를 분리하고 조회 권한을 다르게 둔다.
• 검색·내보내기·대량 다운로드 행동도 감사한다.
• 디버그 로그는 짧은 보존과 제한된 환경에서만 활성화한다.
• 마스킹 규칙 실패 샘플을 안전한 테스트 데이터로 검증한다.

정규식 하나로 모든 비밀값을 찾을 수는 없다. 스키마 단계에서 허용 필드만 로그에 넣는 방식이 사후 마스킹보다 안전하다. LLM 기능처럼 입력 원문이 특히 민감한 경우는 운영 중인 LLM 관측성의 메타데이터 중심 설계를 적용한다.

보존 기간은 사용 목적별로 나눈다

하나의 숫자를 모든 로그에 적용하지 않는다.

계층	용도	운영 기준 예시
즉시 검색	경보 조사와 최근 장애	빠른 검색, 짧은 보존, 높은 비용 허용
근접 보관	수주·수개월 범위의 사고 조사	압축·인덱스 축소, 필요 시 재수화
장기 증거	계약·규제·포렌식 요구	변경 방지, 엄격한 접근, 삭제 절차
집계 지표	장기 추세와 성능	원문 최소화, 익명화·집계 우선

실제 기간은 데이터 종류, 고객 계약, 적용 법률, 사고 탐지 지연, 비용을 함께 검토해 정한다. 오래 보관한다는 이유만으로 유용하지 않은 민감 원문을 축적해서는 안 된다.

실패 모드와 탐지 신호

실패 모드	보이는 증상	바로 확인할 항목
이벤트 수만 늘림	저장비는 증가하지만 조사 시간이 줄지 않음	우선 조사 질문과 필수 필드가 정의됐는가
자유문장 중심 로그	같은 사건이 서비스마다 다른 표현	이벤트 이름·결과·이유 코드 표준이 있는가
시간 필드 불일치	순서가 뒤바뀌거나 미래 이벤트가 나타남	UTC 기준, 시계 동기화, 생성·수집 시각 분리
파서 오류 은폐	원본에는 있지만 검색 결과가 0	원본·정규화 건수와 실패 큐를 비교하는가
과도한 본문 저장	SIEM에서 비밀값·개인정보 발견	허용 필드 목록과 마스킹 테스트가 있는가
단일 저장소 의존	SIEM 장애와 함께 증거도 사라짐	원본 변경 방지 보관과 복구 경로가 있는가
요청 ID 단절	계층별 로그는 있으나 한 사건으로 묶이지 않음	경계에서 ID 생성·전달·재작성 규칙이 있는가

탐지 규칙을 운영 가능한 형태로 만든다

모든 규칙에는 다음 메타데이터를 붙인다.

• 탐지하려는 행위와 위협 시나리오
• 필요한 데이터 소스·필드·최소 지연
• 임계값과 기준선을 정한 근거
• 예상 정상 원인과 예외 조건
• 심각도, 담당 팀, 첫 조사 단계
• 마지막 적중·검토·테스트 시각
• 데이터 누락 시 동작과 폐기 기준

규칙이 울렸을 때 조사자가 첫 15분에 확인할 쿼리와 관련 대시보드를 바로 열 수 있어야 한다. EDR 경보의 튜닝과 소유권은 EDR 경보 피로를 줄이는 운영 규칙과 연결한다.

종단 검증 체크리스트

매 배포

• 새 이벤트와 스키마 버전이 계약 테스트를 통과했는가.
• 필수 필드 누락과 민감정보 유입 테스트가 있는가.
• 요청 ID가 모든 서비스와 비동기 작업까지 이어지는가.
• 파서가 실패할 때 원본 이벤트가 보존되는가.
• 탐지 규칙이 새 필드·값과 호환되는가.

주기적 운영

• 소스별 마지막 수신 시각과 예상 이벤트 수를 확인하는가.
• 합성 공격 이벤트가 경보·티켓·온콜까지 도달하는가.
• 보존·삭제 정책이 실제로 실행되고 증거가 남는가.
• 검색·내보내기 권한을 재검토하는가.
• 상위 비용 소스가 실제 탐지·조사에 쓰이는지 평가하는가.
• 사고 회고에서 빠진 필드를 스키마 백로그에 반영하는가.

거래 위험 신호를 설계할 때도 동일한 원칙이 적용된다. 점수만 남기지 말고 의사결정 이유와 데이터 신선도를 연결하는 방법은 핀테크 거래 위험 모니터링에서 다룬다.

참고 기준

• OWASP Logging Cheat Sheet
• Open Cybersecurity Schema Framework
• NIST Cybersecurity Framework 2.0
• MITRE ATT&CK Detection Strategies

최종 판단

보안 로그 파이프라인은 데이터 호수가 아니라 의사결정 인프라다. 사고 질문에서 필드를 역산하고, 원본과 정규화를 분리하며, 누락·지연·스키마 변화·민감정보 유입을 자체 경보로 관리해야 한다. 가장 먼저 할 일은 중요한 사고 시나리오 하나를 골라 사용자 행동 한 건이 모든 계층에서 같은 타임라인으로 이어지는지 종단 테스트하는 것이다.