[AWS] Security - IAM Deep Dive

bluewhale·2021년 6월 29일

AWS

목록 보기

17/19

IAM

IAM은 Identity & Access Management의 약자로 AWS 리소스에 대한 접근 및 제어 권한을 설정하기 위해 사용하는 서비스이다. IAM에서는 구체적으로 IAM Policy 설정을 통해 권한 제어가 이뤄진다.

Principal

IAM Principal은 AWS 리소스에 접근을 요청한 사용자로, User, Account, Application 등이 있다. IAM Principal에 대한 인증은 AWS 루트 계정 혹은 IAM Entity를 통해 이뤄진다. 일반적으로, 보안을 강화하고 사용자의 실수로 인한 장애를 최소화하기 위해 용도에 맞는 IAM Entity를 생성하여 사용하는 것이 바람직하다.

IAM User vs IAM Group

IAM User와 IAM Group은 모두 IAM Entity에 속한다. IAM 유저는 IAM 정책이 적용되는 단일 개체를 의미한다. 그룹은 동일한 IAM 정책이 적용되는 유저의 집합으로 관리의 편의성을 위해 사용된다. IAM 유저는 최대 10개의 IAM 그룹에 포함될 수 있다.

IAM Policy

IAM Policy는 AWS 서비스와 리소스에 대한 권한 제어를 담당한다. AWS에서는 IAM Principal이 AWS 서비스에 대한 요청을 생성하면, IAM Entity와 연결된 IAM 정책을 이용하여 요청의 유효성을 검사한다. IAM 정책은 JSON 포맷으로 관리되며, IAM Principal에 대한 권한 설정을 포함한다.

IAM Policy Structre

IAM Principal이 AWS 리소스에 접근을 시도할 경우, 접근 요청이 생성되어 AWS로 전달된다. 요청은 다음의 구성요소를 갖는다. AWS는 요청을 모아서 request context를 생성하고, 요청에 대한 인증 작업을 처리한다.

effect: 허용(allow) 혹은 차단(deny) 여부를 결정
Principal: 리소스에 대한 접근을 요청한 사용자
Resource: IAM Principal이 접근하고자 하는 AWS 서비스 혹은 리소스(ex, S3, EC2)
Action: IAM 정책을 통해 리소스에 설정하고자 하는 권한(ex, 읽기)
Condition: 정책을 적용하기 위해 필요한 조건. Condition을 활용하면 tag 기반으로 여러 리소스에 대해 편리하게 권한 설정을 할 수 있다.

IAM Policy 종류

IAM 정책은 다양한 유형이 존재한다. AWS에서는 하나의 요청에 대해 여러 개의 정책이 적용될 수 있다. IAM 정책으로는 identity-based policy, resource-based policy 등이 있다.

Identity-based policy

Identity-based policy는 IAM Entity에 대한 리소스 제어 권한을 담고 있다. Identity 기반 정책은 세부적으로 Managed policy와 Inline policy로 구분된다.

Managed Policy

Standalone Policy로, 여러 IAM Entity에게 탈부착이 가능하다. Managed Policy는 관리 주체에 따라 AWS managed policy와 Customer managed policy로 구분된다.

Inline Policy

이름처럼, IAM Entity에 내제된 정책이다. Managed Policy와 달리, 하나의 Inline Policy는 하나의 IAM Entity와만 연결될 수 있는 1:1 관계이다.

다음은 S3 bucket에 대한 identity 기반 정책을 생성하는 예시이다. 해당 정책을 포함한 IAM 사용자는 example_bucket에 대해, 버킷 목록 조회 요청이 가능하다.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::example_bucket"
  }
}

Resource-based policy

Identity기반 정책과 달리, 리소스 단위(ex, S3 bucket)로 권한 설정이 이뤄지는 정책이다. 모든 Resource 기반 정책은 inline policy 유형에 속한다. 리소스가 권한 설정의 주체가 되기 때문에, cross-account에 대한 권한 설정이 가능하다는 것이 특징이다.

다음은 S3 bucket에 대한 resource 기반 정책을 생성하는 예시이다. 해당 정책은 인가된 IAM Principal에 대해 mybucket에 대한 모든 권한을 부여하는 정책이다.

{
  "Version": "2012-10-17",
  "Id": "S3-Account-Permissions",
  "Statement": [{
    "Sid": "1",
    "Effect": "Allow",
    "Principal": {"AWS": ["arn:aws:iam::{ACCOUNT-ID-WITHOUT-HYPHENS}:root"]},
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::mybucket",
      "arn:aws:s3:::mybucket/*"
    ]
  }]
}

Permission Boundary

Permission boundary는 Indentity 기반 정책의 일종(managed policy)으로, IAM Entity가 가질 수 있는 권한의 최대 범위에 해당다. Permission boundary는 이름처럼 권한의 범위를 설정하는 것으로, 그 자체로 권한을 부여하지는 않는다. 따라서, Permission boundary는 항상 identity 기반 정책과 함께 사용되어야 한다.

AWS에서는 permission boundary, permission policy 등을 순차적으로 적용하는 방식으로 요청을 검사한다. 따라서, permission boundary에서 명시적으로 허용되지 않은 요청은 permission policy에서 허용 여부와 관계없이 묵시적으로 거부된다. permission boundary의 묵시적 거부는 identity 기반 정책에만 적용되며, resource 기반 정책은 이를 적용을 받지 않는다. 이와 관련된 자세한 내용은 이어지는 IAM Policy 적용 장에서 다루도록 한다.

Service Control Policy(SCP)

