[AWS 기타] 꼭 알아야 하는 IAM 정책

 

 

 

IAM Policy란 무엇인가?

 

 

 

 

 

 

 

IAM Policy의 종류와 사용 목적

 

 

AWS Organizations (Service Contorl Policies SCPs)

AWS의 무료 서비스이며 멀티 계정을 관리하는 서비스이다. 

두개 이상의  AWS 계정을 운영한다면 Organizaitions을 고려하는 경우가 많다. 그럴 경우 Organizations 안에 있는 SCPs 서비스를 고려할 수 있다. 

 

 

AWS Identity and Access Management(IAM)(Permission Policies, Permission Boundaries)

가장 많이 사용하는 Permission Policies, Permission Boundaries이다. 한번이라도 IAM을 써봤다면 Permission Policies를 써 봤을 것이다. 우리가 흔히 말하는 Policy가 바로 이것이다.

Permission Boundaries는 사용자나 Role에 할당되는 IAM Policy의 기능을 제한하는 역할을 한다. 

사용자나 역할에 Permission Policy만 있다면 Policy에서 제한하는 기능만 사용이 가능하다. 즉 Policy에서 제공하는 모든 기능을 사용가능하다는 것이다. 하지만 관리자 입장에서는 제한하고 싶은 Policy가 있을 것이다.

기존의 경우 Policy를 세분화 했어야 했다. 하지만 Permission Boundaries 추가로 만들어서 사용자나 Role에 할당하면 교집합 개념처럼 Permission Policy 권한을 축소시킬 수 있다. 

 

 

AWS Security Token Service(STS, Session Policies)

Federation이나 Role 전환을 사용할 때 사용한다.

 

 

Specific AWS services (Resource-based Policies)

S3와 같은 서비스에 할당할 때 사용한다.

 

 

VPC Endpoints (Endpoint Policies)

자주 사용이 되지 않지만 s3 gateway vpc endpoint 같은 경우에 사용한다. 

 

 

 

 

 

위에서 언급했던 세부적인 Policy를 크게 두 가지로 나누어 보면 Identity 기반과 Resource 기반 정책으로 나눌 수 있다.

 

Identity 기반 정책은 Policy를 만든 후 ID에 할당한다. 즉 사용자나 계정에 할당한다.

그리고 Resource 정책은 말 그대로 Resource에 할당하는 것이다. 

 

 

 

 

 

 

IAM Policy 구조

IAM Policy는 Json 포맷을 띄게 된다. 하나의 Statement 안에 관리자가 여러 조건을 넣어 하나의 Policy를 만들게 된다. 
하나의 Policy 안에 아래 5가지 조건이 모두 들어가야 하는 것은 아니다. 

 

 

Effect

어떤 조건을 만들고 이 조건이 명시적인 허용 조건이 될 것인지 명시적인 차단 조건이 될 것인지를 지정하는 것이다. 

 

 

Principal

접근을 허용 혹은 차단하고자 하는 대상을 지정하는 것이다. Account, 사용자, Role이 될 수 있다.

이러한 자격증명을 지정하는 것이 Principal이다. 

 

 

Action

자격증명이 어떤 행위를 할 수 있는지 지정하는 것이 Action이다. ex: S3 upload, Download

 

 

Resource

identity를 갖는 사용자가 어디에 접근을 허용할 지 차단할 지를 지정하는 것이다. 

 

 

Condition

P,A,R에 추가적으로 다양한 조건을 복잡하게 지정할 수 있다. ex: IP Address, Date, 사용자가 보내는 API Call에 유저 에이전트, 헤더값을 넣는 것

 

 

 

 

 

 

 

IAM 권한 할당 원리의 이해

 

 

명시적 Deny란 Policy 안 Statement 안 Effect가 Deny일 시 그것을 명시적 Deny라고 한다.

 

기본적으로 IAM은 Policy를 lookup 할 때 API 호출에 해당되는 모든 Policy를 검증한다. 

그 중 첫번째로 찾는 것이 명시적 Deny가 있지에 대한 검사이다. 만약 명시적인 Deny가 존재하면 API 콜이 차단된다.

 

묵시적인 Deny는 눈에는 보이지 않지만 묵시적으로 허용되지 않은건 차단된다는 개념이다.

허용범위를 따로 선언하지 않으면 묵시적으로 Deny 처리가 된다. 

 

 

 

 

 

 

허용을 하기 위해서는 Permission Boundary, Policy 각각 허용이 되어야 한다. 

하나의 사용자나 하나의 Role에 두개의 Policy가 할당되어 있는 상황인 것이다.

 

먼저 원칙 1에 의해 명시적 Deny가 없어야 하고 두번째 조건으로 Permission Boundary에도 명시적 허용 조건이 있어야 하고 Permission Policy 역시 명시적인 허용 조건이 있어야 한다. 

 

 

 

 

 

 

두 개의 Permission policy가 존재한다. 

 

우측에 있는 Permission Policy를 먼저 봐야한다.

그리고 먼저 명시적인 deny 조건은 없는 것을 확인 할 수 있다.

