[AWS-Security] 8.1. 감사 로그 및 사고 대응

1. 개요

방어막을 아무리 잘 구축해도 보안 침해(사고)는 언제든 발생할 수 있다. 2016년 우버(Uber)에서 5,000만 명의 고객 데이터가 유출되어 해커가 몸값을 요구했던 사건처럼, 최악의 상황이 발생했을 때 가장 먼저 열어봐야 하는 것이 바로 감사 로그(Audit Log)다.

감사 로그 및 추적 시스템은 사고 대응(Incident Response)을 위해 절대적으로 필요하며, 완벽한 사고 대응을 위해서는 아래 3단계의 질문에 답할 수 있어야 한다.

2. 1단계: 공격이 실제로 발생했는가? (이상 징후 탐지)

양호한 감사 로깅 시스템이 있다면, 평소와 다른 ‘이상 징후(지표)’를 통해 공격을 조기에 파악할 수 있다. 대표적인 공격 징후로는 아래 4가지가 있다.

1. 읽기 접근 수의 급증 : 누군가 대량의 레코드를 훔쳐 가고 있다면 데이터베이스나 스토리지의 읽기 호출이 비정상적으로 치솟는다.
2. 지나치게 큰 응답 페이로드 : 평소보다 반환되는 데이터의 크기가 과도하게 크다면, 이는 SQL 인젝션 공격으로 DB 전체가 털리고 있다는 지표일 수 있다.
3. 특이한 지리적 위치에서의 요청 : 주요 고객이 한국에 있는데 갑자기 동유럽이나 남미 등에서 트래픽이 급증한다면 악의적인 목적일 가능성이 크다.
4. 비정상적인 시간대의 대규모 요청 : 일반적인 업무 시간(오전 9시 ~ 오후 5시)이 아닌 새벽 시간대에 대규모 데이터 접근이 일어난다면 의심해 볼 만한 상황이다.

3. 2단계: 악용된 취약점은 무엇인가? (정찰 및 원인 파악)

공격이 확인되었다면, 로그에 남은 식별자(사용자 ID, IP 주소 등)를 단서로 스택 전체의 로그를 교차 검증(정찰)하여 공격 경로를 파악해야 한다.

• 추적 시나리오
  1. DB 접근 로그를 보니 권한을 가진 ‘Bob’이라는 사용자가 수많은 데이터를 빼간 기록이 있다.
  2. 애플리케이션 (웹 서버) 로그로 넘어가 ‘Bob’의 기록을 다시 검색해 본다.
  3. 특정 IP 주소들에서 ‘Bob’의 계정으로 수많은 ‘로그인 실패’ 기록(무차별 대입 공격)이 발생한 것을 확인한다.
  4. 결론 : 해커가 로그인 공격으로 Bob의 계정을 탈취했음을 알아내고, 즉시 해당 IP 차단 및 처리율 제한(Rate Limiting)을 적용해 추가 공격을 막는다.

4. 3단계: 공격의 피해 범위는 어디까지인가? (영향도 평가)

공격을 막아낸 후에는 다음과 같은 질문에 답하여 법적, 도의적 책임을 다해야 한다.

• 어떤 데이터 접근했는가? (개인정보, 금융 정보 등 데이터의 민감도 파악)
• 얼마나 많은 사용자가 영향을 받았는가? (전체 고객의 1%인지, 100%인지 정확히 파악하여 공지)
• 손상된 계정은 누구인가? (악의적인 IP에서 성공적으로 로그인한 사용자를 식별하여 즉각적인 비밀번호 변경 및 보호 조치 수행)

실시간 탐지를 위한 로깅의 가치
로그는 사고가 끝난 뒤 조사에만 사용하는 것이 아니다. 로그가 실시간으로 잘 쌓이고 있다면, 공격이 ‘진행 중’일 때 이를 탐지하여 조기에 차단할 수 있다. (ex. 무차별 로그인 실패 로그가 일정 수치를 넘으면 알람 발생)