Secure Azure Networks

One of the main aspects of cloud computing is the shared responsibility model, where the cloud solution provider (CSP) and the customer share different levels of responsibilities depending on the cloud service category. When it comes to platform security, Infrastructure as a Service (IaaS), customers will have a long list of responsibilities. However, in a Platform as a Service (PaaS) scenario, there are still some platform security responsibilities; they are not as extensive as when using IaaS workloads.

Azure has native platform security capabilities and services that should be leveraged to provide the necessary level of security for your IaaS and PaaS workloads while maintaining a secure management layer.

Skills covered in this chapter:

• Skill 2.1: Virtual Network Security

• Skill 2.2: Security for private access to Azure resources

• Skill 2.3: Security for public access to Azure resources

Skill 2.1: Virtual Network Security

To implement an Azure network infrastructure, you need to understand the different connectivity options available in Azure. These options will enable you to implement a variety of scenarios with different requirements. This section of the chapter covers the skills necessary to implement advanced network security.

Plan and implement Network Security Groups (NSGs) and Application Security Groups (ASG)

Network security groups (NSG) in Azure allow you to filter network traffic by creating rules that allow or deny inbound network traffic to or outbound network traffic from different types of resources. You can think of an NSG as a Virtual LAN or VLAN in a physical network infrastructure. For example, you could configure an NSG to block inbound traffic from the Internet to a specific subnet that only allows traffic from a network virtual appliance (NVA).

Network security groups can be enabled on the subnet or to the network interface in the VM, as shown in Figure 2-1.

In Figure 2-1, two types of NSGs are shown. In the first case, the NSG is assigned to Subnet A. This can be a good way to secure the entire subnet with a single set of NSG rules. However, there will be scenarios where you might need to control the NSG on the network interface level, which is the case of the second scenario (Subnet B), where VM 5 and VM 6 have an NSG assigned to the network interface.

When inbound traffic comes through the VNet, Azure processes the NSG rules associated with the subnet first—if there are any—and then processes the NSG rules associated with the network interface. When the traffic is leaving the VNet (outbound traffic), Azure processes the NSG rules associated with the network interface first, followed by the NSG rules associated with the subnet.

When you create an NSG, you need to configure a set of rules to harden the traffic. These rules use the following parameters:

• Name The name of the rule.

• Priority The order in which the rule will be processed. Lower numbers have high priority, meaning a rule priority 100 will be evaluated before rule priority 300. Once the traffic matches the rule, it will stop to evaluate other rules. When configuring the priority, you can assign a number between 100 and 4096.

• Source Define the Source IP, CIDR Block, Service Tag, or Application Security Group.

• Destination Define the Destination IP, CIDR Block, Service Tag, or Application Security Group.

• Protocol Define the TCP/IP protocol that will be used, which can be set to TCP, UDP, ICMP, or Any.

• Port Range Define the port range or a single port.

• Action This determines the action to be taken once this rule is processed. This can be set to Allow or Deny.

Before creating a new NSG and adding new rules, it is important to know that Azure automatically creates default rules on NSG deployments. Following is a list of the inbound rules that are created:

• AllowVNetInBound

  • Priority 65000

  • Source VirtualNetwork

  • Source Ports 0-65535

  • Destination VirtualNetwork

  • Destination Ports 0-65535

  • Protocol Any

  • Action Allow

• AllowAzureLoadBalancerInBound

  • Priority 65001

  • Source AzureLoadBalancer

  • Source Ports 0-65535

  • Destination 0.0.0.0/0

  • Destination Ports 0-65535

  • Protocol Any

  • Action Allow

• DenyAllInbound

  • Priority 65500

  • Source 0.0.0.0/0

  • Source Ports 0-65535

  • Destination 0.0.0.0/0

  • Destination Ports 0-65535

  • Protocol Any

  • Action Deny

Below is a list of outbound rules that are created:

• AllowVnetOutBound

  • Priority 65000

  • Source VirtualNetwork

  • Source Ports 0-65535

  • Destination VirtualNetwork

  • Destination Ports 0-65535

  • Protocol Any

  • Action Allow

• AllowInternetOutBound

  • Priority 65001

  • Source 0.0.0.0/0

  • Source Ports 0-65535

  • Destination Internet

  • Destination Ports 0-65535

  • Protocol Any

  • Action Allow

• DenyAllOutBound

  • Priority 65500

  • Source 0.0.0.0/0

  • Source Ports 0-65535

  • Destination 0.0.0.0/0

  • Destination Ports 0-65535

  • Protocol Any

  • Access Deny

Follow the steps below to create and configure an NSG, which, in this example, will be associated with a subnet:

1. Navigate to the Azure portal by opening https://portal.azure.com.

2. In the search bar, type network security, and under Services, click Network Security Groups; the Network Security Groups page appears.

3. Click the Add button; the Create Network Security Group page appears, as shown in Figure 2-2.

1. In the Subscription field, select the subscription where this NSG will reside.

2. In the Resource Group field, select the resource group in which this NSG will reside.

3. In the Name field, type the name for this NSG.