리소스를 먼저 살펴보면 아스테리크 처리가 되어 있다. 그러면 모든 것이라는 의미이므로 버킷에 의한 것은 처리가 될 것을 알 수 있다.

 

그 후 Action을 봐야 한다.  s3:* 조건이므로 S3에 대한 모든 권리를 가지는 것을 확인할 수 있다. 

 

그 후 이제 Permission Boundary를 봐야 한다.

리소스가 arn aws log만 지정이 되어있다. S3 버킷에 대한 지정은 따로 없다. 그러면 Permission Boundary의 조건은 묵시적 Deny가 적용이 된다. 

IAM Policy는 명시적으로 무엇인가를 선언하지 않은 호출에 대해서는 암묵적으로 Deny 되기 때문이다. 

 

 

 

 

즉 Permission Policy에 허용조건이 있다 하더라도 Boundary에 허용이 없기 때문에 묵시적 Deny 조건을 통해서 요청이 차단된 것을 확인 할 수 있다. 

 

 

 

 

 

 

이번엔 이 조건을 확인 해 보자

 

Permission Policy는 똑같은 것을 확인할 수 있다.

Permission Boundary를 살펴보면 아까와는 다르게 허용 조건이 생기고 Resource는 Korea Summit 버킷을

Action은 S3의 Get object를 제대로 표현하는 것을 알 수 있다. 

 

 

 

 

 

 

결과적으로 잘 적용이 된 것을 확인할 수 있다.

 

 

 

 

 

 

 

 

Permission Boundary는 두 번째 예제와 똑같은 것을 확인할 수 있다. 

 

하지만 오른쪽에 있는 Permission Policy가 변한 것을 확인할 수 있다. 

리소스는 그대로 모든 리소스에 접근이 가능하지만 액션에 문제가 있는 것을 확인 할 수 있다.

Action에 S3에 관한 행위가 없기 때문에 묵시적인 Deny가 적용된다는 것을 확인할 수 있다.

 

 

 

 

 

 

 

 결과적으로 Boundary는 통과 했지만 Policy의 묵시적 Deny에 의해 API 요청이 차단된 것을 알 수 있다. 

 

 

 

 

 

 

 

 

만약 사용자가 SCP를 사용하고 있고 S3 버킷에 접근하는 환경이라면 관리자 입장에서는 두 가지 방법을 지정할 수 있다.

 

하나는 SCP에서 허용을 해 준 후 Identity Policy에서 허용을 해 주는 것이다.

다른 방법은 Rsource Policy의 명시적인 허용 조건을 해 주는 것이다. 

 

다시 정리하면 요청을 보내는 쪽에서 허용을 해주는 조건과, 요청을 받는 쪽에서 허용을 해주는 방법이 존재한다.

이 것은 동일 계정 안에서만 적용이 가능하다. 

 

 

 

 

 

 

만약 다른 계정으로 접근을 하려고 한다면 명시적 Deny도 없어야 하고 SCP, Boundary Policy, Resource Policy 역시 모두 허용이 되어야 접근이 가능하다. 

 

 

 

 

 

 

 

같은 계정 시 Permission Policy에서 ec2에 대한 모든 권한을 주어진다고 가정하고 Resource Policy에서 S3에 대한 모든 액션을 허용해준다고 가정한다면 그 Policy가 할당된 사용자나 역할은 두 권한을 모두 획득하는 것이다. 

 

 

 

 

 

 

 

그렇다면 만약 Permission Boundary에는 get object만 존재하고 policy에는 S3의 모든 액션이 허용된다면 S3 Get Object 권한만 획득할 수 있다. 

 

 

 

 

 

 

만약 사용자의 IAM 역할이나 사용자가 복잡하게 쓰는 경우 ex: SCP, Permission Boundary, Policy, Session Policy

결국 이 4개의 Policy의 교집합이 사용자가 최종적으로 획득할 수 있는 권한인 것이다. 

 

 

 

 

 

 

IAM 사용 팁

 

IAM Role은 별도의 과금 없이 사용할 수 있는 서비스이다. 

토큰을 기반으로 하는 임시보안자격 증명을 사용하기 때문에 보안성이 뛰어나다

 

동일한 작업을 하는 사용자에 대해서 개별적으로 Policy로 권한관리를 하다보면 Policy가 복잡해지는 경우가 있다.

그것을 Role로 관리하면 편리성이 증대된다고 할 수 있다. 

 

 

 

 

 

 

사용자가 EC2 인스턴스를 프로비저닝 하려고 할 때 IAM Policy를 어떻게 주어야 할까?

가장 쉬운 방법은 사용자에게 EC2 권한이 명시적으로 허용된 Policy를 할당하면 된다. 이렇게 Action에다 Policy를 넣으면 점점 복잡해진다. 

다른 방법으로는 첫번째 사용자에게 sts:AssumeRole 역할만 준다. 이 역할은 사용자에서 Role로 역할을 전환할  수 있는 권한이다. 나머지는 따로 설정해놓지 않으면 Deny가 된다. 그럼 사용자는 Role 전환을 할 수 있다. 최초의 사용자는 sts:AssumeRole에 대한 권한만 가지고 있었지만 하지만 Role로 전환이 되면 최종적으로는 EC2 인스턴스를 프로비저닝 할 수 있게 된다. 

 

 

 

 

 

 

 

