IAM

Identity and Access Management(IAM)

AWS 리소스를 사용하기 위해 Console 기반, Script 기반, 프로비저닝(테라폼), DOM 기반 등 여러 방식을 사용하고 있지만 모두 AWS API 로 projection 된다.

AWS API 요청시 사용자의 인증, 인가를 제어하는 역할이 IAM 이다.

IAM 에는 아래 4가지 구성요소가 있다.

• User: 실제 AWS 를 사용하는 유저 혹은 어플리케이션
• Group: User의 집합
• Policy: [User, Group] 이 언제 어디서 무엇을 할 수 있는지에 대한 문서, JSON 형식으로 정의
• Role: AWS 리소스에 부여되어 무엇을 할 수 있는지 정의

예시로 S3 파일에 접근할 경우 아래 순서로 권한 체크한다.

1. User 가 가지는 Policy 확인
2. User 가 속한 Group이 가지는 Policy 확인
3. User 가 위임된 Role 의 가지는 Policy 확인

User 부분이 어플리케이션, 서비스(Lambda) 로 치환될 수 있다.

시그니쳐

현재 User 종류로는 아래 2가지가 존재한다.

Root User
결제, 관리의 계정권한을 가짐, 해킹시 매우 위험하기에 사용하지 않는것을 권장
Access Key, Secret Key 가 존재하지 않음으로 AWS API 호출 불가하다.

IAM User
Root User에 의해 생성되는 사용자 혹은 어플리케이션 권한으로 [Access Key, Secret Key] 를 사용하여 AWS API 호출한다.

Root User 에 준하는 IAM User 의 경우 MFA(멀티 팩터 인증: 다단계 인증) 을 권장한다.
AdministratorAccess - 빌링을 제외한 모든 권한을 설정하여 Admin IAM User 생성가능

보안 주체의 시그니쳐(Credential)를 통해 사용자를 식별, 인증하고
Policy 를 확인하여 해당 요청은 허락, 인가한다.

시그니쳐는 [Access Key, Secret Key] 를 해시연산 등을 통해 생성되고
항상 AWS API 를 사용할때 아래형식과 같이 HTTP 헤더에 포함된다.
시그니쳐 생성방식은 version2 와 version4 가 있으며 대부분 version4 를 사용한다.

[Access Key, Secret Key] 를 알고있다 하더라도 시그니쳐를 생성하는 방식이 매우 복잡하기 때문에 직접 생성보단 libraray 사용을 권장

IAM Policy 개요

리소스에 대한 인가 기능을 제공하는 서비스로 IAM Policy 는 아래 4가지 구성요소에 대한 정의를 JSON 으로 구성한다.

• Principal: 주체
• Condition: 조건
• Resouce: 자원
• Action: 행위

{
    "Version": "2012-10-17",
    "Statement": [ // 정책의 묶음
        {
            "Effect": "Allow Or Deny", 
            "Principal": [...], // 접근 허용여부 대상(User, Role) 기술
            "Action": [...], // 행위목록 기술
            "Resource": [...], // 접근할 AWS 리소스 기술
            "Condition": [...], // 조건부 기술
        }
    ]
}

모든 액션과 모든 리소스에 대한 접근허용을 할 경우 아래 정책생성
어드민 권한에 준하는 정책이다.

{
    "Effect": "Allow", 
    "Action": "*",
    "Resource": "*",
}

만약 1.1.1.1 IP에서 DynamoDB 의 table/MyTable 테이블에 Read/Write 만을 할 경우 아래와 같이 detail 한 정책을 정의하는 것이 보안에 유리하다.

{
    "Effect": "Allow", 
    "Action": [
        "dynamodb:GetItem",
        "dynamodb:PutItem"
    ],
    "Resource": "arn:aws:dynamodb:us-east-2:.....:table/MyTable",
    "Condition": {
        "IPAddress": {
            "aws:SourceIp": "1.1.1.1"
        }
    }
}

아래와 같은 여러 종류의 IAM Policy 를 제공한다.

Identity based(Permission Boundary, Permision Policy)

기장 범용적으로 믾이 사용되는 IAM Policy.

요청자 IAM Principal(User, Role) 에 대한 상세 권한 경계를 설정할 수 있다.
가장 흔히 사용되는 사용자에 대한 접근 제한을 거는 것이 Permision Policy 이다.

Permission Boundary 는 2018년 추가된 기능으로 아래 그림처럼 추가적으로 방화벽 한대를 더 두어 사용자나 Role 의 IAM Principal를 제한하는 역할을 한다.

묵시적 Deny
방화벽에 맨 마지막에 default all deny 를 추가하는 것 처럼
AWS Policy 도 별다른 선언이 없다면 자동으로 Deny 되버린다.

명시적 Allow
Permission Boundary, Permision Policy 모두 리소스에 대한 Allow 를 정의해두었을 때를 뜻한다.

