locked
Use single data storage for several roles RRS feed

  • General discussion

  • I need to use a single storage across several instances.

    One work role will write files to drive, several web roles will read data from drive (only authorized access should be provided).

    Is it possible to do with Azure Drive?

    If not - please,  advise other way.

    Thanks in advance.

    Friday, August 10, 2012 10:49 AM

All replies

  • Hi Jack,

    You should definetly consider Windows Azure Blob Storage service instead.

    Hope this helps!


    Cheers, Carlos Sardo

    Saturday, August 11, 2012 8:03 PM
  • Hi Carlos, thanks for reply.

    Blob storage is public resource. I must provide access to files only for users, who completed authenticate on my site.

    Monday, August 13, 2012 9:44 AM
  • Hi Carlos, thanks for reply.

    Blob storage is public resource. I must provide access to files only for users, who completed authenticate on my site.

    Hi Jack,

    There is also support for private containers for consumers and numerous security features, in Windows Azure Storage. I suggest you also read this forum thread about Using SQL Azure BLOB for secure document storage.

    Jeff Irwin (MSFT), has a nice post/reply about this:

    ...We have a number of security features that are worth mentioning here.  First, if you're just getting familiar with Windows Azure Storage, and Blob Storage specifically, I invite you to take a look at this page: http://www.windowsazure.com/en-us/develop/net/how-to-guides/blob-storage/.  It's a getting started page for blob storage that will explain briefly how it all works.

    Regarding security, here are the highlights:

    1) Shared Key Authentication: each storage account has 2 "keys".  Either key gives the user owner-level access in the storage account, and without these keys, no access is allowed (see below for exceptions).  The keys are authenticated on each request, and you have two of them to make rotating them periodically possible without needing to incur downtime.

    2) Publically readable blobs: you can choose to make a blob container "public", which will allow unauthenticated users read access to the blobs in that container.  It doesn't sound like you'd be interested in this, so you would simply make sure that your containers are marked "private" (this is the default).

    3) HTTPS access: of course, we support accessing storage via HTTPS if you need security during transport.

    4) Shared Access Signatures: If you need to provide limited access to users, you will not want to give them one of your storage keys.  For example, you want a user to be able to write a single blob, but no other blob.  For this, we have Shared Access Signatures, which are URL based permissions that the key owner can distribute to other users.  These permissions can be time-limited (e.g., 30 minutes), and access limited (e.g., write only).  For more information, see this blog post: http://blogs.msdn.com/b/windowsazurestorage/archive/2012/06/12/introducing-table-sas-shared-access-signature-queue-sas-and-update-to-blob-sas.aspx

    5) Encyrption at rest: this is a feature request we've heard, but at this time it's not supported.  Data on our servers is stored as you send it.  Customers who need the data to be encrypted at rest can encrypt it themselves prior to uploading it to us, and then decrypt it when they access it.

    6) ACS integration: A slight correction to Arwind's post: ACS (Access Control Service) is not currently integrated with Blob Storage.

    Let us know if you have any other questions about security or would like more detail on any of the above.

    Thanks!


    -Jeff

    Hope this Helps!


    Best Regards,
    Carlos Sardo

    Monday, August 13, 2012 10:04 AM
  • Thanks, Carlos, for the quote!

    Jack - yes, Blob storage supports exactly the kind of scenario you're talking about (restricting access to either account owner or authenticated users).  Let me know if you have follow-up questions on this!

    Thanks!


    -Jeff

    Friday, August 17, 2012 5:17 PM