Organizing rule collections and rule collection groups in Azure Firewall Policy (2024)

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:

¹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:

² 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.

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:

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.

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

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:

<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.