AWS identity and access management(IAM)

IAM 서비스
조직의 규모가 커저서 계정을 관리하는 관리자가 모든 자원을 관리하는것이 아니라 개발자가 스스로 리소스를 만들고, 컨트롤을 해야할 정도로 기업이 클 경우에 반드시 필요한 서비스이다. AWS 계정을 가지고 있다면 보안을 위해서 반드시 IAM을 사용해야한다.
인증과 접근관리, 권한제어에 대한 서비스를 의미한다.

AWS에서 계정을 생성하게 되면 최초로 나오는 계정은 ROOT 즉 모든 권한을 가진 루트 사용자가 생성된다. 모든 AWS 서비스 및 리소스에 대한 전체 액세스 권한을 가지고 있으며, 결제정보, 사용자의 개인정보 등 모든 정보를 볼 수 있으며, 모든 권한을 가지고 있다. 모든 권한을 가지고 있기 때문에 타인에게 이 계정이 넘어가게 된다면 통제할 수 없을 정도로 강력한 권한이기에 반드시 계정에 대한 보안을 신경써야한다.

AWS 계정 해킹에 대한 각종 사례

그렇기에 AWS 계정(AWS에서의 계정은 Root만을 의미한다.)을 생성 후 가장먼저 root계정으로 관리자가 사용할 계정을 생성한다. 이 후 root계정의 루트 사용자 자격 증명 잠금을 활용해 계정을 잠궈둔다. 이 후 IAM 관리 사용자를 사용해 접근을 하도록 한다.

 

IAM을 사용하기 위해서는 세분화된, 최소한의 권한(개발팀에서는 개발만을 위한 계정, 테스트팀에서는 테스트만을 위한 계정 등의 구체적이며 명확한)을 부여할 수 있어야 한다. SDK(Software Development Kit), 콘솔, CLI 등에서 사용할 수 있다. IAM의 사용자는 말 그대로 AWS의 리소스를 사용하는 사용자-server, app, user 등-을 의미한다. 다른 aws서비스와 통합할 수 있으며, 연동 자격 증명을 관리할 수 도 있다. 에플리케이션의 안전한 액세스를 할 수 있기도 하다.

 

IAM의 보안주체는 IAM 사용자, 연동 사용자(다른 인증환경으로부터 인증 받아 들어온 사용자), IAM Role(특정 역할을 특정 기간동안 부여받은 사용자 = 유효기간이 있는 임시권한을 특정 사용자에게 부여), 자격 증명 공급자(IdP,. amazon, facebook 등...)가 있다.

 

IAM 사용자

계정이 아니고 계정 내 사용자를 의미한다. 각 사용자는 자체적인 자격 증명을 가지고 있다. IAM 사용자가 가지고 있는 기본 권한은 아무것도 없으며 사용자를 만들때에는 콘솔에 엑세스할 사용자를 만들것인가 혹은 CLI 에 대한 엑세스는 명시적으로 부여되어 있어야 한다.

 

이때 정책을 활용하여 권한을 부여할 수 있다. 

하나 이상의 권한에 대한 형식(거부, 허용 등)을 선언하는 파트이며, 요청 시(외부에서 신호를 받았을 때)에 평가할 수 있다. IAM정책은 AWS 서비스 에 대한 액세스(DB에 특정 쿼리만 보낸다. 와 같은 제어(DB계정이 해야하는 작업)는 할 수 없다.)만 제어한다. IAM에는 하이퍼바이저에 대한 가시성이 없다.(어차피 하이퍼바이저 위에서 구동되는 서비스 이기에)

 

평가방법은 아래와 같다.

1. 명시적으로 거부되어 있는가?  ==> 거부되어있으면 종결

2. 명시적으로 허용이 되어 있는가? ==> 허용이 되어있으면 들어올 수 있게하고, 아무런 권한이 없으면 거부를 한다.

* 특정 리소스는 허용/거부 둘 다 되어있을 수 있는데, 이때는 거부를 우선순위로 하여 허용 권한이 있더라도 차단한다.

