{"id":22006,"date":"2020-07-01T18:13:20","date_gmt":"2020-07-01T17:13:20","guid":{"rendered":"https:\/\/aidanfinn.com\/?p=22006"},"modified":"2020-07-02T21:10:39","modified_gmt":"2020-07-02T20:10:39","slug":"rethinking-firewall-management-with-azure-firewall-manager","status":"publish","type":"post","link":"https:\/\/aidanfinn.com\/?p=22006","title":{"rendered":"Rethinking Firewall Management With Azure Firewall Manager"},"content":{"rendered":"

Microsoft has just announced the general availability<\/a> a feature that I’ve been waiting for since I first learned about it last Autumn, called Azure Firewall Manager. Azure Firewall Manager allows you to centrally manage one or more Azure Firewall instances through a central, policy-driven, user interface. And it’s those policies, Azure Firewall Policies, that made me re-think Azure Firewall management a few months ago when I was writing my Cloud Mechanix course (running next ONLINE on July 30th<\/a>) “Securing Azure Services & Data Through Azure Networking”.<\/p>\n

Azure Firewall Policy<\/h2>\n

This is a new resource type<\/a> that is generally available today. Azure Firewall Policy<\/a> outsources the configuration and management of the firewall to a policy resource; that means that the usual settings in the Azure Firewall for things like rules and Threat Intelligence\u00a0move<\/em> from the firewall resource to a policy when a policy is associated with the firewall.<\/p>\n

Policies can be created in a hierarchy. You can create a parent\/global policy that will contain configurations and rules that will apply to all\/a number of firewall instances. Then you create a child policy that inherits from the parent; note that rules changes in the parent instantly appear in the child. The child is associated with a firewall and applies configurations\/rules from the parent policy and the child policy instantly to the firewall.<\/p>\n

Problem<\/h2>\n

I’ve deployed and configured multiple customers where we have virtual data centers (VDCs, which are governed & secured hub and spoke architectures) across multiple regions. Creating rules configurations to allow flows from a spoke\/service in one region to another spoke\/service in another region is a royal pain in the tushie. Here’s the network flow (as I documented with routing here<\/a>):<\/p>\n

    \n
  1. Source device<\/li>\n
  2. Outbound NSG rules in source spoke<\/li>\n
  3. Firewall in source hub<\/li>\n
  4. Firewall in destination hub<\/li>\n
  5. Inbound NSG rules at destination spoke<\/li>\n
  6. Destination device<\/li>\n<\/ol>\n

    There are potentially 4 sets of rules to configure for a simple service running on a single protocol\/port. Today I configured Microsoft Identity Management for this scenario and there were dozens of protocol\/port combinations across three spokes. The work took hours to complete – which I did in code and it provided a working result for the identity consulting team.<\/p>\n

    I minimise the work by controlling outbound flows in the local hub firewall, not in the NSG. So the NSGs do not control outbound flows at all. I could allow all via the firewall, even to other private networks, but that goes against the idea of compartmentalisation or micro-segmentation to combat modern network threats – so I need to configure both firewalls for a flow.<\/p>\n

    Solution<\/h2>\n

    Re-think the firewall for a moment. Imagine you had one virtual firewall that spanned all of your Azure regional deployments. You can control all global flows with one configuration in that global virtual firewall. The global virtual firewall has instances in each Azure region. Any local flows can be configured just in that instance. That’s what Firewall Policy allows.<\/p>\n