[Udemy][day-19~22] AWS 강의 section 11 : Amazon S3 소개

#AWS Certified Developer Associate

 

 

 

109. Amazon S3 - 섹션소개

 

 

 

110. S3 객체 및 버킷

S3 - 객체를 저장하게 해주는 시스템이자 서비스

각 버킷은 전역적으로 고유한 이름을 가짐 - 이미 사용중인 버킷 이름은 사용할 수 없음

S3는 전역 서비스이지만 버킷은 region level 임

키(key) - 파일의 전체 경로(FULL path)

객체의 최대 크기는 5TB, 그러나 한번에 5GB 이상 업로드 할 수 없음 - 5GB보다 큰 객체를 업로드 할때는 분할 업로드 해야함

Amazon S3의 각 객체는 키페어의 리스트인 메타데이터가 있다 - 객체에 정보와 태그를 추가할 때 사용됨

Amazon S3 객체에 버전 ID 가 있음 - 버전 관리

 

 

111. S3 버킷 및 개체 - 실습

 

https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html

Bucket naming rules - Amazon Simple Storage Service

버킷 이름 지정 규칙 참조 링크

 

버킷 이름은 AWS에 있는 모든 계정에서 전역적으로 고유해야 함

 

S3는 글로벌 콘솔이지만 글로벌 리전은 아님 - 리전을 선택해야 함

버킷 생성

 

버킷에 이미지 파일 업로드

 

객체 정보

버킷에 업로드된 파일을 여는 방법

- S3 콘솔의 옵션에서 open

- 객체 url 로 접근

 

access denied

버킷이 공용이 아니기 때문에 접근 거부 당함

free sign url(미리 서명된 url) 사용 - AWS에 임시 보안 인증을 제공할 수 있음 - S3 콘솔의 객체 옵션 작업에서 OPEN 할 때 활성화

 

버킷에 폴더 만들기

생성한 폴더에 파일 업로드

images/ 라는 키 안에 들어있는 2.png

 

폴더를 삭제하면 내용물도 같이 영구적으로 삭제된다.

 

 

 

112. S3 버전 관리

버킷 레벨에서 Versioning 활성화 가능

같은 키를 덮어쓰기(같은 파일 업로드) - 해당 파일의 새로운 버전 생성

 - 원치 않는 삭제로부터 보호받을 수 있음

 - 필요한 이전 버전으로 손쉽게 되돌릴 수 있음

버전 관리를 활성화 하기 전에 버전이 관리 되지 않은 파일은 null 버전이 됨

버전 활성화를 중단하면 이전 버전 파일이 삭제되는 것이 아닌 이후 업로드 되는 파일이 버전을 할당받지 못하도록 함

 

 

 

113. S3 버전 관리 실습

 

버킷-속성-버킷버전관리

버전 표시

버전 표시를 활성화하면 버전ID 라는 행이 새로 생긴다

1.png 파일을 추가한 시점이 버전 관리를 활성화 하기 전이기 때문에 버전ID는 null 이다

 

새로 파일 업로드

버전 관리를 활성화한 이후 업로드한 파일에는 버전ID 가 부여됨

 

같은 파일 업로드

새로 파일을 업로드 하면 이전 버전ID 와 별도로 새로운 버전ID 가 부여된다

 

객체 삭제

삭제시에는 해당 객체에 삭제 마커가 추가된다고 한다

 

삭제마커

만약 파일을 복원한다고 하면

이 삭제마커를 지우면 된다.

 

파일의 영구 삭제는

버전을 삭제하면 영구 삭제 된다.

버전 삭제

버전 관리 활성화 상태에서 비활성화로 전환하면

이전 버전들은 계속 유지되나 새로운 버전의 경우에는 버전 ID 에 null 이 부여된다.

 

 

 

114. S3 암호화 (Encryption)

SSE - Server Side Encryption

SSE-S3 : AWS가 처리 및 관리하는 키를 사용해 S3 객체를 암호화 하는 방법

SSE-KMS : AWS 키 관리 서비스를 사용해서 암호화 키를 관리하는 방법

SSE-C : 사용자가 만든 암호화 키를 관리할 때 쓰이는 방식

Client Side Encrtpyion(클라이언트 측 암호화)

 

 

• SSE-S3

객체는 서버 측에서 암호화 됨

AES-256 알고리즘 암호화 유형 사용

SSE-S3 암호화 방식을 사용하려면 헤더에 "x-amz-server-side-encryption":"AES256" 을 추가해줘야 함

