Azure Firewall is the firewall-as-a-service solution exists in the Microsoft public cloud, which allows you to secure the resources present in the Azure Virtual Networks and to govern the related network flows. This service has been officially released from several months and, as is often the case with cloud services, there are rapid evolutions, to improve the service and increase the feature set. This article lists the top news that recently affected Azure Firewall.
Public IP addresses associated with Azure Firewall
While initially, only one public IP address could be associated with Azure Firewall, now you can associate up to 100 public IP addresses. This opens up new configuration and operation scenarios:
- In DNAT configurations you have the option to use the same port on different public IP addresses.
- For SNAT outbound connections will be available a larger number of ports, reducing the ability to finish the doors available.
Currently the source Public IP address of Azure Firewall used for the connections is chosen randomly. This should be considered when you need specific permissions for traffic from Azure Firewall. Microsoft still has a roadmap of SNAT configurations by specifying the Public IP address to use. The steps to deploy Azure Firewall with multiple public IP addresses, using PowerShell commands, you can consult in this document.
In order to increase the availability levels of Azure Firewall, you can, during the creation phase, plan to use the Availability Zones. Selecting two or more Availability Zones will allow you to get an uptime percentage of the 99.99 %. Full details about Service Level Agreements (SLA) of Azure Firewall are contained in this document. The adoption of this deployment methodology does not involve any additional costs, but you need to contemplate an increase in the costs of inbound and outbound data transfer from Availability Zones, available in this document. Compared to the cost of the Azure Firewall, these do not have a particularly significant impact. I personally think that if you adopt an architecture of the networking where Azure Azure Firewall is the core component for the security of the environment, it becomes very useful to use the Availability Zones to ensure a high level of availability of mission-critical applications protected by this service.
In the presence of Azure Firewall created without the use of Availability Zones, you do not have the possibility of carrying out a conversion to the use of the same. The only currently available method involves the creation of a new Azure Firewall migrating existing configurations. Backups in JSON format of the Azure Firewall configuration can be made using the following PowerShell commands:
$BackupFileName = ".AzureFirewallBackup.json"
Export-AzResourceGroup -ResourceGroupName "Network-RG" -Resource $AzureFirewallId -SkipAllParameterization -Path $BackupFileName
With the availability of the JSON file you need to edit it to contemplate the Availability Zones:
After the change is complete, you can deploy the new Azure Firewall, using suitably modified JSON file, using the following command:
Centralized management with third party solutions
Azure Firewall exposes publicly REST APIs that can be used by third-party vendors to provide solutions that allow a centralized management of Azure Firewall, Network Security Groups (NSGs), and network virtual appliances (NVA's). At the moment these are the vendors that offer such solutions: Barracuda with Cloud Security Guardian, AlgoSec with CloudFlow and Tufin with Orca.
Just-in-time (JIT) VM access for Azure Firewall
When a user requests access to a VM with a Just-in-time policy (JIT), the Security Center first checks whether the user actually has Role-Based Access Control permissions (RBAC) required to make the request for access. If so the request is approved, and the Security Center is able to automatically configure not only the NSG, but also the necessary rules in Azure Firewall side to allow incoming traffic.
Application rules with SQL FQDN
In application rule of Azure Firewall the ability to specify the SQL FQDN was introduced. This makes it possible to control access from the virtual network to specific instances of SQL Server. Through SQL FQDN you can filter traffic:
- From Virtual Network to a Azure SQL database or a SQL Azure Data Warehouse.
- From the on-premises environment to a SQL Azure Managed Instances or SQL IaaS running on Virtual Network.
- From spoke-to-spoke to Azure SQL Managed Instances or SQL IaaS running on Virtual Network.
FQDN Tag for Azure HDInsight (HDI)
Azure HDInsight clusters present on its Virtual Network have different dependencies on other Azure services (for example Azure Storage), with which an outgoing network traffic is necessary to operate in the correct way. With the introduction of the FQDN tags for HDInsight you can configure Azure Firewall to restrict outbound access for HDI clusters. For more details please visit the Microsoft's official documentation.
Automation to handle the backup
Having a strategy to restore the configuration of the service in a short time is critical because this service is the government center of your Azure networking environment and contains several rules to comprehensively manage the network traffic. The service currently does not have an integrated feature to make full backup periodically. In this article you can find a mechanism designed to make the scheduled backup of the configuration of this component using the Azure Automation service.
Azure Firewall is a solution that is increasingly being used in network architectures of Azure, for the advantages over firewall solutions by third party vendors and thanks to a constant enrichment of features offered. All these new features make Azure Firewall a more comprehensive solution, totally integrated in the platform, that allows you to secure the resources on Azure Virtual Networks with high flexibility.