소개
작업자는 임시 작업 신원을 통해 보고서에 접근해야 합니다. 역할을 생성하고 사용할 수 있는 주체를 선택하며 읽기 권한을 테스트한 뒤 정리 전에 접근을 회수합니다.
먼저 보고서 읽기 신원에 최소 권한 부여하기에서 정책 필드와 요청 경계를 익히세요. 새 VM에는 default, worker, outsider 프로필이 준비됩니다. /home/labex/project와 AWS View를 사용하세요. 개인 계정 설정은 필요하지 않습니다. 자격 증명 파일, CLI 캐시, 필터링되지 않은 AssumeRole 응답은 비공개로 유지하세요.
인증 시험 관련 주제
| 인증 | 시험 태스크 | 실습 내용 |
|---|---|---|
| Cloud Practitioner (CLF-C02) | 태스크 2.3 | IAM 역할 신뢰, 임시 세션과 리소스 접근. |
| Solutions Architect – Associate (SAA-C03) | 태스크 1.1 | IAM 역할 신뢰, 임시 세션과 리소스 접근. |
| Developer – Associate (DVA-C02) | 태스크 2.1 | IAM 역할 신뢰, 임시 세션과 리소스 접근. |
| CloudOps Engineer – Associate (SOA-C03) | 태스크 4.1 | IAM 역할 신뢰, 임시 세션과 리소스 접근. |
| Security – Specialty (SCS-C03) | 태스크 4.1, 태스크 4.2 | 기초 실습: IAM 역할 신뢰, 임시 세션과 리소스 접근; IAM 정책, 작업 및 리소스 범위와 최소 권한. |
| Data Engineer – Associate (DEA-C01) | 태스크 4.1 | 기초 실습: IAM 역할 신뢰, 임시 세션과 리소스 접근. |
| DevOps Engineer – Professional (DOP-C02) | 태스크 6.1 | 기초 실습: IAM 역할 신뢰, 임시 세션과 리소스 접근. |
| Solutions Architect – Professional (SAP-C02) | 태스크 2.3 | 기초 실습: IAM 역할 신뢰, 임시 세션과 리소스 접근. |
실습 개요

역할의 신뢰와 읽기 권한 정의하기
이 단계에서는 허용된 호출자를 지정한 신뢰 정책으로 ReportReader를 생성합니다. **신뢰 정책(trust policy)**은 역할의 리소스 정책입니다. Principal은 누가 해당 역할을 맡을 수 있는지 식별합니다. 역할의 권한 정책은 그 결과로 생성된 세션이 할 수 있는 작업을 별도로 정의합니다.
보고서 작업에 이제 임시 역할 세션이 필요합니다. S3 작업에는 익숙한 Action과 Resource 필드를 사용하고, 역할 진입에는 별도의 신뢰 정책을 사용합니다. 접근을 철회하기 전에 이 두 결정을 각각 테스트합니다.
IAM 역할은 권한과 역할을 맡을 수 있는 주체를 정의합니다. **AWS Security Token Service(STS)**는 호출자와 다른 신원인 역할 세션을 위한 임시 자격 증명을 발급합니다.

