IAM과 RBAC 차이: AWS, Azure, GCP 기준으로 이해하기

"개발자에게 S3 읽기 권한을 주려면 IAM으로 해야 하나요, RBAC로 해야 하나요?" — 이 질문 자체가 두 개념의 관계를 혼동하고 있다는 신호입니다. IAM은 접근 제어 시스템 전체를 가리키고, RBAC는 그 안에서 권한을 부여하는 방식 중 하나입니다.

핵심 요약

• IAM(Identity and Access Management)은 "누가, 무엇에, 어떤 작업을 할 수 있는가"를 관리하는 시스템 전체를 의미합니다.
• RBAC(Role-Based Access Control)는 역할(Role)을 기준으로 권한을 묶어서 부여하는 접근 제어 모델입니다.
• AWS는 IAM 안에서 Policy 기반(ABAC/PBAC)과 Role 기반(RBAC)을 혼합하여 사용합니다.
• Azure는 IAM 계층 안에서 RBAC를 명시적으로 분리한 구조(Azure RBAC)를 제공합니다.
• GCP는 IAM 안에서 Role을 중심으로 권한을 부여하되, Predefined Role과 Custom Role로 유연성을 확보합니다.
• 실무에서는 "RBAC만 쓴다" 또는 "IAM만 쓴다"가 아니라, 각 클라우드의 IAM 시스템 안에서 RBAC 원칙을 어떻게 적용할지 설계하는 것이 핵심입니다.

1. IAM과 RBAC는 어떤 관계인가

1.1 시나리오: 신입 개발자 온보딩

팀에 신입 개발자가 합류했습니다. 이 개발자에게 다음 권한이 필요합니다: - 개발 환경 S3 버킷 읽기/쓰기 - CloudWatch 로그 조회 - 개발 환경 EC2 인스턴스 재시작

이 권한을 부여하는 방법은 크게 두 가지입니다:

방법 A (개별 부여): 개발자 계정에 S3, CloudWatch, EC2 권한을 각각 직접 연결합니다. 개발자가 5명이면 5번, 50명이면 50번 반복합니다.

방법 B (역할 기반): "Backend Developer"라는 역할을 만들고, 필요한 권한을 이 역할에 묶습니다. 신입 개발자에게는 역할만 부여합니다. 권한 변경이 필요하면 역할 하나만 수정합니다.

방법 B가 RBAC입니다. 그리고 IAM은 방법 A와 B 모두를 포함하는 시스템 전체를 말합니다.

IAM과 RBAC 관계 구조

1.2 개념 정리

구분	IAM	RBAC
정의	접근 제어 시스템 전체	역할 기반 권한 부여 모델
범위	인증 + 인가 + 감사	인가(Authorization) 방식 중 하나
포함 관계	RBAC를 포함하는 상위 개념	IAM 안에서 동작하는 하위 모델
대안	—	ABAC, PBAC, ACL 등

IAM은 다음 세 가지를 모두 다룹니다: - 인증(Authentication): 이 사용자가 누구인가? (로그인, MFA, SSO) - 인가(Authorization): 이 사용자가 무엇을 할 수 있는가? (RBAC, ABAC, Policy) - 감사(Audit): 이 사용자가 무엇을 했는가? (로그, 추적)

RBAC는 이 중 인가 단계에서 "역할"이라는 중간 계층을 통해 권한을 부여하는 방식입니다.

1.3 RBAC 외의 접근 제어 모델

모델	설명	예시
RBAC	역할에 권한을 묶어 부여	"개발자 역할"에 S3 읽기 권한 포함
ABAC	속성(태그, 부서, 환경)에 따라 동적으로 권한 결정	env=dev 태그가 붙은 리소스만 접근 허용
PBAC	정책 문서로 세밀하게 조건 정의	JSON Policy에 조건절(Condition) 포함
ACL	리소스별로 접근 가능한 주체 목록 관리	S3 버킷 ACL, 파일시스템 ACL

