AWS 보안

s3버킷 내 객체를 암호화 하는 방법은 네가지 있다,

1. SSE 서버측 암호화

• SSE-S3 : Amazon S3 관리형 키를 사용하는 서버측 암호화인 SSE-S3
• SSE-KMS : KMS키를 사용해서 암호화 키를 관리하는 SSE-KMS가 있다. 
• SSE-C : 고객이 제공하는 키를 사용하는 SSE-C 이 경우 스스로 암호화 키를 제공해야함

2. 클라이언트 측 암호화

클라이언트 측에서 모든 것을 암호화 한 다음에 아마존 S3에 업로드 하는 것이다.

SSE-S3 

이 경우 AWS 처리, 관리 및 소유하는 키로 암호화를 진행한다. 

사용자는 이 키에 접근할 수 없다. 객체는 AWS에 의해 서버 측에서 암호화 되고 AES-256유형으로 암호화가 이루어진다.

따라서 헤더를 x-amz-server-side-encryprtion : AES256으로 설정해서 SSE-S3메커니즘으로 객체를 암호화 하도록 Amazon S3에 요청 해야한다. 그럼 업로드 된 객체와 s3가 가지고있는 키를 조합해 암호화 시킨다.

 

SSE-KMS

KMS로 자신의 키를 직접 관리하는 방식이다. KMS를 사용하면 사용자가 키를 제어할 수 있느다는 장점이 있다.

KMS내에서 직접 키를 생성하고 CloudTrail을 사용해서 사용량을 감시할 수 있다, 누군가 KMS에서 키를 사용하면 AWS에서 발생하는 모든 일을 기록하는 역할을 담당하는 것이 cloudtrail이다.

 

헤더는 x-amz-server-side-encryption: aws: kms로 지정해야한다. 그러면 서버에서 객체를 암호화한다.

업로드 하면 업로드 된 객체와 AWS의 KMS에서 가져온 키를 조합해 암호화 시킨다.

이 때는 S3버킷에서 해당 파일을 읽으려면 객체 자체의 액세스 뿐만 아니라 KMS 키에 대한 엑세스도 필요하다.

이처럼 업로드 다운로드할 때 KMS키를 사용하기에 처리량이 매우 높은 s3버킷이 있고 모든 파일이 KMS로 암호화 되어 있다면 

스로틀링 오류 등의 사례가 발생할 수 있다.

 

SSE-C

여기서는 키가 AWS외부에서 관리되지만 AWS로 키를 보내기 때문에 이것도 서버측 암호화이다.

제공된 암호화 키는 Amazon S3에 저장되지 않고 사용 후 폐기 된다.

이 경우 Amazon S3로 키를 전송하기 때문에 HTTPS를 사용해야 하고, 요청을 전송할 때마다 HTTP헤더에 키를 포함하여 전달해야 한다. 키는 외부에서 관리하고 업로드 할 때마다 헤더에 키를 같이 넣어 보내고 s3에서는 받아온 객체와 키를 조합해 s3에 저장한다.

ㅜㄹ론 이 파일을 다시 읽으려면 사용자는 암호화에 사용된 키를 다시 제공해야 한다.

 

Client-Side Encryption

이 방식은 클라이언트 라이브러리로 더 쉽게 구현할 수 있다. 데이터를 Amazon S3에 보내기 전에 클라이언트가 직접 암호화 해야한다,

암호화된 데이터는 s3에서 가져올 수도 있고 데이터 복화화는 외부의 클라이언트에서 수행된다. 그러니 클라이언트가 전적으로 키와 암호화 주기를 관리한다.

 

amazon콘솔에서는 sse-s3, sse-kms만 사용가능하다. sse-c는 cli, sdk, 등에서만 가능하고 client side encrytion은 사용자 측에서 미리 암호화를 하니까 일반 업로드 하듯이 하면된다. 

 

버저닝을 해두고 암호화 되지 않은 파일을 암호화 해서 다시 올리면 버저닝 됨으로써 마지막에 올린파일은 암호화가되어있고 이전꺼는 암호화가 안되어있는걸 확인할 수 있다., 

 

암호화를 강제화 하기 위해서 버킷 정책을 사용할 수도 있다. 지정된 암호화 헤더가 없는 s3객체를 버킷에 넣는 api호출을 거부한다.

 

 

 