4. In the Region field, select the Azure region in which this NSG will reside.

5. Click the Review + Create button, review the options, and click the Create button.

6. Once the deployment is complete, click the Go To Resource button. The NSG page appears.

You have successfully created your NSG at this point, and you can see that the default rules are already part of it. The next step is to create custom rules, which can be inbound or outbound. (This example uses inbound rules.) The same operation could be done using the New-AzNetworkSecurityGroup PowerShell cmdlet, as shown in the following example:

New-AzNetworkSecurityGroup -Name "AZ500NSG" -ResourceGroupName "AZ500RG"  -Location
"westus"

Follow these steps to create an inbound rule that allows FTP traffic from any source to a specific server using the Azure portal:

1. On the NSG page, click Inbound Security Rules under Settings in the left navigation pane.

2. Click the Add button; the Add Inbound Security Rule blade appears, as shown in Figure 2-3.

1. On this blade, you start by specifying the source, which can be an IP address, a service tag, or an Application Security Group (ASG). If you leave it set to the default option (Any), you are allowing any source. For this example, leave this set to Any.

2. In the Source Port Ranges field, you can harden the source port. You can specify a single port or an interval. For example, you can allow traffic from ports 50 to 100. Also, you can use a comma to add another condition to the range, such as 50-100, 135, which specifies ports 50 through 100 and 135. Leave the default selection (*), which allows any source port.

3. In the Destination field, the options are nearly the same as in the Source field. The only difference is that you can select the VNet as the destination. For this example, change this option to IP Addresses and enter the internal IP address of the VM that you created at the beginning of this chapter.

4. In the Destination Port Ranges field, specify the destination port that will be allowed. The default port is 8080; for this example, change it to 21.

5. In the Protocol field, you can select which protocol you will allow; in this case, change it to TCP.

6. Leave the Action field set to Allow, which is the default selection.

7. You can also change the Priority of this rule. Remember that the lowest priority is evaluated first. For this example, change it to 101.

8. Change the Name field to AZ500NSGRule_FTP and click the Add button.

The NSG will be created, and a new rule will be added to the inbound rules. At this point, your inbound rules should look like the rules shown in Figure 2-4.

While these are the steps to create the inbound rule, this NSG has no use if it is not associated with a subnet or a virtual network interface. For this example, you will associate this NSG to a subnet. The intent is to block all traffic to this subnet and only allow FTP traffic to this specific server. Use the following steps to create this association:

1. At the left hand side of the NSG Inbound Security Rules page, in the navigation pane of the Network security group, under Settings, click Subnets.

2. Click the Associate button, and in the Virtual Network dropdown, select the VNet where the subnet resides.

3. After this selection, you will see that the Subnet dropdown appears; select the subnet and click the OK button.

You could also use PowerShell to create an NSG and then associate the NSG to a subnet. To create an NSG using PowerShell, use the New-AzNetworkSecurityRuleConfig cmdlet, as shown in the following example:

$MyRule1 = New-AzNetworkSecurityRuleConfig -Name ftp-rule -Description "Allow FTP"
-Access Allow -Protocol Tcp -Direction Inbound -Priority 100 -SourceAddressPrefix *
-SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 21

Application security group

If you need to define granular network security policies based on workloads centralized on application patterns instead of explicit IP addresses, use the application security group (ASG). An ASG allows you to group VMs and secure applications by filtering traffic from trusted network segments, adding an extra micro-segmentation level.

You can deploy multiple applications within the same subnet and isolate traffic based on ASGs. Another advantage is that you can reduce the number of NSGs in your subscription. For example, in some scenarios, you can use a single NSG for multiple subnets of your virtual network and perform the micro-segmentation on the application level by using ASG. Figure 2-5 shows how ASG can be used with an NSG.

In Figure 2-5, two ASGs have been created to define the application pattern for a web application and another ASG to define the application pattern for a SQL database. Two VMs are part of each group, and the ASG is used in the routing table of the NSG located in subnet A. In the NSG routing table, you can specify one ASG as the source and destination, but you cannot specify multiple ASGs in the source or destination.

When you deploy VMs, you can make them members of the appropriate ASGs. If your VM has multiple workloads (Web App and SQL, for example), you can assign multiple ASGs to each application. This will allow you to have different types of access to the same VM according to the workload. This approach also helps to implement a Zero Trust model by limiting access to the application flows that are explicitly permitted. Follow these steps to create an ASG:

1. Navigate to the Azure portal at https://portal.azure.com.

2. In the search bar, type application security, and under Services, click Application Security Groups.

3. In the Application Security Groups dashboard, click the Create button, which makes the Create An Application Security Group page appear, as shown in Figure 2-6.

   

   Figure 2-6 Create an application security group

4. In the Subscription dropdown, select the appropriate subscription for this ASG.

5. In the Resource Group dropdown, select the resource group in which this ASG will reside.

6. In the Name field, type a name—ASGAZ500.

7. Select the appropriate region for this ASG in the Region dropdown and click the Review + Create button.

8. On the Review + Create button page, click the Create button.

