Amazon S3 버킷 정책 예시 - Amazon Simple Storage Service

Amazon S3 버킷 정책 예시

Amazon S3 버킷 정책을 사용하면 적절한 권한을 가진 사용자만 객체에 액세스할 수 있도록 하여 버킷의 객체 액세스를 보호할 수 있습니다. 인증받은 사용자라도 적절한 권한이 없다면 Amazon S3 리소스에 액세스하지 못하게 할 수도 있습니다.

이 섹션에서는 버킷 정책의 일반적인 사용 사례에 대한 예제를 제시합니다. 이러한 샘플 정책은 리소스 값으로 amzn-s3-demo-bucket를 사용합니다. 이러한 정책을 테스트하려면 user input placeholders를 (귀하의 버킷 이름 등) 자체 정보로 대체합니다.

객체 집합으로의 권한을 부여 또는 거부하려면 Amazon 리소스 이름(ARN) 및 기타 값에 와일드카드 문자(*)를 사용하면 됩니다. 예를 들어, 공통 접두사로 시작하거나 .html과 같은 특정 확장자로 끝나는 객체 그룹에 대한 액세스를 제어할 수 있습니다.

AWS Identity and Access Management(IAM) 정책 언어에 대한 자세한 내용은 Amazon S3의 정책 및 권한를 참조하십시오.

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

참고

Amazon S3 콘솔을 사용하여 권한을 테스트할 경우 콘솔이 요구하는 추가 권한 즉, s3:ListAllMyBuckets, s3:GetBucketLocations3:ListBucket을 부여해야 합니다. 콘솔을 사용하여 사용자에게 권한을 부여하고 해당 권한을 테스트하는 방법에 대한 예제는 사용자 정책을 사용하여 버킷에 대한 액세스 제어을 참조하십시오.

버킷 정책 생성을 위한 추가 리소스에는 다음이 포함됩니다.

일반 익명 사용자에게 읽기 전용 권한 부여

정책 설정을 사용하여 일반 익명 사용자에게 액세스 권한을 부여할 수 있으며, 이는 버킷을 정적 웹 사이트로 구성하는 경우에 유용합니다. 익명 퍼블릭 사용자에게 액세스 권한을 부여하려면 버킷에 대한 퍼블릭 액세스 차단 설정을 비활성화해야 합니다. 이 작업을 수행하는 방법과 필요한 정책에 대한 자세한 내용은 웹 사이트 액세스에 대한 권한 설정 섹션을 참조하세요. 동일한 목적으로 더 제한적인 정책을 설정하는 방법을 알아보려면 AWS 지식 센터의 Amazon S3 버킷의 일부 객체에 대해 공개 읽기 액세스 권한을 부여하려면 어떻게 해야 하나요?를 참조하세요.

기본적으로 Amazon S3은 계정 및 버킷에 대한 퍼블릭 액세스를 차단합니다. 버킷을 사용하여 정적 웹 사이트를 호스팅하려는 경우 이러한 단계를 사용하여 퍼블릭 액세스 차단 설정을 편집할 수 있습니다.

주의

이러한 단계를 완료하기 전에 Amazon S3 스토리지에 대한 퍼블릭 액세스 차단을 검토하여 퍼블릭 액세스 허용과 관련된 위험을 이해하고 이에 동의하는지 확인합니다. 퍼블릭 액세스 차단 설정을 해제하여 버킷을 퍼블릭으로 만들면 인터넷상의 모든 사용자가 버킷에 액세스할 수 있습니다. 버킷에 대한 모든 퍼블릭 액세스를 차단하는 것이 좋습니다.

  1. https://console.aws.amazon.com/s3/에서 Amazon S3 콘솔을 엽니다.

  2. 정적 웹 사이트로 구성한 버킷의 이름을 선택합니다.

  3. Permissions를 선택합니다.

  4. 퍼블릭 액세스 차단(버킷 설정)(Block public access (bucket settings))에서 편집(Edit)을 선택합니다.

  5. 모든 퍼블릭 액세스 차단(Block all public access)을 선택 취소하고 변경 사항 저장(Save changes)을 선택합니다.

    퍼블릭 액세스 차단 버킷 설정을 보여주는 Amazon S3 콘솔.

    Amazon S3은 버킷에 대한 퍼블릭 액세스 차단 설정을 끕니다. 정적 퍼블릭 웹 사이트를 생성하려면 버킷 정책을 추가하기 전에 계정에 대한 퍼블릭 액세스 차단 설정을 편집해야 할 수도 있습니다. 계정에 대한 퍼블릭 액세스 차단 설정이 현재 켜져 있는 경우 퍼블릭 액세스 차단(버킷 설정) 아래에 메모가 표시됩니다.

암호화 필요

다음 예와 같이 AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)를 요구할 수 있습니다.

버킷에 쓰는 모든 객체에 SSE-KMS 필요

다음 예제 정책에서는 버킷에 쓰는 모든 객체가 AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화(SSE-KMS)로 암호화되어야 합니다. 객체가 SSE-KMS로 암호화되지 않은 경우, 요청이 거부됩니다.

