145. S3 암호화 - 개요
Amazon S3 - Object Encryption
S3 버킷에서 암호화 하는 4가지 방법이 있다.
SSE - Server Side Encryption
서버 측 암호화로
SSE-S3 : s3 관리형 키를 사용
SSE-KMS: KMS 키를 사용
SSE-C: 고객이 제공하는 키 사용
Client-Side Encryption
클라이언트 측에서 모든 것을 암호화한 다음에 S3에 업로드 하는 것이다.
SSE-S3
aws 에서 처리, 관리 및 소유하는 키로 암호화를 진행
AES-256 보안 유형으로 암호화가 이루어짐.
헤더 "x-amz-server-side-encryption":"AES256"
객체를 전송하면 객체와 암호화 키가 혼합되어 암호화를 진행한 후 버킷에 저장된다.
SSE-KMS
KMS로 자신의 키를 직접 관리하는 방식이다.
사용자가 키를 제어할 수 있다.
KMS 내에서 직접 키를 생성하고 CloudTrail 을 사용해서 사용량을 감시할 수 있다.
KMS 에서 키를 사용하면 AWS 에서 발생하는 모든 일을 기록하는 역할을 담당하는 서비스가 CloudTrail이다.
헤더는 "x-amz-server-side-encryption":"aws:kms" 로 지정
버킷에 객체가 저장된다.
해당 파일을 읽을려면 객체 자체에 대한 액세스 뿐만 아니라 객체를 암호화하는데 사용된 KMS 키에 대한 액세스도 필요하다.
보안이 한 단계 추가되었다.
SSE-KMS Limitation
SSE-KMS 를 사용하면 KMS 제약에 걸린다.
업로드할때 GenerateDataKey KMS API 를 호출한다.
다운로드할때 복호화 KMS API를 호출한다 .
KMS 서비스에 API 호출을 수행해야 하는데 API 호출은 초당 KMS 할당량에 포함된다.
리전에 따라 초당 5,500~30,000 개의 요청을 처리할 수 있지만 서비스 할당량 콘솔로 한도를 늘릴 수 있다.
Service Quotas Console
처리량이 매우 높은 s3 버킷이 있고 모든 파일이 KMS 키로 암호화 되어있다면 스로틀링 오류 등의 사례가 발생할 수 있다. (api 를 너무 많이 호출)
SSE-C
aws 외부에서 키가 관리 된다.
aws 로 키를 보내기 때문에 sse이다.
제공된 키는 저장되지 않고 사용 후 폐기 된다.
오직 HTTPS 통신만 가능
HTTP 헤더에 키를 포함하여 전달해야한다.
Client-Side Encryption
amazon s3 client-side encryption library 로 쉽게 구현할 수 있다.
데이터를 s3로 보내기전 클라이언트가 직접 암호화 해야한다.
데이터를 가져온다면 외부에서 복호화 해야한다.
전송 중 암호화 Encryption in transit (SSL/ TLS)
s3 버킷에는 두 개의 엔드 포인트가 있다.
암호화되지 않은 http 엔드포인트와 전송 중 암호화인 https 엔드포인트
sse-c 매커니즘을 사용할때 https 프로토콜을 사용해야한다.
146. S3 암호화 실습
객체 업로드시 sse 옵션을 설정할 수 있다.
147. S3 기본 암호화
Amazon S3 - Default Encryption vs Bucket Policies
기본 암호화 옵션과 버킷 정책
버킷 정책은 암호화를 강제 할 수 있다. 지정된 암호화 헤더가 없는 S3 객체를 버킷에 넣는 API 호출을 거부하는 등
one way to "force encryption" is to use a bucket policy and refuse any API call to PUT an S3 object without encyption headers
또 다른 방법으로 S3 에서 '기본 암호화 옵션' 을 활성화 시킬 수 있다.
객체가 암호화되지 않은 채로 업로드 되더라도 업로드된 후에 s3에 의해 암호화 된다.
버킷 정책은 항상 기본 암호화 전에 평가된다.
bucket policies are evaluated before "default encryption"
148. S3 CORS - 개요
Cross-Origin Resource Sharing (CORS)
Origin = Scheme(protocol) + host(domain) + port
오리진은 프로토콜, 호스트, 포트로 구성
https 포트는 443,
프로토콜은 http 자체
도메인은 example.com
CORS는 웹 브라우저 기반 보안 매커니즘으로 메인 오리진을 방문하는 동안 다른 오리진에 대한 요청을 허용하거나 거부한다.
오리진이 같다는것
프로토콜, 호스트, 포트 가 동일함을 뜻함.
웹브라우저가 한 웹사이트를 방문하는 동안 요청 체계의 일부로 다른 웹사이트에 요청을 보내야 할 때 다른 오리진이 CORS 헤더를 사용해서 요청을 허용하지 않는 한 해당 요청은 이행되지 않는다.
The requests won't be fulfilled unless the other origin allows for the requests, using CORS Header ( example: Access-Control-Allow-Origin)
웹브라우저에서 오리진 방문
www.example.com 이 www.other.com 으로 부터 사진을 가져와야한다면?
오리진에 방문하고 다른 오리진으로 요청을 보낸다
웹브라우저는 다른 오리진으로 preflight 요청을 보낸다.
preflight 응답을 통해서 권한을 확인하고
다른 오리진으로부터 파일을 받는다.
S3 - CORS
만약 클라이언트가 교차 오리진 요청을 s3 버킷에 할려면 정확한 cors 헤더를 활성화해야한다.
특정 오리진을 허용하거나 * 별표를 붙여 모든 오리진을 허용한다.
149. CORS 실습
150. S3 MFA Delete - 개요
S3 에서 무슨 작업을 실행할때 해당 코드를 입력해야한다.
MFA 가 필요한 작업
영구 삭제에 대한 보호 설정
버킷에서 버저닝을 중단할 때
비권장
버저닝 활서오하나 삭제된 버전 나열하는 작업은 굳이 MFA 를 쓸필요가 없다.
mfa delete를 사용할려면 버킷 버저닝을 활성화
루트 계정만이 MFA Delete 활성화, 비활성화 할 수 있다.
only the bucket owner can enable/disable MFA Delete
151. S3 MFA Delete 실습
152. S3 액세스 로그 개요
S3 Access Logs
감사 목적으로 S3 버킷에 대한 모든 액세스를 기록할 수 있다.
S3 로 보낸 모든 요청은 승인 또는 거부 여부와 상관없이 다른 S3 버킷에 파일로 기록된다.
해당 데이터는 Amazon Athenea 같은 데이터 분석 도구로 분석할 수 있다.
대상 로깅 버킷은 같은 aws 리전에 있어야한다.
클라이언트 -> 버킷 -> 로깅 버킷
S3 Access Logs 주의 사항
절대로 로깅 버킷을 모니터링하는 버킷과 동일하게 설정하지 마세요
Do not set your loggin bucket to be the monitored bucket
무한 반복되어 버킷의 크기가 기하 급수적으로 증가하게 된다.
객체를 넣었는데 앱 버킷과 로깅 버킷이 동일하면 로깅 루프가 생겨 로그를 반복적으로 기록하게 된다.
요금 폭탄이다. 하지마!
153. S3 액세스 로그 - 실습
154. S3 사전 서명된 URL - 개요
Amazon S3 - Pre-Signed URLs
S3 콘솔, CLI , SDK 를 사용하여 생성할 수 있는 URL 이다.
URL 만기기간
S3 콘솔 - 1min~ 720min 12hr
AWS CLI - 168 hr
미리 서명된 URL 을 생성할 때 URL 을 받는 사용자는 URL을 생성한 사용자의 GET, 또는 PUT 에 대한 권한을 상속한다.
버킷이 있고 버킷 소유자가 있다.
버킷 소유자가 파일을 공유 하고 싶으면 미리 성명된 URL 을 생성한다.
S3 버킷이 URL 을 제공한다.
제3의 사용자는 해당 URL을 통해 S3 버킷에 접속해 파일에 액세스한다.
EX
제한 시간에 프리미엄 동영상을 제공하는 링크
일시적으로 사용자가 S3 버킷의 특정한 위치에 파일을 업로드하도록 허용할 수 있다.
155. S3 사전 서명된 URL - 실습
share with presigned URL
만기 시간을 지정할 수 있다.
156. S3 잠금 정책 및 Glacier 볼트 잠금
S3 Glacier Vault Lock
WORM (write once Read Many) 모델을 채용한다.
객체를 가져와서 S3 볼트에 넣은 다음 수정하거나 삭제할 수 없도록 잠그는 것이다.
1. 볼트 잠금 정책 생성 Create a Vault Lock Policy
2. 향후 편집을 위해 정책을 잠금 Lock the policy for future edits
( 일단 볼트 잠금 정책을 설정하고 잠근 후에는 누구도 변경하거나 삭제할 수 없게 된다. )
규정 준수와 데이터 보존에 아주 유용하다.
Helpful for compliance and data retention
객체가 glacier 볼트에 삽입되면 볼트에 볼트 잠금 정책이 적용되어 있으므로 객체를 절대로 삭제할 수 없다.
S3 Object Lock ( versioning must be enabled)
s3 객체 잠금을 활성화하려면 먼저 버저닝을 활성화 해야한다.
WORM 모델 채택
객체 잠금은 전체 S3 버킷 수준의 잠금 정책이 아니라
버킷 내의 모든 객체에 각각 적용할 수 있는 잠금이다 .
S3 객체 잠금을 사용하면 특정 객체 버전이 특정 시간 동안 삭제되는 걸 차단할 수 있다.
두 가지 보존 모드
규정 준수 모드 Retention mode - Compliance
사용자를 포함한 그 누구도 객체 버전을 덮어쓰거나 삭제할 수 없다.
누구도 객체를 변경할 수 없다.
보존 모드 자체도 변경할 수 없다. 보존 기간도 단축 불가
거버넌스 보존 모드 Retention mode - Governance
대부분의 사용자는 객체 버전을 덮어쓰거나 삭제하거나 로그 설정을 변경할 수 없다.
하지만 관리자 같은 일부 사용자는 IAM 을 통해 부여받은 특별 권한으로 보존 기간을 변경하거나 객체를 바로 삭제할 수 있다.
보존 기간 설정 Retention Period
고정된 기간 동안 객체를 보호할 수 있고 원하는 만큼 기간을 연장할 수 있다.
법적 보존 Legal Hold
S3 버킷 내 모든 객체를 무기한으로 보호한다.
재판에 사용될 정도로 중요함.
s3:PutObjectLegalHold IAM 권한을 가진 사용자는 어떤 객체에든 법적 보존을 설정하거나 제거할 수 있다.
157. S3 Access Points 와 Object Lambda
S3 - Access Points
IAM 그룹이 3개, S3 버킷이 각각 3개 있다고 가정하자
버킷 정책을 만들어서 어떤 그룹이 접속할 수 있는지 정할 수 있는데
그룹, 버킷이 많아 질수록 복잡해지고 관리하기 힘들어진다.
대신 버킷 마다 액세스 포인트를 만들어 정해진 그룹은 해당 액세스 포인트 접속을 허용하게 만든다.
S3 버킷 앞에 하나의 계층이 추가되었다고 볼 수 있다.
각 액세스 포인트마다 고유의 DNS 와 정책이 있다.
액세스 포인트마다 하나의 정책만 가지므로 복잡하고 고유한 버킷 정책보다 훨씬 다루기 쉽다.
S3 Object Lambda
람다의 사용 목적은 S3 버킷의 객체를 호출한 애플리케이션이 회수하기 전에 수정하기 위함이다.
Use AWS Lambda Functions to change the object before it is retrieved by the caller application
예를 들어 각 객체를 다른 버전으로 만들기 위해 버킷을 복사하는 대신 S3 객체 람다를 사용하는 것이다 .
이를 위해서 S3 액세스 포인트가 필요하다.
S3 버킷으로 부터 데이터를 가져와 람다를 실행하고 액세스 포인트를 생성한다.
usage
분석이나 비프로덕션 환경을 위해 개인 식별 정보와 같으 PII 데이터를 삭제하는 겨웅
xml 에서 JSON 으로 데이터를 변환 하거나
원하는 변환을 실행하는 경우
이미지 크기를 바꾸거나 워터마크를 남긴다 .
