AWS IAM 기초 (User, Role, Policy 생성)

 

AWS IAM

 

AWS IAM은 Identity and Access Management의 약자로

AWS 내의 자격 인증과 리소스에 대한 접근 제어를 통한 보안관리를 제공하는 서비스입니다.

 

IAM의 로고를 보면 뭐 같나요? 열쇠모양처럼 생겼죠?

맞습니다. IAM은 일종의 열쇠라고 보시면 됩니다.

요즘에는 열쇠 키를 잘 안 쓰니까 일종의 Face인증이라고 생각하면 편할 것 같습니다.

 

그러면 IAM의 특징을 알아볼까요?

 

1. Create and manage AWS users and groups

2. Manage permissions

3. Manage roles for entities

4. Federate users

5. Add conditions for fine-tuned access control

6. Audit service usage

 

키워드를 하나씩 살펴보겠습니다.

 

Create and manage AWS users and groups은 말 그대로

AWS의 User(사용자)와 Group(사용자 그룹)을 생성하는 기능을 제공한다는 의미입니다.

 

AWS의 IAM은 User를 만들어서 하나의 계정에

여러 명의 사용자가 리소스에 접근하는 것을 관리할 수 있도록 합니다.

또한, Group은 User을 그룹화하여 그룹단위로 권한을 부여한 후,

그룹에 속한 User는 그룹의 권한을 그대로 상속받아서 쓸 수 있도록 합니다.

 

Manage permissions은 어떤 리소스에 접근하는 권한을 IAM에서 컨트롤할 수 있다는 의미입니다.

하지만 내가 어떤 건물에 Face 인증이 등록되어 있어도

건물 입구에서 경비를 하시는 분이 출입을 통제할 수 있는 것처럼 

IAM에서 policy attachment를 통해 권한을 부여받았어도

Resource Based Policy를 통해 리소스의 접근이 통제 될 수도 있습니다.

 

User, Role and Policy

 

Manage roles for entities는 Role을 만들어서

User나 Service가 Assume하여 Role이 가진 권한을 가질 수 있도록 하는 기능입니다. (이게 뭔 개소리여)

Role을 한국어로 바꾸면 역할이죠? 일반적인 역할이란 단어를 생각해봅시다.

 

만약에 축구감독이라는 역할을 맡았다고 해봅시다. 그러면 어떠한 권한이 생기나요?

축구감독의 권한은 축구선수들의 출전 명단 작성, 포메이션 짜기, 전술전략 결정, 선수교체, 선수훈련 등등 다양한데,

축구감독이라는 역할을 맡는 순간 이러한 모든 권한을 가지게 됩니다. 

 

AWS에서 IAM의 Role도 동일합니다.

어떤 Role을 만들고 그 Role에 다양한 권한을 부여한 다음에 (policy attachment)

User가 그 Role을 맡게 되면 해당 Role에 부여된 권한도 가지게 됩니다.

User나 Service가 Role을 맡는 것을 Assume한다고 표현합니다.

(Assume의 여러 이미 중에 가장 적합한 '~인 체하다' 의 의미로 사용된 것으로 보입니다.)

 

Federate users는 좀 쉽게 표현하면 단체 인증이 가능하다는 특징입니다.

다른 말로 하면 다른 곳에서 하는 인증을 우리의 인증으로 인정해주겠다는 의미입니다.

만약 이미 회사 단체로 User 인증을 받았다고 하면 회사의 소속인 사람들이

같은 User 인증으로 인증이 가능하도록 하는 것입니다.

 

예를 들어 카카오라는 회사에 카카오 본사 건물 빌딩의 출입 인증을 주면,

카카오 직원이라 사원증을 받으면 따로 카카오 본사 건물의 출입 인증을 받지 않아도

카카오의 소속인 것이 본사 건물의 출입 권한을 부여하는 것과 동일한 효과를 주는 것으로 비유할 수 있을 것 같습니다.

 

Add conditions for fine-tuned access control는 권한에 여러가지 옵션을 붙일 수 있다는 의미입니다.

이를테면 회사 직원이면 건물에 출입할 수 있되,

