Azure Policy Overview
In this, we will get a brief about Azure Policy.
Azure Policy compares the attributes of Azure resources to business rules to assess them. Policy definitions are business rules defined in JSON format. Several business rules, on the other hand, might can come together to form a policy initiative to make management easier. Following the formation of business rules, the policy definition or initiative allocates to any Azure resource scope. Management groups, subscriptions, resource groups, and individual resources are all examples of this.
In addition, Azure Policy employs a JSON format to provide the logic that determines whether or not a resource is compliant. Metadata and the policy rule includes in the definitions. To match exactly the situation you want, the rule can include functions, arguments, logical operators, conditions, and property aliases. Policy rule decides which resources are in the scope of the assignment that evaluates.
Understand evaluation outcomes
Resources evaluates at particular points in their lives, such as throughout the resource lifecycle, the policy assignment lifecycle, and on a regular basis for ongoing compliance. The times or events that trigger a resource to be reviewed are as follows:
- Firstly, a resource creates, updates, or deletes in a scope with a policy assignment.
- Secondly, a policy or initiative newly assign to a scope.
- Thirdly, a policy or initiative already assign to a scope update.
- Lastly, during the standard compliance evaluation cycle, which occurs once every 24 hours.
Control the response to an evaluation
Organizations have different business principles for dealing with non-compliant resources. The following are some examples of how an organisation would want the platform to react to a non-compliant resource:
- Firstly, deny the resource change
- Secondly, log the change to the resource
- Thirdly, alter the resource before the change
- Then, alter the resource after the change
- Lastly, deploy related compliant resources
Azure Policy objects
Policy definition
In Azure Policy, we offer several built-in policies that are available by default. For example:
- Firstly, Allowed Storage Account SKUs (Deny). Determines if a storage account being deploys within a set of SKU sizes.
- Secondly, Allowed Resource Type (Deny): Defines the resource types that you can deploy. Its effect is to deny all resources that aren’t part of this defined list.
- Thirdly, Allowed Locations (Deny): Restricts the available locations for new resources.
- Then, Allowed Virtual Machine SKUs (Deny): Specifies a set of virtual machine SKUs that you can deploy.
- Add a tag to resources (Modify): Applies a required tag and its default value if it’s not specified by the deploy request.
- Lastly, Not allowed resource types (Deny): Prevents a list of resource types from being deployed.
Initiative definition
A set of policy definitions tailored toward attaining a single overall purpose is referred to as an initiative definition. Policy definitions are easier to manage and assign when using initiative definitions. They make things easier by combining a number of policies into a single piece. For instance, you might start an endeavor called Enable Monitoring in Azure Security Center with the purpose of monitoring all of your Azure Security Center’s available security recommendations.
However, under this initiative, you would have policy definitions such as:
- Firstly, monitor unencrypted SQL Database in Security Center – For monitoring unencrypted SQL databases and servers.
- Secondly, monitor OS vulnerabilities in Security Center – For monitoring servers that don’t satisfy the configured baseline.
- Lastly, monitor missing Endpoint Protection in Security Center – For monitoring servers without an installed endpoint protection agent.
Reference: Microsoft Documentation