본문 바로가기

웹 운영/AWS

[CDA] 섹션 20 - AWS 모니터링 및 감사 (Audit): CloudTrail

728x90

<266강: CloudTrail 개요>

 

 

> CloudTrail 은 AWS 계정에 대한 Governance, Compliance (규정), Audit (감사) 를 제공해주며, 기본적으로 활성화되어 있다.

> AWS 계정 내에서 발생한 모든 events / API 호출의 기록들을 제공받는다.

>> 콘솔, SDK, CLI, 타 AWS 서비스 등

> 이 CT의 로그들을 CloudWatch Log 혹은 S3 로 전달할 수 있다.

> 모든 Region / Single Region 에 적용되는 Trail 을 만들 수 있음. 

> 어떤 사람이 어떤 계정으로 접속해서 어떤 리소스를 지워서, 누군지 알고 싶으면 CT 부터 확인한다. (CT 의 API 를 통해 누가 / 언제 / 무엇을 했는지 파악할 수 있다) >>> AWS 의 블랙박스 같은 느낌

 

 

 

CloudTrail 은 계정 및 계정의 활동에 대한 로깅을 제공한다



> Inspect & Audit 을 위해 CT 를 살펴볼 수 있다. (90일 이상 보관을 원하면 후속으로 보내야 한다)

 

 

<CT Events>

 

> Management Event

>> AWS 계정에 있는 리소스들에 대한 Operation 을 말한다

(ex: 누군가 보안을 구성 (Configure Security) 하려면 IAM AttachRolePolicy 를 사용하는데, 이게 CT 에 나타난다)

(ex: 누군가 서브넷 세팅을 건드려도 (EC2 Create Subnet), 로깅을 설정해도 (CT CreateTrail) 모두 CT 에 나타난다)

>> default 로, 모든 management event 를 trail 하도록 되어 있다. 

>> 이 이벤트는 또한 두 종류로 나눌 수 있다.

>>> Read Event : 리소스를 수정하지 않음 (ex: IAM에서 모든 사용자 나열, EC2 인스턴스 나열 등)

>>> Write Event : 수정이 동반되는 동작 (DynamoDB 테이블 삭제) 좀 더 중요.

 

> Data Event

>> 높은 단위의 operation 이며, default 로 로깅되지 않는다.

(ex: S3 객체 수준 활동 / Get,Delete,Put Object) 

(ex: Lambda Function Execution Activity (Invoke API 사용) -> 람다를 본격적으로 쓰면 high-volume op 이라고 함) 

>> 이 역시 두 종류로 나눌 수 있다. (Read / Write)

 

> CT Insights Event

> 좀 더 자세히 살펴보자

 

 

<CT Insights>

 

> 계정 내에 사용하는 리소스가 매우 많으면, 많은 API 가 발생한다. 

> 가끔 정상 범위의 녀석과, 이상하거나 비정상적으로 보이는 녀석들을 구분하는게 제법 어려울 수 있다. 

> CT 인사이트는 직접 활성화해야하며, 유료이다.

> 발생하는 이벤트들을 분석하여 Unusual Activity 를 감지한다.

>> 부정확한 리소스 프로비저닝

>> 서비스 제한 초과

>> AWS IAM 작업 폭주

>> Gaps in 주기적인 유지보수 활동(?)

> CT 는 Management Events 들을 분석하여 "정상 범위" 에 해당하는 기준선을 만들고, "올바른 유형"을 계속 분석해 나감.

> 지속적으로 "write event" 들을 분석하여 unusual pattern 을 감지하려 한다. (비정상 패턴은 write event 만 판단하는 듯?)

 

CT Insight 는 비정상적인 활동을 알아서 분석하고 감지한다

 

> Management Events 들은 지속적으로 분석된다

> 당연히 Unusual Event 로 판단된 것은 CT 콘솔에 나타나며, S3, EventBridge 등으로 연결해줄 수 있다. (EventBridge 에서 SNS 등으로 연계 가능) 

 

 

<CT Event Retention>

 

> 기본적으로 CT 에는 90일동안 이벤트 로그가 보관된 뒤 삭제된다.

> 감사 목적으로 1년 전 이벤트를 보고 싶을 수 있다. 

> 따라서 이런 Use Case 가 있을 수 있어 더 오래 보관이 필요하다 판단되면 S3 에 로그를 보내고, 보통 이 경우에는 [Athena] 라는 걸 사용해서 분석할 수 있다고 한다...

 

CT 에서 90일 이상으로 보관하고 싶으면 S3 연계해야하고, 이를 분석하려면 Athena 서비스를 보통 사용한다

 

 

> Athena 는 S3 에서 데이터를 쿼리할 때 사용하는 Serverless 서비스이다.

> 이를 통해 S3 내에서 관심있는 이벤트 기록을 찾아볼 수 있다.

 

 

----------------

 

<267강: CloudTrail 실습>


