[AWS/S3] S3 Presigned Url

 

해당 게시물은 위 동영상을 참고하여 작성되었습니다.

 

Amazon S3 소개 / 객체 업로드 방법

Amazon S3는, Amazon Simple Storage Service의 약자로, 아마존의 객체 스토리지 서비스를 의미합니다.

데이터를 S3에 저장하려면, bucket과 객체라는 리소스를 사용해야하는데,

여기서 버킷은 S3에 저장된 객체에 대한 컨테이너, 객체는 파일과 해당 파일의 메타 데이터를 의미합니다.

 

이 S3에 객체를 업로드하는 방법은 간단합니다.

aws 콘솔에서 S3 서비스에 진입하여 버킷을 생성하고, 그 안에 객체를 업로드하면 됩니다.

이렇게 객체를 업로드하는 방법으로는 크게 4가지로 이야기해볼 수 있습니다!

• Presigned URL 사용
• 파일을 AWS 콘솔에서 직접 업로드
• HTTP 서블렛 리퀘스트에 Input Stream을 이용하여 S3에 직접 파일을 전송하는 Stream 방식
• 스프링에서 제공하는 멀티파트 파일 인터페이스를 사용하는 방식

 

이렇게 객체를 업로드 한 후, S3의 파일을 공유하는 방법도 크게 4가지로 이야기해 볼 수 있습니다.

• 모든 파일을 퍼블릭으로 만들기
• IAM 자격증명 공유 (Access Key Pair)
• IAM 사용자 부여하기
• Presigned URL

 

각각의 방법의 장단점을 간략하게 살펴보겠습니다.

 

1. 모든 파일을 퍼블릭으로 만들기

이 방식은, 별도의 관리가 필요 없다는 장점이 있지만,

아무나 파일을 다운로드 할 수 있다는 단점이 존재합니다. 보안상으로 좋지 않습니다. (아무래도 ..)

 

2. IAM 자격증명 공유(Access Key Pair)

다음으로 IAM 자격증명을 공유하는 방법이 있습니다.

이 방법의 경우, 지정한 사람만 공유 가능하지만,

자격증명 유출/변경 시 공유자 모두에게 다시 부여가 필요하고,

이 자격증명을 개인이 지니고 있기 때문에 자격증명의 관리가 어렵습니다. 또한, 영구 자격 증명이라 보안이 뛰어나지 않다는 단점이 있습니다.

 

3. IAM 사용자 부여하기

이렇게 IAM 사용자를 부여하는 방법도 마찬가지로 지정한 사람만 공유 가능하다는 장점이 존재하지만,

IAM 사용자의 숫자는 5000개로 제한되어 있으며,

모든 유저에게 IAM 사용자를 부여하는 과정이 필요해 번거롭습니다.

또한, 유지보수가 어렵다는 단점이 존재합니다.

 

4. Presigned URL 

마지막으로 이번 게시글의 목적, Presigned Url입니다.

Presigned Url은, 권한이 담긴 url을 생성하고, 이 url을 통해 S3 버킷에 객체를 업로드할 수 있도록 하는 방식입니다.

위의 방식들과 비교해서 생각해보면, Presigned URL은 앞선 2,3번 방식과 동일하게 지정한 사람만 공유 가능합니다.

또한 만료기간도 설정 가능하고, 권한을 관리할 수 있습니다.

그리고 HTTP 기반으로 접근이 가능하다는 장점이 있습니다.

 

그렇다면 이 presigned url이 구체적으로 어떤 방식인지 살펴보도록 하겠습니다! 🚶🏻‍♀️🚶🏻‍♀️

 

Presigned URL의 개념

Presigned URL 방식은,

권한이 있는 사용자가 특정 권한을 담아서 URL을 생성하면, 이를 통해 다른 사용자가 S3 버킷에 객체를 업로드할 수 있게 되는 방식을 지원합니다.

