2010-03-31 15 views
14

Tôi đã khởi chạy một ứng dụng mẫu sử dụng Amazon S3 để lưu trữ hình ảnh. Tôi quản lý để dỗ nó vào làm việc. Ứng dụng được lưu trữ tại github.com. Ứng dụng cho phép bạn tạo người dùng bằng ảnh tiểu sử. Khi bạn tải ảnh lên, ứng dụng web lưu trữ nó trên Amazon S3 thay vì hệ thống tệp cục bộ của bạn. (Rất quan trọng nếu bạn lưu trữ tại heroku.com)Làm thế nào để làm cho hình ảnh được lưu trữ trên Amazon S3 ít công khai hơn nhưng không hoàn toàn riêng tư?

Tuy nhiên, khi tôi đã thực hiện "nguồn xem" trong trình duyệt của trang, tôi nhận thấy URL của hình ảnh là URL Amazon S3 trong nhóm S3 mà tôi đã gán cho ứng dụng. Tôi đã cắt & dán URL và có thể xem ảnh trong cùng một trình duyệt và trong một trình duyệt khác mà trong đó tôi không có phiên mở nào cho ứng dụng web của tôi hoặc Amazon S3.

Có cách nào để hạn chế quyền truy cập vào URL đó (và hình ảnh) để chỉ có thể truy cập vào các trình duyệt được đăng nhập vào các ứng dụng của tôi không?

Hầu hết thông tin tôi tìm thấy về Amazon ACL chỉ nói về quyền truy cập chỉ cho chủ sở hữu hoặc nhóm người dùng được xác thực với Amazon hoặc AmazonS3 hoặc cho mọi người nặc danh.

EDIT ---- CẬP NHẬT ngày 07 tháng 7 năm 2010

Amazon có hơn just announced cách để hạn chế truy cập vào các đối tượng S3 và xô. Trong số các cách khác, bây giờ bạn có thể hạn chế quyền truy cập vào đối tượng S3 bằng cách đủ điều kiện tham chiếu HTTP. Điều này có vẻ thú vị ... Tôi không thể đợi cho đến khi họ cập nhật tài liệu nhà phát triển của họ.

Trả lời

3

S3 là một dịch vụ riêng biệt và không biết về các phiên của bạn.

Giải pháp chung là nhận ra lợi ích và thuộc tính bảo mật gán cho mỗi nội dung một khóa riêng biệt, độc đáo, rất dài và ngẫu nhiên, tạo thành một phần của URL cho nội dung đó. Nếu bạn chọn, bạn thậm chí có thể gán một khóa với 512 bit ngẫu nhiên hiệu quả và URL đó sẽ vẫn không thể chấp nhận được trong một thời gian rất dài.

  • Do ai đó có thời gian sao chép tài sản để tham khảo trong tương lai, nên cho phép người đó biết URL và truy cập nội dung bất kỳ lúc nào. Tương tự như vậy, vì người đó chỉ đơn giản có thể tải xuống nội dung và phân phát nội dung cho người khác, nên có nghĩa là cho phép người đó phân phối URL cho những người khác mà người đó chỉ đơn giản phân phối nội dung đó.
  • Vì tất cả quyền truy cập như vậy là chỉ đọc và do việc viết bị hạn chế đối với máy chủ trang web, nên không có nguy cơ "tấn công" độc hại từ bất kỳ ai có quyền truy cập này.

Bạn phải xác định xem điều này có đủ bảo mật hay không. Nếu không, thì có lẽ S3 không phải dành cho bạn, và có thể bạn cần phải lưu trữ hình ảnh của bạn dưới dạng cột nhị phân trong cơ sở dữ liệu của bạn và lưu trữ chúng trong memcached, mà bạn có thể làm trên Heroku.

+0

@Justice - Cảm ơn bạn đã có câu trả lời hoàn chỉnh và rất hợp lý. Đó chính xác là lý do tôi cần để sử dụng S3. Các tài sản được lưu trữ trên S3 không phải là siêu quan trọng như xa như sự riêng tư đi, và các URL chỉ có sẵn cho người dùng đăng nhập. Tôi cho rằng tôi phải làm một số loại băm muối để tạo ra số ngẫu nhiên. –

+1

+1 cho điểm logic. Tạo một url ngẫu nhiên mới cho mỗi cập nhật cho tài nguyên cũng rất quan trọng. –

1

Tôi nghĩ tốt nhất bạn có thể làm là drop.io làm gì. Mặc dù dữ liệu về nguyên tắc có thể truy cập được đối với bất kỳ ai, nhưng bạn cung cấp cho nó một URL lớn và ngẫu nhiên. Bất kỳ ai biết URL đều có thể truy cập, nhưng ứng dụng của bạn kiểm soát những người được xem URL.

