Author: Almu

by Almu Gómez Sánchez-Paulete

When we talk about cybersecurity, the image of a person with a hood in front of black screens and white lines (or green, which are cooler) comes to mind, and we don’t always take into account that cybersecurity encompasses much more than knowing how to attack a system (Red Team). It is also important to design a secure architecture and know how to apply compliance controls to help carry out a risk plan and manage vulnerabilities in the infrastructure. If you add a cloud architecture, we find ourselves with the exciting world of “Cybersecurity Compliance on Cloud”.

Cybersecurity Compliance reaches from legal controls of confidentiality, integrity and availability of data, as well as the use of tools and application of processes that help in these controls.

In a cloud-based architecture with Microsoft Azure, we have multiple tools that will help us in this process (Azure Role Based Access Control, Azure Group Administration, Azure Blueprints...). In this first article, we will talk about Azure Policies and how they can help us monitor the compliance of our infrastructure.

These tools fall under the control of Azure Governance, which, in general terms, is the way to control how a group of users access certain resources, and for how long.

The first thing is to know what Azure Policies are and how they can help us.

They are a series of rules that will help us maintain consistency in the infrastructure.

What can lead us to make use of them?

  • Regulatory Compliance
  • Controlling cost
  • Maintain security and performance consistency

These rules will allow the following actions to be carried out once they are evaluated:

  • Append
  • Audit
  • AuditIfNotExists
  • Deny
  • DeployIfNotExists
  • Disabled
  • Modify

For example, if we don't want any resources to be deployed in the “Test” resource group without the “test” tag and value, the rule will deny this action on deployment, which is useful in large infrastructures with different teams working on top of each other with one or several subscriptions having to meet a minimum structure for the organization.

This service has no additional cost, and by default, Azure provides a series of already created policies in which you only need to assign them and indicate the action to be taken.

These rules can be grouped into sets called "initiatives", and of which Azure also offers us some by default for checking compliance with certain standards, such as NIST, the CIS Microsoft Azure Benchmark:

Also, you can create your own sets of rules so that with a simple assignment on a subscription, or group of resources, you can control all the rules you require.

But we are going to focus on the possibility of creating custom Azure Policies for our environment, for this, we have to know:

  • What language do you use? JSON
  • What permissions does the user require to manage these policies?

Action Type

Operation

Description

Action

Microsoft.Authorization/policyDefinitions/read

Get information about a policy definition.

Action

Microsoft.Authorization/policyDefinitions/write

Create a custom policy definition.

Action

Microsoft.Authorization/policyDefinitions/delete

Delete a policy definition.

Action

Microsoft.Authorization/policyAssignments/read

Get information about a policy assignment.

Action

Microsoft.Authorization/policyAssignments/write

Create a policy assignment at the specified scope.

Action

Microsoft.Authorization/policyAssignments/delete

Delete a policy assignment at the specified scope.

Action

