This is a quick introduction and testament to my experience using Azure Policy within the Azure portal.
What problems do Azure Policies solve for our organizations security?
Azure policies allow us to future proof and audit our Azure resources for vulnerable configurations. There are a few parameters/effects that allow us to either “audit”or “deny” configurations we don’t want taking place unknowingly or maliciously. Additionally we can also leave an effect in “disabled” mode.
For instance we can use a “deny” effect with the policy definition called “Storage account public access should be disallowed” and this stops anyone from creating a blob storage account with public access BUT it will not remediate already configured resources, that is another matter.
How/when/where can you apply the policies?
Use Initiatives to group multiple definitions or directly apply a single definition.
Additionally you can apply policies via Defender for Cloud’s “Regulatory Compliance” blade which for the most part are just canned initiatives with various definitions pertaining to a compliance standard ie; SOC2.
My strategy to using the Compliance based standard Initiatives is to deploy those you care about across your subscriptions/Management groups/Tenant since they deploy in an audit mode(Although you should confirm this by checking all the definitions). This will give you an idea about how vulnerable your environment is based on the standard. From this point to deny resources I’ve found the best method is use your own custom initiative via the Azure Policy blade because this will avoid confusing parameters within the standards based initiatives which are set to target on a larger scope. With your custom initiatives you lower the scope to say one test subscription. This will reduce the impact of a policy that could break something unintentionally.
Additionally using your own initiatives can slowly incorporate definitions for controls you’d like to roll out at your convenience and keep things ordered and clutter free.
How can you remediate vulnerable resources?
This is possible with definitions that use that allow for the “DeployifNotExists” effect value. The initiative itself will create a system identity that can be used to apply the changes across resources.
This is just an overview to better understand the options available from a high level perspective. Before deploying any changes as always a test subscription or resource group should be used to verify things will work as expected.