실무에서는 하나만 쓰는 경우가 드뭅니다. 대부분 RBAC를 기본으로 하되, 세밀한 조건이 필요하면 ABAC이나 PBAC를 결합합니다.

2. 클라우드별 IAM과 RBAC 구현 비교

클라우드별 IAM/RBAC 구조 비교

2.1 AWS: IAM + Policy 기반 혼합 모델

AWS IAM은 RBAC라는 용어를 명시적으로 분리하지 않습니다. 대신 Policy와 Role이라는 두 축으로 접근 제어를 설계합니다.

구성 요소: - IAM User/Group: 사람 또는 사람의 집합 - IAM Role: 서비스나 사용자가 임시로 맡는(assume) 자격 - IAM Policy: 허용/거부할 작업을 JSON으로 정의한 규칙

AWS에서 RBAC를 구현하는 방식:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::dev-bucket",
        "arn:aws:s3:::dev-bucket/*"
      ]
    }
  ]
}

이 Policy를 "BackendDeveloper"라는 IAM Role에 연결하고, 개발자에게 이 Role을 부여하면 RBAC 패턴이 됩니다.

AWS의 특징: - RBAC와 ABAC를 동시에 지원합니다. Policy의 Condition 블록에서 태그 기반 접근 제어(ABAC)를 설정할 수 있습니다. - IAM Role은 사람뿐 아니라 EC2, Lambda 등 서비스에도 권한을 부여하는 데 사용됩니다. - 권한 경계(Permission Boundary)로 Role이 가질 수 있는 권한의 상한선을 설정할 수 있습니다.

2.2 Azure: 명시적 RBAC 분리 모델

Azure는 IAM 내에서 RBAC를 별도 시스템으로 명확히 분리했습니다. "Azure RBAC"라는 이름으로 독립적인 접근 제어 계층을 제공합니다.

구성 요소: - Security Principal: 권한을 받을 주체 (User, Group, Service Principal, Managed Identity) - Role Definition: 허용할 작업의 집합 (Reader, Contributor, Owner 등) - Scope: 권한이 적용되는 범위 (Management Group → Subscription → Resource Group → Resource) - Role Assignment: Principal + Role + Scope를 연결하는 바인딩

Azure에서 RBAC를 구현하는 방식:

# 개발자 그룹에 개발 리소스 그룹의 Contributor 역할 부여
az role assignment create \
  --assignee "dev-team-group-id" \
  --role "Contributor" \
  --scope "/subscriptions/{sub-id}/resourceGroups/dev-rg"

Azure의 특징: - Scope 계층 구조가 명확합니다. 상위 Scope에서 부여한 권한이 하위로 상속됩니다. - Built-in Role이 수백 개 제공되어 대부분의 시나리오를 커버합니다. - Deny Assignment로 특정 권한을 명시적으로 차단할 수 있습니다(제한적 사용). - Entra ID(구 Azure AD)의 디렉토리 역할과 Azure RBAC는 별개 시스템입니다.

2.3 GCP: IAM + Predefined Role 모델

GCP IAM은 Role을 중심으로 권한을 부여하는 구조이며, Azure처럼 명시적으로 "RBAC"를 별도 제품으로 분리하지는 않습니다.

구성 요소: - Principal(Member): 권한을 받을 주체 (Google 계정, Service Account, Group) - Role: 권한(Permission)의 집합 (Basic, Predefined, Custom) - Resource: 권한이 적용되는 대상 (Organization → Folder → Project → Resource) - Allow Policy(IAM Binding): Principal + Role + Resource를 연결

GCP에서 RBAC를 구현하는 방식:

# 개발자 그룹에 프로젝트 수준 Storage Object Viewer 역할 부여
gcloud projects add-iam-policy-binding dev-project \
  --member="group:dev-team@company.com" \
  --role="roles/storage.objectViewer"

