AWS Certified Solutions Architect Associate [8] Amazon S3

Amanzon S3

S3

• AWS에서 가장 중요한 구성 요소 중 하나
• 무한히 확장 가능한 스토리지 입니다.
  • 즉, 크기를 사전에 프로비저닝할 필요가 없으며 무한히 확장 가능하다고 합니다
• 세계의 많은 웹사이트가 Amazon S3를 중추로 사용한다는 것입니다.

---

Buckets

• S3는 객체를 저장하게 해주는 시스템이자 서비스입니다.
  • 파일이 버킷 또는 디렉터리에 있고 각 버킷은 전역적으로 고유한 이름을 갖습니다.
• 이미 사용 중인 이름을 사용하여 버킷을 만들 수 없습니다.
  • 버킷의 이름은 유니크해야합니다.
• 리전 수준에서 정의됩니다.
• 명명 규칙
  • 대문자나 밑줄을 포함하지 않는다.
  • 길이는 3에서 63자
  • IP 주소가 아닐 것
  • 소문자 또는 숫자로 시작할 것

---

Objects (객체)

• 객체는 파일로, 키를 가집니다.
  • 키?
    • 파일의 전체 경로입니다.
    • EX) s3://my-bucket/my_file.txt
    • EX) s3://my-bucket/my_folder1/another_folder/my_file.txt
  • 키는 2개로 구성되는데 바로 EX) s3://my-bucket/접두어와 객체 이름입니다.
    • EX) s3://my-bucket/my_folder1/another_folder/my_file.txt
  • 버킷 내에는 디렉터리 개념 없이 키 이름만 아주 깁니다.
  • S3에서 가질 수 있는 것은 '/'를 가진 매우 긴 이름의 키뿐입니다.
    
    
• 객체 값은 본문의 내용으로 Amazon S3에서 객체의 최대 크기는 5TB, 5,000GB로 매우 큽니다
• 멀티파트 업로드
  • 5TB의 큰 객체를 업로드하기 원한다면 객체를 5GB 미만으로 나누어서 각각 업로드해야 합니다.
• Amazon S3의 각 객체는 키 페어의 리스트인 메타데이터가 있습니다.
  • 객체에 정보와 태그를 추가할 때 사용합니다.
• 객체나 수명 주기 정책 관련 보안이 없는 경우에 매우 유용한 키 값 페어와 태그를 가질 수 있습니다
• Amazon S3 객체에 버전 ID가 있습니다.

---

Versioning (버전 관리)

• Amazon S3 파일을 버저닝 하려면
  • 버킷 레벨에서 활성화가 되어야 합니다.
    • 같은 키로 파일 버전을 다시 업로드하는 경우에
      기존 파일을 덮어쓰게 되는데 사실은 덮어쓰는 게 아니라
      해당 파일의 새로운 버전을 생성하는 겁니다.
  • Amazon S3에서 버킷을 버저닝하여 모든 파일 버전을 어느 정도 유지하는 것이 가장 좋은 방법입니다.
    • 이전 버전을 복원하여 원치 않은 삭제로부터 보호받을 수 있습니다.
    • 필요한 이전 버전으로 손쉽게 되돌릴 수도 있습니다.
  • 버저닝을 활성화하기 전에 버전 관리되지 않은 파일은 null 버전이 됩니다.
  • 그리고 버킷에서 버저닝을 중단하면 이전 버전을 삭제하는 것이 아니라 이후의 파일이 버전을 할당받지 못하도록 합니다.

---

객체를 위한 S3 암호화

• 네 가지 방법
  • SSE-S3
    • AWS가 처리 및 관리하는 키를 사용해 S3 객체를 암호화하는 방법입니다.
  • SSE-KMS
    • AWS 키 관리 서비스를 사용해서 암호화 키를 관리하는 방법입니다.
  • SSE-C
    • 사용자가 만든 암호화 키를 관리할 때 쓰이는 방식입니다.
  • 클라이언트 측 암호화
    
    

    특정 상황에서 어떤 방법을 적용해야 하는지를 이해하는 게 중요하다.

SSE-S3

• Amazon S3에서 처리하고 관리하는 키를 암호화에 사용하는 방식입니다.
• 객체는 서버 측에서 암호화됩니다.
  • SSE가 서버 측 암호화를 뜻합니다.
  • 암호화 유형은 AES-256 알고리즘입니다.
• "x-amz-server-side- encryption":"AE256"로 헤더를 설정합니다.
  • x-amz는 x Amazon
  • x Amazon 서버 측 암호화 AES-256

---

SSE-KMS