초기 신뢰와 비교할 수 있도록 worker의 ARN을 확인하세요.
cd /home/labex/project
aws sts get-caller-identity --profile worker --query Arn --output text
arn:aws:iam::123456789012:user/report-worker를 예상하세요. 운영자만 지정한 신뢰로 시작합니다. sts:AssumeRole은 역할 세션을 요청합니다. Principal은 프로필 이름이 아닌 신원 ARN입니다. worker는 아직 의도적으로 신뢰하지 않습니다.
cat > trust.json <<'JSON'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:user/iam03-operator"},"Action":"sts:AssumeRole"}]}
JSON
aws iam create-role \
--role-name ReportReader \
--assume-role-policy-document file://trust.json \
--query Role.Arn \
--output text
role/ReportReader로 끝나는 ARN을 예상하세요. 역할을 생성해도 S3 권한이 부여되지는 않습니다. 좁은 인라인 정책 하나를 추가하세요. 역할은 오늘 보고서에만 GetObject를 수행할 수 있으며 보고서를 쓰거나 급여를 읽을 수 없습니다.
cat > role-policy.json <<'JSON'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam03-reports/reports/today.txt"}]}
JSON
aws iam put-role-policy \
--role-name ReportReader \
--policy-name ReportRead \
--policy-document file://role-policy.json
aws iam get-role --role-name ReportReader --query Role.AssumeRolePolicyDocument
aws iam get-role-policy \
--role-name ReportReader \
--policy-name ReportRead \
--query PolicyDocument
두 문서를 다시 읽으세요. 신뢰는 진입을 제어하고 역할 권한은 세션 작업을 제어합니다. worker는 아직 신뢰하지 않습니다. 안전한 반환 ARN 필드만 선택하여 이 진입 조건을 테스트하세요.
aws sts assume-role --profile worker --role-arn arn:aws:iam::123456789012:role/ReportReader --role-session-name report-run --query AssumedRoleUser.Arn --output text || true
AccessDenied를 예상하세요. 쿼리 필터를 제거하지 마세요. 필터링되지 않은 성공 응답에는 비밀 정보가 포함됩니다.
호출자에게 권한을 부여하고 역할 프로필 사용하기
이 단계에서는 worker가 ReportReader를 요청할 수 있게 하고 역할 신뢰를 업데이트하며 역할 프로필을 사용합니다. 테스트 사용자 두 명은 같은 호출자 권한을 받지만 신뢰하는 worker만 역할 세션을 얻어야 합니다.
Resource가 정확한 역할 ARN인 호출자 정책을 작성하여 worker에 연결하세요.
cat > assume-policy.json <<'JSON'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"sts:AssumeRole","Resource":"arn:aws:iam::123456789012:role/ReportReader"}]}
JSON
aws iam put-user-policy \
--user-name report-worker \
--policy-name AssumeReportReader \
--policy-document file://assume-policy.json
신뢰 검사를 분리해 확인할 수 있도록 outsider에도 같은 좁은 호출자 권한을 부여하세요. 이 일회성 비교 사용자는 신뢰 문서에 없습니다.
aws iam put-user-policy \
--user-name outsider \
--policy-name AssumeReportReader \
--policy-document file://assume-policy.json
aws sts assume-role --profile worker --role-arn arn:aws:iam::123456789012:role/ReportReader --role-session-name before-trust --query AssumedRoleUser.Arn --output text || true
AccessDenied를 예상하세요. 신원 Allow는 운영자만 지정한 기존 신뢰보다 우선하지 않습니다. 해당 신뢰를 의도한 worker로 교체하고 역할을 업데이트하세요.
cat > trust.json <<'JSON'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:user/report-worker"},"Action":"sts:AssumeRole"}]}
JSON
aws iam update-assume-role-policy \
--role-name ReportReader \
--policy-document file://trust.json
aws sts assume-role --profile outsider --role-arn arn:aws:iam::123456789012:role/ReportReader --role-session-name outsider-test --query AssumedRoleUser.Arn --output text || true
outsider의 신원 정책이 AssumeRole을 허용해도 AccessDenied를 예상하세요. 해당 ARN을 신뢰하지 않기 때문입니다. worker로 반복하세요.
aws sts assume-role \
--profile worker \
--role-arn arn:aws:iam::123456789012:role/ReportReader \
--role-session-name report-run \
--query AssumedRoleUser.Arn \
--output text
역할 신뢰가 어떤 호출자가 진입할 수 있는지 결정했습니다. 신원 Allow는 이를 우회할 수 없습니다. 같은 계정의 사용자를 직접 지정한 신뢰는 별도 신원 Allow 없이도 진입을 부여할 수 있습니다. 여기서 동일한 호출자 권한을 부여한 것은 신뢰 비교를 분리하는 데 도움이 됩니다.
assumed-role/ReportReader/report-run으로 끝나는 ARN을 예상하세요. 세션 이름은 활동 기록에서 역할 사용을 구분하는 데 도움이 됩니다. 역할 자격 증명은 만료됩니다. 아래 CLI 역할 프로필은 임시 자격 증명을 대신 얻습니다.
준비된 report-role 프로필이 임시 자격 증명을 자동으로 요청하도록 설정하세요. source_profile은 호출자를 선택하고 role_arn은 대상 역할을 선택합니다. 이 설정에는 비밀 값이 없습니다. CLI는 임시 캐시를 안전하게 저장하므로 출력하지 마세요.
aws configure set role_arn arn:aws:iam::123456789012:role/ReportReader --profile report-role
aws configure set source_profile worker --profile report-role
aws configure set role_session_name report-run --profile report-role
aws sts get-caller-identity --profile report-role --query Arn --output text
다시 assumed-role ARN을 예상하세요. CLI는 이 프로필에 대해 내부적으로 STS 인증을 수행합니다. worker 신원 자체에는 역할의 S3 권한이 아닌 AssumeRole 권한이 있습니다.
aws s3api get-object --profile worker --bucket labex-iam03-reports --key reports/today.txt direct-worker.txt || true
AccessDenied를 예상하세요. 역할을 맡아도 역할 권한이 원래 사용자에게 다시 연결되지는 않습니다.
역할 세션의 리소스와 작업 경계 테스트하기
이 단계에서는 보고서 작업에 역할 프로필을 사용하고 관련 없는 작업을 수행할 수 없음을 확인합니다. AssumeRole 요청 성공은 역할 진입만 증명합니다. 실제 S3 요청이 유효한 접근을 증명합니다.
aws s3api get-object \
--profile report-role \
--bucket labex-iam03-reports \
--key reports/today.txt today.txt
cat today.txt
Daily orders: 145를 예상하세요. 역할의 정확한 객체 ARN 밖에 있는 기존 리소스 두 개를 시도하세요.
aws s3api get-object --profile report-role --bucket labex-iam03-reports --key private/payroll.txt private-denied.txt || true
aws s3api get-object --profile report-role --bucket labex-iam03-reference --key reference.txt reference-denied.txt || true
둘 다 AccessDenied를 반환해야 합니다. 다음으로 제공된 미승인 대체 파일로 오늘 보고서를 덮어써 보세요. GetObject는 PutObject를 허용하지 않습니다.
aws s3api put-object --profile report-role --bucket labex-iam03-reports --key reports/today.txt --body upload.txt || true
aws s3api get-object \
--profile report-role \
--bucket labex-iam03-reports \
--key reports/today.txt today.txt
cat today.txt
PutObject AccessDenied와 변경되지 않은 Daily orders: 145를 예상하세요. 로컬 파일 누락, 자격 증명 만료 오류, 서비스 사용 불가는 다른 진단이며 권한 경계를 증명하지 않습니다. AWS View는 저장된 신뢰, 역할 정책, 실제 역할 세션 읽기를 보여 줍니다. 오늘 보고서를 펼쳐 바이트를 확인하세요.