Encrpytion in transit ( SSL / TLS )

s3에는 두 개의 엔드포인트가 있다. 암호화되지 않은 http 엔드포인트와 전송 중 암호화인 https 엔드포인트이다.

 

CORS?

시험에 나올 CORS관련질문은 하나이다.

오리진은 체계(프로토콜)와 호스트(도메인)와 포트로 구성된다.

https://www.example.com을 예로 살펴보면 HTTPS포트는 443이고 프로토콜은 http자체이고 도메인은 www.example.com이다.  cors는 웹 브라우저 기반 보안 메커니즘으로 메인 오리진을 방문하는 동안 다른 오리진에 대한 요청을 거부한다.

오리진이 같다는 것이 무슨뜻인지 알아보자. 

프로토콜, 도메인, 포트가 동일할 때 오리진이 같아고 말한다.

http://example.copm/app1 & http://example.com/app2 이 두 url은 같은 오리진을 공유하고 있다. 

http://www.example.com & http://other.example.com 이 둘은 다른 오리진이다. 

웹 브라우저가 한 웹사이트를 방문하는 동안 요청 체계의 일부로 다른 웹사이트에 요청을 보내야 할 때 다른 오리진이 CORS헤더를 사용해서 요청을 허용하지 않는 한 해당요청은 이행되지 않는다.

 

a서버에서 domain1111.com이라는 도메인을 운영하고 그 서버 내에서 index.html, image1111.jpg를 불러온다고 하자

이 때에  index.html 은 domain1111.com/index.html일테고, 그 안에 image파일이 있다 가정하면 domain1111.com/static/image1111.jp이니까 이 index.html은 같은 오리진으로 요청을 보낼 것이다. 이러면 상관 없는데

 

만약 index.html안에 다른 이미지 파일을 불러오는데 , 그파일이 b서버에 있는 즉 domain2222.com/static/image.jpg여기서 가져오는 것이라면 다른 도메인에 해당하니까 요청하는 곳은 domain1111.com인데 실제 파일은 domain2222.com에 있으니까.. 이게 문제가 될 수 있다. 따라서 이를 방지하기 위해서 cors를 사용한다고 한다

 

이 경우 b서버 측에 cors 정책을 설정해줘야 한다. 그 정책에서는 a도메인에서 접근하는 것을 허용하는 내용을 적어주면 된다.

 

자세하게는 잘 모르는데 대충 이런내용인듯?

 

MFA Delete

s3객체를 영구삭제할 우려가 있기에 MFA를 설정해두면 실수로 삭제할 일을 방지할 수 있다.

또 버킷에서 버저닝을 중단할 때에도 필요하게 할 수 있다, 

MFA Delete를 사용하려면 먼저 버킷에서 버저닝을 활성화 해야한다. 버저닝과 관련이 있기 때문이다. 

루트 계정만이 MFA Delete를 활성화 하건거나 비활성화 할 수 있다.

 

S3 Access Logs

감사 목적으로 s3버킷에 대한 모든 액세스를 기록할 수 있다. 

어떤 계정에서든, S3에 액세스 한 기록을 보여준다. ( 승인 거부 상관없이 )

다른 s3버킷(로깅 버킷)에 파일로 기록이 된다. 해당 데이터는 amazon Athena와 같은 데이터 분석 도구로 분서 가능

S3 Access Log + Amazon Athena

대상 로깅 버킷(로그 저장하는 버킷 )은 같은 AWS에 있어야 한다.

사용쟈 -> s3 액세스 -> 로킹 버킷 기록

 

저장하려고 만든 버킷을 로깅버킷으로 지정하면 안된다. ( 같은 버킷 )

무한 루프가 돌아가게 된다.

유저 파일 업로드 -> s3버킷은 로깅버킷에 로그 기록 -> 로그 기록파일이 업로드 되니 다시 로깅버킷에 로그기록 -> ...

하나의 버킷이 두 용도로 사용되어버리면 이렇게 되버린다.

 

Pre Signd URLs

미리 서명된 URL,

S3콘솔, CLI, SDK를 사용하여 생성가능

S3로 생성한 경우 최대 12시간

CLI로 생성하면 168 최대시간이다.

