[AWS] AWS IAM(Identity and Access Management), Policy

1. AWS IAM(Identity and Access Management) 이란?

AWS IAM(Identity and Access Management)는 AWS 전체의 권한을 통제하는 시스템을 말한다. 

 

IAM에서 Identity는 AWS로 요청을 할 수 있는 보안주체(Principal)를 AWS 어카운트 내에 만드는 도구 

Access Management 누가 어떤 리소스들에 대해 어떤 일을 할 수 있는 권한을 가지는지를 정의하는 도구

로 이루어져 있다. 

 

AWS의 모든 요청은 인증(Authentication)과 인가(Authorization) 과정을 거칩니다.

• 인증(Authentication): "너 진짜 그 사람 맞아?"를 확인하는 과정입니다. (로그인, 액세스 키 확인)
• 인가(Authorization): "너 이거 할 권한 있어?"를 확인하는 과정입니다. (S3 읽기 권한 등)

2. 보안 주체의 종류 ( User, Role...)

AWS의 Root 계정은 모든 권한을 가진 '슈퍼 유저'이므로 일상적인 작업에 사용하는 것은 매우 위험합니다.

그래서 우리는 다음과 같은 보안 주체를 만들어 사용합니다.

구분	IAM User (사용자)	IAM Role (역할)
특징	장기 자격 증명 (ID/PW, Access Key)	임시 자격 증명 (STS 활용)
보안성	유출 시 위험 (주기적 로테이션 필요)	자동 로테이션되어 안전함
구성 요소	Access Key, Secret Key	Access Key, Secret Key, Session Token
사용 방식	특정 개인이나 고정된 서비스에 할당	Assume(어쑴): 일시적으로 권한을 빌려 씀

 

AWS에서 모든 보안 주체는 AWS에 API 요청을 할 때 Access key / Secret Access key 로 구성된 Credential을 포함해서 인증을 받게 된다. 

 

AWS에서 IAM User의 경우에는 장기 Credential을 이용한다.

즉, 관리자가 명시적으로 Credential 정보를 로테이션 하지 않는 이상 영구적으로 유지되며, 이 자격증명을 서버에 하드코딩이나, 코드에 사용하는 것은 보안적으로 상당히 위험할 수 있다. 

 

하지만 IAM Role의 경우에는 정의된 권한 범위 내에서 AWS API를 사용할 수 있는 임시 자격 증명으로 
Role의 경우 자동으로 로테이션되는 임시 자격 증명을 사용하기 때문에, 장기 Credential을 설정해서 사용하는 것 보다 

훨씬 안전하게 사용할 수 있다. 

 

임시 Credential의 경우  Access key / Secret Access key 뿐만 아니라 일정 시간이 지나면 만료되는 Token이 함께 구성되어 있어 발급된다. 

 

IAM Role를 사용하면 사용자 권한을 공유하거나 매번 필요한 권한 부여가 불 필요하고 안전하게 사용할 수 있다.

그리고 Role을 사용하는 것을 Assume(어쑴)이라고 한다. 

Assume을 하면 임시 Credential을 발급받아 특정 액션을 수행할 수 있게 된다. 

 

예를 들어, AWS 외부에 존재하고 있는 IAM User가 아닌 보안주체에게 임시적으로 권한을 수행하기 위해 IAM Role 사용할 수 있다.

이런경우 SAML이나 OpenIDC같은 연계 프로토콜을 사용해서 외부 사용자를 IAM Role과 매핑해주게 된다. 

 

기업에서는 규모가 커지면서 보안 등의 목적으로 계정을 여러개로 나누어서 운영하는데, 

이런 경우 또 아예 외부는 아니지만 다른 AWS Account에 접근할 때, A 계정이 B 계정에서 만든 S3 자원을 보고 싶은 Cross Account
상황에서도 Role를 사용해서 임시 자격증명을 발급해 안전한 접근을 구현할 수 있다. 

