8.3 Ensure that Resource Locks are set for mission critical Azure resources

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

Resource Manager Locks provide a way for administrators to lock down Azure resources to prevent deletion of, or modifications to, a resource. These locks sit outside of the Role Based Access Controls (RBAC) hierarchy and, when applied, will place restrictions on the resource for all users. These locks are very useful when there is an important resource in a subscription that users should not be able to delete or change. Locks can help prevent accidental and malicious changes or deletion.

Rationale:

As an administrator, it may be necessary to lock a subscription, resource group, or resource to prevent other users in the organization from accidentally deleting or modifying critical resources. The lock level can be set to to CanNotDelete or ReadOnly to achieve this purpose.

CanNotDelete means authorized users can still read and modify a resource, but they can't delete the resource.

ReadOnly means authorized users can read a resource, but they can't delete or update the resource. Applying this lock is similar to restricting all authorized users to the permissions granted by the Reader role.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.

Solution

From Azure Console

Navigate to the specific Azure Resource or Resource Group

For each of the mission critical resource, click on Locks

Click Add

Give the lock a name and a description, then select the type, CanNotDelete or ReadOnly as appropriate

Using Azure Command Line Interface 2.0
To lock a resource, provide the name of the resource, its resource type, and its resource group name.

az lock create --name <LockName> --lock-type <CanNotDelete/Read-only> --resource-group <resourceGroupName> --resource-name <resourceName> --resource-type <resourceType>

Default Value:

By default, no locks are set.

See Also

https://workbench.cisecurity.org/files/3459