[AWS] IAM에서 사용하는 객체들

IAM에서 사용하는 객체들 

IAM에서 사용하는 객체는 크게 두 가지 영역으로 구성되어 있다. 

하나는 사용자를 정의하는 IAM User, IAM Group, IAM Role 영역이고, 다른 하나는 각 사용자의 권한을 정의하는 IAM Policy 영역이다. 

사용자와 권한은 1:N으로 매핑되며, 

IAM User + IAM Policy(s), 

IAM Group + IAM Policy(s), 

IAM Role+IAM Policy(s) 

형태로 각 단위 객체에 권한을 붙여 사용하게 된다.

루트 계정과 IAM 객체

앞서 하나의 AWS 계정을 만들었따. 이 계정을 루트 계정(Root Account)라고 부른다.

루트 계정은 이 계정 내에서 할 수 있는 모든 행위에 대한 권한을 태생적으로 갖고 있는 계정이다. 사용자는 앞으로 이 AWS계정 내에서 네트워크를 구성(VPC)하고, 가상 서버(EC2)을 올리고, 스토리지(S3) 등을 만든 후 이들을 조합하여 하나의 커다란 서비스 뭉치를 만들 예정이다. 예를 들어, 이 서비스를 하나의 모바일 게임이라고 칭하고,

이 모바일 게임에 투입되는 인원의 성격은 매우 다양하다. 개발자, 테스터, 네트워크 운영, 인프라 운영, 보안담당자 등은 고유의 역할이 있고, 이들은 하나의 AWS 계정 내에서 각각의 역하을 제한적으로 수행해야 한다.

이 때, 이 모든 인원이 하나의 루트 계정을 공용으로 사용한다면 어떤 일이 벌어질까?

역할 범위를 넘어서는 권한이 모든 사용자에게 주어짐으로써 발생할 수 있는 인적 실수(Human Error)의 가능성은 없을까?

그리고 어떤 작업을 어느 사용자가 수행했는지에 대한 추적(Cloudtrail에서 기록) 또한 가능할까?

보안적인 관점에서 다음과 같은 내용이 수행되어야 한다.

1. 역할에 따라 사용자가 엄격하게 분리가 되어야 함.

2. 해당 사용자에게는 업무수행에 필요한 최소한의 권한만 부여

IAM User의 분리

하나의 AWS 계정 내에서 분리된 하나의 사용자 단위를 IAM User라고 부르고, 제한된 권한을 부여하기 위한 단위 권한 객체를 IAM Policy라고 부른다. 즉, 하나의 AWS 계정 내에는 모든 권하능ㄹ 가진 하나의 루트 계정과 다수의 IAM User, 그리고 다수의 IAM Policy가 존재하게 된다.

여기서 잠깐 Q&A Q. AWS에서는 보안상의 이유로 가급적 Root Account를 사용하지 않을 것을 권고하던데, 그럼 반드시 Root Account를 사용해야만 하는 특수한 경우가 있나요? A. 반드시 Root Account의 권한을 사용해야만 하는 상황이 몇몇 존재한다. 예를들어, EC2를 기반으로 또는 대상으로 수행하는 보안 침투테스트 고지, 특정 EC2의 TCP 프로토콜 25번 포트 사용 제약사항 해제 신청, ColudFront 전용 인증키 페어 생성등의 작업들은 반드시 Root Account로만 신청이 가능하다. 즉, IAM User로는 어떤 권한을 부여하더라도 위의 작업들을 수행할 수가 없기 때문에 Root Account는 일반적으로는 사용하지 않지만, 이런 상황을 대비하여 별도로 엄격한 절차에 따라 인증 정보를 관리해야 한다.

IAM User, Group, Role

IAM User를 만들고 나면 해당 IAM User의 인증 방식을 설정할 수 있다. 하나는 AWS Management Console 로그인용으로 사용하는 username/password 방식, 다른 하나는 AWS CLI나 AWS SDK에서 필요한 인증키쌍(Accesskey/Secretkey) 방식다.

필요에 따라 둘 중 하나만 사용할 수도 있고, 두 가지 모두를 사용할 수도 있다.

각 IAM User에는 하나 또는 하나 이상의 IAM Policy 객체를 연결(mapping)하여 권한을 정의한다.

IAM Group 도입 전후