• KMS는 키 관리 서비스를 의미하며 암호화 서비스들 중 하나입니다.
• KMS 서비스에서 처리 및 관리합니다.
• 왜?
  • 누가 어떤 키에 접근할 수 있을지 제어 가능하고 또한 감사 추적을 할 수 있기 때문입니다.
• 헤더를 설정할 때 x Amazon 서버 측 암호화 값을 "aws:kms"로 지정해야 합니다.
  • "x-amz-server-side-encryption":"aws:kms"

---

SSE-C

• 서버 측 암호화 방식
• AWS가 외부에서 고객이 관리하는 키를 사용합니다.
  • Amazon S3은 고객이 제공한 암호화 키를 저장하지 않습니다.
  • 암호화를 위해서는 당연히 키를 사용하겠지만 그 후에는 키를 폐기합니다.
• 데이터를 AWS로 전송할 때에는 HTTPS를 사용해야 합니다
  • AWS로 암호를 전달할 테니 전송되는 동안 암호화가 반드시 필요하기 때문입니다.
• 암호화 키가 HTTP의 헤더에 제공되어야 합니다.

---

클라이언트 사이드 암호화

• Amazon S3에 객체를 업로드하기 전 클라이언트, 즉 여러분이 객체를 암호화하는 겁니다.
• 클라이언트 라이브러리를 사용하여 클라이언트 측 암호화를 수행할 수 있습니다.
• 클라이언트는 데이터를 S3로 보내기 전에 암호화해야 합니다.
• CSE를 사용해 암호화되었다면 데이터를 해독할 책임도 전적으로 사용자에 달려있습니다.
• 키와 암호화 주기 전체를 클라이언트가 전부 관리하게 됩니다.

---

통신 중 암호화 (SSL / TLS)

• Amazon S3
  • 암호화되지 않은 상태의 HTTP 엔드 포인트를 노출합니다.
  • 암호화된 HTTPS 엔드 포인트를 노출해 전송 중 암호화 서비스를 제공합니다.
  • 이때 SSL와 TLS 인증서의 도움을 받게 됩니다.
• 원하는 엔드 포인트를 사용하셔도 되지만,
  콘솔에서는 대게 HTTPS를 사용하게 됩니다.
  그리고 대부분의 클라이언트가 기본적으로 HTTPS 엔드 포인트를 사용합니다.

HTTPS를 사용하면 클라이언트 및 Amazon S3 사이를 이동하는 데이터가 모두 암호화되며,
이것 때문에 송 중 암호화라는 이름이 붙었습니다.

• SSE-C, 즉 서버 측 암호화를 사용해 클라이언트가 키를 제공하는 경우에는 HTTPS 사용이 의무입니다.
• 전송 중 암호화는 SSL/TLS라고도 불리는데 SSL와 TLS 인증서를 사용하기 때문입니다.

---

S3 Security

• 사용자 기반
  • IAM 사용자는 IAM 정책을 가지고 있는데 이들은 정책은 어떤 API 호출이 허용될지를 결정합니다.
• 리소스 기반
  • 악명 높은 S3 버킷 정책입니다.
  • S3 콘솔에서 설정 가능한 버킷 전반의 규칙이며 S3 버킷에서 보안 주체가 무엇을 할 수 있는지 혹은 할 수 없는지를 결정하는 정책입니다.
  • 세분화된 방식인 ACL 방식입니다.
    • 객체 레벨에서의 액세스 규칙을 설정합니다.
  • 버킷 ACL 방식

참고로 IAM 보안 주체인 유저나 역할 등은 IAM 권한이 허용할 경우에 S3 객체에 액세스할 수 있습니다.
그와 동시에 명시적 거부가 없어야 합니다.
따라서 사용자가 IAM을 통해 S3 버킷에 액세스할 수 있다 해도 버킷 정책이 사용자 액세스를 명시적으로 거부한다면 액세스가 불가능합니다.

---

S3 Bucket 정책

• JSON 기반 정책
  • 리소스 : 버킷과 객체
  • Actions : API가 허가 및 거부를 하도록 설정
  • Effects : 허용이나 거부
  • Principal : 해당 버킷의 정책을 적용할 계정 또는 유저
    
    
• S3 버킷 정책을 사용하는 경우
  • 버킷에 퍼블릭 액세스 권한을 승인
  • 업로드 시점에 객체를 암호화
  • 교차 계정 S3 버킷 정책을 사용해서 다른 계정에 액세스 권한을 주는 경우

---

Block Public Access Bucket 설정

