AWS IAM

이 글은 이현수님의 AWS IAM: IAM Policy 알아보기 (이론편) 글을 읽고 개인적으로 이해 및 정리를 위하여 쓰여진 글입니다. 자세한 내용은 해당 링크를 참고해주세요 😊

AWS는 교과서 위주로 책을 보면서 배웠다기 보다는 구글링을 통해서 여러 블로그와 커뮤니티들을 탐방하며 SJ (SapJil)을 통해 익혔다는 표현이 맞을 것 같다. 대부분 AWS 를 입문하는 사람들이 그러할 것 같은데, 사실 이렇게 익히면서 배우면 AWS 서비스나 개념에 대해서 좀 더 빨리 이해하고 실전 사용이 가능하다는 장점이 있지만, 이론적 근간이 없기 때문에 꽤나 중요한 개념들을 놓치고 지나쳐 버릴 수 있다.

IAM 도 그러한 맥락에서 볼 수 있을 것 같은데, 굳이 IAM 접근제어를 사용하지 않아도, AWS 회원가입을 마치고 얻게되는 루트계정만 있으면 모든 서비스를 접근하고 구축하는데 불편함이 없으므로 그냥 그렇게 사용해버리는 경향이 있는 것 같다.

하지만, 사실 이런 행위는 매우 위험하다고 볼 수 있는데, 루트계정의 비밀번호 하나만 탈취당하면, 그간 구축해왔던 모든 서비스들을 한꺼번에 날려버릴 수도 있고, 루트 계정을 공유해서 사용하면 여러 개발자들 중 누가 어떤 설정을 했는지 책임소재를 파악하기도 쉽지 않다. 무엇보다 모든 서비스를 루트 계정으로 이용하게 되면, 특정 서비스에는 필요없는 과도한 권한이 부여될 수 있기 때문에 웬만하면 AWS 에서 권장하는 방식대로 사용하는 것이 좋다.

기본 개념 이해하기

AWS IAM 은 AWS Identity and Access Management 의 약자로서 AWS 서비스를 이용하기 위한 모든 계정의 인증 및 접근제어를 담당하는 서비스이다. 보안과 연결되어있다는 점에서 어쩌면 AWS 상에서 가장 중요한 서비스라고 할 수 있다.

AWS IAM console 화면을 보면 왼쪽 사이드 바에 사용자그룹, 사용자, 역할 정책 등 다양한 메뉴가 보인다. 각각의 개념을 살펴보고 서로의 연관관계를 이해해보자.

Access Control, 접근제어

어떤 특정 행동을 할 수 있고, 할 수 없는 권한을 통제하는 것을 접근 제어라고 한다.

UBAC, User Based Access Control

사용자 중심의 접근제어를 사용한다면 사용자 개개인에게 권한을 일일히 부여할 것이다.

  • 둘리 : A 가능

  • 도우너 : A, B 가능

  • 고길동 : C 가능

사용자가 1-2명 정도 소수일때만해도 이 방법은 간단하고 쉽기 때문에 편리하다고 느껴질 것이다. 하지만 사용자가 100명, 1000명 으로 늘어날 경우에는? 각 사용자마다 매번 반복되는 권한설정을 해주는 것은 엄청난 시간과 노력을 할애하는 일이 된다. 이런 배경에서 나온 것이 바로 그룹의 개념이다.

GBAC, Group Based Access Control

그룹 중심의 접근제어방식이다. 같은 권한을 가진 사용자끼리 묶어서 그룹을 형성한뒤, 사용자가 아니라 그룹에 권한을 부여하는 방식이다.

  • A group : 둘리, 도우너

  • B group : 도우너

  • C group : 홍길동

이렇게 그룹 기반으로 설정을 하게 되면, 그룹에 권한을 부여하고, 그룹에 사용자를 추가하는 방식으로 권한을 조정할 수 있다. 하지만, 시간이 갈수록 특정 권한을 가진 그룹들이 다양하게 늘어나게 되고, 한 개의 권한을 여러개의 그룹에서 적용할수도 있다. 이렇게 특정 권한을 여러 그룹에서 적용가능할 경우, 그룹 베이스로 권한검사를 하는 것은 더 어려워진다.

이러한 맥락에서 등장한 것이 바로 역할이라는 개념이다.

RBAC, Role Based Access Control

역할 기반의 접근제어 방식에서는 그룹에 바로 권한을 부여하는 것이 아니라, 권한의 그룹이라는 개념으로 역할을 만들고 그 역할을 그룹이나 사용자에 연결한다. 정리하자면 아래와 같다.

  • 그룹 내에는 사용자들이 있다.

  • 역할(이라는 그룹)에는 권한이 부여되고 그 역할은 그룹과 사용자와 연결된다.

    • 배포역할 -> 배포그룹 - 배포 담당 개발자

    • 관리자 역할 -> 관리자 그룹 -> 인프라 관리자

  • 그룹은 사용자의 그룹으로 주로 사용하고, 역할은 권한의 그룹으로 사용한다.

  • 그룹이 울타리라면, 역할은 포스트잇!

    • 역할은 그룹이나 사용자 모두에게 잘 붙는다. 필요할 경우 사용자에게, 그룹에게 바로바로 붙일 수 있다.

  • 그룹 베이스로 권한을 설정하기보다, 그룹은 사용자를 분류하는 개념으로, 정책은 권한을 분류하는 개념으로 사용한다.

  • 예시

    • 그룹

      • 관리자 그룹

      • 사용자 그룹

      • 게스트 그룹

    • 역할

      • S3에 접근할 수 있는 역할

      • S3에 접근 및 읽고 쓸 수 있는 역할

      • EC2 에 접근할 수 있는 역할

