AWS - 모니터링 및 감사

Amazon EventBridge

- CloudWatch의 차세대 버전

- 다른 AWS 계정에서 접근할 수 있다.

- 이벤트를 아카이빙하거나, 저장 기간을 지정해서 이벤트를 이후에도 볼 수 있도록 설정할 수 있다.

- Rules : 어떻게 이벤트를 처리할 것인지 (CloudWatch와 동일하다)

 

 

Event Bus의 종류

- Default Event Bus : CloudWatch에서 사용하는 것과 동일함

- Partner Event Bus : Saas 서비스나 애플리케이션으로 이벤트를 전달한다

- Custom Event Buses : 내 애플리케이션에 이벤트를 전송한다.

 

Schema Registry

- 버스의 이벤트를 분석하고 스키마를 추측할 수 있다.

- Schema Registry가 코드를 생성하고 이벤트 버스의 구조를 사전에 알 수 있다.

- 스키마 버전이 기록된다.

 

스키마를 코드화하여 다운로드 받을 수도 있다.

 

 

리소스 기반 정책(Resource-based Policy)

- 교차 계정 엑세스를 위해

- 특정 이벤트 버스에 대한 권한을 관리할 수 있다.

- 다른 AWS 계정이나 지역에서의 이벤트를 수락/거절할 수 있다.

- 다른 AWS에서의 모든 이벤트를 통합하여 하나의 AWS 계정or리전에 둘 수 있다.

 

 

CloudWatch 검색 - Event > Event buses로 들어간다.

 

[Create event bus] 클릭

 

Event archive를 활성화 하여 이벤트를 아카이빙 할 수 있다.

 

리소스 기반 정책에 아무것도 하지 않았다.

그러면 이벤트 버스의 소유자만 이벤트 버스에 이벤트를 전송할 수 있게 된다.

 

Intergration > Partner event sources

를 들어가면, 다양한 이벤트가 있다.

Auth0를 Set up 한다.

[Set up] 하게 되면, Auth0의 이벤트를 캐치할 수 있게 된다.

 

Events > Rules 메뉴에서 [Create rule]을 클릭한다.

 

Rule type

- Rule with an event pattern : 특정 일이 발생했을 때 돌아가는 규칙

- Schdule : 특정 시간에 돌아가는 규칙

 

AWS event - EC2 상태 변화 알람, Sample event는 4로 하여 인스턴스가 중단될 때를 알도록 한다.

 

검토 후 생성한다.

그러면 인스턴스가 중단되거나 Terminate되었을 때, Notification이 온다.

 

 

Archives 메뉴로 오면, 기존에 생성된 모든 이벤트들을 볼 수 있다.

 

EventBridge와 CloudWatch의 차이

- 같은 서비스 API, endpoint, underlying service infrastructure를 사용한다.

- 하지만 EventBridge는 CloudWatch의 확장 버전이다.

- EventBridge는 커스텀 애플리케이션이나 제 3의 SaaS 애플리케이션에 이벤트 버스를 추가하도록 확장성을 부여한다.

 

AWS CloudTrail(추적)

- 내 AWS 계정에 관리(governance), 규정 준수, 감사(audit)를 제공한다.

- 기본값으로 설정되어 있다.

- 이벤트나 API 호출에 대한 기록을 얻을 수 있다. - Console, SDK, CLI, AWS Services

- CloudTrail의 로그를 CloudWatch 로그나 S3로 옮길 수 있다.

- trail을 전체 리전이나 하나의 리전에 적용할 수 있다.

 

 

CloudTrail Events

- Management Events

   - AWS 계정에서 리소스에 수행되는 연산들 - API 호출 등

   - 기본적으로  trail은 로그 관리 이벤트로 설정된다.

   - Read 이벤트와 Write 이벤트로 나눌 수 있다. - Write 이벤트는 리소스를 수정할 수 있으므로 데이터 손상 가능성이 있다.

 

