S3 Encryption
Amazon S3 기본 암호화를 사용하면 S3 버킷에 대한 기본 암호화 동작을 설정하여 모든 새 객체가 버킷에 저장될 때 암호화되도록 할 수 있습니다. Amazon S3로의 모든 새 객체 업로드는 추가 비용 없이 성능에 영향을 미치지 않고 자동으로 암호화(기본값: SSE-S3)됩니다.
S3 버킷 내 객체를 암호화하는 방법은 네 가지가 있습니다
-
Server-Side Encryption
- SSE-S3
- SSE-KMS
- SSE-c -
Client-Side Encryption
Server-Side Encryption
서버 측 암호화는 데이터를 받는 애플리케이션 또는 서비스에 의해 해당 대상에서 데이터를 암호화하는 것입니다. Amazon S3에서 데이터 센터의 디스크에 데이터를 쓰면서 객체 수준에서 데이터를 암호화하고 사용자가 해당 데이터에 액세스할 때 자동으로 암호를 해독합니다.
요청을 인증하기만 하면 액세스 권한을 갖게 되며, 객체의 암호화 여부와 관계없이 액세스 방식에는 차이가 없습니다. 예를 들어, 미리 서명된 URL을 사용하여 객체를 공유하는 경우, 해당 URL은 암호화된 객체와 암호화되지 않은 객체에 동일하게 작동합니다. 또한 버킷에 객체를 나열하는 경우 목록 API에서는 암호화 여부와 관계없이 전체 객체의 목록을 반환합니다.
SSE-S3
- 관리형 키를 사용한 서버 측 암호화
Amazon S3 관리형 키를 사용한 서버 측 암호화(SSE-S3)를 사용하면 각 객체는 고유한 키로 암호화됩니다. 즉, AWS에서 처리, 관리 및 소유하는 키로 암호화를 진행합니다.
또한 추가 보안 조치로 주기적으로 교체되는 루트 키를 사용하여 키 자체를 암호화하는데, Amazon S3 서버 측 암호화는 가장 강력한 블록 암호 중 하나인 256비트 Advanced Encryption Standard(AES-256) GCM을 사용하여 데이터를 암호화합니다.
사용자는 이 키에 접근할 수 없기 때문에, 헤더(header)를 "x-amz-server-side-encryption": "AES256"로 설정해서
SSE-S3 메커니즘으로 객체를 암호화하도록 Amazon S3에 요청해야 합니다.
SSE-KMS
- AWS KMS keys를 사용한 서버 측 암호화(SSE-KMS)
AWS KMS keys를 사용한 서버 측 암호화(SSE-KMS)는 AWS와 S3 서비스가 소유한 키에 의존하는 대신 KMS(Key Management Serice)로 자신의 키를 직접 관리하는 방식입니다.
SSE-S3와 유사하지만 이 서비스 사용 시 몇 가지 추가적인 이점이 있고 비용이 발생합니다. Amazon S3의 객체에 대한 무단 액세스에 대응하여 추가적인 보호를 제공하는 KMS 키를 사용하려면 별도의 권한이 필요합니다.
KMS를 사용하면 사용자가 키를 제어할 수 있다는 장점이 있습니다.
- SSE-KMS도 CloudTrail을 사용하여 KMS 키가 사용된 때와 사용 주체를 표시하는 감사 추적 기능을 제공합니다.
- 고객 관리형 키를 생성하고 관리하거나 사용자, 서비스 및 리전에 고유한 AWS 관리형 CMK를 사용할 수 있습니다.
헤더는 "x-amz-server-side-encryption": "aws:kms"로 지정해야 하고 그러면 서버에서 객체를 암호화합니다 S3 버킷에서 해당 파일을 읽으려면 객체 자체에 대한 액세스뿐만 아니라 객체를 암호화하는 데 사용된 KMS 키에 대한 액세스도 필요합니다
SSE-KMS에는 제약이 있습니다 Amazon S3에서 파일을 업로드하고 다운로드할 때 KMS 키를 사용해야 하기 때문인데, KMS 키에는 GenerateDataKey 같은 자체 API가 있고 그리고 복호화할 때는 복호화 API를 호출합니다.
따라서 KMS 서비스에 API 호출을 수행해야 하는데 각 API 호출은 초당 KMS 할당량에 포함됩니다.
리전에 따라 초당 5,500-30,000개의 요청을 처리할 수 있지만 서비스 할당량 콘솔로 한도를 늘릴 수 있습니다. 따라서 처리량이 매우 높은 S3 버킷이 있고 모든 파일이 KMS 키로 암호화되었다면 스로틀링 오류 등의 사례가 발생할 수 있습니다.
SSE-C
- 고객 제공 키를 사용한 서버 측 암호화
키가 AWS 외부에서 관리되지만 AWS로 키를 보내기 때문에 이것도 서버 측 암호화입니다. 하지만 제공된 암호화 키는 Amazon S3에 저장되지 않고 사용 후 폐기됩니다 이 경우 Amazon S3로 키를 전송하기 때문에 HTTPS를 사용해야 하고 요청을 전송할 때마다 HTTP 헤더에 키를 포함하여 전달해야 합니다
Client-Side Encryption
마지막으로 클라이언트 측 암호화가 있는데, 이는 클라이언트 측 암호화는 데이터를 S3로 보내기 전에 데이터를 암호화하고 데이터를 다운로드한 후 해독하는 것을 말합니다.
이 방식은 클라이언트 라이브러리로 더 쉽게 구현할 수 있고 Amazon S3 Client-Side Encryption Library가 그러한 라이브러리의 예입니다
클라이언트 측 암호화 방식에서는 데이터를 Amazon S3로 보내기 전에 클라이언트가 직접 암호화해야합니다. 암호화한 데이터는 Amazon S3에서 가져올 수도 있고 데이터 복호화는 Amazon S3 외부의 클라이언트에서 수행됩니다
즉, 클라이언트가 전적으로 키와 암호화 주기를 관리합니다.
Encryption in Transit(SSL/TLS)
전송 중 암호화는 SSL 또는 TLS라고도 합니다
Amazon S3 버킷에는 두 개의 엔드포인트가 있습니다.
- 암호화되지 않은 HTTP 엔드포인트
- 전송 중 암호화인 HTTPS 엔드포인트
웹사이트에 접속할 때 자물쇠 모양을 보신 적이 있으실 텐데
이것은 웹사이트가 전송 중 암호화를 사용하고 있다는 의미로
여러분과 대상 서버의 연결이 안전하고 암호화되었다는 뜻입니다
따라서 Amazon S3를 사용하는 경우 데이터를 안전하게 전송하려면 HTTPS를 사용하는 것이 좋습니다. SSE-C 유형의 메커니즘을 사용할 땐 HTTPS 프로토콜을 꼭 사용해야 하고, 실제로 적용은 크게 신경 쓰지 않아도 됩니다 왜냐하면 대부분의 클라이언트에서는 HTTPS 엔드포인트가 기본값으로 되어 있기 때문입니다.
https://jayendrapatil.com/aws-s3-encryption/
https://dev.classmethod.jp/articles/lim-s3-sse-2021/