그래서 보통 AWS 에서는 이 역할을 기반으로 접근 제어를 설정한다.

ABAC, Attribute Based Access Control

PBAC, Policy Based Access Control 이라고도 한다.

하지만 위와 같이 역할 기반 제어관리로는 다음과 같은 상황을 해결할 수 없다.

현재상황

  • 사용자 : 나씨티 CTO, 나개발 개발자

  • 그룹 : 개발자 그룹

  • 역할

    • 서버관리 : EC2

  • 권한

    • Allow 서버접근 및 설정 수정

위와 같은 상황에서 서버 배포를 할 수 있는 CodePipeline 권한을 CTO 에게만 부여하고 싶다면, 어떻게 해야할까? 나씨티 CTO 사용자에게 다이렉트로 서버배포의 역할을 부여할 수 있겠지만, 만약에 배포 담당자가 다수로 늘어날 경우, 관리가 힘들어지므로 별로 좋은방법이 될 수 없다. 같은 그룹내 사용자라도 사용자의 속성에 따라서 동적으로 권한을 부여하고 싶다면 어떻게 해야할까?

해결

  • 사용자 : 나씨티 CTO, 나개발 개발자

  • 그룹 : 개발자 그룹

  • 역할

    • 서버관리 : EC2

    • 배포관리 : CodePipeline

  • 정책

    • Allow 서버접근 및 설정 수정

    • Allow 배포 파이프라인 접근 및 설정 수정 if 사용자.C레벨? == TRUE (Subject 속성 사용)

    • Allow 배포 파이프라인 접근 및 설정 수정 if 접근메뉴.CodePipeline? == TRUE (Object 속성 사용)

    • Allow 배포 파이프라인 접근 및 설정 수정 if 현재시각 BETWEEN 오전 12시 AND 오전 1시 (Global/Environment/Context 속성 사용)

다음과 같이 단순한 권한을 정책으로 변경하게 되면, 동적이고 조건적으로 권한을 부여할 수 있게된다.

AWS 의 IAM 은 그래서 역할 기반의 RBAC 와 정책 기반의 ABAC 를 융합한 개념이다. AWS IAM = Role + Policy

IAM Policy JSON 문법

자세한 내용은 공식 문서 참고

{
  "Version": "2012-10-17",
  "Statement": [ ... ]
}

루트 - 최상위요소

  1. version

    1. 문서 양식의 버전

    2. 디폴트는 2008-10-17 이지만 가장 최신 버전인 2012-10-17 을 사용해야한다.

  2. statement

    1. 권한부여규칙들을 배열로 나열

Statement 내부의 요소

  1. Effect

    1. type : enum

    2. 허용할지 불허할지에 대한 구분

    3. 대부분의 경우에는 allow 형태로 설정한다.

  2. Action

    1. type : string / string array

    2. 하나 혹은 여러개의 action 을 정의할 수 있음

  3. Resource

    1. statement 의 주제가 되는 리소스 대상

    2. 서비스에 따라서 하부 리소스 단위까지 한정할 수 있음

  4. Principal

    1. object

    2. 리소스 기반 정책에서 보안 주체를 지정함

  5. Sid

    1. statement ID

    2. 각 요소에 고유한 id 값을 붙이고 싶을 때 사용함

Policy 종류

정책에도 다양한 종류가 있는데 그 기준에 따라서 다양하게 나뉠 수 있다.

  1. 연결대상에 따라서

    1. 자격증명주체 : 자격증명-기반정책

    2. 리소스 : 리소스-기반정책

    3. 역할의 신뢰관계 : 신뢰정책

  2. 생성 주체에 따라서

    1. 사용자가 생성 : 고객 관리 정책

    2. AWS 빌트인 : AWS 관리정책, 직무 기반 정책

  3. 인라인 정책 여부에 따라서

    1. 인라인 정책

되게 복잡하게 여러가지 정책들이 있는 것 같은데, 사실 중요한 것은 정책이 어떤 대상과 연결되었는지, 즉 1번이 가장 중요하다. 그런데 정책은 앞서 살펴본 것처럼

  1. 누가

  2. 어떤 조건을 충족하면

  3. 어떤 대상에 대해서

  4. 어떤 행위에 대한 권한을 가진다.

이렇게 4가지 요소가 나타나야 한다. 1번의 자격증명 기반 정책과 리소스 기반 정책은 누가, 즉 정책의 보안주체(principal)가 서로 다르다.

자격증명 기반 정책 Id-Based Policy

자격증명 기반 정책에서는 그 정책에 연결된 보안주체(AWS 계정, IAM 사용자, 그룹, 역할 등)가 암묵적으로 보안주체가 된다. 대부분 우리가 봐왔던 정책에서는 principal 이 명시되어있지 않으므로 자격증명 기반 정책이라고 볼 수 있을 것 같다.

리소스 기반 정책 Resource-Based Policy

반면에 리소스 기반 정책에서는 특정 리소스에 대해서 특정 사용자에게 권한을 부여하는 개념이다. 따라서 반드시 특정사용자인 principal 이 정책설정에 명시된다. 대표적으로 S3 가 있을 수 있는데, S3 의 경우는 버킷정책을 서비스 내부에서 설정할 수 있도록 되어있다.

PreviousAWSNextAWS CodePipeline 으로 배포 자동화하기 (1)

Last updated