S3 서버 액세스 로깅과 CloudTrail을 사용한 S3 로깅의 차이
개요
OpsNow Security에서 감사 로그 목적으로 S3에 대한 로깅 설정을 확인하는 정책을 개발하다 보니 S3의 로깅 옵션이 2가지가 있고 이에 대한 차이점을 확인하기 위해 포스팅을 작성하였습니다.
결론적으로 2가지 로깅 방법 중 CloudTrail을 사용하여 S3 로그를 남기는 것을 권고하며, 왜 그런지 알아보도록 하겠습니다.
목차
- S3 서버 액세스 로그란 무엇인가?
- CloudTrail을 사용하여 S3 로깅이란 무엇인가?
- 2개의 차이점은 무엇인가?
- 둘 중 하나만 켜야 하는가? 둘 다 켜야 하는가?
- 결론
- 참고 페이지
1. S3 서버 액세스 로그란 무엇인가?
1.1 정의
누가 언제 어떤 버킷에 작업(액세스)을 했는지를 로그로 남긴 것을 S3 서버 액세스 로그라고 합니다. Sample로 서버 액세스 로깅이 활성화된 버킷에서 해당 로그를 다운받아 봅니다.
1.2 로그포맷
다운받은 S3 서버 액세스 로그는 아래와 같은 포맷을 지니고 있습니다. 간단하면서 별 내용이 없습니다. 각 필드의 구분은 공백(띄어쓰기)로 구분합니다.
다운 받은 S3 서버 액세스 로그를 포맷으로 구분해서 보면 아래 표와 같으며, 여기서 유용하게 사용할 수 있는 필드는 7개 정도 되는 것 같습니다.
작업이 몇 가지 없는데 버킷 목록을 조회하거나, 버킷이 삭제되거나 생성되는 등의 작업은 서버 액세스 로그에 남지 않습니다.
대신 S3 수명주기 작업의 로그는 남는데 전체 수명주기에 대해서 로그가 남는다는 보장이 없고 순서대로 남지 않습니다.
1.3 설정 방법 및 확인
S3 서버 액세스 로그를 설정하려면 새로 버킷을 만들 때 설정은 못하고 만들어진 버킷의 속성 편집을 통해 설정 가능하며, 버킷 정책을 통해 로깅 권한을 부여해야 합니다.
2. CloudTrail을 사용하여 S3 로깅이란 무엇인가?
2.1 정의
AWS의 API 이벤트를 JSON 형태로 저장하는 CloudTrail 서비스를 이용하여 S3 버킷과 객체에 대한 로그를 저장하는 방법입니다. 아까 서버 액세스 로그의 포맷보다 JSON 형태의 로그가 훨씬 보기 좋긴 합니다.
설정은 CloudTrail의 Trail 설정에서 Data events 항목에서 Data event source를 S3로 선택하면 됩니다.
2.2 로그 포맷
S3 서버 액세스 로그랑 비교하기 위해서 동일한 PutObject 로그 샘플을 하나 가져와봤습니다.
트레일 로그 포맷 형태(JSON)이고 구분해서 보면 21개로 구분해서 볼 수 있습니다. 필드에 대한 자세한 설명은 아래 참고사이트의 CloudTrail Record 형태 링크를 참고하시기 바랍니다.
2.3 설정 방법 및 확인
CloudTrail에서 설정할 수 있습니다. Data Event를 CloudTrail로 수집할 때 Basic 과 Advanced 2가지 Selector가 있습니다. Advanced는 따로 더 수집하는 것이 아니라 수집할 로그의 옵션을 지정할 수 있습니다.
아래는 CloudTrail에서 개별 해당 AWS Account의 전체 S3를 대상으로 로깅 설정을 하는 방법입니다.
3. 2개의 차이점은 무엇인가?
동일한 항목 배경 초록색, 다른 항목 빨간색으로 표기해 봤습니다.
서버 액세스 로그에서는 소유자, 요청자, 호스트 ID와 같은 ID 정보가 더 있긴 합니다만 CloudTrail의 Source. 대신 CloudTrail 로그에서는 Account, Region, VPC 정보와 더불어 eventSource, eventType, resource 정보가 추가로 더 있습니다.
위 로그로는 감사 로그로 알맞은 로그가 무엇인지 감이 잘 안 잡혀서 AWS Console에서 S3 버킷에 파일을 업로드해 보았습니다. CloudTrail을 이용한 로그에서 userIdentity 필드에서 User를 판별할 수 있는 걸 확인 가능합니다.
파일 업로드하면서 서버 액세스 로그를 활성화해놨는데, 서버 액세스 로그는 로그 전송에 대한 보장이 없어서 그런지 제가 파일을 업로드한(PutObject) 이벤트를 확인할 수 없었습니다.
4. 둘 중 하나만 켜야 하는가? 둘 다 켜야 하는가?
2가지 기능을 모두 활성화하여 테스트해 본 결과 둘 중 하나만 활성화하는 것이 적합하다고 판단되며, 둘 중 하나는 CloudTrail을 이용한 S3 로그 저장 기능입니다.
S3 서버 액세스 로그는 전송이 보장되지 않아 로그 유실이 있고 또한 로그가 순서대로 저장되지 않아서 감사 용도의 로그로는 적합하지 않습니다.
5. 결론
S3 서버 액세스 로그의 문제점으로 로그 전송에 대해 보장하지 않고, 로그가 시간순으로 저장되지 않아서 안정적으로 분석하는데 매우 큰 어려움이 있습니다.
그래서 Production 환경에서 S3 서버 액세스 로그보다 CloudTrail을 사용하여 S3 로깅(Object-Level)을 사용하는 것을 권고하며, 또한 AWS Docs에서도 S3 서버 액세스 로그 대신 CloudTrail을 이용하여 S3 로그를 남기는 것을 권장하고 있습니다.
6. 참고 페이지
서버 액세스 로그란?
https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/ServerLogs.html
Amazon S3 액세스 로그를 사용하여 요청 식별
https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/using-s3-access-logs-to-identify-requests.html
Amazon S3 서버 액세스 로그 형식
https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/LogFormat.html
Object-Level(CloudTrail 수준)의 S3 로그란?
https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/cloudtrail-logging.html
CloudTrail을 사용하여 Amazon S3 요청 식별
https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/cloudtrail-request-identification.html
CloudTrail Record 형태
https://docs.aws.amazon.com/ko_kr/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html
S3 버킷 및 객체에 대한 CloudTrail 이벤트 로깅 사용 설정
https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/enable-cloudtrail-logging-for-s3.html