125. Amazon S3 - 섹션 소개
Amazon S3는
AWS에서 가장 중요한 구성 요소 중 하나이며 본 강의에서 계속해서 사용할 것입니다. 무한히 확장 가능한 스토리지로 광고하며 즉, 크기를 사전에 프로비저닝할 필요가 없으며 무한히 확장 가능하다고 합니다.
굉장히 인기가 많고 이를 위해 고급 섹션을 준비해두었습니다. Amazon S3 관련 배울 것이 많이 있습니다.
여러분이 모를 수 있는 것은 세계의 많은 웹사이트가 Amazon S3를 중추로 사용한다는 것입니다. Amazon S3에 웹사이트를 어떻게 배포하는지 알아보고
Amazon S3와 통합할 수 있는 많은 AWS 리소스들을 살펴볼 것입니다
126. S3 버킷 및 객체
먼저 Amazon S3에 관해 이야기하겠습니다
버킷에 관해 이야기해야 하는데요. S3은 객체를 저장하게 해주는 시스템이자 서비스입니다. 즉, 파일이 버킷 또는 디렉터리에 있고
각 버킷은 전역적으로 고유한 이름을 갖습니다. 실습에서 보게 될 텐데 이미 사용 중인 이름을 사용하여 버킷을 만들 수 없습니다.
버킷은 리전 수준에서 정의됩니다. S3은 전역 서비스이지만 버킷은 리전 리소스입니다
명명 규칙으로는
- 대문자나 소문자를 포함하지 말 것,
- 밑줄을 사용하지 말 것
- 길이는 3에서 63자일 것,
- IP 주소가 아닐 것
- 소문자 또는 숫자로 시작할 것이 있습니다
S3 버킷에서 객체를 만들어야 합니다
객체는 파일로, 키를 가집니다 키가 무엇일까요?
이것은 파일의 전체 경로입니다
- 만약 버킷 이름이 my-bucket이고 객체 이름이 my_file.txt라면 키는 my_file.txt로 파란색 글씨 부분입니다.
- 만약 S3 버킷 내에 폴더 구조가 있다면 즉, my_folder1, another_folder, my_file.txt가 있다면 키는 전체 경로입니다. 여기 파란색으로 되어 있는 전체 경로가 키입니다.
키는 2개로 구성되는데 바로 접두어와 객체 이름입니다.
- 같은 예시로 살펴보자면 my_file.txt의 접두어는 my_folder1/another_folder/입니다 이것이 접두어죠. 반면 객체 이름은 my_file.txt입니다.
즉, 버킷 내에는 디렉터리 개념 없이 키 이름만 아주 깁니다. UI는 여러분이 디렉터리를 생각하도록 만들 것이지만요. 왜냐하면 S3 내에서 디렉터리를 생성할 수 있기 때문입니다.
S3에서 가질 수 있는 것은 '/'를 가진 매우 긴 이름의 키뿐입니다.
계속해서 객체를 살펴봅니다
객체 값은 본문의 내용으로
- Amazon S3에서 객체의 최대 크기는 5TB, 5,000GB로 매우 큽니다
- 그러나 한 번에 5GB 이상 업로드할 수 없습니다. 즉, 5TB의 큰 객체를 업로드하기 원한다면 객체를 5GB 미만으로 나누어서 각각 업로드해야 합니다. 이것을 멀티파트 업로드라고 합니다
Amazon S3의 각 객체는 키 페어의 리스트인 메타데이터가 있습니다. 이는 시스템이나 사용자 메타데이터에서 사용됩니다. 객체에 정보와 태그를 추가할 때 사용하죠.
객체나 수명 주기 정책 관련 보안이 없는 경우에 매우 유용한 키 값 페어와 태그를 가질 수 있습니다.
마지막으로 버전 관리를 살펴보면 Amazon S3 객체에 버전 ID가 있습니다. 버전 관리 관련 강의를 통해 버전 관리의 가치를 알아보겠습니다. 그럼 Amazon S3 콘솔로 들어가 바로 실습으로 들어가겠습니다.
127. S3 버킷 및 객체 - 실습(실습)
128. S3 버전 관리
이번에는 Amazon S3 버전 관리에 대해 알아봅시다
Amazon S3 파일을 버저닝 하려면 먼저 버킷 레벨에서 활성화가 되어야 합니다. 실습에서 보여 드릴 내용이죠.
즉, 같은 키로 파일 버전을 다시 업로드하는 경우에 기존 파일을 덮어쓰게 되는데 사실은 덮어쓰는 게 아니라 해당 파일의 새로운 버전을 생성하는 겁니다. 따라서 기존의 파일을 덮어쓰는 것이 아니라 새로운 파일 버전을 생성하는 거죠 여기서는 간단하게 표현해서 버전 1, 2, 3 등이 되겠습니다
Amazon S3에서 버킷을 버저닝하여 모든 파일 버전을 어느 정도 유지하는 것이 가장 좋은 방법이라고 할 수 있는데요.
- 원치 않은 삭제로부터 보호받을 수 있기 때문입니다. 이전 버전을 복원할 수 있거든요.
- 또한 필요한 이전 버전으로 손쉽게 되돌릴 수도 있습니다
여기서 몇 가지 알아 두셔야 할 점은
- 버저닝을 활성화하기 전에 버전 관리되지 않은 파일은 null 버전이 됩니다
- 그리고 버킷에서 버저닝을 중단하면 이전 버전을 삭제하는 것이 아니라 이후의 파일이 버전을 할당받지 못하도록 합니다
129. S3 버전 관리 실습(실습)
130. S3 암호화
이번 시간에 살펴볼 내용은 Amazon S3 객체 암호화입니다. Amazon S3에 객체를 업로드할 경우 이들은 AWS 내의 서버가 되므로 객체로 접근이 불가능하게끔 보호하려 할 겁니다. 예를 들어 누군가가 Amazon 서버에 들어올 때 혹은 회사에서 설정한 보안 기준을 확실히 준수하려는 경우 등이 있겠죠.
이런 경우, Amazon S3에서 객체 암호화를 위한 네 가지의 방법이 있습니다
- 첫 번째는 SSE-S3입니다 AWS가 처리 및 관리하는 키를 사용해 S3 객체를 암호화하는 방법이죠.
- 두 번째는 SSE-KMS로 AWS 키 관리 서비스를 사용해서 암호화 키를 관리하는 방법입니다
- 세 번째는 SSE-C인데, 사용자가 만든 암호화 키를 관리할 때 쓰이는 방식이죠
- 그리고 마지막으로는 클라이언트 측 암호화가 있죠
이제부터 자세히 알아볼 테니 너무 걱정하지 마세요
특정 상황에서 어떤 방법을 적용해야 하는지를 이해하는 게 시험 대비를 위해 중요합니다. 시험에서 분명 상황에 따라 올바른 암호화 레벨을 고르는 문제가 출제될 테니까요.
먼저 SSE-S3를 살펴봅시다
이 암호화 방법은 Amazon S3에서 처리하고 관리하는 키를 암호화에 사용하는 방식입니다.
객체는 서버 측에서 암호화됩니다 SSE가 서버 측 암호화를 뜻하죠.
그리고 암호화 유형은 AES-256 알고리즘입니다. 따라서 이렇게 객체를 업로드하고 SSE S3 암호화를 설정하려면
"x-amz-server-side- encryption":"AE256"로 헤더를 설정합니다 x-amz는 x Amazon이며 x Amazon 서버 측 암호화 AES-256, 이런 식으로 헤더 이름을 기억할 수 있겠죠
여기의 예시를 보시면 객체가 있는데 암호화된 상태는 아닙니다. Amazon S3로 해당 객체를 업로드해서 SSE-S3 암호화를 하려 합니다. 그러면 우선 Amazon S3에 객체를 업로드합니다. HTTP 혹은 HTTPS 프로토콜을 사용할 수 있습니다. 그리고 방금 언급했던 헤더를 추가합니다. "x-amz-server-side- encryption":"AES256" 그러면 Amazon S3는 이 헤더를 통해 고유의 S3 관리 데이터 키를 사용해야 한다는 사실을 인식하고 S3 관리 데이터 키와 객체를 사용해서 암호화가 이루어집니다. 그 후 객체는 암호화되어 Amazon S3 버킷에 저장이 되죠
아주 간단합니다 하지만 이 인스턴스에서는 Amazon S3에서 데이터 키를 전부 소유 및 관리하고 있는 거죠.
다음은 SSE-KMS입니다 KMS에 아직 배운 적이 없죠. 해당 과정 후반부에서 보안을 다룰 때 알아 볼 내용입니다. KMS는 키 관리 서비스를 의미하며 암호화 서비스들 중 하나죠.
SSE-KMS에서의 암호화 키는 KMS 서비스에서 처리 및 관리합니다.
왜 SSE-S3 대신 KMS를 사용할까요? 그 이유는, 누가 어떤 키에 접근할 수 있을지 제어 가능하고 또한 감사 추적을 할 수 있기 때문입니다.
각각의 객체는 마찬가지로 서버 측에서 암호화되며
이를 위해서는 헤더를 설정할 때 x Amazon 서버 측 암호화 값을 "aws:kms"로 지정해야 합니다
역시 서버 측 암호화이므로 원리는 이전과 동일합니다. 객체가 있고, HTTPS와 헤더를 사용해 업로드가 되어 있죠. 그리고 이 헤더를 통해서 Amazon S3은 미리 정의해 둔 KMS 고객 마스터 키를 사용하게 됩니다. 고객 마스터 키를 사용하면 즉 지정된 키와 객체를 사용하면 암호화가 이루어지고 파일은 SSE-KMS 암호화 방식 하에 S3 버킷에 저장됩니다
다음은 SSE-C 차례입니다
서버 측 암호화 방식을 뜻하며 AWS가 외부에서 고객이 관리하는 키를 사용하죠
이런 경우에 Amazon S3은 고객이 제공한 암호화 키를 저장하지 않습니다. 암호화를 위해서는 당연히 키를 사용하겠지만 그 후에는 키를 폐기합니다
그리고 데이터를 AWS로 전송할 때에는 HTTPS를 사용해야 합니다 AWS로 암호를 전달할 테니 전송되는 동안 암호화가 반드시 필요하겠죠.
암호화 키가 HTTP의 헤더에 제공되어야 하는데, 모든 HTTP 요청마다 매번 제공되어야 합니다 항상 사용 후 폐기되기 때문이죠.
예시에 있는 이 객체를 Amazon S3에 암호화하려 한다고 해봅시다. 하지만 직접 클라이언트 측 데이터 키를 제공해서 암호화하고자 하죠. 따라서 HTTPS를 통해 이 두 가지를 모두 전송합니다. 이때 클라이언트와 Amazon S3 사이의 연결은 암호화되고 데이터 키는 헤더 안에 있습니다. 따라서 Amazon S3는 처음과 동일한 객체 및 클라이언트 제공 데이터 키를 받을 것이고 이 역시 서버 측 암호화 방식이므로 Amazon S3이 그 두 가지를 사용해서 암호화한 후에 암호화된 객체를 S3 버킷에 저장할 겁니다. 만약 SSE-C를 통해 Amazon S3으로부터 파일을 다시 받으려면 사용된 것과 동일한 클라이언트 측 데이터 키를 제공해야만 합니다. 그러니 클라이언트 측에서 관리할 것이 더 많겠죠. 클라이언트가 데이터 키를 관리하는데 Amazon 측인 AWS는 사용자가 어떤 데이터 키를 사용했는지를 알 수 없기 때문입니다. 우리가 해야 할 일이 좀 더 많죠.
마지막으로, 클라이언트 측 암호화입니다. 이 방법은 Amazon S3에 객체를 업로드하기 전 클라이언트, 즉 여러분이 객체를 암호화하는 겁니다
클라이언트 라이브러리를 사용할 수 있는데 Amazon S3 Encryption Client 등으로 클라이언트 측 암호화를 수행할 수 있습니다.
클라이언트는 데이터를 S3로 보내기 전에 암호화해야 합니다.
만약 전달받은 데이터가 클라이언트 측 암호화, 즉 CSE를 사용해 암호화되었다면 데이터를 해독할 책임도 전적으로 사용자에 달려있습니다. 따라서 올바른 키가 준비되어 있어야겠죠
즉 클라이언트 측 암호화에서는 키와 암호화 주기 전체를 클라이언트가 전부 관리하게 됩니다.
예시를 살펴봅시다
현재 Amazon S3는 그저 버킷 상태입니다. 어떤 암호화도 제공하지 않아요 지금은 서버 측 암호화가 아니라 클라이언트 측 암호화니까요.
그리고 클라이언트는 암호화 SDK를 사용합니다. 예를 들어 S3 암호화 SDK를 사용해 객체와 클라이언트 측 데이터 키를 제공할 수 있습니다. 암호화가 클라이언트 측에서 일어나므로 객체는 클라이언트 측에서 완전히 암호화가 됩니다. 그리고 암호화된 객체를 Amazon S3에 업로드하게 되죠.
여기까지 암호화의 네 가지 유형을 살펴봤습니다.
이번 강의에서는 통신 중 암호화에 대해서도 언급했었는데 정확하게 정리를 해드리겠습니다. SSL 및 TLS 연결이 여기에 해당합니다.
Amazon S3이 이 서비스를 주도하며
- 암호화되지 않은 상태의 HTTP 엔드 포인트를 노출하고
- 또한 암호화된 HTTPS 엔드 포인트를 노출해 전송 중 암호화 서비스를 제공합니다. 이때 SSL와 TLS 인증서의 도움을 받게 됩니다
물론 원하는 엔드 포인트를 사용하셔도 되지만 콘솔에서는 대게 HTTPS를 사용하게 되죠 그리고 대부분의 클라이언트가
기본적으로 HTTPS 엔드 포인트를 사용합니다. 따라서 HTTPS를 사용하면 클라이언트 및 Amazon S3 사이를 이동하는 데이터가 모두 암호화되며, 이것 때문에 전송 중 암호화라는 이름이 붙었죠.
여기서 참고하실 점으로는 SSE-C, 즉 서버 측 암호화를 사용해 클라이언트가 키를 제공하는 경우에는 HTTPS 사용이 의무입니다.
전송 중 암호화는 SSL/TLS라고도 불리는데 SSL와 TLS 인증서를 사용하기 때문입니다
그럼 이제 암호화를 실습해 보겠습니다
131. S3 암호화 - 실습(실습)
132. S3 보안 및 버킷 정책
이번에는 Amazon S3 보안에 대해서 알아보겠습니다
제법 복잡한 내용인데요, 가장 먼저 사용자 기반 보안이 있습니다
- IAM 사용자는 IAM 정책을 가지고 있는데 이들은 정책은 어떤 API 호출이 허용될지를 결정합니다. 만약 유저가 IAM 정책을 통해 Amazon S3 버킷으로의 액세스 방법을 승인받게 되면 실행이 가능해집니다
다음은 리소스 기반 보안입니다.
- 악명 높은 S3 버킷 정책이죠. S3 콘솔에서 설정 가능한 버킷 전반의 규칙이며 S3 버킷에서 보안 주체가 무엇을 할 수 있는지 혹은 할 수 없는지를 결정하는 정책이죠. 그리고 이를 통해 S3 버킷으로의 교차 계정 액세스가 활성화됩니다. S3 버킷 정책은 실습을 통해 자세히 배우겠습니다
- 다음은 세분화된 방식인 ACL 방식입니다. 객체 레벨에서의 액세스 규칙을 설정하죠.
- 그리고 마지막인 버킷 ACL 방식은 더욱 드물죠. 이 두 가지 방식은 시험에 거의 출제되지 않습니다
참고로 IAM 보안 주체인 유저나 역할 등은
- IAM 권한이 허용할 경우에 S3 객체에 액세스할 수 있습니다. 다시 말해 IAM 정책이 S3 버킷에 액세스를 허용하는 보안 주체와 연결되어 있는 경우 혹은 리소스 정책, 즉 보통의 경우 S3 버킷 정책이 허용하는 경우에도 액세스가 가능합니다.
- 그리고 그와 동시에 명시적 거부가 없어야 하죠. 따라서 사용자가 IAM을 통해 S3 버킷에 액세스할 수 있다 해도 버킷 정책이 사용자 액세스를 명시적으로 거부한다면 액세스가 불가능합니다.
이제 S3 버킷 정책을 자세히 살펴봅시다
이는 JSON 기반 정책인데요. JSON은 표기형 언어입니다.
우측을 보시면 예시로 나타낸 JSON 버킷 정책이 있습니다 이 버킷 정책을 사용하면 S3 버킷 상에서 퍼블릭 읽기가 허가됩니다. "Effect"는 "Allow" "Principal"의 "*"은 누구나 "Action"은 "s3:GetObject", "Resource"는 examplebucket/* 즉 S3 버킷의 어떤 객체도 가능하다는 의미죠. 좋습니다, 이를 통해 S3 버킷에 퍼블릭 액세스가 가능해지죠
- 이러한 버킷 정책은 사용자의 버킷이나 객체 둘 다에 적용할 수 있습니다
- Action은 API가 허가 및 거부를 하도록 설정하고
- Effect는 허용이나 거부
- Principal은 해당 S3 버킷의 정책을 적용할 계정 혹은 유저입니다
흔히 S3 버킷 정책을 사용하는 경우의 예로는
- 버킷에 퍼블릭 액세스 권한을 승인하거나
- 업로드 시점에 객체를 암호화시킬 경우, 혹은
- 교차 계정 S3 버킷 정책을 사용해서 다른 계정에 액세스 권한을 주는 경우 등이 있습니다.
실습을 통해 S3 버킷 정책을 더 상세히 다뤄 볼 겁니다
그리고 블록 퍼블릭 액세스 버킷 설정이 있죠. 강의 초반에 실습에서 나왔던 내용이죠
객체가 퍼블릭화 되는 것을 차단하는 새로운 설정이었죠. 계정에 제한이 있을 경우에 사용됩니다. 여기 네 가지 종류의 퍼블릭 액세스 차단 설정이 있습니다.
- 새 액세스 제어 목록
- 모든 액세스 제어 목록
- 새 퍼블릭 또는 액세스 포인트 정책이죠. 이런 방식이 승인되는 경우 객체와 버킷이 외부로 공개되지 않도록 차단할 수 있게 됩니다.
혹은 퍼블릭 버킷이나 액세스 포인트 정책을 통해 버킷과 객체를 향한 퍼블릭 및 교차 계정 액세스를 막을 수 있죠.
네 가지 설정을 전부 기억할 필요는 없습니다. 여기서는 요약만 해드렸는데 시험 준비를 위해서는 이러한 설정들을 사용하면 S3 버킷에 대한 퍼블릭 액세스를 차단할 수 있다는 사실 정도만 기억해 두시면 됩니다. 시험에서 각 설정에 대한 문제가 출제되진 않거든요.
이들은 역사적으로 기업 데이터 유출을 막기 위해서 만들어졌습니다. Amazon S3 버킷이 많이 유출되었고, 결국 Amazon S3은 버킷이 퍼블릭이 아니라는 사실을 알릴 수 있는 설정을 만들어 낸 것이고 아주 인기가 많았습니다.
따라서 버킷을 절대로 퍼블릭으로 두지 않으시려면 이 설정을 켜 두셔야 합니다
그리고 이들을 계정 레벨에서 설정하는 방법들은 실습에서 다뤄 보겠습니다
기타 S3 보안에 대해서도 봅시다
네트워킹에서는
- VPC 엔드 포인트로 S3에 비공개 액세스가 가능합니다. 즉 VPC에 EC2 인스턴스가 있고 인터넷 액세스는 없는 경우 VPC 엔드 포인트를 통해 비공개로 S3에 액세스할 수 있는 거죠.
로깅 및 감사에서는 S3 액세스 로그를 사용하면
- 다른 S3 버킷에 해당 로그가 저장됩니다
- API 호출은 CloudTrail, 계정에 API 호출을 로깅할 수 있는 서비스에도 로깅이 가능합니다
사용자 보안에는 MFA 삭제라는 것이 있는데
- 멀티 팩터 인증을 뜻하죠. 특정 버전 객체를 버킷에서 삭제하고 싶은 경우에 MFA 삭제를 활성화하면 됩니다. 그러면 MFA로 인증이 되어야만 객체를 삭제할 수 있습니다.
- 마지막은 사전 서명된 URL입니다. 전에 파일을 열자 아주 긴 URL이 나타났던 적이 있었죠. AWS의 자격 증명으로 서명된 URL입니다. 한정된 시간 동안만 유효하고요. 사용 예시를 보면, 유저가 로그인한 서비스로부터 프리미엄 영상을 구매하여 다운로드하는 경우 등입니다. 그러므로 만약 시험에서 제한된 시간 내에 특정 사용자가 특정 파일에 액세스하는 경우에 관련된 문제가 나오면 사전 서명된 URL을 생각하시면 됩니다.
133. S3 버킷 정책 실습(실습)
134. S3 웹사이트 + 실습
이제 S3 웹사이트에 대해 알아보죠 S3는 정적 웹사이트를 호스팅 할 수 있고 www에서 접근이 가능하도록 허용하며
웹사이트 URL도 아주 간단합니다.
- HTTP 엔드 포인트로 이와 같은 모습이거나
- 여러분이 속한 리전에 따라 다음과 같은 모습일 수 있습니다. 버킷 이름으로 먼저 시작해서 .s3-website.AWS-리전 .amazonaws.com으로 끝납니다
웹사이트를 활성화했으나 설정된 버킷 정책이 없을 때는 해당 버킷에 대한 공개 액세스가 가능하며 이때는 403 Forbidden 오류가 발생합니다. 이번 강의에서 이를 해결하는 방법까지 살펴보도록 하죠. 이제 생성한 S3 버킷을 웹사이트로 활성화해 보겠습니다
이 버킷을 정적 웹사이트로 만드는 거죠
먼저 이전에 설정해 두었던 버킷 정책을 삭제하겠습니다
삭제해서 객체 업로드 시에 아무 문제가 없도록 해 줍니다
이제 다시 Objects로 들어가서
index.html 파일을 업로드해 보겠습니다
해당 파일은 코스 다운로드 코드로 들어가서
바로 찾을 수 있습니다
아주 간단한 html 문서죠
제목은 My First Webpage고, 내용은 I love coffee, Hello world! 등으로
coffee.jpg 파일을 로드하는 역할을 합니다
나머지는 주석으로 달린 코드로
코스에 대한 데모를 다룰 때에 사용할 코드입니다
지금까지는 쉽고 간단했죠
다음으로 error.html 파일이 보이는데
이 파일은 에러가 나왔을 때 여기 나와 있는 메시지를 표시합니다
좋습니다 이제 다시 돌아가서
이 두 파일을 업로드해 보도록 하죠
Add files를 눌러서 index.html과 error.html
두 파일 모두를 업로드해 줍니다
두 파일 모두 업로드되었군요
이제 스크롤을 내려서
Upload를 클릭해 줍니다
이제 본 버킷에는 다음의 4개의 파일이 들어 있습니다
이를 직접 살펴보기도 하고 싶은데
그러려면 Properties로 이동해서
이 버킷을 웹사이트로 만들어 줘야 합니다
스크롤을 내리면 Static website hosting이 보이죠
disabled로 비활성화 상태지만 Edit으로 가서
Enable로 활성화해서 정적 웹사이트 호스팅을 선택합니다
index document에는 index.html
error document에는 error.html
바로 방금 업로드한 두 파일의 이름을 입력해 준 겁니다
변경 사항을 저장하면 이제 버킷이 정적 웹사이트로 호스팅 될 준비가 끝난 겁니다
스크롤을 끝까지 내려 보면
본 버킷의 웹사이트 엔드 포인트가 나옵니다
이 주소를 그대로 복사해서
새 탭을 연 다음 붙여 넣습니다
어떻게 됐나요? 403 Forbidden 오류가 나옵니다
본 버킷에 액세스가 허용되지 않는 거죠
당연한 일이죠 다시 돌아가서 스크롤을 끝까지 올려 보면
현재 버킷과 객체가 공개 상태가 아니라고 나와 있습니다
그럼에도 공개적으로 접근하려고 했던 거죠
그럼 어떻게 하면 될까요? 두 단계가 있는데 먼저 Permissions로 가서
Block public access 설정을 비활성화로 바꿔 줍니다
그렇지 않으면 버킷을 공개하는 것이 영영 불가능해지겠죠
Block all public access 상자 체크를 해제합니다
이제 일부 객체가 공개로 전환됩니다
그리고 공개 버킷 정책을 세워야겠죠
confirm을 입력하면 첫 번째 단계가 끝납니다
이제 두 번째 단계로는 Bucket policy로 가서
공개 액세스를 허용하는 버킷 정책을 작성해야 합니다
다시 AWS Policy Generator로 이동해서
S3 Bucket Policy로 유형을 지정합니다
Effect은 Allow로 설정하고 Principal에는 *를 입력하고
액션에는 PutObject가 아닌 GetObject를 골라 줍니다
ARN은 이번에도 버킷 ARN 뒤에 /*를 붙여 입력합니다
누구나 이 버킷에 있는 객체를 얻을 수 있다는 문장이죠
Add Statement를 클릭하고 Generate Policy에서
이대로 복사한 다음 다시 돌아와 붙여 넣습니다
이 버킷 정책으로 본 S3 버킷이 공개로 전환된 겁니다
어떻게 확인할까요? Access를 보면 Public으로 표시되며 경고 메시지가
함께 나와 있습니다 AWS에서는 공개 버킷을 권고하지 않고
Amazon S3 상에서 그 무엇이든
공개 상태로 전환한 사항에 대해서는 사용자의 주의를 요하기 때문이죠
다시 앞선 URL로 돌아가서 새로고침을 해 줍니다
I love coffee와 Hello world가 나와 있죠
coffee.jpg 파일도 표시됩니다 훌륭한 결과군요
URL 뒤에 /coffee.jpg을 추가해 보면
coffee.jpg 파일만 이렇게 따로 표시될 겁니다
dosenotexist.jpg과 같이
무작위로 URL을 입력해 보면
앞서 error.html 파일에 정의한 오류 메시지가 표시됩니다
좋습니다 성공적으로 S3 버킷을
정적 웹사이트로 변경시켜
135. S3 CORS
이제 CORS 교차 오리진 리소스 공유에 대해 살펴보도록 하겠습니다. 복잡한 개념이지만 시험에서는 단순한 사용 사례로 출제됩니다. 하지만 본 강의에서는 CORS를 심층적으로 다루며 원리를 설명할 텐데 이를 통해 시험 문제 풀이가 더욱 수월해질 수 있을 겁니다.
오리진(Origin)이란 뭘까요? 오리진은 체계, 즉 프로토콜이자 호스트, 도메인, 그리고 포트입니다 쉽게 설명하면
- 가령 https://www.example.com는 체계가 HTTP 호스트가 www.example.com, 포트가 443인 오리진입니다. 포트는 어떻게 알까요? HTTP를 사용하는 경우 기본 포트가 443입니다
CORS는 교차 오리진 리소스 공유라고 했습니다. 즉 리소스를 다른 오리진에서 얻을 수가 있다는 말이죠
웹 브라우저에는 기본적인 보안으로 CORS를 갖추고 있는데 이는 여러분이 웹사이트를 방문했을 때 다른 오리진이 허락할 때에만 요청을 보낼 수 있도록 허락하는 설정입니다. 브라우저 기반 보안인 거죠
그럼 같은 오리진과 다른 오리진이란 무엇일까요? 같은 오리진은 다음과 같습니다. example.com/app1 또는 example.com/app2일 때 같은 오리진이라고 할 수 있죠. 이때는 첫 번째 URL에서 두 번째 URL로 웹 브라우저 간 요청이 가능합니다. 오리진이 같기 때문이죠.
하지만 www.example.com를 방문한 다음 웹 브라우저에 other.example.com에 대한 요청을 할 경우 이를 교차 오리진 요청이라고 하며 이때 올바른 CORS 헤더가 없으면 웹 브라우저가 해당 요청을 차단합니다. 이 내용은 금방 다시 보도록 하죠
이제 같은 오리진과 다른 오리진을 살펴보며 다른 오리진에서 해당 CORS 헤더를 사용한 요청을 허용하지 않는 한 요청이 수행될 수 없다는 것을 알았습니다. CORS 헤더는 화면에서 보이는 것과 같이 Access-Control-Allow-Origin라고 합니다.
원리를 그림과 함께 살펴보면 더 잘 이해하실 수 있을 겁니다.
이 웹 브라우저가 첫 번째 웹 서버를 방문한다고 해 보죠. 첫 번째 방문이기 때문에 이를 오리진이라고 하겠습니다. https://www.example.com로 이 웹 서버를 불러 보죠
이제 두 번째 웹 서버는 교차 오리진이 됩니다. https://www.other.com으로 URL이 다르기 때문이죠. 이제 웹 브라우저가 첫 번째 오리진을 방문했으니 이제 이 웹 브라우저는 오리진에서 업로드된 파일에 대한 요청을 교차 오리진에서 발생시켜야 합니다. 이때 해당 웹 브라우저는 사전 요청이라는 것을 전송합니다. 이 사전 요청은 교차 오리진에게 요청을 발생시키는 것이 가능한지를 묻습니다. "교차 오리진, 웹사이트 https://www.example.com에서
나를 전송하려 하는데 네 웹사이트에 요청을 보내도 될까?" 묻는 거죠. 이때 교차 오리진이 "그럼, 이렇게 해" 하고 Access-Control-Allow-Origin을 통해 해당 웹사이트가 허용되는지를 판단하죠 좌측에 초록색으로 표시된 바와 오리진이 일치하므로 허용됩니다. 승인된 Methods는 GET, PUT, DELETE가 되죠. 파일을 가져오거나 삭제하거나 업데이트할 수 있게 되는 겁니다. 교차 오리진으로 웹 브라우저가 앞서 말한 동작을 할 수 있는 거죠. 이를 CORS 메서드라고 하며 이제 웹 브라우저가 해당 동작을 할 수 있게 되었으니 교차 오리진 URL에 대한 GET도 가능한 셈입니다. 이전에 전송받은 CORS 헤더가 웹 브라우저의 해당 요청을 허용하기 때문이죠.
생소한 개념이겠지만 다음 사례로 넘어가기 전 잘 이해하는 것이 중요합니다. 다음은 S3 CORS입니다
클라이언트가 웹사이트로 활성화된 S3 버킷에 대해 교차 오리진을 요청하는 경우 올바른 CORS 헤더를 활성화할 필요가 있습니다.
자주 나오는 시험 문제죠. 이때 CORS 헤더를 활성화해야 하는 시기와 위치를 이해해야 합니다. 곧 직접 살펴보기도 할 겁니다.
전체 오리진 이름을 지정해서 특정 오리진에 대해 허용할 수도 있고 *로 모든 오리진에 허용할 수도 있습니다 그럼 함께 한번 살펴보죠.
웹 브라우저는 버킷에서 HTML 파일을 가지고 옵니다. 이때 버킷은 웹사이트로 활성화된 상태죠. 여기서 두 번째 버킷은 교차 오리진 버킷이 되는데 이 또한 웹사이트로 활성화되어 있고 동일한 파일을 가지고 있습니다. 이때 버킷에 GET index.html을 전송하면 웹사이트가 index.html 파일을 전송해 줄 겁니다. 그리고 그 파일은 다른 오리진에 있는 또 다른 파일을 위해 GET 동작이 필요하다고 요청하겠죠. 해당 버킷이 올바른 CORS 헤더로 구성되어 있을 경우에는 웹 브라우저가 요청을 보낼 수 있으나 아닐 경우에는 요청이 불가능합니다. 바로 이것이 CORS의 목적이죠. 여기 보이는 바와 같이 CORS 헤더는 첫 번째 오리진 버킷이 아닌 교차 오리진 버킷에 구성되어야 합니다.