SCP(Service Control Policy)는 AWS 계정의 집합인 AWS Organization에 적용되는 IAM 정책으로 가장 상위 레벨의 IAM 정책에 해당한다. Permission boundary가 하나의 IAM Entity에 대한 권한 범위를 지정한다면, SCP는 더 큰 범위의 AWS 그룹에 대한 권함 범위를 지정한다고 볼 수 있다.

SCP는 최상위 IAM 정책으로, permission boundary와 다르게 resource 기반 정책에도 동일하게 적용된다. 단, 예외적으로 동일한 계정에 속한 리소스에 접근하는 경우에는 resource 기반 정책에 영향을 주지 않는다.

Access Control List(ACL)

ACL(Access Control List)는 서비스 정책의 일종으로, 다른 계정의 IAM Principal에 대한 권한을 설정하기 위해 사용된다. 따라서, ACL은 동일한 계정에 속한 리소스에 접근하는 것을 제한하는 기능은 없다. ACL은 다른 IAM 정책과 달리 JSON 포맷을 사용하지 않는 것이 특징이다.

Session Policy

Session Policy는 프로그램에서 임시로 세션을 생성하여 IAM Entity(role 혹은 federated user)에 AWS 리소스에 대한 권한을 부여하기 위해 사용된다. Session Policy는 permission boundary와 동일하게 identity 기반 정책에만 적용된다.

IAM Policy 적용

AWS에서는 하나의 요청에 대해 다양한 IAM 정책이 동시에 적용될 수 있다. 서로 다른 계정에서 여러 IAM 정책이 동시에 적용되는 경우, 권한 부여 로직이 매우 복잡하다. 먼저, 동일한 계정에서 IAM 정책이 적용되는 과정을 도식화한 그림은 다음과 같다.

IAM 정책이 적용될 때에는, Resource 기반 정책을 제외한 모든 IAM 정책에서 명시적으로 허용되지 않은 요청은 묵시적으로 거부된다는 규칙이 존재한다. 따라서, 권한 설정시 이를 유의하여야 한다.

또한, identity 기반 정책은 요청을 최종적으로 평가하는 가장 low-level의 IAM 정책으로 반드시 필요하다. 이와 달리, 다른 IAM 정책들은 optional하게 사용 여부를 결정할 수 있다는 것이 특징이다.

Organization SCP: 최상위 IAM 정책으로 AWS 계정 그룹에 모두 적용된다. 예외적으로, 명시적 거부가 없는 경우에는 동일한 계정에 속한 리소스를 평가할 때에는 묵시적 거부의 적용을 받지 않는다.
Resource-based policy: 일부 예외를 제외하고, 이 단계에서 허용된 요청은 이후 IAM 정책에 영향을 받지 않는다.

Note
Resource 기반 정책에서는 IAM Principal을 어떻게 지정했는지 여부에 따라 권한 평가 방식이 달라진다. 특히, role 혹은 federated user에 대해 임시로 session policy를 생성한 경우에는 위와 다른 과정을 거치게 되므로 유의하여야 한다. 관련된 자세한 설명은 [이 글](Session Policies)에서 확인할 수 있다.
IAM permission boundary: IAM 객체에 대한 최대 권한 범위에 대한 검사가 이루어진다.
Session policy: 프로그램에 의해 임시로 생성된 세션 정책이 존재하는 경우, 함께 평가한다.
Identity-based policy: 가장 low-level의 정책으로, IAM Entity가 요청을 수행할 권한이 있는지 여부를 최종적으로 평가한다.

Identity-based policy + resource-based policy

가장 일반적인 유형으로, identity 기반 정책과 resource 기반 정책이 동시에 적용되는 상황에 해당한다. 동일한 계정에서는 identity 기반 정책과 resource 기반 정책에서 명시적으로 허용한 권한의 합집합만큼의 권한이 부여된다.

단, resource 기반 정책에서 IAM Principal을 명시적으로 제한한 경우에는, IAM 사용자의

Identity-based policy + permission boundary

Permission boundary는 하나의 IAM Entity가 가질 수 있는 권한의 최대 범위를 제한한다. 따라서, 이 경우에는 identity 기반 정책과 permission boundary에서 허용한 권한의 교집합만큼의 권한이 할당된다.

Identity-based policy + permission boundary

Identity-based policy + Organizations SCP

SCP는 AWS 계정 그룹에 대한 권한 범위를 지정하기 위해 사용된다. 따라서, permission boundary를 적용한 위 예시와 동일하게 identity 기반 정책과 SCP 권한의 교집합만큼의 권한이 부여된다.

Resource-based policy + Identity-based policy + Permission boundary

이 경우, identity 기반 정책과 permission boundary의 교집합에 Resource 기반 정책에서 허용한 범위를 추가한 것이 최종 권한 범위가 된다.

Authentication

대부분의 AWS 서비스에서는, IAM Principal이 AWS로 요청을 전송하기 위해서는 먼저 인증(authentication)을 받아야 한다. 일부(ex, S3, STS)를 제외한 모든 AWS 서비스는 인증되지 않은 사용자로 부터의 요청을 거부한다.

AWS 리소스에 접근하는 형태에 따라 인증 과정에 차이가 존재한다. 콘솔에서 AWS 루트 계정을 통해 인증을 하는 경우에는 이메일 주소와 패스워드가 요구된다. IAM 유저는 account ID(혹은 alias)와 유져명, 패스워드를 사용한다. API 혹은 AWS CLI를 통한 경우, access key와 secret key가 사용된다. 인증 보안을 강화하기 위해 AWS에서는 multi-factor authentication(MFA) 기능을 추가적으로 제공한다.