[SAA] S3 Introduction

Amazon S3 Introduction

이번 장에서는 SAA를 준비하며 S3란 무엇인지 기본적인 개념을 알아보도록 한다.

S3 스토리지 및 데이터 관리

• Amazon S3(이하 S3)는 AWS의 주요 빌딩 블록 중 하나다.
• “무한 확장” 스토리지로 광고되고 있으며 널리 사용되고 있다.
• 많은 웹 사이트에서 S3를 백본으로 사용하고 있으며, 많은 AWS 서비스에서 Amazon S3를 통합으로 사용하고 있다.

---

S3 개요

Buckets(버킷)

• S3를 사용하면 “버킷”이라고 하는 디렉토리에 객체(Objects, 파일)을 저장할 수 있다.
• “버킷”에는 전역적으로 고유한 이름이 있어야 한다.
• “버킷”은 리전 수준에서 정의된다. 이것은 "S3"를 사용할 리전을 지정하지 않고 모든 리전에서 공통되도록 사용되는 것을 의미한다.
• “버킷”의 명명 규칙은 아래와 같다.
  • 대문자를 사용할 수 없다.
  • 밑줄(_, 언더스코어)을 사용할 수 없다.
  • 3 ~ 63의 길이
  • IP주소의 형식이 아니다.
  • 소문자 또는 숫자로 시작해야 한다.

Objects(객체)

• “객체”(파일)에는 키가 있다.
• 키는 전체 경로이며 아래와 같은 예시가 있다.
  • s3://my-bucket/my_file.txt
  • s3://my-bucket/my_folderI/another_folder/my_file.txt
• 키는 “접두사 + 객체 이름”으로 구성된다.
  • s3://my-bucket/my_folderI/another_folder/my_file.txt라는 키가 있다고 가정한다.
  • s3://my-bucket/은 버킷의 경로를 의미한다.
  • my_folderI/another_folder/는 접두사를 의미한다.
  • my_file.txt는 객체의 이름을 의미한다.
• “객체”의 값은 컨텐츠의 내용이다.
  • 객체의 최대 크기는 5TB이다.
  • 5GB 이상을 업로드하는 경우 “multi-part upload”(다중 분할 업로드)를 사용해야 한다.
• 메타데이터(텍스트 키/값 쌍 목록 - 시스템 또는 사용자 메타데이터)
• 태그(유니코드 키/값 쌍 - 최대 10개) - 보안/수명 주기에 유용
• 버전 ID(버전 관리가 활성화된 경우)

Versioning(버전 관리)

• S3에서 파일의 버전을 관리할 수 있으며 “버킷 수준”에서 활성화된다.
• 동일한 키에 객체를 덮어쓰면 “버전이 증가"된다.
• 버킷의 버전을 관리하는 것이 좋은 방법이다.
  • 의도하지 않은 삭제로부터 보호할 수 있으며 버전 복원 기능을 제공한다.
  • 이전 버전으로 쉽게 롤백할 수 있다.
• 버전 관리를 활성화하기 전에 버전이 지정되지 않은 모든 파일의 버전은 null이다.
• 버전 관리를 일시 중단해도 이전 버전이 삭제되지 않는다.

Encryption for Object(객체 암호화)

• S3에서 객체를 “암호화”하는 4가지 방법이 존재한다.
  • SSE-S3:
    • AWS에서 처리 및 관리하는 키를 사용하여 S3 객체를 암호화한다.
    • 객체는 서버 측에서 암호화된다.
    • AES-256 암호화 유형이다.
    • 헤더는 "x-amz-server-side-encryption":"AES256"으로 설정되어야 한다.
  • SSE-KMS:
    • “AWS Key Management Service”를 활용하여 암호화 키를 관리한다.
    • 사용자 제어 + 감사 추적
    • 객체가 서버 측에서 암호화된다.
    • 헤더는 "x-amz-server-side-encryption":"aws:kms"로 설정되어야 한다.
  • SSE-C:
    • AWS 외부에서 고객이 완전히 관리하는 데이터 키를 사용한 서버 측 암호화 방식이다.
    • AWS는 고객이 제공한 암호화 키를 저장하지 않는다.
    • HTTPS를 사용해야 한다.
    • 모든 HTTP 요청에 대해 HTTP 헤더에 암호화 키를 제공해야 한다.
  • 클라이언트 측 암호화
    • S3 암호화 클라이언트와 같은 클라이언트 라이브러리다.
    • 클라이언트는 S3로 보내기 전에 데이터를 자체적으로 암호화해야 한다.
    • S3에서 검색할 때 클라이언트는 데이터를 스스로 복호화해야 한다.
    • 클라이언트는 키와 암호화 주기를 완전히 관리한다.
  • 전송 중 암호화(SSL/TLS)
    • S3는 HTTP를 통해 암호화되지 않은 엔드포인트를 노출하고 HTTPS를 통해 전송 중 암호화 된 엔드포인트를 노출한다.
    • 원하는 엔드포인트를 자유롭게 사용할 수 있지만 HTTPS의 사용이 권장되며, 대부분의 클라이언트는 기본적으로 HTTPS 엔드포인트를 사용한다.
    • HTTPS는 “SSE-C”에서도 필수이다.
    • 전송 중 암호화는 SSL/TLS라고도 한다.
