Безопасное использование хранилища Azure в приложении Electron
Я создаю приложение для обмена видео для записи и обмена игровыми клипами. Недавно я добавил облачное хранилище в качестве функции, в которой использую Azure SDK для Node для взаимодействия с учетной записью хранения, куда загружаются видео и метаданные. Пока все работает хорошо. Моя цель — продать функцию облачного хостинга за небольшую ежемесячную подписку.
Электронный клиент принимает имя учетной записи хранения и ключ доступа. Он имеет свободный контроль над учетной записью хранения и может загружать столько, сколько пожелает, без ограничений. Это меня пугает, поскольку я не хочу получить большой счет за Azure.
Я предполагал, что в Azure будут средства управления для создания учетных записей хранения с меньшими привилегиями и/или контейнеров с налагаемыми ограничениями на размер. Однако, похоже, ничего из этого не существует.
Итак, мой вопрос; как я могу безопасно раздать своим пользователям учетные данные, которые позволяют ограничить чтение и запись в учетную запись хранения Azure?
Кажется, что я мог бы настроить сервер аутентификации, который действует как прокси-сервер для каждого запроса к моей учетной записи хранения Azure, используя механизмы подписи в Azure, но мне кажется, что это слишком усложняет то, что кажется базовым вариантом использования? Если нет изящного решения, предлагают ли другие облачные провайдеры что-то подходящее?
Ответы 1
Электронный клиент принимает имя учетной записи хранения и ключ доступа. Это имеет полную свободу управления учетной записью хранения и может загружать столько, сколько необходимо. лайков без ограничений. Это меня пугает, так как я не хочу, чтобы меня ударили большой лазурный счет.
Вы правы в своем понимании. Ключ учетной записи не только дает полный контроль над учетной записью хранения, но и создает большую проблему, если вам по какой-либо причине придется заменить ключ учетной записи (всем вашим пользователям потребуется загрузить новую версию приложения).
Я предполагал, что в Azure будут средства управления для создания меньших привилегий. учетные записи хранения и/или контейнеры с наложенными ограничениями на размер. Однако, ничего из этого, кажется, не существует.
Правильно. Невозможно создавать учетные записи с меньшими привилегиями или налагать ограничения на размер контейнеров «из коробки». Это то, с чем вам придется справиться самостоятельно.
Итак, мой вопрос; как я могу безопасно раздавать учетные данные своим пользователям которые позволяют ограничить чтение и запись в хранилище Azure. счет?
Ознакомьтесь с функцией Подпись общего доступа в хранилище Azure. Он позволяет создавать URL-адреса SAS, которые предоставляют пользователям ограниченный по времени и разрешению доступ к вашей учетной записи хранения.
Вам все равно потребуется реализовать прокси. В обязанности этого прокси-сервера будет входить генерация токенов SAS. В зависимости от желаемого контроля и безопасности вы можете реализовать этот прокси-сервер двумя способами:
- Управляйте загрузкой через этот прокси. По сути, вашим пользователям всегда придется проходить через этот прокси. Когда они пытаются что-то загрузить, они сначала отправляют контент на ваш прокси. Содержимое пройдет проверку и оттуда будет записано в хранилище Azure.
Недостатком этого подхода является то, что все маршрутизируется через этот прокси-сервер, и вам может потребоваться очень надежная инфраструктура для обработки запросов пользователей, но она очень безопасна и дает вам много контроля.
- Использовать прокси-сервер для генерации токенов SAS. Вы можете использовать этот прокси-сервер для генерации только токенов SAS. Это будет работать так: когда пользователь пытается загрузить что-то в ваше приложение, вы отправляете метаданные этих данных (например, имя файла, тип файла, размер и т. д.) и выполняете некоторую проверку (например, размер не превышает установленный размер). ограничения или тип файла соответствует поддерживаемому типу и т. д.). После успешной проверки вы создадите URL-адрес SAS и отправите его обратно в свое приложение. Если проверка не удалась, вместо этого вы возвращаете ошибку. Код вашего приложения затем будет использовать этот URL-адрес SAS для прямой загрузки содержимого в хранилище Azure.
Однако имейте в виду, что URL-адреса SAS могут быть использованы не по назначению. Например, они могут отправить вам информацию о файле небольшого размера, получить URL-адрес SAS и каким-то образом использовать этот URL-адрес для загрузки другого файла. Вам необходимо будет защитить свое приложение от таких случаев использования.
Эта ссылка может оказаться полезной для ознакомления с лучшими практиками использования SAS: https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview#best-practices-when-using-sas.
Хм, вообще-то, согласно вашему ответу здесь: stackoverflow.com/questions/73902354/… невозможно включить ограничение по размеру в URL-адрес SAS.
it is not possible to include the restriction by size in the SAS URL - Это еще так. Извините, если я не ясно выразился в ответе. Я хочу сказать, что когда вы получаете метаданные (которые будут содержать размер файла) на вашем прокси-уровне, вы можете проверить размер файла и вернуть пользователю ошибку, если файл, который он пытается загрузить, превышает допустимый размер. Но да, этим все равно можно злоупотреблять.
Неправильное использование в том смысле, что они могут отправить информацию о небольшом файле, получить от вас токен и использовать его для загрузки большого файла. Обновил и мой ответ.
Жаль, это было бы действительно изящное решение, но без дополнительных сложностей. В любом случае, спасибо за отличный ответ.
Спасибо за подробный ответ. Наличие прокси-сервера, через который проходят все загрузки, похоже, будет работать хорошо, но, вероятно, это слишком большая инфраструктура для моего проекта. Другой вариант звучит хорошо. Чего мне здесь не хватало, так это возможности генерировать токен SAS, специфичный для размера файла. Я не смог найти в документации ничего, подтверждающего это, но я попробую SDK. Я предполагал, что URL-адрес SAS будет просто сообщать: «вот URL-адрес, на который у вас есть разрешение на загрузку в течение следующего часа», и ничто не сможет остановить вредоносную загрузку 1 ПБ.