AWS VPC 플로우 로그를 S3로 보내도록 켜고 정리하기

VPC 플로우 로그는 VPC 안 네트워크 인터페이스를 오가는 트래픽의 정보를 기록합니다. 보안 그룹이나 네트워크 ACL이 막은 트래픽도 기록에 남는 것으로 알려져 있고(일부 트래픽은 기록되지 않는다고 문서에 안내되어 있습니다), 접속이 안 될 때 원인을 찾거나 의심스러운 접근을 살필 때 씁니다. 이 글에서는 기록을 S3 버킷으로 보내는 설정을 만들고 지우는 과정을 따라갑니다. 기록 파일이 실제로 쌓인 뒤 내용을 읽는 것은 다루지 않았습니다. 앞선 네트워크 ACL과 보안 그룹 글의 규칙 화면과 함께 보면 어떤 트래픽이 기록 대상인지 이해하기 쉽습니다.

준비물

화면의 계정 ID, 사용자 이름, 이 계정의 VPC 이름은 가렸습니다. 플로우 로그를 켜면 로그 저장과 전송에 요금이 붙을 수 있으니 실습 뒤 반드시 지웁니다. 요금 수준은 이 실습에서 확인하지 않았습니다.

1. 로그를 받을 버킷 만들기

S3 콘솔 위쪽 리전이 서울인지 확인하고 버킷 만들기로 cr-demo-flowlogs-1018을 만듭니다. 나머지는 기본값입니다. 이 실습에서는 버킷 만들기 입력 화면을 따로 캡처하지 않았습니다.

2. VPC에서 플로우 로그 생성 시작하기

VPC 콘솔의 VPC 목록에서 VPC를 선택하고 작업 메뉴를 엽니다.

플로우 로그 생성을 누릅니다. 목록 아래 세부 정보의 플로우 로그 탭에서도 같은 작업을 시작할 수 있습니다.

화면은 이렇게 구성됩니다.

• 선택한 리소스: 앞에서 고른 VPC가 표시됩니다.
• 필터: 적용(수락된 트래픽), 거부(거부된 트래픽), 전체 중 고릅니다. 기본값은 전체였습니다.
• 최대 집계 간격: 10분과 1분 중 고릅니다. 기본값은 10분이었습니다.
• 대상: CloudWatch Logs로 전송, Amazon S3 버킷으로 전송, 같은 계정에서 Amazon Data Firehose로 전송, 다른 계정에서 Amazon Data Firehose로 전송 중 고릅니다. 기본값은 CloudWatch Logs였습니다.

이 실습에서는 IAM 역할을 따로 만들지 않아도 되도록 S3를 골랐습니다(생성 결과의 IAM 역할 칸이 비어 있었고, 문서 기준으로 S3 대상은 버킷 정책으로 전달 권한을 줍니다). 이름 칸에는 cr-demo-vpc-flow-log를 입력했습니다. 거부된 트래픽만 보려면 필터를 거부로 바꿉니다. 이 실습에서는 전체를 그대로 썼습니다.

3. S3 대상과 기록 필드 보기

Amazon S3 버킷으로 전송을 고르면 S3 버킷 ARN 칸이 나타납니다.

ARN 아래 파란 상자에 자동으로 리소스 기반 정책이 생성되고 대상 버킷에 연결됩니다.라는 안내가 있습니다. 이 정책이 어떻게 생기는지는 5번에서 읽습니다.

로그 레코드 형식의 기본값은 AWS 기본 형식이고, 형식 미리 보기에는 기록 한 줄에 담기는 필드가 나열됩니다. 이 실습 화면에서 읽은 필드는 다음 14개입니다.

version, account-id, interface-id, srcaddr, dstaddr, srcport, dstport, protocol, packets, bytes, start, end, action, log-status

출발지와 목적지 주소와 포트, 프로토콜, 패킷과 바이트 수, 허용 여부를 뜻하는 action이 들어 있습니다. 각 필드의 의미는 AWS 문서에서 확인하시기 바랍니다(이 실습에서 대조하지 않았습니다). 더 아래로 내리면 마지막 설정이 있습니다.

로그 파일 형식은 텍스트(기본값)와 Parquet, 시간별 로그 파티션은 24시간마다(기본값)와 1시간(60분)마다입니다. Hive 호환 S3 접두사는 체크하지 않았습니다. 태그 칸에는 Name 키와 방금 입력한 플로우 로그 이름이 들어 있었습니다. 플로우 로그 생성을 누릅니다.

4. 생성 결과 읽기

세부 정보에서 읽은 값은 다음과 같습니다.

S3 대상에서는 IAM 역할 칸이 -로 표시되었습니다. CloudWatch Logs를 대상으로 쓸 때는 로그 전송용 IAM 역할이 필요한 것으로 알려져 있으며, 이 실습에서는 시험하지 않았습니다.

5. 버킷에 자동으로 붙은 정책 읽기

대상 버킷의 권한 탭에서 버킷 정책을 봅니다.

이미지에서 읽을 수 있는 것은 다음과 같습니다.

• Id는 AWSLogDeliveryWrite20150319, Sid는 AWSLogDeliveryWrite1
• 허용 대상(Principal)은 서비스 delivery.logs.amazonaws.com
• 허용 작업은 s3:PutObject
• 조건에는 s3:x-amz-acl이 bucket-owner-full-control일 것이 보였고, 그 아래 계정 조건 줄과 ArnLike 조건 안의 줄은 이미지에서 통째로 가렸습니다

