[AWS] S3 Server Access Logging(S3 서버 액세스 로깅), 한 눈에 이해하자

S3 Server Access Logging(S3 서버 액세스 로그)

 

• S3 Server Access Logging은 S3 버킷에 대한 모든 HTTP 요청(성공/실패 포함)을 로그 파일 형태로 기록하는 기능이다.
• 이 로그는 다른 S3 버킷에 저장되며, 요청을 보낸 사용자, 시간, 요청 유형, 응답 코드, 요청자 IP 주소 등의 정보를 포함한다.
• 403 Forbidden, 401 Unauthorized 같은 인증 실패 요청도 로그에 포함됨

 

S3 서버 액세스 로그를 활용한 주요 사례

 

• 보안 감사 및 인증 실패 추적 : 누가/언제/어디서 접근을 시도했는지 로그 확인
• 비정상 트래픽 분석 (DoS, 공격 시도 등)
• S3 사용 통계 및 비용 분석
• 데이터 접근 추세 파악

 

S3 서버 액세스 로그 설정 시 참고사항

• 로그 버킷은 암호화 및 Object Lock 설정 권장
• CloudTrail과 병행 사용 시 보안 분석의 신뢰성 향상
• Athena + Glue Catalog로 정형화된 분석 가능
• 로그 버킷에는 전용 S3 Lifecycle 정책 설정 권장 (예: 90일 후 Glacier 이동)
• 로그 활성화 대상과 로그 수신 버킷을 분리해야 함 (로그 저장도 S3 PUT 요청인데 저장한 로그가 또 저장되고 다시 저장되는...)

로그 활성화 대상과 로그 수신 대상을 분리

 

---

 

예제 문제

한 회사는 민감한 정보를 포함한 프라이빗 Amazon S3 버킷을 운영 중입니다. SysOps 관리자는 버킷 객체에 대한 접근 시도 중 인증 실패가 발생한 IP 주소의 로그를 보관해야 합니다. 로그는 90일 동안 덮어쓰기나 삭제가 불가능해야 합니다.
이 요구 사항을 충족할 수 있는 솔루션은 무엇입니까?

• A. AWS CloudTrail trail을 생성합니다. 로그 파일이 Amazon CloudWatch Logs에 저장되도록 구성합니다. 로그 그룹의 보존 기간을 90일로 설정합니다.
• B. AWS CloudTrail trail을 생성합니다. 로그 파일이 다른 S3 버킷에 저장되도록 구성합니다. CloudTrail 로그 파일 무결성 검증을 90일 동안 활성화합니다.
• C. S3 버킷에 대한 access logging을 활성화합니다. 액세스 로그가 Amazon CloudWatch Logs에 저장되도록 구성합니다. 로그 그룹의 보존 기간을 90일로 설정합니다.
• D. S3 버킷에 대한 access logging을 활성화합니다. 액세스 로그가 두 번째 S3 버킷에 저장되도록 구성합니다. 두 번째 S3 버킷에서 S3 Object Lock을 활성화하고 기본 보존 기간을 90일로 설정합니다.

답 : D

이유 : 인증 실패 로그는 기본적으로 CloudWatch에 로깅되지 않는다. 따라서 Access Logging을 별도로 활성화 해줘야하고, 로그 수신대상은 별개의 S3 버킷으로 구성한다. 이때, 90일 동안 로그 파일을 보호하기 위해 S3 Object Lock를 활성화해야 한다.

C가 답이 아닌 이유는 Access Log가 CloudWatch Logs에 저장되려면 별도의 데이터 전처리(Lambda 활용 등) 과정이 필요한데 지문에는 마치 연동이 되는 것처럼 작성되어있다.

더불어 로그 그룹의 보존 기간의 경우, 자동 삭제 시점을 지정하는 기능이며 로그 파일의 무결성이나 삭제 방지 기능을 지원하지 않으므로 로그 보호도 전혀되지 않는다.

Cloud Watch Logs : JSON 기반의 실시간 로그 스트림

S3 Access Log : 비동기적이고, 분석용으로 설계된 로그(정형화된 텍스트 파일)