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.

deletedDB

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.

RBAC

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.

VMContribRole

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.

CustomRBACRole

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.

ResourceLocks

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

Author: Thomas Janetscheck

Architect for Microsoft Cloud and Messaging Solutions, community leader, Azure and PowerShell enthusiast working for Data One GmbH

1 thought on “How to protect Azure resources from accidental deletion”

Leave a Reply

Please log in using one of these methods to post your comment:

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