Как сделать изображения, размещенные на Amazon S3, менее общедоступными, но не полностью приватными?

Question

Я запустил пример приложения, которое использует Amazon S3 для размещения изображений. Мне удалось заставить его работать. Приложение размещено на github.com . Приложение позволяет создавать пользователей с фотографией профиля. Когда вы загружаете фотографию, веб-приложение сохраняет ее на Amazon S3 вместо локальной файловой системы. (Очень важно, если вы ведете на heroku.com )

Однако, когда я сделал «просмотр источника» в браузере страницы, я заметил, что URL-адрес картинки был URL-адресом Amazon S3 в корзине S3, которую я назначил приложению. Я вырезал и вставил URL-адрес и смог просмотреть изображение в том же браузере и в другом браузере, в котором у меня не было открытых сеансов для моего веб-приложения или Amazon S3.

Можно ли как-нибудь ограничить доступ к этому URL (и изображению), чтобы он был доступен только для браузеров, которые вошли в мои приложения?

Большая часть информации, которую я нашел о списках ACL Amazon, говорит только о доступе только для владельца или групп пользователей, аутентифицированных с помощью Amazon или AmazonS3, или для всех анонимно.

РЕДАКТИРОВАТЬ ---- ОБНОВЛЕНИЕ 7 июля 2010

У Amazon есть только что анонсированный больше способов ограничить доступ к S3-объектам и корзинам. Помимо прочего, теперь вы можете ограничить доступ к объекту S3, указав ссылку HTTP. Это выглядит интересно ... Я не могу ждать, пока они обновят свои документы разработчика.

Answer 1

Для файлов, где конфиденциальность действительно имеет значение, мы обрабатываем это следующим образом:

• Файлы хранятся с частным ACL, что означает, что только уполномоченный агент может загрузить (или загрузить) их
• Чтобы получить доступ к файлу, мы ссылаемся на http://myapp.com/download/{s3-path}, где download соответствует контроллеру (в смысле MVC)
• ACL реализованы соответствующим образом, так что только зарегистрированные пользователи могут получить доступ к этому контроллеру./ action
• Этот контроллер загружает файл с помощью API, а затем передает его пользователю с правильным типом mime, заголовками кэша, размером файла и т. д.

Используя этот методв итоге вы используете гораздо большую полосу пропускания, чем вам нужно, но вы все равно экономите на хранилище.Для нас это работает, потому что мы стремимся исчерпать хранилище намного быстрее, чем пропускная способность.

Для файлов, где важна только конфиденциальность, мы генерируем случайный хеш, который мы используем для URL.В основном это защита от неизвестности, и вы должны быть осторожны, чтобы угадать ваш хеш достаточно сложно.

Однако, когда я сделал «просмотр источника» в браузере страницы, я заметил, чтоURL-адрес изображения был URL-адресом Amazon S3 в корзине S3, которую я назначил приложению.Я вырезал и вставил URL-адрес и смог просмотреть изображение в том же браузере и в другом браузере, в котором у меня не было открытых сеансов для моего веб-приложения или для Amazon S3.

Сохранить вИмейте в виду, что это ничем не отличается от любого изображения, хранящегося в другом месте в корне вашего документа.Вам может понадобиться, а может и не быть, тот тип безопасности, который вы ищете.

Answer 2

Amazon Ruby SDK (https://github.com/aws/aws-sdk-ruby) имеет полезные методы, которые позволяют легко это сделать. "Url_for" может генерировать временный читаемый URL для в противном случае частного объекта S3.

Вот как создать читаемый URL, срок действия которого истекает через 5 минут:

object = AWS :: S3.new.buckets ['BUCKET']. Objects ['KEY']

object.url_for (: read,: expires => 300) .to_s

Документация AWS: http://docs.aws.amazon.com/AWSRubySDK/latest/AWS/S3/S3Object.html#url_for-instance_method

Answer 3

S3 является отдельной службой и не знает о ваших сессиях.

Общее решение заключается в распознавании преимуществ и свойств безопасности, которые присваивают каждому активу отдельный, уникальный и очень длинный и случайный ключ, который является частью URL-адреса этого актива. При желании вы можете даже назначить ключ с 512 эффективными битами случайности, и этот URL будет оставаться неуязвимым в течение очень долгого времени.

• Поскольку тот, кто на момент t имеет доступ к активу, может просто скопировать актив для использования в будущем, имеет смысл разрешить этому человеку в любое время узнать URL-адрес и получить доступ к активу.
• Аналогичным образом, поскольку этот человек может просто загрузить ресурс и распространить его среди других, имеет смысл разрешить этому человеку распространять URL-адрес среди тех, кому он в противном случае просто распространил бы сам актив.
• Поскольку весь такой доступ предназначен только для чтения и записи разрешены только для серверов веб-сайтов, нет риска злонамеренного "взлома" со стороны тех, кто имеет такой доступ.

Вы должны определить, достаточно ли это безопасности. Если это не так, то, возможно, S3 не для вас, и, возможно, вам нужно хранить изображения в виде двоичных столбцов в базе данных и кэшировать их в memcached, что вы можете сделать в Heroku.

Answer 4

Я думаю, что лучшее, что вы можете сделать, это то, что делает drop.io. Хотя данные в принципе доступны для всех, вы даете им большой и случайный URL. Любой, кто знает URL, может получить к нему доступ, но ваше приложение контролирует, кто увидит URL.

Вид безопасности через безвестность.

Вы можете думать об этом как о пароле, включенном в URL. Это означает, что если вы серьезно относитесь к безопасности, вы должны рассматривать URL как конфиденциальную информацию. Вы должны убедиться, что эти ссылки также не попадают в поисковые системы.

Также сложно отозвать права доступа. Единственное, что вы можете сделать, это сделать недействительным URL-адрес и назначить новый.