Category Archives: Azure Networking

How to configure the Azure Bastion service to securely access virtual machines

Azure Bastion is a PaaS service that provides secure and reliable RDP and SSH access to virtual machines, directly through the Azure portal. The provisioning of Azure Bastion service is carried out within a Virtual Network of Azure and it supports access to all the virtual machines on it attested, without having to assign public IP addresses directly to systems. This article describes how to activate the service and what things to consider.

Azure Bastion deployment is per virtual network and not per subscription or per single virtual machine. Therefore, after the configuration is complete, you will be able to access directly from the Azure portal all the virtual machines attested on the Host Bastion virtual network.

Activating the Azure Bastion service requires:

One subnet at least /27, which should be called AzureBastionSubnet and on which the Bastion host will be attested. On this subnet is not currently supported the configuration of User Defined Routes.
A Static Public IP address that will be assigned to the Bastion resource. The public IP must be standard SKU and must be in the same Azure region on which you want to activate the service.

On the subnet AzureBastionSubnet you can apply a specific Network Security Group (NSG). NSGs are the primary tool for controlling network traffic in Azure and allow you to filter communications with deny and permit rules.

To do this, you should review the network traffic required for Azure Bastion:

Figure 1 – Network flows required for Azure Bastion

The Network Security Group (NSG) on the subnet AzureBastionSubnet must include the following rules.

Inbound security rules

Inbound traffic from Internet: Azure Bastion Public IP address must be accessed on TCP port 443. The ports 3389/22 *are non required.
Inbound traffic from the Azure Bastion control plane. You need to enable the port 443 inbound using the service tag GatewayManager. This allows the control plane, (Gateway Manager), to be able to communicate with Azure Bastion.

Figure 2 – AzureBastionSubnet NSG – Inbound security rules

Outbound security rules

Outbound traffic to target VMs: Azure Bastion will reach the destination VMs via private IP address. NSGs must allow outbound traffic to other destination subnets for ports 3389 and 22.
Outbound traffic to other public endpoints in Azure. Azure Bastion must be able to connect to various public endpoints within Azure (for example, to store diagnostic logs and metering logs). That's why, Azure Bastion must be allowed to exit with the port 443 towards the service tag AzureCloud.

Figure 3 – AzureBastionSubnet NSG – Outbound security rules

For the subnet on which the machine that needs to be accessed by Azure Bastion is attested, the following rules must be provided.

Inbound security rules

Inbound traffic from Azure Bastion: Azure Bastion will reach the destination VM via private IP on ports RDP / SSH (ports respectively 3389 and 22). Therefore, as best practice, you can only add the Azure Bastion subnet as the source in this rule.

Figure 4 – NSG on the target subnet

The creation of the Azure Bastion host can be done directly from the Azure portal by completing the following steps:

Figure 5 – Adding the Azure Bastion service

Figure 6 – Parameters required when creating the Azure Bastion service

After configuring the Azure Bastion service, you can use it as follows.

Figure 7 – Accessing a VM from the Azure portal

Figure 8 – Enter credentials to sign in to a VM from the Azure portal

Figure 9 – RDP access to the VM directly from the browser

To allow access to the service, you must assign the following roles:

Reader role on the virtual machines that you want to allow access to
Reader role on NICes with virtual machine private IP address
Reader role on Azure Bastion resource

Azure Bastion is a paid service, to get cost details you can access the page Azure Bastion pricing.

Conclusions

Azure Bastion guarantees simple and secure remote access to systems in the Azure environment. There are several features that will be released soon for this service and that will make it even more complete and flexible. These include support for Virtual Network in peering and multi-factor authentication.

Azure Networking: how to secure Window Virtual Desktop deployments

Windows Virtual Desktop is a full desktop and application virtualization service available in Azure that, in a period like this, where work from home has increased exponentially, has seen wide adoption. Enabling your employees to work from home requires organizations to address major changes in their IT infrastructure in terms of capacity, network, security and governance. The Virtual Desktop Infrastructure solution (VDI) in Azure can help business companies effectively address these evolutions, but you need to protect access to these VDI environments appropriately. This article describes how you can structure networking in Azure to effectively protect Windows Virtual Desktop deployments.

