DevSecOps · February 24, 2024 0

Secure Defaults with AZURE Policies

In simple terms with Azure policy, you can audit, deny, and modify if any resource is misconfigured. It's very helpful for creating secure defaults in Azure Cloud.

why would you create secure defaults?
For example, if someone from your organization is creating a blob storage, he may allow anonymous access. If you find a storage account public during the scan, then you might consider your data is already breached.
Also let's say you fixed certain cloud misconfigurations, after a month again these misconfigurations pop up & You will end up in non-compliance.

Basic of Azure Policy -

  • In policy definition, you can specify a conditional match based on the available resource API value and set actions according to the conditions. A set or group of policies can be combined into an initiative, which makes it easier to manage and enforce broader governance objectives. Applying policies through initiatives provides a more comprehensive approach to governance.
  • There are 2 types of policy. Built-in and custom.
If you think you can generate these policies from GPTs, your policies might not work. Mostly for SQL servers, I have seen GPTs are giving wrong API parameters. Don't worry in this blog we will discuss how to create custom policies efficiently.
 
First, create a resource and check the JSON view from the far right tab. Below is an example of the storage account.
We want to deny any storage account if allowBlobPublicAccess is true.
create the policy and apply - deny-storage
In action-
Also for a few resources API version might be different or updated, you can select a specific API and check specific values. Note the sub-objects of APIs also.
 
{
"value": "[requestContext().apiVersion]",
"less": "2019-04-01"
},
{
"field": "Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
"exists": "true"
 
Modify or deployifnotexist - Now instead of denying, we will modify the resource value to a secure configuration so that the resource will be deployed automatically without any blocker. I like the "Deny" effect because you can set custom messages like "security team- Denied public access, Contact-secops" as shown in the above screenshot.
Note that you need to attach a role in order to modify resources. Don't worry even if you don't define "roleDefinitionIds" in policy, it is dynamically added after attaching the role selector from the UI.
 
EXCEPTIONS
But Let's say now some resources need to be exposed to the public internet or TLS 1 is needed for backward compatibility as a business requirement. Two ways you can do that by using inbuilt Azure exception functionality or via a tag.
However, I did not like the Azure exemptions because you can only set 10 exceptions and many exception resource selectors have a very broad scope. Let's create an exemption with a tag "sorry:shaktiman" tag. Now if the DevOps/SRE team is blocked, I can attach a tag and monitor the resources with that tag.
 
But still, those who have exemption permission will create exemptions. Let's apply a quick trick to prevent this by creating a policy to deny policy exemptions.
Please share other ideas, and feedback in comments/DM.
 
 
Spread the love