
close
close
We are not short of options to deploy network security in the form of a firewall in Azure:
advertisment
And earlier this year, Microsoft released a preview of the Azure Firewall, a new Azure firewall service. Unlike NSGs, Azure Firewall is intended to be a centralized deployment. And unlike the WAF, Azure Firewall is not instance-based; it operates as a true PaaS feature and doesn’t bother you with worrying about deployed instances. Instead, the Azure Firewall automatically scales under the covers to deal with your workloads. And unlike NVAs, you won’t need to license a third-party service to use the WAF.
The Azure Firewall is not a budget service; it will start at over $900 per month for a deployment, plus $0.03 per GB of inbound/outbound of data that is processed. This will give you a clue as to how Azure Firewall should be used.
Very often in the cloud, firewall services are distributed. It’s not uncommon to see NSGs on every subnet and a WAF for every application. Azure Firewall is intended to be deployed in a hub VNet that is managed by network admins or IT security. Applications can then be deployed into spoke virtual networks without a public IP address.
Note that Azure Policy could be used to restrict the creation of public IP addresses.
Each of the spoke networks can peer with the hub with IP forwarding enabled from the hub into the spoke VNets; this will allow the firewall to forward traffic into applications running in the spokes. And now, the Azure Firewall can control traffic into and between the spoke VNets.
Azure Firewall is deployed into a hub virtual network [Image Credit: Microsoft]
The Azure Firewall is not instance based. The goal is that you deploy it and configure it and let Azure worry about sizing – therefore you pay for data processed. It is a highly available service that should scale to match the requirements of the applications that it protects.
By default, the Azure Firewall blocks all traffic, inbound and outbound. Outbound traffic can be allowed based on IP address, CIDR block or HTTP/HTTPS fully qualified domain names (FQDNs). All traffic leaving the spoke VNets will be translated to the Standard tier public IP address of the Azure Firewall, allowing you to identify that traffic in remote networks.
Inbound traffic can be translated to private IP addresses that are protected by the Azure Firewall – this is a new feature that was not available in the preview. Destination Network Address Translation (DNAT) is what this feature is called, and you will see the phrase “DNAT” throughout the Azure Firewall documentation. It is simply referred to as NAT in the Azure Portal.
All events that happen are integrated into Azure Monitor. You can archive these events in a storage account, Log Analytics or stream the events to an Event Hub.
The Azure Firewall preview was a limited one. I thought Microsoft would launch a public preview at the Ignite conference, so I was surprised to see it have become generally available. There are a few kinks, but this is The Cloud and things should improve quickly:
advertisment
The Azure Firewall is pretty simple to deploy. I think that the main thing to consider is that this is intended to be a centrally deployed security service, so you must plan out your network architecture. Applications will be deployed into spoke VNets, possibly with application gateways and/or load balancers, and even with the Layer-7 WAF, but with private IP addresses. Routing tables will have to be deployed to control the flow out outbound traffic through the Azure Firewall, and this firewall will also control the flow of traffic between applications. And yes, NSGs will still play a role, however, Application Security Groups will probably flatten deployments that previously might have contained many subnets.
The example deployment documentation that Microsoft has shared is pretty good – you can see that some minor UI stuff changed at the last second. What I think is missing now are reference architectures to display end-to-end architectures that Microsoft will be recommending for different patterns involving the Azure Firewall.
More from Aidan Finn
advertisment
Petri Newsletters
Whether it’s Security or Cloud Computing, we have the know-how for you. Sign up for our newsletters here.
advertisment
More in Microsoft Azure
Microsoft's Azure AD Conditional Access Service Can Now Require Reauthentication
May 13, 2022 | Rabia Noureen
Microsoft Addresses Cross-Tenant Database Vulnerability in Azure PostgreSQL
Apr 29, 2022 | Rabia Noureen
Microsoft Simplifies IT Monitoring with New Azure Managed Grafana Service
Apr 19, 2022 | Rabia Noureen
System Center 2022 is Now Available with New Datacenter Management Capabilities
Apr 4, 2022 | Rabia Noureen
Most popular on petri
Log in to save content to your profile.
Article saved!
Access saved content from your profile page. View Saved
Join The Conversation
Create a free account today to participate in forum conversations, comment on posts and more.
Copyright ©2019 BWW Media Group