In order to adopt the right approach, it is necessary to evaluate which are the components of Windows Virtual Desktop (WVD) and their iterations. The service is distributed according to a shared responsibility model and sees:

RD Clients connected to the desktops and applications provided by the WVD service. The environment can be reached from any location with Internet access and client management falls under the customer's responsibilities.
Managed Azure Services responsible for piloting connections between RD clients and Windows virtual machines in Azure. These are the server roles that are required for this environment, such as Gateways, Web Access, Brokers and Diagnostics, fully managed by Microsoft.
Virtual machines in Azure attested on a virtual network, whose management is totally in charge of the customer.

Figure 1 – Shared Responsibility model di Windows Virtual Desktop

To secure your Windows Virtual Desktop environment, you must define the most appropriate network topology and the necessary communication flows.

Hub-Spoke Network Topology for Windows Virtual Desktop

In a Hub-Spoke network architecture, theHub is a virtual network on Azure that serves as the point of connectivity to the on-premises network. This connectivity can be done through VPN Site to site or through ExpressRoute. TheSpoke are virtual networks running the peering with the Hub and can be used to isolate workloads. A good approach would therefore be to structure Azure networking by adopting this network topology right away and place the Windows Virtual Desktop virtual machines on a Spoke network. This network architecture is also designed to place in the Hub network a network virtual appliance (NVA) to control network flows centrally. Control of network communications can be assigned to a network virtual appliance (NVA) or to Azure Firewall, Microsoft's managed and fully integrated public cloud service, that allows you to secure the resources present on the Virtual Networks of Azure.

Figure 2 – Hub-spoke network topology in Azure

Communication flows required for Windows Virtual Desktop

There are several communication flows that need to be predicted and that thanks to the Hub-Spoke network topology you can easily and centrally govern.

Figure 3 – Communication flows for the Windows Virtual Desktop environment in the Hub-Spoke topology

Windows Virtual Desktop does not require that you have to open inbound communication streams to the virtual network on which its virtual machines are attested.

However, in order for the service to work properly, you must provide access from WVD machines, attested on the spoke virtual network, towards specific Fully Qualified Domain Names (FQDNs). The full list of addresses required for Windows Virtual Desktop to work can be found in this Microsoft's document. To simplify this configuration, Azure Firewall has the appropriate tag FQDN called WindowsVirtualDesktop, that you can use in a specific application rule. In this regard, it is good to specify that this tag does not include access to the storage and service bus accounts required for Windows Virtual Desktop pool hosts. As deployment-specific URLs, you can go to allow https traffic on time to specific URLs, or you can use the wildcard for the following FQDNs: *xt.blob.core.windows.net, *eh.servicebus.windows.net and *xt.table.core.windows.net. These FQDN tags are also present in third-party Virtual Appliances to facilitate configuration.

Windows Virtual Desktop machines must also have access to DNS servers, KMS service for activation jobs and NTP servers for time synchronization.

Depending on your business needs, you may also need to enable Internet access for end users, optionally applying specific navigation rules. A secure web gateway located on-premises or the network virtual appliance located in the Hub network can be used to filter Internet traffic.

Finally, you should allow the necessary communication flows between Windows Virtual Desktop machines, placed in the Spoke network, resources that reside in the on-premises environment.

Conclusions

One of the first aspects to consider when you implement solutions in the cloud is the network architecture to be adopted. Establishing the most appropriate network topology from the outset allows you to have a winning strategy and avoids being in the condition of having to migrate workloads later, to adopt different network architectures, with all the complications that ensue. The Hub-Spoke network architecture also lends itself well for Windows Virtual Desktop deployment scenarios, as it allows to obtain a high level of control on aspects related to network security and to segregate network traffic by adopting Azure Firewall or third-party Network Virtual Appliance.

Azure Networking: IP address management for outbound traffic from Azure

When designing architectures in Azure, it is often important to accurately determine which public IP addresses are used for outbound network traffic. A commonly required requirement is to ensure that outbound traffic from the Azure virtual network occurs with established public IP addresses. This requirement is typically due to the need to explicitly authorize traffic from Azure on other resources. This article describes how in Azure you can govern this aspect, what are the elements to be taken into consideration and what innovations have recently been introduced in this area.

