Azure Policy

Created on 2021-10-29 07:19

Published on 2021-10-29 07:25

Azure Policy

Azure Policy is a service that allows an organization to set its standards and look at the compliance of the complete environment. From getting an overview of the environment to the compliance and standards of each resource, one can do it all with Azure Policy.

The idea is to set a framework for organization compliance and standards that can automatically tweak the new resources accordingly and enable them to be a part of the environment.

Azure Policy allows the implementation of governance over the consistency of resources, compliance to regulations, security, cost, etc. There are policies defined for some of the most common aspects, such as resource consistency, that you can access. However, for other more complex elements, there is a complete process that will be defined below.

How Does Azure Policy Work?

At first, policies are written and defined in a JSON format. These policy definitions are known as business rules. They are aligned with an organization's requirements and regulations that it has to comply with.

Policies can also be grouped to form a Policy set or a policy initiative. Once this is complete, these initiatives or sets are assigned to resources individually or as a group of resources. The idea behind grouping policies and resources is to simplify the management.

One can bring together or group resources to comply with similar policies or, on the flip side, group policies that a large chunk of resources will have to comply with.

The Policy usually includes metadata with rules. These rules are defined using functions, parameters, operators to create specific scenarios that you want.

The resources are then evaluated against these rules, definitions, and initiatives.

How Does The Evaluation Work?

When policies are written, a part of them is also meant for the subsequent actions after the resources have been evaluated. The actions are automatically triggered once the evaluation is complete. Furthermore, they vary from organization to organization based on their needs. Some of the common ways of dealing with the resources if they don't comply are as follows:

  1. Deploy the related resources that follow the compliance.
  2. Deny any changes to the resource.
  3. Alter the resource either before or after the change
  4. Log the resource change

Furthermore, there are multiple timings or instances when a resource can be evaluated throughout its lifecycle, from being created to becoming compliant. They are as follows:

  1. In the usual compliance check cycle.
  2. When a resource is created, modified, or removed.
  3. When a policy definition or initiative is assigned to a scope or resource.
  4. When an already assigned policy definition or initiative is updated.


Furthermore, pre-existing resources that are non-compliant can be remediated automatically.

How To Start Implementing Azure Policy

The three fundamental blocks of Azure Policy are:

As mentioned earlier, every policy definition is written with functions and parameters to establish certain conditions and guide subsequent actions if those conditions are met. Azure Policy provides a few built-in policy definitions that most organizations require as default.

Allowed Storage Account SKUs

This checks if the storage space allotted for SKUs is within the limit. If the resources do not comply with this limit, they are denied by the system.

Not Allowed Resource Types

As the name suggests, there is a list of resource types that shouldn't be allowed. So if those types of resources are found within the environment, they are prevented from being deployed.

Allowed Resource Types

This is the exact opposite of the previous built-in policy definition. This has a list of resource types that should be allowed in the environment. Any resource that doesn't comply with this list is prevented from being deployed.

Allowed Virtual Machine SKUs

This contains a list of virtual machine SKUs that are eligible to be a part of the environment.

These are just a few examples, and there are many more built-in policy definitions that an organization can pick and choose from.

Initiative

An initiative is essentially a group of policies that work towards accomplishing one overarching goal. For instance, all policy definitions that can aid in getting the monitoring a security center and creating reports can be grouped into one initiative.

This way, management will be much more straightforward and effortless. Like policy definitions, there are numerous built-in initiatives that organizations ideally need.

Some of those are Monitor OS vulnerabilities, unencrypted SQL database, missing endpoint protections, etc., in the security center.

Assignment

An assignment is essentially a policy definition of initiative assigned to a resource or a group of resources. The scope of an assignment changes based on the requirements, and all child resources will inherit the assignment from the parent resources.

For instance, if there's a networking group that includes all resources oriented with building and managing the network infrastructure, an assignment to the network group means assigning all the resources within.

However, exceptions can be made. For example, a subscope can be created to exclude specific resources from the assignment based on the organization's requirements.

Thus this is a brief overview of Azure Policy. It is important to note that it is vital to rely on cloud security framework initially until the organization understands the ins and outs of Azure Policy thoroughly. This is necessary to mitigate all the risks that might occur when an organization makes the transition.