Resource 줄도 이미지에서 가렸습니다. AWS 문서의 예시 정책에서는 Resource가 버킷/AWSLogs/<계정 ID>/* 형태이고 조건에 aws:SourceAccount와 aws:SourceArn이 들어 있으니, 로그 전달 서비스가 이 버킷의 AWSLogs/ 아래에만 쓰도록 허용한 정책으로 읽었습니다(문서 기준, 가린 줄은 이 글에서 확인할 수 없습니다). 정책 상자를 아래로 스크롤해 둘째 문장이 있는지(문서상 s3:GetBucketAcl)는 확인하지 않았습니다.

6. 버킷에 생긴 것 보기

플로우 로그를 만든 뒤 버킷의 객체 탭을 열었더니 AWSLogs/ 폴더가 생겨 있었습니다.

폴더 안에는 계정 ID 이름의 폴더가 있었습니다. 그 아래 구조와 기록 파일의 내용은 이 실습에서 열어 보지 않았습니다. 기록 파일이 S3에 나타나기까지 몇 분 걸리는 것으로 알려져 있으며(문서 기준), 이 실습에서는 그 시점을 확인하지 않았습니다.

7. 정리: 플로우 로그와 버킷 삭제

먼저 플로우 로그를 지웁니다. VPC의 플로우 로그 탭에서 방금 만든 항목을 선택하고 작업 메뉴의 삭제 항목을 누릅니다. 이 콘솔은 같은 기능을 플로우 로그와 흐름 로그 두 가지로 표기합니다.

대화상자에는 삭제할 플로우 로그 ID가 표시됩니다. 안내 문구는 확인을 위해 delete를 입력하라고 적혀 있었지만, 이 실습에서는 delete를 입력해도 삭제 단추가 활성화되지 않았습니다. 입력칸에 한글 삭제를 입력하자 단추가 활성화되었습니다(9번 화면). delete를 입력했을 때 단추가 켜지지 않은 상태는 캡처하지 않은 관찰입니다. 한국어 콘솔 기준의 관찰이며 콘솔 버전에 따라 다를 수 있습니다.

삭제 뒤 플로우 로그 탭이 흐름 로그 없음으로 바뀌었습니다. 이어서 버킷을 삭제하려 했더니 막혔습니다.

플로우 로그가 만든 AWSLogs/ 폴더 때문에 버킷이 비어 있지 않았습니다. 버킷 비우기를 열고 확인 칸에 안내된 영구 삭제를 입력해 비웠습니다(비우기 입력 화면은 캡처하지 않았습니다). 이 버킷은 이 실습에서 만든 것이고 안의 내용도 플로우 로그가 만든 것뿐이라서 비워도 되는 것으로 판단했습니다. 실제 운영 버킷이라면 지우기 전에 내용을 확인합니다.

삭제된 객체는 1개였고 실패는 0개였습니다. 이 객체가 무엇이었는지는 확인하지 않았습니다. 비운 뒤 버킷 삭제 화면에서 버킷 이름을 입력해 확인하고 버킷을 삭제했습니다. 플로우 로그를 지워도 이미 전달된 로그 파일과 자동으로 붙은 버킷 정책은 지워지지 않는 것으로 알려져 있어, 버킷을 남겨 둘 때는 따로 정리해야 합니다(문서 기준).

목록에는 이미 있던 버킷 1개만 남았고 이 버킷은 이 실습에서 다루지 않았습니다.

자주 막히는 곳

• 플로우 로그를 지우기 전에 버킷부터 지우려는 경우: 버킷이 비어 있지 않으면 삭제가 막힙니다. 플로우 로그를 먼저 지워 새 기록이 더 쌓이지 않게 한 뒤 버킷을 비웁니다.
• 삭제 확인 칸에 안내 문구대로 영어를 입력했는데 단추가 안 켜지는 경우: 이 실습에서는 한글 삭제를 입력해야 켜졌습니다.
• 버킷 이름이 이미 있다는 오류: 버킷 이름은 고유해야 하므로 끝의 숫자를 바꿉니다.
• CloudWatch Logs를 대상으로 고르는 경우: 이 글에서 시험하지 않았습니다. 화면에는 로그 그룹을 새 이름으로 만들 수 있다는 안내가 있었고, 전송용 IAM 역할이 필요한 것으로 알려져 있습니다.

이어서 해 볼 것

• 필터를 거부로 바꿔 거부된 트래픽만 기록하고, 보안 그룹이나 네트워크 ACL 규칙을 일부러 막았을 때 action 필드가 REJECT로 남는지 확인하기. 규칙을 바꿀 때는 사용 중이지 않은 테스트 서브넷에서 합니다
• 기록 파일이 쌓인 뒤 객체 하나를 내려받아 14개 필드가 어떻게 한 줄로 이어지는지 읽기
• 대상을 CloudWatch Logs로 바꿔 만들고 로그 그룹에서 같은 기록을 찾아보기
• CloudTrail 이벤트 기록 글에서 CreateFlowLogs와 DeleteFlowLogs 이벤트를 찾아 이 실습의 생성과 삭제 시각을 확인하기

확인한 범위와 확인하지 않은 것

• 확인한 것: 플로우 로그 생성 화면의 선택지와 기본값, S3 대상으로 생성, 생성 결과 화면, 대상 버킷에 자동으로 붙은 정책의 일부, 버킷의 AWSLogs/ 폴더, 플로우 로그 삭제와 버킷 비우기와 삭제.
• 확인하지 않은 것: 기록 파일의 내용과 생성 시점, 필터를 거부로 바꿨을 때의 동작, CloudWatch Logs와 Firehose 대상, 요금. 필드 의미와 IAM 역할 요구 같은 설명은 AWS 문서를 근거로 한 것이며 이 실습에서 직접 시험하지 않았습니다. 화면 문구는 이 실습 시점의 한국어 콘솔 기준입니다.