Azure Arc is Microsoft’s solution to allow customers to manage on-premises resources (servers and the likes) using Azure Resource Manager, i.e. the Azure Portal, CLI and the Azure PowerShell module. It basically enables on-premise server management in a way that it feels like you’re administrating an Azure Virtual Machine instead of an on-premises server. Note that Azure Arc supports Windows and Linux, but this blog series will only cover aspects of Windows machines.

This post is part of a blog series covering the security implications of an Azure Arc deployment. The first part is a technical deep-dive into the possibilities of an attacker who gained access to the machine itself, and which implications that has for the Cloud environment. The second part of the series deals with technical aspects of what permissions an attacker would require to move laterally the on-premises Azure Arc machine and what traces such actions would leave. This third post sums up all the uncovered aspects and gives general, non-technical advice on how to integrate Azure Arc in existing security concepts and what to be careful about.

Is Azure Arc Secure?

That’s one of these questions that require the typical consultant answer “It depends”. However, if I have to answer it, I feel like in most cases and with most security concepts I’ve seen, Azure Arc would actually degrade the security posture of a company. There are, of course, exceptions to this. For example, I’ve seen Azure Arc being used to manage a couple of Hybrid Workers in an Azure Automation environment that was isolated in a subscription for specifically and only that use case, and I couldn’t find any major security issues there.

The first thing “it depends” on is your security concept: is it centered on cloud or on-premises? Almost all hybrid environments that I’ve seen are on-premises centered, as that has been there first. With a lot of generalization (as it is seldomly that easy), this means that for those environments it’s less of a problem if their Cloud environment is compromised than if their on-premises environment is. And in this situation I see Azure Arc as a risk, due to the new attack vector it introduces leading from Cloud to on-premises.

At this point we have reached the root of this discussion: Azure Arc introduces two new attack vectors to the environment: the attack vector of escalation from Cloud to on-premises, and the attack vector from on-premises to Cloud. It all depends on how well you handle those attack vectors. These two vectors have been covered in the two previous blog posts of this series, but I will sum it up in the following.

Attack Vector 1: Cloud to On-Premises

From the point of view of the Cloud, Azure Arc doesn’t introduce a big security issue. It is only endangered if you give its managed identity too many or too high permissions. Or if you use Cloud credentials on the machine improperly. However, those issues are not limited to Azure Arc machines and are more of a general security problem that every Azure Cloud has to deal with. In the case of no permissions assigned to the Azure Arc machine’s managed identity, and no Cloud credentials used on the machine, there would be no way to escalate any further.

Attack Vector 2: On-Premises To Cloud

The second attack vector is tougher: altogether 15 Azure Cloud built-in roles are able to execute code on Azure Arc machines with administrative privileges, including roles you wouldn’t normally link to Azure Arc, such as “Log Analytics Contributor” or “Azure Extension for SQL Server Deployment”. If you are, like me, still thinking in Microsoft’s legacy administrative tier model, this means that all those 15 roles need to be limited to only users and accounts that are in the same tier as the Azure Arc machine. In a complex Azure environment, this is practically almost impossible. Consequently, the complexity needs to be reduced: if you put Azure Arc machines into a subscription that is solely intended for a single use case, and doesn’t host any further Azure resources, you should be able to avoid the issue of having other IT personnel or service accounts with the “Log Analytics Contributor” role roaming around.

But don’t stop there: create a management group just to bundle permissions for Azure Arc machines. Many permissions are usually granted on management group level to “the Cloud team” that would then inherently have access to your Azure Arc resources, and thus to the corresponding on-premises systems – which usually violates the Principle of Least Privilege. If you create a management group solely for Azure Arc subscriptions, you can avoid that.

Summary

Securing your Azure Arc machines will be tough in most cases. Deploying it will increase the risk of attackers in the Cloud gaining access to your on-premises environment significantly.

So when you deploy Azure Arc, always consider the Clean Source Principle and the resulting attack paths (think BloodHound or AzureHound). So far your Cloud environment will only have been used for Cloud management, but if you integrate Azure Arc, this will have to change. You should reflect that in reducing the Azure Cloud (not Entra ID) team’s permissions to only pure Cloud resources, and integrate people responsible for managing the Azure Arc machines into your Cloud security concepts.

Alternatively, your Cloud team could be made responsible for managing these machines, however, this will have to be reflected in your on-premises security concept, and they will have to get trained in all the security aspects of on-premises / Windows Server Active Directory – which is why I would not recommend that in most cases.