[일본 이야기] 일본 지사 개별 어카운트 연결 관리, 가볍게 시작해 보는 방법을 알려드립니다

작성일: 2024-03-14

들어가며

요즘 AWS를 이용하시는 고객을 만나보면, Organizations / Landing Zone / Control Tower를 활용하고 싶다는 이야기를 자주 듣습니다.

복수의 AWS Account를 사용하면서 SSO, OU, IAM 등, AWS 계정 들을 회사 조직 체계와 연동하여 관리하기를 원하는 것이 그 시작입니다. 또한, AWS가 Landing Zone의 업그레이드 버전인 Control Tower 활용을 추천하고 있어, 그저 한 번 “사용해보고 싶다”는 고객들도 많습니다.

이러한 복수의 AWS Account가 존재하는 이유 중 하나는 기업의 글로벌 확장에 따른 해외 지사나 법인의 설립도 그 원인 중 하나가 됩니다. 특히, 일본에서는 리소스 관리 측면에서 혹은 보안적인 관점에서 이런 부분을 중시하고 있는 경향이 있습니다. 이는 각 지역의 요구사항과 규제를 준수하며 효율적인 관리와 운영을 가능하게 하는 중요한 요소입니다.

Organizations를 기반으로 Landing Zone / Control Tower는 잘 만들어진 서비스입니다. AWS의 다른 서비스들과 마찬가지로, Control Tower를 활용하기 위해서는 설정 작업과 운영 리소스 투입이 필수입니다.

AWS Account들이 수십 개에서 수백 개 상황이라면, Control Tower 도입을 추천합니다. 하지만, 단순한 트렌드를 기 위한 도입은 지양해야 합니다. 사내 보안 담당자를 통한 조직 관리 체계가 되어 있어야 합니다. 그래야 Control Tower에 적용할 기준이 마련됩니다.

조직 변경이 Control Tower에 반영되어야 하며, 이를 위해서는 Control Tower 담당이 회사 조직 내에 내재화되어 있어야 합니다. 회사 규정, 정책, 조직 구성, 연결, 역할, 권한 등이 유기적으로 연동되기 때문입니다.

그러므로, Control Tower 사용을 위해서는 다음과 같은 내용이 전제되어야 합니다.

보안 전문가가 조직 내에 존재한다.
조직 운영 방침과 AWS Account 간의 연동 요구사항이 명확하다.
AWS Control Tower 전담 조직이나 인원이 준비되어 있다.
조직 변경에 따른 Organizations / Control Tower 설정 업데이트가 가능하다.

이 정도 각 잡고 들어가지 않고, 몇 개의 AWS Account만을 가지고 Organizations / Control Tower를 도입한다는 것은, 오히려 배보다 배꼽이 더 클 수 있습니다.

복수의 AWS Account 끼리 어떻게 리소스 관리를 할 수 있을까요? 그리고, 인증 체계를 어떻게 가져가면 좋을까요? 이런 소규모 조직에서 AWS 리소스 관리와 인증 체계를 가볍게 가져갈 수 있는 방법을 알아보고자 합니다.

Within an Account

AWS 계정 별로 워크로드를 나누었을 경우, 각각의 인프라 환경이 독립적으로 분리되어 있기 때문에, 여러 계정 간의 직접적인 연동에 대해서는 별도의 고려가 필요하지 않습니다. 이러한 방식은 보안과 자원 관리 측면에서 큰 이점을 제공합니다. 각 계정이 이미 독립적인 경계를 가지고 있기 때문에, 하나의 계정에서 발생할 수 있는 문제가 다른 계정에 영향을 미치지 않으며, 비용 관리 및 청구 프로세스 또한 간소화됩니다.

이러한 각각 분리된 환경 내에서도 특정 IAM(Identity and Access Management) 사용자가 여러 리소스에 액세스 하려는 것을 통제해야 할 상황이 발생할 수 있습니다. 이 때, AWS의 AssumeRole 기능이 중요한 역할을 합니다. AssumeRole을 통해 사용자는 임시로 권한을 부여 받아 필요한 작업을 수행할 수 있으며, 이는 리소스에 대한 접근을, 보다 세분화하고 통제할 수 있는 방법을 제공합니다.

