정책 언어 상호작용

정책 언어 상호작용 (Access Policy Language Interplay)

여러 정책 타입(ID 기반, 리소스 기반, 권한 경계, SCP, RCP, 세션 정책)이 함께 적용될 때 최종 허용/거부가 어떻게 결정되는지를 설명하는 페이지예요. 특히 Deny가 항상 우선한다는 원칙이 핵심이에요.

출처: 문서

본문

하나의 AWS 요청에는 여러 정책 타입이 동시에 적용될 수 있어요. 각 정책 타입은 다음과 같이 결합돼요.

  • ID 기반 정책 — 프린시펄(IAM 사용자·그룹·역할)에 연결된 권한 정책.
  • 리소스 기반 정책 — 리소스에 연결된 정책 (S3 버킷 정책, 역할 신뢰 정책 등).
  • 권한 경계(permissions boundary) — IAM 엔티티의 최대 권한을 제한하는 경계.
  • AWS Organizations SCP — 조직 계정의 최대 권한을 제한.
  • 리소스 제어 정책(RCP) — 조직의 리소스에 대한 최대 권한을 제한.
  • 세션 정책 — 임시 자격 증명 세션에 전달되는 정책.

Deny가 항상 우선한다

모든 정책 타입을 함께 평가할 때, 적용되는 **어떤 정책이든 명시적 거부(explicit deny)**가 있으면 요청은 거부돼요. 이는 다른 정책의 명시적 허용보다 우선해요. 이것이 정책 언어 상호작용에서 가장 중요한 원칙이에요.

즉 요청 결과는 다음 두 단계로 요약돼요.

  1. 적용되는 정책 중 하나라도 명시적 거부가 있는가? → 있으면 거부.
  2. 아니면, 모든 제한(SCP, RCP, 권한 경계) 안에서 어느 정책이든 명시적 허용이 있는가? → 있으면 허용, 없으면 거부(기본 거부).

권한 경계와 SCP/RCP의 역할

권한 경계, SCP, RCP는 그 자체로 권한을 부여하지 않아요. 대신 계정이나 엔티티가 가질 수 있는 최대 권한의 상한을 정해요. 즉 허용이 있더라도 그 허용이 상한 경계 안에 있어야 최종 허용이 돼요.

예를 들어 ID 기반 정책이 s3:*를 허용해도, 권한 경계가 s3:GetObject까지만 허용한다면 실제로는 s3:GetObject만 허용돼요.

Role trust 정책과 세션 정책

역할을 수임할 때는 신뢰 정책(누가 수임 가능한지)과, 수임 과정에서 전달될 수 있는 세션 정책까지 함께 평가돼요. 세션 정책은 세션의 유효 권한을 세션 정책에 명시된 동작으로 제한해요.

결론

다양한 정책 타입이 얽힐 때, 최종 결정은 "명시적 거부가 있는가 → 아니면 상한 경계 안에서 명시적 허용이 있는가"로 정리돼요. 자세한 다이어그램과 단계별 평가는 요청 허용/거부 결정을 참고하세요.

더 알아보기 (Learn more)