• 이러한 암호화 방식은 자신이 운영하는 서비스의 특성에 맞게 선택되어야 한다.

Security

• 사용자 기반:
  • IAM 정책 - IAM 콘솔에서 특정 사용자에 대해 허용되어야 하는 API 호출
• 리소스 기반:
  • 버킷 정책 - S3 콘솔의 버킷 전체 규칙이며 교차 계정을 허용한다.
  • 객체 액세스 제어 목록(ACL) - 더 세분화되어 있다.
  • 버킷 액세스 제어 목록(ACL) - 일반적으로 사용되지 않는다.
• IAM 보안의 주체는 아래의 경우 S3 객체가 액세스할 수 있다.
  • 사용자 IAM 권한이 이를 허용하거나 리소스 정책이 이를 허용한다.
  • 명시적 DENY가 없는 경우(블랙리스트 정책)

---

Bucket Policies(버킷 정책)

• JSON 기반 정책
  • Resource: 버킷(buckets) 및 객체(objects)
  • Action: 허용(allow) 또는 거부(deny)할 API 집합
  • Effect: 허용(allow) / 거부(deny)
  • Principle: 정책을 적용할 계정 또는 사용자
• 정책에 S3 버킷을 사용하여 아래와 같은 작업을 수행한다.
  • 버킷에 대한 공개 액세스 권한 부여
  • 업로드 시 객체를 강제로 암호화
  • 다른 계정에 대한 액세스 권한 부여(교차 계정)

공개 액세스 차단을 위한 버킷 설정

• 아래의 기능을 통해 부여된 버킷 및 객체에 대한 공개 액세스를 차단할 수 있다.
  • 새로운 액세스 제어 목록(ACL)
  • 모든 ACL(액세스 제어 목록)
  • 새로운 퍼블릭 버킷 또는 액세스 포인트 정책
• “공개 버킷” 또는 “액세스 포인트 정책”을 통해 버킷 및 객체에 대한 “공개 및 교차 계정(cross-account) 액세스 차단”한다.
• 이러한 설정은 회사의 데이터 유출을 방지하기 위해 만들어졌으며, 버킷이 공개되어서는 안되는 경우에 사용하면 된다.
• 계정 수준에서도 차단이 가능하다.

기타 보안

• Networking
  • VPC 엔드포인트 지원(www 인터넷이 없는 VPC의 인스턴스용)
• Logging and Audit
  • “S3 액세스 로그”를 다른 S3 버킷에 저장할 수 있다.
  • API 호출은 “AWS CloudTrail”에 로깅할 수 있다.
• User Security
  • MFA 삭제: 객체를 삭제하려면 버전이 지정된 버킷에서 “MFA”가 필요할 수 있다.
  • 서명된(Pre-Signed) URLs: 제한된 시간 동안만 유효한 URL(예를 들어, 로그인한 사용자를 위한 프리미엄 비디오 서비스)을 제공할 수 있다.

S3 웹사이트

• S3는 정적 웹사이트를 호스팅하고 “www”에서 액세스할 수 있다.
• 웹사이트 URL은 아래와 같다.
  • <bucket-name>.s3-website-<AWS-region>.amazonaws.com
  • <bucket-name>.s3-website.<AWS-region>.amazonaws.com
• 만약 403(Forbidden) 오류가 발생한다면 버킷 정책이 공개 읽기를 허용하고 있는지 확인해야 한다.

---

CORS

개요

• “Origin”은 스키마(프로토콜), 호스트(도메인) 및 포트를 의미한다.
• “CORS”는 “Cross-Origin Resource Sharing”을 의미한다.
• 웹 브라우저 기반 메커니즘을 통해 기본 출처(Origin)를 방문하는 동안 다른 출처(Origin)에 대한 요청을 허용한다.
• 동일한 출처(Origin)의 예시: http://example.com/app1 & http://example.com/app2
• 다른 출처(Origin)의 예시: http://www.example.com & http://other.example.com
• “CORS” 헤더(Access-Control-Allow-Origin과 같은)를 사용하여 다른 출처에서 요청을 허용하지 않는 한 요청이 허용되지 않는다.

Diagram

S3에서의 CORS

• 만약 클라이언트가 S3 버킷에 대해 “교차 출처 요청”을 수행하는 경우, 올바른 CORS 헤더가 필요하다.
• 특정 출처 또는 *(모든 출처)에 대해 허용할 수 있다.

S3 일관성(Consistency) 모델

• 2020년 12월 현재 강력한 일관성을 보여준다.
• After a
  • 새 객체의 성공적인 쓰기(새로운 PUT)
  • 기존 객체 덮어쓰기 또는 삭제(PUT 덮어쓰기, DELETE)
• ...any
  • 후속 읽기 요청은 객체의 최신 버전을 즉시 수신한다.(쓰기 일관성 후 읽기)
  • 후속 목록 요청은 변경 사항을 즉시 반영한다.(목록 일관성)
• 성능에 미치는 영향이나 추가 비용 발생없이 사용 가능하다.

---

참고 자료

• https://www.udemy.com/course/aws-certified-solutions-architect-associate-saa-c03