AssumeRole을 사용하는 데에는 주로 두 가지 접근 방식, RBAC(Role-Based Access Control)과 ABAC(Attribute-Based Access Control)이 있습니다. RBAC은 역할에 따라 사용자 권한을 지정하는 방식으로, 간단하고 직관적이며, 대규모 조직에서 광범위하게 사용됩니다.

예를 들어, ‘개발자’라는 역할에는 코드를 배포할 수 있는 권한이 주어질 수 있습니다. 반면, ABAC은 사용자의 속성이나 환경에 따라 권한을 동적으로 부여하는 보다 세밀한 접근 방식입니다.

예를 들어, 특정 프로젝트 태그가 붙은 리소스에만 접근을 허용하는 것이 가능합니다.

RBAC – Role-Based Access Control

RBAC는 사용자의 역할에 따라 접근 권한을 부여하는 방식입니다. 예를 들어, ‘개발자’ 역할에는 리소스를 생성하고 수정할 수 있는 권한이 있으나, ‘감사자’ 역할에는 리소스를 보는 것만 허용되는 권한 설정이 있을 수 있습니다.

아래는 RBAC 예제 입니다.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Action":[
            "ec2:Describe*",
            "s3:ListBucket"
         ],
         "Resource":"*"
      }
   ]
}

위 IAM 정책 예시는 사용자에게 EC2 인스턴스의 정보를 조회하고 S3 버킷 목록을 보는 권한을 부여하고 있습니다. 이러한 정책은 ‘감사자’ 역할에 적합할 수 있으며, 개발자나 관리자 역할에는 추가적인 권한이 부여될 것입니다.

ABAC – Attribute-Based Access Control

ABAC는 사용자의 속성(Attributes) 또는 환경 조건을 기반으로 접근 권한을 결정하는, 보다 세밀한 접근 제어 방식입니다. 이 방법을 사용하면 특정 프로젝트 태그나 사용자 속성에 따라 동적으로 권한을 조정할 수 있습니다.

아래는 ABAC 예제 입니다.

{
	"Version": "2012-10-17",
	"Statemetn":[
		{
			"Effect": "Allow",
			"Action": "se:*",
			"Resource": "arn:aws:s3:::example_bucket",
			"Condition": {"StringEquals":{"s3:ResourceTag/Project": "Project1"}}
		}
	]
}

이 IAM 정책 예시에서는 ‘Project1’이라는 태그가 붙은 S3 버킷 ‘example_bucket’에 대한 모든 작업을 허용하고 있습니다. 이는 특정 프로젝트 팀 또는 개인이 해당 프로젝트와 관련된 리소스에만 접근할 수 있도록 하여, 보다 미세한 권한 제어가 가능하게 합니다.

이와 같이 RBAC과 ABAC는 각 방식은 상황에 따라 장단점을 가지고 있습니다.

RBAC은 정책 관리가 비교적 단순하며 이해하기 쉽지만, 사용자의 역할이 다양해지고 복잡해 질수록 관리가 어려워질 수 있습니다. 반면, ABAC은 보다 유연하고 세밀한 권한 부여가 가능하지만, 정책 설정과 관리가 복잡해질 수 있습니다.

따라서, 조직의 특정 요구 사항과 운영 환경을 고려하여 두 접근 방식 중 적절한 방법을 선택해야 합니다.

Cross Account AssumeRole Access

사용자가 여러 AWS 계정의 접근을 운용할 필요가 있을 때, 각 계정 별로 별도의 신원과 인증정보를 모두 설정하는 것은 실용적이지 않습니다.

신원과 접근을 더욱 효율적으로 관리할 수 있는 몇 가지 방식이 존재하며, 이 섹션에서는 ‘Assume Role’ 방식에 대해 이야기 해보고자 합니다.

가장 단순하게, 두 계정을 예로 설명해 보겠습니다.

사용자가 이 두 계정에 접속해야 하는 경우, 각 계정에 IAM 사용자를 하나씩 생성하는 방식을 쉽게 생각해볼 수 있습니다. 처음에는 관리하기 어렵지 않아 보이지만, AWS 계정 수가 늘어난다면, 각각에 대한 인증 정보를 매번 생성해야 할 것입니다.이를 관리하는 것은 매우 버거운 일이 됩니다.

