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 suggest solutions. Feel free to jump in the discussion in the comments section!
The past blog entries are:
In my last post, I discussed about the variety of security models in the Azure platform, i.e. the different ways to authenticate or to get access to a resource. This time, I would like to discuss the granularity of access.
In any system, once you are authenticated, you are authorized to some access / actions. Access comes in different flavours: read/write, create/delete, etc. .
A recurring theme in authorization schemes is the concept of a hierarchy of rights in order to get around the complexity related to fine granularity of access. For example, in both Windows File System & SharePoint, each file can be denied to a group or specific users but typically access is managed at a higher level, e.g. folders, library, site, site collection, etc. .
If we now look at different Azure services, we’ll find the same the same diversity we found in security models.
SQL Azure has the same authorization scheme than SQL Server, i.e. Database, Schemas, objects (e.g. tables, views). Service Bus has three possible actions, manage, read & write and those can be hierarchically given to an entire namespace or some sub domain. Active Directory has two permissions for the Graph API, read & read-write applied to the entire directory.
Now the weakness I’ve experimented is the lack of granularity in some services, mainly Azure Storage & Active Directory.
Active Directory Graph API grants read or read-write access to the entire directory. I cannot give to an application the ability to manage only some groups: it’s a master switch, once I gave the access, it’s total.
In the case of Azure Storage, there is two types of access: via SAS or via access keys. With the access key, you’re the king of the entire storage account: you can create / delete containers and read-write wherever you want. The SAS comes in two flavours. Ad hoc ones have quite granular access: they can be given to a file with read or read-write access or on a container with read, read-write, or list (to obtain the list of files). SAS policies on the other hand are good for an entire container so once you give one to a system, it can do whatever you authorized it to do (e.g. write) to the entire container. So ad-hoc SAS sounds good, don’t they? Except they are short lived and must be created… using the access keys!
The main problem with not having fine grain enough access controls is that you end up giving more access that you want to. I give you access to write in this entire blob container but please write only in this sub folder. If files start to disappear, you’ll be on the list of suspects though.
There is an overarching principle in Information Technology, Principle of least privilege, give access to an agent ONLY what they need to do their business. In order to do that, you need the underlying platform to support that.
Microsoft Pattern & Practices has a corresponding pattern, the valet key pattern. This is a quite specialized view on the principle of least privilege, limited to SAS. The problem with SAS, as I mentioned in previous articles, is that it multiplies the number of secrets you need to keep as a system. If, as a system, I access 10 resources, I need to keep 10 SAS, i.e. 10 secrets since if I divulge a SAS to a third party, said third party now has access it shouldn’t have. An authentication / authorization mechanism minimizes the number of secrets to one: the secret you need to authenticate.
So… how can we improve?
Well, the conceptual solution is quite easy:
- Make sure to have the most granular access scheme possible
- Use other mechanisms, e.g. hierarchy, to ensure the granularity doesn’t make the access unmanageable
This is quite coupled with the previous article about unifying the security models: you need to authenticate a user / agent in order to grant them access. But even with SAS you could go more granular than is currently the case.