파일 관리 서비스 1 - 업로드 (Presigned URL)

개요

많은 서비스가 사용자로 부터 파일을 받아, 이를 스토리지 등에 저장 해 두고 관리한다. 

업로드 간 올바른 데이터가 잘 업로드 되도록 검증하거나, 유출되면 안되는 중요한 정보도 있기 때문에 이를 잘 관리하는 것 또한 중요하고, 스토리지가 유저에 의해 오남용 되는 경우도 주의해야 한다.

 

해당 글에서는 다음 정보에 대해 알아본다.

• 파일 업로드 간 올바른 데이터(무결성) 관리를 위한 검증 목록
• 파일 업로드 시 스토리지 접근 주체 (BE vs FE)
• 파일 업로드 Presigned URL 방법

 

파일 업로드 간 올바른 데이터(무결성) 관리를 위한 검증 목록

파일  간 꼭 모든 사항을 필수적으로 검증해야 하는 것은 아니고, 서비스에 맞게 하면됨.

대분류	소분류	내용
1. 파일 형식 검증	확장자 검증	file 이름에서 확장자 검증
	MIME 타입 검증	파일 header의 content-type 검증
	확장자 검증	file 이름 => MIME 매핑 유효한지 검증
	파일 내용 분석	실제 (ex.이미지) 파일인지 ex) 파일 앞부분의 1024 자리 체킹
	파일 크기 검증	서비스에 맞는 파일 크기 인지 or 물리적으로 업로드 가능한 크기 제한
	파일 갯수	서비스에서 요구하는 파일 갯수 or 물리적으로 동시 업로드 가능한 파일 갯수
2. 파일 이름 검증	허용된 문자	특수 문자 등 허용된 문자 여부 검증
	파일 이름 길이	파일 이름 길이 제한
	중복 처리	파일 이름 변경, 덮어쓰기 등 이슈 대비 -> 파일 저장을 Hash 화도 가능
3. 파일 접근 권한 검증	인증 검사	파일 업로드 사용자 인증 및 권한 체크
	파일 접근 제어	업로드 파일에 대한 접근 권한 설정
4. 파일 무결성 검증	해시 검증	파일이 전송중 손상 여부에 대한 해시값 검증
	CRC 체크	파일 전송 오류 감지

 

 

파일 업로드 시 스토리지 접근 주체 (BE vs FE)

파일을 S3(스토리지)로 올리기 위해선 누군가는 S3에 대한 접근 권한을 가지고 있어야 하는데, 이는 FE(클라이언트)가 가지고 있을 수도 있고 BE(서버)가 가질 수도 있는데, 각 경우의 장단을 비교해본다. 

 

1. FE → BE → S3 (서버가 S3로 올리는 경우)

- 파일 객체를 유저가 업로드 하여 서버로 전달하고, 서버에서 스토리지로 한 번 더 보내는 방식

- 위에 작성한 검증 목록에서는 대다수를 서버에서 처리 가능하다.

 

장점

• 파일 업로드 과정에서 클라이언트가 S3 자격 증명(Key)에 접근하지 않아 안전함
• 서버에서 파일에 대해 직접 검증하거나 변환하는 작업을 할 수 있음
• 파일 무결성 유지 및 추가 처리(예: 압축, 변환)등 도 가능 (클라이언트에선 비교적 하기 힘든)
• 서버에서 모든 업로드 트래픽을 제어할 수 있어 로깅, 모니터링, 정책 적용 등이 용이

 

단점

• 모든 파일이 서버를 거치게 되어 서버의 트래픽과 리소스 사용량 증가 될 수 있음
• 파일이 담긴 네트워크가 두 번 발생하게 되어 (FE → BE / BE → S3) 비용이 높아진다.
• 네트워크 비용이 높아짐에 따라 응답 시간이 늘어져, 유저가 불편함을 느낄 수 있다.

 

2. FE → S3 (클라이언트가 S3로 올리는 경우)

- 위에 작성한 검증 목록들은 대다수를 FE에서 처리해야 한다.

 

 

장점

• 클라이언트에서 직접 업로드 하기 때문에, 서버 부하가 감소됨
• 클라이언트에서 S3로 직접 업로드 하기 때문에 지연시간이 짧아짐

 

단점

• 파일 업로드 과정에서 클라이언트가 S3 자격 증명(Key)에 접근하게 되어 취약할 수 있음
• 검증에 대해 클라이언트에서 보다 많은 책임을 가지게 되는데, 처리에 어려움이 있을 수 있음
• S3에 대한 CORS 설정 등 스토리지와의 연결을 위한 추가적인 작업이 필요할 수 있음

 

결론 

- 즉 1안은 보안에 뛰어나지만 성능에 이슈가 있을 수 있고, 2안은 성능은 좋지만 보안에 취약할 수 있다.

 

Presigned URL 업로드 방법

Presigned URL 업로드 방식은 보안성과 성능을 모두 고려한 S3 파일 업로드 방법으로, 서버가 AWS S3에 요청하여 특정 파일에 대한 임시 접근 권한을 가진 URL을 생성하고, 해당 URL을 통해 클라이언트가 S3에 직접 파일을 일정 시간 동안 만 업로드 할 수 있는 권한을 가져, 보안 위험을 최소화함.

 

동작 방식

1. 클라이언트 요청: 클라이언트가 파일을 업로드하고자 할 때, Presigned URL 생성 요청 (POST /presigned)
2. 서버 Presigned URL 생성: 서버는 S3에 파일 업로드를 위한 Presigned URL을 생성하고, 클라이언트에게 반환
3. 클라이언트 파일 업로드: 클라이언트는 받은 Presigned URL을 사용하여 S3에 파일을 직접 업로드
4. 업로드 완료 후 처리: 필요에 따라 서버에 업로드 완료를 알려주어 추가 작업(ex. DB 업데이트)를 진행 가능

 

장점

• 클라이언트는 제한된 시간 동안만 유효한 Presigned URL을 사용해 파일 업로드 가능, AWS 자격증명이 필요 없어 보안에 좋음
• 클라이언트에서 S3에 직접 파일을 업로드하기 때문에, 서버의 부담이 적고 지연 시간도 줄어듬
• 서버에서 파일의 유효 시간, 권한 등을 미리 설정할 수 있어, 보안 요구 사항에 맞게 조정도 가능

 

단점

• 클라이언트와 서버 간의 Presigned URL 요청 로직 추가 구현 필요
• Presigned URL 발급 이후 파일 업로드 된 과정에서 검증은 FE가 관여하게 되는데, 한계가 있다.
• URL 발급 이후 파일에 대해서는 서버가 직접 관여 하지 않아, 위에 작성한 파일 검증 목록에서, 일부 (1~3)는 Presigned URL에서 사전에 제약을 걸어 미리 조율 할 수 있지만, 4. 와 같은 파일 자체에 대한 검증은 FE에서 처리하거나, 추후 비실시간으로 처리가 필요할 수 있다. 

 

결론

- Presigned URL 방식은 보안과 성능의 균형을 맞추면서, 클라이언트가 S3에 안전하게 파일을 업로드할 수 있는 방법이다.