간단한 방안으로는 접속하고자 하는 계정에 IAM 사용자를 생성하고, 이 사용자에게 다른 모든 계정에 대한 접근 권한을 부여하는 방식이 있습니다. 이 방식을 사용하면, 처음 계정에서 사용자 이름과 비밀번호 한 쌍 만으로 관리가 가능합니다. AWS에서는 이런 방식을 ‘Assume Role’ 이라 부르며, IAM 사용자가 다른 계정의 역할을 가정하는 절차는 아래와 같이 진행됩니다.

계정 간 신뢰 관계는 역할을 가정하기 위한 필수 조건입니다. 위의 도표에서 보듯이, 사용자 인증정보를 담당하는 계정이 있고, 워크로드와 리소스를 관리하는 계정이 있습니다. 신뢰와 신뢰받는 계정의 관계성을 정해 보면 다음과 같습니다.

인증 계정 = 신뢰하는 계정
워크로드 계정 = 신뢰 받는 계정

이때, 인증 계정의 IAM 사용자는 워크로드 계정의 역할을 “가정”하여 STS의 AssumeRole API를 통해 리소스를 관리할 수 있게 됩니다. 참 쉽죠.

자, 실제 코드를 참고하면서 설정 작업 순서를 보면 다음과 같이 됩니다.

[설정 작업 순서]

인증 계정
1. 권한 정책을 생성합니다.
2. IAM 사용자를 생성합니다.
워크로드 계정
1. 역할을 생성합니다.
2. 신뢰 당사자를 설정합니다.
3. 권한 정책을 연결합니다.
확인
1. 역할을 전환합니다.

각 단계에서 좀 더 자세한 순서를 나열해 보면 다음과 같습니다.

[인증 계정]

사용자 관리자로서 인증 계정에 로그인합니다.
IAM 페이지로 이동하여 정책을 생성합니다.

JSON 형식의 정책을 입력하고 다음 단계로 이동합니다.

{
	"Version" : "2021-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": "sts:AssumeRole",
			"Resource": "*"
		}
	]
}

사용자를 생성하고 위에서 만든 정책을 연결합니다.

[워크로드 계정]

워크로드 계정에서는 관리자 권한을 가지고 있어야 하며, 인증해줄 계정 ID를 알고 있어야 합니다. 이 정보를 바탕으로 다음 단계를 진행합니다.

1. 워크로드 계정에 로그인하여 역할을 생성합니다.
2. 다른 AWS 계정으로부터 신뢰를 받을 수 있도록 설정합니다.
3. 필요한 권한 정책을 연결합니다.
```
{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Action": "s3:ListBucket",
			"Resource": "arn:aws:s3:::example_bucket/*"
		}
	]
}
```
4. 역할 생성을 완료합니다.

[확인]

IAM 사용자로 인증 계정에 로그인합니다.
콘솔 상단에서 역할 전환을 선택합니다.
워크로드 계정 ID와 역할 이름을 입력하고 전환합니다.
<AssumeRole name>@<workload account ID>와 같이 표시될 것입니다.
1. e.g. AssumedRole@123456789012

예상대로 설정이 완료되면, 역할 전환을 통해 워크로드 계정의 자원에 접근할 수 있게 됩니다. 설정한 권한 정책에 따라 워크로드 자원에 대한 접근이 확인되면, IAM 사용자 크로스 계정 접근 구성이 완료됩니다.

IdP with SAML 2.0

AWS 리소스 접근을 위하여 SAML 2.0 기반하는 외부 IdP 를 이용하여 접근하게 할 수도 있습니다.

쉬운 예로 Google Workspace 와 연동 방법을 가져와 봤습니다.