> 아무것도 하지 않은채로 CT>이벤트 기록 이동해도, 90일동안 발생한 이벤트들을 확인할 수 있다
> 그냥 예시로 EC2 로 이동, Ec2 하나 삭제해버림
> 사용한 API : TerminateInstances 로, 어디서 언제 사용되었는지, 어떤 access key 로 사용되었는지 로깅이 된 것을 알 수 있다


<268강 EventBridge 와의 연동 - Intercept API Calls>

CT의 Log 에 대한 Event 를 발생시켜 연동할 수 있다

 


> 유저가 DB에 어떤 삭제 처리를 할 때마다, SNS 알람을 받고 싶다고 해보자  (DeleteTable API Call 사용)
> 모든 API 와 마찬가지로 해당 API 역시 발생할 때마다 CT 에 Logging 이 된다
> 이 모든 Log 들을 Amazon EventBridge 의 Event 로서 남게 되기도 한대 (이것도 모든 API 다 남았었나? 벌써 기억 안남)

>> 사실 이 부분이 자동으로 되는건지, 연동!이 필요한건지 조금 헷갈림
> 이 이벤트 (Delete Table API) 에 대한 규칙 (EventRule) 을 만들고, SNS 화 시킬 수 있다


CT 와 EventBridge 를 연동한 다른 사례

 


> 또다른 예시들을 살펴보자
> 너의 계정내 IAM Role 을 어떤 User 가 Assume 할 때마다 알람을 받고 싶다고 해보자
> AssumRole 은 IAM 에서 제공하는 API 이므로, CT에 Logged 된다
> 아까와 같이 EventBridge 와 Event 로 연계시킬 수 있고, SNS 토픽으로 Alert 를 Trigger 할 수 있다


> 두번째 예시는 두번째 그림
> SecurityGroup Inboud Rule 을 수정하는 API 에 대한 Intercept 도 만들 수 있다 (AuthorizeSecurityGroupIngress)
> 위와 같은 흐름으로, 어떤 API 들에 대해서도 EventBridge 와 연동할 수 있다


<269강 - CT vs CW vs X-Ray - 다시 한 번 요약>

CT  (API Call 이 focus)
> User / Service / Console 등의 API Calls 들을 Audit 하는 것이 목적
> 인증/인가되지 않은 호출 / 어떤 변화(삭제,수정)에 대한 이유 파악 등에 유용하다 

CW (Monitoring 이 focus)
> CW Metric 에 대한 Monitoring
> CW Logs 를 활용한 앱 로그 저장
> CW Alarms 을 활용한 Unexpected metric 이상에 대한 Notification 발송

X-Ray (Trace oriented 가 focus) 
> 자동화된 Trace Analysis & Central Service Map 시각화 (분산 환경 서비스에 최적) 
> Debugging 에 유용 / Latency, Error, Fault 분석에 효과적
> 분산환경에 따른 요청 Tracking 가능 (걍 똑같은 말) 


<퀴즈>

1. 기본은 5분, High Resolution 은 1초
2(틀림 - (EC2 에 대한 부분 복습 필요)). CW Metric 1분마다 수집 EC2 인스턴스가 몇 개 있다. 뭘해야하는가? > High Resolution (1번과 동일)
> 아니 ㅅㅂ 뭔 Metric 인지도 안말해줬잖아..
> 해설: 사용자 지정 메트릭을 게시할 때 표준 해상도 또는 고해상도로 정의할 수 있습니다. 1초, 5초, 10초, 30초 또는 60초의 배수에 고해상도 사용자 지정 지표를 읽고 검색할 수 있습니다.
> 정답: 세부 모니터링 활성화 :: 유료, 비활성화,  활성화시 EC2 인스턴스의 Metric 은 1분동안 사용할 수 있다. 
3. 팀원 중 한 명 4개월 전에 EC2 종료. 누가 이걸 수행했는지 CT 로 API 호출 거검토. S3 로 보내도록 구성되어 잇음 (90일 이상에 대해) > 아테나로 분석가능
4 (오픈북). 모든 AWS Region 에서 AWS 계정에 대해 CT 활성화. 비정상적 활동 감지를 위해 뭘해야함? > 많은 API 를 감시해야함. 많은 API 에서는 Insight 를 활성화하여 "Manged Event" 를 분석하도록 하여, unusual pattern 을 감지할 수 있따 (올바른 유형을 분석해나간다) 
5. 누가 중요한 인스턴스 종료함. 누가했는지 알려면? > CT
6.  구성 변경 후 앱 성능에 미치는 영향 평가하려 함. CW 사용해서 메트릭스 봐야지. 
해설: CW는 애플리케이션을 모니터링하고, 시스템 전체의 성능 변화에 대응하고, 리소스 사용률을 최적화하고, 운영 상태에 대한 통합 보기를 얻을 수 있는 모니터링 서비스입니다. 애플리케이션의 성능과 메트릭을 모니터링하는 데 사용
7 (틀림, 해석도 좀 이상-아예 기억 안남...이부분 찾아야 할듯) . 고해상도 CUstom 사용자 지정 Metric 에 대한 CW Alarm 의 주기 설정? (횟수만큼 트리거?)
> 10초
> 해설: 고해상도 매트릭에 알람을 설정한다면, 고해상도 알람을 10초 / 30초로 지정하거나 정기 알람을 60초의 배수로 설정 가능 
8. CW 에서 EC2 인스턴스 메모리 사용량 어떻게 모니터링?
> 이거 기본적으로 안된다고 했음 (사용자 지정 필요! 세부 모니터링, 사용자 지정 이거 차이에 대해, Unified CW Agent 가 뭐였나?)
9 (틀림, 중요한 문제인듯). 최소 용량 2로 구성한 ASG 에서 관리하는 EC2 집합. CPU 사용률이 60% 미만일 때 ASG 를 축소하도록 구성된 CW Alert 생성. 현재 2개의 EC2 인스턴스 실행중인데, Alert 가 ALARM 상태임. 무슨 일이 일어나는가? 
> 1번 vs 3번. 내 기억으론 여러번 확인후, 그 중 a(설정된것의 갯수) 만큼 이면 ALARM 이 발생. ALARM 상태이면 감소되는게 맞음. : 1번!
> 이거 약간 장난질인듯.. 최소 용량 (Min 은 내려가지 않는다) > 최소 용량이 2로 구성되었고 2개가 있으니 절대 내려갈 수 없음 (Desired 가 2면 내려가는 거일듯, 최소가 1이고) 

