Using SQL Azure BLOB for secure document storage?

Question

Hey All,

Can sql azure blob storage be used to secure corporate documents? We're considering moving our document storage into the cloud so our multiple offices can share documents easier. Our solution needs to take into consideration certain documents have SSN #'s, addresses, etc. that of course needs the highest security. Only authenticated users should be able to download the documents. I have to make sure the documents are not accessible at all unless first authenticated.

I am unfamiliar with BLOB storage in general, but in reading up on cloud storage sounds like a good solution if it can be completely secure. We plan on using Silverlight 5 for the interface.

Thanks for any help you can provide!

Answer 1

Hi,

I think so, Azure Blob Storage support private container for consumers, other users can not access the documents if they haven't credential, here is a article introduce Blob Container permission:

http://msdn.microsoft.com/en-us/library/ee741656.aspx

You can also enable ACS for protect blob storage.

Hope this helps.

---

Please mark the replies as answers if they help or unmark if not. If you have any feedback about my replies, please contact [e-mail] Microsoft One Code Framework

Answer 2

Hi - great question!  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

Answer 3

Thanks for the help guys. Jeff I'm going to address your post here:

I actually had found the How To Guide on BLOB storage, the one you linked, and found it really helpful. I believe what we need/will use is a combination of HTTPS, Shared Access Signatures and our own encryption for files at rest. Based on the BLOB How To guide here's how we would like the system to work:

• We'd like a Company Account that is the main BLOB account
• Each employee in the company will have an 'Account' (or container, please see questions below related to this)
• Each Account will have multiple containers, ie 'HR', 'Meetings', 'Misc'
• Each container can contain any number of files

Here's how the account access should work:

• Each employee can only access their own account/blob files
• Department heads can access each employee in their department, but not employee's outside their department
• So basically each account can be accessed by 2 people: the employee who's account it is and the department head

Here's my questions:

1. Does this seem like a scenario that Azure BLOB storage can handle?
2. The first graphic on the How To page shows an Account 'Sally', multiple containers and blobs within the containers. My confusion is do we want multiple accounts (1 for each employee), ie a 'Sally' account, a 'John' account, etc? Or do we want 1 account, 'Company Account', and each employee would have a container, ie. 'Sally container', 'John container', etc?
3. HTTPS. Is that something that comes with azure blob storage (as in a checkbox to enable ssl) or do we purchase an SSL cert for the blob domain?

Here's how the  scenarios look and we are not sure which one is possible or best practice:

• Company Account->Employee Containers (Sally, John, Sue)->all blobs for that employee in here
• Company Account?->Employee Account->Containers (HR, Meetings, Misc)->blobs

Our preference would be having the ability to have multiple containers for each employee to have some grouping of blob files, but we really need to understand if that means each employee has an 'Account'.

Hopefully I've made it clear what we are trying to achieve. If I need to clarify please let me know and thank you for your help! I really appreciate it!

Answer 4

Hi,

My opinion is use ACS to do some authentication, not make ACS works with Blob Storage directly, for example, you can create rules that include username in ACS Claim, the relying-party application can get the user info from the Claim, then the application will access authority table (Stored in SQL Azure, table storage, etc) to check the current user's permission. You can only list the available blob containers to users or reject  exceeds authority requests. (You can create a custom HttpModule for authorization)

Hope this helps.

---

Please mark the replies as answers if they help or unmark if not. If you have any feedback about my replies, please contact [e-mail] Microsoft One Code Framework

Answer 5

Hi Arwind,

Thanks for the suggestion. I'm now looking into ACS and seeing how that works.

Answer 6

Hi - let me try to answer your questions here, though a little out of order.

1) Yes, absolutely, blob storage can handle this, in a couple different ways.

3) HTTPS: this is included automatically as part of your account.  You access your account at .blob.core.windows.net">https://<accountname>.blob.core.windows.net.  If you use table storage, you just use "table.core.windows.net" instead of "blob.core.windows.net".  Same for queue storage (queue.core.windows.net).  No configuration is necessary to use https!