출입구 5번으로만 출입이 가능하다 아니면 10시부터 5시까지만 출입이 자유롭다 등의

조건을 붙일 수 있는 것으로 비유할 수 있습니다.

 

마찬가지로 정책(Policy)의 Statement 내 Action에 다양한 권한을 정의할 수 있지만,

Statement 내 Condition에 여러가지 조건(특정 IP로만 접근해라, 특정 서비스를 통해서만 접근이 가능하다)

등을 통해 접근에 제약을 걸 수 있습니다.

 

Audit service usage은 AWS CloudTrail을 사용하여 AWS API에 대한 request 등을 추적할 수 있다는 특징입니다.

 

그러면 이제 User와 Role, Policy를 생성하는 것을 해보겠습니다.

(IAM에 대한 추가적인 내용을 다룰 때는 IAM Assume Role을 해보겠습니다.)

 

User 생성부터 해보겠습니다.

우선, AWS에 로그인을 하고 검색창에 IAM을 검색하여 IAM 메인화면으로 이동합니다.

 

IAM 메인 화면

 

보면 중간에 IAM 리소스라는 부분에 지금까지 IAM 리소스들이 몇개가 생성되어 관리되고 있는지

숫자를 확인할 수 있습니다. (이미 제가 테스트를 하면서 만들었던 사용자나 역할이 보이네요)

 

우선 User(사용자)부터 생성하기 위해 왼쪽 액세스 관리 밑에 사용자라고 된 부분을 클릭해봅시다. 

그러면 다음과 같은 User 메인 화면으로 이동합니다. (미리 모든 유저를 깨끗하게 지웠습니다.)

 

User Main

 

User는 메인화면에서 오른쪽 상단에 사용자 생성 버튼을 눌러서 User를 만들어봅시다.

(User라고 했다가 사용자라고 했다가 헷갈리게 해서 죄송합니다. 저는 User가 익숙합니다)

 

그 전에 하나만 보면 User 메인화면의 오른쪽 상당을 보면 글로벌이라고 쓴 부분이 보이시나요?

이 글로벌의 의미는 User나 Role, Policy같은 IAM 리소스는

region에 상관없이 모든 region에서 통용되는 리소스라는 의미입니다.

 

그러면 이제 User 생성화면으로 넘어가 보겠습니다.

 

User Create

 

왼쪽을 보면 3단계에 걸쳐서 User을 생성할 수 있는데,

우선 1단계에서는 User의 이름을 정할 수 있습니다.

user의 이름은 cloudman-bot-01이라고 만들어보겠습니다.

그리고 다음을 누릅니다.

 

User Create Step 2

 

User의 권한을 부여하는 단계가 Step2입니다. 아무런 권한을 안 주고 User을 만드는 것도 가능합니다.

하나씩 간단하게 살펴보면 그룹에 사용자 추가는

사용자를 특정 그룹에 속하게 만들어서 그룹이 가진 권한을 상속받게 하는 방법입니다.

다음으로 권한 복사는 이미 만들어진 User가 가진 권한을 복사하여 동일한 권한을 가지도록 하는 방법입니다.

마지막으로 직접 정책(policy) 연결은 aws에서 제공하는 정책이나

직접 custom으로 만든 정책을 User에서 붙여서 권한을 직접 부여하는 방법입니다.

 

그룹에 사용자 추가는 많은 수의 사용자 권한 관리에 유리하고

직접 정책 연결은 해당 사용자에게 특정 권한을 골라서 customizing하여 부여할 때 유리합니다.

 

우리는 아직 그룹을 만든 적이 없기 때문에 여기서 그냥 다음을 눌러 아무런 권한 설정도 하지 않고 넘어갑니다.

 

그러면 마지막 검토 및 생성 화면이 나오는데 이렇게 아무런 권한이 없이 사용자를 만드는 것인지 확인을 합니다. 

그러면 사용자 생성 버튼을 눌러서 아무런 권한이 없는 무능력한 User를 만들어봅시다.

 

User Create Step3

 

그러면 이렇게 만들어진 아무런 권한이 없는 무능력한 User를 리스트에서 확인할 수 있습니다.

 

User 생성 완료

 