Now that the ASG is created, you need to associate it with the network interface of the VM that has the workload you want to control. Follow these steps to perform this association:

1. Navigate to the Azure portal at https://portal.azure.com.

2. In the search bar, type virtual, and under Services, click Virtual Machines.

3. Click the VM that you want to perform this association.

4. Click the Network Settings option on the VM’s page in the Networking section.

5. On the right pane, under the Essentials section, click Configure beside the Application Security Group option, and the page shown in Figure 2-7 appears.

   

   Figure 2-7 Connecting an application security group to a network interface

6. Click the Add Application Security Groups button, and the Add Application Security Groups blade appears, as shown in Figure 2-8.

   

   FIGURE 2-8 Selecting the application security group

7. Select the ASG you created previously, and click the Add button.

You can also use the New-AzApplicationSecurityGroup cmdlet to create a new ASG, as shown in the following example:

New-AzApplicationSecurityGroup -ResourceGroupName "MyRG" -Name "MyASG" -Location
"West US"

When you create your new NSG rule for inbound or outbound traffic, you can select the ASG as the source or destination.

Plan and implement user-defined routes (UDRs)

To better understand the different components of an Azure network, let’s review Contoso’s architecture diagram shown in Figure 2-9.

Figure 2-9 shows Azure infrastructure (on top), with three virtual networks. Contoso needs to segment its Azure network into different virtual networks (VNets) to provide better isolation and security. Having VNets in its Azure infrastructure allows Contoso to connect Azure Virtual Machines (VMs) to securely communicate with each other, the Internet, and Contoso’s on-premises networks.

A VNet is much like a traditional physical, on-premises network where you operate in your own data center. However, A VNet offers some additional benefits, including scalability, availability, and isolation. When you create a VNet, you must specify a custom private IP address that will be used by the resources that belong to this VNet. For example, if you deploy a VM in a VNet with an address space of 10.0.0.0/24, the VM will be assigned a private IP, such as 10.0.0.10/24.

Notice in Figure 2-9 that there are subnets in each VNet in Contoso’s network. Contoso needs to segment the virtual network into one or more subnetworks and allocate a portion of the virtual network’s address space to each subnet. With this setup, Contoso can deploy Azure resources in a specific subnet, just like it used to do in its on-premises network. From an organizational and structure perspective, subnets have allowed Contoso to segment its VNet address space into smaller segments appropriate for its internal network. By using subnets, Contoso also was able to improve address allocation efficiency.

Another important trio of components is shown in Figure 2-9: subnets A1, B1, and C1. Each of these subnets has a network security group (NSG) bound to it, which provides an extra layer of security based on rules that allow or deny inbound or outbound network traffic.

NSG security rules are evaluated by their priority, and each is identified with a number between 100 and 4096, where the lowest numbers are processed first. The security rules use 5-tuple information (source address, source port, destination address, destination port, and protocol) to allow or deny the traffic. When the traffic is evaluated, a flow record is created for existing connections, and the communication is allowed or denied based on the connection state of the flow record. You can compare this type of configuration to the old VLAN segmentation that was often implemented with on-premises networks.

Contoso is headquartered in Dallas and has a branch office in Sydney. Contoso needs to provide secure and seamless RDP/SSH connectivity to its virtual machines directly from the Azure portal over TLS. Contoso doesn’t want to use jumpbox VMs and instead wants to allow remote access to back-end subnets through the browser. For this reason, Contoso implemented Azure Bastion, as shown in the VNet C, subnet C1 in Figure 2-9.

Azure Bastion is a platform-managed PaaS service that can be provisioned in a VNet.

Contoso’s connectivity with Sydney’s branch office uses a VPN gateway in Azure. A virtual network gateway in Azure comprises two or more VMs deployed to a specific subnet called a gateway subnet. The VMs that are part of the virtual network gateway contain routing tables and run specific gateway services. These VMs are automatically created when you create the virtual network gateway, and you don’t have direct access to those VMs to make custom configurations to the operating system.

When planning your VNets, consider that each VNet may only have one virtual network gateway of each type, and the gateway type may only be VPN or ExpressRoute. Use a VPN when sending encrypted traffic across the public Internet to your on-premises resources.

For example, let’s say that Contoso needs a faster, more reliable, secure, and consistent latency to connect its Azure network to its headquarters in Dallas. Contoso decides to use ExpressRoute, as shown in Figure 2-9. ExpressRoute allows Contoso to extend its on-premises networks into the Microsoft cloud (Azure or Office 365) over a private connection because ExpressRoute does not go over the public Internet.

In Figure 2-9, notice that the ExpressRoute circuit consists of two connections: Microsoft Enterprise Edge Routers (MSEEs) at an ExpressRoute Location from the connectivity provider or your network edge. While you might choose not to deploy redundant devices or Ethernet circuits at your end, the connectivity providers use redundant devices to ensure that your connections are handed off to Microsoft in a redundant manner. This Layer 3 connectivity redundancy is a requirement for Microsoft SLA to be valid.