IAM Group은 단순히 IAM User를 집합 단위로 묶어 권하능ㄹ 통합 관리하기 위해 만들어진 개념이다.

만일 위 그림과 같이 동일한 권한을 사용하는 IAM User의 집합이 있다고 하자. 기존 방식처럼 각각의 IAM User를 넣어놓고, IAM Group에 붙은 IAM Policy를 참조하여 사용하도록 구성할 수도 있다. 참고로 하나의 IAM User는 복수의 IAM Group에 속할 수도 있다.

IAM Role 동작 흐름

IAM Role의 개념은 조금 복잡하다. 먼저 믿을 수 있는 객체(Trusted Entities)가 API Call이 필요할 때마다 일정 주기로 STS 서비스에 임시키를 요청한다. STS 서비스는 요청한 객체가 믿을 수 있는 객체인지 확인하고 임시키를 발급한다. 여기서 발급된 임시키는 지정된 유효시간을 가지며 시간이 경과된 후에는 무효화되므로 IAM User에서 사용하는 영구키 인증키쌍에 비해 보안성이 높다. 그리고 마지막으로 임시 인증키쌍을 사용하여 API Call을 수행한다.

여기서 잠깐 Q&A Q. IAM Role의 개념이 명확하게 잘 이해되지 않습니다. IAM Role이 사용되는 실제 예시를 알고 싶습니다. A. IAM Role은 외부 인증과 연동하는 경우에 주로 사용된다. 예를 들어, 다른 AWS 정의 인프라를 활용하여 서비스하는 모니터링 서비스가 있다고 하자. 이 때 내가 사용하고 있는 AWS 계정내의 각종 모니터링 수치를 다른 AWS 계정에 백데이터로 제공해야 한다. 이때 사용되는 것이 IAM Role이다. IAM Role을 하나 만들어 데이터를 제공할 AWS 계정의 ID와 IAM Policy를 통해 제공할 정보의 범위를 정의하면, 별도의 IAM User 새생성 없이도 손쉽게 내 계정의 리소스 정보를 타 AWS 계정 객체에게 전달할 수 있다.

IAM Role의 또 다른 활용 예로는 AWS 서비스간 권한을 제어하는 경우이다. 예를 들어, 특정 EC에서 지정된 S3버킷에 주기적으로 접근하여 객체 읽기와 쓰기를 수행한다고 하자, 

이때 EC2내에 IAM User의 인증키쌍을 입력하지 않고 IAM Role을 정의해 놓으면 별도의 인증정보 없이(임시 인증값을 주기적으로 재생성하는 방법으로) S3 접근 권한을 정의할 수 있다.

믿을 수 있는 객체(Trusted Entities)로 정의할 수 있는 대상은 여러 가지가 있다. 

다른 AWS 계정이 될 수 도 있고, EC2와 같은 AWS 단위 서비스가 될 수도 있다. 또한 외부 자격증명 공급자(Amazon, Google, MS Active Directory)와 IAM Role을 연동하여 기존 외부자격 증명 공급자에 인증된 사용자에게 AWS 계정과 관련된 권한을 부여할 수도 있다.

Root Account와 IAM User, IAM Role의 항목별 특징은 다음과 같다.

Root Account, IAM User, IAM Role 비교

IAM Policy

IAM Policy는 IAM User, Group, Role의 권한을 정의하는 객체이다. 

JSON 포맷을을 사용하며 하나의 IAM Policy에는 다음과 같은 항목을 포함한다. 

다음의 예제는 모든 사용자(Principal)가 examplebuket(Resource)에 리스팅, 업로드, 다운로드의 작업(Action)을 허용하거나 거부(Effect:Allow) 하는 정책 예시이다. 

또한 Condition이라는 항목을 통해 "54.240.143.0/24"의 IP대역에서는 Bucket 접근을 허가하고, 

"54.240.143.188/32" 의 IP에서는 접근을 거부하도록 정책을 구성하였다.

S3 관련 IAM Policy 예시

IAM Policy 객체의 종류 

IAM Policy 객체는 크게 Management Policies와 Inline Policies로 분류되며, 이식성이 좋고 버전 관리 기능을 제공하는 Managed Policies 사용을 가급적 권장한다. Managed Policy에는 AWS에서 기본적으로 제공하는 권한 묶음인 AWS Managed Policy와 사용자가 직접 권한을 정의하여 사용하는 Customer Managed Policy가 있다.