쉽죠? 중간에 권한 설정에서 직접 권한 부여를 통해서 원하는 권한을 주어서

해당 리소스에 대해서 권한을 가진 action을 잘 수행하는지 테스트해 볼 수도 있습니다.

(하지만 여기서는 가장 기초적인 내용으로 User 생성만 해보고 넘어가겠습니다.)

 

그러면 이제 role을 생성해보겠습니다. Role 생성도 User 생성과 거의 유사합니다.

IAM 메인 화면(혹은 User 메인 화면)에서 역할이라고 쓴 부분을 클릭해봅시다.

그러면 아래와 같은 Role 메인 화면이 뜹니다. 

 

Role Main

 

이미 몇 가지 Role들이 생성되어 있네요.

우리는 따로 cloudman-role-01라는 이름을 가진 Role을 만들어봅시다.

오른쪽 상단에 역할 만들기를 클릭해 봅시다.

 

Role Create Step 1

 

Role을 생성하는 가장 첫 번째 단계는 신뢰할 수 있는 엔터티 선택입니다. 

역할이라는 것은 누군가 그 역할을 맡아야 비로소 의미가 있습니다.

하지만 아무나 그 역할을 맡을 수 있다면 안 되겠죠. (개나 소나 축구 국대 감독을 할 수 있는건 아닌 것처럼...)

 

그래서 그 역할을 맡을 수 있는 신뢰관계(Truested Relationship)라는 설정을 하게 됩니다.

신뢰관계는 쉽게 말해서

  해당 Role과 신뢰관계에 있는 특정한 User 혹은 Service가 Role을 맡을 수 있다 (Assume할 수 있다)

라는 의미입니다.

 

여기서는 AWS 계정을 선택해서 현재 계정에 소속된 어떠한 User나 Service 모두 Role을 사용할 수 있도록 하겠습니다.

그리고 다음을 클릭합니다.

 

Role Create Step2

 

다음 단계는 권한 추가입니다. User나 Role에 권한을 부여하는 방법은

권한에 대해서 정의가 되어있는 정책(policy)를 붙여서(attachment)

권한을 부여할 수 있습니다.

 

여기서 보이는 목록은 AWS에서 제공하는 서비스에 대한 권한을 정의한 기본 제공 정책(policy)들입니다.

물론 뒤에서 만들 custom policy를 붙이는 것도 가능합니다.

또한, 기본 제공 정책이 워낙 많기 때문에 검색도 할 수 있는데요, 

여기서 "ec2full"라는 키워드로 검색해서 나오는 다음 권한을 체크하고 다음으로 넘어갑시다.

 

Role Create Step 2

 

그러면 마지막 단계인 이름지정, 검토 및 생성에서

Role의 이름을 정하고 지금까지 결정한 신뢰관계나 정책을 체크하여 Role 생성을 마무리합시다.

 

Role Create Step 3

 

Role 이름은 cloudman-role-01로 정하겠습니다.

그리고 하나씩 살펴보면

 

Role Trusted Relationship

 

아까 현재 계정을 신뢰관계의 대상으로 선택했기 때문에

JSON 양식으로 된 신뢰정책에서 이 내용을 확인할 수 있습니다.

 

Policy Attachment

 

또, 2단계에서 우리는 EC2에 대해서 모든 권한을 가진 policy를 붙였기 때문에 이렇게 권한이 부여된 것을 확인할 수 있습니다.

3단계는 태그 추가인데 따로 태그를 추가하지 않을 것이기 때문에 바로 역할 생성을 눌러서 Role을 생성합시다.

 

Tagging

 

그러면 이렇게 우리가 만든 cloudman-role-01이 잘 만들어진 것을 리스트에서 확인할 수 있습니다.

 

IAM Role List

 

그럼 마지막으로 정책(Policy)을 만들어 봅시다.

왼쪽에 있는 메뉴에서 정책을 클릭해봅시다.

그러면 정책 메인화면으로 이동합니다.

 

Policy Main

 

보시는 바처럼 이미 많은 AWS 기본 제공 Policy들의 리스트를 확인할 수 있습니다.