Network segmentation is important in many scenarios, and you need to understand the design requirements to suggest the implementation options. Let’s say you want to ensure that Internet hosts cannot communicate with hosts on a back-end subnet but can communicate with hosts on the front-end subnet. In this case, you should create two VNets: one for your front-end resources and another for your back-end resources.

In a physical network environment, you usually need to start configuring routes as soon as you expand your network to have multiple subnets. Azure automatically creates the routing table for each subnet within an Azure VNet. The default routes created by Azure and assigned to each subnet in a virtual network can’t be removed. The default route contains an address prefix and the next hop (where the package should go). When traffic leaves the subnet, it goes to an IP address within the address prefix of a route; the route that contains the prefix is the route used by Azure.

When you create a VNet, Azure creates a route with an address prefix corresponding to each address range that you defined within the address space of your VNet. If the VNet has multiple address ranges defined, Azure creates an individual route for each address range. You don’t need to worry about creating routes between subnets within the same VNet because Azure automatically routes traffic between subnets using the routes created for each address range. Also, unlike your physical network topology and routing mechanism, you don’t need to define gateways for Azure to route traffic between subnets. In an Azure routing table, this route appears as:

• Source Default

• Address prefix Unique to the virtual network

• Next hop type Virtual network

If the destination of the traffic is the Internet, Azure leverages the system-default route 0.0.0.0/0 address prefix, which routes traffic for any address not specified by an address range within a virtual network to the Internet. The only exception to this rule is if the destination address is for one of Azure’s services. In this case, instead of routing the traffic to the Internet, Azure routes the traffic directly to the service over Azure’s backbone network. The other scenarios in which Azure will add routes are as follows:

• When you create a VNet peering In this case, a route is added for each address range within the address space of each virtual network peering that you created.

• When you add a Virtual Network Gateway In this case, one or more routes with a virtual network gateway listed as the next hop type are added.

• When a VirtualNetworkServiceEndpoint is added When you enable a service endpoint to publish an Azure service to the Internet, the public IP addresses of the services are added to the route table by Azure.

You might also see None in the routing table’s Next Hop Type column. Traffic routed to this hop is automatically dropped. Azure automatically creates default routes for 10.0.0.0/8, 192.168.0.0/16 (RFC 1918), and 100.64.0.0/10 (RFC 6598).

At this point, you might ask: “If all these routes are created automatically, in which scenario should I create a custom route?” You should do this only when you need to alter the default routing behavior. For example, if you add an Azure Firewall or any other virtual appliance, you can change the default route (0.0.0.0/0) to point to this virtual appliance. This will enable the appliance to inspect the traffic and determine whether to forward or drop the traffic. Another example is when you want to ensure that traffic from hosts doesn’t go to the Internet; you can control the routing rules to accomplish that.

To create a custom route that is effective for your needs, you need to create a custom routing table, create a custom route, and associate the routing table to a subnet, as shown in the following PowerShell sequence.

1. Create the routing table using New-AzRouteTable cmdlet, as shown here:

   $routeTableAZ500 = New-AzRouteTable `
     -Name 'AZ500RouteTable' `
     -ResourceGroupName ContosoCST `
     -location EastUS

1. Create the custom route using multiple cmdlets. First, you retrieve the route table information using Get-AzRouteTable, and then you create the route using Add-AzRouteConfig. Lastly, you use the Set-AzRouteTable to write the routing configuration to the route table:

   Get-AzRouteTable `
     -ResourceGroupName "ContosoCST" `
     -Name "AZ500RouteTable" `
     | Add-AzRouteConfig `
     -Name "ToAZ500Subnet" `
     -AddressPrefix 10.0.1.0/24 `
     -NextHopType "MyVirtualAppliance" `
     -NextHopIpAddress 10.0.2.4 `
    | Set-AzRouteTable

1. Now that you have the routing table and the custom route, you can associate the route table with the subnet. Notice here that you first write the subnet configuration to the VNet using the Set-AzVirtualNetwork cmd. After that, you use Set-AzVirtualNetworkSubnetConfig to associate the route table to the subnet:

   $virtualNetwork | Set-AzVirtualNetwork
   Set-AzVirtualNetworkSubnetConfig `
     -VirtualNetwork $virtualNetwork `
     -Name 'CustomAZ500Subnet' `
     -AddressPrefix 10.0.0.0/24 `
     -RouteTable $routeTableAZ500 | `
   Set-AzVirtualNetwork

When you have multiple VNets in your Azure infrastructure, you can connect those VNets using VNet peering. You can use VNet peering to connect VNets within the same Azure region or across Azure regions; doing so is called global VNet peering.

When the VNets are in the same region, the network latency between VMs communicating through the VNet peering is the same as within a single virtual network. It’s also important to mention that the traffic between VMs in peered virtual networks is not through a gateway or public Internet; instead, traffic is routed directly through the Microsoft backbone infrastructure. To create a VNet peering using the Azure portal, follow these steps:

1. Navigate to the Azure portal at https://portal.azure.com.

2. In the search bar, type virtual networks, and under Services, click Virtual Networks.

3. Click the VNet that you want to peer, and on the left navigation pane, under Settings, click Peerings (see Figure 2-10).

