Governance suggested policies
Last updated
Last updated
Here is a list of suggested policies you can apply in your environment in order to help in your governance approach.
Allowed virtual machine size SKUs: This policy enables you to specify a set of virtual machine size SKUs that your organization can deploy.
Allowed locations: This policy enables you to restrict the locations your organization can specify when deploying resources. Use to enforce your geo-compliance requirements. Excludes resource groups, Microsoft.AzureActiveDirectory/b2cDirectories, and resources that use the 'global' region.
Allowed locations for resource groups: This policy enables you to restrict the locations your organization can create resource groups in. Use to enforce your geo-compliance requirements.
Allowed resource types: This policy enables you to specify the resource types that your organization can deploy. Only resource types that support 'tags' and 'location' will be affected by this policy. To restrict all resources please duplicate this policy and change the 'mode' to 'All'.
Audit resource location matches resource group location: Audit that the resource location matches its resource group location
Audit usage of custom RBAC rules: Audit built-in roles such as 'Owner, Contributor, Reader' instead of custom RBAC roles, which are error-prone. Using custom roles is treated as an exception and requires a rigorous review and threat modeling
Custom subscription owner roles should not exist: This policy ensures that no custom subscription owner roles exist.
Not allowed resource types: Restrict which resource types can be deployed in your environment. Limiting resource types can reduce the complexity and attack surface of your environment while also helping to manage costs. Compliance results are only shown for non-compliant resources.
Please note that if you decide to enable the Azure Security Center built-in initiatives, be on the lookout for overlapping conflicts. See here the Azure Policy built-in definitions for Azure Security Center
A maximum of 3 owners should be designated for your subscription: It is recommended to designate up to 3 subscription owners in order to reduce the potential for breach by a compromised owner.
MFA should be enabled on accounts with owner permissions on your subscription: Multi-Factor Authentication (MFA) should be enabled for all subscription accounts with owner permissions to prevent a breach of accounts or resources.
Subscriptions should have a contact email address for security issues: To ensure the relevant people in your organization are notified when there is a potential security breach in one of your subscriptions, set a security contact to receive email notifications from the Security Center.
There should be more than one owner assigned to your subscription: It is recommended to designate more than one subscription owner in order to have administrator access redundancy.
Require a tag on resource groups: Enforce the existence of a tag on resource groups.
Inherit a tag from the resource group if missing: Adds the specified tag with its value from the parent resource group when any resource missing this tag is created or updated. Existing resources can be remediated by triggering a remediation task. If the tag exists with a different value it will not be changed.