그러면 오른쪽 위에 정책 생성 버튼을 눌러서 정책 생성 화면으로 넘어갑니다.

 

Policy Create Step 1

 

정책 생성의 1단계는 바로 권한 지정입니다. (사실 이게 정책의 전부입니다.)

AWS의 어떤 서비스에 대해서 어떠한 권한을 지정할 것인지에 대해서 결정하는 부분입니다.

 

정책 편집기 라고 쓰긴 곳에서 오른쪽을 보면 시각적, JSON이라고 된 부분을 확인할 수 있는데요.

JSON을 작성하여 권한을 부여하는 것도 가능합니다.

하지만 지금은 가장 쉬운 방법으로 권한 부여를 하기 위해

클릭으로 권한을 부여해보겠습니다. 

밑에 AWS의 여러 서비스들이 보이는데요, EC2라고 된 부분을 클릭해서 EC2의 권한을 부여해봅시다.

 

Policy Step 1

 

액세스 수준을 보면 나열과 관련된 권한이 168개, 읽기와 관련된 권한이 31개 등이 있는 것을 확인할 수 있는데요.

우리는 여기서 나열의 권한을 모두 부여해봅시다.

나열을 클릭하고 다음과 같이 모든 나열 작업이라고 된 체크박스를 체크하여

나열의 168개의 권한을 모두 부여합니다.

 

Check EC2 List

 

밑으로 스크롤을 내리면 다음과 같이 리소스, 요청 조건이라는 부분이 나오는데요.

 

 

여기서 리소스라는 것은 실제 생성된 리소스들 중에서 어떤 리소스를 대상으로 할 것인가를 선택하는 부분입니다.

만약에 이미 만들어진 EC2 instance가 있다면 해당 EC2의 arn을 넣어서 해당 EC2 instance 한정으로 권한을 설정할 수 있습니다.

여기서는 모두를 선택해서 모든 EC2 instance을 대상으로 권한을 부여하도록 하겠습니다.

 

여기서 빨간 글씨로 모든 와일드카드, 즉 모든 리소스를 대상으로 권한을 부여하는 것은

지나치게 많은 리소스에 대해서 권한을 부여하여 (보안 상) 문제가 될 수 있다고 경고합니다.

사실 보안을 생각하면 *보다는 특정 리소스로 제한하는 것이 더 좋고,

특정 리소스로 제한하는 것이 어렵다면 요청조건에서 제한을 하는 방법도 있습니다.

(둘 다 쓰는 방법도 있습니다.)

 

또한, 요청 조건은 아까 앞부분에서 언급했던 권한에 여러가지 옵션을 붙이는 부분입니다.

여기서는 아무런 조건도 붙이지 않고 바로 다음을 눌러 넘어갑시다.

 

Policy Create Step 2

 

1단계가 끝나자마자 바로 마지막 단계인 검토 및 생성 단계인데요. (단계는 적은데 1단계가 어렵다는...)

정책의 이름을 cloudman-policy-01로 정합니다.

그리고 하나씩 보면

 

 

이 정책에서 정의했던 EC2를 나열하는 모든 권한을 부여한 것을 확인할 수 있고

리소스도 모든 리소스로 설정된 것을 확인할 수 있습니다.

그 다음은 태그 추가인데 태그 추가 없이 바로 정책 생성을 눌러서 정책 생성을 완료해봅시다. 

 

 

정책 생성을 눌러서 정책 생성을 완료하게 되면 

다음과 같이 우리가 만든 커스텀 정책인 cloudman-policy-01이 다른 기본 제공 정책들과 같이

정책 리스트에서 조회할 수 있게 됩니다.

 

Policy Create Complete

 

이렇게 IAM의 주요 리소스인 User, Role, Policy를 AWS Console에서 생성해보았습니다.

 

나중에 IAM의 추가적인 내용에서 role을 assume하는 방법이나 policy에 condition을 설정하는 방법,

다른 클라우드의 인증과 Federation하여 다른 클라우드에서 AWS 리소스에 접근하거나 

AWS의 Role을 가지고 다른 클라우드 리소스에 접근하는 등의 다양한 IAM 활용에 대해서 다뤄보겠습니다.