То, как сделать изображения, разместило на Amazon S3 меньше общественности, но не абсолютно частное?
Я разжег пример приложения, который использует Amazon S3 для хостинга изображений. Мне удалось подключить его коаксиальным кабелем в работу. Приложение размещается по github.com. Приложение позволяет Вам создать пользователей с фотографией профиля. При загрузке фотографии веб-приложение хранит ее на Amazon S3 вместо локальной файловой системы. (Очень важный, если Вы размещаете по heroku.com),
Однако, когда я сделал "источник представления", в браузере страницы я заметил, что URL изображения был URL Amazon S3 в блоке S3, который я присвоил приложению. Я сократил и вставил URL и смог просмотреть изображение в том же браузере, и в в другом браузере, в котором у меня не было открытых заседаний к моему веб-приложению или к Amazon S3.
Есть ли какой-либо способ, которым я мог ограничить доступ к тому URL (и изображение) так, чтобы это было доступно только для браузеров, которые зарегистрированы в мои приложения?
Большая часть информации я нашел о Amazon ACLs только, говорит о доступе только для владельца или группам пользователей, аутентифицируемых с Amazon или AmazonS3, или всем анонимно.
РЕДАКТИРОВАНИЕ----ОБНОВЛЕНИЕ 7 июля 2010
Amazon только что объявил о большем количестве способов ограничить доступ к объектам S3 и блокам. Среди других путей можно теперь ограничить доступ к объекту S3 путем квалификации ссылающегося домена HTTP. Это выглядит интересным... Я не могу ждать, пока они не обновляют свои документы разработчика.
3 ответа
S3 - это отдельный сервис, который не знает о ваших сеансах.
Общее решение состоит в том, чтобы распознать преимущества и свойства безопасности, которые присваивают каждому активу отдельный, уникальный, очень длинный и случайный ключ, который составляет часть URL-адреса этого актива. Если вы так решите, вы даже можете назначить ключ с 512 эффективными битами случайности, и этот URL-адрес будет оставаться нераспознаваемым в течение очень долгого времени.
- Поскольку кто-то, кто в момент
tимеет доступ к активу, может просто скопировать актив для дальнейшего использования, имеет смысл разрешить этому человеку знать URL-адрес и получить доступ к активу в любое время. - Аналогичным образом, поскольку этот человек может просто загрузить актив и распространить его среди других, имеет смысл разрешить этому человеку распространять URL среди других, которым он в противном случае просто распространил бы сам актив.
- Поскольку весь такой доступ предоставляется только для чтения, а запись ограничена серверами веб-сайта, риск злонамеренного «взлома» со стороны любого, у кого есть такой доступ, отсутствует.
Вы должны определить, является ли это достаточной защитой. Если это не так, то, возможно, S3 не для вас, и, возможно, вам нужно сохранить свои изображения в виде двоичных столбцов в своей базе данных и кэшировать их в memcached, что вы можете сделать на Heroku.
Для файлов, конфиденциальность которых действительно имеет значение, мы обрабатываем это следующим образом:
- Файлы хранятся с частным ACL, что означает, что только авторизованный агент может загружать (или выгружать) их
- Для доступа к файлу мы связываем на
http://myapp.com/download/ {s3-path}, гдезагрузкасоответствует контроллеру (в смысле MVC) - ACL реализованы соответствующим образом, поэтому что только зарегистрированные пользователи могут получить доступ к этому контроллеру / действию
- Этот контроллер загружает файл с помощью API, затем передает его пользователю с правильным типом mime, заголовками кеша, размером файла и т. д.
Используя это метод, вы в конечном итоге используете гораздо большую пропускную способность, чем вам нужно, но вы все равно экономите на хранилище. Для нас это работает, потому что у нас, как правило, заканчивается хранилище гораздо быстрее, чем пропускная способность.
Для файлов, для которых важна лишь конфиденциальность, мы генерируем случайный хэш, который используем для URL-адреса. По сути, это безопасность через неясность, и вы должны быть осторожны, чтобы ваш хеш было достаточно сложно угадать.
Однако, когда я сделал «просмотр исходного кода» в браузере страницы, я заметил, что URL-адрес изображения был URL-адресом Amazon S3 в корзине S3, которую я назначил приложению. Я вырезал и вставил URL-адрес и смог просмотреть изображение в том же браузере и в другом браузере, в котором у меня не было открытых сеансов с моим веб-приложением или Amazon S3.
Имейте в виду, что это ничем не отличается от любого изображения, хранящегося в другом месте в корне вашего документа. Вы можете нуждаться или не нуждаться в той защите, которую вы ищете.
Думаю, лучшее, что вы можете сделать, это то, что делает drop.io. Хотя данные в принципе доступны для всех, вы даете им большой и случайный URL. Любой, кто знает URL-адрес, может получить к нему доступ, но ваше приложение контролирует, кто получит этот URL-адрес.
Вид безопасности через безвестность.
Вы можете думать об этом как о пароле, включенном в URL. Это означает, что если вы серьезно относитесь к безопасности, вы должны относиться к URL-адресу как к конфиденциальной информации. Вы должны убедиться, что эти ссылки также не попадают в поисковые системы.
Также сложно отозвать права доступа. Единственное, что вы можете сделать, - это аннулировать URL-адрес и назначить новый.