AWS 로그 모니터링(Cloudtrail, VPC Flow Log)
클라우드 로그 종류
클라우드 자원별 로그
- EC2생성 및 삭제, S3스토리지, DB, 서버리스 자원, 컨테이너 로그 등
- 자원별로 cloud watch를 이용하여 확인하고 통합
(cloudwatch + elk/splunk 등의 기존 통합로그 시스템을 복합적으로 사용 가능)
네트워크 트래픽 로그
- 가상네트워크 VPC flow 로그
자원이벤트 로그
- AWS SDK, CLI 를 이용한 API로그 관리
- API를 호출한 IP주소와 호출한 사용자 IAM계정 추적 가능
비용 이벤트 로그
- 클라우드 서비스를 이용할 때, 각 자원/태그별 비용 확인
- 정해진 예상 금액 이상 → 경고메세지 기능
비용 이벤트 로그
예전에 cloudgoat로 과제하다가 하루만에 오만원 과금폭탄을 받은 적이 있다....내 크고 소중한 오만원..
매를 맞더라도 미리 맞을 수 있도록 cloudwatch를 통해 billing이 과금되면 알람이 오도록 설정해주자.
이때, region은 서울이 아닌 버지니아 북부에서 'cloudwatch-결제'를 통해서 내 이메일로 알람이 오도록 설정해준다.
# CloudTrail을 통한 로그 관리
Cloudtrail (이벤트 로그st)
- AWS 계정관리, 규정준수, 운영 및 위험 감사 지원
- 사용자, 역할, 서비스에 수행한 작업에 대한 정보를 확인 가능 → "누가, 언제, 무엇을 했는 지"에 대한 API 호출 기록 확인 O
- AWS에서 서비스하고있는 모든 행위의 이벤트를 모아 분석 및 리소스 변경 등의 추적 가능
- cloudtrail 자체는 무료지만, 로그를 수집하며 사용하는 S3에 의해 요금이 발생
Cloudtrail의 이벤트 종류
- 관리 이벤트 : 계정 리소스에서 수행되는 관리 작업 이벤트
- 데이터 이벤트 : 리소스에서 수행되는 리소스 작업 이벤트
- 인사이트 이벤트 : 계정에서 발생한 비정상적 활동 이벤트
※ Cloudtrail vs Cloudwatch ※
cloudtrail은 이벤트 로그로 "누가 무엇을 했는 가"에 초점을 두어
보안감사, 포렌식, 변경 추적에 용이하다 또한, 해당 이벤트 로그들은 S3에 수집된다.
반면, cloudwatch는 메트릭 및 로그 기반의 시스템 모니터링으로 "시스템이 어떻게 동작하는 지"에 초점을 둔 모니터링 도구이다. 리소스 상태, 성능 지표, 로그 등을 수집하여 시스템 운영 모니터링 /성능 측정 / alert 등을 수행한다.
또한, 수집된 데이터들은 cloudwatch 자체의 스토리지에 저장된다.
cloudtrail에서 추적할 이벤트를 선택하고, 저장할 버킷을 선택해주면 다음과 같다.
추적 시작 시, 해당 s3에 로그들이 저장되며,
설정한 감사로그 이벤트들을 확인할 수 있다. trail을 추적하기 이전의 로그들도 다 나타나는 것을 확인할 수 있다.
각 이벤트를 확인해보면, 이벤트 트리거 계정, 시간, ip, 키 등의 정보를 확인할 수 있다.
# VPC Flow 로그를 통한 네트워크 접근 로그 수집 및 분석
VPC Flow 로그란?
- VPC, 서브넷, ENI(network interface) 수준에서의 오고가는 네트워크 트래픽 흐름을 로그로 기록해주는 기능,
- "누가 누구에게 패킷을 보냈고, 허용/차단되었는 지"
- 실시간을 고려하면 cloudwatch 로그 / 장기간 보관을 고려하면 s3로 게시
- 트래픽 기록 수준 설정가능 → accept만 기록/ reject+accept기록 ..등
#실습
VPC Flow로그를 vpc에 붙여보자.
0. 인프라 기본세팅
- VPC: cloud infra
- 서브넷 구성: Public / Private Subnet
- EC2 인스턴스: dmz_web (Public Subnet에 배치)
- dmz_web_sg : ssh, http, https만 allow
1. Cloudwatch 로그 그룹 생성
cloudwatch 로그 그룹은 cloudwatch가 모니터링하는 대상의 로그들이 수집되는 저장소이다.
- 이름: VPC_logs
- 보존 기간: 3일로 설정 (거지닉까..)
- 최대 1만 개까지 로그 그룹 생성 가능하다.
VPC flow logs를 CloudWatch로 전송하기 위해서
'CloudWatch으로 로그를 전송할 수 있는' 권한을 생성하고, 해당 권한이 부여된 IAM 역할을 생성하자.
그 역할은 VPC Flow Logs 서비스(VPC 자체)가 가져가도록 할 것임.
2. IAM 정책 생성 및 역할 설정
2.1. IAM 정책 생성
정책 : VPC-Flow-Log
VPC → CloudWatch log로의 전송을 위한 권한 제공
포함 권한 : 최소 권한을 주기 위해 5개만 설정하였음
- 나열
- DescribeLogGroups
: Grants permission to return all the log groups that are associated with the AWS account making the request - DescribeLogStreams
: Grants permission to return all the log streams that are associated with the specified log group - 쓰기
- PutLogEvents
: Grants permission to upload a batch of log events to the specified log stream - CreateLogGroup
: Grants permission to create a new log group with the specified name - CreateLogStream
: Grants permission to create a new log stream with the specified name
2.2. 역할 설정
역할: VPC-Flowlog-Role
- 서비스 선택: EC2
- 위에서 만든 정책 연결 → 이 역할에 해당 정책에 정의된 내용만 수행가능 (권한 설정)
생성 후에 신뢰관계를 수정해주자.
- 신뢰관계 : 해당 역할을 사용할 수 있는 대상 정의 (위임 대상)
- 우리는 EC2가 VPC flow log를 cloudwatch로 보내도록 하는 것이 아니라,
VPC Flow자체가 cloudwatch logs로 보내도록 하는 것이기 때문에
"ec2.amazon.com" 이 아닌 "vpc-flow-logs.amazonaws.com"으로 바꿔야함.
(이때, vpc-flow-logs는 뭐 내가 만든 정책명 같은게 아니라 찐 서비스 명칭)
- 우리는 EC2가 VPC flow log를 cloudwatch로 보내도록 하는 것이 아니라,
3. VPC Flow 로그 설정
- 이름 : Cloud_Infra-Flowlog
- 대상: 전체 트래픽(All)
- 샘플링 간격: 10분 (1분이면 더 좋지만 난 거지닉가..)
- 대상 로그 그룹: VPC_log (CloudWatch)
- IAM 역할: VPC-Flowlog-Role
- 설정 완료 후 Flow Log 생성
이제 해당 VPC에 쌓이는 로그들을 만들고 확인해보자
4. 로그분석 실습
외부 접근 시도를 먼저 만들어주고,
- ssh로 직접 접근
- 접근을 시도하는 공격 스크립트 생성 및 실행
CloudWatch 로그를 확인해보자!
- 각 ENI별 스트림 존재
- 로그 상세 확인 가능:
- source IP, destination IP, 포트, 프로토콜, action (ACCEPT/REJECT), 시간 등
log insight 를 통해 filtering도 가능하다
- 로그 스트림 → [작업] → Log Insights 실행
- Sample query 예제 사용하여 분석 가능
fields @timestamp, srcAddr, dstPort, action
| filter action = "ACCEPT"
| sort @timestamp desc
| limit 20
시행착오
1. EC2 접속 문제.
public subnet을 만들때,
igw( cloud_infra_igw )를 vpc(cloud_infra)에 붙이고,
해당 igw를 public_subnet의 라우팅 테이블에 추가하여 외부 접속을 허용
그리고 계속 라우팅 테이블이랑 nat gateway이랑 헷갈림.
그냥 그 접속을 해주는 서비스말고 그 규칙? 들이 헷갈리는 듯.