Encryption
S3 버킷에 저장되는 파일을 암호화 하여 저장하여 파일 보안을 강화 할 수 있습니다.
아티클 작성일로부터 비교적 최근인 2023년 1월 5일 부터는 버킷 생성 시 S3 관리형 키를 사용한 서버측 암호화 방식(SSE-S3) 암호화를 기본 수준으로 적용 합니다.
Server-Side Encryption
업로드 후 S3 내에서 암호화 하는 방식을 Server-Side Encryption 이라고 하며 일반적으로 많이 사용하는 방식입니다.
SSE-S3
- S3 에서 자동으로 생성하고 관리하는 키로 파일을 암호화 합니다
SSE-KMS
- KMS에서 사용자가 생성하고 관리하는 키를 사용하여 암호화
- KMS 키를 사용하기 때문에 CloudTrail로 암호화 로그를 확인 할 수 있습니다
- 다운로드 받을때도 암호화에 사용한 KMS 키에 대한 접근 권한이 있어야 복호화 이후 다운로드 받을 수 있으므로 이를 인지하고 IAM 권한을 부여해야 합니다(추가적인 보안 포인트 이기도 합니다)
SSE-C
- 사용자가 직접 관리하는 키로 암호화 합니다
- S3에 키를 보내지만 S3에서 저장하고 있지 않습니다
- S3에 키를 보내야 하기 때문에 전송간 프로토콜은 HTTPS 여야 합니다
- HTTPS 요청 시 x-amz-server-side-encryption-customer-algorithm 헤더의 값으로 암호화에 사용할 값을 같이 전송합니다
- x-amz-server-side-encryption-customer-algorithm 헤더를 사용 하려면 추가로 버킷 정책을 아래와 같이 추가해야 합니다
Client-Side Encryption
클라이언트에서 직접 파일을 암 / 복호화 하는 방식으로 S3 에서는 업로드된 파일이 암호화된 파일인지 아닌지 여부를 알 수는 없습니다. 또한 클라이언트에서 모든 동작이 이루어지기 때문에 암호화에 사용되는 키 또한 당연히 클라이언트에서 관리 됩니다.
CORS(Cross Origin Request Sharing)
브라우저에서 띄우는 웹 호스팅을 제공하는 서버가 Origin 서버라고 하는데 같은 Origin 서버에 있는 리소스를 가지고 오는건 문제 없지만 다른 도메인을 가진 서버에 요청하여 리소스를 필요로 할 경우 해당 서버에서 access-control-allow-origin 설정을 해야 정상적으로 가져 올 수 있습니다.
S3 버킷도 이와 마찬가지로 특정 도메인 혹은 모든 도메인에 대한 리소스 요청(access-control-allow-origin)을 버킷 정책 설정(Bucket Policy)에서 허용해야 합니다.
MFA Delete
실제 최근 사내에서 테라폼의 상태정보(status)를 저장하는 버킷에서 작업자가 실수로 상태정보를 삭제하면 어떻게 되는지에 대한 논의가 있었습니다.
이러한 케이스처럼 삭제가 많이 우려스러운 파일이 삭제되는 것을 방지 하거나 혹시라도 AWS 계정이 해킹 당하더라도 지켜야되는 파일 정보가 있을 경우 MFA Delete를 설정하여 이를 방지 할 수 있습니다.
MFA 인증은 모바일기기에서 주로 사용하는 Google Authenticator와 물리적인 장비를 이용하는 Hardware Device를 사용 할 수 있습니다.
Conclusions
이번 아티클은 SAA를 준비하면서 공부한 내용을 토대로 정리 해보았습니다. 아무래도 업무에서 S3를 많이 사용하다 보니깐 S3에 대해서는 기본적으로 좀 안다 생각 했는데 저도 이런 보안 관련된 설정들은 하나도 모르고 있었습니다. 다음 아티클은 SAA 시험 후기에 대해 작성 해보도록 하겠습니다. 감사합니다!