역할 접근 회수하고 정리하기
이 단계에서는 데이터를 삭제하기 전에 역할의 보고서 권한을 제거합니다. 역할 권한 제거와 새 역할 맡기 방지는 별개입니다. 로컬 캐시만 비워서는 서버 측 권한이 회수되지 않습니다.
역할과 보고서가 아직 존재하는 동안 ReportRead를 제거하고 역할 프로필로 읽기를 반복하세요.
aws iam delete-role-policy --role-name ReportReader --policy-name ReportRead
aws s3api get-object --profile report-role --bucket labex-iam03-reports --key reports/today.txt revoked.txt || true
AccessDenied를 예상하세요. 두 호출자 권한을 모두 제거하고 worker를 직접 지정한 신뢰를 운영자 전용 신뢰로 교체하세요. 신원 Allow만 제거해서는 같은 계정의 직접 신뢰 권한을 회수하지 못합니다. 그런 다음 worker가 새 세션을 얻을 수 없는지 테스트하세요.
aws iam delete-user-policy --user-name report-worker --policy-name AssumeReportReader
aws iam delete-user-policy --user-name outsider --policy-name AssumeReportReader
cat > trust.json <<'JSON'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:user/iam03-operator"},"Action":"sts:AssumeRole"}]}
JSON
aws iam update-assume-role-policy \
--role-name ReportReader \
--policy-document file://trust.json
aws sts assume-role --profile worker --role-arn arn:aws:iam::123456789012:role/ReportReader --role-session-name after-revocation --query AssumedRoleUser.Arn --output text || true
역할이 아직 존재하는 동안 AccessDenied를 예상하세요. 이러한 기능적 권한 회수 검사를 마친 뒤에만 역할을 삭제하세요.
aws iam delete-role --role-name ReportReader
aws iam list-roles --query 'Roles[].RoleName'
aws s3api delete-object --bucket labex-iam03-reports --key reports/today.txt
aws s3api delete-object --bucket labex-iam03-reports --key private/payroll.txt
aws s3api list-objects-v2 --bucket labex-iam03-reports
빈 역할 목록과 객체 응답의 KeyCount: 0을 예상하세요. 소유한 빈 버킷을 삭제한 뒤 참조 리소스가 원래 바이트로 계속 존재하는지 확인하세요.
aws s3api delete-bucket --bucket labex-iam03-reports
aws s3api list-buckets --query 'Buckets[].Name'
aws s3api get-object --bucket labex-iam03-reference --key reference.txt reference.txt
cat reference.txt
Platform reference: keep이 있는 참조 버킷만 남습니다. 성공한 이 조회들은 삭제와 보존을 확인합니다. 일회성 환경이 끝나면 준비된 신원과 임시 자격 증명 파일이 회수됩니다. 이 연습을 위해 생성한 역할과 호출자 권한을 제거했습니다.
요약
역할의 신뢰와 권한 정책을 구분하고 호출자 권한만으로는 신뢰를 우회할 수 없음을 증명했습니다. CLI 역할 프로필을 통해 STS를 사용했습니다. 역할 세션은 보고서만 읽을 수 있었으며 쓰거나 관련 없는 데이터를 읽을 수는 없었습니다. 범위를 지정한 정리 전에 역할과 호출자 권한을 모두 제거했습니다. 영구 워크로드 키보다 임시 역할을 우선하고 접근을 진단할 때 실제 신원과 허용/거부 요청을 확인하세요.
자세한 내용은 AWS 공식 문서를 참고하세요: IAM 역할, 신뢰 및 임시 자격 증명.



