[AWS] Amazon S3 - Object Encryption

S3 - Object Encryption

• 밑의 네 가지 방법을 이용해 S3 버킷에 있는 객체들을 암호화 할 수 있다.
    - 서버 측 암호화 = SSE 중
        첫 번째 : SSE-S3는 Amazon S3에서 관리하는 키를 이용한 서버 측 암호화이다.
        두 번째 : SSE KMS는 KMS 키를 이용해서 암호화 키를 관리한다.
        세 번째 : SSE-C는 고객이 제공한 키를 사용한다. 이 경우에는 우리가 가진 키를 제공한다. 
    - 클라이언트 측 암호화 중
        네 번째 : 이 경우에는 클라이언트 측의 모든 걸 암호화한 다음에 그걸 Amazon S3에 업로드 한다.

 

 

Amazon S3 Encryption - SSE-S3

• AWS가 처리하고 관리하고 소유한 키를 이용해서 암호화를 한다. 우리는 그 키에 절대로 엑세스 할 수 없다.
• 객체는 AWS에 의해 서버 측에서 암호화가 될 것이다.
• 암호화의 보안 유형은 AES-256이다. 
• Amazon S3가 SSE-S3 메커니즘을 이용해서 객체를 암호화하도록 요청하기 위해 헤더를 "x-amz-server-side-encryption":"AES256"이라고 설정해야 한다.
• 그리고 SSE-S3는 새로운 버킷과 새로운 객체에 대해 기본 값으로서 활성화되어 있다.

• 그럼 작동 방식을 알아보자.
• Amazon S3가 있고 사용자가 있는데, 사용자는 올바를 헤더를 써서 파일을 업로드 할 것이다. 그리고 그게 Amazon S3 아래의 객체가 된다. 그럼 Amazon S3는 S3가 보유한 키와 그 객체를 짝지어준다.
• 우리가 SS3-S3 메커니즘을 사용하고 있기 때문에, 우리는 그 키와 객체를 혼합해서 암호화를 할 수 있다. 그리고 그게 우리의 S3 버킷에 저장될 것이다.

 

Amazon S3 Encryption - SSE-KMS

• AWS와 S3 서비스가 보유한 키에 의존하지 않고, KMS 서비스 즉, 키 관리 서비스를 이용해서 직접 자신의 키를 관리하려고 한다.
• KMS를 사용할 경우에는 사용자가 키를 통제할 수 있다는 장점이 있다. 즉, 우리는 KMS에서 직접 키를 생성할 수 있고, CloudTrail을 이용해서 키 사용을 검사할 수 있다. 그래서 누군가 KMS에서 키를 사용할 때마다 AWS 안에서 일어나는 모든 걸 로깅하는 서비스인 CloudTrail에 로깅될 것이다.
• 그렇게 하려면 반드시 "x-amz-server-side-encryption":"aws:kms"라는 헤더가 있어야한다. 그러면 객체가 서버 측에서 암호화된다.

• 그럼 작동 방식을 알아보자.
• 우린 객체를 업드하는데, 이번엔 다른 헤더를 사용한다. 그리고 헤더 안에서 우리가 사용하려는 KMS 키를 지정한다. 그러면 객체가 Amazon S3에 나타난다. 그리고 이번에 사용될 KMS 키가 AWS KMS 외부에서 오게된다. 그리고 이 두 개가 혼합되고 암호화가 이루어진다. 
• 그 파일이 결국 S3 버킷으로 가게 된다. 
• 그럼 이제 S3 버킷에서 그 파일을 읽기 위해서는 여러분은 객체 자체에 액세스 할 수 있어야 할 뿐만 아니라 이 객체를 암호화하는 데 사용된 KMS 키에도 액세스 할 수 있어야 한다. 이렇게 보안 수준이 한층 강화되는 것이다.

 

SSE-KMS Limitation

• SSE-KMS에는 약간의 제한 사항이 있다.
  왜냐면 Amazon S3로 업로드하고 거기서 다운로드하기 때문에 우리가 KMS 키를 사용해야 한다.
  KMS 키에는 예를 들어 GenerateDataKey 같은 자체 API가 있고, 우리는 Decrpt API를 사용해서 복호화를 한다. 그래서 우리는 KMS 서비스에 API 호출을 하게 될 것 이다. 그리고 그 API 호출 건은 모두 KMS의 초당 API 호출 쿼터에 합산된다.
