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

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

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

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

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

EDIT - ОБНОВЛЕНИЕ 7 июля 2010 г.

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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

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

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

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