Loại bảo mật thông qua sự tối tăm.

Bạn có thể coi đó là mật khẩu được bao gồm trong URL. Điều này có nghĩa là nếu bạn nghiêm túc về bảo mật, bạn phải coi URL là thông tin bí mật. Bạn phải đảm bảo rằng các liên kết này không bị rò rỉ cho các công cụ tìm kiếm.

Cũng khó để thu hồi quyền truy cập. Điều duy nhất bạn có thể làm là vô hiệu hóa một URL và gán một URL mới.

9

Đối với các file mà sự riêng tư thực sự quan trọng, chúng tôi xử lý này như sau:

  • tập tin được lưu trữ với một ACL tin, có nghĩa là chỉ có một đại lý ủy quyền có thể tải về (hoặc tải lên) họ
  • Để truy cập tập tin, chúng tôi liên kết đến http://myapp.com/download/{s3-path}, nơi download tương ứng với một bộ điều khiển (theo nghĩa MVC)
  • ACL được thực hiện phù hợp để chỉ đăng nhập người dùng có thể truy cập điều khiển/hành động
  • đó khiển tải t anh ấy sử dụng API, sau đó truyền cho người dùng với các loại mime, tiêu đề bộ nhớ cache, kích thước tệp chính xác, v.v.

Sử dụng phương pháp này, bạn sử dụng nhiều băng thông hơn mức bạn cần, nhưng bạn vẫn lưu trữ. Đối với chúng tôi, điều này hoạt động, bởi vì chúng tôi có xu hướng hết dung lượng nhanh hơn băng thông.

Đối với các tệp chỉ có vấn đề về quyền riêng tư, chúng tôi tạo một băm ngẫu nhiên mà chúng tôi sử dụng cho URL. Đây là cơ bản bảo mật thông qua tối tăm, và bạn phải cẩn thận rằng băm của bạn là đủ khó đoán.

Tuy nhiên, khi tôi đã thực hiện "nguồn xem" trong trình duyệt của trang, tôi nhận thấy URL của hình ảnh là URL Amazon S3 trong nhóm S3 mà tôi đã gán cho ứng dụng. Tôi đã cắt & dán URL và có thể xem ảnh trong cùng một trình duyệt và trong một trình duyệt khác mà trong đó tôi không có phiên mở nào cho ứng dụng web của tôi hoặc Amazon S3.

Hãy nhớ rằng điều này không khác với bất kỳ hình ảnh nào được lưu trữ ở nơi khác trong gốc tài liệu của bạn. Bạn có thể hoặc không cần loại bảo mật mà bạn đang tìm kiếm.

+0

Nếu bạn * thực sự * cần ACL, đây chắc chắn là cách thực hiện.Tuy nhiên, trên Heroku, và tùy thuộc vào các mẫu truy cập cho các tài sản này, chiến lược này sẽ buộc bạn phải "quây dynos của bạn" nhanh hơn nhiều so với cách khác. – yfeldblum

+0

Công lý: Tôi không chắc chắn rằng nó tệ hơn là lưu trữ tệp cục bộ và truyền trực tuyến thông qua ứng dụng của bạn. Nếu bạn muốn khóa các tệp xuống theo bất kỳ cách nào không tầm thường, việc truyền trực tuyến qua ứng dụng về cơ bản là giải pháp duy nhất. Tất nhiên, vài ứng dụng có loại yêu cầu đó. Tôi cũng được sử dụng để làm việc trong môi trường máy chủ chuyên dụng, vì vậy có thể lời khuyên của tôi không áp dụng cho heroku. – notJim

+0

Cảm ơn bạn đã có câu trả lời rất hoàn chỉnh. –

5

SDK Ruby của Amazon (https://github.com/aws/aws-sdk-ruby) có các phương pháp hữu ích giúp bạn thực hiện việc này dễ dàng. "url_for" có thể tạo một URL có thể đọc tạm thời cho một đối tượng S3 khác.

Dưới đây là làm thế nào để tạo ra một URL có thể đọc được hết hạn sau 5 phút:.

đối tượng = AWS :: S3.new.buckets [ 'xô'] vật [ 'KEY']

đối tượng .url_for (: đọc,: hết hạn => 300) .to_s

AWS tài liệu: http://docs.aws.amazon.com/AWSRubySDK/latest/AWS/S3/S3Object.html#url_for-instance_method

+0

Chúng có tính năng tương tự cho các URL đã ký trong SDK PHP. http://docs.aws.amazon.com/aws-sdk-php/guide/latest/service-s3.html#creating-a-pre-signed-url Tôi nghĩ đây là giải pháp hiện tại tốt nhất cho áp phích này loại vấn đề. – Chris