[AWS DEA] 문제로 공부하기 15 - IAM 서비스 역할(Role)

AWS DEA-C01 AWS Glue IAM 서비스 역할 IAM 정책 ETL 파이프라인

AWS Glue ETL에 S3 권한 부여 — IAM 서비스 역할(Role)이 정답인 이유

AWS DEA-C01 시험에 자주 나오는 IAM 권한 부여 패턴 문제입니다. AWS 서비스(Glue)에 다른 AWS 리소스(S3) 접근 권한을 부여할 때는 IAM 사용자·액세스 키가 아닌 IAM 서비스 역할(Service Role)을 사용해야 합니다. 리소스 정책과 IAM 역할의 차이, 정책을 직접 연결할 수 없는 이유도 함께 정리합니다.

📋 문제

데이터 엔지니어가 AWS Glue ETL 파이프라인을 새 계정에 배포하고 있다. 파이프라인은 소스 S3 버킷에서 원시 데이터를 읽고 대상 S3 버킷에 변환된 데이터를 저장한다.

데이터 엔지니어는 두 S3 버킷에 대한 접근 권한이 포함된 IAM 정책을 이미 작성했다. 이제 이 정책의 권한을 AWS Glue에 부여해야 한다.

다음 중 이러한 요구 사항을 충족하는 솔루션은 무엇인가?

🔑 핵심 개념 — IAM 엔티티 유형과 용도

🎭

IAM Role (역할)

AWS 서비스용 ⭐

AWS 서비스(Glue, Lambda 등)가 다른 AWS 리소스에 접근할 때 사용. 신뢰 정책으로 서비스에 위임

👤

IAM User (사용자)

사람·애플리케이션용

사람이나 외부 애플리케이션에 장기 자격 증명 발급. AWS 서비스에 직접 부여 불가

🪣

리소스 정책

리소스 자체에 부착

S3 버킷 정책처럼 리소스에 직접 연결. 누가 이 리소스에 접근할 수 있는지 정의

✅ 핵심 원칙: AWS 서비스가 다른 AWS 리소스에 접근해야 할 때는 항상 IAM 역할(Role)을 생성하고, 해당 서비스를 신뢰 정책의 주체(Principal)로 설정합니다. IAM 정책은 역할 또는 사용자에만 연결할 수 있으며, AWS Glue 서비스 자체에 직접 연결할 수 없습니다.

🏗️ 정답 아키텍처 — IAM 서비스 역할 연결 흐름

✅ 올바른 방법 — IAM 역할 생성 → 정책 연결 → Glue에 역할 지정

IAM 정책
(S3 소스·대상 접근)

↓ 연결

IAM 서비스 역할
(신뢰: glue.amazonaws.com)

↓ 지정

AWS Glue 작업

AWS Glue 작업

→ AssumeRole

역할 임시 자격 증명

→

S3 버킷 접근 ✅

📋 IAM 역할 신뢰 정책 예시

{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "Service": "glue.amazonaws.com" }, "Action": "sts:AssumeRole" }] }

📝 선택지 해설

각 항목을 클릭하면 해설이 펼쳐집니다.

A

❌ IAM 사용자 + 액세스 키 생성 → 정책 연결 → Glue 작업에 액세스 키 제공

장기 자격 증명을 코드/설정에 하드코딩 — 보안 위험 + AWS 비권장 방식

💡 두 가지 이유로 잘못된 방식입니다. 첫째, IAM 사용자와 액세스 키는 사람이나 외부 애플리케이션을 위한 것이며, AWS 서비스(Glue)에 권한을 부여하는 목적으로 설계된 것이 아닙니다. 둘째, 액세스 키를 Glue 작업 구성에 직접 포함하면 장기 자격 증명이 코드나 설정 파일에 노출될 위험이 있습니다. AWS는 서비스 간 권한 부여에 IAM 역할을 사용하도록 강력히 권장합니다. IAM 역할은 임시 자격 증명을 자동 순환하여 보안이 훨씬 뛰어납니다.

B

❌ 소스·대상 S3용 IAM 정책 2개 생성 → Glue 작업 구성 시 정책을 직접 연결

IAM 정책은 역할·사용자에 연결하는 것 — Glue 서비스 자체에 직접 연결 불가