• 그럼 비록 서비스 쿼터 콘솔을 이용해서 쿼터를 늘릴 수 있지만 리전에 따라 초당 5,000 내지 30,000 건의 요청이 가능 할 것이다. 
• 그럼 만일 우리의 S3 버킷의 처리량이 아주 아주 많고 모든 게 KMS 키로 암호화되어 있따면 그건 일종의 스로틀링 활용 사례가 될 수 있다.

 

Amazon S3 Encryption - SSE-C

• 키가 AWS 외부에서 관리되지만 여전히 서버 측 암호화이다. 왜냐면 우리가 그 키를 AWS로 전송하기 때문이다.
• 하지만 Amazon S3는 여러분이 제공한 암호화 키를 절대 저장하지 않을 것이다. 사용 후에는 폐기된다.
• 그럼 우리는 키를 Amazon S3로 전송하기 때문에 반드시 HTPS를 사요해야 한다. 모든 요청에 HTTP 헤더의 일부로서 키를 전달해야한다. 그럼 어떻게 작동할까?!
    - 사용자는 파일과 키를 업로드 할 껀데요, 사용자가 AWS 외부에서 그 키를 관리한다. 그러면 Amazon S3 클라이언트가 제공한 키와 객체를 사용해서 약간의 암호화를 수행하고 암호화된 파일을 S3 버킷에 넣게 된다.
• 사용자가 그 파일을 읽으려면 역시 파일을 암호화하기 위해 사용한 키를 제공해야 한다.

 

 

Amazon S3 Encryption - Client-Side Encryption

• 마지막으로 클라이언트 측 암호화가 있다.
• 만일 우리가 클라이언트 측 암호화 라이브러리 같은 클라이언트 라이브러리를 활용하면 더 쉽게 구현할 수 있다.
  클라이언트 측 암호화는 클라이언트가 직접 데이터를 암호화한 다음에 Amazon S3에 전송한다는 개념이다.
• Amazon S3로부터 데이터를 받을 수 있고, 그 다음으로 데이터의 복호화는 Amazon S3  외부의 클라이언트 측에서 이루어진다. 그래서 클라이언트가 키와 암호화 사이클을 완전하게 관리하는 것이다.

• 그럼 작동방식을 알아보자.
• 우린 파일이 있고, AWS 외부에 클라이언트 키가 있따. 그리고 클라이언트가 직접 암호화를 제공하고 수행할 것이다.
  이렇게 암호화된 파일이 만들어지고, 업로드하기 위해 그 파일을 그대로 Amazon S3에 전송할 수 있다.

 

 

 

Amazon S3 - Encryption in transit (SSL/TLS)(전송 중 암호화)

• 전송 중 암호화 또는 통신 중 암호화는 SSL 또는 TLS라고도 부른다.
• 우리의 Amazon S3 버킷에는 기본적으로 2개의 엔드포인트가 있다. 암호화가 되지 않는 HTTP 엔드포인트가 있고, 전송 중 암호화가 제공되는 HTTPS 엔드포인트가 있다.
• 그래서 우리가 웹사이트를 방문할 때마다 녹색 자물쇠나 그냥 자물쇠를 보게 된다. 그럼 그건 전송 중 암호화를 사용하고 있다는 의미이다. 즉, 우리와 타깃 서버간의 연결이 보안 연결이고 완전히 암호화되어 있다는 이야기이다.
• 우리가 Amazon S3를 사용할 때는 물론 데이터 송신 보안을 위해 HTTPS를 사용하도록 100%권고한다.
• SSE-C 타입의 매커니즘을 이용한다면 반드시 HTTPS 프로토콜을 사용해야 한다. 그리고 이건 실제 생활에서는 걱정할 부분이 아니다. 왜냐면 모든 클라이언트가 기본값으로서 HTTPS 엔드포인트를 사용하게 되는것이기 때문이다.

 

 

Amazon S3 - Force Encryption in Transit aws:Secure Transport

• 어떻게 전송 중 암호화를 강제할 수 있을까?
• 그걸 위해 우린 버킷 정책을 사용할 수 있다. 즉, 우리는 S3 버킷에 버킷 정책을 첨부하고 이런 구문을 첨부한다. 즉, aws:SecureTransport가 false라면 GetObject 작업을 거부하라고 하는 것이다.
• 그럼 HTTP를 사용할 경우에는 언제나 SecureTransport는 true일 것이다. 암호화 연결을 사용하고 있지 않다면 false일 것이다.
• 그래서 우리의 버킷에 HTTP를 사용하려는 모든 사용자가 차단될 것이다. 하지만 HTTPS를 사용하는 사용자는 허용될 수 있다.