Azure Resource Groups -Preventing Accidental Deletion with Resource Locks

Question

Did you know that when you delete an Azure Resource Group, it deletes all the resources in that group?

Scenario

You have built a Resource Group in Azure that contains your infrastructure resources including:

  • Virtual Network
  • Subnets
  • Network Security Groups (NSG)
  • Storage account to hold diagnostic logging for the NSGs

The subnets may host your IaaS Virtual Machines, maybe define your DMZ and your reverse proxy. So questions around risk need to be asked including:

  • How easy is it to delete a Resource Group?
  • Who can delete a Resource Group?
  • What can be done to protect a Resource Group?

How easy is it to delete a Resource Group?

Very.

Through the Portal:

  • Select Resource Groups
  • Click on the Resource Group to delete
  • Click Delete
  • Type in the name of the Resource Group. If it matches the name, the delete button activates
  • Click Delete

Using PowerShell:

Remove-AzureRMResourceGroup - Name <Name> -Force

Who can delete a Resource Group?

Owners and Contributors.

This probably describes the level of access granted to most admin staff (Similar to how everyone seems to be a Domain Admin in Active Directory!)

What can be done to protect a Resource Group?

Resource Locks!

Hidden away in the Azure documentation, are PowerShell commands for locking Resources to prevent accidental deletion.

https://azure.microsoft.com/en-us/documentation/articles/resource-group-lock-resources/

A Resource Lock can be applied to a Resource Group – All resources in that group inherit the lock. It is similar to using the Do Not Delete flag on an OU in Active Directory.

To lock a Resource Group run:

New-AzureRMResourceLock - LockName <Name> -LockLevel CanNotDelete -ResourceGroupName <Resource Group Name>

Principle of Least Privilege (PoLP)

Assign all staff the privilege that they require to do their job. No more.

The entire IT department do not need full unfettered access to Azure. Look in depth at the features of Role Based Access Control within the Azure documentation.

Map out who needs access to which resources. For instance, does a server administrator really require access to change your Virtual Network? Do they need to be able to create Subnets?

Change Control

Ensuring that changes to the environment only occur by agreement, and within a fixed time frame can go a long way to prevent disasters.

Some organizations go so far as to only allow the administrator access to a high level of privilege during a change window. After the change window, the extended permissions are revoked.

End Note

Planning is the key to preventing mishap (or malicious damage) to your Azure environment. It is worth taking the time to work out who will use Azure, what privileges they require to perform their roles, and when and how these extended privileges are to be granted.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s