{ "Version": "2012-10-17", "Id": "PutObjPolicy", "Statement": [{ "Sid": "DenyObjectsThatAreNotSSEKMS", "Principal": "*", "Effect": "Deny", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*", "Condition": { "Null": { "s3:x-amz-server-side-encryption-aws-kms-key-id": "true" } } }] }

버킷에 쓰는 모든 객체에 특정 AWS KMS key를 사용하는 SSE-KMS 필요

다음 예제 정책에서는 객체가 특정 KMS 키 ID를 사용한 SSE-KMS로 암호화되지 않았다면 버킷에 써지지 않도록 거부합니다. 요청별 헤더 또는 버킷 기본 암호화를 사용하여 객체가 SSE-KMS로 암호화되었더라도 지정된 KMS 키로 암호화되지 않았다면 객체를 버킷에 쓸 수 없습니다. 이 예제에 사용된 KMS 키 ARN은 자체 KMS 키 ARN으로 대체하십시오.

{ "Version": "2012-10-17", "Id": "PutObjPolicy", "Statement": [{ "Sid": "DenyObjectsThatAreNotSSEKMSWithSpecificKey", "Principal": "*", "Effect": "Deny", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*", "Condition": { "ArnNotEqualsIfExists": { "s3:x-amz-server-side-encryption-aws-kms-key-id": "arn:aws:kms:us-east-2:111122223333:key/01234567-89ab-cdef-0123-456789abcdef" } } }] }

준비된 ACL을 사용한 버킷 관리

여러 계정에 객체를 업로드하거나 객체 ACL을 공개 액세스 가능으로 설정할 수 있는 권한 부여

다음 예시 정책에서는 여러 AWS 계정에 s3:PutObjects3:PutObjectAcl 권한을 부여합니다. 또한 정책 예시는 이러한 작업에 대한 요청에 public-read 표준 액세스 제어 목록(ACL)을 반드시 포함하도록 요구합니다. 자세한 내용은 Amazon S3의 정책 작업Amazon S3의 정책 조건 키 단원을 참조하세요.

주의

public-read 준비된 ACL을 사용하면 전 세계 누구나 버킷 내의 객체를 볼 수 있습니다. Amazon S3 버킷에 대한 익명 액세스 권한을 부여하거나 퍼블릭 액세스 차단 설정을 사용 중지할 때 주의하십시오. 익명 액세스 권한을 부여하면 전 세계 누구나 버킷에 액세스할 수 있습니다. 정적 웹 사이트 호스팅용과 같이 특별히 필요한 경우가 아니면 Amazon S3 버킷에 익명 액세스 권한을 부여하지 않는 것이 좋습니다. 정적 웹 사이트 호스팅에 대한 퍼블릭 액세스 차단 설정을 활성화하려면 자습서: Amazon S3에서 정적 웹 사이트 구성을 참조하십시오.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AddPublicReadCannedAcl", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111122223333:root", "arn:aws:iam::444455556666:root" ] }, "Action": [ "s3:PutObject", "s3:PutObjectAcl" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*", "Condition": { "StringEquals": { "s3:x-amz-acl": [ "public-read" ] } } } ] }

버킷 소유자가 완벽하게 제어할 수 있도록 보증하면서 객체에 업로드하는 크로스 계정 권한 부여

다음 예에서는 업로드된 객체를 완전히 제어하면서 다른 AWS 계정이 버킷에 객체를 업로드하도록 허용하는 방법을 보여줍니다. 이 정책은 특정 AWS 계정(111122223333)이 업로드 시 bucket-owner-full-control이라는 표준 ACL을 포함하고 있는 경우에만 객체를 업로드할 수 있는 권한을 부여합니다. 정책의 StringEquals 조건은 준비된 ACL 요구 사항을 표현하도록 s3:x-amz-acl 조건 키를 지정합니다. 자세한 내용은 Amazon S3의 정책 조건 키 단원을 참조하십시오.

{ "Version":"2012-10-17", "Statement":[ { "Sid":"PolicyForAllowUploadWithACL", "Effect":"Allow", "Principal":{"AWS":"111122223333"}, "Action":"s3:PutObject", "Resource":"arn:aws:s3:::amzn-s3-demo-bucket/*", "Condition": { "StringEquals": {"s3:x-amz-acl":"bucket-owner-full-control"} } } ] }

객체 태깅을 통한 객체 액세스 관리

사용자가 특정 태그 키 및 값이 있는 객체만 읽도록 허용

다음 권한 정책은 environment: production 태그 키 및 값이 있는 객체만 사용자가 읽을 수 있도록 제한합니다. 이 정책은 s3:ExistingObjectTag 조건 키를 사용하여 태그 키 및 값을 지정합니다.

{ "Version":"2012-10-17", "Statement":[ { "Principal":{ "AWS":"arn:aws:iam::111122223333:role/JohnDoe" }, "Effect":"Allow", "Action":[ "s3:GetObject", "s3:GetObjectVersion" ], "Resource":"arn:aws:s3:::amzn-s3-demo-bucket/*", "Condition":{ "StringEquals":{ "s3:ExistingObjectTag/environment":"production" } } } ] }

사용자가 추가할 수 있는 객체 태그 키 제한

다음 권한 정책은 s3:PutObjectTagging 작업을 수행할 수 있는 권한을 사용자에게 부여하여, 사용자가 기존 객체에 태그를 추가할 수 있게 합니다. 조건이 s3:RequestObjectTagKeys 조건 키를 사용하여 Owner, CreationDate 등의 허용 태그 키 세트를 지정합니다. 자세한 내용은 IAM 사용 설명서다수의 키 또는 값을 사용하는 조건 생성을 참조하십시오.

요청에 지정된 모든 태그 키가 인증된 태그 키임을 정책이 보장합니다. 지정된 값 중 최소 1개가 요청에 존재함을 조건 내의 ForAnyValue 한정자가 보장합니다.

{ "Version": "2012-10-17", "Statement": [ {"Principal":{"AWS":[ "arn:aws:iam::111122223333:role/JohnDoe" ] }, "Effect": "Allow", "Action": [ "s3:PutObjectTagging" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/*" ], "Condition": {"ForAnyValue:StringEquals": {"s3:RequestObjectTagKeys": [ "Owner", "CreationDate" ] } } } ] }

사용자가 객체 태그를 추가할 수 있게 하려면 특정 태그 키 및 값 필요

다음 권한 정책은 s3:PutObjectTagging 작업을 수행할 수 있는 권한을 사용자에게 부여하여, 사용자가 기존 객체에 태그를 추가할 수 있게 합니다. 이 조건은 값이 X로 설정된 (Project 등의) 특정 태그 키를 포함하도록 사용자에게 요구합니다.

{ "Version": "2012-10-17", "Statement": [ {"Principal":{"AWS":[ "arn:aws:iam::111122223333:user/JohnDoe" ] }, "Effect": "Allow", "Action": [ "s3:PutObjectTagging" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/*" ], "Condition": {"StringEquals": {"s3:RequestObjectTag/Project": "X" } } } ] }

사용자가 특정 객체 태그 키 및 값이 있는 객체만 추가하도록 허용

다음 예제 정책은 s3:PutObject 작업을 수행할 권한을 사용자에게 부여하여, 객체를 버킷에 추가할 수 있게 합니다. 하지만 Condition 문은 업로드된 객체에 허용된 태그 키와 값만 사용할 수 있도록 제한합니다. 이 예제에서는 값이 Finance로 설정된 특정 태그 키(Department)가 있는 객체만 사용자가 버킷에 추가할 수 있습니다.

{ "Version": "2012-10-17", "Statement": [{ "Principal":{ "AWS":[ "arn:aws:iam::111122223333:user/JohnDoe" ] }, "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/*" ], "Condition": { "StringEquals": { "s3:RequestObjectTag/Department": "Finance" } } }] }

전역 조건 키를 사용한 객체 액세스 관리

전역 조건 키aws 접두사가 있는 조건 키입니다. AWS 서비스는 전역 조건 키나, 서비스 접두사가 포함된 서비스별 키를 지원할 수 있습니다. JSON 정책의 Condition 요소를 사용하면 요청 컨텍스트의 키를 정책에서 지정한 키 값과 비교할 수 있습니다.

Amazon S3 서버 액세스 로그 전달로 액세스 제한

다음 예제 버킷 정책에서는 aws:SourceArn 전역 조건 키를 사용하여, 서비스 대 서비스 요청을 하는 리소스의 Amazon 리소스 이름(ARN)을 정책 내에 지정된 ARN과 비교합니다. aws:SourceArn 전역 조건 키는 서비스 간 트랜잭션 중에 Amazon S3 서비스가 혼동된 대리자로 사용되는 것을 방지하는 용도로 사용됩니다. Amazon S3 서비스만 Amazon S3 버킷에 객체를 추가할 수 있습니다.

이 예제 버킷 정책은 로깅 서비스 보안 주체(logging.s3.amazonaws.com)에만 s3:PutObject 권한을 부여합니다.

참고

Amazon S3 리소스 기반 정책(예: 버킷 정책)에서는 AWS 서비스 보안 주체와 함께 NotPrincipal 요소를 사용할 수 없습니다. 대신 다음 정책에 표시된 대로 aws:PrincipalServiceName 조건 키를 사용하는 것이 좋습니다.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowPutObjectS3ServerAccessLogsPolicy", "Principal": { "Service": "logging.s3.amazonaws.com" }, "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-logs/*", "Condition": { "StringEquals": { "aws:SourceAccount": "111111111111" }, "ArnLike": { "aws:SourceArn": "arn:aws:s3:::EXAMPLE-SOURCE-BUCKET" } } }, { "Sid": "RestrictToS3ServerAccessLogs", "Effect": "Deny", "Principal": "*", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-logs/*", "Condition": { "StringNotEqualsIfExists": { "aws:PrincipalServiceName": "logging.s3.amazonaws.com" } } } ] }

내가 속한 조직에만 액세스 허용

리소스에 액세스하는 모든 IAM 보안 주체가 귀하가 속한 조직 내 AWS 계정(AWS Organizations 관리 계정 포함)에 속하도록 요구하려면 aws:PrincipalOrgID 전역 조건 키를 사용하면 됩니다.

이 유형의 액세스를 부여하거나 제한하려면 aws:PrincipalOrgID 조건을 정의하고 버킷 정책에서 해당 값을 귀하의 조직 ID로 설정합니다. 조직 ID는 버킷에 대한 액세스를 제어하는 데 사용됩니다. aws:PrincipalOrgID 조건을 사용하면, 조직에 새로 추가된 모든 계정에도 버킷 정책에서 설정된 권한이 적용됩니다.

다음은 귀하의 조직 내 특정 IAM 보안 주체에게 버킷의 직접 액세스를 부여하는 데 사용할 수 있는 리소스 기반 버킷 정책의 예제입니다. 버킷 정책에 aws:PrincipalOrgID 글로벌 조건 키를 추가하면, 보안 주체 계정이 귀하의 조직에 속해야만 리소스에 액세스할 수 있습니다. 액세스 권한을 부여할 때 실수로 잘못된 계정을 지정하더라도 aws:PrincipalOrgID 글로벌 조건 키가 추가 보호 장치 역할을 합니다. 이 글로벌 키가 정책 내에 사용되면 지정된 조직 외부의 보안 주체는 누구든 Amazon S3 버킷에 액세스할 수 없습니다. 목록에 있는 조직에 속한 계정의 보안 주체만 리소스에 액세스할 수 있습니다.

{ "Version": "2012-10-17", "Statement": [{ "Sid": "AllowGetObject", "Principal": { "AWS": "*" }, "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*", "Condition": { "StringEquals": { "aws:PrincipalOrgID": ["o-aa111bb222"] } } }] }

HTTP 또는 HTTPS 요청 기반 액세스 관리

HTTPS 요청으로만 액세스 제한

잠재적인 공격자가 네트워크 트래픽을 조작하지 못하도록 하려면, HTTPS(TLS)를 사용하여 암호화된 연결만 허용하고 HTTP 요청은 버킷에 액세스하지 못하도록 제한하면 됩니다. 요청이 HTTP인지 HTTPS인지 확인하려면 S3 버킷 정책에서 aws:SecureTransport 글로벌 조건 키를 사용합니다. aws:SecureTransport 조건 키는 요청이 HTTP를 사용하여 전송되었는지 여부를 확인합니다.

요청이 true로 반환되면 HTTPS를 통해 전송된 요청입니다. 요청이 false로 반환되면 HTTP를 통해 전송된 요청입니다. 그러면 원하는 요청 체계에 기반하여 버킷에 액세스를 허용하거나 거부하면 됩니다.

다음 예제에서는 버킷 정책이 HTTP 요청을 명시적으로 거부합니다.

{ "Version": "2012-10-17", "Statement": [{ "Sid": "RestrictToTLSRequestsOnly", "Action": "s3:*", "Effect": "Deny", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket", "arn:aws:s3:::amzn-s3-demo-bucket/*" ], "Condition": { "Bool": { "aws:SecureTransport": "false" } }, "Principal": "*" }] }

특정 HTTP 리퍼러로 액세스 제한

도메인 이름이 www.example.com 또는 example.com인 웹 사이트에, 이름이 amzn-s3-demo-bucket인 버킷에 저장된 사진과 동영상 링크가 포함되어 있다고 가정합니다. 기본적으로 모든 Amazon S3 리소스는 비공개이므로 리소스를 만든 AWS 계정만 이 리소스에 액세스할 수 있습니다.

웹 사이트에서 이들 객체에 대한 읽기 권한을 허용하려면, GET 요청이 특정 웹 페이지에서 출발한 경우에 한해 s3:GetObject 권한을 허용하는 버킷 정책을 추가하면 됩니다. 다음 정책은 StringLike 조건과 aws:Referer 조건 키를 사용하여 요청을 제한합니다.

{ "Version":"2012-10-17", "Id":"HTTP referer policy example", "Statement":[ { "Sid":"Allow only GET requests originating from www.example.com and example.com.", "Effect":"Allow", "Principal":"*", "Action":["s3:GetObject","s3:GetObjectVersion"], "Resource":"arn:aws:s3:::amzn-s3-demo-bucket/*", "Condition":{ "StringLike":{"aws:Referer":["http://www.example.com/*","http://example.com/*"]} } } ] }

사용하는 브라우저에는 요청의 HTTP referer 헤더가 포함되어야 합니다.

주의

aws:Referer 조건 키를 사용할 때 주의하는 것이 좋습니다. 공개적으로 알려진 HTTP 참조자 헤더 값을 포함하는 것은 위험합니다. 권한이 없는 사용자가 수정된 브라우저나 사용자 지정 브라우저를 사용하여 원하는 aws:Referer 값을 제공할 수 있습니다. 따라서 승인되지 않은 당사자가 직접 AWS 요청을 하지 못하도록 aws:Referer를 사용하지 마십시오.

aws:Referer 조건 키는 고객이 Amazon S3에 저장된 콘텐츠 등의 디지털 콘텐츠를 권한이 없는 서드 파티 사이트에서 참조하지 못하도록 보호하기 위해서만 제공됩니다. 자세한 내용은 IAM 사용 설명서에서 aws:Referer 섹션을 참조하십시오.

특정 폴더에 대한 사용자 액세스 관리

사용자에게 특정 폴더 액세스 부여

사용자에게 특정 폴더에 대한 액세스 권한을 부여하려고 한다고 가정합니다. IAM 사용자와 S3 버킷이 동일한 AWS 계정에 속한 경우, IAM 정책을 사용하여 사용자에게 특정 버킷 폴더에 대한 액세스 권한을 부여할 수 있습니다. 이 접근법을 사용하면 액세스 권한을 부여하기 위해 버킷 정책을 업데이트하지 않아도 됩니다. 여러 사용자가 전환할 수 있는 IAM 역할에 IAM 정책을 추가할 수 있습니다.

IAM ID와 S3 버킷이 다른 AWS 계정에 속해 있다면 IAM 정책과 버킷 정책 모두에 크로스 계정 액세스를 부여해야 합니다. 크로스 계정 액세스 부여에 대한 자세한 내용은 버킷 소유자가 크로스 계정 버킷 권한 부여를 참조하십시오.

다음 예제 버킷 정책은 JohnDoe 콘솔 전체 액세스 권한을 자신의 폴더(home/JohnDoe/)에만 부여합니다. home 폴더를 만들고 사용자에게 적절한 권한을 부여하면, 여러 명의 사용자가 하나의 버킷을 공유하도록 할 수 있습니다. 이 정책은 다음 세 가지 Allow 문으로 구성됩니다.

  • AllowRootAndHomeListingOfCompanyBucket: 사용자(JohnDoe)가 amzn-s3-demo-bucket 버킷의 루트 수준 및 home 폴더에 있는 객체를 나열할 수 있도록 허용합니다. 이 문은 사용자가 콘솔을 사용하여 접두사 home/를 검색할 수 있게 하기도 합니다.

  • AllowListingOfUserFolder: 사용자(JohnDoe)가 home/JohnDoe/ 폴더와 그 모든 하위 폴더에 있는 모든 객체를 나열할 수 있도록 허용합니다.

  • AllowAllS3ActionsInUserFolder: Read, Write, Delete 권한을 부여하여 사용자가 모든 Amazon S3 작업을 수행할 수 있도록 허용합니다. 권한은 버킷 소유자의 홈 폴더로 제한됩니다.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowRootAndHomeListingOfCompanyBucket", "Principal": { "AWS": [ "arn:aws:iam::111122223333:user/JohnDoe" ] }, "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": ["arn:aws:s3:::amzn-s3-demo-bucket"], "Condition": { "StringEquals": { "s3:prefix": ["", "home/", "home/JohnDoe"], "s3:delimiter": ["/"] } } }, { "Sid": "AllowListingOfUserFolder", "Principal": { "AWS": [ "arn:aws:iam::111122223333:user/JohnDoe" ] }, "Action": ["s3:ListBucket"], "Effect": "Allow", "Resource": ["arn:aws:s3:::amzn-s3-demo-bucket"], "Condition": { "StringLike": { "s3:prefix": ["home/JohnDoe/*"] } } }, { "Sid": "AllowAllS3ActionsInUserFolder", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111122223333:user/JohnDoe" ] }, "Action": ["s3:*"], "Resource": ["arn:aws:s3:::amzn-s3-demo-bucket/home/JohnDoe/*"] } ] }

액세스 로그에 액세스 관리

액세스 로그를 활성화할 수 있도록 Application Load Balancer 액세스 권한 부여

Application Load Balancer에 액세스 로그를 활성화할 때는 로드 밸런서가 로그를 저장할 S3 버킷의 이름을 지정해야 합니다. 버킷에 액세스 로그를 쓸 수 있으려면 Elastic Load Balancing 권한을 부여하는 연결된 정책이 버킷에 있어야 합니다.

다음 예제에서는 버킷 정책이 Elastic Load Balancing(ELB) 권한을 부여하여 액세스 로그를 버킷에 쓸 수 있도록 합니다.

{ "Version": "2012-10-17", "Statement": [ { "Principal": { "AWS": "arn:aws:iam::elb-account-id:root" }, "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/prefix/AWSLogs/111122223333/*" } ] }
참고

elb-account-id는 귀하의 AWS 리전에 해당하는 Elastic Load Balancing용 AWS 계정 ID로 대체합니다. Elastic Load Balancing 리전 목록은 Elastic Load Balancing 사용 설명서Attach a policy to your Amazon S3 bucket(정책을 Amazon S3 버킷에 연결)을 참조하십시오.

귀하의 AWS 리전이 지원되는 Elastic Load Balancing 리전 목록에 보이지 않으면, 지정된 로그 전달 서비스에 권한을 부여하는 다음 정책을 사용합니다.

{ "Version": "2012-10-17", "Statement": [ { "Principal": { "Service": "logdelivery.elasticloadbalancing.amazonaws.com" }, "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/prefix/AWSLogs/111122223333/*" } ] }

그런 다음, Elastic Load Balancing 액세스 로그를 활성화하여 구성합니다. 테스트 파일을 생성하면 버킷 권한을 확인할 수 있습니다.

Amazon CloudFront OAI에 대한 액세스 관리

Amazon CloudFront OAI에 대한 권한 부여

다음 예제 버킷 정책은 CloudFront 오리진 액세스 ID(OAI) 권한을 부여하여 S3 버킷에서 모든 객체를 가져옵니다(읽습니다). CloudFront OAI를 사용하면 사용자가 Amazon S3이 아니라 CloudFront를 통해 버킷의 객체에 액세스하도록 허용할 수 있습니다. 자세한 내용은 Amazon CloudFront 개발자 안내서Amazon S3 오리진에 대한 액세스 제한을 참조하십시오.

다음 정책은 OAI의 ID를 정책의 Principal로 사용합니다. S3 버킷 정책을 사용하여 CloudFront OAI에 대한 액세스 권한을 부여하는 방법에 대한 자세한 내용은 Amazon CloudFront 개발자 안내서오리진 액세스 ID(OAI)에서 오리진 액세스 제어(OAC)로 마이그레이션을 참조하십시오.

이 예제 사용

  • EH1HDMB1FH2TC를 OAI의 ID로 대체합니다. OAI의 ID를 찾으려면 CloudFront 콘솔에서 Origin Access Identity page(오리진 액세스 ID 페이지)를 확인하거나 CloudFront API에서 ListCloudFrontOriginAccessIdentities를 사용합니다.

  • amzn-s3-demo-bucket을 사용 중인 버킷의 이름으로 바꿉니다.

{ "Version": "2012-10-17", "Id": "PolicyForCloudFrontPrivateContent", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity EH1HDMB1FH2TC" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*" } ] }

Amazon S3 스토리지 렌즈 액세스 관리

Amazon S3 스토리지 렌즈 권한 부여

S3 스토리지 렌즈는 지표를 집계하고 Amazon S3 콘솔 버킷 페이지의 계정 스냅샷 섹션에 이 정보를 표시합니다. S3 스토리지 렌즈는 또한 인사이트와 추세를 시각화하고, 이상치에 플래그를 지정하고, 스토리지 비용 최적화와 데이터 보호 모범 사례 적용을 위한 권장 사항을 수신하는 데 사용할 수 있는 대화형 대시보드를 제공합니다. 대시보드에 있는 드릴다운 옵션을 통해 조직, 계정, AWS 리전, 스토리지 클래스, 버킷, 접두사 또는 스토리지 렌즈 그룹 수준에서 인사이트를 생성하거나 시각화할 수 있습니다. 또한 CSV 또는 Parquet 형식의 일일 지표 내보내기를 S3 버킷으로 전송할 수 있습니다.

S3 스토리지 렌즈에서 집계된 스토리지 사용량 지표를 Amazon S3 버킷으로 내보내면 추가로 분석할 수 있습니다. S3 스토리지 렌즈가 지표 내보내기를 배치하는 버킷을 대상 버킷이라고 합니다. S3 스토리지 렌즈 지표 내보내기를 설정할 때 대상 버킷에 대한 버킷 정책이 있어야 합니다. 자세한 내용은 Amazon S3 스토리지 렌즈를 사용하여 스토리지 활동 및 사용량 평가 단원을 참조하십시오.

다음 예시 버킷 정책은 대상 버킷에 객체(PUT 요청)를 쓸 수 있는 권한을 Amazon S3에 부여합니다. S3 스토리지 렌즈 지표 내보내기를 설정할 때는 대상 버킷에 이와 같은 버킷 정책을 사용합니다.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "S3StorageLensExamplePolicy", "Effect": "Allow", "Principal": { "Service": "storage-lens.s3.amazonaws.com" }, "Action": "s3:PutObject", "Resource": [ "arn:aws:s3:::amzn-s3-demo-destination-bucket/destination-prefix/StorageLens/111122223333/*" ], "Condition": { "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control", "aws:SourceAccount": "111122223333", "aws:SourceArn": "arn:aws:s3:region-code:111122223333:storage-lens/storage-lens-dashboard-configuration-id" } } } ] }

S3 스토리지 렌즈 조직 수준 지표 내보내기를 설정할 때, 이전 버킷 정책의 Resource 문을 다음과 같이 수정합니다.

"Resource": "arn:aws:s3:::amzn-s3-demo-destination-bucket/destination-prefix/StorageLens/your-organization-id/*",

S3 인벤토리, S3 분석 및 S3 인벤토리 보고서 권한 관리

S3 인벤토리 및 S3 분석 권한 부여

S3 인벤토리는 버킷 내에 객체 목록을 생성하고, S3 분석 스토리지 클래스 분석 내보내기는 분석에서 사용되는 데이터의 출력 파일을 생성합니다. 인벤토리가 객체를 열거하는 버킷을 원본 버킷이라고 합니다. 인벤토리 파일 또는 분석 내보내기 파일이 작성되는 버킷을 대상 버킷이라고 합니다. 인벤토리 또는 분석 내보내기를 설정할 때는 대상 버킷의 버킷 정책을 생성해야 합니다. 자세한 내용은 S3 Inventory를 사용한 데이터 카탈로그화 및 분석Amazon S3 분석 - 스토리지 클래스 분석 섹션을 참조하세요.

다음 버킷 정책 예는 원본 버킷의 계정에서 대상 버킷에 객체를 쓸 수 있는 Amazon S3 권한(PUT 요청)을 부여합니다. S3 인벤토리와 S3 분석 내보내기를 설정할 때는 대상 버킷에서 이와 같은 버킷 정책을 사용합니다.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "InventoryAndAnalyticsExamplePolicy", "Effect": "Allow", "Principal": { "Service": "s3.amazonaws.com" }, "Action": "s3:PutObject", "Resource": [ "arn:aws:s3:::DOC-EXAMPLE-DESTINATION-BUCKET/*" ], "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:s3:::DOC-EXAMPLE-SOURCE-BUCKET" }, "StringEquals": { "aws:SourceAccount": "111122223333", "s3:x-amz-acl": "bucket-owner-full-control" } } } ] }

S3 인벤토리 보고서 구성 생성 제어

S3 Inventory를 사용한 데이터 카탈로그화 및 분석는 S3 버킷 내 객체들의 목록과 각 객체의 메타데이터를 생성합니다. s3:PutInventoryConfiguration 권한을 통해 사용자는 기본적으로 사용 가능한 모든 객체 메타데이터 필드를 포함하는 인벤토리 구성을 생성하고 인벤토리를 저장할 대상 버킷을 지정할 수 있습니다. 대상 버킷의 객체에 대한 읽기 권한이 있는 사용자는 인벤토리 보고서에서 사용할 수 있는 모든 객체 메타데이터 필드에 액세스할 수 있습니다. S3 인벤토리에서 사용 가능한 메타데이터 필드에 대한 자세한 내용은 Amazon S3 인벤토리 목록 섹션을 참조하십시오.

사용자가 S3 인벤토리 보고서를 구성하지 못하도록 제한하려면 해당 사용자의 s3:PutInventoryConfiguration 권한을 제거하세요.

S3 인벤토리 보고서 구성의 일부 객체 메타데이터 필드는 선택 사항입니다. 즉, 기본적으로 사용할 수 있지만 사용자에게 s3:PutInventoryConfiguration 권한을 부여하면 제한될 수 있습니다. s3:InventoryAccessibleOptionalFields 조건 키를 사용하여 사용자가 보고서에 이러한 선택적 메타데이터 필드를 포함할 수 있는지를 제어할 수 있습니다. S3 인벤토리에서 사용할 수 있는 선택적 메타데이터 필드 목록은 Amazon Simple Storage Service API 참조의 OptionalFields 섹션을 참조하세요.

특정 선택적 메타데이터 필드가 포함된 인벤토리 구성을 생성할 권한을 사용자에게 부여하려면 s3:InventoryAccessibleOptionalFields 조건 키를 사용하여 버킷 정책의 조건을 구체화하세요.

다음 예시 정책은 사용자(Ana)에게 조건부로 인벤토리 구성을 생성할 수 있는 권한을 부여합니다. 정책의 ForAllValues:StringEquals 조건은 s3:InventoryAccessibleOptionalFields 조건 키를 사용하여 허용되는 두 개의 선택적 메타데이터 필드(Size, StorageClass)를 지정합니다. 따라서 Ana가 인벤토리 구성을 생성할 때 포함할 수 있는 유일한 선택적 메타데이터 필드는 SizeStorageClass입니다.

{ "Id": "InventoryConfigPolicy", "Version": "2012-10-17", "Statement": [{ "Sid": "AllowInventoryCreationConditionally", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:user/Ana" }, "Action": "s3:PutInventoryConfiguration", "Resource": "arn:aws:s3:::DOC-EXAMPLE-SOURCE-BUCKET", "Condition": { "ForAllValues:StringEquals": { "s3:InventoryAccessibleOptionalFields": [ "Size", "StorageClass" ] } } } ] }

사용자가 특정 선택적 메타데이터 필드를 포함하는 S3 인벤토리 보고서를 구성하지 못하도록 제한하려면 소스 버킷의 버킷 정책에 명시적 Deny 문을 추가하세요. 다음 예시 버킷 정책은 사용자 Ana가 소스 버킷 DOC-EXAMPLE-SOURCE-BUCKET에서 선택적 ObjectAccessControlList 또는 ObjectOwner 메타데이터 필드를 포함하는 인벤토리 구성을 생성하는 것을 거부합니다. 사용자 Ana는 여전히 다른 선택적 메타데이터 필드를 사용하여 인벤토리 구성을 생성할 수 있습니다.

{ "Id": "InventoryConfigSomeFields", "Version": "2012-10-17", "Statement": [{ "Sid": "AllowInventoryCreation", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:user/Ana" }, "Action": "s3:PutInventoryConfiguration", "Resource": "arn:aws:s3:::DOC-EXAMPLE-SOURCE-BUCKET", }, { "Sid": "DenyCertainInventoryFieldCreation", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::111122223333:user/Ana" }, "Action": "s3:PutInventoryConfiguration", "Resource": "arn:aws:s3:::DOC-EXAMPLE-SOURCE-BUCKET", "Condition": { "ForAnyValue:StringEquals": { "s3:InventoryAccessibleOptionalFields": [ "ObjectOwner", "ObjectAccessControlList" ] } } } ] }
참고

버킷 정책에서 s3:InventoryAccessibleOptionalFields 조건 키를 사용해도 기존 인벤토리 구성을 기반으로 하는 인벤토리 보고서 전송에는 영향을 미치지 않습니다.

중요

이전 예시에서 볼 수 있듯이 Allow 효과를 적용하여 ForAllValues를 사용하거나 Deny 효과를 적용하여 ForAnyValue를 사용하는 것이 좋습니다.

Deny 효과와 함께 ForAllValues를 사용하거나 Allow 효과와 함께 ForAnyValue를 사용하지 마세요. 이러한 조합은 지나치게 제한적일 수 있고 인벤토리 구성 삭제를 차단할 수 있기 때문입니다.

ForAllValuesForAnyValue 조건 집합 연산자에 대해 자세히 알아보려면 IAM 사용 설명서의 다중 값 컨텍스트 키를 참조하세요.

MFA 필요

Amazon S3은 Amazon S3 리소스에 액세스하기 위해 멀티 팩터 인증(MFA)을 적용할 수 있는 기능인 MFA 보호 API 액세스를 지원합니다. 멀티 팩터 인증은 AWS 환경에 적용할 수 있는 추가 보안 레벨을 제공합니다. MFA는 사용자가 유효한 MFA 코드를 제공하여 MFA 디바이스를 물리적으로 가지고 있음을 증명하게 하는 보안 기능입니다. 자세한 내용은 AWS 멀티 팩터 인증을 참조하십시오. Amazon S3 리소스에 액세스하는 모든 요청에 대해 MFA가 필요할 수 있습니다.

MFA가 필요하도록 강제하려면 버킷 정책 내에 aws:MultiFactorAuthAge 조건 키를 사용합니다. IAM 사용자는 AWS Security Token Service(AWS STS)에서 발급한 임시 보안 인증을 사용하여 Amazon S3 리소스에 액세스할 수 있습니다. AWS STS 요청 시 MFA 코드를 제공합니다.

멀티 팩터 인증을 사용한 요청을 Amazon S3가 수신하면 얼마나 오래 전(초 단위)에 임시 보안 인증이 생성되었는지를 aws:MultiFactorAuthAge 조건 키가 숫자 값으로 제공합니다. 요청 시 제공된 임시 자격 증명이 MFA 디바이스를 사용하여 만들어진 경우 이 키 값은 null(없음)입니다. 버킷 정책에서는 다음 예시에서 나온 것처럼 이 값을 확인할 수 있는 조건을 추가할 수 있습니다.

이 예에서 MFA를 사용하여 요청이 인증되지 않으면 정책은 /taxdocuments 버킷의 amzn-s3-demo-bucket 폴더에서 모든 Amazon S3 작업을 거부합니다. MFA에 대한 자세한 내용은 IAM 사용 설명서AWS에서 멀티 팩터 인증(MFA) 사용을 참조하십시오.

{ "Version": "2012-10-17", "Id": "123", "Statement": [ { "Sid": "", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/taxdocuments/*", "Condition": { "Null": { "aws:MultiFactorAuthAge": true }} } ] }

Condition 블록의 Null 조건이 true로 평가되려면 aws:MultiFactorAuthAge 조건 키 값이 null이 되어 요청 시 임시 보안 인증이 MFA 디바이스 없이 만들어졌음을 나타내야 합니다.

다음 버킷 정책은 이전 버킷 정책을 확장한 것입니다. 다음 정책에는 두 가지 정책 문이 포함됩니다. 하나의 문은 모든 사용자에게 버킷(amzn-s3-demo-bucket)에 대한 s3:GetObject 권한을 허용합니다. 다른 문은 버킷의 amzn-s3-demo-bucket/taxdocuments 폴더에 액세스할 때 MFA를 요구함으로써 액세스를 제한합니다.

{ "Version": "2012-10-17", "Id": "123", "Statement": [ { "Sid": "", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/taxdocuments/*", "Condition": { "Null": { "aws:MultiFactorAuthAge": true } } }, { "Sid": "", "Effect": "Allow", "Principal": "*", "Action": ["s3:GetObject"], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*" } ] }

aws:MultiFactorAuthAge 키가 유효한 기간을 제한하는 숫자 조건을 사용해도 됩니다. aws:MultiFactorAuthAge 키로 지정된 기간은 요청을 인증하는 데 사용되는 임시 보안 인증의 수명 주기와 무관합니다.

예를 들어, 다음 버킷 정책은 MFA 인증 요구 이외에도 임시 세션이 얼마 전에 생성되었는지도 확인합니다. aws:MultiFactorAuthAge 키 값이 임시 세션이 1시간(3,600초) 전에 생성되었음을 나타낼 경우 해당 정책은 모든 작업을 거부합니다.

{ "Version": "2012-10-17", "Id": "123", "Statement": [ { "Sid": "", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/taxdocuments/*", "Condition": {"Null": {"aws:MultiFactorAuthAge": true }} }, { "Sid": "", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/taxdocuments/*", "Condition": {"NumericGreaterThan": {"aws:MultiFactorAuthAge": 3600 }} }, { "Sid": "", "Effect": "Allow", "Principal": "*", "Action": ["s3:GetObject"], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*" } ] }

기본적으로 사용자에게는 아무 권한이 없습니다. 그러나 정책을 생성할 때 사용자에게 부여하고 싶지 않은 권한을 부여할 수 있습니다. 그러한 권한 허점을 피하기 위해 명시적 거부를 추가하여 더 엄격한 액세스 정책을 작성할 수 있습니다.

객체를 삭제하지 못하도록 명시적으로 사용자 또는 계정을 차단하려면 버킷 정책에 s3:DeleteObject, s3:DeleteObjectVersions3:PutLifecycleConfiguration 권한 작업을 추가해야 합니다. Amazon S3에서 객체의 수명이 만료되었을 때 이를 제거할 수 있도록 명시적으로 DELETE Object API 작업을 직접적으로 호출하거나 해당 수명 주기(객체 수명 주기 관리 참조)를 구성하여 객체를 삭제할 수 있으므로 세 개의 작업 모두 필요합니다.

다음 정책 예시에서는 사용자 MaryMajorDELETE Object 권한을 명시적으로 거부합니다. 명시적 Deny 문은 이미 부여된 다른 모든 권한에 항상 우선합니다.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/MaryMajor" }, "Action": [ "s3:GetObjectVersion", "s3:GetBucketAcl" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket1", "arn:aws:s3:::amzn-s3-demo-bucket1/*" ] }, { "Sid": "statement2", "Effect": "Deny", "Principal": { "AWS": "arn:aws:iam::123456789012:user/MaryMajor" }, "Action": [ "s3:DeleteObject", "s3:DeleteObjectVersion", "s3:PutLifecycleConfiguration" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket1", "arn:aws:s3:::amzn-s3-demo-bucket1/*" ] } ] }