Delegate firewall rule-group editing without granting policy-hierarchy changes

Source facts

Microsoft’s Firewall Policy hierarchy example uses a custom role to give application teams selective access to rule collection groups. In the documented outcome, those users cannot delete the firewall or policy, change policy hierarchy, or update DNS and threat-intelligence settings. The example assigns the role at the relevant application-team policy. Microsoft Learn.

Applicability

Use this review for a proposed application-team delegation model. Identify the team policy, inherited base policy, rule groups and existing effective permissions. The example’s restrictions should be verified against the actual role assignments rather than assumed from a custom role’s name.

DSE recommendation

DSE recommends an explicit allowed-and-denied task list before granting access. Have security owners identify the rule groups the team may edit and the policy controls they must retain centrally. Review the current source’s role definition and assignment scope, then check for other grants that could undermine the intended separation. Preserve ownership and access-review evidence with the delegation.

Verification

With an approved test identity, confirm a permitted rule-group edit in a test policy. Assess restricted operations through effective permissions and safe authorization checks, without deleting a production object as a test. Record the identity, assignment scope and outcomes. Resolve broader inherited access before claiming that the delegation is limited to rule editing.

Official references

Microsoft Learn: Use Azure Firewall policy to define a rule hierarchy.