- 플로우

유저가 HTTP/S에 헤더를 추가해 S3로 파일을 업로드 함 -> AWS S3는 이 헤더를 통해 고유의 S3 관리 데이터키를 사용해야 한다는 사실을 인식 -> S3 관리 데이터 키와 객체를 사용해서 암호화 -> 객체는 암호화되어 Amazon S3 버킷에 저장됨

Amazon S3에서 데이터 키를 전부 소유 및 관리함

 

 

• SSE-KMS

KMS - Key Manegement Service (암호화 서비스 중 하나)

암호화 키를 KMS 서비스에서 처리 및 관리

KMS Advantages - 유저 컨트롤(접근 제어) + 감사 추적 가능

서버 측 암호화

헤더 "x-amz-server-side-encryption":"aws:kms"

- 플로우

유저가 HTTP/S에 헤더를 추가해 S3로 파일을 업로드 함 -> AWS S3는 이 헤더를 통해 KMS 고객 마스터 키를 사용해야 한다는 사실을 인식 -> S3 관리 데이터 키와 객체를 사용해서 암호화 -> 객체는 암호화되어 Amazon S3 버킷에 저장됨

 

 

• SSE-C

server side encryption , 외부에서 고객이 관리하는 키 사용

고객이 제공한 암호화 키를 저장하지 않음 -> 암호화 후 키를 폐기함

데이터를 aws로 전송할 때 무조건 HTTPS 를 사용해야 함

데이터 전송 요청 마다 헤더 정보를 포함해야 함 - 암호화 후 키를 계속 폐기하기 때문

- 플로우

유저는 오직 HTTPS 를 통해야 하고 Client측 데이터 키와 객체 2가지를 헤더에 담아 전송함 -> 서버 측에서 클라이언트로 부터 받은 데이터 키를 사용해 객체를 암호화 함 -> 객체는 암호화 되어 버킷에 저장됨

SSE-C를 통해 암호화 된 파일을 다시 받으려면 사용되었던 것과 동일한 클라이언트 측 데이터 키를 제공해야 함 -> 클라이언트 측에서 관리할 게 많음

 

 

• Client Side Encryption(CSE)

클라이언트 측 암호화

Amazon S3에 객체를 업로드 하기 전 클라이언트 측에서 객체를 직접 암호화 하는 것

Amazon S3 Encryption Client 등으로 클라이언트 측 암호화 수행 가능

클라이언트는 데이터를 S3로 보내기 전에 암호화 해야함 -> 만약 전달받은 데이터가 CSE를 사용해 암호화 되었다면 데이터를 해독할 책임도 전적으로 유저에게 달려있음 - 올바른 키가 준비되어 있어야 한다.

키와 암호화 주기 전체를 클라이언트가 전부 관리

- 플로우

유저는 암호화 SDK를 사용해 객체와 클라이언트 측 데이터 키를 암호화 함 -> 암호화된 객체를 Amazon S3 에 업로드

 

 

(8.9 끝)

 

(8.15 시작)

(뭐한다고 aws 손도 안댔는지 모르겠네)

연휴 가기 전에 찍먹 살짝

 

115. S3 암호화 - 실습

한갱사진 하나랑 카리나 사진 하나를 각각 다른 암호화 방식으로 업로드 할꺼다

 

hangang.png

SSE-S3 방식

별다른 옵션 없이 S3 에서 자동으로 생성 관리 해주는 암호화 방식

 

 

karina.jpeg

SSE-KMS 방식

key management service 로

kms 키는 관리형 키를 선택했다

arn 을 선택하면 키 만드는것도 나온다

 

한갱 사진은 2번 업로드 되었는데

이전에 올린 버전의 옵션을 확인했을때 암호화가 설정되어있지 않고

이번에 새로 올린 버전은 암호화가 설정되어있다.

즉 암호화는 특정 파일 및 그에 해당하는 특정 버전 ID 에만 적용된다.

 

default encryption

propertice 안의 default encryption 에서 해당 버킷의 기본 암호화 방법을 지정할 수도 있다

 

SSE-S3로 기본 암호화 방법 설정

 

 

암호화 설정 과정은 파일을 개별로 올릴때랑 똑같다

기본 암호화 방법을 설정하면 암호화 방법을 따로 설정하지 않아도(기본 암호화 방법 따르기 설정) 설정한 암호화 방법이 적용되어있다.

 

