Amazon S3의 액세스 제어

Amazon S3의 액세스 제어 (Access control in Amazon S3)

AWS에서 리소스는 작업할 수 있는 엔터티예요. Amazon Simple Storage Service(S3)에서는 버킷(buckets) 과 객체(objects) 가 원래의 Amazon S3 리소스예요. 모든 S3 고객은 객체를 담은 버킷을 가지고 있을 가능성이 커요. S3에 새 기능이 추가되면서 추가 리소스도 추가되었지만 모든 고객이 이러한 기능별 리소스를 사용하는 것은 아니에요. Amazon S3 리소스에 대한 자세한 내용은 S3 리소스를 참고하세요.

기본적으로 모든 Amazon S3 리소스는 비공개예요. 또한 기본적으로 리소스를 생성한 AWS 계정의 루트 사용자(리소스 소유자)와 해당 계정 내에서 필요한 권한을 가진 IAM 사용자는 자신이 만든 리소스에 액세스할 수 있어요. 리소스 소유자는 누가 리소스에 액세스할 수 있고 다른 사람이 리소스에서 수행할 수 있는 작업을 결정해요. S3에는 다른 사람에게 S3 리소스에 대한 액세스를 부여하는 데 사용할 수 있는 다양한 액세스 관리 도구가 있어요.

다음 섹션에서는 S3 리소스, 사용 가능한 S3 액세스 관리 도구, 각 액세스 관리 도구의 최적 사용 사례에 대한 개요를 제공해요. 이 섹션의 목록은 모든 S3 리소스, 액세스 관리 도구, 일반적인 액세스 관리 사용 사례를 포함하도록 포괄적으로 설계되었어요. 동시에 이 섹션은 원하는 기술 세부 정보로 안내하는 디렉터리 역할을 하도록 설계되었어요. 다음 주제 중 일부를 잘 이해하고 있다면 해당하는 섹션으로 건너뛸 수 있어요.

S3 리소스 유형별 S3 API 작업 권한에 대한 자세한 내용은 Amazon S3 API 작업에 필요한 권한을 참고하세요.

출처: 문서

본문

S3 리소스 (S3 resources)

원래의 Amazon S3 리소스는 버킷과 그 안에 포함된 객체예요. S3에 새 기능이 추가되면서 새 리소스도 추가되었어요. 다음은 S3 리소스와 각각의 기능에 대한 전체 목록이에요.

리소스 유형 Amazon S3 기능 설명
bucket 핵심 기능 버킷은 객체를 위한 컨테이너예요. S3에 객체를 저장하려면 버킷을 만들고 그 버킷에 하나 이상의 객체를 업로드하세요. 자세한 내용은 Amazon S3 일반 목적 버킷 생성, 구성 및 작업을 참고하세요.
object 핵심 기능 객체는 파일과 그 파일을 설명하는 모든 메타데이터일 수 있어요. 객체가 버킷에 있으면 열고, 다운로드하고, 이동할 수 있어요. 자세한 내용은 Amazon S3에서 객체 작업을 참고하세요.
accesspoint 액세스 포인트 액세스 포인트는 버킷에 연결된 명명된 네트워크 엔드포인트로, GetObject 및 PutObject 같은 Amazon S3 객체 작업을 수행하는 데 사용할 수 있어요. 각 액세스 포인트는 기본 버킷에 연결된 버킷 정책과 함께 작동하는 고유한 권한, 네트워크 제어, 사용자 지정 액세스 포인트 정책을 가져요. 모든 액세스 포인트를 가상 프라이빗 클라우드(VPC)에서만 요청을 수락하도록 구성하거나 각 액세스 포인트에 대한 사용자 지정 공개 액세스 차단 설정을 구성할 수 있어요. 자세한 내용은 액세스 포인트로 공유 데이터셋 액세스 관리를 참고하세요.
objectlambdaaccesspoint Object Lambda 액세스 포인트 Object Lambda 액세스 포인트는 Lambda 함수와도 연결된 버킷용 액세스 포인트예요. Object Lambda 액세스 포인트를 사용하면 Amazon S3 GET, LIST, HEAD 요청에 자체 코드를 추가해 데이터가 애플리케이션에 반환될 때 수정·처리할 수 있어요. 자세한 내용은 Object Lambda 액세스 포인트 생성을 참고하세요.
multiregionaccesspoint Multi-Region 액세스 포인트 Multi-Region 액세스 포인트는 여러 AWS 리전에 있는 Amazon S3 버킷에서 요청을 처리하는 데 애플리케이션이 사용할 수 있는 글로벌 엔드포인트를 제공해요. 단일 리전에서 사용되는 것과 동일한 아키텍처로 다중 리전 애플리케이션을 구축한 다음 전 세계 어디에서나 실행할 수 있어요. 혼잡한 공용 인터넷으로 요청을 보내는 대신 Multi-Region 액세스 포인트 글로벌 엔드포인트에 대한 애플리케이션 요청은 AWS 글로벌 네트워크를 통해 가장 가까운 Amazon S3 버킷으로 자동 라우팅돼요. 자세한 내용은 Multi-Region 액세스 포인트로 다중 리전 트래픽 관리를 참고하세요.
job S3 Batch Operations 작업은 S3 Batch Operations 기능의 리소스예요. S3 Batch Operations를 사용해 지정한 Amazon S3 객체 목록에 대해 대규모 일괄 작업을 수행할 수 있어요. Amazon S3는 일괄 작업의 진행 상황을 추적하고, 알림을 보내며, 모든 작업에 대한 상세 완료 보고서를 저장해 완전 관리형, 감사 가능, 서버리스 경험을 제공해요. 자세한 내용은 Batch Operations로 객체 대량 작업을 참고하세요.
storagelensconfiguration S3 Storage Lens S3 Storage Lens 구성은 계정 전체에 걸쳐 조직 차원의 스토리지 메트릭과 사용자 데이터를 수집해요. S3 Storage Lens는 관리자에게 조직의 수백 또는 수천 개 계정에 걸친 객체 스토리지 사용량과 활동에 대한 단일 보기를 제공하며, 여러 집계 수준에서 인사이트를 생성할 수 있는 세부 정보를 제공해요. 자세한 내용은 Amazon S3 Storage Lens로 스토리지 활동 및 사용량 모니터링을 참고하세요.
storagelensgroup S3 Storage Lens 그룹 S3 Storage Lens 그룹은 객체 메타데이터를 기반으로 한 사용자 지정 필터를 사용해 메트릭을 집계해요. S3 Storage Lens 그룹은 객체 연령별 분포, 가장 일반적인 파일 유형 등 데이터 특성을 조사하는 데 도움을 줘요. 자세한 내용은 S3 Storage Lens 그룹으로 메트릭 필터링 및 집계 작업을 참고하세요.
accessgrantsinstance S3 Access Grants S3 Access Grants 인스턴스는 생성하는 S3 그랜트의 컨테이너예요. S3 Access Grants를 사용하면 계정 내 IAM 자격, 다른 계정의 IAM 자격(교차 계정), 회사 디렉터리에서 AWS IAM Identity Center에 추가한 디렉터리 자격에 대해 Amazon S3 데이터에 대한 그랜트를 만들 수 있어요. S3 Access Grants에 대한 자세한 내용은 S3 Access Grants로 액세스 관리를 참고하세요.
accessgrantslocation S3 Access Grants 위치 Access Grants 위치는 S3 Access Grants 인스턴스에 등록하는 버킷, 버킷 내 프리픽스 또는 객체예요. 해당 위치에 그랜트를 만들기 전에 S3 Access Grants 인스턴스에 위치를 등록해야 해요. 그런 다음 S3 Access Grants를 사용해 계정 내 IAM 자격, 다른 계정의 IAM 자격(교차 계정), 회사 디렉터리에서 AWS IAM Identity Center에 추가한 디렉터리 자격에 대해 버킷, 프리픽스 또는 객체에 대한 액세스를 부여할 수 있어요. 자세한 내용은 S3 Access Grants로 액세스 관리를 참고하세요.
accessgrant S3 Access Grants Access Grant는 Amazon S3 데이터에 대한 개별 그랜트예요. S3 Access Grants를 사용하면 계정 내 IAM 자격, 다른 계정의 IAM 자격(교차 계정), 회사 디렉터리에서 AWS IAM Identity Center에 추가한 디렉터리 자격에 대해 Amazon S3 데이터에 대한 그랜트를 만들 수 있어요. 자세한 내용은 S3 Access Grants로 액세스 관리를 참고하세요.

