Рекомендации по доступу клиентов к облачному хранилищу

Допустим, у меня есть вариант использования, когда пользователи могут покупать mp3-файлы внутри приложения. Объекты хранятся в облачном хранилище GCP. Как лучше всего доставлять эти объекты только тем пользователям, которые приобрели файлы?

Изучив тему, я пришел к трем решениям:

  1. Клиент вызывает службу REST (например, службу, работающую внутри App Engine). Эта служба загружает файлы из облачного хранилища, а затем отправляет их обратно клиенту.
  2. Вместо того, чтобы отправлять файлы через вызов REST, я мог бы отправить URL-адрес загрузки (из облачного хранилища) клиенту. Это было бы более экономично, однако для меня это звучит как проблема безопасности, поскольку любой, кто просто отслеживает свою сеть, может перехватить URL-адрес.
  3. Создание (ограниченного по времени) подписанного URL-адреса, чтобы пользователь мог загрузить

Очевидно, что сначала должна произойти проверка разрешения, например. база данных, содержащая информацию о том, купил ли пользователь X mp3 Y.

Эта проблема также может быть применена к хранилищу BLOB-объектов Azure или AWS S3...


google-cloud-storage amazon-s3 azure-blob-storage
person Yoey    schedule 16.10.2019    source источник
comment
Я не архитектор, поэтому ПОЖАЛУЙСТА, будьте осторожны. Моя интуиция говорит оставлять файлы, которые вы хотите предоставить заказчику, исключительно на GCS. НЕ разрешайте клиентам прямой доступ к этим файлам. Держите их исключительно ОТ Интернета. Затем ваш клиент конечного пользователя (браузер или приложение) будет подключаться к приложению, работающему на GCP (App Engine, CE, K8S, Cloud Function, Cloud Run и т. д.). Когда логика аутентифицирует пользователя и наступает время предоставить ему данные, ваше вычислительное приложение считывает данные GCS и передает их конечному пользователю. Это может быть ответ REST, WebSocket или обычный TCP.   -  person Kolban    schedule 17.10.2019
comment
Мое мнение по этому поводу было бы выбрать 3-й вариант. Второй немного непоследователен в вопросах безопасности, а первый, вероятно, будет немного медленным. Вы также можете выбрать 1-й, но рассмотрите возможность использования параллелизма при загрузке. Не забывайте разрабатывать в соответствии с передовыми практиками для облачного хранилища по соображениям эффективности и безопасности — cloud .google.com/storage/docs/best-practices .   -  person Andrei Tigau    schedule 17.10.2019
comment
Что касается шаблона архитектурного проектирования, я бы рекомендовал реализовать шаблон Ambassador со службой для обработки запросов, мониторинга процесса, уровней безопасности и политик повторного запуска. docs.microsoft.com/en-us/azure/architecture/patterns/ посол   -  person Andrei Tigau    schedule 17.10.2019

Ответы (1)


arrow_upward
0
arrow_downward

В вашем случае использования у вас есть константа:

  • Для аутентификации пользователя требуется серверная часть (например, аутентификация, выполняемая с помощью Cloud Identity Platform). и размещены на App Engine или Облачный запуск
  • Вам необходимо проверить список MP3, который он купил (например, хранится в Firestore)
  • И затем вам нужно разрешить ему загружать файл. Что касается последнего пункта, я рекомендую вам сгенерировать signedURL. URL-адрес загрузки существует только в области Firebase (возможно, ваш проект является projet?), но это то же самое, что и signerURL. Наконец, я не рекомендую вам предложение №1. Это будет работать, но в случае долгой загрузки (из-за плохой сети) соединение будет прервано через 60 секунд. И это будет поддерживать ваш AppEngine впустую (и вы за это заплатите...).
person guillaume blaquiere    schedule 17.10.2019
comment
Да, это проект Firebase. Поэтому я мог пройти аутентификацию с помощью Firebase Authentication и даже использовать облачные функции. Купленный чек будет сделан с Firestore. Я не знал, что загрузка будет прервана через 60 секунд, в этом случае мой первый подход был бы вообще невозможен. - person Yoey; 17.10.2019
comment
Хостинг Firebase — это просто более высокий API стандарта AppEngine, и ограничения те же. Здесь ссылка на ограничение в хостинга firebase (не так ясно, как документация Google Cloud) - person guillaume blaquiere; 17.10.2019