본문 바로가기
Amazon Web Service

AWS IAM 정책(Policy), 역할(Role) 차이점 그리고 개념,이해하기!

by 클수저 2024. 4. 9.
728x90
반응형

AWS IAM을 개념적으로 학습하고 적용하던 와중에 갑작스러운 의문이 들었다.

사실은 단순하게 IAM은 기본적인 계정 보안을 위한 AWS서비스로 가볍게 이해헀다. 사실은 틀린 것은 아니지만, 여기서 더 깊이 들어가지 않았다.

 

그래서 든 의문점....

Policy(정책)과 Role(역할)의 차이점은 뭐지? 이 두개가 User에게 어떻게 적용이 되는거지?

그래서 먼저 AWS IAM 공식 홈페이지에 있는 내용을 차용해서 가져왔다.

AWS IAM 공식홈페이지

위 이미지에서 볼 수 있듯이 IAM 자체가 보안,자격 증명, 규정준수 카테고리에 포함되어 있고, 리소스에 대한 액세스/ID 안전하게 관리이다.

 

개념

 

계정에서 생성할 수 있는 특정 권한을 가진 IAM 자격 증명입니다. IAM 역할은 IAM 사용자와 몇 가지 점에서 유사합니다. 역할과 사용자 모두 AWS에서 자격 증명으로 할 수 있는 것과 할 수 없는 것을 결정하는 권한 정책을 포함하는 AWS 자격 증명입니다. 그러나 역할한 사람과만 연관되지 않고 해당 역할이 필요한 사람이라면 누구든지 맡을 수 있어야 합니다. 또한 역할에는 그와 연관된 암호 또는 액세스 키와 같은 표준 장기 자격 증명이 없습니다. 대신에 역할을 맡은 사람에게는 해당 역할 세션을 위한 임시 보안 자격 증명이 제공됩니다.

AWS에서 설명하는 IAM 개념이다. 핵심은 Bold처리를 해두었다.

역할의 핵심은 임시 보안 자격증명!

계정에서 생성할 수 있는 특정 권한을 가진 IAM 자격 증명입니다. IAM 역할은 IAM 사용자와 몇 가지 점에서 유사합니다. 역할과 사용자 모두 AWS에서 자격 증명으로 할 수 있는 것과 할 수 없는 것을 결정하는 권한 정책을 포함하는 AWS 자격 증명입니다.

👉 정책은 역할과 IAM 사용자에게 부여할 수 있다.

 

그러나 역할은 한 사람과만 연관되지 않고 해당 역할이 필요한 사람이라면 누구든지 맡을 수 있어야 합니다.

👉 정책은 한 사람 한 그룹 단위로 할당해주지만 역할은 다수의 사람이 역할을 맡을 수 있다.

 

또한 역할에는 그와 연관된 암호 또는 액세스 키와 같은 표준 장기 자격 증명이 없습니다.

👉 엑세스 키 또는 암호를 알고 있다면 일부로 이를 바꾸지 않는 한 영원한 크리덴셜이다. 

 

대신에 역할을 맡은 사람에게는 해당 역할 세션을 위한 임시 보안 자격 증명이 제공됩니다. 

👉  임시 보안 자격 증명유효한 시간이 지난 후에는 사용불가능한 크리덴셜이다. IAM 사용자가 역할을 맡는다는 것은 임시 보안 자격 증명을 통해 임시적인 시간(예 1시간) 동안만 역할을 맡고 그 이후에는 역할을 반납한다. 정책은 한번 부여한 뒤 회수하지 않는 한 영구적으로 권한을 부여받는다.


결론

PolicyIAM 사용자 또는 그룹의 접근 권한을 정의하는 것이다. 정책을 부여하고 나서 별도로 회수하지 않는다면 영구적으로 부여받은 권한에 따라 AWS 내의 자원(Resource)에 접근할 수 있다.

 

반면, Role 은 Policy 와 달리 일시적으로 AWS 내의 자원에 접근할 수 있는 권한을 얻고, 권한을 유지할 수 있는 시간이 지나면 그 이후에는 권한이 사라진다. 만약, 다시 권한을 얻고자 한다면 임시 보안 자격 증명을 통해 발급 받아야 한다. Role 은 Policy 연결이 되어야 하는데, Policy 에 정의된 접근 권한에 따라 일시적으로 권한을 얻는 것!

 

즉, Policy는 단독으로 부여가 가능하지만, Role은 정책을 받은 후에 사용할 수 있는 개념이다! 

어떻게 본다면 Role은 Policy의 하위개념인 것 같다.


실습으로 이해하기

AWS같은 인프라는...코드작업도 마찬가지이지만, 무조건 실습을 해야지 이해도가 금방 올라간다.

AWS 콘솔에서 루트계정과 IAM계정을 가지고 실습해보자.

 

기존에 루트계정에서 IAM 서비스에서 test_policy라는 계정을 만들고 권한에 두가지를 부여했다.

AmazonEC2ReadOnlyAccess 👉 EC2를 보는 권한(생성은 불가!)

IAMReadOnlyAccess 👉 IAM 서비스를 읽을 수 있는 권한

 

 

Policy는 기본적으로 JSON으로 되어있다. Action을 보면 해당 정책에서 할 수 있는 동작이 나온다.

IAM 테스트를 위해서 test_policy 라는 계정을 만들었다.

AWS 가장 첫 화면에서 확인 할 수 있듯이, 액세스 거부창이 뜬다!

test_policy는 위에서 2개의 권한만 부여했고, 나머지 권한이 없기 때문이다.

비용 및 사용량에서도 엑세스가 거부되었고, 권한이 없다고 에러메세지가 뜨는 것을 확인 할 수 있다.

 

S3 버킷을 만들어보겠다. (물론 당연히 생성은 안되곘지만 안되는 과정을 남기기 위해서이다.)

S3에 대한 내용을 입력 후, 버킷만들기를 하면 생성실패!

s3 : CreateBucket 권한이 필요합니다. 라는 메세지와 함께 IAM을 확인하라고 나온다.

해당 계정은 AmazonEC2ReadOnlyAccess, IAMReadOnlyAccess 권한만 있기 때문이다.

 

그렇다면, S3에 관한 권한을 부여하고 다시 확인해보자.

test_policy라는 계정에서 권한추가를 한다.

직접 정책 연결을 누르고 s3 로 검색을 하면 s3와 관련 된 정책이 나온다.

s3를 생성할 수 있는 AmazonS3FullAccess 권한을 부여! 

s3 : CreateBucket 만 따로 정책이 존재하지않아 가장 근접한 권한을 부여했다.

 해당 정책을 클릭하면 정책이 있는 사이트로 연결이 되면서 권한에서 create를 검색하면 CreateBucket이라는 정책이 있는 것을 확인할 수 있다.

다시 test_policy로 접속해서 S3를 만들어보려한다.

helloworld100  이라는 버킷이 생성 된 것을 확인할 수 있다!

 

위 실습을 통해서 AWS IAM 서비스에 대한 이해 그리고 개념을 살펴봤다.

굉장히 단순하게 이해했던 IAM 서비스가 복잡하고 이해를 깊게해야하는 것을 깨달으면서 AWS서비스에 대한 이해도를 더욱 더 높이고 깊게 공부를 해야겠다는 생각이 들면서 블로그를 작성했다.

 

클라우드를 입문하면서 이런 부분이 매력적으로 다가왔기에 AWS와 같은 CSP사 제품을 다루는게 즐겁다.

 

다음에는 또 다른 클라우드 서비스로 블로깅 할 예정이다.


Good luck~!

728x90
반응형