[AWS-Security] 3.1. 멀티 계정 간의 접근 보안

Posted Feb 19, 2026 Updated Mar 5, 2026

By haksuperman

views 10 min read

1. 개요

멀티 계정 간에 애플리케이션을 분할하면 보안을 강화할 수 있다. 그러나, 계정 간 통신이 이루어질 때에는 비용이 발생한다.
-> 교차계정(Cross-account) 역할은 이러한 문제를 해결한다.
멀티 계정의 또다른 문제는 모든 계정에 대한 정책을 별도로 관리한다는 것이다.
-> AWS Organization을 통해 한 곳에서 관리가 가능하다.

2. 계정 간의 보이지 않는 벽

2.1. 폭발 반경 시나리오

상황 : 동일한 AWS 계정 내의 WorkPress EC2 서버와 Jenkins EC2 서버가 존재한다.
가정 : Alice 사용자가 EC2에 대한 전체 접근 권한을 가지고 있다.
결과 : Alice의 자격증명을 가진 공격자는 두 애플리케이션(WordPress, Jenkins)을 모두 공격할 수 있다.
-> 이를 “Alice 사용자의 폭발 반경(Blast Radius) 내에 있다”라고 한다.

2.2. 폭발 반경을 줄이는 방법

Alice 사용자의 폭발 반경을 줄이기 위해서는 아래 두 가지 방법이 가능하다.

전체 EC2 액세스 권한 제거
애플리케이션을 별도의 AWS 계정으로 이동

AWS 계정 사이에는 논리적 장벽이 있으며, 이러한 상황에 유리하게 사용할 수 있다.

두 애플리케이션이 별도의 계정에서 실행되고 Alice의 자격증명이 손상된 상황에도 Jenkins 서버에 대한 위험은 없다.
Alice 사용자가 첫 번째 계정에서 EC2 서비스에 대한 전체 접근 권한을 가지고 있더라도, 두 번째 계정에서 어떠한 변경도 할 수 없다.
다소 복잡할 수 있는 설정이 없다면 한 계정의 사용자가 다른 계정의 AWS 작업을 호출할 수 없다.

2.3. 멀티 계정을 사용할 때의 장단점

장점 : 복잡한 IAM 정책을 작성하고 관리할 필요 없이 애플리케이션 간에 적절한 분리를 제공한다.
단점 : 멀티 계정을 관리하고 추적하는 것은 어려울 수 있다.

일반적으로 멀티 계정을 사용하는 것은 모범 사례로 꼽히지만, 조직에 적합한지 여부를 평가해야 한다.

3. 교차계정 IAM 역할

3.1. 교차계정 IAM 역할 시나리오

상황 : 동일한 AWS 계정 내의 WorkPress EC2 서버와 Jenkins EC2 서버가 존재한다.
목표
- 두 애플리케이션 모두 동일한 DynamoDB 테이블을 읽어야 한다.
- 별도의 계정에서 실행함으로써 얻는 보안 이점을 유지하면서, 두 애플리케이션이 사용할 수 있는 공유 DynamoDB 테이블이 필요하다.
해결 : 교차계정 역할을 사용하면 한 계정의 엔터티에 다른 계정의 일부 권한을 부여할 수 있다.

3.2. 설정

표준 역할을 만드는 과정과 매우 유사하며, 리소스 정책의 Principal 블록에서 다른 AWS 계정의 엔터티를 참조한다.

3.2.1. 하나의 DynamoDB를 타 계정에서 접근하려는 경우

신뢰 정책 (Trust Policy) 작성

계정 A(리소스 제공자)에서 역할을 생성하는데, 아래 문서를 토대로 생성한다.
아래 문서는 이 역할을 누가 수임(Assume)할 수 있는지를 정의하는 문서이다.
111111111111 계정의 리소스이지만, 222222222222 계정의 Alice 사용자가 이 역할을 수임하는 것을 허용하는 의미이다.

cross_account_policy.json

  
     {
       "Version": "2012-10-17",
       "Statement": [
         {
           "Effect": "Allow",
           "Action": "sts:AssumeRole",
           "Principal": {
             "AWS": "arn:aws:iam::222222222222:user/Alice"
           }
         }
       ]
     }

권한 정책 (Permission Policy) 작성

222222222222 계정의 Alice 사용자가 역할을 맡았을 때, 할 수 있는 권한이 명시된 리소스 정책이다.

query_policy.json

  
 {
   "Version": "2012-10-17",
   "Statement": [
     {
       "Effect": "Allow",
       "Action": "dynamodb:Query",
       "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/sample-table"
     }
   ]
 }