GCP의 특징: - Predefined Role이 서비스별로 세분화되어 있습니다 (예: roles/storage.objectViewer, roles/storage.objectAdmin). - Basic Role(Owner, Editor, Viewer)은 권한이 넓어서 운영 환경에서는 사용을 피합니다. - IAM Conditions로 시간, IP, 리소스 속성 기반 조건부 접근 제어(ABAC)를 추가할 수 있습니다. - Resource 계층 상속이 동작하며, Organization → Folder → Project 순으로 권한이 내려갑니다.

3. 클라우드별 상세 비교

클라우드별 권한 부여 흐름

3.1 핵심 비교표

비교 항목	AWS	Azure	GCP
RBAC 명시적 분리	아니오 (Policy+Role 혼합)	예 (Azure RBAC)	아니오 (IAM 내 Role 중심)
권한 정의 단위	IAM Policy (JSON)	Role Definition (Actions)	Role (Permissions 집합)
역할 연결 방식	Role에 Policy Attach	Role Assignment (Principal+Role+Scope)	IAM Binding (Member+Role+Resource)
Scope 계층	Account (Organization → OU)	Management Group → Subscription → RG → Resource	Organization → Folder → Project → Resource
서비스 자격 증명	IAM Role (AssumeRole)	Service Principal / Managed Identity	Service Account
속성 기반 제어 (ABAC)	Policy Condition + Tags	ABAC (Preview / 제한적)	IAM Conditions
기본 제공 역할 수	AWS Managed Policy ~1,000+	Built-in Role ~500+	Predefined Role ~1,000+
권한 상한 설정	Permission Boundary	상위 Scope 제한	Organization Policy
Deny 메커니즘	Explicit Deny in Policy	Deny Assignment (제한적)	IAM Deny Policy
감사	CloudTrail	Activity Log	Cloud Audit Logs

3.2 설계 철학의 차이

AWS — 유연성 우선 - Policy라는 범용 도구로 RBAC, ABAC, 조건부 접근을 모두 표현합니다. - 유연하지만, 그만큼 정책이 복잡해질 수 있습니다. - Role과 Policy를 조합하는 방식은 자유도가 높지만 설계 패턴이 여러 개 존재하여 팀마다 다른 방식을 쓸 수 있습니다.

Azure — 구조화 우선 - RBAC를 별도 시스템으로 명확히 분리하여 "누구에게, 어떤 역할을, 어떤 범위에서"를 한 문장으로 표현합니다. - Scope 계층이 깔끔하여 권한 상속과 재활용이 직관적입니다. - 다만 Custom Role을 만들려면 Actions/DataActions 목록을 직접 정의해야 합니다.

GCP — 서비스 세분화 우선 - 서비스별로 Predefined Role이 세밀하게 나뉘어 있어 "딱 필요한 만큼"을 부여하기 쉽습니다. - Basic Role의 유혹(Editor/Owner)이 있지만, 운영 환경에서는 Predefined 또는 Custom Role을 권장합니다. - Resource 계층이 Organization → Folder → Project로 논리적 구분이 명확합니다.

4. 실무 설계 패턴

4.1 시나리오: 멀티 클라우드 환경의 개발팀 권한 설계

5명의 백엔드 개발 팀에게 다음 권한을 부여해야 합니다: - 개발 환경: 리소스 생성/수정/삭제 가능 - 스테이징 환경: 읽기 + 배포만 가능 - 프로덕션 환경: 읽기만 가능

각 클라우드에서 이 요구사항을 구현하는 패턴입니다:

AWS 구현:

IAM Group: backend-dev-team
├── Role: DevEnvFullAccess (dev 리소스 CRUD)
├── Role: StagingDeployAccess (staging 읽기 + 특정 배포 Action)
└── Role: ProdReadOnly (prod 리소스 읽기만)

• 각 Role에 환경별 리소스 ARN을 Condition으로 제한합니다.
• 또는 Tag 기반 ABAC로 env=dev 태그가 붙은 리소스에만 접근을 허용합니다.

