Security Log Audit Abuse Detection
3줄 요약
- 보안 로그는 “장애 원인 확인”만이 아니라 침해 탐지, 책임 추적, 피해 범위 산정, 사고 대응을 위한 증거다.
- 좋은 이벤트는 자유 문장이 아니라
event, actor, resource, action, result, reason, traceId, risk처럼 검색 가능한 필드로 남는다.
- 많이 남기는 것보다 필요한 것을 안전하게 남기는 것이 중요하다. token, password, 전체 카드번호, 과도한 개인정보는 남기지 않고 보존 기간과 접근 권한을 정한다.
핵심 정리
- Audit log는 나중에 사실관계와 책임을 복원하는 기록이고, security event는 탐지와 대응을 위한 신호다. 둘은 필드와 보존 기간이 다를 수 있다.
- 로그인, MFA, 권한 변경, 계정 연결, 결제, 비밀번호 재설정, token 재사용은 상관관계 분석이 필요한 고위험 이벤트다.
- Abuse detection은 “공격 payload”만 찾지 않는다. 정상 기능을 낮은 빈도, 여러 계정, 여러 IP로 반복하는 패턴도 본다.
- 마스킹은 화면뿐 아니라 log, metric label, trace attribute, alert payload, SIEM field에도 적용해야 한다.
- 사고 초기 대응은 완벽한 원인 규명보다 증거 보존, 추가 피해 차단, 사용자 보호, 타임라인 고정이 우선이다.
- 로그 시스템 자체도 공격 대상이다. 쓰기 권한, 조회 권한, 삭제 권한, 보존 정책을 분리해야 한다.
하위 문서 연결
-
- Audit Log와 Security Event: 감사 로그와 보안 이벤트의 목적, 필드, 변조 방지, 접근 제어를 정리한다.
-
- 로그인 권한 변경 결제 이벤트 추적: 계정 탈취에서 금전 피해까지 이어지는 고위험 이벤트 체인을 추적한다.
-
- 이상 요청 Abuse Detection: 단일 요청이 아니라 반복, 비율, 순서, 분산 패턴으로 abuse를 탐지한다.
-
- 개인정보 마스킹과 로그 보존: 민감값을 남기지 않으면서 사고 조사에 필요한 pseudonymous identifier를 설계한다.
-
- 보안 사고 초기 대응: 탐지 직후 첫 대응에서 증거, 차단, 커뮤니케이션, 복구 기준을 잡는다.
헷갈리는 지점
- 모든 요청을 남기면 안전하다고 생각하기 쉽다.
- 과도한 로그는 비용과 개인정보 위험을 만들고, 중요한 이벤트를 묻어 버린다.
- 이벤트 목적별로 필드와 보존 기간을 정해야 한다.
- 민감값을 마스킹하면 조사가 불가능하다고 생각하기 쉽다.
- 원문 대신 hash, masked value, stable internal id, trace id를 남기면 상관관계 분석은 가능하다.
- 단, hash key와 salt/pepper 관리도 필요하다.
- 경고가 많을수록 탐지가 좋다고 생각하기 쉽다.
- 오탐이 많으면 운영자가 알림을 무시한다.
- shadow mode, severity, confidence, 대응 action을 함께 설계한다.
- 사고가 나면 우선 서버를 재시작하면 된다고 생각하기 쉽다.
- 재시작은 메모리 증거와 임시 파일, 연결 상태를 잃게 만들 수 있다.
- 격리와 증거 보존 순서를 runbook에 둔다.
확인 질문
- 보안 이벤트의 최소 필드는 무엇인가?
- event, actor, resource, action, result, reason, time, source, traceId, risk 또는 severity다.
- 로그에 절대 남기지 말아야 할 값은 무엇인가?
- password, token 원문, session id 원문, secret, private key, 전체 카드번호, 과도한 개인정보다.
- 사고 초기 대응에서 먼저 해야 할 일은 무엇인가?
- 추가 피해를 제한하면서 증거를 보존하고, 타임라인과 영향 범위를 빠르게 고정하는 것이다.