버킷에는 두 가지 유형이 있어요. 일반 목적 버킷(general purpose buckets) 과 디렉터리 버킷(directory buckets) 이에요.

  • 일반 목적 버킷은 원래의 S3 버킷 유형이며 대부분의 사용 사례와 액세스 패턴에 권장돼요. 일반 목적 버킷은 S3 Express One Zone을 제외한 모든 스토리지 클래스에 걸쳐 저장된 객체도 허용해요. S3 스토리지 클래스에 대한 자세한 내용은 Amazon S3 스토리지 클래스 이해 및 관리를 참고하세요.
  • 디렉터리 버킷은 S3 Express One Zone 스토리지 클래스를 사용하며, 애플리케이션이 성능에 민감하고 한 자릿수 밀리초의 PUT 및 GET 지연 시간의 이점을 얻는 경우 권장돼요. 자세한 내용은 디렉터리 버킷 작업, S3 Express One Zone, IAM으로 리전 엔드포인트 API 작업 권한 부여를 참고하세요.

S3 리소스 분류

Amazon S3는 S3 리소스를 분류하고 구성하는 기능을 제공해요. 리소스를 분류하는 것은 리소스를 구성하는 데 유용할 뿐만 아니라 리소스 범주를 기반으로 액세스 관리 규칙을 설정할 수도 있어요. 특히 프리픽스와 태그는 액세스 관리 권한을 설정할 때 사용할 수 있는 두 가지 스토리지 구성 기능이에요.

참고 다음 정보는 일반 목적 버킷에 적용돼요. 디렉터리 버킷은 태그를 지원하지 않으며 프리픽스 제한이 있어요. 자세한 내용은 IAM으로 리전 엔드포인트 API 작업 권한 부여를 참고하세요.

  • 프리픽스 — Amazon S3의 프리픽스는 S3 버킷에 저장된 객체를 구성하는 데 사용되는 객체 키 이름의 시작 부분에 있는 문자열이에요. 객체 키 이름 내에서 프리픽스의 끝을 나타내는 데 슬래시(/) 같은 구분 문자를 사용할 수 있어요. 예를 들어 engineering/ 프리픽스로 시작하는 객체 키 이름이나 marketing/campaigns/ 프리픽스로 시작하는 객체 키 이름을 가질 수 있어요. 프리픽스 끝에 슬래시 문자(/) 같은 구분 문자를 사용하면 폴더 및 파일 명명 규칙을 모방해요. 하지만 S3에서 프리픽스는 객체 키 이름의 일부예요. 일반 목적 S3 버킷에는 실제 폴더 계층 구조가 없어요. Amazon S3는 프리픽스를 사용해 객체를 구성하고 그룹화하는 것을 지원해요. 또한 프리픽스로 객체에 대한 액세스를 관리할 수도 있어요. 예를 들어 특정 프리픽스로 시작하는 이름을 가진 객체에만 액세스를 제한할 수 있어요. 자세한 내용은 프리픽스로 객체 구성을 참고하세요. S3 콘솔은 폴더 개념을 사용하며, 일반 목적 버킷에서 이는 본질적으로 객체 키 이름 앞에 붙는 프리픽스예요. 자세한 내용은 폴더로 Amazon S3 콘솔에서 객체 구성을 참고하세요.
  • 태그 — 각 태그는 리소스에 할당하는 키-값 쌍이에요. 예를 들어 일부 리소스에 topicCategory=engineering 태그를 지정할 수 있어요. 태그를 사용해 비용 할당, 분류 및 구성, 액세스 제어에 도움을 줄 수 있어요. 버킷 태그는 비용 할당에만 사용돼요. 객체, S3 Storage Lens, 작업, S3 Access Grants에는 구성 또는 액세스 제어 목적으로 태그를 지정할 수 있어요. S3 Access Grants에서는 비용 할당에도 태그를 사용할 수 있어요. 예를 들어 태그로 리소스에 대한 액세스를 제어하려면 특정 태그 또는 태그 조합을 가진 객체만 공유할 수 있어요. 자세한 내용은 IAM 사용자 가이드의 리소스 태그로 AWS 리소스에 대한 액세스 제어를 참고하세요.

ID (Identities)

Amazon S3에서 리소스 소유자는 버킷이나 객체 같은 리소스를 생성한 ID예요. 기본적으로 리소스를 생성한 계정의 루트 사용자와 해당 계정 내에서 필수 권한이 있는 IAM 자격만 S3 리소스에 액세스할 수 있어요. 리소스 소유자는 다른 ID에 S3 리소스에 대한 액세스를 부여할 수 있어요.

리소스를 소유하지 않은 ID는 해당 리소스에 대한 액세스를 요청할 수 있어요. 리소스에 대한 요청은 인증되거나 인증되지 않을 수 있어요. 인증된 요청에는 요청 발신자를 인증하는 서명 값이 포함되어야 하지만 인증되지 않은 요청에는 서명이 필요하지 않아요. 인증된 사용자에게만 액세스를 부여할 것을 권장해요. 요청 인증에 대한 자세한 내용은 Amazon S3 API 참조의 요청하기를 참고하세요.

중요 AWS 계정 루트 사용자 자격 증명을 사용해 인증된 요청을 하지 말 것을 권장해요. 대신 IAM 역할을 만들고 해당 역할에 전체 액세스를 부여하세요. 이 역할을 가진 사용자를 관리자 사용자라고 해요. AWS 계정 루트 사용자 자격 증명 대신 관리자 역할에 할당된 자격 증명을 사용해 AWS와 상호작용하고 버킷 생성, 사용자 생성, 권한 부여 같은 작업을 수행할 수 있어요. 자세한 내용은 AWS 일반 참조의 AWS 계정 루트 사용자 자격 증명과 IAM 사용자 자격 증명, 그리고 IAM 사용자 가이드의 IAM 보안 모범 사례를 참고하세요.

