구글 드라이브와 같이 개인이 올린 이미지는 개인만 볼 수 있게 서비스를 하고 싶습니다. 이에 s3를 사용하려고하는데, s3 bucket을 private로 두고 있습니다. 어떻게 하면 좋을까요?

개인이 올린 이미지를 개인만 볼 수 있게 하는 서비스를 구현하기 위해 S3를 사용하는 경우, 두 가지 방법 모두 장단점이 있습니다.

1. Presigned URL 방식:

   • 장점: S3에서 직접 콘텐츠를 제공하므로 서버 부하가 적습니다.
   • 단점: URL이 노출되면 유효 기간 동안 누구나 접근할 수 있습니다. 또한 브라우저 캐시 사용이 어렵습니다.

2. 백엔드 서버를 통한 방식:

   • 장점: 더 세밀한 접근 제어가 가능하고 브라우저 캐시를 활용할 수 있습니다.
   • 단점: 서버 리소스를 더 많이 사용하게 됩니다.

보안과 성능을 모두 고려한다면, 다음과 같은 하이브리드 접근 방식을 추천합니다:

1. 인증된 사용자에게만 짧은 유효 기간(예: 5-10분)의 presigned URL을 발급합니다.
2. 프론트엔드에서 이 URL을 사용해 이미지를 요청합니다.
3. 서버 측에서 사용자 인증과 권한을 철저히 확인한 후 URL을 발급합니다.
4. CDN을 사용하여 이미지 전송 속도를 개선하고, 적절한 캐시 정책을 설정합니다.

이 방식을 통해 서버 부하를 줄이면서도 보안을 유지하고, 성능도 개선할 수 있습니다. 또한 각 요청마다 사용자의 권한을 확인할 수 있어 더욱 안전한 서비스 구현이 가능합니다.
Sources
Amazon S3 examples using SDK for Java 2.x - AWS SDK Code Examples
Create a presigned URL for Amazon S3 using an AWS SDK - AWS SDK Code Examples
Amazon S3 examples using SDK for Python (Boto3) - AWS SDK Code Examples
Create a presigned URL for Amazon S3 using an AWS SDK - Amazon Simple Storage Service

안녕하세요. 문의 주신 내용을 정리해드립니다.

요청하신 내용을 기반으로 보면, S3 버킷을 Private으로 유지하면서 동일한 URL을 계속 사용하되, 특정 사용자에게만 선택적으로 객체를 제공하려는 요구사항으로 확인됩니다. 다만, 현재 운영 중인 서비스의 인증 방식이나 접근 패턴이 구체적으로 공유되지 않았기 때문에, 이 답변에서는 AWS에서 일반적으로 활용되는 접근 제어 옵션과 구성 방식 위주로 설명드리겠습니다. 실제 서비스 반영을 위해서는 애플리케이션 단의 인증 로직과 함께 검토가 필요할 수 있습니다.

하나의 URL을 이용해 비공개 S3 버킷의 객체를 선택적으로 일부 클라이언트에게만 제공하는 것이 목적이실 경우 이는 S3와 CloudFront를 함께 사용하여 달성하실 수 있습니다.

먼저, 고객이 고려하셨던 대표적인 대안들에 대해 간단히 정리하면 다음과 같습니다.

1. S3 Presigned URL 활용

Presigned URL은 URL 자체가 권한이기 때문에, 해당 URL만 알고 있다면 누구나 접근할 수 있습니다. 또한 반드시 만료 기간이 포함되어야 하며 최대 7일까지만 설정되기 때문에, 장기간 고정된 링크 유지나 사용자 단위 접근 제어에는 적합하지 않은 방식입니 다. [1]

2. 백엔드 프록시를 통한 S3 바이너리 반환

S3 URL을 외부에 노출하지 않을 수 있으나, 바이너리 자체는 그대로 전달되기 때문에 해당 응답이 유출될 경우 다른 사용자에게 콘텐츠가 공유될 가능성이 있습니다. 또한 트래픽 비용이 전부 애플리케이션 레이어를 거치며 부하 측면에서도 고려가 필요합니다.

이러한 점 등을 고려했을 때에, S3와 함께 CloudFront를 앞단에 배치하여 접근을 통제하는 구성이 요구사항과 더 부합할 가능성이 높습니다. 이때 CloudFront + Origin Access Control(OAC) + Signed Cookies 조합을 함께 사용하실 수 있습니다.

CloudFront에서는 다음과 같은 방식으로 접근 제어를 구현할 수 있습니다.

1. S3는 Private으로 유지하고 CloudFront만 접근하도록 제한

Origin Access Control(OAC)을 적용하면 S3는 외부 요청을 직접 받지 않고, CloudFront의 서명된 요청만 허용하게 됩니다. 이를 통해 버킷은 완전히 비공개로 유지되며, 객체는 CloudFront를 통해서만 제공됩니다.[2]

2. CloudFront Signed Cookies 기반 접근 제어

Signed Cookie를 사용하면 URL을 변경하지 않고도, 유효한 쿠키를 가진 요청에만 콘텐츠 제공이 가능합니다. 애플리케이션에서 인증된 사용자에게만 쿠키를 발급하도록 설계할 수 있으며, CloudFront는 쿠키 서명만 검증합니다. 동일 URL 패턴으로 여러 객체 접근 제어가 필요한 경우 Signed URL보다 더 유연합니다. [3][4]

3. 보안 고려 요소

Signed Cookie 역시 유출되면 의도치 않은 접근이 발생할 수 있습니다. 따라서 만료 기간 최소화, IP 범위 제한, HTTPS 강제 적용 등의 추가 정책을 함께 사용하시길 권장드리며, 사전에 반드시 테스트를 통해 검증 부탁드립니다.[4]

정리하면, 동일한 URL을 유지하면서 사용자 기반 접근 제어를 구현하려는 경우 CloudFront(OAC)와 Signed Cookie 조합이 일반적으로 활용되는 구조입니다. 다만 최종 구현을 위해서는 S3와 CloudFront 설정뿐 아니라 운영 중인 서비스 단에서의 인증·인가 절차와 요구사항도 함께 고려해야 하므로, 위 내용을 서비스 전체 흐름과 함께 검토해보시면 좋겠습니다.

추가적으로 구성 중 의도치 않은 동작이나 확인이 필요한 부분이 있다면 언제든지 알려주세요. 감사합니다.

References

[1] Download and upload objects with presigned URLs - https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/using-presigned-url.html

[2] Restricting Access to an Amazon S3 Origin - https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html

[3] Choosing Between Signed URLs and Signed Cookies - https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-choosing-signed-urls-cookies.html

[4] Use signed cookies - https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-cookies.html

[5] Remediating exposures for Amazon S3 buckets - https://docs.aws.amazon.com/securityhub/latest/userguide/exposure-s3-bucket.html