Microsoft's public cloud introduces the new management service Azure Firewall Manager that allows you to centrally manage security policies and routing rules. With this solution, you can better govern the security perimeters of your cloud environments and help you protect your business ecosystem. This article lists the key features of the new service, highlighting the benefits that can be gained by using it.
The security model, defined Zero trust by Forrester Research analysts, and in contrast with the conventional models based on perimeter security, directs us to adopt an approach related to micro-segmentation and the definition of granular perimeters in its network architecture. To facilitate this approach, Microsoft has released this tool that, providing a single centralized control panel, is able to simplify the configuration and management of network security policies, which often need to be deployed across multiple Azure Firewall instances.
Azure Firewall Manager at the moment is integrated with Azure Virtual WAN, the service that allows you to implement network architectures that are managed according to the hub and spoke model. Azure Firewall can now be enabled in Virtual WAN Hub networks, and when security and routing policies are associated by Azure Firewall Manager the Hub network is defined as a Secured Virtual Hub.
Adopting Azure Firewall Manager you can get the following benefits:
- Centralized configurations and deployments: deploying and configuring multiple instances of Azure Firewall, in Virtual WAN Hub networks, can be done centrally. These Azure Firewall instances can reside in different Azure regions and on different subscriptions. Furthermore, you can organize a hierarchy of DevOps-optimized Azure Firewall policies, where Global firewall policies are managed by central IT and local policy firewalls are delegated to DevOps to promote better agility in processes.
- Automated routing: comes the ability to easily route traffic in a centralized manner from the spoke networks to the Secure Virtual Hub, all without having to manipulate the User Defined Routes of spoke networks.
- Integration with Partners Security as a Service (SECaaS) of third party: to further enhance the security features it can be integrated with SECaaS partners, today Zscaler and iBoss, but soon it will be possible even with CheckPoint.
In detail the steps to adopt the solution are as follows:
- Creating the hub-and-spoke network architecture, using the Azure Virtual WAN service and activating an Azure Firewall instance in the Hub network. To do this, you can do by using two separate modes:
- Creating a new one Secured Virtual Hub by Azure Firewall Manager and adding virtual network connections;
- Transforming an existing Virtual WAN Hub, activating the Azure Firewall service on the Hub network.
- Selecting security providers (Optional). This can be done either during the process of creating a Secure Virtual Hub or during the conversion of a Virtual WAN Hub in a Secure Virtual Hub.
- Creating a firewall policy and association with the Network Hub. This is only possible for Azure Firewall Policies, while for Security as a Service solutions policies (SECaaS) provided by partners, you need to use their management tools.
- Configuring routing settings on the Secured Hub to attract the traffic of the spoke networks and make it filtered according to the defined policies.
At the moment Azure Firewall Manager is supported only for managing Hub and Spoke architectures created through the Azure Virtual WAN service. Support for managing Azure Firewall instances enabled in Virtual Networks is expected in the first half of next year.
Azure Firewall Manager is a tool that is very useful for managing complex environments composed of different network architectures that adopt the Hub and Spoke model over Azure Virtual WAN. This additional management service despite the dawn, and destined to get rich soon with new features, is essential to manage more easily and effectively the Azure network architecture. At the moment the service is Public Preview, so are not guaranteed SLA (Service-Level Agreements) and it should not be used in production environments.