• 객체가 퍼블릭화 되는 것을 차단하는 새로운 설정입니다.
• 승인되는 경우
  • new access control lists (ACLs) - 새 액세스 제어 목록
  • any access control lists (ACLs) - 모든 액세스 제어 목록
  • 새 퍼블릭 또는 액세스 포인트 정책
• 객체와 버킷이 외부로 공개되지 않도록 차단할 수 있게 됩니다.
• 퍼블릭 버킷이나 액세스 포인트 정책을 통해 버킷과 객체를 향한
  퍼블릭 및 교차 계정 액세스를 막을 수 있습니다.
• 이들은 역사적으로 기업 데이터 유출을 막기 위해서 만들어졌습니다.
• 퍼블릭으로 두지 않으시려면 이 설정을 켜 두셔야 합니다.

이러한 설정들을 사용하면
S3 버킷에 대한 퍼블릭 액세스를 차단할 수 있다는 사실

---

기타 S3 보안

• 네트워킹
  • VPC 엔드 포인트로 S3에 비공개 액세스가 가능합니다.
  • VPC에 EC2 인스턴스가 있고 인터넷 액세스는 없는 경우 VPC 엔드 포인트를 통해 비공개로 S3에 액세스할 수 있는 것입니다.
• 로깅 및 감사
  • S3 액세스 로그를 사용하면 다른 S3 버킷에 해당 로그가 저장됩니다.
  • API 호출을 하면 CloudTrail, 계정에 로깅할 수 있는 서비스에도 로깅이 가능합니다.
• 사용자 보안
  • MFA 삭제
    • 특정 버전 객체를 버킷에서 삭제하고 싶은 경우에 MFA 삭제를 활성화하면 됩니다.
  • 사전 서명된 URL
    • AWS의 자격 증명으로 서명된 URL입니다.
    • 한정된 시간 동안만 유효합니다.
    • 특정 사용자가 특정 파일에 액세스하는 경우에 해당합니다.

---

CORS (교차 오리진 리소스 공유)

CORS

• Origin
  • 체계, 즉 프로토콜이자 호스트, 도메인, 그리고 포트입니다.
    https://www.example.com
    체계가 HTTP, 호스트가 www.example.com, 포트가 443인 오리진입니다.
    
    
• CORS는 교차 오리진 리소스 공유라고 했습니다.
  • 리소스를 다른 오리진에서 얻을 수가 있다는 말입니다.
    
    
• 웹 브라우저에는 기본적인 보안으로 CORS를 갖추고 있는데,
  이는 여러분이 웹사이트를 방문했을 때
  다른 오리진이 허락할 때에만 요청을 보낼 수 있도록 허락하는 설정입니다.
  
  
• 같은 Origin
  • http://example.com/app1 & http://example.com/app2
• 다른 Origin
  • www.example.com/app1 & other.example.com/app2
    
    
• 다른 오리진에서 해당 CORS 헤더를 사용한 요청을 허용하지 않는 한
요청이 수행될 수 없다는 것을 알았습니다.
  • CORS 헤더는 화면에서 보이는 것과 같이 Access-Control-Allow-Origin라고 합니다.

S3 CORS

• 클라이언트가 웹사이트로 활성화된 S3 버킷에 대해 교차 오리진을 요청하는 경우,
  올바른 CORS 헤더를 활성화할 필요가 있습니다.
• 전체 오리진 이름을 지정해서 특정 오리진에 대해 허용할 수도 있습니다.
• *로 모든 오리진에 허용할 수도 있습니다.
• CORS 헤더는 첫 번째 오리진 버킷이 아닌 교차 오리진 버킷에 구성되어야 합니다.

---

S3 일관성 모델

• 2020년 12월부터 Amazon S3의 모든 작업은 강력한 일관성을 바탕으로 이루어지며 이전과는 확연히 다른 모습을 보여 줍니다.

만약 새로운 객체를 성공적으로 Amazon S3에 작성했다거나 기존 객체를 덮어쓰거나 삭제하는 경우
혹은 이와 같은 모든 작업에 대해 언제든 읽기 혹은 쓰기 후 읽기를 수행할 때마다
방금 작성한 객체를 볼 수 있다는 의미입니다.
그리고 목록을 작성할 때에도 목록 내 항목을 바로 볼 수 있습니다.

Amazon S3는 이제 강력한 일관성을 자랑하며
언제든 쓰기나 기록 후 읽기, 혹은 읽기를
수행할 때에 여러분이 업로드했거나
방금 작성한 것과 동일한 결과가 표시됩니다
성능에 영향을 주지 않으며 무상으로 제공되는 기능입니다.

---

From
AWS Certified Solutions Architect Associate 시험합격!