Skip to content

액세스 제어

Amazon S3은 다양한 보안 기능 및 도구를 제공한다. 다음 시나리오에서는 특정 작업을 수행하거나 특정 환경에서 작동할 때 사용할 도구와 설정을 안내한다. 이러한 도구를 올바르게 적용하면 데이터의 무결성을 유지하고 의도한 사용자만 리소스에 액세스하도록 보장할 수 있다.

1. 새 버킷 생성

새 버킷을 생성할 때는 Amazon S3 리소스를 보호하도록 다음과 같은 도구와 설정을 적용해야 한다.

액세스 제어 단순화를 위한 S3 객체 소유권

S3 객체 소유권은 액세스 제어 목록(ACL)을 사용 중지하고 버킷에 있는 모든 객체의 소유권을 가져오는 데 사용할 수 있는 Amazon S3 버킷 수준 설정으로, Amazon S3에 저장된 데이터에 대한 액세스 관리를 간소화한다. 기본적으로 다른 AWS 계정이 S3 버킷에 객체를 업로드하면 해당 계정(객체 작성자)이 객체를 소유하고 객체에 액세스할 수 있으며 ACL을 통해 다른 사용자에게 객체에 대한 액세스 권한을 부여할 수 있다. 객체 소유권을 사용하여 ACL이 사용 중지되고 버킷 소유자로서 버킷의 모든 객체를 자동으로 소유하도록 이 기본 동작을 변경할 수 있다. 결과적으로 데이터에 대한 액세스 제어는 IAM 정책, S3 버킷 정책, Virtual Private Cloud(VPC) 엔드포인트 정책 및 AWS Organizations 서비스 제어 정책(SCP)과 같은 정책을 기반으로 한다.

객체 소유권에는 버킷에 업로드된 객체의 소유권을 제어하고 ACL을 사용 중지하거나 사용하는 다음과 같은 세 가지 설정이 있다.

ACL 사용 중지됨

  • 버킷 소유자 시행(Bucket owner enforced)(권장) - ACL이 사용 중지되고 버킷 소유자는 버킷의 모든 객체를 자동으로 소유하고 완전히 제어한다. ACL은 더 이상 S3 버킷의 데이터에 대한 권한에 영향을 주지 않는다. 버킷은 정책을 독점적으로 사용하여 액세스 제어를 정의한다.

ACL 사용됨

  • 버킷 소유자 기본(Bucket owner preferred) - 버킷 소유자가 bucket-owner-full-control 미리 제공 ACL을 사용하여 다른 계정이 버킷에 작성하는 새 객체를 소유하고 완전히 제어한다.

  • 객체 작성자(Object writer)(기본값) - 객체를 업로드하는 AWS 계정은 객체를 소유하고 완전히 제어하며 ACL을 통해 다른 사용자에게 이에 대한 액세스 권한을 부여할 수 있다.

퍼블릭 액세스 차단

S3 퍼블릭 액세스 차단은 S3 리소스가 예기치 않게 노출되는 것을 방지하는 데 도움이 되는 4가지 설정을 제공한다. 이러한 설정은 개별 액세스 포인트, 버킷 또는 전체 AWS 계정에 어떤 조합으로든 적용할 수 있다. 설정을 계정에 적용하면 해당 계정이 소유한 모든 버킷 및 액세스 포인트에 적용된다. Amazon S3 콘솔에서 생성하는 새 버킷에는 기본적으로 모든 퍼블릭 액세스 차단 설정이 적용된다.

S3 퍼블릭 액세스 차단 설정이 너무 제한적인 경우 모든 퍼블릭 액세스 차단 설정을 사용 중지하는 대신 AWS Identity and Access Management(IAM) 아이덴터티를 사용하여 특정 사용자에게 액세스 권한을 부여할 수 있다. IAM 아이덴터티와 함께 퍼블릭 액세스 차단을 사용하면 요청하는 사용자에게 특정 권한이 부여된 경우를 제외하고 퍼블릭 액세스 차단 설정에 의해 차단된 모든 작업이 거부될 수 있다.

IAM 아이덴터티를 사용하여 액세스 권한 부여

