S3 접근 우선순위와 암묵적인 거부

S3는 기존 접근 제어 시스템인 ACL 등 여러 가지가 혼제되어 복잡한 접근 우선순위를 갖고 있습니다.

S3 접근 우선순위

퍼블릭 액세스 차단(BPA)

버킷 자체의 퍼블릭 접근을 차단하는 옵션이 활성화되어 있으면, ACL이나 버킷 정책에서 퍼블릭을 허용해도 접근이 불가합니다.

버킷 정책에서 명시적 Deny

IAM, 버킷정책, ACL 어디에서든 Deny(거부)가 있으면 무조건 거부됩니다.

버킷 정책 vs IAM 정책

두 정책을 동시 평가하며 하나라도 Deny가 있으면 우선적으로 거부됩니다. Allow는 둘 중 하나에만 있어도 허용되지만, Deny가 우선입니다.

ACL, Public 권한

ACL로 퍼블릭 액세스를 부여해도 BPA가 활성화되어 있거나 다른 정책에 Deny가 존재하면 무효화됩니다. 최근 S3에서는 ACL을 최대한 제한적으로 사용하며, 기본적으로는 버킷 정책 및 IAM 권한이 중심입니다.

None

명시적 설정이 전혀 없으면 암묵적 거부로 접근이 불가합니다.

암묵적 거부?

여기서 제일 모호하고 헷갈리는 것이 암묵적 거부 입니다.

만약 버킷 정책에 해당 버킷의 모든 객체에 대한 GET 요청을 deny 한 상황을 가정해봅니다. 하지만 예외적으로 https://naver.com~ 으로 시작하는 url은 접근을 허용합니다.

이렇게 되면 명시적 deny가 되기 때문에 https://naver.com~을 제외한 다른 url에서는 객체에 접근이 불가능합니다.

여기서 중요한 것이 있습니다.

PUT은 어떨까요? PUT은 명시적으로 deny를 하지 않았기 때문에 암묵적으로 요청이 거부 됩니다. 하지만, IAM 정책에 권한이 있다면 말이 달라집니다. IAM 정책에 S3 PUT에 권한이 있다면, 암묵적 거부 상태이더라도 PUT이 가능합니다.

이것이 중요한 포인트인데요, 위의 예시에서 https://naver.com~ 에서의 객체 접근에 대한 예외를 두었지만 이것은 허용을 한 것이 아니라, 암묵적인 거부 상태인 것과 동일합니다.

즉, 예외를 둔 것이지 여전히 암묵적 거부 상태여서, 해당 버킷의 객체에 접근을 허용하는 사용자의 정책이 없다면 요청은 거부됩니다.

그래서 IAM 정책이 없다면 명시적 허용을 해줘야지만 해당 객체에 접근을 할 수가 있습니다.