Chapter 8: Network Connectivity and Security

In the previous chapter, we examined the different options when building computer services, from the different types of Virtual Machines (VMs) to web apps and containerization.

All solution components need to be able to communicate effectively and safely; therefore, in this chapter, we will discuss what options we have to control traffic flow using route tables and load balancing components, securing traffic with different firewalling options, and managing IP addressing and resolution.

With this in mind, we will cover the following topics:

• Understanding Azure networking options
• Understanding IP addressing and DNS in Azure
• Implementing network security
• Connectivity
• Load balancing and advanced traffic routing

Technical requirements

This chapter will use the Azure portal (https://portal.azure.com) and you need an Azure subscription for the examples.

Understanding Azure networking options

Services in Azure need to communicate, and this communication is performed over a virtual network, or VNET.

There are essentially two types of networking in Azure – private VNETs and the Azure backbone. The Azure backbone is a fully managed service. The underlying details are never exposed to you – although the ranges used by many services are available, grouped by region, for download in a JSON file. The Azure backbone is generally used when non-VNET-connected services communicate with each other; for example, when storage accounts replicate data or when Azure functions communicate with SQL and Cosmos DB, Azure handles all aspects of these communications. This can cause issues when you need more control, especially if you want to limit access to your services at the network level, that is, by implementing firewall rules.

Important Note

The address ranges of services in Azure change continually as the services grow within any...

Understanding IP addressing and DNS in Azure

When building services in Azure, you sometimes choose to use internal IP addresses and external IP addresses. Internal IP addresses can only communicate internally and use VNETs. Many services can also use public IP addresses, which allow you to communicate with the service from the internet.

Before we delve into public and internal IP addresses, we need to understand the basics of IP addressing in general, and especially the use of subnets and subnet masks.

Understanding subnets and subnet masks

When devices are connected to a TCP/IP-based network, they are provided with an IP address in the notation xxx.xxx.xxx.xxx. Generally, all devices that are on the same local network can communicate with each other without any additional settings.

When devices on different networks need to communicate, they must do so via a router or gateway. Devices use a subnet mask to differentiate between addresses on the local network and those on a remote...

Implementing network security

Ensuring secure traffic flow to and between services is a core requirement for many solutions. An example is an external communication to a VM running a website – you may only want to allow traffic to the server in a particular port such as HTTPS over port 443. All other traffic, such as SMTP, FTP, or file share protocols, need to be blocked.

It isn't just inbound traffic that needs to be controlled; blocking outbound traffic can be just as important. For many organizations today, ensuring you are protected from insider threats is just as crucial, if not more so, than external threats. For this reason, we may want to block all but specific outbound access so that if a service is infected by malware, it cannot send traffic out – known as data exfiltration.

Important Note

Data exfiltration is a growing technique for stealing data. Either by manually logging on to a server or through malware infection, data is copied from an internal...

Connectivity

A simple, standalone solution may only require a single VNET, and especially if your service is an externally facing application for clients, you may not need to create anything more complicated.

However, for enterprise applications that contain many different services, or for hybrid scenarios where you need to connect securely to Azure from an on-premises network, you must consider the other options for providing connectivity.

We will start by looking at connecting two VNETs.

Previously, we separated services within different subnets. However, each of those subnets was in the same subnet. Because of this, connectivity between the devices was automatic – other than defining NSG rules, connectivity just happened.

More complex solutions may be built across multiple VNETs, and these VNETs may or may not be in the same region. By default, communication between VNETs is not enabled. Therefore you must set this up if required. The simplest way to achieve this connectivity...

Load balancing and advanced traffic routing

Many PaaS options in Azure, such as Web Apps and Functions, automatically scale as demand increases (and within limits you set). For this to function, Azure places services such as these behind a load balancer to distribute the load between them and redirect traffic from unhealthy nodes to healthy ones.

There are times when either a load balancer is not included, such as with VMs, or when you want to provide additional functionality not provided by the standard load balancers – such as the ability to balance between regions. In these cases, we have the option to build and configure our load balancers. You can choose several options, each providing its capabilities depending on your requirements.

Azure Load Balancer

Azure Load Balancer allows you to distribute traffic across VMs, allowing you to scale apps by distributing load and offering high availability. If a node becomes unhealthy, traffic is not sent to us, as shown in the...

Summary

This chapter has looked at many different options and configurations for ensuring connectivity across Azure and hybrid scenarios. We examined how to use public and private DNS in Azure and how we can then control inbound and outbound access using a combination of NSGs, ASGs, and Azure Firewalls.

We have seen how user-defined routes can help us strictly manage traffic flow to support different requirements. Finally, we looked at how to use other Azure services such as Azure Load Balancer, Traffic Manager, Application Gateway, and Azure Front Door to spread traffic over services for better resilience and performance.

In the next chapter, we will look in detail at the different storage options available for use in Azure, including the types of storage, how we can secure our data on it, and what tools we can use to manage it.

Exam scenario

The solutions to the exam scenarios can be found at the end of this book.

MegaCorp Inc. wants to start migrating several on-premises applications into Azure. They want a hybrid configuration whereby VMs in Azure can connect to services on-premises and vice versa.

Any connection into Azure must be resilient, private, and stable with guaranteed throughput.

All VMs in Azure must route any internet-bound traffic through a central firewall to have complete control.

Suggest a solution that achieves these requirements. You need to consider the best connectivity options, how DNS resolution will work, and what sort of firewalls and NSGs you may need.

Further reading

• Azure Virtual Network: https://docs.microsoft.com/en-us/azure/virtual-network/
• Network security groups: https://docs.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview
• VPN gateways: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpngateways
• Azure Load Balancer: https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview
• Azure Application Gateway: https://docs.microsoft.com/en-us/azure/application-gateway/
• Azure Traffic Manager: https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-overview
• Service endpoints: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview
• Private endpoints: https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-overview
• Azure Firewall: https://docs.microsoft.com/en-us/azure/firewall/overview