Amazon S3의 데이터에 액세스하는 자격은 다음 중 하나일 수 있어요.

  • AWS 계정 소유자 – 리소스를 생성한 AWS 계정. 예를 들어 버킷을 생성한 계정이에요. 이 계정은 리소스를 소유해요. 자세한 내용은 AWS 계정 루트 사용자를 참고하세요.
  • AWS 계정 소유자와 같은 계정의 IAM 자격 – S3 액세스가 필요한 새 팀 구성원을 위해 계정을 설정할 때 AWS 계정 소유자는 AWS Identity and Access Management(IAM)를 사용해 사용자(user), 그룹(group), 역할(role) 을 만들 수 있어요. 그런 다음 AWS 계정 소유자는 이러한 IAM 자격과 리소스를 공유할 수 있어요. 계정 소유자는 IAM 자격에 부여할 권한도 지정할 수 있으며, 이는 공유 리소스에서 수행할 수 있는 작업을 허용하거나 거부해요. IAM 자격은 공유 리소스에 액세스하기 전에 사용자가 로그인 자격 증명을 입력하도록 요구하는 기능을 포함한 향상된 기능을 제공해요. IAM 자격을 사용하면 강력한 ID 기반을 지원하기 위한 IAM 다중 인증(MFA) 형태를 구현할 수 있어요. IAM 모범 사례는 각 개별 사용자에게 권한을 부여하는 대신 액세스 관리용 역할을 만드는 것이에요. 개별 사용자를 적절한 역할에 할당하세요. 자세한 내용은 IAM 보안 모범 사례를 참고하세요.
  • 다른 AWS 계정 소유자와 그들의 IAM 자격(교차 계정 액세스) – AWS 계정 소유자는 다른 AWS 계정 소유자 또는 다른 AWS 계정에 속한 IAM 자격에 리소스에 대한 액세스를 부여할 수도 있어요.

    참고 권한 위임 – AWS 계정이 리소스를 소유하면 해당 권한을 다른 AWS 계정에 부여할 수 있어요. 그 계정은 그 권한 또는 그 일부를 같은 계정의 사용자에게 위임할 수 있어요. 이를 권한 위임이라고 해요. 하지만 다른 계정으로부터 권한을 받은 계정은 그 권한을 다른 AWS 계정에 "교차 계정"으로 위임할 수 없어요.

  • 익명 사용자(공개 액세스) – AWS 계정 소유자는 리소스를 공개할 수 있어요. 리소스를 공개하는 것은 기술적으로 리소스를 익명 사용자와 공유하는 것이에요. 2023년 4월 이후 생성된 버킷은 이 설정을 변경하지 않는 한 기본적으로 모든 공개 액세스를 차단해요. 버킷이 공개 액세스를 차단하도록 설정하고 인증된 사용자에게만 액세스를 부여할 것을 권장해요. 공개 액세스 차단에 대한 자세한 내용은 Amazon S3 스토리지에 대한 공개 액세스 차단을 참고하세요.
  • AWS 서비스 – 리소스 소유자는 다른 AWS 서비스에 Amazon S3 리소스에 대한 액세스를 부여할 수 있어요. 예를 들어 AWS CloudTrail 서비스에 버킷에 로그 파일을 쓰는 s3:PutObject 권한을 부여할 수 있어요. 자세한 내용은 AWS 서비스에 대한 액세스 제공을 참고하세요.
  • 회사 디렉터리 자격 – 리소스 소유자는 S3 Access Grants를 사용해 회사 디렉터리의 사용자 또는 역할에 S3 리소스에 대한 액세스를 부여할 수 있어요. 회사 디렉터리를 AWS IAM Identity Center에 추가하는 방법에 대한 자세한 내용은 IAM Identity Center란 무엇인가요?를 참고하세요.

버킷 또는 리소스 소유자

버킷을 만들고 객체를 업로드하는 데 사용하는 AWS 계정이 해당 리소스를 소유해요. 버킷 소유자는 다른 AWS 계정(또는 다른 계정의 사용자)에 객체를 업로드할 교차 계정 권한을 부여할 수 있어요.

버킷 소유자가 다른 계정에 버킷에 객체를 업로드하도록 허용하면 기본적으로 버킷 소유자는 자신의 버킷에 업로드된 모든 객체를 소유해요. 하지만 버킷 소유자 강제(Bucket owner enforced) 및 버킷 소유자 선호(Bucket owner preferred) 버킷 설정이 모두 꺼져 있으면 객체를 업로드하는 AWS 계정이 해당 객체를 소유하며, 버킷 소유자는 다른 계정이 소유한 객체에 대한 권한이 없어요. 단, 다음 예외가 있어요.

  • 버킷 소유자는 청구서를 지불해요. 버킷 소유자는 누가 소유하는지와 관계없이 버킷의 모든 객체에 대한 액세스를 거부하거나 모든 객체를 삭제할 수 있어요.
  • 버킷 소유자는 누가 소유하는지와 관계없이 모든 객체를 보관하거나 보관된 객체를 복원할 수 있어요. 보관은 객체를 저장하는 데 사용되는 스토리지 클래스를 말해요. 자세한 내용은 객체 라이프사이클 관리를 참고하세요.

액세스 관리 도구 (Access management tools)

Amazon S3는 다양한 보안 기능과 도구를 제공해요. 다음은 이러한 기능과 도구의 포괄적인 목록이에요. 이러한 액세스 관리 도구가 모두 필요하지는 않지만 Amazon S3 리소스에 대한 액세스를 부여하려면 하나 이상을 사용해야 해요. 이러한 도구를 적절히 적용하면 리소스가 의도한 사용자에게만 액세스 가능하도록 하는 데 도움이 될 수 있어요.

가장 일반적으로 사용되는 액세스 관리 도구는 액세스 정책(access policy) 이에요. 액세스 정책은 버킷에 대한 버킷 정책처럼 AWS 리소스에 연결되는 리소스 기반 정책일 수 있어요. 액세스 정책은 IAM 사용자, 그룹 또는 역할 같은 AWS Identity and Access Management(IAM) 자격에 연결되는 ID 기반 정책일 수도 있어요. AWS 계정과 IAM 사용자, 그룹, 역할이 리소스에서 작업을 수행할 권한을 부여하도록 액세스 정책을 작성하세요. 예를 들어 다른 AWS 계정에 PUT Object 권한을 부여해 그 계정이 버킷에 객체를 업로드할 수 있게 할 수 있어요.

액세스 정책은 누가 무엇에 액세스할 수 있는지 설명해요. Amazon S3가 요청을 받으면 요청을 승인할지 거부할지 결정하기 위해 모든 액세스 정책을 평가해야 해요. Amazon S3가 이러한 정책을 평가하는 방법에 대한 자세한 내용은 Amazon S3가 요청을 승인하는 방식을 참고하세요.

