AWS IAM Explicit Deny는 왜 Allow보다 우선할까? 권한 오류 읽는 법

역할에 Allow 정책을 추가했는데도 AccessDenied가 계속되면 다른 정책의 명시적 Deny가 이 허용을 막고 있을 수 있다. IAM은 단순히 Allow가 하나라도 있으면 통과하는 방식이 아니다.

기본 거부와 명시적 거부를 구분한다

허용 정책이 없으면 기본적으로 거부된다. 명시적으로 Effect: "Deny"가 적용되면 다른 Allow가 있어도 거부된다. 조직 수준 정책, 권한 경계, 리소스 정책, 세션 정책처럼 여러 계층이 결과에 영향을 줄 수 있으므로 역할 정책 한 파일만 보고 판단하면 안 된다.

가상의 읽기 요청을 생각해 보자. 한 정책은 s3:GetObject를 허용하지만 다른 적용 정책이 같은 객체 경로에 Deny를 둔다면 최종 결과는 거부다. 반대로 두 정책 모두 삭제 작업을 언급하지 않았다면 s3:DeleteObject는 기본 거부다. 두 경우 모두 '허용 정책을 하나 더 붙이면 해결된다'고 판단하면 안 된다.

권한을 넓히기 전에 요청 맥락을 확인한다

실제 호출 주체, 대상 리소스, 리전, API 작업, 조건 키를 확인한다. 오류를 해결하려고 Action: "*", Resource: "*"를 추가하면 당장의 테스트는 통과해도 권한 경계가 무너진다. 필요한 작업만 작은 범위로 허용하고, 조건을 만족하지 않아 거부된 것은 아닌지 대조한다.

진단할 때는 오류 문구에 드러난 작업 이름과 리소스 식별자를 먼저 확인하고, 그다음 적용된 각 정책의 Allow·Deny·조건을 같은 요청 맥락에서 비교한다. 정책 시뮬레이터를 쓰더라도 실제 리소스 정책과 조직 경계까지 모두 재현됐는지 확인해야 한다.

Allow와 Deny가 충돌하는 작은 정책 예시

한 요청에 다음 두 규칙이 모두 적용된다고 생각해 보자. 같은 객체를 읽는 s3:GetObject는 Allow에 포함되지만 더 넓은 Deny에도 포함된다. 결과는 거부다. 아래는 정책 평가를 설명하기 위한 발췌이며, 그대로 붙여 넣을 완성된 정책은 아니다.

[
  { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::example-bucket/*" },
  { "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3:::example-bucket/*" }
]

AccessDenied를 보면 먼저 호출 주체, API 작업, 리소스를 적는다. 그다음 identity·resource 정책의 명시적 Deny와 조건을 확인한다. 다른 정책이 Allow를 더하더라도 이 Deny를 덮을 수 없다.

핵심 요약

IAM에서는 명시적 Deny가 Allow보다 우선하고, Allow가 없으면 기본 거부된다. 권한 오류는 호출 주체·작업·리소스·조건과 여러 정책 계층을 함께 확인해야 한다. 광범위한 허용으로 덮지 말고 최소 권한 정책으로 원인을 고치자.