우리는 AWS리소스와 애플리케이션의 상태, 성능 , 보안수준을 관리하기 위해 AWS환경을 지속적으로 모니터링한다. 이것을 가능하게 해주는 서비스가 Cloudwatch , CloudTrail, Config다.

주로 모니터링 하는 것은 성능, 애플리케이션 문제점, 보안 문제점, 로그 이벤트, 리소스 인벤토리 관리 등이 있다.

CLoudTrail

이벤트란 IAM유저, 사용자가 리소스에 대해 행한 액션이다.
이러한 이벤트(읽기 / 쓰기)를 기록하고, 액션의 종류, 영향을 받는 리소스와 리전, 액션을 위한 사용자, 액션이 취해진 시기등 상세한 내역을 수집하고 기록한다.
이러한 이벤트를 유형에 따라 관리 이벤트, 데이터 이벤트로 분류해 저장한다.

관리 이벤트

AWS리소스와 관련해 사용자가 액션을 수행하였거나 또는 수행하려고 시도한 모든 작업을 포함한다.
📌 리소스 자체를 바꾸는 API작업 같은 리소스 단위의 큰 이벤트다.
📌 예시로 RunInstance API, DescribeInstance API등이 있다.

데이터 이벤트

S3객체 수준의 작업이나, Lambda 함수 실행 두가지로 나누어 진다.
📌 리소스 내에서 수행한 작업으로 관리 이벤트보다는 상대적으로 작은 단위의 작업이다.
📌 예시로, S3버킷에서 데이터를 다운로드 할때 GetObject나 DeleteObject, PutObject등이 있다.

이벤트 히스토리

이러한 이벤트를 저장하는 곳이 이벤트 히스토리라는 데이터베이스다. 최대 90일까지 이벤트를 기록할 수 있으며, 리전 별로 해당 리전에 이벤트 히스토리를 생성한다.
📌 특정 리전에 국한된 서비스들의 로그는 해당 리전의 이벤트 히스토리에서만 찾을 수 있지만 IAM, ROUTE53, Cloudfront와 같은 글로벌 서비스들은 모든 리전에서 이벤트 로그를 찾을 수 있다.

Trail

90일 이상의 이벤트를 저장하거나, 로그에서 특정 서비스 또는 액션을 제외시키거나, S3다운로드/업로드 등을 포함시키는 커스텀 이벤트로그를 생성하는 경우 Trail을 이용한다.

Trail은 CloudTrail의 옵션으로 JSON형식으로 작성된 로그파일을 가지며 로그파일은 하나 이상의 로그 엔트리를 가진다.

• 로그 엔트리 : 리소스의 개별액션의 기록으로 EventTime, useridentity, eventsource, eventname, awsRegion, SourceIPaddress를 기록한다.

Trail 생성

Trail은 글로벌리전, 단일리전을 선택해서 생성할 수 있다.
둘중 어떤 옵션을 선택해도 최대 5개의 Trail을 생성할 수 있다.
💡 예시로, 단일리전으로 us-east-1에 Trail생성 후 글로벌리전으로 Trail을 생성하면 us-east-1리전에는 두개의 Trail이 생성되어있다.

로그 파일 진실성 검증

CloudTrail이 수집한 로그는 주로 감사활동에 사용된다. 하지만 로그 파일이 변조 또는 삭제되지 않았음을 보장할 수 없다. 이를 보장하기 위해 CloudTrail의 로그 파일 진실성 검증 옵션을 활성화 할 수 있다.

보통 로그 파일은 S3버킷으로 보내어 원하는 기간만큼 저장되는데, S3버킷에 로그 파일을 보낼 때 파일에 붙어 있는 암호 해시를 연산 및 확인한다. 해시란 로그 파일자체에서 파생된 유일한 값으로 로그파일이 1바이트라도 변경되면, 전체 해시가 바뀌게 되므로 로그파일의 무결성, 온전성, 진실성을 확인할 수 있다.

Config

AWS리소스나 AWS환경에 설정된 내역, 즉 환경설정 내역을 추적하고 변화를 감지한다. 이를 통해 과거와 현재의 환경설정 내역을 비교할 수 있고, 리소스간 관계를 파악할 수 있으며, 특정 리소스의 설정 변경이 다른 리소스에 어떤 영향을 미치는지 파악할 수 있다.

환경설정 레코더

Config의 핵심 요소로 환경설정 내역 기록, 변경 사항 기록, 시간 흐름에 따른 변경 추적등의 기능을 수행한다. 즉 Config에서 모니터링하는 주체라고 생각하면 된다.
📌 리전당 하나만 사용가능하다.
📌 모니터링을 원치 않는 경우 DynamoDB , EC2등 구체적으로 대상을 정할 수 있다.

환경설정 아이템

환경설정 레코더는 모니터링 대상마다 환경설정 아이템을 생성하는데 리소스타입 , ARN, 생성시점 등의 정보를 가지고 있다.
📌 설정에 변경사항이 생기면 레코더는 최소 하나 이상의 아이템을 생성한다. 예시로 , 보안그룹에 변경사항이 생긴다면 보안그룹을 사용하고 있는 모든 EC2를 위한 아이템도 생성해야한다.

환경설정 히스토리

환경설정 아이템은 환경설정 히스토리에 보관된다.
6시간마다 환경설정 히스토리를 S3버킷에 저장하며, 해당 S3버킷을 '딜리버리 채널' 이라고 부른다. 파일은 리소스 타입별로 그룹화 되며, 타임스탬프를 이용해 시간대별로 파일을 보관한다.

룰을 이용한 모니터링

사용자는 원하는 커스텀 룰 (최적 환경설정 기준)을 생성해 Config가 검증하게 할 수 있다.
예를 들어, 모든 EBS볼륨이 암호화가 되어있는지 확인하며, 루트유저를 위한 MFA가 활성화 되어있는지 확인하는 룰을 생성하면 이 조건이 맞는지 검증을 시작한다.

• EventBridge를 이용한 알림
  

  조건에 맞지 않는다면 EventBridge를 통해 다른 서비스에 알릴 수 있다.
  📌 EventBridge의 타임스케줄링을 통해 원하는 주기마다 조건에 부합하는지 검증하게 할 수 있다.

• SNS를 이용한 알림
  

  조건에 맞지 않는다면 SNS를 통해 다른 서비스에 알릴 수 있다.

📌 룰을 생성하게 되면 즉시 모든 리소스에 걸쳐 조건에 부합하는지 검증에 들어가며, 이후에 재검증 기능을 활성화하면, 일정 기간마다 재검증을 할 수 있다.
📌 환경설정 레코더를 끈 상태에서도 정기 검증은 실행된다.

마치며

Cloudwatch, CloudTrail, Config는 주로 사용자의 요구를 해결 해준다기 보다는 무결성,온전성,진실성을 확인시켜주는 서비스라고 생각이 든다. 그렇기에 감사에 주로 이용되는 것 같다. 만약 이러한 서비스를 관리하는 관리자가 나쁜 마음을 먹는다면 , 조금의 조작으로 회사에 큰 손실이 있을 것 같다. 그렇기에 로그를 관리하는 서비스도 중요하지만 이 서비스를 관리하는 관리자를 관리하는 것도 중요하다는 생각을 했다.
이후 포스팅에서는 CDN(Content Delivery Network,Cloudfront)와 GA(Global Accelerator)에 대해서 다루어 볼 예정이다.