この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
안녕하세요, 임채정입니다.
오늘 블로그에서는 S3 버킷의 액세스 로그를 저장하는 방법과 로그 보는 법에 대해 정리해봤습니다.
Amazon S3 버킷 액세스 로그란?
- 버킷에 이루어진 요청에 따라 상세 레코드를 제공하는 기능
- 액세스 로그 버킷을 생성하여 로그를 객체로 저장한다
- 액세스 로그 정보의 유용성은 다음과 같다
- 보안 및 액세스 감사
- 고객 기반을 이해
- Amazon S3 청구 비용 파악
- 사용자의 버킷과 액세스 로그 버킷이 동일한 경우 로그가 계속해서 들어오게 되는 로깅 루프 (logging loop) 가 일어날 수 있으니 주의해야 한다.
S3 버킷 생성
먼저 S3 버킷을 생성하겠습니다.
S3 버킷은 위의 그림대로 액세스 로그 버킷을 따로 생성해야 하기 때문에 총 2개의 버킷을 생성하겠습니다.
[ 유저 버킷 ]
버킷 이름 : user-bucket-202108
이 버킷의 퍼블릭 액세스 차단 설정 : 모든 퍼블릭 액세스 차단 해제
버킷 버전 관리 : 활성화
생성 후 버킷 정책에 다음과 같이 입력한다. 이 때 버킷 ARN을 자신의 ARN/*으로 수정하여 입력합니다.
{
"Version": "2012-10-17",
"Id": "Policy1629391194783",
"Statement": [
{
"Sid": "Stmt1629391192118",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::logging-bucket-202108/*"
}
]
}
액세스를 시험해보기 위해 임의의 파일을 몇 개 올려둡니다.
[ 액세스 버킷 ]
버킷 이름 : logging-bucket-202108
액세스 로그 버킷 설정
두 개의 버킷이 생성이 되었기 때문에 user-bucket-202108버킷에서 액세스가 발생했을 경우 logging-bucket-202108버킷에 로그가 저장되도록 설정하겠습니다.
먼저 user-bucket-202108버킷의 [속성] 탭에서 [서버 액세스 로깅] 설정을 편집합니다.
활성화를 선택하면 로그를 저장할 대상 버킷을 선택할 수 있는 칸이 나오는데 위에서 생성한 logging-bucket-202108버킷을 선택합니다.
버킷경로 뒤에 /s3-logs/를 추가하고 변경사항을 저장하면 액세스 로깅이 활성화로 변경된 것을 확인할 수 있습니다.
또한, 서버 액세스 로깅을 활성화하면 S3 콘솔이 S3 로그 전달 그룹에 대한 액세스를 포함하도록 버킷 ACL(액세스 제어 목록)을 자동으로 업데이트를 됩니다. 제대로 업데이트가 됐는지 확인해보겠습니다.
user-bucket-202108과 logging-bucket-202108버킷의 [권한]탭에서 [ACL(액세스 제어 목록)]설정부분을 비교해보겠습니다.
user-bucket-202108
S3 로그 전달 그룹에 아무런 권한이 없습니다.
logging-bucket-202108
반대로 액세스 로그 버킷에는 S3 로그 전달 그룹에 대한 권한이 자동으로 업데이트가 된 것을 확인할 수 있습니다.
로그 확인하기
그럼 이번에는 실제로 로그를 확인해봅시다.
먼저 user-bucket-202108의 객체에 액세스를 합니다.
그 후에 logging-bucket-202108버킷을 확인해보면 s3-logs파일이 자동으로 생성된 것을 확인할 수 있습니다.
그리고 s3-logs파일에 들어가면 액세스 로그가 저장되어 있습니다.
로그 중에 하나를 확인해보겠습니다. 다운로드합니다.
다운로그 한 파일에는 로그가 한 줄로 나와있습니다.
306f318a2feb3ea2256ba7d4f0ebd322d3b9ec7d93f0d3e5311a19bee92629ce user-bucket-202108 [19/Aug/2021:16:54:07 +0000] 122.38.73.237 arn:aws:sts::763723081076:assumed-role/cm-lim.chaejeong/cm-lim.chaejeong AW98WX6NX1W7TNYK REST.HEAD.BUCKET - "HEAD /user-bucket-202108 HTTP/1.1" 200 - - - 7 6 "-" "S3Console/0.4, aws-internal/3 aws-sdk-java/1.11.1002 Linux/5.4.129-72.229.amzn2int.x86_64 OpenJDK_64-Bit_Server_VM/25.282-b08 java/1.8.0_282 vendor/Oracle_Corporation cfg/retry-mode/legacy" - BOY/uf8pOEOnp+HGW+UejMdD42FTXDPRMtGVECDorULxq4RYnp57dXbiLuF+8U/gGXQRpSn1Cjw= SigV4 ECDHE-RSA-AES128-GCM-SHA256 AuthHeader s3-ap-northeast-2.amazonaws.com TLSv1.2 -이 로그가 어떤 내용인지 나눠서 살펴보겠습니다.
- 원본 버킷의 정식 사용자 ID : 306f318a2feb3ea2256ba7d4f0ebd322d3b9ec7d93f0d3e5311a19bee92629ce
- 요청이 처리된 버킷의 이름 : user-bucket-202108
- 요청이 수신된 시간 : [19/Aug/2021:16:54:07 +0000]
- 요청자의 명백한 인터넷 주소 : 122.38.73.237
- 요청자의 정식 사용자 ID : arn:aws:sts::************:assumed-role/cm-lim.chaejeong/cm-lim.chaejeong
- 요청의 고유 식별을 위한 문자열 : AW98WX6NX1W7TNYK
- 작업 내용 : REST.HEAD.BUCKET
- 요청의 키(파라미터가 없을 경우 -로 표시) : -
- HTTP 요청 메시지의 Request-URI : "HEAD /user-bucket-202108 HTTP/1.1"
- 응답의 숫자 HTTP 상태 코드 : 200
- 오류 코드 : -
- HTTP 프로토콜 오버헤드를 제외한 보낸 응답 바이트 수 : -
- 해당 객체의 총 크기 : -
- 요청이 수신된 시간부터 응답의 마지막 바이트가 전송된 시간 : 7
- 요청을 처리하는 데 소비한 시간 : 6
- HTTP Referrer 헤더의 값 : "-"
- HTTP User-Agent 헤더의 값 : "S3Console/0.4, aws-internal/3 aws-sdk-java/1.11.1002 Linux/5.4.129-72.229.amzn2int.x86_64 OpenJDK_64-Bit_Server_VM/25.282-b08 java/1.8.0_282 vendor/Oracle_Corporation cfg/retry-mode/legacy"
- 요청의 버전 ID : -
- x-amz-id-2 또는 Amazon S3 확장 요청 ID : BOY/uf8pOEOnp+HGW+UejMdD42FTXDPRMtGVECDorULxq4RYnp57dXbiLuF+8U/gGXQRpSn1Cjw=
- 요청을 인증하는 데 사용된 서명 버전 : SigV4
- HTTPS 요청에 대해 협상된 Secure Sockets Layer (SSL) 암호 : ECDHE-RSA-AES128-GCM-SHA256
- 사용된 요청 인증 유형 : AuthHeader
- Amazon S3에 연결하는 데 사용된 엔드포인트 : s3-ap-northeast-2.amazonaws.com
- 클라이언트가 협상한 TLS(전송 계층 보안) 버전 : TLSv1.2 -
로그를 나눠서 확인해보니 한 줄에 수많은 정보가 포함되어 있었습니다. 이렇게 로그를 분석할 수 있는 것만으로 많은 정보를 확인할 수 있기 때문에 유용하게 사용할 수 있겠네요.
마무리
오늘은 S3 버킷의 액세스 로그를 저장하는 것과 로그를 분석해보는 것까지 해봤습니다.
사실 분석을 해도 다 완벽하게 내용을 이해할 수 있는 건 아니였지만 어떤 정보가 로그에 들어있는지 알 수 있었기 때문에 궁금한 정보가 생기면 바로 확인해볼 수 있을 것같습니다!
로그 내용에 대한 좀 더 자세한 내용은 아래 문서를 확인해주세요 https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/LogFormat.html
1
