How to improve Azure: Security Models

In this blog series I explore some of the shortcomings of the Microsoft Azure platform (as of this date, April 2014) and discuss ways it could be improved. This isn’t a rant against the platform: I’ve been using and promoting the platform for more than four (4) years now and I’m very passionate about it. Here I am pointing at problems and suggesting solutions. Feel free to jump in the discussion in the comments section!

The past blog entries are:

 

What is the security model of Microsoft Azure?

This question is at the heart of the weakness I would like to discuss in this article:  there are no unique security model in Azure.  There are a plethora of models, depending on which Services you are consuming.  Let’s look at some examples:

Those are just a few and they are the access to the service itself.  When you want to manage those services (e.g. creating an SQL Azure Database), you may have a different security model.

If you use Microsoft Azure lightly, i.e. one or two services, it might not appear as a problem.  Once you start using Azure a bit more as a development platform, then this lack of uniformity will hit you:

  1. You have a lot of protocols to understand and implement.
  2. You need to work around different limitations, e.g. I can be very granular on access on the Service Bus but with SAS Policies in Azure Storage, the SAS is good for an entire container.
  3. You have a lot of secrets to store, since many Services do not share secrets (see my blob on secrets for more details).
  4. You have a lot of credentials to manage, e.g. you need to implement retention policies and renew different secrets in different services which all have different management interfaces.  This increases the chances of error or more typically, of not automating such policies.

 

How could we fix that?

 

I would propose a dual security model for each Service.

The primary Security Model would be Claims based and not even limited to Microsoft Azure Active Directory but open to any Identity provider.  For ease of use, your Azure Subscription could be configured with a set of trusted Identity Provider (i.e. URI & signing keys, token type).  When you want to configure an access you could then have a standard dialog where you pick the Identity Provider and compose a Claims rule (e.g. I want the claim type & claim value or those types & value, or either this combination or that one, etc. .).

This would enable your solution to have Service Identities managed wherever you want (although Azure Active Directory would be easier since it is part of the platform) and the same Identity could be used to access SQL Azure, Service Bus, Media Services, etc.  .  Quite a bit like we do on-premise with Service Accounts.

The access token provided by the Identity provider would need to be passed in the Authorization cookie at each HTTP Request or differently for different protocol (e.g. TCP TDS for SQL, proprietary TCP for Service Bus, etc.).

image

The secondary Security Model could be unique to each Service but would typically address the shortcomings of the primary one.  The primary model I define here requires access to an Identity Provider (this one must be up), configuration of an account in that Provider, etc.  .  A simpler Security Model, e.g. SAS, would be quite good for faster ramp-up with a Service (although it has the weakness of multiplying the number of secrets).

 

With this Primary / Secondary Security Model we would have a robust security model (Primary) and one for quicker use (Secondary).  When using the primary security model, it is quite possible to have only one secret to store for an application:  the user name & password of the Service Identity associated with the application.  This would allow for central management of the secret and much less complex logic to store and use the secrets.

 

Hope this was useful!


Leave a comment