AWS 리소스에 대한 액세스를 안전하게 제어할 수 있는 웹 서비스.
사용자가 리소스를 사용하기위해 IAM을 사용한 인증(로그인) 및 권한 확인을 거치게 한다
AWS 계정을 처음 생성할 때는 해당 계정의 모든 AWS 서비스 및 리소스에 대한 완전한 액세스 권한이 있는 SSO(Single Sign-In) ID, 즉 AWS 계정 루트 사용자로 시작한다. 계정을 생성할 때 사용한 이메일 주소와 암호로 로그인하여 액세스한다.
일상적인 작업은 물론 관리 작업에도 루트 사용자를 사용하지 않는 것이 좋다. 루트 사용자 자격 증명을 안전하게 보관해 두고 몇 가지 계정 및 서비스 관리 작업을 수행할 때만 해당 자격 증명을 사용하자.
AWS 계정에 대한 공유 액세스
암호나 액세스 키를 공유하지 않고도 AWS 계정의 리소스를 관리하고 사용할 수 있는 권한을 다른 사람에게 부여.
세분화된 권한
리소스에 따라 여러 사람에게 다양한 권한 부여 가능.
Amazon EC2에서 실행되는 애플리케이션을 위한 보안 AWS 리소스 액세스
EC2 인스턴스에서 실행되는 애플리케이션의 경우 IAM 기능을 사용한 자격 증명 가능.
이러한 자격 증명을 통해 다른 AWS 리소스 접근 권한을 애플리케이션에 제공.
리소스 예시: S3 버킷, DynamoDB 테이블, etc.
멀티 팩터 인증(MFA)
보안 강화를 위해 계정과 개별 사용자에게 2팩터 인증
추가 가능.
MFA를 사용할 경우 암호나 액세스 키 외에도 특별히 구성된 디바이스의 코드를 제공해야 한다.
자격 증명 연동
다른 곳에(기업 네트워크나 인터넷 자격 증명 공급자) 이미 암호가 있는 사용자에게 AWS 계정에 대한 임시 액세스 권한 부여 가능.
보장을 위한 자격 증명 정보
AWS CloudTrail을 사용하는 경우 계정의 리소스를 요청한 사람에 대한 정보가 포함된 로그 기록를 받음.
이 정보는 IAM 자격 증명을 기반으로 한다.
PCI DSS 준수
전자 상거래 웹사이트 운영자 또는 서비스 공급자에 의한 신용 카드 데이터의 처리, 저장 및 전송을 지원.
자세한 내용은 PCI DSS 레벨 1을 참조.
최종 일관성
IAM은 다른 많은 AWS 서비스처럼 eventually consistent에 해당된다. IAM에서는 전 세계의 Amazon 데이터 센터 내의 여러 서버로 데이터를 복제함으로써 고가용성을 구현하므로, 일부 데이터를 변경하겠다는 요청이 성공하면 변경이 실행되고 그 결과가 안전하게 저장된다.
그러나 변경 사항이 IAM에 두루 복제되는데는 일정한 시간이 걸리는데, 이러한 변경 사항에는 사용자, 그룹, 역할 또는 정책을 만들거나 업데이트한 것이 포함된다. 따라서 그러한 IAM 변경 사항을 애플리케이션의 중요한 고가용성 코드 경로에 포함시키지 않는 것이 좋다.
무료 사용
AWS IAM, STS은 무료 기능.
하지만 IAM 사용자 또는 AWS STS 임시 보안 자격 증명을 사용하여 다른 AWS 서비스에 액세스하는 경우에는 요금이 부과된다.
AWS Management 콘솔
브라우저 기반 인터페이스.
AWS CLI(명령줄 도구)
두 가지 명령줄 도구 세트 AWS CLI, AWS 도구(Windows PowerShell 용)를 제공.
AWS SDK
다양한 프로그래밍 언어 및 플랫폼(Java, Python, Ruby, .NET, iOS, Android 등)을 위한 라이브러리와 샘플 코드로 구성된 소프트웨어 개발 키트(SDK)를 제공.
IAM HTTPS API
서비스로 직접 HTTPS 요청을 실행할 수 있는 IAM HTTPS API를 사용하여 프로그래밍 방식으로 IAM 및 AWS에 액세스 가능. HTTPS API를 사용할 때는 자격 증명을 사용하여 요청에 디지털 방식으로 서명하는 코드를 포함해야 한다.
Resources (리소스)
IAM에 저장된 user(사용자), group(그룹), role(역할), policy(정책) 및 identity provider(자격 증명 공급자) 객체.
IAM에서 리소스를 추가, 편집 및 제거 가능.
Identities (ID)
식별 및 그룹화에 사용되는 IAM resources 객체.
IAM identity(자격 증명)에 policy를 attach(연결)할 수 있습니다. users, groups, roles가 포함된다.
Entities (엔터티)
AWS가 인증에 사용하는 IAM resources 객체.
IAM users, federated(연합된) users, assumed(상정된) IAM roles가 포함된다.
Principals (보안 주체)
AWS 계정 루트 사용자, IAM 사용자 또는 IAM 역할을 사용해 로그인하고 AWS에 요청을 보내는 사람 또는 애플리케이션.
Principal은 AWS 계정 루트 사용자 또는 IAM 엔터티로 인증되어 AWS resource에 대한 요청을 보낸다.
principal이 AWS Management Console, AWS API 또는 AWS CLI 사용을 시도할 때, request가 AWS에 전송된다. request는 다음 정보를 포함한다.
Actions or operations (작업 또는 작동)
principal이 수행하고자 하는 actions 또는 operations.
AWS Management Console -> Actions
AWS CLI, AWS API -> Operations
Resources (리소스)
actions 또는 operations이 수행되는 AWS resource 객체.
Principal (보안 주체)
entity(user 또는 role)를 사용해 요청을 보내는 사람 또는 애플리케이션. principal에 대한 정보에는 entity(principal이 로그인에 사용한)에 연관된 policy가 포함된다.
Environment data (환경 데이터)
IP 주소, user agent, SSL enabled status 또는 시간대와 같은 정보.
Resource data (리소스 데이터)
요청되는 리소스와 관련된 데이터.
DynamoDB 테이블 이름 또는 Amazon EC2 인스턴스의 태그와 같은 정보가 포함될 수 있다.
AWS는 요청의 평가, 승인에 사용되는 정보를 모아 request context에 담는다.
principal은 AWS에 요청을 보내려면 무조건 credentials(자격 증명)를 사용해 인증(AWS에 로그인)해야 한다.
Amazon S3, AWS STS 같은 일부 서비스는 익명 사용자의 몇 가지 요청을 허용하지만, 이는 예외로 봐야한다.
보낸 요청은 인가되어야만(authorized, allowed) 완료된다. AWS는 authorization 과정에서 request context의 값을 사용해 해당 요청에 적용할 policies를 확인한다. 이 후 그 policies를 바탕으로 요청의 허용/거부를 결정한다. 대부분의 policies는 AWS에 JSON 문서로 저장되고, principal entities의 permissions(허가, 권한)를 명시한다. 요청의 인가 여부에 영향을 미칠 수 있는 policies 유형들이 존재한다.
사용자 계정의 AWS resources로의 접근 권한은 오직 identity-based policies로만 제공할 수 있다.
Resource-based policies는 cross-account access(교차 계정 액세스)를 제공하기 좋다.
AWS은 사용자의 request context에 적용되는 각각의 policy를 체크한다. 만약 어떤 한 permissions policy에 denied action(거부된 작업)이 포함되어 있으면, AWS는 모든 요청을 거부하고 평가를 중지한다. 이를 explicit deny
(명시적 거부)라고 한다.
요청은 기본적으로 거부되므로, AWS는 오직 적용 가능한 permissions policies에서 요청의 모든 부분이 허용되는 경우에만 요청을 인가한다. 단일 계정에서 요청의 evaluation logic(평가 로직)은 다음 일반 규칙을 따른다.
기본적으로 모든 요청을 거부.
(일반적으로, AWS 계정 루트 사용자 credentials를 사용한 해당 계정의 리소스 요청은 항상 허용.)
(identity-based 또는 resource-based) permissions policy에 포함된 explicit allow(명시적 허용)가 기본 규칙을 덮어쓴다(override).
조직 SCP, IAM permissions boundary 또는 session policy이 존재하는 경우, allow(허용)는 재정의된다. 만약 이러한 policy 유형이 하나 이상 존재하면 이들 모두가 해당 요청을 허용해야만 인가된다. 그렇지 않은 경우 묵시적으로 거부된다(implicitly denied).
explicit deny는 어떠한 policy에 있든 간에 그 어떤 허용(allows)도 덮어쓴다.
사용자가 다른 계정에서 요청을 보내는 경우, 접근하고자 하는 resource 소유 계정의 policy에서 사용자의 resource 접근을 허용하고, 요청을 보내는데 사용한 IAM 엔터티에도 해당 요청 전송을 허용하는 identity-based policy가 있어야 한다.
요청이 인증 및 인가된 이 후, AWS는 요청의 action 또는 operation들을 승인한다. operations는 보기, 생성, 편집 및 삭제와 같이 리소스에 대해 수행할 수 있는 사항들을 포함하며, 서비스에 의해 정의된다.
예를 들어, IAM은 user resource에 대해 다음을 포함한 약 40가지 action들을 지원한다.
principal이 operation을 수행하는 것을 허용하려면, policy(해당 principal 혹은 영향 받는 resource에 적용되는)에 필요한 action들을 포함해야 한다.
AWS가 요청의 operation들을 승인하면, 사용자 계정의 관련 리소스에서 수행 가능해진다. resource는 서비스 내에 존재하는 객체로 Amazon EC2 인스턴스, IAM user 및 Amazon S3 bucket을 예로 들 수 있다. 서비스는 각 resource에서 수행할 수 있는 일련의 action들을 정의한다.
만약 리소스에서 관련없는 작업 수행을 요청하면, 해당 요청은 거부된다. 예를 들어 IAM role 삭제 요청을 보내면서 IAM group resource를 입력한다면, 요청은 실패한다.