두번째는 EC2 상의 어플리케이션에서 활용되는 사례이다. 

만약 EC2의 특정 애플리케이션이 S3 버킷에 접근을 해야 한다. 그렇다면 어떻게 코딩을 해야 할까?

S3 버킷은 Internal하게 사용하고 있다. 그렇다면 답은 하나다. S3에 접근할 수 있는 계정 정보를 넣으면 된다. 

그렇다면 애플리케이션이 S3 접근이 필요할 때 마다 자격증명을 통해 API를 호출하고 데이터를 주고 받을 수 있다. 

하지만 이렇게 운영한다면 소스코드 안에 자격증명이 들어가기 때문에 자격증명이 유출되기가 쉽다. 

 

이런 상황에서도 Role을 사용하면 된다. 

메타 데이터를 활용하면 된다. EC2 인스턴스는 메타 데이터를 제공한다. 만약 EC2 인스턴스를 프로비저닝 할 때 Role을 attach 했다면 자격증명을 메타데이터를 통해서 뽑아낼 수 있다. 여기에 있는 정보가 임시 보안 자격 증명이다. 따라서 애플리케이션은 username, pwd를 사용하는게 아닌 메타데이터에서 뽑아낸 임시 자격증명을 통해 S3를 접근하는 것이다. 

 

 

 

 

 

 

 

화면을 확인해 보면 두개의 Account가 존재한다. 하나는 dev의 account고 하나는 prod account이다. 

이 상황은 개발자가 dev account에서 prod account에 있는 dynamo db에 접근을 하려는 상황이다.

Role을 사용하지 않는다면 관리자가 prod account에 하나의 user를 생성한 후 dynamo db를 쓸 수 있는 권한을 준 후 username, pwd를 전달하면 된다.  하지만 이렇게 운영을 하게 되면 IAM 유저에 대한 관리가 어려워진다. 

 

이런 상황 역시 Role을 사용하면 된다. 

prod account에서 Role을 하나 만든다. Role을 만들 때 Trust relationship을 지정할 수 있다. 거기서 dev account를 지정하면 이 Role은 dev account에서 사용할 수 있다. 그리고 그 Role에 특정 dynamo db만 접근할 수 있게 policy를 지정해 준다.

그 후 dev account에서 하나의 iam 유저를 만든 후 assumeRole을 지정한다. 그리고 target role을 prod에서 만든 Role을 주면 된다.

 

 

 

 

 

 

Tag을 활용한 접근 권한 제어

 

AWS에서 Tag가 가지는 기능은 상당히 많다. 

우측에는 9개의 EC2가 있다. 6개는 Project Blue라는 태그가 있고 3개는 Project Green이라는 태그가 있다. IAM 유저나 롤에 Policy를 만들고 그 안에 Condition을 넣어서 태그를 지정해 놓으면 이 IAM을 할당받는 사용자나 Role은 태그와 일치하는 리소스에 대해서만 API 호출이 허용이 된다. 

 

 

 

 

 

 

 

Access Advisor를 활용한 미사용 권한 탐지

 

Access Advisor는 IAM에서 지원하는 기능이다. 

최대 1년간 IAM 사용자나 Role이 권한을 어떻게 썼는지 확인한 후 쓰지 않는 권한을 보여준다. 

Administrator 권한을 받아 사용했음에도 불구하고 사용하지 않는 권한들은 존재한다. 보안적인 관점에서 보면 필요 없는 기능은 빼는것이 안전하다. 왜냐하면 최소한의 권한을 부여하는 것을 추천하기 때문이다. 

그리고 이 기능은 API를 통해서도 호출할 수 있다. API를 통해 호출할 수 있다는 것은 자동화를 할 수 있다는 것이다. 

 

IAM 정책을 부여하는 것 중 가장 Best는 어떤 사용자 그룹에 어떤 Action이나 Resource가 필요한지 파악한 후 정책으로  놓는 것이다. 하지만 현실적으로는 너무 힘들다. 요구사항은 변경할 수 있기 때문이다. 

그럴 때 권한을 조금 느슨하게 준 후 Access Advisor를 사용하는 것도 방법이 될 수 있다. 

 

 

 

 

 

 

하지만 그 방법도 어려울 수 있다.

그럴 떄는 오픈 소스를 사용할 수 있다. 위 그림에 있는 Aardvark, Repokid는 넷플릭스에서 오픈소스로 개발하고 배포하고 있는 소프트웨어이다. 

Aardvark는 Access Advisor 정보를 계속해서 조회한 후 계속해서 policy를 체크한다. 

Repokid는 불필요한 권한을 삭제하는 데 사용된다. Aardvark가 조회를 한다면 실제 action은 Repokid가 진행한다. 

 

참고로 위 두 서비스는 오픈소스이며 라이센스는 아파치 version 2 를 사용한다. 

 

 

 

 

 

 

 

 

 

출처

https://www.youtube.com/watch?v=iPKaylieTV8&ab_channel=AmazonWebServicesKorea