1. Click the Add button, and the Add Peering page appears, as shown in Figure 2-11.

1. In the Peering Link Name field, type a name for this peering.

2. At the bottom of the Add Peering page, you can choose these options:

   • Allow [VNet Name] To Access The Peered Virtual Network This option is selected by default and allows traffic from AZ500VNet (in this scenario, to the peered virtual network). This setting enables communication between the hub and spoke in hub-and-spoke network topology and allows a VM in AZ500VNet to communicate with a VM in the peered virtual network.

   • Allow [VNet Name] To Receive Forwarded Traffic From The Peered Virtual Network By enabling this option, you are allowing the VNet (in this case, AZ500VNet) to receive traffic from virtual networks peered to the peered virtual network. For example, if AZ500VNet-2 has an NVA that receives traffic from outside of AZ500VNet-2 that gets forwarded to AZ500VNet-1, you can select this setting to allow that traffic to reach AZ500VNet-1 from AZ500VNet-2. Notice that while enabling this option allows the forwarded traffic through the peering, it doesn’t create any user-defined routes (UDR) or network virtual appliances. User-defined routes and network virtual appliances are created separately.

   • Allow Gateway Or Route Server In [VNet Name] To Forward Traffic To The Peered Virtual Network By enabling this option, you allow the peered virtual network to receive traffic from the VNet (in this case, AZ500VNet) gateway or route server. You should only enable this option if the VNet (in this case, AZ500VNet) contains a gateway or route server.

   • Enable [VNet Name] To Use The Peered Virtual Networks’ Remote Gateway Or Route Server You can only enable this option if the peered virtual network has a remote gateway or route server and the peered virtual network enables the Allow Gateway In The Peered Virtual Network To Forward Traffic To [VNet Name] option. This option can be enabled in only one of the VNet peerings.

3. Under the Remote Virtual Network section, in the Peering Link Name field, type the name you want to appear for this peering connection on the other VNet.

4. Keep the Virtual Network Deployment Model with the default selection, Resource Manager.

5. If you know the Resource ID, select the I Know My Resource ID option.

6. In the Subscription field, select the subscription that has the VNet to which you want to connect.

7. In the Virtual Network field, click the dropdown and select the VNet you want to peer.

8. The same options are available but for the virtual network.

9. Click Add to finish the configuration.

To configure a VNet peering using PowerShell, you just need to use the Add-AzVirtualNetworkPeering cmdlet, as shown here:

Add-AzVirtualNetworkPeering -Name 'NameOfTheVNetPeering' -VirtualNetwork SourceVNet
-RemoteVirtualNetworkId RemoteVNet

A peered VNet can have its own gateway, and the VNet can use its gateway to connect to an on-premises network. One common use of VNet peering is when you are building a hub-spoke network. In this type of topology, the hub is a VNet that acts as a central hub for connectivity to your on-premises network. The spokes are VNets peering with the hub, allowing them to be isolated, increasing their security boundaries. An example of this topology is shown in Figure 2-12.

A hybrid network uses the hub-spoke architecture model to route traffic between Azure VNets and on-premises networks. When there is a site-to-site connection between the Azure VNet and the on-premises data center, you must define a gateway subnet in the Azure VNet. All the traffic from the on-premises data center would then flow via the gateway subnet.

When you have a complex network infrastructure, as shown in Figure 2-12, creating custom or user-defined(static) routes in Azure to override Azure’s default system routes or add more routes to a subnet’s route table is common.

In Azure, you create a route table, subsequently linking it to one or multiple virtual network subnets. Each subnet may be linked to no more than one route table. Upon linking a route table to a subnet, the routes within the table combine with the subnet’s inherent routes. Should conflicting route allocations arise, user-defined routes take precedence over default routes. When creating a user-defined route (UDR), you can use the following elements as the next hop:

• Virtual appliance

• Virtual network gateway

• None. (In this case, you will use this option when you want to drop traffic to an address prefix rather than forwarding the traffic to a destination.)

• Virtual network

• Internet

Plan and implement virtual vetwork peering or VPN gateway

With organizations migrating to the cloud, virtual private networks (VPNs) are constantly used to establish a secure communication link between on-premises and cloud network infrastructure. Many organizations will also keep part of their resources on-premises while using cloud computing to host different services, creating a hybrid environment. While this is one common scenario, there are many other scenarios where a VPN can be used. You can use Azure VPN to connect two different Azure regions or subscriptions.

Azure natively offers a service called VPN gateway, a specific type of virtual network gateway used to send encrypted traffic between an Azure virtual network and on-premises resources. You can also use a VPN gateway to send encrypted traffic between Azure virtual networks. When planning your VPN gateway implementation, be aware that each virtual network can have only one VPN gateway, and you can create multiple connections to the same VPN gateway. When deploying a hybrid network that needs to create a cross-premises connection, you can select from different types of VPN connectivity. The available options are:

• Point-to-Site (P2S) VPN This type of VPN is used when connecting to your Azure VNet remotely. For example, you would use P2S when working remotely (hotel, home, conference, and the like) and need to access resources in your VNet. This VPN uses SSTP (Secure Socket Tunneling Protocol) or IKE v2 and does not require a VPN device.

