How to protect Azure resources from accidental deletion

Accidental deletion of Azure RM resources might be one of the biggest issues you might face in your career as Azure administrator. With that blog post I want to explain how to avoid losing your Azure resources after running a “Whipe All” PowerShell script against your productive cloud environment.

There are several possibilities you have to make your environment more secure and reliable. Below I have listed the six most important capabilities in my opinion:

1. Common sense
2. Azure Backup
3. Azure “recycle bin”
4. RBAC
5. Azure Resource Locks
6. Azure Resource Manager Policies

Common sense

Common sense is a basic prerequisite for being allowed to administer productive infrastructure resources! At least it should be. With common sense the probability of having a “Nuke All” script run against a productive environment can be minimized.

Azure Backup

In a productive on-premise infrastructure you most likely use any kind of backup solution to have your servers and data backed-up to tape or disk or both, don’t you? Just in case you accidentally delete one of your most important Azure VMs you should have a respective backup in place, too. So create a Recovery Services Vault in Azure Primary Portal (ARM), define a backup policy and apply it to your VMs and go for it knowing that your VMs are protected.

Azure “recycle bin”

For some kind of Azure resources such as Azure SQL Databases there is a native option for item restore.

Role-based Access Control

RBAC is a concept most of you might know from products such as Microsoft Exchange Server and which is used for fine-grained permission management. There are predefined roles such as owner, contributor or reader with a predefined permission set on Azure resources.

In addition to it you can define own roles with own permissions using PowerShell. With the command

(Get-AzureRmRoleDefinition -Name 'Virtual Machine Contributor').Actions

you get a list of all permissions the RBAC role “Virtual Machine Contributor” owns.

You can define a new RBAC role named “Virtual Machine Operator” using the following commands:

$role = Get-AzureRmRoleDefinition "Virtual Machine Contributor"
$role.Id = $null
$role.Name = 'Virtual Machine Operator'
$role.Actions.Clear()
$role.Actions.Add("Microsoft.Compute/*/read")
$role.Actions.Add("Microsoft.Compute/virtualMachines/start/Action")
$role.Actions.Add("Microsoft.Compute/virtualMachines/restart/Action")
$role.Actions.Add("Microsoft.Compute/virtualMachines/powerOff/Action")
$role.Actions.Add("Microsoft.ClassicCompute/*/read")
$role.Actions.Add("Microsoft.ClassicCompute/virtualMachines/stop/Action")
$role.Actions.Add("Microsoft.ClassicCompute/virtualMachines/shutdown/Action")
$role.Actions.Add("Microsoft.ClassicCompute/virtualMachines/start/Action")
$role.Actions.Add("Microsoft.ClassicCompute/virtualMachines/restart/Action")
$role.Actions.Add("Microsoft.ClassicCompute/virtualMachines/downloadRemoteDesktopConnectionFile/Action")
$role.AssignableScopes.Clear()
$role.AssignableScopes.Add("/subscriptions/[Subscription-ID]")
New-AzureRmRoleDefinition -Role $role

The new role can now be assigned via PowerShell or Azure Primary Portal.

Azure Resource Locks

Azure Resource Locks are used to prevent resources from being altered or deleted by privileged users. You can define Read-only or Delete locks on resource, resource group or subscription level. Locks that are defined on resource group level are valid for all resources within the respective resource group, locks on subscription level for any resource within the subscription.

Azure Resource Manager Policies

Azure Resource Manager Policies are used for fine-grained permission management focussed on resources, not users (unlike RBAC). Policies are defined in JSON syntax and can be assigned via PowerShell or REST API.

With PowerShell you have two possibilities of passing the JSON content to your script: as file or plain text within the PowerShell script:

Plain text:

$policy = New-AzureRmPolicyDefinition -Name regionPolicyDefinition -Description "Policy to allow resource creation only in certain regions" -Policy '{
"if" : {
"not" : {
"field" : "Location",
"in" : ["northeurope" , "westeurope"]
}
},
"then" : {
"effect" : "deny";
}
}'

JSON file:

$policy = New-AzureRmPolicyDefinition -Name regionPolicyDefinition -Description "Policy to allow resource creation only in y in certain regions"-Policy <path-to-policy-json-on-disk>

You can assign the policy you’ve just created to an Azure Resource Group with the command

New-AzureRmPolicyAssignment -Name regionPolicyAssignment -PolicyDefinition $policy -Scope /subscriptions/<SubscriptionID>/resourceGroups/<resourceGroupName>

I hope I could clarify the most important capabilities that make an Azure infrastructure most reliable and secure. And keep in mind that common sense might prevent you from doing things that result in an outage of your most critical business infrastructures.

Thanks for reading and kind regards,
Tom