- Data Events

   - *데이터 이벤트는 대규모 연산이기 때문에 원래는 로그가 남지 않는다.

   - S3의 객체 활동 -> Read / Write 이벤트로 

   - Lambda 함수 실행 활동 -> ex. InvokeAPI 사용하면 람다 함수가 몇 번 실행되었는지 확인 가능하다.

 

- CloudTrail Insight Events

   - 심상치 않은 활동들을 발견해 낸다.(유료 서비스) - ex. 불명확한 리소스 프로비저닝, 서비스 limit에 도달, AWS IAM 동작 과다 사용, 주기적 유지보수 활동에 gap이 생겼을 때 등

   - 심상치 않은 패턴(=Insight Events)을 찾기 위해 write 이벤트를 분석한다.

 

 

CloudTrail Event Retention(이벤트 보존)

- 이벤트들은 90일간 보관된다.

- 더 오래 보관하려면, S3를 이용한다. => 이 S3에 보관된 데이터를 Query하기 위해서 Athena가 사용된다.

 

 

   

 

AWS Config

- AWS 자원들의 회계 감사(audit), 규정 준수(compliance) 기록을 위해 사용한다.

- 시간에 따른 환경설정과 변화들을 기록한다.

- SNS 등으로 알람을 받을 수 있다.

- region 당 생성되는 서비스이다.

- 리전과 계정을 중앙화 할 수 있다(aggregate).

- S3에 환경 설정 데이터를 저장하고, 이를 Athena에서 분석할 수 있다.

 

 

Config 검색해서 들어간 뒤, [Create Config] 한다.

한 5분정도 리소스 탐색 시간이 걸리기 때문에 생성 후 기다려야 한다.

 

 

Config Rules

- 커스텀 config rule을 만들 수 있고, 이는 Lambda에서 생성된다.

- 어떤 주기로 확인할 것인지를 정할 수 있다 - 각각의 config가 바뀔 때? 주기적인 시간에 따라?

- 문제 자체를 예방하진 못한다.

restricted-ssh rule을 추가했다.

ssh 기능이 없어야 규칙을 준수하게 된다.

들어가 보면 7개 중 4개만이 규칙을 준수하고 있다.

 

Noncompliant인 SG중 첫번째를 들어가서, 우측 상단의 [Manage Resource]로 들어가 본다.

 

Inbound 규칙을 살펴보면 ssh 포트가 열려 있는 것을 볼 수 있다.

 

삭제한다.

 

다시 탭으로 돌아와서, [Resource Timeline]을 클릭한다.

 

CloudTrail과 연결해 리소스에 대한 API 호출을 확인할 수 있다.

조금 시간이 경과된 뒤, 확인해보면 Configuraiton이 바뀐 것이 기록되어 있고

Noncompliance -> Compliance로 바뀐 것을 확인할 수 있다.

 

 

Config Rules - Remediation(수정 작업)

- SSM 자동화 문서를 통해 규칙 준수하지 않는 리소스들을 수정할 수 있다.

- 최대 5번, 자동 Remediation 작업을 재시도 할 수 있다.

 

 

Config Rules - Notifications

-  자원이 non-compliant 상태일 때, 알람을 트리거 하기 위해 EventBridge를 사용한다.

 

- 환경설정이 바뀌었거나 compliance 상태를 알리기 위해 SNS를 사용한다.

 

 

CloudWatch vs CloudTrail vs Config

	CloudWatch	CloudTrail	Config
특징	- 성능 모니터링 - Event & 알람 - 로그 집계, 분석	- API Call들을 기록한다 - 특정 리소스에 trail을 정의할 수 있다 - Global Service	- configuration이 바뀐 것을 기록한다. - compliance rule에 따라 자원들을 평가한다. - 변화와 compliance를 시간에 따라 기록한다.
ELB에 응용	- 들어오는 연결에 대해 모니터링 - 에러 코드를 퍼센트화하여 시각화 - LB의 성능 확인	- API 호출로 LB를 변경하였는지, 누가 변경하였는지 확인할 수 있다	- SG를 트래킹 - configuration 변화를 트래킹 - SSL certificate가 항상 LB에 할당되는 것을 보장한다.