💡 IAM 정책은 IAM 자격 증명(역할, 사용자, 그룹)에 연결하는 것이며, AWS Glue 서비스 자체에 직접 연결할 수 없습니다. Glue 작업을 구성할 때 정책을 직접 지정하는 옵션도 존재하지 않습니다. 또한 하나의 역할에 두 정책을 모두 연결하면 되므로 정책을 굳이 2개로 분리할 필요도 없습니다. 올바른 방법은 IAM 역할을 만들고 그 역할에 정책을 연결한 후 Glue에 역할을 지정하는 것입니다.

C

✅ AWS Glue에 새 IAM 서비스 역할 생성 → 정책 연결 → 역할을 사용하도록 Glue 구성

AWS 서비스 간 권한 부여의 표준 방식 — 임시 자격 증명 자동 순환, 최소 보안 위험

💡 정답. AWS 서비스가 다른 AWS 리소스에 접근할 때의 표준 패턴입니다. ① 신뢰 정책에 glue.amazonaws.com을 Principal로 설정한 IAM 서비스 역할을 생성합니다. ② 기존에 작성한 S3 접근 IAM 정책을 이 역할에 연결합니다. ③ Glue 작업을 구성할 때 이 역할을 지정합니다. Glue가 실행될 때 STS(Security Token Service)를 통해 역할을 수임(AssumeRole)하고 임시 자격 증명을 자동으로 받아 S3에 접근합니다. 액세스 키를 코드에 노출할 필요가 없으며, 임시 자격 증명은 자동으로 갱신됩니다.

D

❌ 소스·대상 S3용 리소스 정책 2개 생성 → 각 S3 버킷에 연결

리소스 정책은 "누가 이 버킷에 접근할 수 있는가" 정의 — Glue에 권한 부여 목적이 아님

💡 리소스 정책(버킷 정책)은 S3 버킷 자체에 연결되어, 어떤 주체(Principal)가 해당 버킷에 접근할 수 있는지를 정의합니다. 이 방식은 S3 버킷에 정책을 연결하는 것이지, AWS Glue에 권한을 부여하는 것이 아닙니다. 또한 버킷 정책만으로는 Glue가 S3에 접근하도록 Glue 자체에 권한을 부여하는 메커니즘이 부재합니다. 리소스 정책은 IAM 역할 기반 접근 제어를 보완하는 용도로 사용하며, 단독으로 서비스 권한 부여에 사용하지 않습니다.

정답 및 핵심 정리 (클릭)

정답: C — IAM 서비스 역할 생성 + 정책 연결 + Glue에 역할 지정

"AWS 서비스에 권한 부여 = IAM Role"은 AWS 보안 모범 사례의 핵심입니다. IAM 사용자·액세스 키(A)는 사람/외부 앱용이고, IAM 정책은 서비스에 직접 연결(B) 불가하며, 리소스 정책(D)은 리소스 접근 제어용입니다.

# AWS 서비스 간 권한 부여 표준 패턴 [잘못된 방법 A] IAM 사용자 → 액세스 키 → Glue 코드에 하드코딩 ❌ (보안 위험, 장기 자격 증명 노출) [잘못된 방법 B] IAM 정책 → Glue 서비스에 직접 연결 ❌ (정책은 역할/사용자에만 연결 가능) [잘못된 방법 D] 리소스 정책 → S3 버킷에 연결 ❌ (Glue에 권한 부여가 아닌 버킷 접근 제어) [올바른 방법 C] ✅ 1. IAM 역할 생성 - 신뢰 정책: Principal = glue.amazonaws.com 2. IAM 정책(S3 소스·대상 접근)을 역할에 연결 3. Glue 작업에 이 역할 지정 → Glue가 STS로 역할 수임 → 임시 자격 증명으로 S3 접근 # 핵심 암기 사람/외부앱 → IAM User + Access Key AWS 서비스 → IAM Role (서비스 역할) ⭐

📊 선택지 비교 요약

선택지	방식	Glue에 권한 부여	보안 수준	가능 여부	결론
A	IAM 사용자 + 액세스 키	⚠️ 가능하나 부적절	❌ 낮음 (장기 키 노출)	기술적 가능	탈락
B	IAM 정책 직접 연결	❌ 불가	❌ 해당 없음	불가	탈락
C ⭐	IAM 서비스 역할	✅ 표준 방식	✅ 높음 (임시 자격)	✅ 가능	정답
D	S3 리소스 정책	❌ Glue 권한 부여 아님	❌ 불완전	불완전	탈락

#AWS_DEA-C01 #AWSGlue #IAM서비스역할 #IAMRole #IAM정책 #ETL파이프라인 #S3접근권한 #IAM사용자액세스키 #리소스정책 #AWS권한부여패턴 #AWS자격증 #AWS데이터엔지니어