[AWS/S3] S3 Presigned Url

Amazon S3 소개

• Amazon Simple Stroage Servie
  • 객체 스토리지 서비스.
  • 데이터를 S3에 저장하려면 , 버킷과 객체라는 리소스를 사용해야 함.
    • 버킷 : S3에 저장된 객체에 대한 컨테이너
    • 객체 : 파일과 해당 파일의 메타 데이터
• 객체를 업로드 하는 방법
  1. 버킷 생성, 그 안에 객체 업로드
  • 그 안에 객체 업로드.
    1. Presigned URL 사용
    2. 파일을 AWS 콘솔에서 직접 업로드
    3. HTTP 서블렛 리퀘스트에 Input Stream을 이용하여 S3에 직접 파일을 전송하는 Stream 방식
    4. 스프링에서 제공하는 멀티파트 파일 인터페이스를 사용하는 방식
• S3의 파일 공유하는 방법
  1. 모든 파일을 퍼블릭으로 만들기
     1. 장점: 별도의 관리가 필요 없음
     2. 단점: 아무나 파일 다운로드 가능
  2. IAM 자격증명 공유(Access Key Pair)
     • 장점: 지정한 사람만 공유 가능.
     • 단점
       • 자격증명 유출/변경 시 공유자 모두에게 다시 부여 필요
       • 자격증명의 관리가 어려움.
       • 영구자격증명이라 보안이 뛰어나지 않음.
     1. IAM 사용자 부여하기
        • 장점: 지정한 사람만 공유 가능
        • 단점
          • IAM 사용자 숫자 제한 = 5000개
          • 모든 유저에게 IAM 사용자를 부여하는 과정 필요
          • 유지보수의 어려움
     2. Presigned URL
        • 장점
          • 지정한 사람만 공유 가능
          • 만료기간 설정 가능
          • 권한 관리 가능
          • HTTP 기반으로 접근 가능
     3. : 관리자, 혹은 권한이 있는 사람이 권한을 담아서 URL을 생성하는 것. 여기에 보안적인 처리가 되어 있어서, 여기에 S3에 파일을 공유받기 위한 모든 권한이 들어있음. 이 URL을 가지고 유저들에게 공유하는 것. 매번 User들에게 다른 URL을 공유.

 

Presigned URL의 개념

• Presigned URL
  • 권한이 있는 사용자가 특정 권한을 담아서 URL을 생성하면, 이를 통해 다른 사용자가 S3 버킷에 객체를 업로드할 수 있게 됨.
    • 이 방법을 사용하면, 상대방이 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를 프로젝트에 적용한 과정에 대해 적어보겠습니다.