Organizing rule collections and rule collection groups in Azure Firewall Policy

Firewall Policy is the recommended method to manage Azure Firewall security and operational configurations. When using Firewall Policy, any rules must be part of a rule collection and rule collection group. Rule collections are sets of rules that share the same priority and action, and can be of type DNAT, Network, or Application. Rule collection groups are containers for rule collections of any type and are processed first by Azure Firewall based on priority. To learn more about rules, rule collections, and rule collections groups, see Azure Firewall Policy rule sets.

 

This article provides some best practices for configuring and organizing Firewall Policy rules into rule collections and rule collections groups.

 

Rule processing logic

 

The first thing to note is that if threat intelligence-based filtering is enabled, those rules are evaluated first and may deny traffic before any configured rules are processed.

 

For configured rules, the following logic applies:

 

1. All DNAT rules are processed first, followed by Network rules, and lastly, by Application rules.
2. For each rule type stated in 1., the firewall evaluates rules based on priority. It will look at the rule collection group with the highest priority, and within that rule collection group, at the rule collection with the highest priority. Keep in mind that priority is any number between 100 (highest priority) and 65,000 (lowest priority).
3. If there are rules inherited from a parent policy, these will take precedence over rules configured in the child policy. Thus, the logic described in step 2. will apply to inherited rules first.

For detailed examples of this rule processing logic, see Rule processing using Firewall Policy.

 

How to structure your rule collections and rule collection groups?

 

While there is no one-size-fits-all approach, as it depends on an organization’s specific requirements, here are some general recommendations:

 

• Create a rule collection group per workload or per Line of Business (LOB), depending on the size of the organization. 
  • Allows for the separation of concerns, by grouping multiple rule collections, potentially of different types, into a single rule collection group.
  • Improves readability and management.
  • Particularly useful when adopting Infrastructure-as-Code (IaC). Rule collection groups are independent objects in Bicep, Terraform, or ARM templates, so you can have separate templates, one for each rule collection group, and assign different owners. Moreover, it minimizes the blast radius of changes.

Note: The maximum number of rule collection groups per firewall policy is 90, for policies created after July 2022, and 50 for policies created before July 2022. If you expect the number of workloads to surpass these values, create a rule collection group per LOB and leverage rule collections to segregate workloads. For more information on Azure Firewall limits, see Azure Firewall limits.

 

• Prioritize rule collections and rule collection groups based on their use frequency. Keep in mind that priority is any number between 100 (highest priority) and 65,000 (lowest priority).
  • Assign a higher priority to rule collections and rule collections groups that are expected to have more hits, and a lower priority to those that are more generic, less critical, or with a lower use frequency.
  • DNAT rules must have a higher priority than Network rules, and Network rules must have a higher priority than Application rules.
  • This approach optimizes rule processing, which in turn, contributes to maintaining the firewall’s optimal performance.
  • Can be monitored and fine-tuned as needed with the help of Azure Firewall Policy Analytics.

• Use an intuitive and consistent naming convention.

 

• Use IP groups or IP prefixes when configuring rules whenever possible.
  • Optimizes rule configuration and processing.
  • Simplifies management.

• Use the allow action for rule collections and rule collection groups that explicitly allow traffic that is required, and the deny action for rule collections and rule collection groups that explicitly block traffic not required. An example of this could be allowing internet access from your VNets, except for specific Web categories. Keep in mind that Azure Firewall denies traffic by default, so a ‘Deny All’ rule is generally not useful.

 

Reference implementations

 

In the following section, we will describe some potential ways to arrange rule collections and rule collection groups when setting up your firewall policy.

 

1. Single policy with rule collection group per workload

 

In this scenario, each workload has its own rule collection group encompassing all rules related to it. There is also a separate rule collection group for platform rules, i.e., rules that support the platform as a whole, regardless of workload. The tables below represent how this approach could look like.

 

Using as an example a fictional, publicly facing, application named ContosoWeb:

 

Name	Type	Action	Priority	Function
contosoWeb-rcg01	Rule collection group	-	500	Encompasses every rule related to this workload, typically deployed in its own VNet, peered to a hub VNet, or Virtual WAN hub, where the firewall is deployed.
contosoWeb-dnat-rc01	DNAT rule collection	Allow	501	Allows access from the Internet to this application via DNAT rule1.
contosoWeb-net-rc01	Network rule collection	Allow	502	Allows access from admins or developers in selected networks (Azure or on-premises).
contosoWeb-app-rc01	Application rule collection	Allow	503	Allows access from ContosoWeb resources to required FQDNs.

 

¹Azure Application Gateway (regional service) or Azure Front Door (global service) are the recommended products to securely expose HTTP(S) applications on the internet. Azure Firewall is primarily recommended for non-HTTP(s) applications. To see more information on how to leverage both Azure Firewall and Azure Application Gateway to secure workloads, see Firewall and Application Gateway for virtual networks.

 

Using as an example a second fictional application, but privately facing, named ContosoOps:

 

Name	Type	Action	Priority	Function
contosoOps-rcg01	Rule collection group	-	600	Encompasses every rule related to this workload, typically deployed in its own VNet, peered to a hub VNet, or Virtual WAN hub, where the firewall is deployed.
contosoOps-net-rc01	Network rule collection	Allow	601	Allows access to this workload from selected Azure VNets, branches, remote users, and/or vice versa. Allows access to specific Azure services leveraging service tags2.
contosoOps-net-rc02	Network rule collection	Deny	602	Blocks internet access from resources pertaining to this workload.

 

² If not using private endpoints to securely access PaaS services, it is recommended to enable virtual network service endpoints for those services in the Azure Firewall subnet (not applicable when deploying Azure Firewall in Virtual WAN hub), and disable them in the connected spoke virtual networks. To learn more about service tags and virtual network service endpoints, see Virtual network service tags.

 

