Amazon S3
in AWS CDA
Buckets
- 버켓에 files 저장 가능
- 버켓은 globally unique name 가짐
- Region level에서 저장 –> 버켓은 리전에 묶임
Objects
key 를 가진다. key는 full path(key는 prefix와 object name) 를 말한다.
Naming convention
No uppercase No underscore 3-63 characters long Not an IP Must start with lowercase letter or number버켓에 디렉토리가 있게 보이게 한다.
object value는 바디의 컨텐츠다.
5GB 이상 업로드시에 multi-part upload 사용해야한다. (Max Object Size is 5TB (5000GB))
Metadata (list of text key / value pairs – system or user metadata)
Tags (Unicode key / value pair – up to 10) – useful for security / lifecycle
버전 트래킹이 되어있으면, 버전 ID
버킷에 사진 넣으면 object URL 뜬다. 근데 이걸 주소창에 복붙해도 접근할 순 없다. private이기 때문에.
S3 Versioning
파일, 버젼 가능. 근데 버킷 레벨에서 가능하다.
이름같은 걸 재업로드하면, override 할 것이다. 근데 진짜 override 하는게 아니라 새 버전 파일을 만드는 것이다. 그리고 version restore 할 수 있다.
S3 Encryption for objects
네가지 방법 있다.
1) SSE-S3 : 아마존 s3에서 관리하는 키 이용. AES-256
2) SSE-KMS : KMS 서비스에서 관리하는 키 이용
3) SSE-C : 보안 키를 직접 관리하고 싶을 때
4) Client Side Encryption
SSE-S3
헤더에 “x-amz-server-side-encryption”: “AES256” 이게 있어야한다.
아마존 S3에서 관리되는 키를 사용해 보안
서버 사이드에서 보안이 된다. HTTP/S 에 헤더에 “x-amz-server-side-encryption”: “AES256” 이게 있으면, 서버사이드에서 object가 s3에서 관리되는 data key를 만나 보안되어 버켓으로
SSE-KMS
- KMS에서 관리되는 키를 사용해 보안
- 헤더에 “x-amz-server-side-encryption”: “aws:kms” 이게 있어야한다.
- 서버 사이드에서 보안이 된다. HTTP/S 에 헤더에 “x-amz-server-side-encryption”: “aws:kms” 이게 있으면, 서버사이드에서 object가 KMS에서 관리되는 data key를 만나 보안되어 버켓으로
SSE-C
- AWS 에서 말고,고객쪽에서 관리되는 데이터 키로 서버사이드에서 보안
- AWS S3는 내가 제공한 보안 키를 저장하지 않는다.
- HTTPS가 꼭 이용되어야한다.
- HTTP헤더에 보안키가 꼭 제공되어야한다. 모든 HTTP 요청에…
Client Side Encryption
- Amazon S3 Encryption Client와 같은 클라이언트 라이브러리 사용
- S3에 보내기 전에 클라이언트가 직접 암호화시켜야한다.
- S3에서 조회할 때 클라이언트가 데이터를 암호 해독을 해야한다.
- 키와 보안 사이클을 고객이 전적으로 담당한다.
Encryption in transit
S3는 HTTP endpoint(보안x) 와 HTTPS endpoint(보안 SSL/TLS에 노출된다. HTTPS가 권장이긴하다.(단 SSE-C는 꼭 HTTPS)
SSL
TLS
S3 Security
User Based
IAM policies (앞서 배운것.. )
Resource Based
bucket policies
object Access Control List(ACL) - finer grain (나중 확인)
Bucket Access Control List (ACL) – less common
사용자 IAM 퍼미션이 허용하거나, 리소스 정책이 허용하고, 명시적인 거절이 없으면 IAM principal 이 S3 object 접근 가능하다. (IAM principal 이 뭔데? 나중에 체크)
S3 Bucket Policies
JSON based policies
• Resources: buckets과 objects
• Actions: API가 Allow 혹은 Deny 할 수 있게 한다.
• Effect: Allow / Deny
• Principal: 사용자나 어카운트에 정책 적용
Bucket settings for Block Public Access
object나 bucket에 public 접근 막기위해.
new access control lists (ACLs)
- any access control lists (ACLs)
- new public bucket or access point policies
object나 bucket에 public, cross-account 접근 막기위해
회사 데이터가 유출되는 것을 막기 위해 만들어진 세팅
S3 Security - Other
Networking:
Supports VPC Endpoints ( 예시/ in VPC without www internet) private하게 연결 가능하다.
Logging and Audit
S3 Access Logs can be stored in other S3 bucket
API calls can be logged in AWS CloudTrail
User Security
MFA Delete: MFA (multi factor authentication) can be required in versioned buckets to delete objects • Pre-Signed URLs: URLs이 제한적 시간내에만 유효한 것.
S3 Websites
: static website 를 host 할 수 있다. www 로 접근 가능
• <bucket-name>.s3-website-<AWS-region>.amazonaws.com
• <bucket-name>.s3-website.<AWS-region>.amazonaws.com
: 403 forbidden 에러 일어나면, 버켓 policy에서 public reads 허용해준다.
CORS (Cross Origin Resource Sharing)
1. 웹 브라우저가 다른 오리진에 preflight request를 보낸다. (origin: 내 도메인)
2. 그 오리진 헤더에 allow origin 으로 내 도메인이 있으면 preflight response로 답한다.
3. get/put...으로 정보를 요청한다.
4. 정보를 웹브라우저에 준다.
: CORS 헤더가 중요하다. 이게 없으면, 다른 오리진에 리퀘스트 안 받아들여진다.
• Same origin: http://example.com/app1 & http://example.com/app2
• Different origins: http://www.example.com & http://other.example.com
Amazon S3 - Consistency Model
- : amazon s3는 여러개의 서버로 만들어져 있다. 그래서 S3에 어떤 걸 쓰면, 다른 서버가 복제한다. 그래서 different consistency issue에 봉착한다.
새로운 것을 쓰자 마자 조회할 수 있다. ex) PUT 200 => GET 200 (put하자마자 다른 서버에서 get한다는 뜻 같음..)
- 아 만약 GET404를 먼저 하면, PUT 해도 다음에 GET404뜬다 ex: (GET 404 => PUT 200 => GET 404)
- 만약 GET404 먼저 안했으면 PUT 200 ==> GET 200이렇게 스무스하게 갔을 텐데. 아마 캐싱때문에 그런가?
업로드 후 바로 읽으면, older version get할 수 있다. (맨날 그럼 내 홈페이지는..)
객체 삭제를 하면, 짧은 시간동안은 조회 가능할 수 도 있다.ex: (DELETE 200 => GET 200)