SSE-C 설정은 CLI 환경에서만 가능하며 객체 암호화를 위해서 암호화 키를 AWS로 안전하게 전달하기 위함인데, 현재는 콘솔에서 사용이 가능하게끔 개발되지 않았다 - 개발환경이 구축되지 않았다

 

(8.15 끝)

 

(8.16 시작)

 

116. S3 보안 및 버킷 정책

JSON 기반

Resources : 버킷이나 오브젝트

Actions : API가 허가 및 거부를 하도록 설정

Effect : Allow / Deny

Principal : 해당 S3 버킷의 정책을 적용할 계정 혹은 유저

 

Block Public Access

객체가 퍼블릭화 되는 것을 차단하는 설정

계정에 제한이 있을 경우에 사용됨

4가지 Block Public Access

- new access control lists (ACLs) - 새 액세스 제어 목록

- any access control lists (ACLs) - 모든 액세스 제어 목록

- new public bucket or access point policies -  새 퍼블릭 또는 액세스 포인트 정책

 

객체와 버킷이 외부에 노출되지 않도록 차단할 수 있게 됨

혹은 퍼블릭 버킷이나 액세스 포인트 정책을 통해 버킷과 객체를 향한 퍼블릭 및 교차 계정 액세스를 막을 수 있다

S3를 퍼블릭으로 두지 않으려면 이 기능을 활성화 해야 

 

기타 보안

- Networking : vpc엔드 포인트로 S3에 비공개 액세스가 가능함

- Logging and Audit(로깅 및 감사)

S3 액세스 로그를 사용하면 다른 S3버킷에 해당 로그가 저장됨

API 호출은 CloudTrail과 게정에 API 호출을 로깅할 수 있는 서비스에도 로깅이 가능

- User Security : 

MFA Delete : MFA (Multi factor authentication-멀티 팩터 인증) 삭제를 활성화 하면 특정 버전 객체를 버킷에서 삭제하고 싶은 경우 용이하다.

Pre-Signed URLs : 한정된 시간동안 사용 가능한 AWS의 자격 증명으로 서명된 URL (EX. 유저가 로그인한 서비스로부터 프리미엄 등으로 영상등을 다운로드 받는 경우)

 

 

117. S3 버킷 정책 실습

버킷 메뉴 중 권한으로 들어가서

버킷 정책 쪽에서 EDIT 을 눌러보면

 

JSON 형식 편집기

JSON 으로 정책을 제어할 수 있게끔 나와있는데

여기서 오른쪽 상단의 정책 예제에서는

정책을 만들 수 있는 수 많은 예시들이 있었고

정책 생성기로 들어가면

 

정책 생성기

링크가 열리면서 정책 생성기가 나온다

아마 설정하면 JSON 으로 변환해주는듯

https://awspolicygen.s3.amazonaws.com/policygen.html

AWS Policy Generator

 

일단 따라서 정책을 설정해봣다

정책 타입에는 S3 서비스 말고도 다른 서비스도 있었다

