Deploying services in Azure is as simple as going to the marketplace and filling out a form. And boom, a new service or resource is up and running. This is great because it saves time and makes services accessible to us in very little time. However, there is a big downside with this simple approach that lots of companies do not keep in mind – and might hit them hard later.

This is a simple, generic blog post and to demonstrate the problem I will use an Azure storage account. However, this can be adapted to almost all of the existing Azure services.

The Azure storage account

I will use a simple case for this blog post. I created an Azure storage account and gave owner permissions to a specific user. That user can now obviously manage the storage account.

The storage account has multiple blob containers, some of them with a private, others with a public access level.

We will focus on the private container because this obviously means, that not everyone can access this content because it is kind of sensitive. Only authorized users will get to the private content. In the portal I can easily get to that content and the blobs in the containers are listed (there is only one blob in this container). The authentication method shown to access the content is “Access Key”.

Access to the storage account container content is not possible with the “Owner” permissions. But because I am the owner of the storage account, the access keys are accessible. The keys are read automatically in the background and are then used to authorize me for the private container. This is why I can now see the container content.

I now try to change the authentication method to Azure AD which should then use proper Azure AD authentication to authorize me for this content. With that method, the access key would become obsolete.

Obviously this does not work and the content is not listed using this authentication method. The reason is simple: I am the owner of the storage account, so I can manage the resource (=management plane). However, this does not include permissions to get access to the content that lives inside the storage account (=data plane).

This is a common concept that is used in Azure.

To give my user account access to the content, I have to assign another role. For this example I will assign the “Storage Blob Data Owner” role that gives full access to all content of this specific storage account.

It might take a while, but after a minute or two the user can use both authentication methods to get to the storage account content. I can now switch back and forth between the two methods, both work perfectly and the content is accessible with both authentication methods.

The selection of the authentication method is only used in the portal to try to get access to the storage account content. Both methods can be used. It does matter which method is selected, both are always active.

Bye bye employee

Everything works as expected. Now imagine a user leaves your company: What to do now? Easy, we just disable his user account and the user will not be able to login to the Azure portal anymore nor get access to the storage account content. True?

• Once a user left a company he/she doesn’t have network access to on-premises systems anymore because they are sitting behind a firewall. In Azure however, many services will have a public endpoint which means that they can be accessed from the internet using a URL or public IP address. So very often network access to a service is possible even after someone leaves a company.
• The authentication using Azure AD is gone because the user account is disabled. However, the authentication method with the storage account access keys is still active.
• Having network access to the service through the public endpoint (=network access) and having the storage account access keys at hand (=authentication) still allow access to the storage account content, long after someone left the company.

Let’s see if this is true: I installed the Storage Account Explorer from Microsoft on my notebook to try to get access to the storage account content. The tool allows different authentication methods, one of them is “Access Key”. So after connecting to the storage account using the access key, I can easily access everything that lives in there without even having an Azure AD account.

This is a big issue for many companies and adds some additional challenges to the show. And of course this is not only true for storage accounts, but also for many other Azure services. You must know how to handle those services, e.g. in case an employee leaves the company (and also cover other scenarios).

There are countermeasures to address this issue, but you must plan and implement those before you put a service into production. Those could be:

• Understand how a service works and what you need to take care of before you put it into production
• Remove public endpoints of services (if not really needed) to avoid public network access
• Restrict public endpoint access to the service (if possible) using the service firewall
• Rotate shared keys (such as storage account access keys) automatically
• Use Azure policies to audit or enforce service compliance
• etc.

Depending on the service there might be additional authentication methods available, not just the two I mentioned in this post.

Re-cap

As I normally say: Provisioning service in Azure is very simple. But to really master and operate a service in a secure way, it needs more than just going to the marketplace and filling out a form. It needs deep understanding how a service works, how one has to authenticate against it to get access, how it encrypts data etc. And it might need proper processes in place to securely operate, protect and manage it. Don’t put anything into production before you have all of this ready or you might put your environment, your company and yourself at risk. Don’t let the simplicity of Azure fool you.

Cheers,
Marcel