Azure 구현:

Azure AD Group: backend-dev-team
├── Role Assignment: Contributor @ dev-rg (개발 리소스 그룹)
├── Role Assignment: Reader + Custom Deploy Role @ staging-rg
└── Role Assignment: Reader @ prod-rg

• Scope를 Resource Group 단위로 분리하여 환경별 접근을 제한합니다.
• Custom Role에 배포 관련 Actions만 포함시킵니다.

GCP 구현:

Google Group: backend-dev-team@company.com
├── IAM Binding: roles/editor @ dev-project
├── IAM Binding: roles/viewer + custom.deployer @ staging-project
└── IAM Binding: roles/viewer @ prod-project

• Project 단위로 환경을 분리하여 권한 경계를 명확히 합니다.
• Custom Role에 배포에 필요한 Permission만 포함시킵니다.

4.2 RBAC 설계 시 공통 원칙

어떤 클라우드를 사용하든 다음 원칙은 동일하게 적용됩니다:

1. 최소 권한 원칙(Least Privilege): 필요한 권한만 부여합니다. "일단 넓게 주고 나중에 줄이자"는 운영 환경에서는 위험합니다.
2. 그룹/역할 기반 부여: 개인에게 직접 권한을 부여하지 않습니다. 역할이나 그룹을 중간에 둡니다.
3. 환경별 분리: 개발/스테이징/프로덕션 환경은 별도 계정, 구독, 프로젝트로 분리합니다.
4. 정기 감사: 사용하지 않는 권한은 주기적으로 제거합니다(90일 미사용 기준).
5. 임시 권한(JIT): 프로덕션 접근은 상시 부여보다 필요 시 임시 승격 방식을 선택합니다.

4.3 흔한 실수와 대응

실수	문제점	대응
Admin/Owner 권한 상시 부여	피해 범위가 전체로 확대됨	JIT 접근 + 별도 Break Glass 계정 운용
개인에게 직접 권한 연결	퇴사/이동 시 정리 누락	Group/Role 기반 부여 후 멤버십만 관리
환경 미분리	개발 실수가 프로덕션에 영향	Account/Subscription/Project 수준 분리
권한 감사 미실시	불필요 권한 누적 (권한 팽창)	90일 미사용 권한 자동 알림 설정
Service Account 키 직접 사용	키 유출 시 영구 접근 가능	Workload Identity/IRSA/Managed Identity 사용

5. Kubernetes RBAC와의 관계

클라우드 IAM과 Kubernetes RBAC는 별도의 인가 시스템입니다. 두 계층이 함께 동작하며, 둘 다 통과해야 실제 작업이 가능합니다.

클라우드 IAM과 Kubernetes RBAC 이중 인가 흐름

5.1 이중 인가 구조

사용자 → 클라우드 IAM 인증 → Kubernetes API Server → K8s RBAC 인가 → 리소스 접근

• 클라우드 IAM: 클러스터에 접근할 수 있는가? (kubectl 명령을 실행할 자격이 있는가)
• Kubernetes RBAC: 클러스터 안에서 어떤 네임스페이스의 어떤 리소스에 어떤 작업을 할 수 있는가?

5.2 클라우드별 Kubernetes 인증 연동

클라우드	인증 방식	RBAC 연동
AWS EKS	IAM Role → aws-auth ConfigMap 또는 EKS Access Entry	IAM Role을 K8s Group에 매핑
Azure AKS	Entra ID 인증	Entra ID Group을 K8s RoleBinding에 연결
GCP GKE	Google Account / Service Account	IAM Role에 K8s RBAC 권한 포함 가능

5.3 실무 예시: EKS에서 개발자 권한 분리

# 1. K8s RBAC: dev 네임스페이스에서 Pod 읽기/실행만 허용
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create"]
---
# 2. RoleBinding: 개발자 그룹에 연결
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: dev
  name: dev-pod-reader
