한 줄 정의
- 정책(Policy): “무엇을 허용/거부할지”를 적은 권한 문서(JSON)
- 역할(Role): “누가 이 신분을 빌려서” 어떤 작업을 하게 할지 정한 임시 자격 증명용 신분
핵심 차이 표
| 구분 | 정책 (Policy) | 역할 (Role) |
|---|---|---|
| 본질 | 권한 규칙(Allow/Deny) | 임시 자격 증명 신분 |
| 부착 대상 | 사용자/그룹/역할(Identity-based) 또는 리소스(Resource-based) | 스스로 정책을 붙여 권한을 가짐 |
| 자격 증명 | 없음(문서일 뿐) | 장기 키 없음, STS로 임시 키 발급 |
| 누가 사용? | 붙어 있는 주체가 그대로 사용 | 사람/서비스/다른 계정이 AssumeRole로 “역할을 가정”하여 사용 |
| 꼭 필요한 문서 | — | 신뢰 정책(Trust policy): “누가 AssumeRole 가능한가” |
| 대표 사용처 | 권한 정의/재사용 | EC2/Lambda 실행 역할, 크로스 계정 접근, SSO/페더레이션 |
정책(Policy) 자세히
-
형태: JSON 문서.
Effect,Action,Resource,Condition으로 구성. -
종류
- Identity-based: 사용자/그룹/역할에 부착해 권한 부여.
- Resource-based: S3 버킷, SQS 큐, KMS 키 등 리소스에 부착(외부 계정/역할 허용에 유용).
- Managed vs Inline: 재사용 가능한 관리형 정책 vs 특정 엔티티 전용 인라인 정책.
-
예시(조각):
{ "Effect":"Allow", "Action":["s3:GetObject"], "Resource":"arn:aws:s3:::my-bucket/*" }
역할(Role) 자세히
-
임시 자격 증명 전용 신분. 패스워드/엑세스키 없음.
-
두 가지 정책을 가짐:
- 신뢰 정책(Trust policy): 누가 이 역할을 가정할 수 있나?
- 권한 정책(Permissions policy): 가정한 뒤 무엇을 할 수 있나?
-
주요 쓰임
- EC2/Lambda 실행 역할: 앱이 안전하게 AWS API 호출.
- 서비스 역할(Service-linked/Service role): CloudWatch, EventBridge 등 AWS 서비스가 고객 리소스를 조작.
- 크로스 계정 접근: A계정 사용자가 B계정의 역할을 가정해 작업.
- 기업 SSO/IdP 연동: 직원이 로그인 시 특정 역할 가정.
신뢰 정책 예시(크로스 계정)
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111122223333:root" },
"Action": "sts:AssumeRole",
"Condition": { "StringEquals": { "sts:ExternalId": "my-ext-id" } }
}]
}권한 정책 예시(해당 역할이 할 수 있는 일)
{
"Version": "2012-10-17",
"Statement": [{
"Effect":"Allow",
"Action":["s3:ListBucket","s3:GetObject"],
"Resource":[
"arn:aws:s3:::my-bucket",
"arn:aws:s3:::my-bucket/*"
]
}]
}함께 동작할 때의 평가 규칙
- 최종 권한 = 역할의 권한 정책 ∩ 리소스 정책(둘 다 허용이어야 함).
- 명시적 Deny가 항상 이김.
- 추가 제약: Permission Boundary(역할/사용자의 권한 상한), 세션 정책(Assume 시 더 좁히기) 등이 동시에 적용될 수 있음.
자주 하는 질문(FAQ)
Q. 사용자와 역할의 차이는?
- 사용자: 사람/애플리케이션을 위한 장기 자격 증명(Access key/비밀번호).
- 역할: 임시로 가정해서 쓰는 신분(장기 키 없음). 보안·교차계정에 유리.
Q. 그룹은 뭐죠?
- 여러 사용자에게 정책을 일괄 부여하기 위한 컨테이너. 역할과는 별개.
Q. 리소스 정책만으로도 되나요?
- 가능. 다만 보통은 역할의 권한 정책 + 리소스 정책을 함께 써서 최소 권한을 확실히 함.
선택 가이드 (언제 무엇을?)
- 애플리케이션/서비스에서 AWS API 호출 → 역할(실행 역할) + 필요한 권한 정책
- 사람에게 장기 키 주고 싶지 않다 → IdP/SSO 로그인 → 역할 가정
- 도메인(버킷/큐 등) 자체에서 접근 제어 → 리소스 정책(필요 시
aws:PrincipalOrgID/aws:SourceArn조건)
30초 요약
- 정책 = 권한 문서, 역할 = 임시 신분.
- 역할은 신뢰 정책(누가 가정?) + 권한 정책(무엇 가능?) 두 축.
- 최종 권한은 역할 권한 ∩ 리소스 정책, 그리고 명시적 Deny가 최우선.
- 실행 역할/크로스 계정/SSO 같은 시나리오에 역할이 핵심
`•.¸¸.•´´¯`••._.• 🎀 𝒸𝓇𝒶𝓏𝓎 𝓅𝓈𝓎𝒸𝒽💞𝓅𝒶𝓉𝒽 🎀 •._.••`¯´´•.¸¸.•`