[AWS] Amazon S3

Amazon S3의 사용 사례

• 백업과 스토리지
• 파일용 또는 디스크용, 재해 복구의 용도로 사용
• 아카이브용
   - S3 파일을 아카이브 해두면 추후 매우 손쉽게 검색할 수 있다.
• 하이브리드 클라우드 스토리지
• 애플리케이션 호스팅
• 미디어 호스팅
• 데이터 레이크 & 빅 데이터 분석
• 정적 웹사이트 호스

 

Amazon S3 - Buckets

• S3는 파일을 '버킷'에 저장하는데, 버킷은 상위 레벨 디렉토리로 표시된다.
• S3 버킷의 파일은 '객체'라고 한다.
• 버킷은 계정 안에 생성되고, 버킷에는 전역적으로 고유한 이름이 있어야 한다.
    - 이름은 계정에 있는 모든 리전과 AWS에 존재하는 모든 계정에서 고유해야 한다.
       (= AWS에서 전역적으로 고유한 단 하나의 이름)
• 버킷은 리전 수준에서 정의된다.
    - 버킷 이름이 모든 리전과 모든 계정에서 고유해도 버킷은 반드시 특정 AWS 리전에서 정의되어야 한다.
• S3는 전역 서비스처럼 보이지만 버킷은 사실상 '리전'에서 생성된다.
• S3 버킷의 네이밍 규칙
   - 대문자나 밑줄이 없어야 한다.
   - 길이는 3자 ~ 63자 사이여야 한다.
   - IP여서는 안된다.
   - 소문자나 숫자로 시작해야 한다.
   - 몇가지 접두사 제한도 있다.
   - 문자와 숫자, 하이픈만 사용가능 하다.

 

Amazon S3 - Objects

• 객체나 파일에는 '키'라는 것이 있는데, S3키는 파일의 전체 경로이다.
• 키는 길이가 굉장히 긴 이름으로 슬래시를 포함하며, 키는 접두사와 객체 이름으로 만들어진다.
• 객체의 값은 '본문의 내용'이다.
• 파일 등 원하는 것은 뭐든지 S3로 업로드 할 수 있다. 최대 객체 크기는 5TB(= 5000GB)이다.
• 객체에는 메타데이터도 있다. 객체의 키-값 쌍 리스트를 말한다.
   - 시스템이나 사용자에 의해 설정되어 파일에 관한 요소나 메타데이터를 나타낼 수 있다.
• 태그의 경우, 가령 유니코드 키-값 쌍은 최대 10개까지 가능하다.
   - 태그는 보안과 수명 주기에 유용하다.
• 객체는 버전 ID를 갖기도 한다.
   - 버전 관리를 활성화한 경우

 

Amazon S3 - Security(보안)

• 사용자 기반
   - 사용자에게는 IAM 정책이 주어지는데, 이 정책은 어떤 API 호출이 특정 IAM 사용자를 위해 허용되어야 하는지를 승인한다.
• 리소스 기반
   - Bucket Policies(버킷 정책)
      : 이 정책은 S3 콘솔에서 직접 할당할 수 있는 전체 버킷 규칙이다.
      : 특정 사용자가 들어올 수 있게 하거나 다른 계정의 사용자를 허용할 수 있는데 이를 S3 버킷에 액세스 할 수 있는 "교차 계정"이라고 한다.
    - Object Access Control List(ACL, 객체 액세스 제어 목록)
    - Bucket Access Control List(ACL, 버킷 액세스 제어 목록)
• S3 버킷의 보안을 관리하는 가장 일반적인 방법은 버킷 정책을 사용하는 것이다.
  그렇다면 어떤 상황에서 IAM 원칙이 S3 객체에 액세스 할 수 있을까?!
    - IAM 권한이 이를 허용하거나 리소스 정책이 이를 허용하는 경우이다. 이것이 작동할 때는 명백한 거부는 없고, IAM 원칙이 특정 API 호출 시 S3 객체에 액세스 할 수 있는 것이다.
