Secure Azure Network architectures

Chapter 1, “Introduction to Azure Network Security,” covers some basics to Azure networks and the current threat landscape. Given this, it is ever more important to define your Azure network architecture to meet needs but allow for network security and containment in the event of a breach.

Many organizations used perimeter-based networks that assume all systems behind the perimeter are trusted. This type of network defense is obsolete. Zero Trust networks are the next evolution that eliminates the trust based on network location. Zero Trust typically integrates user and device information, such as location and health state, which is run through a policy engine to determine whether access should be permitted or denied. In Zero Trust, a user in the corporate office on a managed machine might be able to access a cloud-based highly sensitive application, but when they go home, the same access may be limited (block downloading) or denied.

Layering cloud security into your Azure deployments as part of a Zero Trust approach allows for limiting or containing an attack if it does occur. In a simple form, having all IaaS VMs on one subnet would allow an attacker to quickly pivot between machines. Breaking the machines into groups by function and moving them to separate virtual networks (vNet) and applying Network Security Groups (NSGs) to the virtual networks can prevent an attacker from pivoting at all.

This chapter explains the best practices to a good network architecture, various types of network architectures in Azure, and how network security services can be layered in to protect these architectures.

Best practices

Before diving into network architectures, it’s important that we quickly mention Azure Well-Architected Framework. The framework consists of the following five pillars:

• Cost Optimization

• Operational Excellence

• Performance Efficiency

• Reliability

• Security

The Azure Well-Architected Framework gives you a way to apply the best practices and principles to your applications or services. Security is one of the most important aspects of architecture. It provides assurance for the CIA (confidentiality, integrity, and availability) triad against attacks and loss of data. Losing these assurances can hurt an organization’s reputation, business operations, and revenue. If you don’t cost optimize your architecture, your return might be lower, but if you don’t secure your architecture, there might be no returns at all.

Under the pillar of security, network security and containment is a key topic that organizations must adhere to for protecting their cloud deployments. Here are the best practices for network security and containment:

• Align network segmentation with enterprise segmentation strategy

• Centralize network management and security

• Evolve security beyond network controls

• Build a security containment strategy

  • Define an internet edge strategy

  • Decide on an internet ingress/egress policy

  • Mitigate DDoS attacks

  • Design virtual network security technology

• Decide use of legacy network security technology

• Enable enhanced network visibility

The first best practice is to align network segmentation with enterprise segmentation. Organizations need to define how they will segment the enterprise starting from the top so that all teams (identity, network, app teams, and so on) are building and working to the same strategy. The following graphic depicts a reference enterprise segmentation from the Well-Architected Framework. Here the organization has created a central identity store, uses Management Groups to apply central policies and permissions, and has broken networks into segments that align with enterprise segments of subscriptions and resources. Figure 2-1 shows a segmentation reference model that can be used as a starting point.

Under the core services, the organization has centralized network management and security. This is the second best practice for network security. By centralizing network management and security, the organization can prevent applications or segments from being created that do not adhere to the network security strategy. Very often organizations that don’t centralize have new resources created in the cloud with a direct connection to the internet and little to no network security applied. This results in attacks against those resources that we know are unavoidable! Centralizing network management and security ensures new segments are protected and leverages the tools and expertise of the network and security teams. The following graphic depicts the reference for network security applied using the enterprise segmentation strategy. Figure 2-2 is a possible model for centralized network management and security.

In this design, the shared services segment is a hub virtual network providing core services, connectivity to on-prem, and public connectivity. By using this design, the organization can control ingress/egress (north-south) traffic from the hub and apply to all spokes. The next best practice is to define an internet edge strategy. Organizations need to choose how they will protect against from internet-based attacks. There are two primary choices:

• Use cloud native controls, such as Azure Firewall and Web Application Firewall This approach typically implements basic security that is good enough for common attacks but is well integrated into the platform.

• Use partner virtual network appliances (available in the Azure Marketplace) This approach often provides advanced features that protect against sophisticated attacks, but can cost more. An organization may also have existing knowledge/skills on the partner virtual network appliances.

The organization must decide based on experience and requirements. Once decided, the next detail is to apply ingress/egress policy baseline. In perimeter-based networks, many organizations would allow network traffic from internal to internet over HTTP/80 and HTTPS/443. This was fine until attackers started using HTTP(s) outbound to conduct command and control of exploited machines. In the era of Zero Trust, the concept starts with deny all outbound and only allows what is needed. It can’t be as broad as HTTP(s), and it must be more restrictive to allow HTTP(s) to specific domain names. Using this approach makes it significantly harder for attackers because they can’t use their command and control nodes and need to find another way.

Let’s take a look at the ingress side, too. By using cloud native controls, instead of having to allow RDP/SSH inbound on the firewall, organizations can use services like Azure Bastion and Azure Security Center (ASC) Just-in-time VM (JIT) access. Azure Bastion allows remote management access using HTTPs and would not require opening the firewall at all. Because Bastion is integrated into the Azure portal, organizations could apply Azure Active Directory Conditional Access to the Azure portal, which would apply Zero Trust to remote management of VMs. ASC JIT integrates with Azure Firewall, which again means RDP/SSH would not need to be open all the time to all sources but could be opened on demand to only specific sources (client machine IP or a specific subnet). Both of these examples are part of the best practice to evolve security beyond network controls. They now factor in identity, device, and application as part of access to the VM incorporating Zero Trust principles.

For public-facing applications and services, it’s imperative to protect against DDoS attacks. Cloud providers, including Azure, provide DDoS protection at the network layer to protect the platform. Organizations should also apply DDoS protection at higher layers to protect their applications. This type of protection typically profiles the application usage and uses machine learning to look for anomalous traffic. The service should proactively protect the application before degradation. Azure provides DDoS protection service, which is covered in Chapter 6, “Mitigating DDoS attacks.”

Moving inward, organizations need to design network subnet security for their network segments. It is recommended that you plan for growth of resources in subnets over time and group resources in subnet by common roles and functions. Allow for larger IP address subnets on virtual networks to support expansion. If an organization has one subnet with five different resources, it needs to create NSG rules to support the different roles. Grouping resources allows for NSG configuration to be simplified and not get out of hand over time. It’s important to apply the principle of least privilege at the NSG to limit and contain traffic between subnets and virtual networks (east-west traffic). If an attacker somehow makes it into a virtual machine, maybe due to an application vulnerability, they won’t be able to pivot to other machines in other virtual networks. This is also referred to as micro-segmentation.

Organizations should enable enhanced network visibility as a best practice. Network logs should be integrated with the organization SIEM (security information and event management). This provides better visibility either through network log detection rules, the ability to query the data in the event of an incident for further investigation, or the ability to dashboard the data to look for trends and interesting changes for the central network and security teams. We cover monitoring in Chapter 8, “Security monitoring with Azure Sentinel, Security Center, and Network Watcher.”

Lastly, organizations have some existing or legacy network security technologies, like IDS/IPS, that they must decide whether to bring to the cloud. The recommendation is to evaluate these technologies and favor newer Zero Trust technologies where appropriate and look to cloud-native versions of where machine learning and artificial intelligence can be provided to replace or advance these types of technologies.