Use Azure Policy to help enforce compliance standards for your Azure deployments

Scenario:

You need to allow researchers the flexibility to create storage accounts in Azure but you want to ensure they're using security best practices.  Specifically, you would like to require that secure transfer (HTTPS) be required as they transfer data in & out over the network as well as Server Side Encryption (SSE) be enforced to ensure compliance with encryption at rest requirements.

Components:

Azure Policy is a service in Azure that allows you to create, assign and manage policy definitions against Azure Resource Manager (ARM) resources.  Azure Policy can be used to ensure you stay compliant with your standards and service level agreements.  Policy Definitions can be assigned to subscription level scopes as well as resource group level scopes.  These can be combined together into Policy Initiatives that help meet a compliance standard you would like to enforce.

Solution:

Use built-in and custom Azure Policy definitions to enforce the required practices for any newly created storage accounts in a resource group.

In this scenario, I'm going to create a resource group to ensure that my policy assignments don't have unintended consequences - after all a subscription can be a pretty broad scope and I don't want to impact other admins or resources!  Despite my tendency to be verbose (ask my peers!), I prefer Azure CLI because of its compactness, so that's what I'll use here.

 az group create --name policydemo --location EastUS

We've got a resource group created, now let's validate that we can create a storage account in that resource group without the options that would meet our security requirements (seed the name with some numbers of your own to ensure uniqueness):

 az storage account create --name notcompliant3432 --resource-group policydemo --location EastUS

Not ideal - we've confirmed we can create a storage account without any concern for our institution's best practices.  Let's use Azure Policy to fix that!  We'll move over to the portal and take a look at the available policy definitions to see if any might be useful for our scenario.  Click All services in the upper left corner of the portal and scroll on down to the Monitoring + Management section where you'll find Policy:

You'll land at the overview, which will be pretty empty if this is your first foray into Azure Policy.  I'll leave it to the documentation to expand on the various options and elements available, but let's focus on the task at hand.  Look for the Authoring section and click on Assignments:

Let's assign a policy by clicking Assign Policy on the right side of the Policy blade.  This opens up a new blade where we have to select which policy we'd like to apply.  Click the ellipses next to the policy field to see the options.  Scroll down a bit through the available policies and you'll see a built-in policy which looks like it'll address one of our concerns "Require blob encryption for storage accounts":

Let's select that policy and change the tier to Free since we don't need to enforce against existing resources, just newly created ones.  We are forced to specify a scope and it's important to specify both a subscription and a resource group (though resource group is optional) for this exercise as we're learning and don't want to disrupt other deployments as mentioned earlier:

OK, so that takes care of the encryption at rest requirement, but at the time of this blog post, there isn't a built-in policy available to address the secure transport requirement.  Luckily, an example with deployment template is in the documentation here.  Let's deploy that into our subscription so that it appears as a custom policy in our list.  Now we can assign this "require HTTPS traffic only" for blob storage accounts policy:

Now, we'll set the scope and pricing tier as we did with the first policy.  If everything went as planned, we have a pair of policies assigned and scoped to a resource group within your subscription that requires any new storage account to have both encryption at rest and https traffic only enabled. If not the deployment will fail.  Let's test it!

First, we'll try the Azure CLI command we used prior to assigning the policies - remember to change the storage account name.  Last time it deployed a storage account, this time - Doh!

 az storage account create --name notcompliant3433 --resource-group policydemo --location EastUS

 Resource 'notcompliant3433' was disallowed by policy. Policy identifiers: '[{"policyDefinitionId":"/subscriptions/########-bff6-4b73-98b3-0e064b38ff54/providers/Microsoft.Authorization/policyDefinitions/deacdafe-4560-40a5-8eb7-1fdcadb2601b","policyAssignmentId":"/subscriptions/########-bff6-4b73-98b3-0e064b38ff54/resourceGroups/PolicyDemo/providers/Microsoft.Authorization/policyAssignments/e176a7e03ff44dedb3bb5202"},{"policyDefinitionId":"/providers/Microsoft.Authorization/policyDefinitions/7c5a74bf-ae94-4a74-8fcf-644d1e0e6e6f","policyAssignmentId":"/subscriptions/########-bff6-4b73-98b3-0e064b38ff54/resourceGroups/PolicyDemo/providers/Microsoft.Authorization/policyAssignments/e5fe344d694c4a589a53a40e"}]'.

Excellent!  Even users with fully authorized RBAC roles cannot create non-compliant storage accounts in this resource group.  But what about the folks that do care about security and did read the guidance I sent them?  Let's try again, this time specifying https-only and encryption-services options and see what happens . . .

 az storage account create --name compliant3433 --resource-group policydemo --location EastUS  --https-only true --encryption-services blob

Success!  Now you can go back and check for other interesting policy templates like "Allowed Locations" because a researcher may accidentally deploy a resource in Brazil South region, but that may not meet the research grant's data location requirements.  The documentation does a great job of explaining the differences between RBAC and Azure Policy and offers several examples as well.  My hope is that you'll feel more empowered to allow your customers the flexibility to deploy resources in Azure while maintaining your institution's compliance and governance requirements.