Google Workspace 설정
1. Google Admin Console에 로그인합니다.
2. 보안 > 사용자 인증 정보 > SAML 앱으로 이동합니다.
3. ‘SAML 앱 추가’를 선택하고 AWS SAML 애플리케이션을 설정합니다.
4. Google에서 제공하는 메타데이터 다운로드를 선택하여 IdP 메타데이터 파일을 저장합니다.
AWS에서 IdP 설정
1. AWS IAM 콘솔에 로그인합니다.
2. ‘신원 제공자’ 섹션으로 이동하여 ‘신원 제공자 생성’을 선택합니다.
3. 신원 제공자 유형으로 ‘SAML’을 선택하고, Google Workspace에서 다운로드한 메타데이터 파일을 업로드합니다.
IAM 역할 생성 및 정책 연결
1. Json
```
{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Principal": {
				"Federated": "arn:aws:iam:ACCOUNT-ID-WITHOUT-HYPHENS:saml-provider/
				},
				"Action": "sts:AssumeRoleWithSAML",
				"Condition": "{
					"StringEquals": {
						"SAML:aud" : "https://signin.aws.amazon.com/saml"
				}
			}
		}
	]
}
```
2. 위 IAM 정책은 Google Workspace에서 인증된 사용자가 특정 AWS 역할을 맡을 수 있도록 허용합니다.
3. AWS IAM 콘솔에서 ‘역할 생성’을 선택하고, SAML 2.0 페더레이션을 위한 역할 유형을 선택합니다.
4. 앞서 생성한 신원 제공자를 선택하고, 적절한 권한 정책을 역할에 연결합니다.
5. Google Workspace와 AWS 연결
  1. Google Workspace의 SAML 앱 설정에서, AWS에 대한 SSO 시작 URL, 엔티티 ID, ACS URL 등을 설정합니다.
  2. 사용자가 Google Workspace에서 AWS SAML 애플리케이션을 선택하면, AWS 콘솔에 SSO로 로그인할 수 있습니다.

마치며

지금까지 제시한 바와 같이, Organizations / Control Tower를 활용하지 않더라도 AWS 다중 계정 간의 접근 제어 및 외부 IdP를 활용한 인증 절차를 구현하는 것이 가능합니다.

Organizations / Control Tower 활용은 내부에 해당 분야의 전문가가 있고 AWS 시스템에 대한 깊은 이해를 바탕으로 지속적인 유지관리가 가능한 상황에서 진가를 발휘합니다. 이는 인력 배치와 추가 비용 부담을 수반합니다.

복수의 AWS 계정이 존재한다 하더라도, 먼저 간단한 접근 방식을 시도하고 이후 상황을 검토하여 Organizations / Control Tower 도입을 결정하는 것이 현명한 전략 일 수 있습니다. 이러한 접근 방식이 더욱 합리적이고 효과적인 관리를 가능하게 할 것입니다.

잊지 마세요. AssumeRole, RBAC, ABAC, IdP with SAML 2.0. 외우셨다면 OK.

참고

What is ABAC for AWS?
https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html
IAM tutorial: Define permissions to access AWS resources based on tags
https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html
AWSのABAC(タグに基づいたアクセス制御)の設計/運用のポイントを考える
https://dev.classmethod.jp/articles/aws-abac-tips/
AWS services that work with IAM
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html
AWS Cross Account Access – Assume Roles
https://www.linkedin.com/pulse/aws-cross-account-access-assume-roles-richard-lenan-zhao/
AWS Role Assumption Configuration
https://cloudstudio.com.au/2021/05/27/aws-roleassumption-configuration/

#AWS #Accout #IAM #RBAC #ABAC #Role

#일본 #Japn #일본동향 #일본진출 #Go-Japan #고재팬 #해외진출 #디지털여정 #MSP

📧 일본 IT 시장 정보를 한 눈에 Go-Japan 뉴스레터 📧

신청하신 분들께 월 1회, 무료로

일본 IT 업계 트렌드, 시장 진출, 시장 분석 인사이트를 담아 보내드립니다.

👇뉴스레터 신청하기👇

Written by 메가존클라우드 Cloud Technology Center, Global Pre-Sales Team, 이용진 (Yongjin Lee)

매달 마지막 주 수요일, IT 트렌드에 전문가 인사이트 더하기!

아잇팅 우리의 IT는 진행 중

IT 트렌드에 전문가 인사이트 더하기!