By default, outbound traffic from an Azure virtual network uses randomly allocated public IP addresses, and they can change.

Public IP Assignment to the Single Virtual Machine

When you need to fix the Public IP address for the outbound traffic of a single virtual machine, the easiest method is to assign a Public IP address to it. This IP address will be used for inbound traffic, if necessary, and for outbound traffic. Through Network Security Groups (NSGs), the primary tool to control network traffic in Azure, you can filter communications with deny and permit rules.

Public IP Assignment to Load Balancer

Instead of assigning a public IP address directly to a virtual machine, you can assign it to a load balancer. In this way, any virtual machine added to the load balancer back-end pool will use the public IP assigned to it for outbound network traffic.

Figure 1 – Load Balancer with Public IP

This approach is recommended if there is a real need to use a Load Balancer to balance inbound network traffic across multiple virtual machines. This also allows you to limit the number of public IPs required, configuring multiple virtual machines behind the same load balancer.

Using Azure Firewall

If you have Azure Firewall, if network traffic is appropriately channeled to this component through specific routes, you are sure that it will go out to the Internet using the Public IPs assigned to the Azure Firewall instance. You can associate to Azure Firewall up to 250 public IP addresses, However, consider that the Azure Firewall Source Public IP address used for connections is currently randomly chosen from the assigned IPs. This is something to consider when you need specific permissions for traffic from Azure Firewall and whether you need to manage access to FTP Passive (unsupported if Azure Firewall has multiple IP addresses assigned). Microsoft still has a roadmap of SNAT configurations by specifying the Public IP address to use.

Figure 2 – Azure Firewall overview

Azure Firewall is an increasingly popular component and its activation is recommended to better manage and govern network traffic. However, In the absence of this component it is possible to evaluate less expensive alternative methods if the only goal is to govern which IP addresses are used in outbound network traffic.

Virtual Network NAT

Virtual Network NAT is a new method that was recently introduced to simplify Internet connectivity in virtual networks and affects outbound network traffic only. If configured on a subnet, all outbound traffic will use the specified static public IP addresses. All this is possible without the adoption of public IP addresses directly linked to virtual machines and load balancers.

Figure 3 – Virtual Network NAT

A subnet can then be configured by specifying which NAT Gateway resource to use. When configuration is complete, all outbound network flows (UDP and TCP) from any virtual machine attested on that subnet, will use the Public IP (standard SKU), the Public IP Prefix or a combination of these. The same NAT Gateway resource can be used by multiple subnets, as long as they belong to the same Virtual Network.

Virtual Network NAT is compatible with the following resources, having Standard SKUs:

Load balancer
Public IP address
Public IP prefix

These components, used in conjunction with Virtual Network NAT provide inbound Internet connectivity to subnets. Virtual Network NAT instead manages all internet connectivity outbound from the subnet. The joint use of these components is possible as they are aware of the direction in which the flow was started and allow them to be managed correctly.

Figure 4 – Virtual Network NAT flow direction

The guaranteed SLA for this feature is 99.9%, as it is automatically distributed by the platform on multiple fault domains to best support any fault.

Virtual Network NAT is by default a regional service and you can isolate it in a specific area (zonal deployment), when you have to contemplate scenarios that adopt different availability zones.

Figure 5 – Virtual Network NAT with availability zones

To monitor the usage of this component and to perform troubleshooting operations, you can review the metrics exposed in Azure Monitor:

Bytes
Packets
Dropped Packets
Total SNAT connections
SNAT connection state transitions per interval.

NSG flow logging is not currently supported for Virtual Network NAT.

The cost of this component is due to two factors:

Hours of resource existence
Processed data

For more details on costs please visit the Microsoft pricing page for this component.

Conclusions

To govern which IP addresses are used by systems in Azure to communicate externally there are several possibilities, each with its own characteristics. If you are adopting the Hub-spoke network topology with an Azure Firewall in the Hub network, control is guaranteed by design. A great solution in the absence of Azure Firewall or other Network Virtual Appliances is the adoption of the methodology Virtual Network NAT recently introduced.