버킷 ARN 을 올릴때 ARN 을 따와서 뒤에 /* 를 붙여줘야 한다고 한다

디렉토리상 버킷 내 모든 파일을 의미함

Action 은 PutObject API 1개만 선택해줬다

 

이 정책이 의미하는 바는

누구든 이 버킷에 객체를 업로드 할 수 없도록 거부한다

는 정책이다.

 

이렇게만 설정하면 버킷에는 무엇도 올릴 수 없으니까 Add Conditions(Optional) 해준다

 

add conditions - 조건

condition 은 null 로 설정

key에 설정한 값은, S3 에 파일을 보낼 때에 이 헤더가 있는지를 확인하게 된다

value 는 true 로 해준다

이 설정의 뜻은, 이 헤더가 Null로 나오면 정책을 실행한다는 것이다. - Null 일때 거부되는 것

 

이제 지금까지 만든 첫번째 문장의 반복을 위한 두번째 문장을 만든다

Add Statement

2번째 문장

Statement 부분은 아까와 같지만

ㅇconditions 부분은 StringNotEquals 에

key 는 똑같이 sse 로 해주고

value 에 AES256 을 넣어줬다

 

이 조건(condition)은 파일이 업로드 되었고, 해더가 있는 경우

그 헤더가 AES256, 즉 SSE-S3 유형의 암호화를 나타내고 있지 않은 경우 이를 거부한다는 내용이다.

 

이후 컨디션을 추가해주고

Generate Policy

Generate Policy 를 해주면

완성된 JSON 문서가 나오고 이를 복사해서 AWS 콘솔로 가져갔다

 

붙여넣기

이렇게 정책을 설정하고

새로운 파일을 다른 정책 설정없이 그냥 업로드하면

업로드를 거부당한다

 

Access Deny

즉 파일을 올릴때 올바른 암호화 설정을 하지 않으면 이처럼 액세스를 거부하게끔 설정한 정책인것

 

karina.jpeg 업로드

암호화 부분에서 정책에 설정한 SSE-S3 (AES-256)으로 설정한 다음 업로드 해보면

 

업로드 성공

업로드가 잘 된다.

 

Block Public Access

퍼블릭 액세스 차단

퍼블릭 액세스 차단 기능은 기본적으로 활성화되어있다.

S3 콘솔의 메뉴에서 버킷 단위가 아닌 계정 단위의 퍼블릭 액세스 차단을 활성화 시킬 수도 있다.

그리고 각 객체로 접근해서 ACL로 객체 수준에서 읽고 쓰는 객체를 정의할 수 도있다.

 

(8.16 끝)

 

(8.18 시작)

 

118. S3 웹사이트

S3는 정적 웹사이트를 호스팅 할 수 있고 www에서 접근이 가능하도록 허용할 수 있음

웹 사이트 URL :

- HTTP 엔드포인트 : <bucket-name>.s3-website-<AWS-region>.amazonaws.com

OR 리전에 따라 <bucket-name>.s3-website.<AWS-region>.amazonaws.com

의 형태

웹사이트를 활성화했으나 설정된 버킷 정책이 없을때는 해당 버킷에 대한 공개 액세스가 가능하며 403 Forbidden 오류가 발생하게 됨

 

실습 - 먼저 이전에 실습했던 버킷 정책을 삭제해주고

 

uproad html file

html 파일 두개를 업로드 해준다

각각 내용은

 

index.html

<html>
    <head>
        <title>My First Webpage</title>
    </head>
    <body>
        <h1>I love coffee</h1>
        <p>Hello world!</p>
    </body>

    <img src="coffee.jpg" width=500/>

    <!-- CORS demo -->
    <!-- <div id="tofetch"/>
    <script>
        var tofetch = document.getElementById("tofetch");

        fetch('extra-page.html')
        .then((response) => { 
            return response.text();
        })
        .then((html) => {
            tofetch.innerHTML = html     
        });
    </script> -->
</html>

 

error.html

<h1>Uh oh, there was an error</h1>

 

 

 

 

static website hosting

버킷 옵션 중 속성 탭에 들어가서

맨아래쪽에 정적 웹 사이트 호스팅을 활성화해주고

버킷에 업로드했던 인덱스 문서와 오류 문서를 넣어준다

 

403 Forbidden

그러면 403 Forbidden 오류가 나는데이는 본 버킷에 액세스가 허용되지 않았음을 의미한다

Block public access 해제

Block Public Access 를 비활성화 해준다이제 일부 객체가 공개로 전환될텐데이후 공개 버킷 정책을 세워줘야 한다.

 

policy generator

정책 생성기로 들어가서

s3 버킷 타입 - allow - * - getobject - 내버킷/*

까지 입력해주고 add statement 해준다

이는 버킷 하위로 접근하는 모두를 허용한다는 내용이다.

 

JSON

이렇게 완성된 JSON 문서를 붙여넣기하고 정책을 생성하게 되면

 

경고

경고문이 뜨는데

퍼블릭 액세스가 그만큼 위험하다는거겠지

 

refresh

새로고침하면 이렇게 뜨는데

index 에 등록해놓은 사진이 coffee.jpg 라서 그런데

내사진으로 바꿔서 다시 해보자

 

성공!

이쁘다

 

해당 url 뒤에 아무 글자나 입력하면 error.html 에 입력한 내용이 나올꺼다

 

 

119. S3 CORS

Cross-Origin Resource Sharing - 교차오리진 리소스 공유

Origin - 체계, 즉 프로토콜이자 호스트. 도메인, 포트이다

- ex) https://www.naver.com  :  scheme-HTTP, host-www.naver.com, port-443 인 Origin 이다

다른 오리진에서 리소스를 얻을 수 있다.

웹사이트는 기본적인 보안으로 CORS 를 가지고 있다.

 

same origin : http://example.com/app1 & http://example.com/app2

같은 오리진이며 첫번째 url 에서 두번째 url로 웹 브라우저 간 요청이 가능하다

different origins : http://www.example.com & http://other.example.com 

다른 오리진이며, 첫번째 url 에서 두번째 url로 요청을 보내면 이를 교차 오리진 요청이라고 하며

이때 올바른 CORS 헤더가 없으면 웹 브라우저가 해당 요청을 차단한다.

CORS Header (ex : Access-Control-Allow-Origin)

 

S3 CORS

클라이언트가 웹사이트로 활성화된 S3 버킷에 대해 교차 오리진을 요청하는 경우 올바른 CORS 헤더를 활성화할 필요가 있다.

*시험에 자주 나옴

전체 오리진 이름을 지정해서 특정 오리진에 대해 허용할 수도 있고 혹은 *를 이용해 모든 오리진에 허용할 수도 있다.

 

 

120. S3 CORS 실습

 

수정된 index.html 파일과 extra.html 파일을 업로드 했다

아까 위의 index.html 파일에서 아래 스크립트 부분 주석을 지우고 업로드 해줬고

 

extra-page.html

<p>This <strong>extra page</strong> has been successfully loaded!</p>

 

파일을 추가로 업로드 해줬다

 

그리고 다른 오리진 생성을 위해서

버킷을 새로 만들어줬다

새로 버킷 생성

버킷을 만들고 정적 웹 호스팅을 활성화 해준 후

block public access 를 모두 비활성화 해줬다

이후에 권한에서 이전 버킷에서 사용한 정책을 긁어와서 arn 만 바꿔줬다.

index.html 이랑 error.html , extra-page.html 도 업로드 해줬다.

 

이후 원래 버킷으로 돌아가서

extra-page.html 객체를 버킷에서 삭제했다

 

그러면 이렇게 아래에 에러가 떳다고 나옴

 

2번째 버킷의 extra-page.html 이 나온 주소를

index.html 의 fetch 에 넣어줬다

index.html

첫번째 버킷의 웹에서 두번째 버킷의 extra-page.html 로 접근하려는 것

 

수정한 index 파일을 메인 버킷에 다시 업로드하고

 

새로고침해보면

 

refrexh

이전에 있었던 에러 문구는 사라지지만

크롬 개발자 도구의 콘솔창에 보면

 

Access to fetch at 'http://demo-yeonwoo-cors-2022.s3-website-ap-northeast-1.amazonaws.com/extra-page.html' from origin 'http://demo-yeonwoo-s3-bucket-2022.s3-website-ap-northeast-1.amazonaws.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

 

이라고 나온다

CORS 정책에 의해 blocked 되었고 requested resource 에 'Access-Control-Allow-Origin' 헤더가 없다고 한다

 

그래서 이제 두번재 버킷에 CORS 정책을 설정해 줘야 한다.

두번째 버킷에 CORS 정책을 설정해 줘서 첫번째 버킷이 요청을 전송할 수 있도록 허용해 주는 것

 

CORS Policy

두번째 버킷의 권한 탭에 들어가서 쭉 내리면

CORS 정책 구성이 나온다.

edit 에 들어가면 JSON 으로만 작성할 수 있는 화면이 나오는데

이렇게 입력 해줬다.

 

두번째 버킷의 CORS 정책 편집

AllowdOrigins 에 첫번째 버킷의 웹주소를 넣어주는데 이때 마지막에 있는 / 는 제외하고 넣어준다.

캡처하고 설정 후 실습해봤는데 안되서 찾아봤더니

이때 맨 뒤에 > 가 들어가있어서 계속 오류가 났었다

 

오류 없이 나오는 모습

CORS 설정 끝

 

 

 

121. S3 일관성 모델

- 2020년 12월 부터 Amazon S3 의 모든 작업은 강력한 일관성을 바탕으로 이루어진다.

 

만약 새로운 객체를 성공적으로 Amazon S3에 작성한 경우 (new PUT)

기존 객체를 덮어쓰거나 삭제하는 경우 (overwrite PUT or DELETE)

언제든 읽기 혹은 쓰기 후 읽기를 수행할 때마다 방금 작성한 객체를 볼 수 있다.

목록을 작성할 대에도 목록 내 항목을 바로 볼 수 있다.

 

이전에는 파일 업로드 혹은 수정 후 바로 읽는게 안됬었나 봄

 

 

 

이후 퀴즈 풀고 끝!

오래걸렸다