IAM 정책 평가와 명시적 거부(Explicit Deny)

개발자를 위한 AWS 보안 활용

Rahul Singh

Technical Product Manager

정책은 규칙 목록입니다

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "true"
    },
    "IpAddress": {
      "aws:SourceIp": "203.0.113.0/24"
    }
  }
}

하나의 IAM 문을 구성하는 세 가지 필드를 하나의 축에 쌓아 1~3번으로 표시한 이미지: Effect는 허용 또는 거부 여부, Action은 어떤 API 호출인지, Resource는 ARN으로 지정된 대상이 무엇인지를 나타냅니다.

정책은 규칙 목록입니다

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "true"
    },
    "IpAddress": {
      "aws:SourceIp": "203.0.113.0/24"
    }
  }
}

하나의 IAM 문을 구성하는 네 가지 필드를 하나의 축에 쌓아 1~4번으로 표시한 이미지: Effect는 허용 또는 거부 여부, Action은 어떤 API 호출인지, Resource는 ARN으로 지정된 대상이 무엇인지, Condition은 어떤 조건이 충족되어야 하는지를 나타냅니다. 마지막 줄에는 "네 가지 필드, 하나의 규칙"이라고 쓰여 있습니다.

세 필드는 묻고, 한 필드는 답합니다

질문

Action: 어떤 호출인지
Resource: 어떤 대상인지
Condition: 조건이 맞는지

답

Effect: 허용인지 거부인지

IAM 문의 네 가지 필드를 세로로 쌓은 이미지: Action, Resource, Condition은 "질문"이라는 괄호로 묶이고, Effect는 "답"이라는 괄호로 묶여 있습니다.

규칙은 여러 곳에서 올 수 있습니다

역할에 연결된 정책 문서에서 버킷으로 화살표가 이어지는 이미지입니다.

ID 기반(Identity-based)

역할에 연결됨
이 역할이 할 수 있는 일

규칙은 여러 곳에서 올 수 있습니다

역할에 연결된 정책 문서에서 버킷으로 화살표가 이어지는 이미지입니다.

리소스에 연결된 정책 문서와, 보안 주체(Principal)에서 버킷으로 이어지는 화살표를 보여주는 이미지입니다.

ID 기반(Identity-based)

역할에 연결됨
이 역할이 할 수 있는 일

리소스 기반(Resource-based)

접근 대상에 연결됨
이 버킷에 접근할 수 있는 주체

규칙이 서로 충돌할 때

{"Effect": "Allow", "Action": "s3:*", "Resource": "*"}
{"Effect": "Deny",  "Action": "s3:DeleteObject", "Resource": "*"}

규칙이 서로 충돌할 때

{"Effect": "Allow", "Action": "s3:*", "Resource": "*"}
{"Effect": "Deny",  "Action": "s3:DeleteObject", "Resource": "*"}

요청: s3:DeleteObject 실행 결과: 거부됨(Denied).

명시적 거부(Explicit Deny)는 아무리 광범위한 허용보다도 우선합니다

허용 문과 거부 문이 하나의 요청으로 모이는 이미지로, 거부 경로가 굵게 표시되고 결과는 "거부됨"으로 표시되어 있습니다.

평가 순서와 암시적 거부

IAM 정책 평가 흐름도: API 요청은 먼저 적용 가능한 명시적 거부가 있는지 확인하고, 다음으로 적용 가능한 허용이 있는지 확인하며, 둘 다 없으면 암시적 거부에 도달합니다.

명시적 거부(Explicit Deny): 누군가 안 된다고 말한 경우
허용(Allow): 누군가 된다고 말했고, 아무도 안 된다고 하지 않은 경우
암시적 거부(Implicit Deny): 아무도 아무 말도 하지 않은 경우

네 가지 요청, 세 가지 결과

{"Effect": "Allow", "Action": "s3:*",
 "Resource": "*"}

{"Effect": "Deny", "Action": "s3:DeleteObject",
 "Resource": "*"}

s3:GetObject → 허용: 광범위한 허용 규칙이 이를 포함합니다
s3:DeleteObject → 명시적 거부: 한 문이 안 된다고 명시합니다
kms:Decrypt, dynamodb:GetItem → 암시적 거부: 이 정책은 해당 서비스를 전혀 언급하지 않습니다
KMS는 암호화 키를 보관하고, DynamoDB는 관리형 키-값 데이터베이스입니다

권한을 추가해도 해결되지 않는 이유

같은 오류, 두 가지 원인

명시적 거부

또 다른 허용을 추가해도 달라지지 않습니다
거부 규칙을 찾아 범위를 좁히거나 제거하세요

암시적 거부

좁은 범위의 허용 하나
호출을 수행한 ID에 적용

AccessDenied 오류가 두 가지 원인으로 나뉘는 이미지입니다. 왼쪽은 거부 규칙이 발견되어 허용을 추가해도 아무것도 달라지지 않는 경우이고, 오른쪽은 허용 규칙이 없어 호출한 ID에 좁은 범위의 허용 하나를 추가하면 해결되는 경우입니다.

연습해 봅시다!

개발자를 위한 AWS 보안 활용