• Site-to-Site (S2S) VPN This type of VPN is used when connecting on-premises resources to Azure. The encrypted connection tunnel uses IPsec/IKE (IKEv1 or IKEv2).

• VNet-to-VNet As the name states, this VPN is used in scenarios where you need to encrypt connectivity between VNets. This type of connection uses IPsec (IKE v1 and IKE v2).

• Multi-Site VPN This type of VPN is used when expanding your site-to-site configuration to allow multiple on-premises sites to access a virtual network.

ExpressRoute is another option that allows connectivity from your on-premises resources to Azure. This option uses a private connection to Azure from your WAN instead of a VPN connection over the Internet.

VPN authentication

The Azure VPN connection is authenticated when the tunnel is created. Azure generates a pre-shared key (PSK), which is used for authentication. This pre-shared key is an ASCII string character no longer than 128 characters. This authentication happens for policy-based (static routing) or routing-based VPN (dynamic routing). You can view and update the pre-shared key for a connection with these PowerShell cmdlets:

• Get-AzVirtualNetworkGatewayConnectionSharedKey This command is used to show the pre-shared key.

• Set-AzVirtualNetworkGatewayConnectionSharedKey This command changes the pre-shared key to another value.

For point-to-site (P2S) VPN scenarios, you can use native Azure certificate authentication, RADIUS server, or Azure AD authentication. For native Azure certificate authentication, a client certificate is presented on the device, which is used to authenticate the connecting users. The certificate can be one that was issued by an enterprise certificate authority (CA), or it can be a self-signed root certificate. For native Azure AD, you can use the native Azure AD credentials. Remember that native Azure AD is only supported for the OpenVPN protocol and Windows 10 (Windows 10 requires using the Azure VPN Client).

If your scenario requires the enforcement of a second authentication factor before access to the resource is granted, you can use Azure Multi-Factor Authentication (MFA) with conditional access. Even if you don’t want to implement MFA across your entire company, you can scope the MFA only for VPN users using conditional access capability.

Another option for P2S is the authentication using RADIUS (which also supports IKEv2 and SSTP VPN). Remember that RADIUS is only supported for VpnGw1, VpnGw2, and VpnGw3 SKUs. For more information about the latest VPN SKUs, visit http://aka.ms/az500vpnsku. Figure 2-13 shows an example of the options that appear when configuring a P2S VPN, and you need to select the authentication type.

The options under the Authentication Type section will vary according to your selected authentication type. In Figure 2-13, Azure Certificate is chosen, and the page shows options to enter the Name and Public Certification Data for the Root Certificates and the Name and Thumbprint for the Revoked Certificates. If you select RADIUS authentication, you must specify the Server IP Address and the Server Secret. Lastly, if you select the Azure Active Directory option, you will need to specify the Tenant’s URL; the Audience (which identifies the recipient resource the token is intended for); and the Issuer (which identifies the Security Token Service (STS) that issued the token). Lastly, choose the Azure AD tenant.

Your particular scenario will dictate which option to use. For example, Contoso’s IT department needs to implement a VPN solution that can integrate with a certificate authentication infrastructure that it already has through RADIUS. In this case, you should use RADIUS certificate authentication. When using the RADIUS certificate authentication, the authentication request is forwarded to a RADIUS server, which handles the certificate validation. If the scenario requires the Azure VPN gateway to perform the certificate authentication, the right option would be to use the Azure native certificate authentication.

Plan and implement Virtual WAN, including secured virtual hub

When organizations need to expand their reach and ensure that their branch offices are interconnected, they can leverage Azure Virtual WAN networking services. This networking service provides different networking capabilities, including security and routing functionalities. The diagram shown in Figure 2-14 shows some key scenarios enabled by Virtual WAN:

The Virtual WAN architecture is a hub-and-spoke architecture that enables branch office connectivity (VPN/SD-WAN devices), end user connectivity (Azure VPN/OpenVPN/IKEv2 clients), headquarters connectivity with ExpressRoute circuits, and virtual networks. In this architecture, Azure regions work as hubs that you can select to connect to. These hubs are connected in full mesh in a standard Virtual WAN, which makes it easier for the user to leverage the Microsoft backbone for any-to-any (any spoke) connectivity. Spoke connectivity users can either manually set it up in Azure Virtual WAN or use the Virtual WAN Customer Premies Equipment (CPE) partner solution to set up connectivity to Azure.

When planning to adopt an Azure Virtual WAN, you need to take into consideration the following points:

• Some partners, such as Barracuda Networks, Cisco, VMWare, Versa Networks, and Aruba, offer Network Virtual Appliances (NVAs) that can be deployed directly into the Azure Virtual WAN hub. You are not required to use a partner solution. You can use any VPN-capable device that complies with Azure requirements for IKEv2/IKEv1 IPsec support.

• There is a limit of 1,000 connections per virtual hub.

• You can connect your on-premises VPN device to multiple hubs by connecting with the closest Microsoft network edge and then to the virtual hub.