Training: Cloud Community with the school to explore the digital world

We are pleased to inform you that our community will participate in a major training project dedicated to the classes fourth and fifth of the’State Higher Institute P. Gobetti in Scandiano (RE).

The training initiative in two months will involve about 50 Guys. It is a training course specifically designed to bring students closer to the big digital topics. The following are the themes covered during this project.

Automation with Powershell

Powershell is Microsoft's multi-platform shell designed to automate and make repeatable administrative operations on IT systems. Automation makes certain and repeatable operations applied to a few units or thousands of systems. In this introductory module, you will limit ourselves to the management of the Windows platform and you will not cover themes related to the Linux platform.

Goals

Making students able to:

Identify different versions of Powershell and usage scope
Describe powershell features, search and perform basic commands
Use powershell pipeline
Working with variables, array and hash tables
Write a simple powershell script
Run remote powershell commands and scripts

Prerequisites

Object programming logic
Understanding the basic mechanisms for authentication and authorization in an Active Directory Domain

Teacher

Daniele Grandini

Cloud Networking in Hybrid Environments

Enterprise IT is no longer limited to proprietary networks between locations or factories, the public cloud in its various forms is now a fundamental component of any IT architecture. The ability to interconnect systems and services is the first brick for building a hybrid environment between public and private (on-premises). In this module, students will be able to understand public cloud networking and connect the public cloud with the private network.

Goals

Making students able to:

Identify major public cloud providers
Describe the different types of cloud computing
Describe cost management differences between proprietary systems and cloud computing (if they also study economics there may be a reference to the difference between capital expenses and operational expenses)
Describe what virtual networking is all about, and in particular, Microsoft Azure virtual network concepts
Gather the information you need to create a virtual network on Microsoft Azure
Creating subnets into virtual networks, define routing rules and network security groups
Know the different types of connectivity between different virtual networks and between virtual networks and private networks
Connect an Azure virtual network with a private on-premises network
Security overview for public cloud virtual networks.

Prerequisites

Knowledge of the tcp/ip protocol and routing modes

Teacher

Francesco Molfese

Conclusions

The main goal of this community initiative is to help and incentivize young talents to grow and train for digital professions. Thanks to this training course, it will be possible for young participants to approach the world of work with greater awareness and a wider vision..

How to activate an SFTP service in Azure based on Container

A communication protocol that is commonly used for transferring files between different business realities is certainly SFTP (SSH File Transfer Protocol or Secure File Transfer Protocol). To date, Azure does not have a fully managed platform service that allows you to provide access over the SFTP protocol. Activating a virtual machine in Azure that hosts the SFTP service incurs activation costs and a significant management effort. This article provides a solution that you can use to deliver the SFTP service to Azure in an Azure environment., Azure Container Instances (ACI) and Azure File Shares.

The proposed solution is based on the following components::

Azure Container Instances (ACI), It is the easiest and quickest way in Azure to run containers on-demand in a managed serverless environment. All this is made possible without having to activate specific virtual machines and the necessary maintenance is almost negligible. The solution Azure Container Instances is eligible in scenarios that require isolated containers, without the need to adopt an orchestration system. The service Azure Container Instances costs depend on the number of vCPUs and memory GBs used by the container group.. For more details on costs please visit the Microsoft official page.
Azure File, the managed Azure service that allows you to access file shares in the cloud through the Server Message Block (SMB).

Figure 1 – Azure architecture

You will then be activated Linux-based docker container to deliver the SFTP service through Azure Container Instance (ACI). In order to have a persistent storage access from the container it will be made the mount of an Azure Files Shares. Files transferred via the SFTP service will therefore also be accessible via SMB protocol, managing the appropriate permissions, also stopping the execution of the container created.

To deploy this solution, you can use the referenced templates as a starting point in this Microsoft's document. These are two templates, where the first also involves creating a storage account, but of type V1.

Figure 2 – Deployment via custom template

