2010-06-24 2 views
3

Я пишу резервный сервис для резервного копирования базы данных SQL и сохранения его в облачном хранилище. Я уже реализовал это уже с Amazon S3, но поскольку приложение будет распространено среди клиентов, я не могу иметь ключи API, хранящиеся в приложении. Я рассматривал использование веб-службы для предоставления ключей, но это не мой лучший вариант в это время (потому что он по-прежнему оставляет возможность кражи ключей.)Подходит ли Azure Shared Access Signature для доступа к моим блобам?

Итак, я смотрел в Windows Azure, службу Blob и видел они имеют подписи общего доступа, которые могут использоваться для обеспечения доступа к ресурсам в облаке. Вы также можете использовать подпись, чтобы поместить капли в облаке. Но, прочитав через MSDN docs, я не могу не думать, что это небезопасная система. Любой, кто знает 1. точные имена контейнеров для моей учетной записи и 2. как сформировать подпись, сможет получить доступ к объектам. При использовании этой подписи вам не нужен секретный ключ. По крайней мере, это мое впечатление, читая документы.

Итак, наконец, на мой вопрос. Правильно ли я оцениваю подписи общего доступа с Azure, если нет, то почему? И может ли кто-нибудь предложить альтернативный способ сделать то, что я пытаюсь выполнить.

+0

Итак, теперь я вижу, что вы должны вычислить хэш-подпись, зашифровав ключом. Так что отвечает на мой первый вопрос (я был неправ в своей первоначальной оценке). Azure позволяет создавать неограниченное количество контейнеров, поэтому у меня будет контейнер для каждого клиента. Клиент будет вызывать мой веб-сервис, который затем сгенерирует подпись, уникальную для клиента. Таким образом, любые ключи шифрования, имена контейнеров и т. Д. Могут быть защищены на моем сервере, а не на клиентской системе. – BrianB

ответ

6

Подписи общего доступа могут быть ограничены конкретным контейнером или конкретным блобом. Затем они могут указать, какие разрешения они дают (читать, писать, списковать blobs), и они могут указать, как долго они действительны.

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

Похоже, вы хотите разрешить всем своим клиентам написать blobs, но не прочитать их? Если это так, SAS, который задает только разрешения на запись, должен делать трюк.

Но я предполагаю, что вы также хотите ограничить использование (или счетчик) индивидуальными клиентами? Если это так, вам, вероятно, понадобится что-то активное на сервере (веб-служба?), Которое разрешает каждое использование и генерирует конкретный SAS с ограниченным сроком действия, чтобы разрешить эту операцию. Затем вы можете отслеживать и оплачивать счета за каждое использование.

+0

Мне нужно также разрешить чтение, для функции восстановления, которую я еще не реализовал. Я думаю, что я буду использовать веб-службу для генерации SAS в любое время, когда клиенту необходимо выполнить операцию в облаке. – BrianB

+0

Наверное, тупой вопрос, но когда подпись построена, он учитывает URL-адрес blob? Так что SAS, созданный на блобе, хорош только для этого блоба? Если бы у меня был список URL-адресов blob-ов в этом контейнере, я не смог бы вырезать маркер SAS из одного блоба в конце и получить доступ к другим? – nmit026

 Смежные вопросы

  • Нет связанных вопросов^_^