If applicable, each workload can have a rule collection group dedicated to its test or sandbox environment. This ensures that any changes to the test environment do not affect production rules, thus preventing unwanted changes.

 

Name	Type	Action	Priority	Function
contosoOps-test-rcg02	Rule collection group	-	700	Includes all rules related to the test environment of contosoOps.
contosoOps-test-net-rc01	Network rule collection	Allow	701	Allows access from developers in selected networks (Azure or on-premises) to contosoOps test environment.

 

Name	Type	Action	Priority	Function
platform-all-wrkls-rcg01	Rule collection group	-	800	Workload-agnostic rules, enforced by a general network admin, that support the platform and follow org-wide security standards.
all-wrkls-net-rc01	Network rule collection	Allow	801	Allow all workloads access to shared services – domain controllers, for example – or cloud services leveraging service tags2.
all-wrkls-app-rc01	Application rule collection	Allow	802	Application rules to allow all workloads access to Microsoft services - for instance, Windows Update traffic - leveraging FQDN tags.
all-wrkls-app-rc02	Application rule collection	Deny	803	Enforce internet browsing restrictions from Azure networks, leveraging Web Categories, for example.

 

This is a graphical representation of this reference implementation:

Reference implementation 1 - Single policy with rule collection group per workload.

2. Policy with rule collection group per Line of Business (LOB) and inherited rules from parent policy

 

In this scenario, a parent policy is used to enforce platform rules on potentially several firewall instances, in different regions. Applications are grouped into Lines of Business (LOBs), each having a dedicated rule collection group. Rule collections are used to distinguish between applications belonging to the same LOB. Firewall administrators in each region handle the configuration of their child policy.

 

Using the previous example as a basis, this approach would result in the following rule collection and rule collection group structure:

 

Name	Type	Action	Priority	Function
contosoApps-rcg01	Rule collection group	-	500	Encompasses every rule related to ContosoApps LOB.
contosoWeb-dnat-rc01	DNAT rule collection	Allow	501	Allows access from the Internet to ContosoWeb via DNAT rule1.
contosoWeb-net-rc01	Network rule collection	Allow	502	Allows access from admins or developers in selected networks (Azure or on-premises).
contosoOps-net-rc01	Network rule collection	Allow	503	Allows access to ContosoOps from selected Azure VNets, branches, remote users, and/or vice versa. Allows access to specific Azure services leveraging service tags2.
contosoOps-net-rc02	Network rule collection	Deny	504	Blocks internet access from resources pertaining to ContosoOps.
contosoOps-test-net-rc01	Network rule collection	Allow	505	Allows access from developers in selected networks (Azure or on-premises) to contosoOps test environment.
contosoWeb-app-rc01	Application rule collection	Allow	506	Allows access from ContosoWeb resources to required FQDNs.

 

 

The same logic can be used for other LOBs. Notice that contosoWeb-app-rc01 rule collection has a lower priority than the network rule collections of contosoOps, even though it had a higher priority in the previous example. contosoOps-test-net-rc01 also gets a lower priority number (meaning higher priority) than in the previous example.

 

This meets the requirement to make sure that, within the same rule collection group, DNAT rules have a higher priority than Network rules, and that Network rules have a higher priority than Application rules.

 

The rule collection group dedicated to platform rules remains practically the same in this example, except for org-wide restrictions such as all-wrkls-app-rc02, enforced by a parent policy instead. The names of the rule collections and rule collection groups are also slightly different to distinguish between regional and global rules.

 

Name	Type	Action	Priority	Function
<region>-platform-all-wrkls-rcg01	Rule collection group	-	800	Workload-agnostic rules, enforced by a regional network or firewall admin.
<region>-all-wrkls-net-rc01	Network rule collection	Allow	801	Allows all workloads access to shared services – domain controllers, for example – or cloud services leveraging service tags2.
<region>-all-wrkls-app-rc01	Application rule collection	Allow	802	Application rules to allow all workloads access to Microsoft services - for instance, Windows Update traffic - leveraging FQDN tags.

 

Moreover, this policy would inherit the following rule collection group from its parent policy:

 

Name	Type	Action	Priority	Function
global-platform-all-wrkls-rcg01	Rule collection group	-	1000	Workload-agnostic rules, enforced by a global network or firewall admin and that enforce org-wide security standards.
global-all-wrkls-app-rc01	Application rule collection	Deny	1001	Enforces internet browsing restrictions from Azure networks, leveraging Web Categories, for example.

 

Here's the graphical representation of this reference implementation:

Reference implementation 2 - Policy with rule collection group per Line of Business (LOB) and inherited rules from parent policy.

Lastly, the following table illustrates how the order of evaluation by the firewall is impacted by each approach:

 

1. Single policy with RCG per workload	2. Policy with RCG per LOB & inherited rules
contosoWeb-dnat-rc01	contosoWeb-dnat-rc01
contosoWeb-net-rc01	contosoWeb-net-rc01
contosoOps-net-rc01	contosoOps-net-rc01
contosoOps-net-rc02	contosoOps-net-rc02
contosoOps-test-net-rc01	contosoOps-test-net-rc01
all-wrkls-net-rc01	<region>-all-wrkls-net-rc01
contosoWeb-app-rc01	<global>-all-wrkls-app-rc01
all-wrkls-app-rc01	contosoWeb-app-rc01
all-wrkls-app-rc02	<region>-all-wrkls-app-rc01

 

<global>-all-wrkls-app-rc01 (all-wrkls-app-rc02 in example 1.) is evaluated before any other application rules in example 2. because it is inherited from a parent policy. Rule collection groups from a parent policy always take precedence, regardless of the priority of the child policy.