Защищенные Blobs в Azure

Question

Каков наилучший способ защитить blobs в хранилище Windows Azure для определенного набора пользователей. например, у меня есть веб-сайт ASP.NET (интрасеть) на месте с фоновым хранилищем для Windows Azure для больших файлов. Мне нравится идея подписанного URL-адреса для безопасности для каждого отдельного блоба, но будет ли это действительно работать для blob, который будет там в течение длительного времени. (бесконечно?)

Мне нужны гранулированные уровни безопасности на блобе только для конкретных пользователей (как мне это легко достичь с помощью Blob Storage). * Примечание. Я считаю, что мне не нужен ACS. Я хочу достичь этого, используя Политики и Подписанный URL, если это возможно.

Второй вопрос, я предполагаю, что я также могу защитить эти данные в CDN таким же образом, может кто-нибудь подтвердить?

Благодаря

Shared политики доступа с бесконечным временем работы и привилегии на сгустка, например, читать работу?

Answer 1

Если вам нужно, чтобы blob был доступен отдельным пользователям более часа, вы должны использовать политику SAS, прикрепленную к контейнеру. Однако, поскольку вы можете иметь максимум 5 единиц в контейнере, он не будет хорошо масштабироваться для многих пользователей. Политика SAS может истекать через годы.

Более типичное решение для пользователя - поразить ваш сайт или услугу, и вы аутентифицируете их любым способом. Когда они действительно хотят загрузить файл, вы должны создать одноразовую подпись SAS с коротким сроком действия (а не политикой). Это хорошо масштабируется и предотвращает повторное использование неавторизованных пользователей позже. Вы также получаете преимущество от обслуживания от хранения, а не от своей веб-роли.

Все становится сложнее при использовании CDN. Таким образом, хотя вы можете использовать подпись SAS на ресурсе CDN, они не заслуживают похвалы. То есть уникальный URL-адрес является ключом к базовому ресурсу. Таким образом, когда вы запрашиваете защищенный blab-файл SAS, он просто вставляет его в CDN и обслуживает его с использованием этого URI в качестве ключа. Затем он будет использовать политику кэширования CDN (а не истечение срока действия SAS) для продолжения работы. Это может привести к сценарию, когда URI blob истекает через 10 минут, но CDN будет кэшировать этот blob с использованием той же SAS-сигнатуры в течение нескольких дней в зависимости от политики истечения срока действия. CDN никогда не свяжется с хранилищем для проверки. Следовательно, вероятно, это не очень хорошая идея. Кроме того, поскольку каждый ресурс CDN привязан к URI, это также означает, что каждый раз, когда будет изменена подпись SAS, вы будете кэшировать много копий одного и того же файла (запустив транзакцию и плату за пропускную способность). Короче говоря, CDN и SAS плохо смешиваются.

Answer 2

Я не могу помочь вам с CDN, поскольку у меня нет опыта использования этого, хотя я бы ожидал, что он будет работать аналогичным образом.

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

При запросе этого файла вы создаете подпись общего доступа на лету (см. here) и передайте ее пользователю.

Это имеет то преимущество, что загрузка файлов не перекачивается через вашу веб-роль, а загружается пользователю непосредственно из хранилища blob.