[AWS] Multi Account에서 IAM 내역 감사하기 #1 - 개요, 아키텍쳐, 고려 사항

1. 개요

Multi Account 환경에서 IAM 관련 Action에 대한 감사를 하기 위해서는 Log들을 Security 관련 Account에서 수집해야 한다.

 

이에 대해 다음의 AWS 서비스들을 활용하였다.

 

Terraform : 인프라스트럭쳐 프로비저닝

 

CloudTrail : AWS API 감사해주는 서비스

Event Bus : AWS Event가 흐르는 통로

Event Rule : AWS 특정 Pattern을 지닌 API를 잡아내기 위함

CloudWatch Logs : 각 Account에서 발생하는 Log들을 수집

Subscription Filter : CloudWatch Logs로 적재되는 Log들을 Amazon ES로 보내기 위한 구독 필터 설정

Amazon OpenSearch : Log 중앙 수집 및 Kibana를 통한 시각화

 

Lambda : Slack으로 Notification을 보내기 위한 Python 코드를 실행시키기 위한 컨테이너 (런타임)

Slack : Notification을 받기 위한 용도

 

Slack Notification : CloudTrail -> EventBridge -> SNS -> Lambda -> Slack

시각화 및 로그 수집 : CloudTrail -> EventBridge -> CW Logs -> OpenSearch (Kibana 시각화)

---

2. 아키텍처

Multi Account에 동일한 리소스를 배포하기 위해 Terraform을 활용

(SNS, Lambda, VPC Peering 등 몇몇 리소스는 웹 콘솔에서 수동 생성하였다.)

 

전체적인 흐름을 설명하자면,

 

각각의 Account에서는 CloudTrail을 활성화하면 각각의 IAM API 내역들이 Default EventBus를 통해 흐르게 된다.

이 때, Default EventBus는 API 내역을 감시하기 위해서는 Event Rule을 설정할 수 있다.

(Default EventBus 외에 Custom EventBus가 존재한다는 사실을 알고 있어야 한다. 중요 ! )

 

Event Rule에서는 어떤 API 내역들을 Capture 할 것인지 Event Pattern을 정의할 수 있고 Event Pattern을 충족하는 API를 어떤 Target으로 보낼지 정의할 수 있다.

 

Target 으로는 EventBus, CloudWatch Logs, Kinesis 등 여러가지가 존재하는데, 여기서는 SNS, EventBus와 CloudWatch Logs 3개를 Target으로 설정하였다.

 

각 Account에서 Security Account으로 IAM API를 보내게 되면 Security Account에서는 또 한번 더 Target으로 보내게 된다.

 

Target으로는 SNS와 CloudWatch Logs로 보내도록 할 것이며, SNS는 Slack Notification 용도로 활용하고, CloudWatch Logs는 Subscription Filter를 걸어서 OpenSearch Index로 보낼 것이다.

 

(각각의 API 내역은 OpenSearch에서 개별 Document로 존재할 것이며, OpenSearch 및 Kibana 활용도에 따라서 감사할 수 있는 범위가 천지 차이가 될 것이다.)

 

## 고려  사항

 

1. 각 Account에 대한 인증을 Terraform에서 어떻게 수행할 것인지?

방법은 다양할 것이다.

보안을 위해 각 Account에 대한 접근은 AssumeRole을 통해 발급 받은 액세스키와 시크릿키, 임시 토큰 값을 ~/.aws/credentials 파일에 alias로 설정한 뒤 _provider.tf 파일에서 Profile=${alias}로 접근

 

2. Multi Account에서 IAM 권한은 어떻게 설정해야 하는지?

단일 Account일 경우 Resource 혹은 Principle 한 곳에서만 API Action이 Allow일 경우 수행할 수 있지만

  Cross Account일 경우 A <-> B 각각에 대한 Policy가 충족이 되어야 한다. 혹은 신뢰관계를 설정하여 sts:assumeRole을 통해 임시 Token을 발급받아 접근해야 한다.

 

 

3. Default EventBus와 Custom EventBus의 차이점
: 이 부분때문에 시간이 좀 소요되었다.

 

 

4. A, B, C, .. 계정의 EventBridge -> Security 계정의 EventBus로 Event를 보낼 때 IAM Policy 적용

아래의 문서 참조

 

공식 문서 : https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus-perms.html

 

 

5. OpenSearch를 대상으로 구독 필터를 생성할 경우 내부적으로 Lambda가 생성이 된다.

이 때, Lambda -> OpenSearch로 https에 대한 Inbound가 막혀 있을 경우 구독 필터가 정상적으로 설정이 되었어도 Lambda -> OpenSearch Timeout 발생 이슈가 존재한다.

 

Timeou이 발생하는지 확인하는 방법은 Lambda의 Monitoring 혹은 CloudWatch Logs를 보면 확인할 수 있으며, SG 기반으로 Allow 해주면 된다.

 

또한, 이러한 이유로 인해 Terraform으로 구독 필터를 만들 경우 Error가 발생하며, Lambda 소스코드 및 Lambda function을 Terraform으로 직접 생성해주어야 한다. 이러한 이슈로 인해 웹 콘솔에서 수동으로 생성해주었다.

 

 

6. OpenSearch에서 Alert 기능이 많은 정보를 전달해주지 못하는 것 같다 (이 부분은 잘 몰라서 정확 X)

 

=> 이러한 이유로 인해 따로 Lambda를 만들어서 Slack Alert를 보내도록 설정하였다.

 

{monitor={_id=, _version=1, name=IAM_CreateUser, enabled=true}, results=[{_shards={total=5, failed=0, successful=5, skipped=0}, hits={hits=[], total={value=0, relation=eq}, max_score=null}, took=3, timed_out=false}], periodStart=2022-04-06T07:12:40.849Z, periodEnd=2022-04-06T07:13:40.849Z, error=null, trigger={id=nEi4_X8BKGQCku7dywj0, name=IAM_CreateUser, severity=1, actions=[{name=SecuritySlackChannel}]}, alert=null}

 

다음 글에서는 Terraform 폴더 구조 및 코드를 어떻게 작성하였는지에 대해 글을 써보겠다.