[IAM] AssumeRole과 PassRole

여러 AWS 서비스에서는 사용자를 대신해서 작업을 실행하기 위해 IAM Role을 부여한다. 

그 과정에서 AssumeRole과 PassRole을 자주 볼 수 있는데, 이 둘은 간혹 보면 햇갈리는 점이 있다.

이번에는 이 둘이 각각 어떤 기능이고, 어떤 차이점이 존재하는 지 알아보도록 한다.

 

AssumeRole

한 IAM Role이 다른 Role의 권한을 일시적으로 가져와서 사용할 수 있도록 하는 기능

AssumeRole은 IAM이 아닌 STS(Security Token Service)라는 서비스의 Action으로 분류된다.

 

Assume Role을 통해 User/Role은 자신에게 부여된 권한을 넘어 다양한 추가 권한을 임시로 얻어서 누릴 수 있게 된다.

더불어, AssumeRole은 동일한 계정 내의 Role 뿐만 아니라 다른 계정의 Role을 가져와서 사용할 수도 있다.

AssumeRole을 통한 임시 Token발급과 사용

 

 

AssumeRole은 아래와 같은 간단한 비유로 설명할 수 있다.

인프라 엔지니어 직무를 수행하는 A는 회사의 긴급한 개발프로젝트에 투입된다.
이를 위해 회사는 A에게 개발팀의 역할(권한)을 임시로 부여하게 되었다.
이후 개발프로젝트가 마무리되면 A는 다시 원래 직무를 수행하기 위해 돌아가게 된다.

 

→ 타 권한의 임시 사용

 

 

PassRole

리소스가 특정 작업을 수행할 때, 사용자가 리소스에 자신이 가진 Role을 전달해주기 위한 권한, 직접 수행하는 것이 아닌 권한을 넘겨주는 중개자 역할

서비스나 작업에 특정 역할을 할당하는 작업을 수행하는 경우에 사용된다.

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "Statement1",
			"Effect": "Allow",
			"Action": "iam:PassRole",
			"Resource": [
				"arn:aws:lambda:ap-northeast-2:123456789012:function:role_test"
			]
		}
	]
}

 

 

예를 들어, EC2 인스턴스와 Lambda에 Role을 할당하는 경우에 PassRole이 필요하다.

PassRole이 Deny된 Policy에 대해 Lambda에 Role 업데이트가 제한된 모습

 

PassRole은 다음과 같은 비유를 들 수 있다.

팀장이 외부 직원 B에게 새로운 프로젝트를 참여시키게 되었다.
B가 새로운 프로젝트를 수행함에 따라 팀의 영역(회의실 등)에 접근할 수 있어야하는데,
이때 팀장은 B가 팀의 영역에 접근할 수 있도록 자신의 출입증을 B에게 넘겨주게(PassRole) 된다.
이렇게 B는 팀장의 출입증을 통해 팀의 영역으로 들어가 프로젝트를 진행하고, 끝나면 반납하게 된다.

 

→ 내가 가진 권한을 다른 주체에게 전달

 

 

결과적으로 두 권한의 기능과 차이점은 아래와 같다.

권한	sts:AssumeRole	iam:PassRole
기능	다른 Role의 권한을 일시적으로 가져와서 사용	리소스에 특정 Role을 넘겨주는 기능
시나리오	계정간의 권한 공유, 임시권한 획득 등	EC2, Lambda, ECS 등의 서비스에 Role을 전달

 

즉, AssumeRole은 스스로 다른 Role로 전환하는 것이고, PassRole은 자신의 역할을 다른 주체에게 위임해주는 것이다.

 

보안

이렇게 AssumeRole과 PassRole은 'Role'을 통해 권한을 조작한다는 점에서 항상 주의하며 사용할 필요가 있다.

대부분의 CloudGoat 문제에서 AssumeRole을 통해 Role의 Token을 발급받아 사용하는 방식으로 Exploit이 구성되어있었다.

[CloudGoat] Scenario "lambda_privesc" - solution

 

 

PassRole 역시 악용하는 시나리오를 작성해 볼 수 있다.

SSM ParameterStore로부터 GetParameters를 수행해 실행되는 Lambda가 있다고 가정하자.

아래같이 Policy가 지정된 User는 SSM ParameterStore에 직접 접근할 수 없다. (Policy에 명시적으로 지정하지 않았음)

 

이 상황에서, PassRole에 대한 Statement가 추가되었다고 가정해본다.

그렇다면 User는 새로 Lambda 함수를 생성하고(lambda:*), ParameterStore에 Access하는 Role을 연결해(iam:PassRole) Lambda를 통해 ParameterStore의 값을 읽어올 수 있게된다.

 

다방면에 대해 보안 설정을 철저하게 했더라도, 이러한 권한 설정 하나만 놓치게 되면 모두 무너지게 된다.

권한 설정에서 언제나, 그 무엇보다도 중요한 것은 "최소한의 권한만 부여"하는 점을 명심하도록 하자