• If your deployment scenario requires, you can deploy a Network Virtual Appliance (NVA) inside a virtual hub.

• Regarding a spoke VNet, consider that you can’t have a virtual network gateway if it’s connected to the virtual hub, and you can’t have a route server if it’s connected to the virtual WAN hub.

• Border Gateway Protocol (BGP) is supported when creating a VPN connectivity.

• You don’t need to use ExpressRoute from each site when implementing Virtual WAN.

• You can have multiple virtual WAN hubs in the same region.

• Although you can customize virtual hub routing preferences, by default, Virtual WAN chooses ExpressRoute over VPN for traffic egressing Azure.

• When creating a Virtual WAN through the Azure portal, hubs must be in the same resource group as the Virtual WAN. However, if you need to create hubs in different resource groups, you can only do it by using PowerShell.

Secure VPN connectivity, including point-to-site and site-to-site

To implement a point-to-site (P2S) VPN in Azure, you first need to decide what authentication method you will use based on the options that were presented earlier in this section. The authentication method will dictate how the P2S VPN will be configured. When configuring the P2S VPN, you will see the options available under Tunnel Type, as shown in Figure 2-15.

• Another important variable to select is the protocol that will be used. Use Table 2-1 to select the most-appropriate protocol based on the advantages and limitations:

TABLE 2-1 Advantages and limitations

Protocol	Advantages	Limitations
OpenVPN Protocol	This TLS VPN-based solution can traverse most firewalls on the market. Can be used to connect from a variety of operating systems, including Android, iOS (versions 11.0 and above), Windows, Linux, and Mac devices (OSX versions 10.13 and above).	Basic SKU is not supported. Not available for the classic deployment model.
Secure Socket Tunneling Protocol (SSTP)	Can traverse most firewalls because it uses TCP port 443.	Only supported on Windows devices. Supports up to 128 concurrent connections, regardless of the gateway SKU.
IKEv2	Standard-based IPsec VPN solution. Can be used to connect to Mac devices (OSX versions 10.11 and above).	Basic SKU is not supported. Not available for the classic deployment model. Uses nonstandard UDP ports, so you need to ensure that these ports are not blocked on the user’s firewall. The ports in use are UDP 500 and 4500.

Site-to-site

A site-to-site (S2S) VPN is used in most scenarios to allow communication from one location (on-premises) to another (Azure) over the Internet. To configure an S2S, you need the following prerequisites fulfilled before you start:

• An on-premises VPN device compatible with Azure VPN policy–based or route-based configuration. See the full list at https://aka.ms/az500s2sdevices.

• Externally facing public IPv4 address.

• An IP address range from your on-premises network that will allow Azure to route to your on-premises location.

Implement encryption over ExpressRoute

If your connectivity scenario requires higher reliability, faster speeds, consistent latencies, and higher security than typical connections over the Internet, you should use ExpressRoute, which provides layer 3 connectivity between your on-premises network and the Microsoft Cloud.

ExpressRoute supports two different encryption technologies to ensure the confidentiality and integrity of the data traversing from on-premises to Microsoft’s network. The options are

• Point-to-point encryption by MACsec

• End-to-end encryption by IPSec

MACsec encrypts the data at the media access control (MAC) level or at network layer 2. When you enable MACsec, all network control traffic is encrypted, including the border gateway protocol (BGP) and your (customer) data traffic. This means that you can’t encrypt only some of your ExpressRoute circuits.

If you need to encrypt the physical links between your network devices and Microsoft’s network devices when you connect to Microsoft via ExpressRoute Direct, MACsec is preferred. MACsec also allows you to bring your own MACsec key for encryption and store it in Azure Key Vault. If this is the design choice, remember that you will need to decide when to rotate the key.

Remember that when you update the MACsec key, the on-premises resources will temporarily lose connectivity to Microsoft over ExpressRoute. This happens because the MACsec configuration only supports pre-shared key mode, so you must update the key on both sides. In other words, if there is a mismatch, traffic flow won’t occur. Plan the correct maintenance window to reduce the impact on production environments.

The other option is to use end-to-end encryption with IPSec, which encrypts data at the Internet protocol (IP)–level or at the network layer 3. A common scenario is using IPSec to encrypt the end-to-end connection between on-premises resources and your Azure VNet. In a scenario where you need to encrypt layers 2 and 3, you can enable MACsec and IPSec.

Configure firewall settings on PaaS resources

You can also leverage the native firewall-related capabilities for different PaaS resources. Azure Storage and SQL Database are examples of Azure PaaS resources with this functionality.

When you leverage this built-in functionality to harden your resources, you add an extra layer of security to your workload and follow the defense-in-depth strategy, as shown in Figure 2-16.

Azure storage firewall

When you enable this feature in Azure Storage, you can better control the level of access to your storage accounts based on the type and subset of networks used. When network rules are configured, only applications requesting data over the specified set of networks can access a storage account.

You can create granular controls to limit access to your storage account to requests from specific IP addresses, IP ranges, or a list of subnets in an Azure VNet. The firewall rules created on your Azure Storage are enforced on all network protocols that can be used to access your storage account, including REST and SMB.