S3 액세스가 필요한 새 팀 구성원의 계정을 설정할 때는 IAM 사용자 및 역할을 사용하여 최소 권한을 부여하도록 한다. 또한 IAM Multi-Factor Authentication(MFA)을 구현하여 강력한 아이덴터티 기반을 지원할 수 있다. IAM 아이덴터티를 사용하면 사용자에게 고유한 권한을 부여하고 사용자가 액세스할 수 있는 리소스와 수행할 수 있는 작업을 지정할 수 있다. IAM 아이덴터티를 통해 사용자가 공유 리소스에 액세스하기 전에 로그인 크레덴셜을 입력하도록 요구하거나 단일 버킷 내의 다양한 객체에 권한 계층을 적용하는 등 더욱 강력한 기능을 구현할 수 있다.

버킷 정책

버킷 정책을 사용하면 버킷 액세스를 개인화하여 승인된 사용자만 리소스에 액세스하고 리소스 내에서 작업을 수행하도록 할 수 있다. 버킷 정책 외에도 버킷 수준의 퍼블릭 액세스 차단 설정을 사용하여 데이터에 대한 퍼블릭 액세스를 추가로 제한해야 한다.

정책을 생성할 때 Principal 요소에 와일드카드를 사용하면 모든 사용자가 Amazon S3 리소스에 액세스할 수 있게 되므로 와일드카드 문자는 사용하지 않도록 한다. 버킷에 액세스할 수 있는 사용자 또는 그룹을 명시적으로 지정하는 것이 더 좋다. 작업에 와일드카드를 포함하는 대신 해당되는 경우 사용자 또는 그룹에 특정 권한을 부여한다.

최소 권한의 원칙을 더 엄격히 지키기 위해 Effect 요소의 Deny 문은 최대한 광범위해야 하며 Allow 문은 최대한 제한적이어야 한다. 's3:*' 작업과 페어링된 Deny 효과 또한 정책 조건 문에 포함된 사용자에게 옵트인 모범 사례를 적용하는 좋은 방법이다.

VPC의 버킷 설정

회사 환경에서 사용자를 추가하는 경우 Virtual Private Cloud(VPC) 엔드포인트를 사용하여 가상 네트워크의 모든 사용자가 Amazon S3 리소스에 액세스하도록 허용할 수 있다. VPC 종단점을 통해 개발자는 사용자가 연결된 네트워크를 기반으로 사용자 그룹에 특정 액세스 및 권한을 부여할 수 있다. IAM 역할 또는 그룹에 각 사용자를 추가하는 대신 VPC 종단점을 사용하여 요청이 지정된 종단점에서 시작되지 않는 경우 버킷 액세스를 거부할 수 있다.

2. 데이터 저장 및 공유

Amazon S3 데이터를 저장하고 공유할 때는 다음과 같은 도구와 모범 사례를 사용한다.

데이터 무결성을 위한 버전 관리 및 객체 잠금

Amazon S3 콘솔을 사용하여 버킷과 객체를 관리하는 경우 S3 버전 관리 및 S3 객체 잠금을 구현해야 한다. 이러한 기능을 사용하면 중요한 데이터가 예기치 않게 변경되는 것을 방지하고 의도하지 않은 작업을 롤백할 수 있다. 이 기능은 전체 쓰기 및 실행 권한을 가진 여러 사용자가 Amazon S3 콘솔에 액세스하는 경우에 특히 유용하다.

비용 효율성을 위한 객체 수명 주기 관리

수명 주기 동안 객체가 비용 효율적으로 저장되도록 관리하기 위해 객체 버전 관리와 함께 수명 주기 정책을 사용할 수 있다. 수명 주기 정책은 객체의 수명 동안 S3가 수행할 작업을 정의한다. 예를 들어 객체를 다른 스토리지 클래스로 이동하거나, 객체를 아카이빙하거나, 지정된 기간 후에 객체를 삭제하는 수명 주기 정책을 생성할 수 있다. 공유 접두사 또는 태그를 사용하여 버킷의 모든 객체 또는 일부 객체에 대해 수명 주기 정책을 정의할 수 있다.

여러 사무실 위치에 대한 리전 간 복제

여러 사무실 위치에서 액세스하는 버킷을 생성하는 경우 S3 리전 간 복제를 구현하는 것을 고려해야 한다. 리전 간 복제를 사용하면 모든 사용자가 필요한 리소스에 액세스할 수 있고 운영 효율성을 높일 수 있다. 리전 간 복제는 서로 다른 AWS 리전의 S3 버킷 간에 객체를 복사하여 가용성을 높인다. 하지만 이 도구를 사용하면 스토리지 비용이 증가한다.

안전한 정적 웹 사이트 호스팅을 위한 권한