이 방법을 사용하면, 이 url을 이용하는 사용자는 AWS 보안 자격 증명이나 권한이 없어도 객체를 업로드할 수 있습니다.

이때 Presigned Url은 생성하는 사용자의 권한에 따라 제한됩니다. 이 Url을 수신한 사용자는, url 생성자가 해당 객체를 업로드할 수 있는 경우에만 객체를 업로드할 수 있습니다.

또한, URL 생성 시 지정된 기간 동안만 유효하게끔 설정하여 보안을 강화합니다.

Amazon S3 콘솔에서, Presigned URL을 생성할 때 만료 시간은 1분 ~ 12시간 사이로 설정할 수 있으며, AWS CLI 혹은 AWS SDK를 사용하는 경우에는 최대 7일까지 설정이 가능합니다.

즉 정리해보면, Presigned URL을 통해 Amazon S3 버킷의 정책을 업데이트 하지 않아도, S3 객체에 제한된 시간 동안 접근할 수 있는 권한을 부여하여 업로드 또는 다운로드를 진행할 수 있게 됩니다.

 

Presigned URL의 동작 과정

1. 클라이언트가 서버에게 Presigned URL을 요청함.
2. 이후 서버는, AWS Credential 인증 과정을 거쳐서 S3에 요청함.
3. 이때 버킷 이름과 HTTP Method, 만료 시간 등을 놓고 Presigned URL을 생성함.
4. 서버는 S3로부터 Presigned URL을 반환받음.
5. 다음 서버는, 클라이언트에게 앞서 반환받은 URL을 전달함.
6. 이후 클라이언트는 해당 Presigned URL로 HTTP 요청을 보내면, 지정된 버킷 및 디렉토리에 객체가 업로드 됨.
7. 추가적으로 서버는 해당 이미지의 주소를 String 형태로 데이터베이스에 저장할 수 있음.

 

Presigned URL의 장점

• 서버 부하 감소
  • 이미지 파일은 용량이 큰 경우가 많아, json을 주고받는 일반적인 API 요청에 비해 서버에 더 큰 부하를 주게 됨.
  • 따라서, 이미지 업로드가 백엔드 서버를 거치게 될 경우, 서버에 큰 부담이 가해지게 됨.
  • 그렇다면 클라이언트에서 바로 업로드하면 되지 왜 굳이 서버를 거치나?
  • → 보안 때문. 서버를 거치지 않을 때는 권한이 없는 사용자도 S3에 접근할 수 있기 때문.
• 보안 강화
  • 하지만 Presigned URL을 사용하면 이미 S3에 객체를 업로드할 수 있는 권한을 갖고 있는 상태이기 때문에 이미지를 업로드할 때 백엔드 서버를 거치지 않고도 클라이언트에서 바로 S3에 업로드가 가능하게 됨.
  • 이전에는, 백엔드가 이미지를 임시로 저장해놨다가, S3에 전달함과 동시에 보안 절차도 한 번에 진행함. 하지만, Presigned URL 방식을 사용하면, 백엔드는 url 생성으로 보안절차 작업만 해주고, 클라이언트가 S3로 바로 업로드할 수 있도록 과정을 분리하게 됨.
  • 또한, 파일 업로드를 위해 네트워크 대역폭이나 별도의 앱을 제작할 필요가 없으므로 서버는 메모리와 네트워크 자원을 절약할 수 있게 됨.
  • 두 번째로, 만료 기간 설정으로 보안을 강화할 수 있음.
    • Presigned URL 생성 시, access 허용 기간과 범위를 설정할 수 있어서 유효기간 동안에 지정된 사용자만 접근이 가능하도록 제어할 수 있음.
    • 이러한 방법을 통해 URL이 탈취 당하더라도 만료 기간이 되면 자동으로 권한이 사라지게 됨.

 

 

다음 글에서는,

S3를 프로젝트에 적용한 과정에 대해 적어보겠습니다!