Because the default storage accounts configuration allows connections from clients on any other network (including the Internet), it is recommended that you configure this feature to limit access to selected networks. Follow these steps to configure Azure Storage firewall:

1. Navigate to the Azure portal at https://portal.azure.com.

2. In the search bar, type storage, and under Services, click Storage Accounts.

3. Click the storage account for which you want to modify the firewall settings.

4. On the storage account page, under the Security + Networking section in the left navigation pane, click the Networking option; the page shown in Figure 2-17 appears.

1. By default, the Firewalls And Virtual Networks tab appears. Under the Public Network Access section, you have the option to enable access from all networks (default selection), only from selected virtual networks and IP addresses (best option when you need to create custom access rules), and disable access completely (the most restrictive option).

2. Under the Network Routing section, you can configure the traffic route as it moves from its source to the Azure endpoint. If you choose Microsoft Network Routing, the traffic will enter the Microsoft Cloud closer to the requesting client. If you choose Internet Routing, your traffic will be redirected to enter the Microsoft cloud closer to the Azure Storage endpoint.

3. Under the Publish Route-Specific Endpoints section, you can also select Microsoft Network Routing or Internet Routing.

4. Once you finish configuring, click the Save button.

If you want to quickly deny network access to the storage account, you can use the Update-AzStorageAccountNetworkRuleSet cmdlet, as shown here:

Update-AzStorageAccountNetworkRuleSet -ResourceGroupName "MyRG" -Name "mystorage" -DefaultAction Deny

Monitor network security by using Network Watcher, including NSG flow logging

Azure Network Watcher offers a comprehensive set of utilities for overseeing, diagnosing, accessing metrics, and controlling log settings for Azure’s Infrastructure-as-a-Service (IaaS) resources. It empowers users to track and troubleshoot the network status of IaaS components such as virtual machines (VMs), virtual networks (VNets), application gateways, and load balancers.

However, it’s important to note that Network Watcher is not tailored for monitoring Platform-as-a-Service (PaaS) resources or conducting web analytics. Table 2-2 has a list of capabilities offered by Azure Network Watcher.

TABLE 2-2 Network Watcher capabilities

Capability	Category	Description
Connection monitor	Monitoring	Provides comprehensive, end-to-end connection monitoring through its unified platform. The Connection monitor functionality is compatible with both hybrid setups and Azure cloud deployments.
Topology	Monitoring	The Topology feature offers a graphical representation of the complete network infrastructure, facilitating comprehension of network configuration. It presents an interactive interface that allows users to explore resources and their interconnections within Azure, encompassing various subscriptions, resource groups, and geographic locations.
NSG diagnostics	Network diagnostic tool	Assist in comprehending the traffic permissions within your Azure virtual network by providing detailed insights for debugging purposes. This tool assists in verifying the accuracy of your network security group (NSG) rules configuration.
IP flow verify	Network diagnostic tool	Enables you to determine whether a packet is permitted or blocked to and from an Azure virtual machine according to the established security and administrative regulations. This feature aids in troubleshooting connectivity problems by examining network security group (NSG) rules and Azure Virtual Network Manager administrative rules. It is a swift and straightforward diagnostic tool for pinpointing connectivity concerns with other Azure resources, the Internet, and on-premises environments.
Effective security rules	Network diagnostic tool	Enables you to have insight into the combined inbound and outbound rules enforced on a network interface. It grants visibility into both security and administrative regulations applied to the interface. This feature is invaluable for troubleshooting connectivity problems and conducting audits to ensure the security and compliance of your Azure network resources.
Packet capture	Network diagnostic tool	Enables you to capture traffic to and from a virtual machine (VM) or a scale set. This capability assists in diagnosing network irregularities, whether reactively or proactively. Its applications include gathering network statistics, identifying network intrusions, debugging client-server communications, and various other tasks.
VPN troubleshoot	Network diagnostic tool	Enables you to diagnose issues with virtual network gateways and their connections. This functionality can be accessed via the Azure portal, Azure PowerShell, Azure CLI, or REST API.
Next hop	Network diagnostic tool	Enables you to see more details such as the Next hop type, IP address, and Route table ID corresponding to a designated destination IP address. This information helps discern whether traffic is properly routed to its intended destination or is being blocked.
Connection troubleshoot	Network diagnostic tool	Enables you to streamline the process of diagnosing and troubleshooting network connectivity issues, resulting in reduced downtime. The returned results offer valuable insights into the underlying cause of the connectivity problem, distinguishing between platform-related issues and user configuration errors.
Flow log	Traffic	Flow logs are the definitive record of all network activity within your cloud environment, offering indispensable insights regardless of your organizational scale. They facilitate tasks such as optimizing network flows, monitoring throughput, ensuring compliance adherence, detecting intrusions, and beyond.
Traffic analysis	Traffic	Provides comprehensive visibility into user and application interactions within your cloud networks. More precisely, traffic analytics examines Azure Network Watcher flow logs, furnishing valuable insights into the patterns and dynamics of traffic flow within your Azure cloud infrastructure.