공개적으로 액세스되는 정적 웹 사이트로 사용할 버킷을 구성하는 경우 모든 퍼블릭 액세스 차단 설정을 사용 중지해야 한다. 정적 웹 사이트에 대한 버킷 정책을 작성할 때는 s3:GetObject 작업만 제공하고 ListObject 또는 PutObject 권한은 제공하지 않는 것이 중요하다. 이렇게 하면 사용자가 버킷의 모든 객체를 보거나 자체 콘텐츠를 추가할 수 없다.

Amazon CloudFront는 안전한 정적 웹 사이트를 설정하는 데 필요한 기능을 제공한다. Amazon S3 정적 웹 사이트는 HTTP 엔드포인트만 지원한다. CloudFront는 Amazon S3의 내구성 있는 스토리지를 사용하면서 HTTPS와 같은 추가 보안 헤더를 제공한다. HTTPS는 일반적인 HTTP 요청을 암호화하고 일반적인 사이버 공격으로부터 보호함으로써 보안을 강화한다.

3. 리소스 공유

특정 사용자 그룹과 리소스를 공유하는 데는 몇 가지 방법이 있다. 다음과 같은 도구를 사용하여 문서 또는 기타 리소스 세트를 단일 사용자 그룹, 부서 또는 사무실과 공유할 수 있다. 이러한 도구를 모두 동일한 목표를 달성하는 데 사용할 수 있지만 일부 도구가 다른 도구보다 기존 설정에 더 적합할 수 있다.

S3 객체 소유권

S3 객체 소유권은 ACL을 사용 중지하고 버킷에 있는 모든 객체의 소유권을 가져오는 데 사용할 수 있는 Amazon S3 버킷 수준 설정으로, Amazon S3에 저장된 데이터에 대한 액세스 관리를 간소화한다. 기본적으로 다른 AWS 계정이 S3 버킷에 객체를 업로드하면 해당 계정(객체 작성자)이 객체를 소유하고 객체에 액세스할 수 있으며 ACL을 통해 다른 사용자에게 객체에 대한 액세스 권한을 부여할 수 있다. 객체 소유권을 사용하여 ACL이 사용 중지되고 버킷 소유자로서 버킷의 모든 객체를 자동으로 소유하도록 이 기본 동작을 변경할 수 있다. 결과적으로 데이터에 대한 액세스 제어는 정책을 기반으로 한다.

사용자 정책

IAM 그룹 및 사용자 정책을 사용하여 제한된 사용자 그룹과 리소스를 공유할 수 있다. 새 IAM 사용자를 생성할 때는 그룹을 만들어 사용자를 그룹에 추가하라는 메시지가 표시된다. 하지만 언제든지 그룹을 만들어 사용자를 그룹에 추가할 수 있다. 리소스를 공유할 개인 사용자들이 이미 IAM 내에 설정되어 있는 경우 이들을 하나의 그룹에 추가하고 사용자 정책 내에서 해당 그룹과 버킷을 공유할 수 있다. 또한 IAM 사용자 정책을 사용하여 버킷 내의 개별 객체를 공유할 수도 있다.

액세스 제어 목록

일반적으로 액세스 제어에 S3 버킷 정책 또는 IAM 정책을 사용하는 것이 좋다. Amazon S3 ACL은 IAM보다 앞선 Amazon S3의 원래 액세스 제어 메커니즘이다. 이미 S3 ACL을 사용하고 있고 ACL로 충분하다고 생각되면 변경할 필요가 없다. 그런데 특정 액세스 제어 시나리오에서는 ACL을 사용해야 한다. 예를 들어 버킷 소유자가 객체에 권한을 부여하려고 하지만 버킷 소유자가 소유하지 않은 객체가 있는 경우, 먼저 해당 객체 소유자가 버킷 소유자에게 권한을 부여해야 한다. 이 작업은 객체 ACL을 사용하여 수행된다.

Amazon S3의 최신 사용 사례 대부분은 더 이상 ACL을 사용할 필요가 없으며, 각 객체에 대해 액세스를 개별적으로 제어해야 하는 비정상적인 상황을 제외하고는 ACL을 사용 중지하는 것이 좋다. 객체 소유권으로 ACL을 사용 중지하고 액세스 제어 정책을 사용할 수 있다. ACL을 사용 중지하면 다른 AWS 계정이 업로드한 객체로 버킷을 쉽게 유지 관리할 수 있다. 버킷 소유자는 버킷의 모든 객체를 소유하고 정책을 사용하여 객체에 대한 액세스를 관리할 수 있다.

Note

