Primary key and Security of Azure Tables

Question

I am concerned that my azure tables will be compromised if the primary key ever become compromised. This question pretains more to procedures rather than a specific technical question.  This question was prompted by a quick way to access the azure tables such as: https://www.myazurestorage.com/. 

I am developing a Silverlight application which uses Azure tables for storage. As part of my application I place the primary key in the ServiceConfiguration.csfg file. This allows my application to access the Azure tables. In the future I can see contracting out some of the design/programming work. In order for a contractor to complete his work I will need to supply the primary key to the contractor. With the primary key the contractor will have full access to all of my Azure tables. 

My concern is that the contractor could either accidently or malliciously expose the primary key to an outside party. Even if I quickly become aware that the primary key has been compromised and renew the primary key id number, the damage will already have been done. With the primary key anyone can easily use a program such as https://www.myazurestorage.com/ to access all of my tables.  

I am wondering how other people are protecting themselves against the above scenario? I was thinking of having a second Azure project which mirrors the production site. Then outside parties can have the primary key to the mirror site which does not contain any sensitive information.

At this time I do not want to use Azure SQL tables which can limit access according to IP address. However I do not know how to limit access to certain Azure tables if I have to give the primary key to outside developers in order for them to complete work. As an example I might want to limit access to tables with sensitive user information but allow contractors access to other more generic tables. 

Thanks,

Dave

Answer 1

First, you get two keys as your secret key and you can choose the one you want to give to 3rd parties, which you'd always refresh each time it goes into new hands. When you contract people to do stuff for you, just follow the same pattern you'd follow for on-premise system: either give your contractors access to one environment and not the other ... or bind your contractors to non-disclosure agreements. 

Azure does not introduce any additional issue in this regard.

---

Pita.O:
http://www.arizentax.com/
http://www.cgi.com

Answer 2

I am wondering how other people are protecting themselves against the above scenario? I was thinking of having a second Azure project which mirrors the production site. Then outside parties can have the primary key to the mirror site which does not contain any sensitive information.

If I were in this situation, I wouldn't give the key out at all and would have contractors use their local dev stores.  Or, I'd give them access to a storage account used just for development, not the live hosted service.  That way you don't incur the hourly cost of running a second hosted service, which adds up over a month.

Another recent post mentions an account type called Service Administrator, but I haven't found any documentation on this.  Perhaps this will be a solution though.

Answer 3

First, you get two keys as your secret key and you can choose the one you want to give to 3rd parties, which you'd always refresh each time it goes into new hands.

Aren't both keys functionally equivalent?  That is to say, couldn't a renegade developer delete all data using either one of the keys?  If so, I'm missing how this strategy would help.

Answer 4

I think your idea of using the local development environment is a good one. I had not thought of that. This way the keys will always be in my possession and I do not have to be concerned with regenerating them. For now this solution should be sufficient for my needs. 

I am wondering if it will be possible to link access to certain tables to a particular key. The primary key can access all tables while the secondary keys can be configured to access only certain tables.  If Azure had this capability then it would be possible to have outside developers access some test tables which still protecting our sensitive data. 

Thanks, 

Dave