이거 왜 다적는지 갑자기 모르겠음. 문제별로 노트만 하고 할거 없으면 이제부터 안쓸거임

12 (틀림). 이거 문제 틀린거 아님..? 다음 API 를 사용하여 X-Ray 에 쓸 수 있다
1, BatchGetTraces / 2. PutTraceSegments / 3. PutTelemetryRecords (답이 1번인데..?, 2,3 번이 쓸 수 ㅣㅆ는거아님? 2번이 있었나는 잘 기억안남. 3번은 그 Open API 그거 아닌가? 아닌가? ㅋㅋㅋㅋㅋ 그 write API 설명할 때.. 음..) 
14. 필터링 여부 잘 판단/ metadata & annotations, sampling & segment 이 네가지 차이 기억
15 (제법 어려움? 권한 정책 얘기가 아니라니..!). 여러 AWS 계정에서 중앙 AWS 계정으로 추적을 보내도록 X-Ray 데몬을 구성하려면 어떻게?
> ANW: 중앙 계정에서 IAM 역할을 생성한 다음 이 IAM 역할을 맡을 다른 ㅖ정에서 IAM 역할을 생성 (Assume Role 한다는게 이거일 것 같음!)
17 (자주나오는 질문이라고 하심) : 로컬에서는 X-Ray 하는거 잘됐어요! 근데 Deploy 하고 운영해보려니까 안돼요! 데몬은 실행중이에요! > 거의 무조건 권한 문제. 
> 정답 : EC2 인스턴스에 연결된 IAM Role 에 X-Ray 로 데이터를 보내는 권한 필요
18. X-Ray 를 활용하여 앱 구성함. Local 에선 되지만, Deploy 하니까 안됨. 가능한 원인은? 데몬 확인안했으면 데몬이지 뭐
19. Beanstalk 은 자동으로 데몬이 실행된다. 따라서 SDK 만 잘 맞물리면됨. 근데 Console 에서 활성화하거나, ebextension 으로 활성화한다고 해줘야 함
20 (틀림). CW Log 에서 Log 보존 정책은 ㅁ 수준에서 정의된다
1) Log Stream 2) Log Group > 정답은 2번이래. 이거 다시 한 번 보자!!
21 (맞았는데 생각은 틀림). 기본적으로 CW Log 는 7일 후 만료. 7일은 아니였던 것 같은데...
>> Log 는 직접하지 않는 이상 절대 만료되지 않음!!!
22 (틀림). 옛날에 공부한걸 많이 틀림 >> RAM 사용량 같은걸 CW 사용자 지정 지표로 사용하려 함. CW 에 푸시할 수 있는 API 호출의 이름은?
1) SendMetricData // 2) PutCustomMetric // 3) PutMetricData // 4) SendCustomMetric 
> 이렇게 옹졸하게도 나오는구나. 유독 이 섹션에서 API 이름에 대해 많이 묻는듯. 정답은 3번이라고 함.
23.  CW Alarm Test 하기 복잡한 경우 그냥 CLI 로 API 쏘라고 했음

 

 

 

 

====================================================================================

 

 

교육 출처

 

- AWS Certified Developer Associate 시험 대비 강의 - Udemy

 

https://www.udemy.com/share/105Hxw3@z0Wqme5D9voly52i8MuQYl_c8462GP25Oul4H38G3nVfgD4fMrYPJE5LOB88iDuZ/

728x90