Did you know that when you delete an Azure Resource Group, it deletes all the resources in that group?
You have built a Resource Group in Azure that contains your infrastructure resources including:
- Virtual Network
- 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?
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
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?
Hidden away in the Azure documentation, are PowerShell commands for locking Resources to prevent accidental deletion.
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?
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.
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.
Consultant: Cloud + Collaboration