URL을 받는 사용자는 URL을 생성한 사용자의 GET또는 PUT에 대한 권한을 상속한다.

 

프라이빗 버킷이 있고 AWS외부에서 특정 파일에 접근하려고한다. 그 파일을 퍼블릭 으로 설정하고 싶지는 않을 것이다.

이 때 버킷 소유자가 해당 파일을 가지고 미리 서명된 URL을 생성한다. 그럼 S3버킷이 URL을 제공하고 해당 URL은 미리 서명이 된다.

가령 어떤 웹사이트에서 로그인한 사용자만 S3버킷에서 프리미엄 비디오를 받게 하도록 하고싶으면 이 방법을 사용할 수 있다. 또는 일시적으로 사용자가 S3버킷의 특정한 위치에 파일을 업로드 하도록 하게 할 수도 있다. ( 버킷을 비공개로 유지하면서 )

 

파일에서 object actions -> share file with a presigned URL을 누르고 시간을 정하면

url이 생성이되는데 이제는 이 시간만큼 이 파일에 접근할 수 있다.

 

S3 Glacier Vault Lock

glacier 위에 볼트 잠금 정책을 생성한 다음

 

S3 Object Lock ( versioning must be enabled)

S3객체 잠금을 활성화 하려면 먼저 버저닝을 활성화 해야한다.

객체 잠금은 전체 s3버킷 수준의 잠금 정책이 아니라 버킷 내의 각 객체에 적용할 수 있는 잠금이다.

특정 객체 버전이 특정 시간 동안 삭제되는걸 차단할 수 있다.

두가지 모드가 존재한다.

1. compliance 모드

s3 glacier 볼트 잠금과 매우 유사 사용자를 포함한 그 누구도 객체 버전을 덮어쓰거나

삭제할 수 없다. 누구도 객체를 변경할 수 없다.

 

2. governance 모드

대부분의 유저는 객체 버전을 덮어쓰거나 삭제하거나 로그 설정을 변경할 수 없다.

하지만 관리자 같은 일부 사용자는 iam을 통해 받은 권한으로 보존기간을 변경하거나 객체를 바로 삭제할 수 있다.

조금 더 유연성이 있다.

 

3.Legal mode

법적인 문제가 있을 때 사용하며 보존기간 모드에 상관없이 객체가 영구적으로 보호된다.

법적인 문제가 끝나면 이 모드를 제거할 수도 있다.

 

 

s3 access Points

여기 S3 버킷이 있습니다 S3 버킷에는 폴더 두 개가 있죠

재무 데이터가 있는 finance 폴더와 기업의 세일즈 데이터가 있는 sales 폴더가 있습니다

이 S3 버킷에 액세스하려는 세 가지 그룹의 사용자가 있다고 가정합시다 재무, 세일즈, 분석(Analytics)까지 세 가지 그룹으로 나뉘는데요

이제 버킷 정책을 만들어서 모든 사용자가 어디에 액세스할지 정의할 수 있는데요

하지만 그룹과 사용자가 많을수록 버킷 정책은 더욱 복잡해집니다

그러므로 버킷 정책 대신 S3 액세스 포인트라는기능을 사용하겠습니다

재무팀을 위한 액세스 포인트를 '재무 AP'로 부르겠습니다

이 액세스 포인트는 재무 데이터와 연결되어 있죠

세일즈 데이터와 연결된 '세일즈 AP'도 있습니다

재무, 세일즈 데이터와 연결된 '분석 AP'도 있죠

S3 버킷 상위 수준에 하나의 계층을 만들었습니다

이제 재무 AP에 정책을 연결하겠습니다

이를 통해 재무팀 사용자와 그룹은

특정 접두사인 /finance에만 읽기/쓰기 액세스를 허용할 거예요

그러면 재무 AP를 통해 S3 버킷에 액세스한 사용자에게는

재무 데이터를 읽고 쓰는 권한만 있겠죠

마찬가지로 세일즈 팀도 접두사 /sales에만

읽기와 쓰기만 가능하도록 액세스 포인트에 정책을 연결하면

세일즈 팀이 액세스 포인트를 통해 버킷에 액세스했을 때만

세일즈 데이터를 읽고 쓸 수 있습니다

마지막으로 분석팀은

읽기만 허용하지만 모든 데이터에 액세스합니다

