Реализация Rails для защиты документов S3

Я бы хотел защитить мои s3-документы за помощью rails app, чтобы, если я перейду к:

www.myapp.com/attachment/5, который должен аутентифицировать пользователя перед отображением/загрузкой документа.

Я прочитал похожие вопросы о stackoverflow, но я не уверен, что видел хорошие выводы.

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

1) Обфускайте URL-адрес. Я сделал это. Я думаю, что это хорошо, поэтому никто не может угадать URL. Например, было бы легко "прогуливать" URL-адрес, если ваши URL-адреса S3 очевидны: https://s3.amazonaws.com/myapp.com/attachments/1/document.doc. Наличие URL-адреса, такого как: https://s3.amazonaws.com/myapp.com/7ca/6ab/c9d/db2/727/f14/document.doc кажется намного лучше. Это здорово делать, но не решает проблему передачи URL-адресов по электронной почте или веб-сайтам.

2) Используйте URL-адрес истечения срока действия, как показано ниже: Rails 3, paperclip + S3 - Howto Store для экземпляра и защиты доступа Для меня, однако, это не отличное решение, потому что URL-адрес отображается (даже на короткий период времени), и другой пользователь может, возможно, со временем повторно использовать URL-адрес. Вы должны настроить время для загрузки, не предоставляя слишком много времени для копирования. Это похоже на неправильное решение.

3) Прокси загрузите документ через приложение. Сначала я попытался просто использовать send_file: http://www.therailsway.com/2009/2/22/file-downloads-done-right, но проблема в том, что эти файлы могут быть только статическими/локальными файлами на вашем сервере и не обслуживается через другой сайт (S3/AWS). Однако я могу использовать send_data и загружать документ в свое приложение и сразу же обслуживать документ для пользователя. Проблема с этим решением очевидна - в два раза больше полосы пропускания и в два раза больше времени (для загрузки документа в мое приложение, а затем обратно к пользователю).

Я ищу решение, обеспечивающее полную безопасность # 3, но не требующее дополнительной пропускной способности и времени для загрузки. Похоже, что Basecamp "защищает" документы за своим приложением (через аутентификацию), и я полагаю, что другие сайты делают что-то подобное, но я не думаю, что они используют мое решение № 3.

Предложения были бы с благодарностью.

UPDATE

Я пошел с 4-м решением:

4) Для управления доступом к файлам на основе referrer используйте политики amazon bucket: http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?UsingBucketPolicies.html

UPDATE AGAIN:

Ну # 4 можно легко обойти с помощью инструмента разработчика браузеров. Поэтому я все еще ищут прочное решение.

ОТВЕТЫ

Ответ 1

Я бы проголосовал за номер 3, это единственный действительно безопасный подход. Потому что, как только вы передадите пользователю URL-адрес S3, действительный до истечения срока его действия. Ловкий пользователь может использовать эту дыру, единственный вопрос, повлияет ли это на ваше приложение? Возможно, вы могли бы установить, чтобы время истечения было ниже, что минимизировало бы риск? Взгляните на выдержку из этой публикации: Доступ к закрытым объектам из браузера

Все частные объекты доступны через аутентифицированный запрос GET для S3 сервера. Вы можете создать аутентифицированный URL-адрес для объекта, такого как это:

S3Object.url_for('beluga_baby.jpg', 'marcel_molina')

По умолчанию аутентифицированные URL-адреса истекают 5 минут после того, как они были сгенерированы.

Можно указать параметры срока действия либо с абсолютным временем, так как эпоха с параметрами: expires, или с несколькими секундами относительно теперь с параметрами: expires_in:

Ответ 2

Я уже давно пытаюсь сделать что-то подобное. Если вы не хотите использовать пропускную способность дважды, то единственный способ, который это возможно, - позволить S3 сделать это. Теперь я полностью с вами о выставленном URL. Вы могли придумать любую альтернативу?

Я нашел кое-что, что может быть полезно в этом отношении - http://docs.aws.amazon.com/AmazonS3/latest/dev/AuthUsingTempFederationTokenRuby.html

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