[AWS] IAM과 Role, Policy

IAM

항상 나는 AWS에 로그인할 때 루트 유저로 로그인했었다.

 

로그인 화면

 

책이나 다른 실습 강의에서는 항상 루트 사용자로 로그인했었기에, 그냥 그런가보다 하고 넘겼었다.

 

하지만 AWS에 점점 익숙해지면서, 그리고 로그인을 하면서

 

밑에 있는 IAM 사용자 로그인은 무엇일까? 라는 궁금증이 자연스레 생기게 되었다.

 

계정 ID를 확인할 수 있다.

 

AWS 계정은 모두 고유한 12자리의 ID값을 갖는다.

 

AWS의 공식 가이드에 따르면, 서비스의 성숙도와 상관없이 루트 사용자를 사용하는것을 권장하지 않는다.

 

 

위의 메뉴에서 보안 자격 증명탭을 누르면 자연스럽게 IAM 페이지가 나오는데, 사용자 탭이 있는걸 볼 수 있다.

 

IAM의 구성요소

IAM의 구성요소로는 크게 4가지가 있다.

 

• Group : 사용자 그룹을 나타낸다. 사용자 그룹마다 Policy를 설정할 수 있다.
• User : 사용자를 나타낸다. 사용자는 Policy를 가지거나 여러개의 Policy가 설정된 Role을 Assume할 수 있다.
• Role : Policy들을 모아놓은 Role이다.
• Policy : 어떤 리소스에 어떤 액션을 취할 수 있는지 정의해놓은 Policy이다.

구성요소들에 대해 천천히 알아보자.

사용자

AWS 계정에는 여러 명의 사용자가 있을 수 있다.

 

일반적으로 생각해보면, 회사에서는 회사의 AWS 계정을 사용할 것이다.

 

회사안에서도 로그 수집 및 분석을 위한 부서, 인프라 관리 부서, DBA등 각자 담당하는 분야가 다를것이다.

 

이 모든 사람들이 하나의 루트 계정으로 AWS를 이용하면 안될거란 느낌이 강하게 든다.

 

분야가 다르다는것은 자기 분야가 아닌 다른 분야의 리소스를 제어할 필요가 없다는 뜻으로 바뀐다.

 

따라서 사용자를 구분할 필요가 있다.

 

보다 정확하게는 사용자 그룹을 DE, Infra, DBA등으로 구분해야 한다. 

 

각 부서내에서도 직급별로 권한이 다를 수 있으므로 사용자 그룹에 사용자들을 다시 생성한다.

 

루트, 사용자 그룹, 사용자를 도식화

그림을 보면 사용자 1과 2는 DE와 Infra 사용자 그룹에 모두 속해있다.

 

이렇게 사용자와 그룹은 N:M 관계를 가질 수 있다.

 

 

현재 나는 test 그룹에 속한 imsong.kk 라는 사용자를 생성했다.

 

ARN과 MFA, 권한이 눈에 띈다.

 

• ARN : Amazon Resource Name의 준말로, AWS 리소스를 식별할 수 있는 고유한 이름이다.
• MFA : Multi Factor Authentication으로 OTP나 SMS등으로 2차 비밀번호를 설정한다.

권한에 대해서는 밑에서 알아보자.

 

권한

권한 정책을 살펴보면 2개의 정책이 있는것을 볼 수 있다.

 

권한은 해당 사용자가 가지고 있는 Policy들을 나타낸다.

 

정책(Policy)

Policy는 하나 이상의 AWS 리소스에 대한 가능한 작업들을 명시해 놓은 json 형식의 파일이다.

 

정책은 사용자, 사용자 그룹, 역할(Role)에 연결될 수 있다.

 

AWS 관리형과 고객 관리형 정책으로 나뉜다

AWS 관리형 정책은 AWS에서 미리 정의해놓은 정책이며,

 

고객 관리형은 내가 직접 정의할 수 있는 정책이다.

 

AdministratorAccess 정책을 살펴보자.

 

 

정책도 리소스의 일종으로 고유한 ARN을 가지고 있는것을 볼 수 있다. 하단에는 정책을 구성하는 json 파일이 있다.

 

관리자 정책이므로 모든 리소스와 모든 행동들이 Allow 된다.

 

여기까지 알아봤을 때 하나 빼먹은게 있다! 바로 역할(Role)이다.

 

역할(Role)

역할은 정책들의 모음으로 이해할 수 있다.

 

흔히 모자라고도 비유되곤 하는데, 해당 모자를 쓰는 사람은 모자에 담긴 정책들을 그대로 가질 수 있다.

 

이때 모자를 쓸 수 있는 사람은 AWS 계정뿐만 아니라 AWS 리소스가 될 수 있다.

 

권한(Policy List)를 갖는다는점에서 사용자와 비슷하지만, 역할은 모자이므로 여러곳에서 빌려쓸 수 있다.

 

 

위의 그림에서 나오는 신뢰할 수 있는 개체가 곧 모자를 쓸 수 있는 사람인데,

 

서비스와 계정이 같이 존재하는것을 볼 수 있다. 이는 사전에 지정을 해주어야 한다.

 

AWSServiceRoleForeAmazonEKS 역할을 살펴보자.

 

이 모자는 이런 Policy를 가진다.

신뢰 관계탭을 살펴보자.

이 모자는 EKS 서비스만 쓸 수 있다

 

Principal에 eks 서비스가 등록된것을 볼 수 있다.

 

Principal은 해당 Role에 대해 요청할 수 있는 주체를 의미한다.

 

이때 Action에는 그동안 못보던 sts 라는 녀석이 등장하는데 이것은 무엇일까?

 

sts

sts(Security Token Service)는 AWS 리소스에 대한 액세스를 제어할 수 있는

 

임시 보안 자격 증명을 생성해주는 서비스이다.

 

모자를 쓰는, Assume Role은 무조건 sts를 이용해야만 동작한다.

 

IAM User에게 정책을 설정하는건 유효기간이 없는 자격증명이지만,

 

Assume Role을 이용하면 임시 자격증명만 가질 수 있다.

 

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_credentials_temp.html

IAM의 임시 보안 자격 증명 - AWS Identity and Access Management

AWS 공식 문서에 따르면

 

sts를 사용해 임시 자격증명을 생성하게 되면 AssumeRole을 할 수 있고,

 

애플리케이션은 더이상 IAM User의 정책들을 영구적으로 가지고 있을 필요가 없으므로 보안상의 이점이 있다.

 

sts라는 이름에서 알 수 있듯이, AWS는 JWT를 통해 expired 시간을 관리한다.

 

위에서 봤던 Role이다.

 

다시 이 Role을 들여다보면 eks 라는 AWS 리소스(서비스)에게 해당 Role에 부여된 정책을 사용할 수 있게

 

sts를 이용해 AssumeRole을 허용한다는 뜻이다!

 

결론

AWS IAM은 이 Role을 얼마나 잘 다루냐가 중요하다.

 

사용자뿐만 아니라 AWS 각 리소스들마다도 사용자들처럼 적절한 권한 설정이 있어야

 

리소스가 망가지지않고 안전한 인프라를 구성할 수 있다.