subjects:
- kind: Group
  name: backend-developers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

이 구성에서 개발자가 실제로 kubectl exec를 실행하려면: 1. AWS IAM Role로 EKS 클러스터에 인증되어야 하고 (클라우드 IAM) 2. backend-developers 그룹에 매핑되어 있어야 하며 (aws-auth 또는 Access Entry) 3. dev 네임스페이스의 pod-reader Role이 허용하는 범위 안에서만 동작합니다 (K8s RBAC)

6. 의사결정 가이드

6.1 언제 무엇을 선택하는가

상황	권장 접근 방식
팀 단위로 동일 권한 부여	RBAC (역할 기반)
리소스 태그/속성에 따라 동적 권한	ABAC (속성 기반)
세밀한 조건 분기 필요	Policy 기반 (PBAC)
환경별 접근 분리	계정/구독/프로젝트 분리 + RBAC
서비스 간 권한	Service Account/Role + 최소 권한
임시 접근 필요	JIT 접근 (Privileged Identity Management)

6.2 멀티 클라우드 환경에서의 고려사항

• 중앙 ID 제공자(IdP)를 통한 SSO 통합이 선행되어야 합니다.
• 각 클라우드의 RBAC 모델이 다르므로, 역할 이름은 통일하되 구현은 클라우드별로 맞춥니다.
• "Contributor"(Azure)와 "Editor"(GCP), IAM Policy(AWS)의 실제 권한 범위가 다릅니다. 이름만으로 동일한 수준이라고 가정하면 안 됩니다.
• Terraform 같은 IaC 도구로 멀티 클라우드 IAM을 코드화하면 일관성을 유지하기 쉬워집니다.

7. 보안과 비용 관점

7.1 보안 Trade-off

결정	보안 이점	운영 부담
세밀한 Custom Role	최소 권한 달성	역할 관리 복잡도 증가
Predefined/Managed Role 사용	관리 단순	불필요 권한 포함 가능성
JIT 접근	상시 노출 최소화	승인 프로세스 필요
Service Account 키 제거	키 유출 위험 제거	Workload Identity 설정 필요

7.2 비용 관점

• IAM 자체는 AWS, Azure, GCP 모두 무료입니다 (추가 비용 없음).
• 다만 AWS Organizations, Azure PIM(Privileged Identity Management), GCP BeyondCorp Enterprise 등 고급 거버넌스 기능은 별도 과금이 있을 수 있습니다.
• 권한 관리의 비용은 금전보다 운영 인력과 시간에서 발생합니다. 복잡한 Custom Role 구조는 유지보수 부담을 높입니다.

8. 정리: 면접에서 이렇게 설명합니다

"IAM과 RBAC의 차이를 설명해주세요"라는 질문에 대한 답변 구조:

1. 관계 설명: IAM은 접근 제어 시스템 전체이고, RBAC는 그 안에서 권한을 역할 단위로 부여하는 모델입니다.
2. 클라우드별 차이: AWS는 Policy+Role 혼합, Azure는 RBAC를 명시적으로 분리, GCP는 Predefined Role 중심으로 구현합니다.
3. 설계 원칙: 어떤 클라우드든 최소 권한, 그룹 기반 부여, 환경 분리, 정기 감사가 핵심입니다.
4. Kubernetes 연동: 클라우드 IAM과 K8s RBAC는 별도 계층이며, 둘 다 통과해야 실제 작업이 가능합니다.

---

관련 글

• AWS IAM Role과 Policy 차이: 권한을 설계하는 두 가지 축
• Azure RBAC란 무엇인가: Role Assignment와 Scope 이해하기
• GCP IAM 기본 개념: Role, Principal, Policy 이해하기
• Kubernetes RBAC란 무엇인가: Role, ClusterRole, Binding으로 권한 설계하기
• 클라우드 보안 기본 원칙: 최소 권한, 네트워크 격리, 감사 로그