IAM 정책 4종류 개념 비교

정책 종류적용 대상평가 시점주 목적예시

① 권한 정책 (Permissions Policy)	사용자, 그룹, 역할	리소스에 접근할 때	이 Principal(주체)이 무엇을 할 수 있는가?	“S3:GetObject 허용”
② 신뢰 정책 (Trust Policy)	역할(Role)	역할을 Assume할 때	누가 이 역할을 맡을 수 있는가?	“AccountB의 User만 AssumeRole 허용”
③ 세션 정책 (Session Policy)	임시 세션 (STS AssumeRole 후)	임시 자격증명 사용 시	세션 내 권한을 추가로 축소	“S3:* 중 GetObject만 허용”
④ 리소스 기반 정책 (예: S3 버킷 정책)	리소스(S3, KMS 등)	리소스 접근 시	누가 이 리소스에 접근할 수 있는가?	“AccountA, AccountB만 허용”

⚙️ 2️⃣ 평가 순서 (IAM 요청 처리 순서)

AWS가 어떤 요청을 받을 때는 아래 순서로 정책을 평가합니다 👇

✅ [Step 1] 인증(Authentication)

→ 요청 주체가 MFA, Access Key, AssumeRole 등을 통해 인증됨.

✅ [Step 2] 신뢰 정책 (Trust Policy) 확인

→ AssumeRole 요청의 경우, “이 사용자가 이 역할을 맡을 수 있는가?”를 확인.
→ 이 시점에서 MFA 조건(aws:MultiFactorAuthPresent)을 확인 가능.
👉 즉, 역할 수행 여부는 여기서 결정됨.

✅ [Step 3] 세션 발급 (STS Token 생성)

→ 성공 시, STS 임시 자격증명(temporary credential) 발급됨.

✅ [Step 4] 권한 정책 (Permissions Policy) + 세션 정책(Session Policy) 평가

→ 이제 역할로서 리소스 접근을 시도할 때,

• 역할의 권한 정책과
• STS 세션 정책을 모두 AND 조합으로 평가.
  👉 둘 다 허용해야 리소스 접근 가능.

✅ [Step 5] 리소스 기반 정책 (예: S3 버킷 정책) 평가

→ 요청이 리소스로 도달하면,
해당 리소스에 부착된 정책이 최종적으로 접근을 허용하거나 거부.

 

🎯 4️⃣ MFA 조건 적용 시점 요약

적용 위치MFA 조건의 의미적절한 사용 사례

신뢰 정책	역할을 AssumeRole 할 때 MFA 필요	다른 계정 사용자가 역할을 수행할 때
권한 정책	역할 수행 후 리소스 접근 시 MFA 필요	콘솔 로그인 사용자가 민감 리소스 접근할 때
세션 정책	이미 생성된 세션에서 MFA 조건을 추가 제한	Fine-grained 제한 (거의 사용 안함)
S3 버킷 정책	S3 접근 시 MFA가 필요한 세션만 허용	권한보다 “리소스 자체 보호” 목적 (일반적이지 않음)

---

🧠 5️⃣ 정리 비유

정책질문 형태시점예시

신뢰 정책	“너 이 역할 맡을 자격 있어?”	입장 전	문 앞에서 신분증+MFA 확인
권한 정책	“이 역할로 뭘 할 수 있어?”	입장 후	건물 안에서 접근 가능한 구역
세션 정책	“이번 임시 방문 중엔 더 제한할게.”	입장 중	일시 방문자 배지로 특정 층만 허용
S3 버킷 정책	“내 리소스엔 누가 접근해도 돼?”	요청이 도착했을 때	문 안에서 경비가 출입자 확인

---

✅ 결론

• 역할 Assume 시점에 MFA 강제 → 신뢰 정책
• 리소스 접근 시점에 MFA 강제 → 권한 정책 또는 버킷 정책

👉 따라서,

“MFA 인증된 사용자만 역할을 수행할 수 있도록” 하려면
B. 역할의 신뢰 정책(Trust Policy)에 aws:MultiFactorAuthPresent 조건 추가
가 정답입니다.