2) Ok, here's where it gets more interesting.  First: don't create a storage account for each of your employees.  A storage account is built to scale massively, so there's no reason to break it down into one storage account per employee.  For grouping, let me suggest you do something like this:

 - Highest level: account.  You have one of these.
 - Second level: containers.  You have one of these for every employee.  Sally has one, John has one, Sue has one, etc)
 - Third level: blob directory.  This is a virtual construct in blob storage, contained within a container - think of it as sub-folders.  It supports listing, just like a container.  You would use this to group within an employee's account, so you might have one for HR, one for Meetings, one for Misc, etc.
 - Fourth level: blobs.  these are the actual files!

So that settles organization, but the next question is access control.  You have a few options:

1) Web Application Proxy.  As Arwind said, one option is to create a "proxy" web application.  This application will be the way all user data is accessed, and it will be responsible for the following:

• Authenticating the user.  You can use ACS (Windows Azure Identity service) or any other authentication mechanism you'd like.  If you want to (this is common), you can store user information in Azure Table Storage as well, like Arwind suggests.
• Authorizing the user. Similar - once you know who the user is, you'll need to decide what they can access.  Table storage is also a great place for this data.
• Serving the data.  The web application will have to allow the user to download/upload their files.  Because this application will have the Shared Key associated with the account, it can perform actions on all blobs/containers/tables.  The drawback to this approach is that it requires all of the data to go through the application, putting a lot more load on that application, meaning you may have to scale it more.

2) Same as the above, except in this one, the data access is not done through the application.  Instead, the web application distributes Shared Access Signatures after Authentication/Authorization.  For example, if the user wants to download the file, the application would send a Shared Access Signature URL to the user, then the user's client application would issue a download request for that file.  This works really well if you have a rich client application, but can also work if you have a browser-based application, and these requests can be made over https as well.  The big gain here is that the files no longer have to go through your web application - instead, only authentication, authorization, and Signature distribution is the job of the application.  We've just announced Shared Access Signatures for Tables and Queues as well, and there's some good samples for those (and general Shared Access Signatures) here: http://blogs.msdn.com/b/windowsazurestorage/archive/2012/06/12/introducing-table-sas-shared-access-signature-queue-sas-and-update-to-blob-sas.aspx.

Hope that all helps - the organization part is pretty straight forward, and you have multiple options for securing and providing access for the data.  Let me know if you have any clarification questions on this.  Thanks!

---

-Jeff

Answer 7

Hi Jeff,

Thank you for the detailed response!

It's nice to see that the organization is really that simple and having built in https is also great.

Regarding access control, in example 2 you say: "The big gain here is that the files no longer have to go through your web application - instead, only authentication, authorization, and Signature distribution is the job of the application." Can you elaborate on that?

We're building the client application in Silverlight 5 so we will have a rich client, so option 2 for access control should definitely work for us. In my mind the client app will have a 'explorer' like area for the user to browse their files. They select the file, click download (or upload) and probably have it defaulted to a particular area to download. So when you say the files no longer go through the application I'm confused. I think you may be talking about having the browser serve the file? Like in Internet Explorer the "Do you want to save this file?" dialog. Or maybe your referring to the underlying application code accessing the blob directly rather then through a wcf service or web service? Or probably something else (I've been living in windows desktop developement for 12 years and have been only recently getting into the web application world).

If you can clarify the above that would be fantastic. Overall I feel like this is the perfect solution for us and will be a really fun and interesting project to build. It's also going to be a huge step up for our company and I'm excited about implementing it.

Answer 8

Hi!  I'm glad you're so excited to try this out!  Unfortunately, I'm leaving for vacation for a few days.  I'm looping in someone else from the Storage team who will be able to help you with those questions.  Thanks, and good luck!

---

-Jeff

Answer 9

Hey thanks Jeff! I really appreciate your help and for passing this on. Have a great vacation!