[Study][AWS 보안] IAM 보안 - 기본 지식

AWS IAM 보안

AWS Identity and Access Management(IAM)은 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스로, AWS 리소스를 제어하는 권한을 중앙에서 관리할 수 있다. AWS 계정을 생성하면 최초 root 계정으로 로그인하게 되고, root계정으로 각 역할에 맞는 IAM계정을 생성해 AWS 작업을 수행한다.

AWS를 처음 사용하거나 상대적으로 보안에 관심이 적은 회사, 스타트업 등에서 root 계정을 사용해 직접 작업을 하기도 하는데, AWS에서도 root계정 권한이 필요한 작업이 아니라면 별도의 IAM을 생성해 작업할 것을 강력히 권고하고 있다.

일상적인 태스크에 루트 사용자를 사용하지 않을 것을 강력히 권장합니다. 루트 사용자 보안 인증 정보를 보호하고 루트 사용자만 수행할 수 있는 작업을 수행하는 데 사용합니다. 루트 사용자로 로그인해야 하는 태스크의 전체 목록은 AWS Account Management 참조 안내서의 Tasks that require root user credentials(루트 사용자 보안 인증이 필요한 태스크)를 참조하세요.

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/introduction.html

IAM이란 무엇입니까? - AWS Identity and Access Management

 

AWS 리소스에 대한 권한을 다루는 서비스다보니 규모에 따라 별도의 IAM 보안 담당자가 있는 경우도 있으며, IAM 설정 미스나 AccessKey 노출로 인해 다양한 보안사고가 발생하기도 한다.

https://www.ciokorea.com/news/232619

“클라우드 계정 99% 과잉 권한… 해커에게 문 열어주는 격”

IAM 동작이나 세부적인 내용에 대한 것을 공부차원에서 간략하게 정리하였다.

 

IAM 구성 요소

• IAM 사용자(users) : 사용자 계정이나, Access  Key와 같은 AWS를 사용하기 위한 자격증명
• IAM 그룹(groups) : 다수의 IAM 사용자에게 할당해 공통 권한을 부여하기 위한 모음
• IAM 역할(roles) : 특정 권한을 가진 자격증명으로, 다수의 IAM 사용자가 역할을 할당받을 수도 있고, 임시로 부여받을 수도 있다.
• IAM 정책(policy) : IAM 권한(허가, 거부 등)을 명시한 리소스, 정책은 IAM 사용자와 역할에 부여함

상세한 내용은 아래의 홈페이지에서 잘 설명되었으니 추후 참고
https://dev.classmethod.jp/articles/what-is-aws-iam-kr/

IAM 살펴보기 기초편 | DevelopersIO

 

IAM 정책

총 6가지 정책이 있으며 주로 자격 증명 기반 정책과, 리소스 기반 정책이 사용된다.

자격 증명 기반 정책
리소스 기반 정책
사용 권한 경계(Permissions boundary)
Organizations SCP
액세스 제어 목록(ACL)
세션 정책

• AWS 공식문서 IAM의 정책 및 권한 : https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/access_policies.html
• IAM Permissions Boundary : https://blog.wisen.co.kr/pages/blog/blog-detail.html?idx=9162

 

IAM 정책은 주로 아래와 같이 2가지를 선택 또는 생성해서 사용한다.

관리형 정책

실제 AWS에 접속해 IAM을 생성하면 다양한 정책 목록을 확인할 수 있는데, 자주 사용될만한 것들을 AWS에서 기본 정책으로 작성해 제공해준다. 바로 적용해서 사용하기 쉽고 간편하나, 정책을 수정할 수는 없다.

AWS에서 제공하는 관리형 정책

 

고객관리형 정책

하지만 IAM계정을 발급받아 사용하는 담당자의 업무의 특성에 따라 별도의 정책이 필요할 수 있는데, 이 때 별도로 IAM 정책을 생성해 할당할 수 있다. 정책은 아래와 같은 문법으로 구성되며, 한땀한땀 손으로 적을 수도 있긴한데 오타나 잘못된 정책을 작성할 수도 있으므로 처음부터 작성할 때는 시각적 정책 편집기를 써서 생성하는게 조금이나마 오타를 줄일 수 있는 방법이다.

policy  = {
    "Version" : ("2008-10-17" | "2012-10-17")
    "Id" : <policy_id_string>
    "Statement" : [
        "Sid" : <sid_string>,
        ("Principal" | "NotPrincipal") : ("*" | { <principal_map_entry>, <principal_map_entry>, ... }),
        "Effect" : ("Allow" | "Deny"),
        ("Action" | "NotAction") : ("*" | [<action_string>, <action_string>, ...]),
        ("Resource" | "NotResource") : : ("*" | <resource_string> | [<resource_string>, <resource_string>, ...]),
        "Condition" : {
            <condition_map> = { 
                <condition_type_string> : { <condition_key_string> : <condition_value_list> },
                <condition_type_string> : { <condition_key_string> : <condition_value_list> }, ...
            }  
        }
     ]
}

시각적 IAM 정책 편집기

필요한 권한을 체크하고 바로 IAM정책을 생성할 수도 있고, JSON으로 변환해서 볼 수도 있다.

JSON 기반 IAM 정책 편집기

 

IAM 정책 평가

하나의 AWS 리소스에 대해 여러 IAM 정책이 부여된다면 어떻게 될까?
어떤 정책은 S3에 접근 허용인데, S3 리소스 자체에서는 접근 거부 정책인 경우가 존재할 수 있다.
이럴 때 AWS는 기본적으로 명시적 Deny(거부)를 Allow(허용)보다 우선한다.

• 기본적으로 전체 액세스 권한이 있는 AWS 계정 루트 사용자를 제외한 모든 요청은 암시적으로 거부
• 자격 증명 기반 또는 리소스 기반 정책의 명시적 허용은 이 기본값을 재정의
• 권한 경계, 조직 SCP 또는 세션 정책이 있는 경우 암시적 거부로 허용을 재정의할 수 있음
• 모든 정책의 명시적 거부는 허용보다 우선 적용됨

아래는 단일 계정 내에서의 정책 평가 순서도이다.

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html

Policy evaluation logic - AWS Identity and Access Management

 

다수의 AWS 계정 간의 접근 권한은 교차계정 평가로직에 따라
1. 요청하는 사용자가 신뢰하는 AWS Account에 존재하는지를 확인하고, 해당 사용자가 부여받은 자격증명 기반 정책을 확인한다.
2. 요청한 리소스가 신뢰하는 AWS Account에 존재하는지를 확인하고, 해당 리소스가 부여받은 리소스 기반 정책을 확인한다.
3. 1과 2에서 모두 허용될 때 요청이 허용된다.

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html

Cross-account policy evaluation logic - AWS Identity and Access Management

 

위의 내용을 종합해서 정리한 내용의 글이 있어 읽어보았는데, 몇몇 이미지 내용이 일본어 인 것을 제외하면 이해하기 쉽게 정리되어있었다.

https://dev.classmethod.jp/articles/new-policy-evaluation-logic-flow-chart/

新しくなった IAM 評価論理フローチャートをひとしきり愛でてみた | DevelopersIO

 

S3의 Pre-Signed와 같은 경우 내부적으로 허용 임시 정책을 할당받은 케이스이다.

https://dev.classmethod.jp/articles/increase-the-expiration-time-of-s3-pre-signed-url/

S3 pre-signed url(미리 서명된 url) 유효 기간 늘리기 | DevelopersIO