[AWS] Amazon S3 (3)

Object Encryption

• 암호화 종류

1. SSE (Server-Side Encryption)
   • SSE-S3 : Amazon S3에서 관리하는 키를 이용 (default)
   • SSE-KMS : KMS 키를 이용하여 암호화 키 관리
   • SSE-C : 고객이 제공한 키 사용 (client에서 키 제공)
2. CSE (Client-Side Encyption) : 클라이언트 측의 모든 걸 암호화한 다음에 S3에 업로드
   
   
   

• SSE-S3

1. AWS가 처리/관리/소유하는 키를 이용 (사용자가 접근할 수 없음)
2. Encryption Type : AES-256
3. request header에 "x-amz-server-side-encryption":"AES256" 설정 필요

• SSE-KMS

1. KMS (키 관리 서비스)를 이용해서 client가 자신의 키를 직접 관리 -> 사용자가 통제 가능 -> KMS에서 신규 키 생성 가능
2. CloudTail (AWS 로깅 서비스) 이용하여 키 사용을 검사할 수 있음
3. request header에 "x-amz-server-side-encryption":"aws:kms" 설정 필요

• SSE-KMS 제한사항
  • S3에 KMS키 활용 암호화된 Object를 업로드하고 다운로드하기 때문에 사용자가 직접 KMS키를 사용해야 함
  • 복호화 : KMS 키의 자체 API인 GenerateDataKey를 활용하여 Object를 복호화 함
  • 복호화 시, KMS API 호출 건은 초당 API 호출에 합산됨 (region마다 다르지만 초당 API 호출에 제한이 있음) -> 쓰로틀링 발생 가능성 있음

• SSE-C

1. 외부에서 관리되는 키 사용 (client가 서버로 해당 키 전송)
2. AWS에서는 해당 키를 저장하지 않음
3. 반드시 HTTPS를 이용하여 요청해야 함

• CSE (Client-Side Encryption)

1. 클라이언트가 직접 데이터를 암호화한 다음에 Amazon S3에 전송하는 방식 (복호화도 마찬가지)
2. 클라이언트측 암호화 라이브러리를 활용한다면 쉽게 구현 가능

• SSL/TLS (전송 중 암호화)

1. S3에는 HTTP/HTTPS 두 개의 endpoint 존재 (HTTPS endpoint에서 전송 중 암호화 제공)
2. HTTPS 권장
3. 강제화 방법 : Bucket 정책 활용
   • Bucket Policies를 활용하여 암호화를 강제하고 올바른 암호화 헤더가 없는 경우에는 S3 API호출을 거절할 수도 있음

CORS

• CORS : Cross-Origin Resource Sharing, 웹 브라우저 기반 보안 메커니즘
  
  
  

• 작동 원리

