[AWS] IAM User/Role/Policy & Service Role

IAM

IAM 구성 요소

구성 요소	역할	예시
IAM User / Principal	AWS에 API 요청을 보내는 주체  (사람, 애플리케이션, 서비스 등)	엔지니어 계정, Lambda 함수
IAM Role	임시로 "권한 세트(Policy)"를 위임받는 신분	EC2 인스턴스 역할,  CloudFormation 서비스 역할
IAM Policy	어떤 리소스에 대해 어떤 작업을 허용/거부할지 정의하는 권한 규칙 세트	`s3:PutObject`, `dynamodb:Query` 등
Service Role	AWS 서비스가 대신 API를 호출할 때 사용하는 특수 IAM Role	CloudFormation, Lambda, ECS, EC2, Step Functions 등.

---

IAM Role

• Role = 신분(Identity) + Trust policy (누가 맡을 수 있는가) + Permission policy (무엇을 할 수 있는가)
• Role 자체에는 장기 인증 자격 증명(access key)이 없고, 대신 누군가(role/user/service)가 AssumeRole 해서 임시 credential을 받아 사용한다.

# Trust policy (누가 이 Role을 맡을 수 있는가?)
Principal: ec2.amazonaws.com

# Permission policy (맡은 후 뭘 할 수 있는가?)
Action: s3:*, dynamodb:*

 

---

출처 : https://blog.devgenius.io/ - AWS IAM Basics — Key terminology

IAM policy

유형	연결 대상	설명
Identity-based Policy	User, Group, Role에 붙음	"이 주체가 어떤 행동을 할 수 있는가?" 정의
Resource-based Policy	S3 버킷, Lambda, SNS, SQS 등에 붙음	"누가 나에게 접근할 수 있는가" 정의 (`Principal` 포함)
Permissions Boundary	Role/User에 제한적으로 부착	붙은 주체가 가질 수 있는 권한의 최대치 상한선
SCP (Service Control Policy)	AWS Organizations 계정/OU 단위	계정 수준에서 가능한 API 전체 제한

 

Customer-managed vs. Inline Policies

	AWS Managed	Customer Managed	Inline policies
관리 주체	AWS	사용자	사용자
권한 수정 가능 여부	X	O	O
정책에 적용 가능한 원칙 (Principals) 수	Many	Many	One (Policy-to-Identity)

---

Service Role

"AWS 서비스가 나 대신 무언가를 수행해야 할 때, 그 서비스가 사용할 권한을 정의한 IAM Role"

 

• Service Role = 특정 AWS 서비스가 Assume 하는 Role
• 서비스 > Role Assume > API 호출 수행

---

예시

1. Trust Policy (누가 이 Role을 맡을 수 있는가?)

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudformation.amazonaws.com" },
  "Action": "sts:AssumeRole"
}

 

2. Permission Policy (맡았을 때 무슨 일을 할 수 있는가?)

{
  "Effect": "Allow",
  "Action": [
    "ec2:*",
    "s3:*",
    "iam:CreateRole"
  ],
  "Resource": "*"
}

---

☆ Permission Boundary

이 주체(User/Role)가 아무리 많은 정책을 가져도, 이 경계에 정의된 권한을 절대 넘을 수 없다.

• Identity-based policy가 "S3:DeleteBucket 허용"이라도,
• Permissions Boundary에서 "S3:DeleteBucket 금지"면 결국 못함.

---

예시

1. EC2만 허용하는 Permission Boundary

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:*",
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

 > 어떤 사용자가 이 Boundary를 가진다면, 그 사용자가 EC2 외의 API는 절대 실행 불가.

 

2. IAM Role 생성 위임 + 제한

{
  "Effect": "Allow",
  "Action": [
    "iam:CreateRole",
    "iam:PutRolePermissionsBoundary"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "iam:PermissionsBoundary": "arn:aws:iam::123456789012:policy/DevBoundary"
    }
  }
}

 > 개발자는 Role(역할)을 생성할 수 있지만, 반드시 `DevBoundary`를 Permission Boundary로 지정해야 함.

---

출처 : https://blog.devgenius.io/ - AWS IAM Basics — Key terminology

권한 평가 순서

1) SCP → AWS Organizations 단위 (최상단)
2) IAM Inline Policies
3) IAM Managed Policies
4) Permission Boundary → User/Role 상한
5) Session Policies
6) Resource Policies → 리소스의 허용/거부 조건
 **Explicit Deny → 최우선 (어디에 있든 최종 거부)

 

최종 허용 조건:

모든 정책에서 허용되고, 어느 정책에서도 명시적 Deny가 없어야 함.

---

참고 자료

 - Managed policies and inline policies - AWS Identity and Access Management

 - Policies and permissions in AWS Identity and Access Management - AWS Identity and Access Management

 - AWS IAM Basics — Key terminology. IAM 101 | by Amit Singh Rathore | Dev Genius

 - AWS IAM 기초 (User, Role, Policy 생성) :: Cloud Man

 - AWS IAM 역할(Role)은 정확히 무엇인가요? 어떻게 써야 할까요 | 조은우 기술 블로그

 - 

 

Powered By. ChatGPT