이렇기에 최초로 사용자를 생성하게 되면 아무런 행동을 할 수 없는 것 이다.

 

정책은 크게 연결된 AWS 리소스를 기반으로하는 리소스기반, 연결된 IAM 보안주체를 기반으로 하는 자격 증명 기반으로 나뉘어진다. 어디에 선언되어있으며, 어디에 만들어져있는가에 대한 차이이다. 

리소스 기반 정책은 주로 운영체제의 권한정책을 할때 주로 리소스 기반정책을 활용한다. 또한 S3의 버켓정책문서(json 문서)와 IAM 문서는 굉장히 유사하다.

 

리소스 기반 정책은 아래와 같이 나뉘어 진다.

연결대상	제어
AWS 리소스 Amzon S3 Amazon SQS Amazon S3 Glacier AWs KMS 등	특정 보안 주체에게 허용한 작업을 한번 더 제어 ==> 어떤 요청을 보내는 보안 주체가 사전에 권한을 가지고 있더라도, 리소스 기반 정책에 의해 필터링을 한 번 더 받는다. ==>  권한이 없는 보안 주체가 접근을했는데, 리소스 기반 정책에 허용되어있다면, 접근을 허용한다.
	필요한 조건
	항상 인라인 정책 ==> 만들어져있는 정책이 없기에 항상 작성을 한다.
	AWS 관리형 리소스 기반 정책이 없음.

자격 증명 기반 정책은 3가지로 나뉘는데 아래와 같다.

연결대상	정책유형	제어
사용자	aws관리형(문서화되어있음)	수행 작업
그룹	고객관리형(문서화해야함)	리소스 대상
역할	인라인	필요한 조건

 

정책을 연결시키는 사용자는 어떻게 관리를 할 수 있을까?

 

권한제어를 할때는 직접 사용자에게 정책을 연결시킬 수 도 있다. 단 이렇게 되면 권한관리가 잘 안되는 경우가 허다하다.

이럴 경우 인사관리를 할 때마다 모든 권한을 변경해야하는 번거로움이 발생하게 된다. 그렇기에 하나의 IAM 사용자 그룹을 생성해 관리를 한다.

 

IAM 사용자 그룹

특정 그룹을 만들고, 그룹에 필요한 정책을 그룹에 연결시킨다. 이 후 사용자들을 그 그룹에 포함시킨다. 그렇게 되면 그룹에 연결된 정책이 사용자들에게 상속이 되며, 필요한 권한이 그룹의 사용자들에게 속하게 된다. 이 후 인사이동이 발령된다면 다른 그룹으로 사용자를 옮기기만 하면 특별히 관리를 할 필요가 없어 진다.

 

IAM 역할

사용자를 생성(영구적으로 자격을 증명)하고싶지 않을 때, 다른 그룹간에 사용자를 계속 푸시/풀링(데브옵스 개발자가 개발그룹에 있다가 테스트 그룹으로 이동해 테스트를 한 후, 피드백을 가지고 다시 개발그룹으로 넘어오는 등의 경우)을 하지 않을 경우와 같은 임시권한을 부여할 때 사용한다.

우선 역할을 만든 후, 부여하고자 하는 정책을 역할에 연결한다. 이 후 역할을 요청할 수 있도록 사용자 혹은 보안주체에게 권한을 부여한다. 그렇게 된다면 보안주체가 권한이 필요할때마다 역할을 요청하게 된다. 역할이 부여받게 되면 기존의 자격 증명과 교체가 되어 동작하게 된다. 즉 그룹간의 이동과 비슷한 효과가 발생하게 된다. 또한 유효기한이 있는 임시 자격증명이 발생되기에 외부에 유출이 되더라도, 기한이 지난 후에는 역할을 사용할 수 없게된다.

AWS 리소스에 AWS 서비스에 대한 접근(액세스)를 제공하고 싶을때 사용할 수 있다.

 

AWS Management Console(콘솔), AWS CLI(명령줄)은 AWS Security Token Service(AWS STS) 쪽으로 AssumeRole API 라는 함수를 호출하는 형태로 역할의 요청이 나오게 된다.