Рельсы Activestorage и S3, хранящие конфиденциальные данные

Question

ActiveStorage позволяет загружать и получать доступ к файлам непосредственно на S3 через пользовательский браузер в JS. Означает ли это, что ваши учетные данные S3 встроены в браузер пользователя? Я думаю, что неправильно понимаю, это сделало бы ваши полномочия почти публичными ...

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

Какой будет хорошая архитектура безопасности?

Answer 1

Когда вы используете ActiveStorage с S3. Вам необходимо хранить учетные данные в переменных среды как таковых

Вам необходимо создать файл storage.yml

amazon:
  service: s3
  access_key_id: ENV["AWS_ACCESS_KEY_ID"]
  secret_access_key: ENV["AWS_SECRET_KEY"]
  region: ENV["AWS_REGION"]
  bucket: ENV["S3_BUCKET"]

Answer 2

Хорошая архитектура безопасности и, вероятно, это то, что реализовано в ActiveStorage:

1 - запрашивается страница с формой загрузки.

2 - запись блоба будет создана на стороне сервера и сохранена в базе данных (даже до того, как произойдет какая-либо загрузка). https://github.com/rails/rails/blob/0718c75bc2a7378d30e729a3c1d25ceb99400b7b/activestorage/app/models/active_storage/blob.rb#L70

3- Сервер вызывает стороннюю облачную службу (AWS S3 для примера) в бэкэнде и выдает предварительно назначенный URL-адрес, используя учетные данные AWS (секретные учетные данные и не должны быть доступны для общественности), которые будут использоваться для загрузки. https://github.com/rails/rails/blob/master/activestorage/lib/active_storage/service/s3_service.rb#L87

https://www.rubydoc.info/github/aws/aws-sdk-ruby/Aws%2FS3%2FObject:presigned_url

4 - Сервер отображает страницу с формой и встроенным presigned_url.

5- На этом этапе перед интерфейсом presigned_url будет сгенерирован сервер и выведен в форму.

6- Javascript будет захватывать этот presigned_url из HTML DOM и использовать его для загрузки.

7- После загрузки javascript будет иметь signed_id, который будет опубликован в форме на серверной стороне, чтобы обновить запись BLOB-объекта и пометить ее как загруженную (ту, которая была создана в шаге 1).

За :

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

2 - Вы можете загрузить, даже если сервер не работает.

3 - Ускоренный пользовательский опыт (меньше поездок в оба конца).

Против

1- временный токен может использовать любой, кто имеет к нему доступ для загрузки.

2- presigned_url имеет период действия (expires_at), и если браузер некоторое время простаивал перед выполнением фактической загрузки, браузер, вероятно, получит ошибку аутентификации. Может потребоваться выдать новый временный токен с сервера!?

Примечание:

• Сгенерированный presigned_url может иметь ограниченный доступ к определенной папке / области действия в зависимости от пользователя, прошедшего проверку подлинности, или им может быть предоставлен доступ к целой корзине / области отсутствия, если загруженные большие двоичные объекты являются общедоступными в соответствии с требованиями бизнеса.

Вот как signed uploads работает :) 1048 *

Answer 3

Ваши учетные данные S3 должны быть сохранены как переменные среды в вашем репо, а не жестко закодированы. В книге Hartls есть пример The Rails Tutorial.