AWS Certified Developer Associate - S3
Udemy
AWS
AWS Certified Developer Associate
S3
12/17/2020
포스팅에 포함된 모든 슬라이드의 출처는 Stephane Maarek의 Udemy 강의입니다. 혹시 틀린 설명이 있을 경우 댓글로 남겨주시면 감사하겠습니다.
S3
Bucket
에 Object
(파일)를 보관하는 서비스
Bucket은 region 종속적이지만, globally unique name을 가져야 한다.
Bucket의 naming convention은 다음과 같다.
- 대문자를 사용하지 않음
- 언더스코어(_)를 사용하지 않음
- 3-63자 길이
- IP가 아니어야 함
- 소문자나 숫자로 시작해야함
Object(files)
Object는 Key를 가지고 있으며, Key는 버킷 내에서 해당 파일의 FULL PATH를 의미한다.
예를 들어, my-bucket이라는 이름의 Bucket내부에 my_file.txt가 있다고 하면, 해당 파일의 경로는 다음과 같이 표시할 수 있다.
S3://my-bucket/my_folder1/another_folder/my_file.txt
- 이 때, my-bucket/ 이하의 full path를 Key라고 일컫는다.
- Key는 prefix와 object name으로 이루어져있다. 따라서 위의 경로에서..
- Key :
my_folder1/another_folder/my_file.txt
- prefix :
my_folder1/another_folder/
- object_name : 'my_file.txt'
- Key :
Object 구성
value
: body의 내용물- 단일 Object의 최대 저장 가능 사이즈는 5TB(5000GB)
- 만약 단일 PUT의 용량이 5GB를 넘어가면, multi-part upload를 사용해야한다.
- Multi-part Upload는 5MB부터 5TB의 경우까지 사용할 수 있다.
- 버킷 자체에는 용량 제한이 없다(infinity)
meta-data
: 시스템이나 유저 정보에 관한 키값 쌍 리스트tags
: 최대 10개까지 저장할 수 있는 유니코드 키값 쌍. 보안이나 라이프사이클에 유용하다.- 'version ID' : 버져닝이 활성화되어있을 경우에 존재한다
Versioning
Bucket 레벨에서 Versioning 옵션을 활성화 할 수 있다.
Versioning 옵션이 켜져 있을 경우, 동일한 파일을 저장할 때 그대로 덮어씌워지는 것이 아니라 1,2,3 씩 변경사항을 적용시킨 버전을 모두 보관해둔다.
버킷 Versioning을 설정 해놓는 것이 best practice.
- 의도치 않게 삭제하는 것을 방지할 수 있다(버전 복구 기능을 이용하면 된다)
- 이전 버전으로 롤백이 쉽다.
Object 암호화
S3의 Object를 암호화하는 방식은 총 4가지가 있다.
- SSE-S3 : AWS에 의해 관리/핸들링 되는 키(S3 Managed Data Key)를 사용해 암호화하기
- SSE-KMS : 암호화 키 관리에
AWS Key Management Service
이용하기 - SSE-C : 직접 암호화 키를 관리하고 싶을 때
- Client Side Encryption
상황에 맞추어 네 가지 방식을 적절히 사용하는 것이 중요하다.
SSE-S3
암호화에 S3 Managed Data Key를 이용한다.
- 서버 사이드 암호화
- AES-256 암호화 알고리즘 사용
- HTTP 헤더에
"x-amz-server-side-encryption" : "AES256"
을 붙여야 한다.
각 오브젝트는 unique한 데이터 키로 암호화되며, 이 데이터키는 정기적으로 교체되는 마스터키가 암호화한다. S3 자체적으로 생성하는 키들.
SSE-KMS
암호화에 KMS의 키를 이용한다.
- 다른 계정의 KMS master key를 사용할 수도 있다(ARN을 입력하면 된다)
- 장점 : 키 유저를 컨트롤할 수 있고, 감사 추적(audit trail)이 가능하다.
- 감사 추적이란, 리소스 사용에 따라 기록된 사용 내역을 의미한다.
- 서버사이드 암호화
- HTTP 헤더에
"x-amz-server-side-encryption" : "aws:kms"
을 붙여야 한다.
SSE-KMS의 aws/s3 key 옵션은 SSE-S3 방식과 다르다.
KMS는 customer master key(CMKs)
라고 불리는, KMS가 생성한 키를 이용하여 S3를 암호화한다.
따라서 마스터 키를 사용할 수 없다.
모든 키의 사용과 관리가 KMS를 통해 중앙적으로 제어되므로, audit과 logging 등도 가능하다. 자세한 내용은 S3 Data Protection 관련 블로그 글을 참조한다.
SSE-C
AWS 외부의 Customer가 관리하는 데이터 키를 이용한다.
- 서버사이드 암호화
- S3는 Customer가 제공하는 키를 저장하지 않는다(저장하면 보안사고..)
- 통신 중 키가 탈취되지 않도록 보안에 유의해야 하므로 반드시 HTTPS를 사용한다.
- 암호화 키가 매 HTTP요청마다 헤더에 붙어야한다.
Client Side Encryption
Customer가 직접 Amazon S3 Encryption Client
같은 클라이언트 암호화 라이브러리를 이용한다.
- S3에 파일을 올리기 전에 암호화 해야한다.
- S3에서 파일을 내려받은 이후 복호화 해야한다.
- Customer가 키와 암호화 사이클을 완전히 관리한다.
- HTTP/HTTPS를 모두 사용할 수 있다(이미 암호화 된 파일이므로)
전송 암호화(SSL/TLS)
S3는 다음과 같은 엔드포인트 선택지를 제공한다.
- HTTP endpoint : 암호화되지 않음, public
- HTTPS endpoint : 전송 중 암호화 처리 --> Encrpytion in flight은 SSL/TLS라고도 불린다.
둘 중 어느것을 사용해도 되지만, HTTPS 엔드포인트를 사용하는것이 권장된다.
대부분의 클라이언트들은 HTTPS 엔드포인트를 디폴트로 사용하고 있다.
또한, SSE-C에서는 HTTPS 엔드포인트만을 사용할 수 있다.
S3 Security
- User based
- IAM policy - IAM policy로 특정 User가 S3에 접근하는 것을 허용
- Resource based
- Bucket Policies - S3 콘솔에서 bucket단위로 통하는 룰 --> cross account를 허용한다!
- Object Access Control List (ACL) - 각 Object에 대하여 Access Rule을 설정하는 것(finer grain)
- Bucket Access Control List (ACL) - Bucket에 대하여 Access Rule을 설정하는 것(less common)
이 때, 다음과 같아야만 IAM principal이 S3 오브젝트에 접근할 수 있다.
- 유저 IAM permission에서 이를 허용 OR 리소스 policy가 이를 허용
- AND 해당 유저에 대한 명시적인 bucket policy DENY가 없어야 한다.
S3 Bucket Policies
S3 버킷 폴리시는 다음과 같은 이유로 사용한다.
- 버킷에 대한 public access를 허용하기 위하여
- 오브젝트가 업로드될 때 암호화하도록 강제하기 위하여
- 다른 계정의 액세스를 허용하기 위하여(Cross Account)
JSON based polices의 구성
- Resources : 버킷과 오브젝트
- Actions : Allow 또는 Deny에 대한 API Set
- Effect : Allow 또는 Deny
- Principal : 해당 policy를 적용할 계정이나 유저
Bucket settings for Block Public Access
버킷에 대한 Public Access를 막는 세팅은 총 4 종류가 있다.
- 버킷과 오브젝트에 대한 퍼블릭 액세스를 모두 막되,
- new access control list(ACLs)의 방식만 허용
- any access control list(ACLs)의 방식만 허용
- new publick bucket 또는 access point policies만 허용
- any public bucket 또는 access point policies로 버킷과 오브젝트에 대한 public, cross-acount access 막기
그 외에..
- Networking : VPC 엔드포인트를 지원함(인터넷을 통하지 않은 인스턴스끼리의 통신)
- Logging and Audit
- Access Log를 다른 S3 버킷에 저장할 수 있음
- API 콜은
AWS CloudTrail
에 저장될 수 있음
- User Security
- MFA Delete: 버져닝된 버킷에서 오브젝트를 지울때 MFA를 요구하도록 설정할 수 있음
- Pre-Signed URLs : 한정된 시간동안만 유효한 URL 생성 가능(ex - 로그인 유저에게 서비스되는 프리미엄 비디오 같은 경우)
S3 Websites
S3로 정적 웹사이트를 호스팅하고, 인터넷에서 접속 가능하게 만들 수 있다.
URL은 아래의 둘 중 하나의 방식으로 구성된다.
<bucket-name>.s3-website-<AWS-region>.amazonaws.com
<bucket-name>.s3-website.<AWS-region>.amazonaws.com
CORS
Origin은 scheme(프로토콜), host(도메인), port를 의미한다.
예를 들어 https://www.example.com
이라는 URL은 다음과 같은 Origin 정보를 내포하고 있다.
- 프로토콜 : HTTPS
- 호스트 : example.com
- 포트 : 443(HTTPS)(, 80(HTTP))
CORS(Cross-Origin Resource Sharing)는 다른 Origin에서 Resource를 공유하려고 시도했다는 뜻이다.
웹브라우저는 기본적으로 main origin 내에 있는 다른 origin만 방문 할 수 있도록 보안처리(Web-based Security)되어있다.
- 같은 origins의 예시 : http://example.com/app1 & http://example.com/app2
- 다른 origins의 예시 :
http://www.example.com
&http://other.example.com
한 Origin이 request를 보냈을 때,
다른 Origin이 CORS header(ex:Access-Control-Allow-Origin)를 이용한 request를 allow하고 있어야만 받아들여진다.주의할 점은,
요청을 보내는 쪽의 버킷이 아니라,
Consistency Model
- S3 내에서, 오브젝트의 PUT(write, 업로드)가 끝나야만 GET(read)을 할 수 있다.
- 새로운 오브젝트가 write되면, retrive할 수 있다.
- ex) PUT 200 -> GET 200
- 만약 object가 exist(write 완료)한 것을 확인하기 전에 GET요청을 한다면, retrive가 정상적으로 되지 않는다.
- ex) GET 404 -> PUT 200 -> GET 404
- 이를
eventually consistent(결과적,최종적 일관성)
라고 한다.
- 새로운 오브젝트가 write되면, retrive할 수 있다.
- 이미 존재하는 오브젝트에 대한 DELETES, PUTS의
Eventual Consistency
- 오브젝트를 업데이트한 후에 읽으려면, 구 버전의 오브젝트를 삭제해야한다
- ex) PUT 200 -> PUT 200 -> GET 200(이럴 때 구버전을 GET하는 경우가 생긴다)
- 오브젝트를 삭제하더라도, 잠시동안은 retrive할 수 있다
- ex) DELETE 200 -> GET 200
- 오브젝트를 업데이트한 후에 읽으려면, 구 버전의 오브젝트를 삭제해야한다