• S3 보안을 관리할 수 있는 또 다른 방법은 암호키를 사용하여 객체를 암호하는 것이다.

 

Amazon S3 Bucket Policies(버킷 정책)

• S3 보안의 주안점은 바로 '버킷 정책'이다.
• JSON 기반의 정책으로 밑의 이미지 처럼 활용된다.
    - 우선 리소스 블록이 있는데, 리소스는 이 정책이 적용되는 버킷과 객체를 정책에 알려준다.
    - examplebucket 내에서 모든 객체에 적용된다는 것을 알 수 있다.
    - 밑의 예시에서 허용한 작업(Action)은 GetObject이다. 
    - 원칙(Principal)은 별표로 표시되었는데, 이 경우 별표를 통해 모든 사용자를 허용할 수 있다.
• 밑의 S3 버킷은 버킷 내 모든 객체에 대해 공개 읽기로 설정하고 있다.
    - 필요한 버킷 정책을 사용해서 버킷에 대한 공개 액세스를 허용할 수 있다. 
    - 업로드 시 객체를 강제로 암호화하거나 또 다른 계정으로의 액세스를 허용할 수도 있다.

(출처 : 구글이미지)

 

Example: Public Access - Use Bucket Policy

(출처 : 구글이미지)

• 사용자는 월드 와이드 웹에 있는데, 이 웹사이트 방문자는 S3 버킷 안에 있는 파일에 액세스하려고 한다.
• 필요한 버킷 정책을 첨부해서 공개 액세스를 허용할 것이다.
• 버킷 정책이 S3 버킷에 첨부되면 그 안에 있는 모든 객체에 액세스 할 수 있다.

Example: User Access to S3 - IAM permissions

(출처 : 구글이미지)

• 계정 내 사용자, 즉 IAM 사용자가 있는 경우는 어떨까요.
• 해당 사용자는 Amazon S3에 액세스하고자 한다. 그럼 우리는 정책을 통해 이 사용자에게 IAM 권한을 할당할 수 있다.
• 정책이 S3 버킷으로의 액세스를 허용하므로 해당 사용자는 지금 우리의 S3 버킷에 액세스 할 수 있다.

Example: EC2 instance access - Use IAM Roles

(출처 : 구글이미지)

• EC2 인스턴스가 있는 경우, EC2 인스턴스에서 S3 버킷으로 액세스를 제공할 수 있는데 위의 예시 IAM 사용자는 적절하지 않다는 걸 확인했었기 때문에 그 대신 IAM 역할을 사용해야 한다. 따라서 올바른 IAM 권한을 통해 EC2 인스턴스 역할을 생성한다.
• 그럼 이 EC2 인스턴스는 Amazon S3 버킷에 액세스 할 수 있을 것이다.

Advanced : Cross-Account Access - Use Bucket Policy

(출처 : 구글이미지)

• 교차 계정 액세스를 허용하려면 버킷 정책을 사용해야 하는데, 다른 계정에 IAM 사용자가 있다.
• 추가 버킷 정책을 생성해서 이 특정 IAM 사용자에게 교차 계정 액세스를 허용하려고 한다.
  따라서 IAM 사용자는 S3 버킷으로 API 호출을 할 수 있게 된다.

Bucket setting for Block Public Access
(블록 공개 액세스에 관한 버킷 설정)

• 버킷을 생성할 때 우리가 설정한 것을 말하는데, 이 설정은 기업 데이터 유출을 방지하기 위한 추가 보안 계층으로서 AWS가 개발했다.
• S3 버킷 정책을 설정하여 공개로 만들더라도 이 설정이 활성화되어 있다면 버킷은 절대 공개되지 않는다.
• 버킷을 공개하면 안되는 경우, 이 설정을 그대로 두면 잘못된 S3 버킷 정책을 설정한 사람들에게 대해 이러한 수준의 보안을 갖출 수 있다.

(출처 : 구글이미지)