41. 보안 로그를 공부하면서 정리해 본 ‘좋은 로그’의 조건

정보보안을 공부하다 보면
자연스럽게 “로그가 중요하다”는 말을 자주 듣게 된다.

침해사고 분석, 이상행위 탐지, 컴플라이언스 준수까지
거의 모든 이야기의 마지막에는
“결국 로그를 보고 판단한다”는 결론이 따라붙는 것 같다.

아직 실무에서 거대한 로그 시스템을 직접 운영해 본 것은 아니고,
강의·책·블로그 자료와 작은 실습 환경을 통해
조금씩 감을 잡아가는 단계에 가깝다.

그래도 공부를 이어가다 보니
“좋은 보안 로그는 이런 조건을 갖추면 좋겠다”라고
나름대로 정리해 본 기준이 있어서,
메모 차원에서 한 번 적어두려고 한다.

누가 / 언제 / 어디서 / 무엇을 했는지가 보이는지

로그를 예시로 보면서
가장 먼저 확인하게 된 건
“이 로그만 보고 상황을 상상할 수 있는가”였다.

적어도 이런 정보는 들어가 있어야
나중에 보안 쪽에서 의미 있게 쓸 수 있을 것 같았다.

• 누가: 계정, ID, 주체 정보
• 언제: 날짜와 시간(가능하면 타임존 포함)
• 어디서: 출발지 IP, 단말 정보, 위치 정보 등
• 무엇을: 수행한 동작, 요청한 기능, 결과(성공/실패)

이 네 가지가 어느 정도만 갖춰져 있어도
나중에 SIEM이나 관제 시스템에서
“어떤 계정이, 어느 시점에, 어떤 행동을 했는지”를
훨씬 쉽게 추적할 수 있을 것 같다는 생각이 들었다.

사람이 읽었을 때도 이해할 수 있는 메시지인지

처음 로그를 접했을 때 느낀 점 중 하나는,
메시지가 너무 코드에 가깝거나
약어 위주로만 쓰여 있으면
나중에 다시 봤을 때 해석하기가 상당히 어렵다는 것이었다.

그래서 공부하면서 기억해 두려고 하는 기준은
“기계도 읽지만, 사람도 이해할 수 있게 쓰자”에 가깝다.

예를 들면,

• action: LOGIN_FAILED
• reason: INVALID_PASSWORD

이 정도만 있어도
나중에 SIEM 대시보드나 분석 화면에서
사람이 의미를 파악하기가 훨씬 수월하다.

기계 처리를 위해 코드값을 쓰더라도,
가능하면 그 의미를 같이 남겨 두는 쪽이
보안 관점에서는 더 나을 것 같다는 생각이 든다.

형식이 어느 정도 일정한지

학습용으로 여러 서비스의 로그 예시를 보다 보면
필드 이름이나 순서, 형식이 제각각인 경우가 많다.

• 어떤 곳은 user, 어떤 곳은 uid, 어떤 곳은 account라고 쓰고
• 어떤 곳은 timestamp, 어떤 곳은 time, ts라고 쓰는 식이다

물론 시스템마다 다를 수밖에 없지만,
관제나 분석 입장에서 보면
최소한의 통일성이 있으면 훨씬 다루기 편할 것 같다.

그래서 개인적으로 정리해 본 원칙은

• 조직/서비스 내에서 자주 쓰는 필드 이름은
  가능한 한 일정하게 가져가고
• 날짜·시간, IP, 계정 같은 핵심 정보는
  형식을 미리 정해두는 것이 좋겠다

는 정도다.

나중에 ELK나 SIEM으로 연동할 때도
이런 통일성이 있으면
파싱이나 시각화 작업이 훨씬 줄어든다는 이야기가 많아서
공부할 때부터 의식적으로 보려고 하고 있다.

나중에 ‘증거로 쓸 수 있을지’를 한 번 떠올려 보기

보안 로그는 단순 모니터링뿐 아니라
나중에 문제가 생겼을 때
“무슨 일이 있었는지 설명하는 근거” 역할도 한다.

그래서 로그 예시들을 볼 때
“이 정보만 가지고 나중에 설명이 가능할까?”를
한 번씩 떠올려 보려고 한다.

예를 들면,

• 중요한 작업(비밀번호 변경, 권한 변경, 대량 다운로드 등)은
  누가, 어떤 경로로, 어떤 대상에 대해 수행했는지 충분히 남아 있는지
• 실패한 시도(권한 없는 접근, 로그인 실패 등)도
  어느 정도까지 기록이 필요한지
• 관리자나 특수 권한 계정의 행위는
  일반 사용자보다 더 자세히 남길 필요가 있는지

이런 점을 생각해 보면,
그냥 “로그가 있다/없다”가 아니라
“설명을 할 수 있을 정도의 로그인가”라는 기준으로
보게 되는 것 같다.

마무리

아직 실무에서 거대한 로그 환경을 운영해 본 것은 아니지만,
공부를 하면서 예시 로그들을 계속 보다 보니

• 누가, 언제, 어디서, 무엇을 했는지 보이는지
• 사람이 읽어도 이해 가능한 메시지인지
• 형식이 어느 정도 일정한지
• 나중에 증거로 쓸 수 있을 정도로 남아 있는지

이 네 가지가
“좋은 보안 로그”를 판단하는 기본 기준이 되지 않을까
라는 생각을 하게 되었다.

앞으로 실제 업무에서 로그를 설계하거나 볼 기회가 생긴다면,
오늘 정리한 기준을 한 번 더 꺼내서
점검해보고 싶다.