1. origin : scheme (protocol) + host (domain) + port (ex. https://www.example.com)
2. 메인 origin에서 다른 origin에 대한 요청을 허용하거나 거부
   • same origin : http://example.com/app1 = http://example.com/app2
   • defferent origin : http://www.example.com != http://other.example.com
3. 웹 브라우저가 main origin에 접속한 상태에서 다른 origin으로 요청해야하는 상황일 때, 다른 origin에서 CORS헤더(Access-Control-Allow-Origin) 허용을 하지 않는 이상 요청이 전달되지 않음 (ex. 웹 브라우저가 front 서버에 접속한 상태에서 back 서버에 요청을 보내야 할 때, front서버 origin != back서버 origin)
   
   
   

• 예제

1. 웹 브라우저가 https://www.example.co(main origin)에 요청하여 index.html을 받아옴
2. 받아온 index.html에서 https://www.other.com(cross origin)에 file을 요청
3. cross origin에 main origin 값을 실어 사전요청을 보냄
4. cross origin에서 CORS를 허용했다면, main origin으로부터 GET/PUT/DELETE 호출을 허용
5. 웹 브라우저에서 cross origin에 파일을 요청하여 받아옴

• S3에 적용한다면, S3는 cross origin으로서 CORS 허용 필요 (permissions - CORS 에서 JSON 형식으로 설정 가능)

MFA Delete

• MFA Delete : S3상에서 중요한 작업을 진행할 때, 특정 Device(ex. Google Authenticator, MFA Hardware Device 등)에서 생성한 코드를 통한 인증을 강제화 하는 것
  
  
  

• object의 특정 version을 삭제하거나, versioning 옵션을 중단할 때 두 가지 경우에 주로 사용됨

• MFA 활용을 위해서 Bucket Versioning을 활성화해야 함

• Bucket소유자(root 계정)만 활성화할 수 있음

• MFA Delete 활성화는 CLI를 통해서 가능

• MFA Delete가 활성화된 상태에서 객체 버전 삭제를 할 경우, CLI를 통해서 MFA Delete를 비활성화한 후에 삭제 진행해야 함
  
  
  

S3 Access Logs

• S3 Access Logs : S3 Bucket에 접근한 모든 case는 다른 S3 Bucket에 log로 저장
  
  
  

• Amazon Athena와 같은 데이터 분석 도구로 분석 가능

• logging bucket은 같은 region내에 있어야 함 -> 같은 region내에 Bucket 생성 후 logging되도록 설정하면 됨

• properties -> Server access logging 설정 -> Enable -> log가 저장될 bucket 선택 -> bucket 정책 자동 현행화
  
  
  

• 주의사항 : 로깅 버킷과 모니터링 버킷을 동일하게 설정x -> 로깅 loop가 생성되어 로깅이 무한반복됨

Pre-Signed URLs

• Pre-Signed URLs : URL에 private bucket의 특정 object에 public하게 접근할 수 있는 권한을 부여 -> URL을 받는 사용자는 생성한 사용자에게 GET/PUT권한을 상속받음 -> 외부의 사용자에게 특정 Object에 대한 권한을 부여해야할 때 사용
  
  
  

• Console, CLI, SDK에서 생성 가능

• Object actions -> share with presigned URL

• 만료시간

1. Console : 최대 12시간
2. CLI : 최대 168시간

• use cases

1. 로그인한 유저에게만 파일을 다운로드할 수 있게끔 함
2. 사용자 list가 계속 변하는 경우, url을 동적으로 생성하여 권한 부여 지속
3. 일시적으로 외부 사용자가 bukcet에 접근해야할 경우

Glacier Vault Lock

• Glacier Vault Lock : Worm(Write Once Read Many) 모델 적용을 위해 활용, 한번 Glacier Vault에 Object를 넣으면 수정/삭제가 불가하도록 lock을 걸어버림 (관리자나 그 누구도 삭제를 못함) -> 규정준수나 데이터 보존에 유용
  
  
  

• Glacier에 Vault lock policy 설정 -> 더이상 정책을 변경할 수 없도록 해당 정책을 lock
  
  
  

S3 Object Lock

• 특징

1. Bucket 전체 대상의 lock이 아닌 Bucket 내 Object에 개별적으로 lock 가능
2. 특정 Object의 특정 version이 특정 시간동안 삭제되는 것을 막을 수 있음
3. Object Lock 활성화를 위해서 Versioning 활성화 필요
4. Worm(Write Once Read Many) 모델 적용
5. 법적 보존 모드 설정을 통해 모든 Object를 무기한으로 보존 가능 -> s3:PutObjectLegalHold IAM 권한을 가진 사용자는 법적 보존 모드 설정 및 삭제 가능
   
   
   

• Retention mode

1. Compliance mode
   • Glacier Vault Lock과 유사
   • 사용자 그 누구도 수정/삭제 불가
   • Retention mode도 변경 불가
2. Governance mode
   • 좀 더 유연성이 필요할 때 사용
   • 대부분의 사용자가 수정/삭제 불가
   • IAM을 통해 권한을 부여받은 사용자는 Object의 보존기간을 변경하거나 바로 삭제할 수 있음

• 두 가지 모드 모두 Object 보존기간 설정 필요
  
  
  

S3 Access Points

• 사용자와 데이터가 많아질 수록 Bucket 정책 등 관리가 까다로워짐 -> Access Points 활용 -> S3 Bucket에 접근하기 위한 다양한 방법 정의

• 특정 S3 Bucket prefix에 대한 Access Points를 생성하고, 해당 point에 prefix에 맞는 Bucket policy 설정 (용도에 따라 단일 Access points에 다수의 prefix를 연결하는 policy 설정 등 가능)
  
  
  

• 특징

1. 각 Access Points는 각각 특정 DNS를 가짐
2. Access Point는 public 인터넷이나 private VPC에 연결될 수 있음

• private VPC -> S3 Access point : VPC에 endpoint를 생성하면 VPC 내부의 EC2 인스턴스는 해당 endpoint에 정의되어 있는 VPC policy에 맞게 S3 Access point로 접근하게 되고, 해당 Access point의 정책에 맞게 Bucket내 데이터에 접근할 수 있게된다. -> 결론적으로 VPC endpoint policy, S3 Access point policy, Bucket policy 세 가지 보안 정책 설정이 필요함

S3 Object Lambda

• S3 Object Lambda : S3 Bucket에 호출하여 Object를 받기 전에 해당 Object를 수정하려는 경우에 사용
  
  
  

• 특징

1. S3 Access point 사용 필요
2. S3 Bucket 외의 Access point를 생성하여 Lambda function에 연결될 수 있도록 설정 -> S3 Lambda Access point를 생성하여 특정 application으로 Lambda의 처리 결과본 전달 -> 결과적으로 특정 application은 Lambda access point를 통해 Lambda를 호출하여 S3 Access point를 통해 S3 객체를 가져오고, 해당 객체를 Lambda function이 수정하여 다시 Lambda access point를 통해 application으로 전달
3. Object 수정본을 위한 Bucket을 생성하여 별도의 버전을 관리할 필요 없음