버킷이 S3 객체 소유권에 대해 버킷 소유자 시행 설정을 사용하는 경우 정책을 사용하여 버킷과 버킷의 객체에 대한 액세스 권한을 부여해야 한다. ACL 설정 또는 ACL 업데이트 요청이 실패하고 AccessControlListNotSupported 오류 코드를 반환한다. ACL 읽기 요청은 계속 지원된다.

접두사

버킷에서 특정 리소스를 공유하려고 할 때 접두사를 사용하여 폴더 수준 권한을 복제할 수 있다. Amazon S3 콘솔은 객체에 대한 공유 이름 접두사를 사용하여 객체를 그룹화하는 방법으로 폴더 개념을 지원한다. IAM 사용자 정책의 조건 내에서 접두사를 지정하여 해당 접두사와 연결된 리소스에 액세스하는 명시적 권한을 부여할 수 있다.

태그 지정

객체 태깅을 사용하여 스토리지를 분류하는 경우 특정 값으로 태깅된 객체를 지정된 사용자와 공유할 수 있다. 리소스 태깅을 사용하면 사용자가 액세스하려는 리소스와 연결된 태그를 기반으로 객체에 대한 액세스를 제어할 수 있다. 이렇게 하려면 IAM 사용자 정책 내에서 ResourceTag/key-name 조건을 사용하여 태깅된 리소스에 대한 액세스를 허용한다.

4. 데이터 보호

다음 도구를 사용하여 전송 중인 데이터와 저장된 데이터를 보호할 수 있다. 이 두 가지 데이터 보호는 데이터의 무결성과 액세스 가능성을 유지하는 데 매우 중요하다.

객체 암호화

Amazon S3은 전송 중인 데이터와 유휴 시 데이터를 보호하는 몇 가지 객체 암호화 옵션을 제공한다. 서버 측 암호화는 데이터 센터의 디스크에 저장하기 전에 객체를 암호화하고 객체를 다운로드할 때 암호를 해독한다. 요청을 인증하기만 하면 액세스 권한을 갖게 되며, 객체의 암호화 여부와 관계없이 액세스 방식에는 차이가 없다. 서버 측 암호화를 설정하는 데는 다음 세 가지 옵션이 있으며 이러한 옵션은 함께 사용할 수 없다.

  • Amazon S3 관리형 키를 사용한 서버 측 암호화(SSE-S3)

  • AWS Key Management Service(AWS KMS) 키(SSE-KMS)를 사용한 서버 측 암호화

  • 고객 제공 키를 사용한 서버 측 암호화(SSE-C)

클라이언트 측 암호화는 Amazon S3으로 보내기 전에 데이터를 암호화하는 것을 가리킨다.

서명 방법

Signature 버전 4는 HTTP로 전송된 AWS 요청에 인증 정보를 추가하는 프로세스이다. 보안을 위해 대부분의 AWS 요청은 액세스 키 ID와 보안 액세스 키로 구성된 액세스 키로 서명해야 한다. 이 두 키는 일반적으로 보안 크레덴셜이라고 한다.

로깅 및 모니터링

모니터링은 Amazon S3 솔루션의 안정성, 가용성 및 성능을 유지하는 데 중요하다. 이를 통해 다중 지점 장애가 발생할 경우 보다 쉽게 디버깅할 수 있다. 로깅을 통해 사용자가 수신하는 오류와 요청이 언제 어떤 것인지 파악할 수 있다. AWS에서는 Amazon S3 리소스를 모니터링하기 위한 몇 가지 도구를 제공한다.

  • Amazon CloudWatch

  • AWS CloudTrail

  • Amazon S3 액세스 로그

  • AWS Trusted Advisor

Amazon S3는 Amazon S3에서 사용자, 역할 또는 AWS 서비스가 수행한 작업에 대한 레코드를 제공하는 서비스인 AWS CloudTrail과 통합된다. 이 기능과 함께 Amazon GuardDuty를 사용하면 CloudTrail 관리 이벤트와 CloudTrail S3 데이터 이벤트를 분석하여 Amazon S3 리소스에 대한 위협을 모니터링할 수 있다. 이러한 데이터 원본은 다양한 종류의 활동을 모니터링한다. 예를 들어 S3 관련 CloudTrail 관리 이벤트에는 S3 프로젝트를 나열하거나 구성하는 작업이 포함된다. GuardDuty는 모든 S3 버킷의 S3 데이터 이벤트를 분석하고 악성 및 의심스러운 활동을 모니터링한다.

References