In order to get a proper integration with existing Azure environments and to ensure a filtered access to the SFTP service you must deploy instances of containers inside an Azure virtual network. To do this, you need to enable a feature in preview, and as such has some limitations, between which does not support peering of virtual networks. In this scenario, if the SFTP service is required to be published to the internet, this will necessarily have to take place via Azure Firewall, as it is not supported directly assigning Public IP to Azure Container configured in Virtual Network. In order to improve the security postures of your Azure environment, it is also recommended that:

Take a micro-segmentation and granular perimeter definition approach in Azure network architecture. To do this, addition to the adoption of Azure Firewall, you need to plan for the use of the Network Security Groups (NSGs), the tool used to segregate network traffic internally with the Azure Virtual Network. Through deny and permit rules can be filtered communications between different subnets where different application workloads are attested.
Predicting the use of Virtual Network (VNet) service endpoints to increase the security level of the Storage Account, preventing unauthorized access. The vNet Service Endpoints allow you to isolate the Azure services, allowing access to them only by one or more subnets defined in the Virtual Network. This feature also ensures that all traffic generated from the VNet towards the Azure services will always remain within the Azure backbone network.

To complete this solution, you must also have a data protection strategy that is placed on the storage account through the SFTP service. Content transferred via SFTP service to Azure file shares can be backed up using the Azure Backup. Again, this is at the time of a feature in preview, so you can have a protection with a daily frequency.

To date, as an alternative to this solution, you can adopt third-party solutions available in the Azure marketplace to deliver the SFTP service. These are significantly more expensive solutions that typically require more effort to deploy and manage them.

Conclusions

Waiting for Microsoft to release a fully managed SFTP service in Azure, this solution enables this service quickly and easily, with reduced costs and without having to maintain and manage virtual machines. The adoption of this solution need integration with other Azure services platform to implement it effectively, without neglecting the safety aspect. At the time you may need to use services in preview, but not officially supported in a production environment.

[Video] – Architecting and Implementing Azure Networking

To implement hybrid clouds securely and functionally, an in-depth understanding of the various aspects of Azure networking is crucial. Recently I had the pleasure of participating in the Italian Cloud Conference where I held a session related to the Azure Networking. In this regard, I report the video of the session where 360-degree exploration of the key elements to be considered in order to build hybrid network architectures, taking advantage of the various services offered by Azure, in order to achieve the best integration with the on-premises environment, without ever neglecting security. Advanced hybrid network architecture scenarios were explored during the session, showing real-world examples, result of a’direct experience in the field.

Azure Networking: managing micro-perimeters with Azure Firewall Manager

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.

Figure 1 – Overview of Azure Firewall Manager

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.

Figure 2 – Central security e route policy management

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:
1. Creating a new one Secured Virtual Hub by Azure Firewall Manager and adding virtual network connections;
2. Transforming an existing Virtual WAN Hub, activating the Azure Firewall service on the Hub network.

Figure 3 – Start the process using Azure Firewall Manager

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.

Figure 4 – Choosing the Trusted Security Partner

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.

Conclusions

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.

Azure Monitor: the news about network monitoring in Azure

Monitor Azure is a cloud-based solution that can collect different types of telemetry data, analyze them and take certain actions. Among the various features provides the ability to monitor the health of the networking, connectivity to applications and is able to provide detailed information on network performance. All this not only for cloud environments, but even in the presence of hybrid architectures. This article shows important changes that were recently announced by Microsoft to make the solution even more comprehensive.

Before focusing on the new features that have been introduced it is good to specify that Azure Monitor includes different specific solutions to monitor the Azure networking, including Network Performance Monitor (NPM), The suite includes the following features:

In addition to the tools included in the Network Performance Monitor (NPM) you can use Traffic Analytics, allowing you to have an overall visibility on network activities that are undertaken in the cloud environment. How this solution works is based on the principle that in Azure, to allow or deny network communication to Azure Virtual Networks-connected resources (vNet), it uses the Network Security Group (NSG), containing a list of access rules. The NSGs are applied to network interfaces connected to the virtual machines, or directly to the subnet (recommended). The platform uses NSG flow logs to maintain the visibility of inbound and outbound network traffic from the Network Security Group. Traffic Analytics is based on the analysis ofNSG flow logs and after an appropriate aggregation of data, inserting the necessary intelligence concerning security, topology and geographic map, can provide detailed information about the network traffic of your Azure cloud environment. The news that interests Traffic Analytics is that you can now process this data more frequently, at time intervals each time 10 minutes, against the 60 minutes previously possible.