3. IAM 정책(Policy)

모든 AWS 서비스는 접근제어 정책을 기반으로 인가가 된다. 

여기서 정책은 IAM Role, User, Group, AWS리소스, 임시 자격증명 세션, OU 등이 적용 대상이 된다. 

 

AWS 정책을 만들 때 반드시 기억해야할 점은 기본값이 Deny이고, 명시적 Allow < 명시적 Deny의 우선순위가 더 높기 때문에 

이런 특성을 이해하고 정책을 작성해야한다. 

요청이 성공하기 위한 조건

 

AWS 정책은 JSON 형식이며 다음과 같은 구조로 정의된다. 

AWS 정책의 JSON  구조

 

4. IAM 정책(Policy)의 종류

AWS의 정책은 다음과 같은 종류로 나뉜다. 

• Identity-based 정책: 사용자/그룹/역할에 직접 붙이는 정책 (가장 일반적).
• Resource-based 정책: S3 버킷이나 KMS 키 등 리소스에 직접 붙이는 정책. (Principal 구문 필수)
• Permission Boundary: 보안 주체가 가질 수 있는 '최대 권한 범위' 설정.
• Organization SCP: 조직(OU) 전체 또는 계정별 권한 가이드라인(Root 권한 제한용).
• Session 정책: AssumeRole 시 실시간으로 권한을 더 좁힐 때 사용.
• ACL: 리소스 중심의 오래된 제어 방식 (주로 S3, VPC 등에서 사용).
• Endpoint 정책: VPC 엔드포인트를 거쳐가는 트래픽에 대한 제어

 

 

사진을 통한 설명을 보면  identity-based 정책은 요청하는 주체에게 연결되고 Resource-based정책은 요청을 받는 리소스에 연결되는 정책이란 것을 알 수 있다.

 

Resource-based정책에는 Principal이라는 한가지 구문이 필수적으로 더 들어가는데 Principal은 구문에 해당 리소스에 요청을 전달할 수 있는 보안 주체를 기술한다.

즉, 사진 예시에서 Principal에 GetObject 요청을 하는 주체가 포함되어야 요청이 성립가능하다.

 

identity-based 정책과 Resource-based정책의 커버리지는 동일 Account인지, Cross Account 환경인지에 따라 다르다.

identity-based 정책은 접근을 하기 위한 정책이고 Resource-based정책은 접근을 받기 위한 정책이다. 

 

자연스럽게 하나의 요청을 허용 또는 차단하기 위한 정책을 양쪽에 다 기술한다면 정책의 내용이 겹칠 수 밖에 없다.

이런경우 동일 Account 환경의 경우 두 개의 정책이 합집합(OR) 형태로 요청 권한 검사가 이루어진다.

Cross Account 환경의 경우 공집합 형태(AND)로 검사가 이루어지는 차이가 있다.

 

그래서 사진의 예시의 경우 한쪽에만 Allow 정책이 정의되어 있는 경우 동일 Account의 경우 요청이 허용되고,
Cross Account일때는 요청이 거부된다. 

 

그리고 두 개의 정책이 모두 있는 경우에는 Deny 정책이 우선되므로 동일 Account, Cross Account 환경 모두에서 요청이 차단된다.

 

📖 용어 정리

• Cross Account : Account A에 있는 사용자나 서비스가 다른 AWS 계정에 있는 자원에 접근해야 하는 상황
• OpenIDC : 현대적인 웹과 모바일 환경에 최적화된 차세대 인증 프로토콜
• SAML (Security Assertion Markup Language) : 기업용 환경에서 많이 쓰이는 '통합 로그인(SSO)' 표준
• Credential : 신원증명정보
• Principal : 시스템에 접근을 요청하는 주체
• Assume : 특정 작업에 필요한 권한을 잠시 빌리는 행위 

학습에 참고한 강의 및 사진 출처 
https://www.youtube.com/watch?v=zIZ6_tYujts