즉 Permission Boundary, Permision Policy 라는 2개의 방화벽이 JSON 으로 정의되어 있고 명시적 Allow, 명시적 Deny, 묵시적 Deny 3개의 법칙에 따라 Allow/Deny 될 수 있다.

// Permission Boundary
{
    "Effect": "Allow", 
    "Action": [
        "log:CreateLogGroup",
        "log:CreateLogStream",
        "log:PutLogEvents",
    ],
    "Resource": "arn:aws:logs:*",
}

// Permission Policy
{
    "Effect": "Allow", 
    "Action": [
        "log:CreateLogGroup",
        "log:CreateLogStream",
        "log:PutLogEvents",
        "s3:*",
    ],
    "Resource": "*",
}

위와같이 IAM Policy 2개를 정의했을 때
arn:aws:logs:* 리소스에 대한 권한, log:... 액션에 대한 권한은 명시적 Allow 라 할 수 있다.

하지만 arn:aws:logs:* 를 제외한 리소스들, log:... 외의 액션(s3:*) 에 대해서는 Permission Policy에만 정의되어 있고 Permission Boundary 에는 정의되어 있지 않다.

Permission Boundary 입장에선 묵시적 Deny 로 해당 요청은 차단된다.

Resource based(리소스 기반 정책)정책

요청을 받는 리소스에 연결되어 정책을 검사한다.

인라인 정책을 리소스에 연결합니다. 리소스 기반 정책의 가장 일반적인 예제는 Amazon S3 버킷 정책 및 IAM 역할 신뢰 정책입니다. 리소스 기반 정책은 정책에 지정된 보안 주체에 권한을 부여합니다. 보안 주체는 리소스와 동일한 계정 또는 다른 계정에 있을 수 있습니다.

{
    "Effect": "Allow Or Deny", 
    "Action": [...], // 행위목록 기술
    "Resource": [...], // 접근할 AWS 리소스 기술
    "Condition": [...], // 조건부
    "Principal": "*" 
}

Resource based 에서는 Principal(보안주체) 가 추가로 정의되어야 한다.

위의 Identity based, Resource based 두 군데에서 모두 정책을 추가하게 되면 내용이 중복될 가능성이 있다

두 정책이 동일 어카운트에서 생성되었을 경우 합집합의 형태로 검사가 이루어진다.

IAM Policy - SCP(Service Control Policy)

AWS Organization, 멀티 계정을 관리하는 SCP 를 적용해서

팁 - Tag

특정 사용자에게 리소스를 그룹핑해서 권한을 관리하고 싶을때

위 그림처럼 각 리소스 에 tag 를 지정하고 condition 에 tag 조건을 지정할 수 있다.

또한 사용자에게도 tag를 지정하면 동적으로 IAM Role 를 지정해 쉬운 관리가 가능하다.

팁 - In Accout, Cross Account

만약 A계정에서 B계정에서 만든 리소스(S3) 에 접근하고 싶을때

A계정에서 정의한 IAM Policy(Identity Based) B계정에서 정의한 IAM Policy(Resource Based) 가 방화벽 역할을 한다.

어떤 보안정책에 막힐지는 각 IAM Policy 에서 명시적 Deny 와 묵시적 Deny 가 있는지 모두 확인해보아야 한다.

IAM Role

토큰기반으로 운영되며 임시 보안 자격증명을 부여할 때 많이 사용한다.
IAM User 와 같이 특정 권한을 가진 IAM 자격 증명 역할을 하는 리소스이지만 역할은 한 사람과만 연관되지 않고 해당 역할이 필요한 사람이라면 누구든지 맡을 수 있다.

IAM Policy(Resource Based) 에 Principal(보안주체) 로 IAM User 와 Action 을 를 일일이 매핑하여 기입하다 보면 복잡해지고 보안상으로 이슈가 많이 생기는데 이를 IAM Role 로 관리하면 편리해진다.

사용자에게 직접 권한을 주지 않고 RBAC(Role-Based Access Control) 로 보안운영시에 사용된다.

사용자에게는 sts:AssumeRole 라는 특정 IAM Role 를 임시로 빌릴수 있는 Action 만을 허용해주고 Role:EC2Administrator 와 같은 IAM Role 를 빌려와서 EC2를 생성할 수 있도록 관리하면 좋다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::ACCOUNT-NUMBER:role/ROLE-NAME" // Role Name
        }
    ]
}

만약 Dev Account 에서 운용중인 서비스 혹은 개발자가 Product 환경에서의 DynamoDB에 접근하고 싶다면
관리자가 Product Account 에 IAM User 를 생성후 계정을 알려주면 되지만
이렇게 하기보단 DynamoDB에 접근할 수 있는 IAM Role 을 생성후 Principal 에 Dev Account 를 지정하면 해당 계정만 사용할 수 있는 IAM Role 이 생성하는 것을 권장한다.