Figure 1 – Traffic Analytics Processing Frequency

Azure Monitor for Networks

For greater visibility into network activities in the cloud Microsoft released Azure Monitor for Networks that introduces a useful visual view on the health of all network resources in your environment, enriched by their metrics. Everything is available without the need to make any specific configuration.

Figure 2 – Overview of Azure Monitor for Networks

In the top pane, you can set up search parameters to quickly identify the resources of interest, while on the right there is a panel showing any critical alerts.

Selecting individual components gives you more detail.

Figure 3 – VPN connection status details

In particular, currently only for Application Gateways, a very useful view of the Dependency, which helps you pinpoint component configuration and track error conditions more quickly. This representation shows the relationships between the front-end IPs, the listeners, the rules and the backend pool of Application Gateway. Colors make it easy to identify problematic health states on resources.

The view also lists key metrics for Application Gateways.

Figure 4 – List of Application Gateways

Figure 5 - Dependency view of a specific Application Gateway

The graph also allows easy access to the various component configurations. In order to identify connectivity issues and start troubleshooting operations, you have the option, right-clicking on the single virtual machine, of access directly to VM Insight and to Connection troubleshoot.

Figure 6 – Access resources to do machine troubleshooting

Conclusions

The new solution Network Insights present in Azure Monitor allows you to have a comprehensive view of network resources in a simple and intuitive way. The solution is particularly useful in the presence of complex environments and the console of Dependency view is a help also to document the implementations of the Application Gateway. It is currently a feature in preview and as such will surely be enriched in the short term with further news, allowing you to have a more complete and intuitive monitor of the network architecture in Azure.

Azure Networking: the new way to privately access services in Azure

The need to be able to access data and services in Azure in a totally private and secure way, in particular from on-premises environment, it's definitely very much felt and more and more widespread. For this reason, Microsoft has announced the availability of Azure Private Link, this simplifies the network architecture by establishing a private connection to services in Azure, without the need for exposure to Internet. This article describes the characteristics of this type of connectivity and how you can enable it.

Thanks to Azure Private Link you can bring Azure services to a virtual network and map them with a private endpoint. In this way, all traffic is routed through the private endpoint, keeping it on the Microsoft global network. The data does not pass ever on the Internet, this reduces exposure to threats and helps to meet the compliance standards.

Figure 1 - Overview of Azure Private Link

The concept that underlies Azure Private Link is already partly known under the Azure networking and invokes the Virtual Network Service Endpoints. Before the introduction of Azure Private Link the only available way to increase the level of security when accessing Azure services, such as Azure Storage and SQL Azure Database, was given by the VNet Service Endpoints. The difference is substantial, as using VNet Service Endpoints traffic remains in the Microsoft backbone network, allowing access to PaaS resources only from its own VNet, but the PaaS endpoint is still accessed via the public IP of the service. Consequently, the operating principle of the VNet Service Endpoints does not extend to on-premises world even in the presence of connectivity with Azure (VPN or ExpressRoute). In fact,, to provide access from on-premises systems you must continue to use the firewall rules to limit the connectivity only to your public IP.

Thanks to Azure Private Link you can instead access the PaaS resources via a private IP address of your VNet, which it is potentially also accessible from:

On-premises systems via Azure ExpressRoute private peering andor Azure VPN gateways.
Systems on VNet in peering.

All traffic resides within the Microsoft network and you do not need to configure access through public IPs of the PaaS Service.

Figure 2 – Access from on-premises and peered networks

Azure Private Link greatly simplifies the way you can access Azure services (Azure PaaS, Azure, Microsoft partners and private services) as they support cross configurations for Azure Active Directory (Azure AD) tenants.

Figure 3 – Private Link cross Azure Active Directory (Azure AD) tenants