Microsoft.Authorization/policyExemptions/*

Create and manage policy exemptions.

Action

Microsoft.Authorization/policySetDefinitions/*

Create and manage policy sets.

What parts does a policy in json format consist of? We have two different parts in the code:

  • The declaration of the rules: determines how the policy will behave (effect) once their condition is fulfilled
  • The declaration of the parameters: the definition of the values ​​that the policy must comply with.

With these clear points, let's get down to business!

We are going to create a simple custom policy that forces a label to be set on the resources. To do this, we will write the JSON and then import it with PowerShell to our Azure account, and from the Azure Portal, we will verify that it has been created correctly.

First, we will create two files:

  • parameters.json
  • Rules.json

In the parameters.json file, we will define the default value of the label that we require with this rule; in our case, it will be the value “test”.

{
"tagName": {
"type": "String",
"metadata": {
"displayName": "Mandatory Tag [test]",
"description": "Name of the tag, such as [test]"
},
"defaultValue": "test"
},
"effect": {
"type": "String",
"defaultValue": "Deny",
"allowedValues": [
"Audit",
"Deny",
"Disabled"
],
"metadata": {
"displayName": "Effect",
"description": "The effect determines what happens when the policy rule is evaluated to match"
}
}
}
{
"if": {
"allOf": [
}
"field": "[concat('tags[', parameters('tagName'), ']')]",
"exists": "false"
}
]
},
"then": {
"effect": "[parameters('effect')]"
}
}

Now, we are going to verify that the JSON is correctly structured and that it is correctly imported into our Azure account, for this, we will need:

  • PowerShell 7.0.6 LTS or PowerShell 7.1.3
  • Install the latest version of PowerShell available for your operating system latest version of PowerShell
  • PowerShell script execution policy must be set to remote signed or less restrictive
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Use the Install-Module cmdlet, as it is the preferred installation method for the Az PowerShell module.

Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force

Once we have all these points, we connect to our Azure account.

  1. Connect Azure Account with PowerShell

Connect AzAccount.

  1. Select subscription to work
Get-AzContext
Set-AzContext NAME OF YOUR SUBSCRIPTION
  1. The command to make a new Azure policy definition is:
$definition = New-AzPolicyDefinition -Name "" -DisplayName "" -description "" -Policy '' -Parameter '' -Mode

The mode can be indexed or all; this will determine what types of resources are evaluated by the policy.

all: evaluate resource groups, subscriptions, and all resource types

indexed: only evaluate resource types that support tags and location

I recommend uploading it to a github repository, and from raw mode, indicate the path where each file is located:

$definition = New-AzPolicyDefinition -Name "test" -DisplayName "Test" -description "Test" -Policy 'https://raw.githubusercontent.com/asanchezpaulete/Articles/main/Azure%20Policies/rules.json' -Parameter 'https://raw.githubusercontent.com/asanchezpaulete/Articles/main/Azure%20Policies/parameters.json' -Mode Indexed

And we can see, it created through the Azure Portal.

We are now going to check its operation, we are going to try to create a resource without a label to see if it will let us, remember that its default value is “Deny”.

To do this, we will first create a resource group in which we will assign this directive.

Home > Policy > Select policy > Assign

We will indicate the following:

  • Scope
  • Exclusions (if any)
  • Parameters to select the policy mode
  • In our case, we will not apply any remediation task, since our goal is to prevent us from creating the resource without the tag
  • Non-compliance message that will appear to the user who tries to break this rule

We proceed to create a vnet without label:

In the validation step, it will indicate that the test has not passed and that we should review the details, where we can see that it is because the policy is preventing the creation of this vnet with this configuration:

Let's create it now with the labels with the required value:

And with the labels established, we have passed the validation phase:

But we are not only denying the creation of resources if they do not comply with a certain structure, Azure Policies can also be useful to analyze an already deployed infrastructure, or in "Audit" mode to only evaluate compliance and not apply any effect of denial or modification. To do this, we will have to take into account that evaluations of assigned policies and initiatives happen as the result of various events:

  • A policy or initiative is newly assigned to a scope (takes around 30 minutes)
  • A policy or initiative already assigned to a scope is updated
  • A resource is deployed or updated within a scope with an assignment via Azure Resource Manager, REST API, or a supported SDK
  • A subscription is created or moved within a management group hierarchy with an assigned policy definition targeting the subscription resource type
  • A policy exemption is created, updated or deleted
  • Standard compliance evaluation cycle (once every 24h)
  • The guest configuration resource provider is updated with compliance details by a managed resource
  • On-demand scan

To launch an evaluation on demand, we must follow the following steps:

  • PowerCli
az policy state trigger-scan --resource-group "YOUR_RESOURCE_GROUP"

$job = Start-AzPolicyComplianceScan -AsJob
$job

In general, the results of a policy evaluation will be compliant or non-compliant.

When a resource is non-compliant, Azure provides us with three ways to look for information to find out why it is non-compliant:

  • Compliance details
  • Change history
  • Custom PowerShell Script

But this is for another article, along with the Policies with Remediation Task and managed identities and service principals…