- Boost PowerShell with Resource Graph queries in Azure - Tue, Oct 19 2021
- Work with Azure management groups and subscriptions using PowerShell - Mon, Sep 27 2021
- Manage Azure Policy using PowerShell - Thu, Aug 26 2021
Now there's another brand-new service, called Azure Firewall Manager (AFM). AFM is a service that allows us to orchestrate the things around security policies, Azure Firewall instances, virtual WANs, routing management, and even virtual networks and connections.
So, you don't really need to worry about taking care of all these individual resources. AFM is a flexible service that offers numerous options for deploying and managing your security infrastructure. There are two main options to go with in AFM in terms of architecture: hub virtual networks and secured virtual hubs.
Before these two in detail, let's have a quick look at Azure Firewall Policies. These policies comprise an important element for both options.
Azure Firewall policies ^
Azure Firewall policy is one of the new services on Azure that we can use to manage multiple firewall instances from a central point. A firewall policy simply consists of network rules, application rules, NAT rules, and threat intelligence settings. It's basically all you need in terms of rule collections. A firewall policy is a standalone resource that you can associate with Azure Firewalls using either AFM or its own resource in the Azure portal.
You can either associate the policy to an existing Azure Firewall or create a new Azure Firewall instance when creating a new policy through the wizard. You can even associate the same policy with more than one Azure Firewall. Also, you can use PowerShell to migrate existing firewall rules that run on a standalone Azure Firewall to a firewall policy.
These policies are global resources, so they work across regions and subscriptions without any restrictions.
Since Azure Firewall policies can be used with both hub virtual networks and secured virtual hubs, AFM manages the associations between Azure policies and the architecture model that you use.
Now let's take a detailed look at those two options, each of which uses different infrastructure in the background.
Hub virtual networks ^
A hub virtual network is based on a standard VNet. In this model, it is you who manages the VNets. So, basically, when you create a new hub virtual network or convert an existing VNet to a hub virtual network, AFM creates a new Azure Firewall instance and associates an Azure policy with it in the background. This can be considered a VNet that is associated with an Azure Firewall, which uses an Azure Firewall policy.
Once a new hub virtual network has been created, it appears as a "managed" firewall.
The wizard automatically creates an Azure Firewall resource in the background. While it can be seen in the resource group, it is not necessary to configure it individually as all elements, such as Azure Firewall policies, public IP configuration, and all other settings, can be managed in Azure Firewall Manager. If we go directly to the Azure Firewall resource that the wizard created, we can see that the Azure Firewall has become a "managed" firewall and has no "Rules" section. Instead, a firewall policy appears to have been associated with this firewall. So if we need to configure rules, we must go to the AFM console to do so.
Also, one of the nice things is that we can now use multiple public IPs with Azure Firewalls. This can be done in AFM or directly on the Azure Firewall resource itself.
Here are some important points to emphasize around hub virtual networks:
- Azure Firewall is the only option as a security provider that can be used with hub virtual So we cannot use trusted security partners with this model.
- Connection settings where network peerings can be managed are not This means that all network peering configurations need to be done at the VNet level.
- Routing is not yet supported.
- Only public IPs with standard SKUs are supported.
Secured Virtual Hubs ^
This architecture uses an Azure Virtual WAN hub, which is a separate resource on Azure that allows us to manage hub and spoke architecture. It has lots of cool features, such as creating VNet peerings without having to configure both VNets. So, once Azure policies are associated with this Virtual WAN resource, then it becomes a secured virtual hub. Using the wizard, you can either create a new Virtual WAN or use an existing one.
The main difference between these two architecture models is that in hub virtual networks, we use standard Azure Virtual Networks, and in secured virtual hubs, we use Virtual WANs.
Like hub virtual networks, secured virtual hubs are also attached to Azure Firewalls that are associated with Azure policies. A VPN gateway is needed if you are looking to integrate with a third-party trusted security partner.
Trusted security partners ^
This feature in AFM gives us the ability to use third-party providers to enhance security based on different routing models. Actually, in the eyes of Azure Firewall Manager, an Azure Firewall is also a security provider, just like other supported TSPs. There are two TSPs that can be associated with secured virtual hubs as of now.
Secured virtual hubs with a VPN gateway can be configured to use a TSP alongside an Azure Firewall.
Some use cases in terms of routing with Trusted Security Partners are as follows:
- Routing the traffic from a VNet to the internet via a trusted partner.
- Routing the traffic from an entire branch to the internet via a trusted partner.
- Combination of Azure Firewall and trusted partner. All the traffic toward the internet from a branch is controlled by the trusted partner, and the rest of the traffic is managed by Azure Firewall.
Routing in the above scenarios is managed automatically so we don't really need to manage user-defined routes manually.
Subscribe to 4sysops newsletter!
Azure Firewall Manager is an easy-to-use environment to centrally manage Azure Firewalls, Firewall policies, VNets, and Virtual WANs with flexible scenarios. On top of Azure Firewall's strong inbound and outbound traffic protection, AFM provides us with an additional layer of management where various types of architecture options can be configured to satisfy organizations with different needs.