Activating Azure Private link it's simple and requires a limited number of Azure networking-side configurations. Connectivity occurs based on a call approval flow and when a PaaS resource is mapped to a private endpoint, route table and Network Security Groups configuration is not required (NSG).

Since Private link center you can create new services and manage the configuration or configure existing services to take advantage of Private link.

Figure 4 - Starting Configuration from Private link center

Figure 5 - Creating an Azure Storage Account to make it privately accessible

Figure 6 - Classical parameters for the creation of an storage account

Figure 7 - Private endpoint configuration

Figure 8 - Private endpoint connection present in the created storage accounts

At this point the storage account will be available in totally private way. To test the connectivity access a virtual machine was created and verified through "Connection troubleshoot":

Figure 9 – Test performed by "Connection troubleshoot" that demonstrates private connectivity

To connect with each other more Azure Virtual Network are typically used VNet peering, that require there are no overlaps in VNets address spaces. If this condition occurs it is possible to adopt the Azure Private Link as an alternative way to privately connect applications that reside in different VNets with an overlapping address space.

Figure 10 – Azure Private Link in the presence of overlapping address space

Azure Private Link features allow you to have specific access only to explicitly mapped resources. In the event of a security incident within your VNet, this mechanism eliminates the threat of extracting data from other resources using the same endpoint.

Figure 11 - Targeted access only to explicitly mapped resources

The Azure Private Link also opens new scenarios for exposure of service in Azure provided by the service provider. In order to allow access to the services provided to its customers, one of these methods was typically carried out in one of these ways.:

They made themselves directly accessible via Public IPs.
To make them private, VNet peerings were created, but with scalability issues and potential IP conflicts.

Figure 12 - How Azure Private Links changing scenarios "Consumer Service" - "Service Provider".

The new possibilities that are offered in these scenarios, requiring a totally private access to the service provided, is the following:

Service Provider: set up an Azure Standard Load Balancer, creates a Azure Private Link and allows access to the Service Consumer coming from a different VNet, subscription, or Azure Active Directory tenant (AD).
Service consumer: create a Private Endpoint in the specific VNet and request access to the service.

Figure 13 – Azure Private Link workflow in “Service Consumer”-“Service Provider” scenario

For more details please visit the Microsoft's official documentation.

Conclusions

This new method allows you to privately consume Azure-delivered solutions within your network infrastructure. This is an important change that you should definitely consider when designing network architectures in Azure, particularly for hybrid scenarios. At the moment the service is in preview, therefore not yet usable for production environments and available for a limited set of Azure services. In the coming months, however, Microsoft has announced that it will also make this feature available to other Azure services and partners, allowing you to have a private connectivity experience, key to having more adoption and dissemination of these services.

Azure Networking: what's new in Azure Firewall

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.

Figure 1 – Assign multiple public IPs to Azure Firewall from the Azure portal

Availability Zones

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.

Figure 2 - Configuration of Availability Zones in the process of creating Azure Firewall

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:

[cc lang=”powershell”]

$AzureFirewallId = (Get-AzFirewall -Name “AzureFirewallName” -ResourceGroupName “Network-RG”).id

$BackupFileName = “.AzureFirewallBackup.json”

Export-AzResourceGroup -ResourceGroupName “Network-RG” -Resource $AzureFirewallId -SkipAllParameterization -Path $BackupFileName

[/cc]

With the availability of the JSON file you need to edit it to contemplate the Availability Zones:

[cc lang=”powershell”]

{

“apiVersion”: “2019-04-01”,

“type”: “Microsoft.Network/azureFirewalls”,

“name”: “[variables(‘FirewallName’)]”,

“location”: “[variables(‘RegionName’)]”,

“zones”: [

“1”,

“2”,

“3”

“properties”: {

“ipConfigurations”: [

{

[/cc]

After the change is complete, you can deploy the new Azure Firewall, using suitably modified JSON file, using the following command:

[cc lang=”powershell”]

New-AzResourceGroupDeployment -name “RestoreFirewallAvZones” -ResourceGroupName “Network-RG” -TemplateFile “.AzureFirewallBackup.json”

[/cc]

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.

Figure 3 - Creating Application Rule with SQL FQDN

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.

Conclusions

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.