다음은 Amazon S3에서 사용할 수 있는 액세스 관리 도구예요.

  • Amazon S3 버킷 정책은 특정 버킷에 연결되는 JSON 형식의 AWS Identity and Access Management(IAM) 리소스 기반 정책이에요. 버킷 정책을 사용해 다른 AWS 계정 또는 IAM 자격에 버킷과 그 안의 객체에 대한 권한을 부여하세요. 많은 S3 액세스 관리 사용 사례는 버킷 정책으로 충족할 수 있어요. 버킷 정책을 사용하면 승인한 자격만 리소스에 액세스하고 그 안에서 작업을 수행할 수 있도록 버킷 액세스를 개인화할 수 있어요. 자세한 내용은 Amazon S3용 버킷 정책을 참고하세요. 다음은 버킷 정책 예시예요. 버킷 정책은 JSON 파일로 표현해요. 이 예시 정책은 IAM 역할에 버킷의 모든 객체에 대한 읽기 권한을 부여해요. BucketLevelReadPermissions라는 이름의 문 하나가 포함되어 있으며, amzn-s3-demo-bucket1이라는 버킷의 객체에 대해 s3:GetObject 작업(읽기 권한)을 허용해요. Principal로 IAM 역할을 지정함으로써 이 정책은 이 역할을 가진 모든 IAM 사용자에게 액세스를 부여해요. 이 예시 정책을 사용하려면 사용자 입력 자리 표시자를 본인의 정보로 바꾸세요.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "BucketLevelReadPermissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789101:role/s3-role"
            },
            "Action": ["s3:GetObject"],
            "Resource": ["arn:aws:s3:::amzn-s3-demo-bucket/*"]
        }
    ]
}