그러면 분석 AP에 모든 버킷에 읽기를 허용하도록

정책을 연결해야겠죠

각기 다른 액세스 포인트 사용 방법을 살펴봤습니다

그룹에 따라 액세스할 액세스 포인트를 정의하는

특정 정책을 액세스 포인트마다 연결할 수 있죠

최종적으로는 S3 버킷에 액세스합니다

각 액세스 포인트마다 고유의 DNS와 정책이 있습니다

이를 통해 사용자나 그룹의 액세스를 제한할 수 있죠

액세스 포인트마다 하나의 정책만 가지니까

복잡하고 고유한 버킷 정책보다 훨씬 다루기 쉽습니다

S3 액세스 포인트가 뭔지 이해했다면

이제 또 다른 사용 사례인 S3 객체 Lambda를 살펴봅시다

S3 객체 Lambda의 사용 목적은 S3 버킷의 객체를

호출한 애플리케이션이 회수하기 전에 수정하기 위함입니다

예를 들어 각 객체를 다른 버전으로 만들기 위해

버킷을 복사하는 대신 S3 객체 Lambda를 사용하는 거죠

이를 위해 앞서 살펴본 S3 액세스 포인트가 필요합니다

어떻게 작동할까요?

클라우드에 S3 버킷이 있다고 가정합시다

전자 상거래 애플리케이션은 이 S3 버킷 데이터를 소유할 테니

이 S3 버킷에 직접 액세스할 수 있고

S3 버킷에 원본 객체를 입력하거나 가져올 수 있을 거예요

하지만 분석 애플리케이션은

편집된 객체에만 액세스해야 할 수도 있습니다

즉, 일부 데이터가 삭제된 객체에 액세스하는 거죠

이를 위한 새 S3 버킷을 생성하는 대신

S3 버킷 상위 수준에 S3 액세스 포인트를 생성하고

Lambda 함수와 연결하면 됩니다

아직 Lambda에 대해 깊게 배우진 않았지만

Lambda 함수는 클라우드에서

몇몇 코드를 손쉽게 실행할 수 있게 도와주죠

이 Lambda 함수는 회수한 객체의 데이터의 일부를 삭제할 거예요

Lambda 함수 상위 수준에는

S3 객체 Lambda 액세스 포인트를 생성하겠습니다

이를 통해 분석 애플리케이션이 S3 버킷에 액세스할 수 있겠죠

요약하면, 분석 애플리케이션은 Lambda 함수를 실행하는

S3 객체 Lambda 액세스 포인트에 액세스하고 Lambda 함수는

S3 버킷에서 데이터를 가져와 코드를 실행해 데이터의 일부를 삭제합니다

그러므로 분석 애플리케이션은 전자 상거래 애플리케이션과 같은

S3 버킷으로부터 편집된 데이터를 얻게 되겠죠

마케팅 애플리케이션은

데이터가 강화된 객체에 액세스하길 원합니다

데이터를 강화할 고객 충성도 데이터베이스가 있죠

S3 버킷을 새로 만들고

강화된 데이터로 객체를 생성할 수도 있지만

다시 Lambda 함수를 사용하겠습니다

고객 충성도 데이터베이스에서 데이터를 찾아

데이터를 강화하는 또 다른 코드가 실행될 거예요

상위 수준에 S3 객체 Lambda 액세스 포인트를 만들어야겠죠

그러면 마케팅 애플리케이션이 S3 객체 Lambda 액세스 포인트에

액세스해서 데이터가 강화된 객체를 취할 거예요

보시다시피 데이터를 수정하는 S3 객체 Lambda와

액세스 포인트를 생성하는 S3 버킷은 하나밖에 없습니다

S3 객체 Lambda의 사용 사례로는

분석이나 비프로덕션 환경을 위해 개인 식별 정보와 같은

PII 데이터를 삭제하는 경우가 있고

XML에서 JSON으로 데이터를 변환하거나

원하는 변환을 실행하는 경우가 있습니다

가령 상황에 맞춰 이미지 크기를 바꾸거나 워터마크를 남기는 거죠

단, 워터마크는 객체를 요청한 사용자를 적용합니다

S3 객체 Lambda가 유용한 사용 사례가 되죠

유익한 시간이었길 바라며 그럼 다음 강의에서 만나요