Cloud/AWS

[IAM] AssumeRole과 PassRole

Omoknooni 2024. 10. 19. 18:14

여러 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

사용자가 특정 작업을 수행할 때, AWS 리소스에 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가 프로젝트에 필요한 리소스에 접근할 수 있는 권한을 넘겨주게(PassRole) 된다.

 

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

 

 

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

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

 

 

보안

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

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

 

[CloudGoat] Scenario "lambda_privesc" - solution

시나리오 목표Full Admin 권한 획득 시나리오 세팅./cloudgoat.py create lambda_privesc User "Chris"의 Access Key와 Secret key가 주어지며 시작 Solution1. 주어진 User의 Role확인먼저 enumerate-iam과 같은 툴을 이용해

blog.omoknooni.me

 

 

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

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

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

 

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

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

 

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

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