교차 계정 역할 생성
1. CrossAccountRoleForAlice라는 이름의 빈 역할을 생성한다.
2. 이때 –assume-role-policy-document 옵션으로 첫 번째 준비물인 신뢰 정책 파일을 지정한다.
3. 이로써 “2222… 계정의 앨리스만 이 역할을 맡을 수 있다”는 규칙이 역할에 할당된다.
  1 2 3 4 5 #!/bin/bash aws iam create-role \ --role-name CrossAccountRoleForAlice \ --assume-role-policy-document file://cross_account_policy.json
권한 정책 생성
1. DynamoDBQueryAccess라는 이름의 독립적인 권한 정책을 생성한다.
2. 이때 –policy-document 옵션으로 두 번째 준비물인 권한 정책 파일을 지정한다.
3. 이 정책은 “특정 테이블에 대해 Query만 가능하다”는 내용을 의미한다.
  1 2 3 4 5 #!/bin/bash aws iam create-policy \ --policy-name DynamoDBQueryAccess \ --policy-document file://query_policy.json
역할에 권한 정책 연결 (Attach)
1. 앞서 만든 역할(1번)과 정책(2번)을 하나로 연결한다.
2. 이 명령어가 성공적으로 실행되면, CrossAccountRoleForAlice 역할을 맡는 사람은 sample-table을 조회(Query)할 수 있다.
  1 2 3 4 5 #!/bin/bash aws iam attach-role-policy \ --role-name CrossAccountRoleForAlice \ --policy-arn arn:aws:iam::111111111111:policy/DynamoDBQueryAccess

3. AWS Organizations를 통한 멀티 계정 관리

3.1. AWS Organizations가 필요한 이유

목적 : 조직에서 모든 사용자가 EC2 인스턴스를 생성하지 못하도록 막고자 한다.
계정이 적은 경우 / 정책 수정이 적은 경우
- 새 그룹을 생성한 후 모든 사용자를 추가한다.
- ec2:StartInstances 작업을 거부하는 정책을 연결한다.
계정이 많은 경우 / 정책 수정이 많은 경우
- 정책을 관리하는 중앙 통제소가 있으면 좋을 것이다. -> AWS Organizations가 등장한 배경이다.

3.2. SCP(Service Control Policy)

AWS Organizations에서는 다른 모든 계정을 관리하는 중앙 계정을 지정할 수 있다.
AWS Organizations 서비스 내에서 모든 관리 계정의 권한을 제어할 수 있는 서비스 제어 정책(SCP, Service Control Policy)을 만들 수 있다. 이 서비스 제어 정책은 작업을 거부할 수만 있다.

AWS Organization을 생성한다.
AWS Organization에 가입하도록 다른 계정을 초대한다.
초대를 수락한다.
서비스 제어 정책(SCP)을 생성한다.
서비스 제어 정책(SCP)을 중앙 계정에 연결한다.

3.3. SCP 설정

조직 생성 및 초대

  
 #!/bin/bash
	
 aws organizations create-organization \
     --feature-set ALL
	
 aws organizations invite-account-to-organization \
     --target Id=account_a_email@example.com,Type=EMAIL
	    
 aws organizations invite-account-to-organization \
 --target Id=123456789012,Type=ACCOUNT

초대 수락하기
- 초대받은 계정의 소유자가 이메일 링크 등을 통해 초대를 수락하면 조직원이 된다.

서비스 제어 정책(SCP) 생성

service_control_policy.json

  
  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Deny",
        "Action": "ec2:StartInstances",
        "Resource": "*"
      }
    ]
  }

통제 정책 생성 (--type SERVICE_CONTROL_POLICY로 지정하는 것이 핵심이다.)

  
  #!/bin/bash
		
  aws organizations create-policy \
      --content file://service-control-policy.json \
      --name DenyCreatingInstancesPolicy \
      --type SERVICE_CONTROL_POLICY \
      --description "Prevents creating any EC2 instances"

정책 연결

  
 #!/bin/bash
	
 aws organizations attach-policy \
     --policy-id p-DenyCreatingInstancesPolicy \
     --target-id r-centralaccountid123

3.4. SCP 효과

중앙 계정을 포함하여 관리되는 계정으로 이동해 EC2 인스턴스를 시작하더라도, 인스턴스를 시작할 수 없다.
중앙 집중식 빌링과 같이 멀티 계정을 더 쉽게 관리할 수 있는 AWS Organizations의 다른 기능이 있다.
많은 AWS 계정을 사용하며 계정을 추적하기가 점점 어려워지는 경우, AWS Organizations 서비스와 해당 서비스에서 제공하는 기능을 활용하는 것도 좋다.

CLOUD, AWS

This post is licensed under CC BY 4.0 by the author.