참고 정책을 만들 때 Principal 요소에 와일드카드 문자(*)를 사용하지 마세요. 와일드카드 문자를 사용하면 누구나 Amazon S3 리소스에 액세스할 수 있기 때문이에요. 대신 버킷에 액세스할 수 있는 사용자 또는 그룹을 명시적으로 나열하거나 정책의 조건 절을 사용해 충족해야 하는 조건을 나열하세요. 또한 사용자 또는 그룹의 작업에 와일드카드 문자를 포함하는 대신 적용 가능할 때 특정 권한을 부여하세요.

  • ID 기반 또는 IAM 사용자 정책은 AWS Identity and Access Management(IAM) 정책의 한 유형이에요. ID 기반 정책은 AWS 계정의 IAM 사용자, 그룹 또는 역할에 연결되는 JSON 형식의 정책이에요. ID 기반 정책을 사용해 IAM 자격에 버킷이나 객체에 대한 액세스를 부여할 수 있어요. 계정에서 IAM 사용자, 그룹, 역할을 만들고 여기에 액세스 정책을 연결할 수 있어요. 그런 다음 Amazon S3 리소스를 포함한 AWS 리소스에 대한 액세스를 부여할 수 있어요. 자세한 내용은 Amazon S3용 ID 기반 정책을 참고하세요. 다음은 ID 기반 정책 예시예요. 예시 정책은 연결된 IAM 역할이 버킷과 그 안의 객체에서 여섯 가지 다른 Amazon S3 작업(권한)을 수행할 수 있게 해줘요. 이 정책을 계정의 IAM 역할에 연결하고 역할을 일부 IAM 사용자에게 할당하면 이 역할을 가진 사용자가 정책에 지정된 리소스(버킷)에서 이러한 작업을 수행할 수 있게 돼요. 이 예시 정책을 사용하려면 사용자 입력 자리 표시자를 본인의 정보로 바꾸세요.
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AssignARoleActions",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:GetBucketLocation"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket/*",
                "arn:aws:s3:::amzn-s3-demo-bucket"
            ]
        },
        {
            "Sid": "AssignARoleActions2",
            "Effect": "Allow",
            "Action": "s3:ListAllMyBuckets",
            "Resource": "*"
        }
    ]
}
  • S3 Access Grants를 사용해 Active Directory 같은 회사 ID 디렉터리의 자격과 AWS Identity and Access Management(IAM) 자격 모두에 대해 Amazon S3 데이터에 대한 액세스 그랜트를 만들 수 있어요. S3 Access Grants는 대규모로 데이터 권한을 관리하는 데 도움을 줘요. 또한 S3 Access Grants는 엔드 사용자 ID와 S3 데이터에 액세스하는 데 사용된 애플리케이션을 AWS CloudTrail에 기록해요. 이는 S3 버킷의 데이터에 대한 모든 액세스에 대해 엔드 사용자 ID 수준까지 상세한 감사 기록을 제공해요. 자세한 내용은 S3 Access Grants로 액세스 관리를 참고하세요.
  • Amazon S3 액세스 포인트는 S3의 공유 데이터셋을 사용하는 애플리케이션을 위해 대규모 데이터 액세스 관리를 단순화해요. 액세스 포인트는 버킷에 연결된 명명된 네트워크 엔드포인트예요. 액세스 포인트를 사용해 객체 업로드 및 검색 같은 S3 객체 작업을 대규모로 수행할 수 있어요. 버킷에는 최대 10,000개의 액세스 포인트를 연결할 수 있으며, 각 액세스 포인트에 대해 별개의 권한과 네트워크 제어를 적용해 S3 객체에 대한 액세스를 세밀하게 제어할 수 있어요. S3 액세스 포인트는 같은 계정 또는 다른 신뢰할 수 있는 계정의 버킷과 연결할 수 있어요. 액세스 포인트 정책은 기본 버킷 정책과 함께 평가되는 리소스 기반 정책이에요. 자세한 내용은 액세스 포인트로 공유 데이터셋 액세스 관리를 참고하세요.
  • ACL은 수혜자와 부여된 권한을 식별하는 그랜트 목록이에요. ACL은 다른 AWS 계정에 기본 읽기 또는 쓰기 권한을 부여해요. ACL은 Amazon S3 전용 XML 스키마를 사용해요. ACL은 AWS Identity and Access Management(IAM) 정책의 한 유형이에요. 객체 ACL은 객체에 대한 액세스를 관리하는 데 사용되고, 버킷 ACL은 버킷에 대한 액세스를 관리하는 데 사용돼요. 버킷 정책에서는 버킷 전체에 대한 단일 정책이 있지만 객체 ACL은 각 객체마다 지정돼요. 각 객체에 대한 액세스를 개별적으로 제어해야 하는 상황을 제외하고는 ACL을 꺼 두는 것을 권장해요. ACL 사용에 대한 자세한 내용은 버킷의 객체 소유권 제어 및 ACL 비활성화를 참고하세요.

    경고 Amazon S3의 대부분의 현대적 사용 사례는 ACL을 사용할 필요가 없어요. 다음은 버킷 ACL 예시예요. ACL의 그랜트는 전체 제어 권한을 가진 버킷 소유자를 보여줘요.

<?xml version="1.0" encoding="UTF-8"?>
    <AccessControlPolicy xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
        <Owner>
            <ID>Owner-Canonical-User-ID</ID>
        </Owner>
        <AccessControlList>
            <Grant>
                <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Canonical User">
                    <ID>Owner-Canonical-User-ID</ID>
                </Grantee>
                <Permission>FULL_CONTROL</Permission>
            </Grant>
        </AccessControlList>
    </AccessControlPolicy>

객체에 대한 액세스를 관리하려면 객체의 소유자여야 해요. 객체 소유권(버킷 수준 설정)을 사용해 버킷에 업로드된 객체의 소유권을 제어할 수 있어요. 또한 객체 소유권을 사용해 ACL을 켤 수 있어요. 기본적으로 객체 소유권은 버킷 소유자 강제(Bucket owner enforced) 설정으로 설정되며 모든 ACL이 꺼져 있어요. ACL이 꺼져 있으면 버킷 소유자가 버킷의 모든 객체를 소유하고 데이터에 대한 액세스를 독점적으로 관리해요. 액세스를 관리하기 위해 버킷 소유자는 정책이나 ACL을 제외한 다른 액세스 관리 도구를 사용해요. 자세한 내용은 버킷의 객체 소유권 제어 및 ACL 비활성화를 참고하세요. 객체 소유권에는 버킷에 업로드된 객체의 소유권을 제어하고 ACL을 켜는 데 사용할 수 있는 세 가지 설정이 있어요.

  • ACL 꺼짐 - 버킷 소유자 강제(기본값) – ACL이 꺼져 있고, 버킷 소유자가 버킷의 모든 객체를 자동으로 소유하고 완전히 제어해요. ACL은 S3 버킷의 데이터 권한에 영향을 주지 않아요. 버킷은 정책만 사용해 액세스 제어를 정의해요.
  • ACL 켜짐 - 버킷 소유자 선호 – 다른 계정이 bucket-owner-full-control 캐닝 ACL로 버킷에 쓴 새 객체를 버킷 소유자가 소유하고 완전히 제어해요.
  • 객체 작성자 – 객체를 업로드하는 AWS 계정이 객체를 소유하고, 완전히 제어하며, ACL을 통해 다른 사용자에게 액세스 권한을 부여할 수 있어요.

추가 모범 사례

전송 중 및 저장 데이터를 모두 보호하는 데 도움이 되는 다음 버킷 설정과 도구 사용을 고려하세요. 둘 다 데이터의 무결성과 접근성을 유지하는 데 중요해요.

  • 공개 액세스 차단 — 기본 버킷 수준 설정인 공개 액세스 차단(Block Public Access) 을 끄지 마세요. 이 설정은 기본적으로 데이터에 대한 공개 액세스를 차단해요. 공개 액세스 차단에 대한 자세한 내용은 Amazon S3 스토리지에 대한 공개 액세스 차단을 참고하세요.
  • S3 버전 관리 — 데이터 무결성을 위해 S3 버전 관리 버킷 설정을 구현할 수 있어요. 이 설정은 객체를 덮어쓰는 대신 업데이트할 때 객체를 버전화해요. 필요할 때 이전 버전을 보존, 검색, 복원하는 데 S3 버전 관리를 사용할 수 있어요. S3 버전 관리에 대한 정보는 S3 버전 관리로 객체의 여러 버전 유지를 참고하세요.
  • S3 객체 잠금 — S3 객체 잠금은 데이터 무결성을 달성하기 위해 구현할 수 있는 또 다른 설정이에요. 이 기능은 WORM(한 번 쓰고 여러 번 읽기) 모델을 구현해 객체를 불변적으로 저장할 수 있어요. 객체 잠금에 대한 정보는 객체 잠금으로 객체 잠금을 참고하세요.
  • 객체 암호화 — Amazon S3는 전송 중 및 저장 데이터를 보호하는 여러 객체 암호화 옵션을 제공해요. 서버 측 암호화는 데이터 센터의 디스크에 저장하기 전에 객체를 암호화한 다음 객체를 다운로드할 때 복호화해요. 요청을 인증하고 액세스 권한이 있으면 암호화된 객체와 암호화되지 않은 객체에 액세스하는 방식에 차이가 없어요. 자세한 내용은 서버 측 암호화로 데이터 보호를 참고하세요. S3는 기본적으로 새로 업로드된 객체를 암호화해요. 자세한 내용은 Amazon S3 버킷의 기본 서버 측 암호화 동작 설정을 참고하세요. 클라이언트 측 암호화는 Amazon S3로 보내기 전에 데이터를 암호화하는 것입니다. 자세한 내용은 클라이언트 측 암호화로 데이터 보호를 참고하세요.
  • 서명 방법 — 서명 버전 4는 HTTP로 전송되는 AWS 요청에 인증 정보를 추가하는 프로세스예요. 보안을 위해 대부분의 AWS 요청은 액세스 키 ID와 비밀 액세스 키로 구성된 액세스 키로 서명되어야 해요. 이 두 키는 일반적으로 보안 자격 증명으로 불려요. 자세한 내용은 요청 인증(AWS 서명 버전 4)과 서명 버전 4 서명 프로세스를 참고하세요.

작업 (Actions)

Amazon S3 권한과 조건 키의 전체 목록은 서비스 권한 부여 참조의 Amazon S3용 작업, 리소스 및 조건 키를 참고하세요. S3 리소스 유형별 S3 API 작업 권한에 대한 자세한 내용은 Amazon S3 API 작업에 필요한 권한을 참고하세요.

작업. Amazon S3용 AWS Identity and Access Management(IAM) 작업은 S3 버킷 또는 객체에서 수행할 수 있는 가능한 작업이에요. 이러한 작업을 자격에 부여해 S3 리소스에 대해 작업할 수 있게 해요. S3 작업의 예로는 버킷의 객체를 읽는 s3:GetObject, 버킷에 객체를 쓰는 s3:PutObject가 있어요.

조건 키. 작업 외에도 IAM 조건 키는 조건이 충족될 때만 액세스 권한을 부여하는 데 사용돼요. 조건 키는 선택 사항이에요.

참고 버킷 정책 같은 리소스 기반 액세스 정책이나 ID 기반 정책에서 다음을 지정할 수 있어요.

  • 정책 문의 Action 요소에 작업 또는 작업 배열.
  • 정책 문의 Effect 요소에서 나열된 작업을 부여하려면 Allow를, 나열된 작업을 차단하려면 Deny를 지정할 수 있어요. 최소 권한 관행을 더 유지하려면 액세스 정책의 Effect 요소에 있는 Deny 문은 가능한 한 광범위해야 하고 Allow 문은 가능한 한 좁아야 해요. Deny 효과를 s3:* 작업과 결합하는 것도 정책 조건 문에 포함된 자격에 대한 옵트인 모범 사례를 구현하는 또 다른 좋은 방법이에요.
  • 정책 문의 Condition 요소에 조건 키.

액세스 관리 사용 사례 (Access management use cases)

Amazon S3는 리소스 소유자에게 액세스 부여를 위한 다양한 도구를 제공해요. 사용하는 S3 액세스 관리 도구는 공유하려는 S3 리소스, 액세스를 부여하는 자격, 허용하거나 거부하려는 작업에 따라 달라져요. S3 리소스에 대한 액세스를 관리하기 위해 S3 액세스 관리 도구를 하나 또는 조합으로 사용할 수 있어요.

대부분의 경우 액세스 정책으로 권한을 관리할 수 있어요. 액세스 정책은 버킷 같은 리소스나 다른 Amazon S3 리소스(S3 리소스)에 연결되는 리소스 기반 정책일 수 있어요. 액세스 정책은 계정의 AWS Identity and Access Management(IAM) 사용자, 그룹 또는 역할에 연결되는 ID 기반 정책일 수도 있어요. 버킷 정책이 사용 사례에 더 잘 맞을 수 있어요. 자세한 내용은 Amazon S3용 버킷 정책을 참고하세요. 또는 AWS Identity and Access Management(IAM)로 AWS 계정 내에서 IAM 사용자, 그룹, 역할을 만들고 ID 기반 정책을 통해 버킷과 객체에 대한 액세스를 관리할 수 있어요. 자세한 내용은 Amazon S3용 ID 기반 정책을 참고하세요.

이 액세스 관리 옵션을 탐색하는 데 도움이 되도록 다음은 일반적인 Amazon S3 고객 사용 사례와 각 S3 액세스 관리 도구에 대한 권장 사항이에요.

사용 사례: 내 버킷의 데이터에 대한 액세스 부여. 모든 액세스 관리 도구가 이 기본 사용 사례를 충족할 수 있어요. 다음 액세스 관리 도구를 권장해요.

  • 버킷 정책 – 하나의 버킷 또는 소수의 버킷에 대한 액세스를 부여하려는 경우, 또는 버킷 간 버킷 액세스 권한이 유사한 경우 버킷 정책을 사용하세요. 버킷 정책을 사용하면 버킷마다 정책 하나를 관리해요. 자세한 내용은 Amazon S3용 버킷 정책을 참고하세요.
  • ID 기반 정책 – 매우 많은 버킷이 있고 각 버킷에 대해 다른 액세스 권한이 있으며 관리할 사용자 역할이 몇 개뿐인 경우 IAM 사용자, 그룹 또는 역할용 IAM 정책을 사용할 수 있어요. IAM 정책은 Amazon S3 리소스뿐만 아니라 다른 AWS 리소스에 대한 사용자 액세스를 관리하는 경우에도 좋은 옵션이에요. 자세한 내용은 예시 1: 버킷 소유자가 사용자에게 버킷 권한 부여를 참고하세요.
  • S3 Access Grants – S3 Access Grants를 사용해 S3 버킷, 프리픽스 또는 객체에 대한 액세스를 부여할 수 있어요. S3 Access Grants를 사용하면 대규모로 다양한 객체 수준 권한을 지정할 수 있어요. 반면 버킷 정책은 크기가 20KB로 제한돼요. 자세한 내용은 S3 Access Grants 시작하기를 참고하세요.
  • 액세스 포인트 – 버킷에 연결된 명명된 네트워크 엔드포인트인 액세스 포인트를 사용할 수 있어요. 버킷에는 최대 10,000개의 액세스 포인트를 연결할 수 있으며, 각 액세스 포인트에 대해 별개의 권한과 네트워크 제어를 적용해 S3 객체에 대한 액세스를 세밀하게 제어할 수 있어요. 자세한 내용은 액세스 포인트로 공유 데이터셋 액세스 관리를 참고하세요.

사용 사례: 데이터에 대한 교차 계정 액세스. 다른 AWS 계정에 권한을 부여하려면 버킷 정책이나 다음 권장 액세스 관리 도구 중 하나를 사용해야 해요. 이 사용 사례에는 ID 기반 액세스 정책을 사용할 수 없어요. 교차 계정 액세스 부여에 대한 자세한 내용은 Amazon S3 버킷의 객체에 대한 교차 계정 액세스를 어떻게 제공하나요?를 참고하세요. 다음 액세스 관리 도구를 권장해요.

  • 버킷 정책 – 버킷 정책을 사용하면 버킷마다 정책 하나를 관리해요. 자세한 내용은 Amazon S3용 버킷 정책을 참고하세요.
  • S3 Access Grants – S3 Access Grants를 사용해 S3 버킷, 프리픽스 또는 객체에 대한 교차 계정 권한을 부여할 수 있어요. S3 Access Grants를 사용하면 대규모로 다양한 객체 수준 권한을 지정할 수 있어요. 반면 버킷 정책은 크기가 20KB로 제한돼요. 자세한 내용은 S3 Access Grants 시작하기를 참고하세요.
  • 액세스 포인트 – 버킷에 연결된 명명된 네트워크 엔드포인트인 액세스 포인트를 사용할 수 있어요. 버킷에는 최대 10,000개의 액세스 포인트를 연결할 수 있으며, 각 액세스 포인트에 대해 별개의 권한과 네트워크 제어를 적용해 S3 객체에 대한 액세스를 세밀하게 제어할 수 있어요. 자세한 내용은 액세스 포인트로 공유 데이터셋 액세스 관리를 참고하세요.

사용 사례: 객체별로 데이터에 대한 액세스. 버킷 정책에서 예를 들어 특정 키 이름 프리픽스(key name prefix) 를 공유하거나 특정 태그를 가진 버킷 내 객체에 대한 액세스를 부여할 수 있어요. logs/ 키 이름 프리픽스로 시작하는 객체에 대한 읽기 권한을 부여할 수 있어요. 하지만 액세스 권한이 객체별로 다르면 버킷 정책으로 개별 객체에 대한 권한을 부여하는 것은 실용적이지 않을 수 있으며, 특히 버킷 정책은 크기가 20KB로 제한됩니다. 다음 액세스 관리 도구를 권장해요.

  • S3 Access Grants – S3 Access Grants를 사용해 객체 수준 또는 프리픽스 수준 권한을 관리할 수 있어요. 버킷 정책과 달리 S3 Access Grants를 사용하면 대규모로 다양한 객체 수준 권한을 지정할 수 있어요. 버킷 정책은 크기가 20KB로 제한돼요. 자세한 내용은 S3 Access Grants 시작하기를 참고하세요.
  • 액세스 포인트 – 액세스 포인트를 사용해 객체 수준 또는 프리픽스 수준 권한을 관리할 수 있어요. 액세스 포인트는 버킷에 연결된 명명된 네트워크 엔드포인트예요. 버킷에는 최대 10,000개의 액세스 포인트를 연결할 수 있으며, 각 액세스 포인트에 대해 별개의 권한과 네트워크 제어를 적용해 S3 객체에 대한 액세스를 세밀하게 제어할 수 있어요. 자세한 내용은 액세스 포인트로 공유 데이터셋 액세스 관리를 참고하세요.
  • ACL – 액세스 제어 목록(ACL) 사용은 권장하지 않아요. 특히 ACL은 객체당 100개의 그랜트로 제한되기 때문이에요. 하지만 ACL을 켜기로 선택했다면 버킷 설정에서 객체 소유권(Object Ownership) 을 버킷 소유자 선호(Bucket owner preferred) 로 설정하고 ACL을 활성화(ACLs enabled) 하세요. 이 설정을 사용하면 bucket-owner-full-control 캐닝 ACL로 작성된 새 객체는 객체 작성자가 아니라 버킷 소유자가 자동으로 소유해요. 그런 다음 XML 형식의 액세스 정책인 객체 ACL을 사용해 다른 사용자에게 객체에 대한 액세스를 부여할 수 있어요. 자세한 내용은 액세스 제어 목록(ACL) 개요를 참고하세요.

사용 사례: 버킷의 프리픽스에 대한 액세스 부여. 다음 액세스 관리 도구를 권장해요.

  • 버킷 정책 – 버킷 정책을 사용하면 버킷마다 정책 하나를 관리해요. 자세한 내용은 Amazon S3용 버킷 정책을 참고하세요.
  • 액세스 포인트 – 액세스 포인트는 버킷에 연결된 명명된 네트워크 엔드포인트예요. 버킷에는 최대 10,000개의 액세스 포인트를 연결할 수 있으며, 각 액세스 포인트에 대해 별개의 권한과 네트워크 제어를 적용해 S3 객체에 대한 액세스를 세밀하게 제어할 수 있어요. 자세한 내용은 액세스 포인트로 공유 데이터셋 액세스 관리를 참고하세요.

사용 사례: 버킷의 로그 파일 수신. 이 사용 사례에는 다음 액세스 관리 도구를 권장해요.

  • 액세스 포인트 – 액세스 포인트는 버킷에 연결된 명명된 네트워크 엔드포인트예요. 버킷에는 최대 10,000개의 액세스 포인트를 연결할 수 있으며, 각 액세스 포인트에 대해 별개의 권한과 네트워크 제어를 적용해 S3 객체에 대한 액세스를 세밀하게 제어할 수 있어요. 각 액세스 포인트는 기본 버킷에 연결된 버킷 정책과 함께 작동하는 사용자 지정 액세스 포인트 정책을 적용해요. 자세한 내용은 액세스 포인트로 공유 데이터셋 액세스 관리를 참고하세요.

사용 사례: VPC 엔드포인트를 통한 버킷 액세스 제어. Amazon S3용 가상 프라이빗 클라우드(VPC) 엔드포인트는 VPC 내에서 S3에만 연결을 허용하는 논리적 엔터티예요. 이 사용 사례에는 다음 액세스 관리 도구를 권장해요.

  • VPC 설정의 버킷 – 버킷 정책을 사용해 버킷에 액세스할 수 있는 사람과 액세스할 수 있는 VPC 엔드포인트를 제어할 수 있어요. 자세한 내용은 버킷 정책으로 VPC 엔드포인트에서의 액세스 제어를 참고하세요.
  • 액세스 포인트 – 액세스 포인트를 설정하기로 선택했다면 액세스 포인트 정책을 사용할 수 있어요. 모든 액세스 포인트를 가상 프라이빗 클라우드(VPC)에서만 요청을 수락하도록 구성해 Amazon S3 데이터 액세스를 프라이빗 네트워크로 제한할 수 있어요. 각 액세스 포인트에 대한 사용자 지정 공개 액세스 차단 설정도 구성할 수 있어요. 자세한 내용은 액세스 포인트로 공유 데이터셋 액세스 관리를 참고하세요.

사용 사례: 정적 웹사이트 호스팅. S3를 사용하면 정적 웹사이트를 호스팅하고 S3 버킷에서 호스팅되는 웹사이트의 콘텐츠를 누구나 볼 수 있게 할 수 있어요. 이 사용 사례에는 다음 액세스 관리 도구를 권장해요.

  • Amazon CloudFront – 이 솔루션은 버킷 콘텐츠에 대한 모든 공개 액세스를 계속 차단하면서도 Amazon S3 정적 웹사이트를 공개적으로 호스팅할 수 있게 해줘요. 네 가지 S3 공개 액세스 차단 설정을 모두 활성화한 상태로 S3 정적 웹사이트를 호스팅하려면 Amazon CloudFront 오리진 액세스 제어(OAC)를 사용할 수 있어요. Amazon CloudFront는 보안 정적 웹사이트를 설정하는 데 필요한 기능을 제공해요. 또한 이 솔루션을 사용하지 않는 Amazon S3 정적 웹사이트는 HTTP 엔드포인트만 지원할 수 있어요. CloudFront는 Amazon S3의 내구성 있는 스토리지를 사용하면서 HTTPS 같은 추가 보안 헤더를 제공해요. HTTPS는 일반 HTTP 요청을 암호화하고 일반적인 사이버 공격으로부터 보호해 보안을 강화해요. 자세한 내용은 Amazon CloudFront 개발자 가이드의 보안 정적 웹사이트 시작하기를 참고하세요.
  • Amazon S3 버킷을 공개적으로 액세스 가능하게 만들기 – 버킷을 공개적으로 액세스되는 정적 웹사이트로 사용하도록 구성할 수 있어요.

    경고 이 방법은 권장하지 않아요. 대신 Amazon CloudFront의 일부로 Amazon S3 정적 웹사이트를 사용할 것을 권장해요. 자세한 내용은 이전 옵션을 참고하거나 보안 정적 웹사이트 시작하기를 참고하세요. Amazon CloudFront 없이 Amazon S3 정적 웹사이트를 만들려면 먼저 모든 공개 액세스 차단 설정을 꺼야 해요. 정적 웹사이트용 버킷 정책을 작성할 때 s3:GetObject 작업만 허용하고 ListObject 또는 PutObject 권한은 허용하지 않도록 하세요. 이렇게 하면 사용자가 버킷의 모든 객체를 보거나 자체 콘텐츠를 추가할 수 없게 하는 데 도움이 돼요. 자세한 내용은 웹사이트 액세스 권한 설정을 참고하세요.

사용 사례: 버킷에 대한 공개 액세스 허용. 새 Amazon S3 버킷을 만들 때 공개 액세스 차단(Block Public Access) 설정은 기본적으로 활성화돼요. 공개 액세스 차단에 대한 자세한 내용은 Amazon S3 스토리지에 대한 공개 액세스 차단을 참고하세요. 버킷에 대한 공개 액세스를 허용하는 것은 권장하지 않아요. 하지만 특정 사용 사례를 위해 반드시 그렇게 해야 한다면 이 사용 사례에는 다음 액세스 관리 도구를 권장해요.

  • 공개 액세스 차단 설정 비활성화 – 버킷 소유자는 버킷에 대한 인증되지 않은 요청을 허용할 수 있어요. 예를 들어 버킷에 공개 버킷 정책이 있거나 버킷 ACL이 공개 액세스를 부여하면 인증되지 않은 PUT Object 요청이 허용돼요. 모든 인증되지 않은 요청은 다른 임의의 AWS 사용자 또는 심지어 인증되지 않은 익명 사용자가 만든 것이에요. 이 사용자는 ACL에서 특정 캐노니컬 사용자 ID 65a011a29cdf8ec533ec3d1ccaae921c로 표시돼요. 객체가 WRITE 또는 FULL_CONTROL로 업로드되면 이는 특별히 All Users 그룹 또는 익명 사용자에게 액세스를 부여해요. 공개 버킷 정책 및 공개 액세스 제어 목록(ACL)에 대한 자세한 내용은 "공개"의 의미를 참고하세요.

사용 사례: 복잡한 액세스 권한 관리. 버킷 정책과 ID 기반 정책 모두 20KB 크기 제한이 있어요. 액세스 권한 요구 사항이 복잡하면 이 크기 제한을 초과할 수 있어요. 이 사용 사례에는 다음 액세스 관리 도구를 권장해요.

  • 액세스 포인트 – 사용 사례에 맞다면 액세스 포인트를 사용하세요. 액세스 포인트를 사용하면 각 버킷에 여러 명명된 네트워크 엔드포인트가 있으며, 각각 기본 버킷 정책과 함께 작동하는 자체 액세스 포인트 정책이 있어요. 하지만 액세스 포인트는 버킷이 아닌 객체에만 작동하며 교차 리전 복제를 지원하지 않아요. 자세한 내용은 액세스 포인트로 공유 데이터셋 액세스 관리를 참고하세요.
  • S3 Access Grants – 버킷, 프리픽스 또는 객체에 대한 액세스를 부여하는 매우 많은 수의 그랜트를 지원하는 S3 Access Grants를 사용하세요. 자세한 내용은 S3 Access Grants 시작하기를 참고하세요.

사용 사례: 회사 디렉터리의 사용자 및 역할에 대한 액세스 부여. AWS Identity and Access Management(IAM)를 통해 사용자, 그룹, 역할을 관리하는 대신 회사 디렉터리를 AWS IAM Identity Center에 추가할 수 있어요. 자세한 내용은 IAM Identity Center란 무엇인가요?를 참고하세요. 회사 디렉터리를 AWS IAM Identity Center에 추가한 후 회사 디렉터리 자격에 S3 리소스에 대한 액세스를 부여하려면 다음 액세스 관리 도구를 사용할 것을 권장해요.

  • S3 Access Grants – 회사 디렉터리의 사용자 또는 역할에 대한 액세스를 부여하는 것을 지원하는 S3 Access Grants를 사용하세요. 자세한 내용은 S3 Access Grants 시작하기를 참고하세요.

사용 사례: 다른 AWS 서비스에 대한 액세스. 이 사용 사례에는 다음 액세스 관리 도구를 권장해요.

  • 버킷 ACL – 버킷 ACL의 유일한 권장 사용 사례는 Amazon CloudFront awslogsdelivery 계정 같은 특정 AWS 서비스에 권한을 부여하는 것이에요. 배포를 만들거나 업데이트하고 CloudFront 로깅을 켜면 CloudFront는 버킷 ACL을 업데이트해 awslogsdelivery 계정에 버킷에 로그를 쓸 FULL_CONTROL 권한을 부여해요. 자세한 내용은 Amazon CloudFront 개발자 가이드의 표준 로깅 구성 및 로그 파일 액세스에 필요한 권한을 참고하세요. 로그를 저장하는 버킷이 S3 객체 소유권에 버킷 소유자 강제(Bucket owner enforced) 설정을 사용해 ACL을 끄면 CloudFront는 버킷에 로그를 쓸 수 없어요. 자세한 내용은 버킷의 객체 소유권 제어 및 ACL 비활성화를 참고하세요.

사용 사례: 업로드된 객체의 소유권 유지. 버킷 정책, 액세스 포인트 또는 S3 Access Grants를 사용해 다른 계정에 버킷에 객체를 업로드할 액세스를 부여할 수 있어요. 버킷에 교차 계정 액세스를 부여했다면 버킷에 업로드된 모든 객체가 완전한 제어 하에 유지되도록 할 수 있어요. 이 사용 사례에는 다음 액세스 관리 도구를 권장해요.

  • 객체 소유권 – 버킷 수준 설정인 객체 소유권(Object Ownership) 을 기본 버킷 소유자 강제(Bucket owner enforced) 설정으로 유지하세요.

액세스 관리 문제 해결 (Access management troubleshooting)

다음 리소스는 S3 액세스 관리 문제를 해결하는 데 도움이 될 수 있어요.

액세스 거부(403 금지) 오류 문제 해결

액세스 거부 문제가 발생하면 계정 수준 및 버킷 수준 설정을 확인하세요. 또한 액세스를 부여하는 데 사용하는 액세스 관리 기능을 확인해 정책, 설정 또는 구성이 올바른지 확인하세요. Amazon S3에서 액세스 거부(403 금지) 오류의 일반적인 원인에 대한 자세한 내용은 Amazon S3에서 액세스 거부(403 금지) 오류 문제 해결을 참고하세요.

S3용 IAM Access Analyzer

리소스 중 하나라도 공개하지 않으려고 하거나 리소스에 대한 공개 액세스를 제한하려면 S3용 IAM Access Analyzer를 사용할 수 있어요. Amazon S3 콘솔에서 S3용 IAM Access Analyzer를 사용해 공개 또는 공유 액세스를 부여하는 버킷 액세스 제어 목록(ACL), 버킷 정책 또는 액세스 포인트 정책이 있는 모든 버킷을 검토하세요. S3용 IAM Access Analyzer는 조직 외부의 AWS 계정을 포함해 인터넷의 모든 사람 또는 다른 AWS 계정이 액세스할 수 있도록 구성된 버킷에 대해 경고해요. 각 공개 또는 공유 버킷에 대해 공개 또는 공유 액세스의 소스와 수준을 보고하는 결과를 받아요.

S3용 IAM Access Analyzer에서 단일 작업으로 버킷에 대한 모든 공개 액세스를 차단할 수 있어요. 특정 사용 사례를 지원하기 위해 공개 액세스가 필요한 경우가 아니면 버킷에 대한 모든 공개 액세스를 차단할 것을 권장해요. 모든 공개 액세스를 차단하기 전에 애플리케이션이 공개 액세스 없이도 계속 올바르게 작동하는지 확인하세요. 자세한 내용은 Amazon S3 스토리지에 대한 공개 액세스 차단을 참고하세요.

또한 버킷 수준 권한 설정을 검토해 세밀한 액세스 수준을 구성할 수 있어요. 공개 또는 공유 액세스가 필요한 구체적이고 검증된 사용 사례의 경우 버킷에 대한 결과를 보관해 버킷이 공개 또는 공유 상태로 유지되도록 하려는 의도를 기록할 수 있어요. 이러한 버킷 구성을 언제든지 다시 방문하고 수정할 수 있어요. 또한 감사 목적으로 결과를 CSV 보고서로 다운로드할 수 있어요.

S3용 IAM Access Analyzer는 Amazon S3 콘솔에서 추가 비용 없이 사용할 수 있어요. S3용 IAM Access Analyzer는 AWS Identity and Access Management(IAM) IAM Access Analyzer로 구동돼요. Amazon S3 콘솔에서 S3용 IAM Access Analyzer를 사용하려면 IAM 콘솔을 방문해 각 개별 리전에 대해 IAM Access Analyzer에서 계정 수준 분석기를 만들어야 해요.

S3용 IAM Access Analyzer에 대한 자세한 내용은 S3용 IAM Access Analyzer로 버킷 액세스 검토를 참고하세요.

로깅 및 모니터링

모니터링은 Amazon S3 솔루션의 안정성, 가용성, 성능을 유지하는 중요한 부분으로, 액세스 실패를 더 쉽게 디버깅할 수 있게 해줘요. 로깅은 사용자가 받는 오류와 요청이 언제 무엇으로 이루어졌는지에 대한 통찰력을 제공할 수 있어요. AWS는 다음과 같은 Amazon S3 리소스 모니터링을 위한 여러 도구를 제공해요.

  • AWS CloudTrail
  • Amazon S3 액세스 로그
  • AWS Trusted Advisor
  • Amazon CloudWatch

자세한 내용은 Amazon S3 로깅 및 모니터링을 참고하세요.