Mastering Network Infrastructure in Azure: Securing Your Network and Protecting Your Applications

Introduction:

In this comprehensive guide, we delve into the essential aspects of ensuring robust network security and application protection within the Azure cloud environment. We explore various Azure services and strategies designed to fortify your network defenses, safeguard your applications, and minimize security risks.

Service Endpoint

Service Endpoint is a fantastic feature in Azure that helps boost your network’s security and safeguard your applications. Let’s dive into what Service Endpoint is and how it can benefit you. Imagine you have a virtual network in Azure, and you want its resources to communicate securely with certain Platform-as-a-Service (PaaS) solutions. Service Endpoint lets you achieve this by using your virtual machine’s private IP address as the source IP when connecting to these PaaS services.

For instance, consider a scenario where you have a storage account. To ensure its security, you can set up a service endpoint that’s linked to the virtual network containing your virtual machines. Once this service endpoint is configured, any outgoing requests from your VMs will carry their private IP addresses as the source. This means that data traveling to the storage account doesn’t go over the public internet but takes a more secure path through Azure’s internal network. However, it’s important to note that even though the VM resolves the name of the storage service to a public IP when using Service Endpoint, the actual request is smartly routed through Azure’s network, maintaining the privacy of your VM’s private IP.

In simpler terms, Service Endpoint helps make your network more secure, enhances routing efficiency, and is incredibly easy to set up. You don’t need to fuss with public IPs or complex configurations. Just select your subscription, resource group, and virtual network, and your Service Endpoint will be good to go in no time. So, in essence, Service Endpoint is a handy tool that strengthens security and simplifies communication between your virtual network and PaaS solutions in Azure.

Private Link

Private link offers a private, dedicated connection to support various Platform-as-a-Service (PaaS) offerings using a private IP address directly from your virtual network. Let’s explore how Private Link sets itself apart from other services like Service Endpoint.

While Service Endpoint leverages the Microsoft backbone network for routing, it’s important to note that the names of servers it resolves to are public IP addresses. In contrast, Private Link introduces a different approach. It acts as a bridge, providing PaaS solutions with private IP addresses originating from your virtual network. Once established, this creates a network environment where these services appear as if they are part of the same network as your Virtual Machines (VMs). Communication between VMs and PaaS solutions takes place over these private IP addresses.

Imagine you have resources in Azure, such as virtual machines or databases, and you want these resources to communicate with your on-premises environment. Your on-premises environment typically includes your local office network or data center.

Now, let’s compare two Azure features: Service Endpoint and Private Link, when it comes to establishing this communication.

1. Service Endpoint: When using Service Endpoint, you may need to set up network address translation (NAT) configurations. NAT is a technique that allows your Azure resources to use private IP addresses internally but map them to public IP addresses when communicating with resources outside your Azure virtual network. This mapping between private and public IPs can involve some complexity in terms of configuration.
2. Private Link: On the other hand, Private Link simplifies the process. You only need to create a gateway in your Azure virtual network that connects to your on-premises infrastructure. This connection is straightforward and does not require extensive NAT configuration. It operates within the private IP address space of your Azure virtual network, meaning that the communication remains within the private boundaries of your Azure network.

Additionally, with Private Link, you can use services like ExpressRoute or VPN to establish this connection. These are common methods for connecting on-premises environments to Azure resources. The advantage here is that Private Link seamlessly integrates with these connection methods, making the setup easier without the need for extra complex configurations.

Private Link isn’t limited to Azure services alone. It also facilitates connections to external services. You can use it to establish connections with other virtual networks and VMs, ensuring a secure and efficient network environment. Moreover, you can employ Private Link to connect with a range of PaaS services, including Azure SQL Database, Azure storage accounts, Redis Cache, and more. It’s worth noting that partner services, such as Snowflake, can also benefit from Private Link.

Now, let’s delve into the key benefits of leveraging Private Link:

1. Private Connectivity: Private Link grants services within your virtual network a private IP address, seamlessly integrating them into your network infrastructure.

2. On-Premises Connectivity: Whether you opt for an ExpressRoute or VPN connection, Private Link enables straightforward communication with PaaS solutions over private IP addresses.

3. Elimination of Public Internet Dependency: By conducting all communication over private IP addresses within the same virtual network, Private Link eliminates the need for public internet access. Unlike Service Endpoint, where names resolve to public IP addresses, Private Link ensures that names resolve to private IP addresses, enhancing your network’s security.

Private Link is a valuable addition to your network security arsenal, providing both privacy and efficiency in your network communication. With this understanding, let’s move on to explore more tools and strategies for securing your Azure network.

Network Security Groups

Network Security Groups are a familiar and vital component in the realm of Azure network management. They serve as a key tool when you’re configuring virtual machines (VMs) and need to control the traffic they allow or deny. Let’s delve into the key aspects of NSGs:

1. Traffic Filtering at Multiple Levels: NSGs empower you to filter network traffic at both the subnet and the network interface (NIC) levels. This means you can set up rules that control what kind of traffic is allowed or blocked for your resources.
2. Precedence of Rules: When you define rules for NSGs, it’s important to understand that rules applied at the subnet level take precedence over those applied at the NIC level. In practical terms, this means that if a particular traffic type is allowed at the subnet level, it will apply to all the resources within that subnet. This rule precedence simplifies management and ensures consistency.
3. Traffic Control: NSGs provide you with granular control over network traffic. You can specify rules based on factors such as port, protocol, Azure service, and even the direction of the traffic (inbound or outbound). This level of precision allows you to tailor your network security to your specific needs.
4. Inbound and Outbound Rules: NSGs offer separate sets of rules for inbound and outbound traffic. This separation means you can define precisely what traffic is permitted to enter or leave your virtual machines.
5. Default Behavior: By default, outbound traffic is allowed, which means your VMs can initiate connections to external resources. However, if necessary, you can override this behavior to restrict outbound traffic. On the other hand, inbound traffic is entirely blocked by default, except for traffic related to the virtual network itself and Azure Load Balancer health metrics. To permit incoming traffic, you must explicitly configure rules to allow it.
6. Scope Flexibility: NSGs can be applied at either the subnet or the NIC level of a virtual machine. When applied at the subnet level, the rules are inherited by all the NICs within that subnet. This inheritance ensures uniform security within the subnet. If you require exceptions or customized rules for specific VMs, you can associate an NSG directly with the NIC of an individual VM, allowing you to override subnet-level rules.

In summary, Network Security Groups are a crucial feature for enhancing the security of your Azure network resources. They allow you to finely control traffic, establish default behaviors, and apply security rules at multiple levels to fit the specific needs of your virtual machines and subnets. Whether you’re setting up SSH, RDP, or other traffic access for your VMs, NSGs provide the necessary tools to safeguard your network effectively.

Azure Firewall

Azure Firewall is a robust security solution designed to protect the resources within your Azure virtual network. It plays a pivotal role in safeguarding your network traffic and enforcing security policies. Here’s a closer look at Azure Firewall’s key features and functions:

1. Dedicated Subnet — AzureFirewallSubnet: To deploy Azure Firewall effectively, you need a dedicated subnet within your virtual network, known as AzureFirewallSubnet. Azure Firewall operates within this subnet to manage network traffic.
2. Network Protection: One of the primary functions of Azure Firewall is to provide comprehensive network protection. It accomplishes this by offering inbound protection for non-web traffic as well as outbound traffic. This protection helps prevent unauthorized access and potential threats from infiltrating your network.
3. Rule-Based Policies: Azure Firewall empowers you to define and enforce rules and policies for network traffic. By default, all incoming and outgoing traffic is denied, creating a secure environment. You have the flexibility to create rules that allow specific types of traffic, including network rules and rules based on Fully Qualified Domain Names (FQDNs). These rules enable you to control traffic flow with precision.
4. Deployment and Availability: Azure Firewall is typically deployed in the hub virtual network to oversee and monitor all traffic. It then routes the traffic to the spoke virtual networks based on defined rules. It’s important to note that Azure Firewall is a platform-managed service provided by Microsoft. This means that the scalability and availability of the service are entirely managed by Microsoft, reducing operational complexity.

Traffic Flow:

In a typical deployment scenario, traffic from your on-premises environment is directed to the AzureFirewallSubnet. Here, the default outbound rule is overridden to ensure that traffic is forced through Azure Firewall. This approach enhances security by allowing you to carefully manage outbound traffic. By default, all incoming traffic from the internet is denied, and you must explicitly create rules in the firewall to permit specific traffic.

In essence, Azure Firewall acts as a crucial security layer in your Azure network infrastructure, protecting your resources from potential threats and unauthorized access. It accomplishes this through rule-based policies, dedicated subnets, and network protection, all while ensuring scalability and availability through Microsoft’s management.

Web Application Firewall

At its core, a Web Application Firewall (WAF) is like a digital security guard for your web applications. It monitors incoming traffic, filters out malicious requests, and ensures that only legitimate and safe traffic reaches your web applications.

Let’s explore what the WAF does in a straightforward and engaging manner.

Your Digital Protector

Imagine the WAF as your online bodyguard, always on the lookout for potential threats to your web applications. It’s skilled at spotting common attack methods like cross-site scripting and SQL injection. When it detects something fishy, the WAF steps in to block access, ensuring your web apps remain secure.

Two Protective Modes

The WAF operates in two distinct modes: Prevention and Detection. In Prevention mode, it actively stops potential threats in their tracks, acting as a proactive shield. In Detection mode, the WAF takes a more cautious approach. It logs any suspicious activity and allows the traffic to continue, providing an extra layer of scrutiny before taking action.

Effortless Management

One handy feature of the WAF is how easy it is to manage. You can create rules and policies to control its behavior efficiently. This centralized control makes it a breeze to protect all your web applications, much like having a single, comprehensive security strategy.

Teamwork Counts

The WAF doesn’t work alone; it teams up with other services like Application Gateway, Content Delivery Network (CDN), and Azure Front Door. These collaborations enhance its protective abilities, ensuring complete security for your web applications, no matter where they’re located.

In summary, the Web Application Firewall (WAF) is your web applications’ guardian, shielding them from online threats. It’s a valuable addition to your cybersecurity toolkit, keeping your online assets safe and sound. When it comes to web security, you can trust the WAF to have your back.

Azure Firewall vs. Web Application Firewall (WAF): When and Where to Use Them

Now that we’ve explored Azure Firewall and Web Application Firewall (WAF) individually, you might be wondering how to make the best use of these security tools. Let’s delve into different scenarios to understand when to deploy Azure Firewall, WAF, or even a combination of both.

1. Azure Firewall Alone:

• Ideal For: Networks without web applications.
• Use Case: When your network consists mainly of non-HTTP workloads that need protection.
• Description: Azure Firewall stands as the stalwart guardian of your entire virtual network, ensuring security, monitoring, and control. It’s the go-to choice when web applications aren’t in the picture.

2. WAF Alone:

• Ideal For: Networks with web applications.
• Use Case: When your primary concern is safeguarding web applications from online threats.
• Description: WAF steps in as the specialized bouncer for your web applications, meticulously scrutinizing and filtering HTTP traffic. It’s the perfect choice for shielding your web apps from common online menaces like SQL injection and cross-site scripting.

3. In Parallel:

• Ideal For: Comprehensive network security.
• Use Case: When you want to cover all fronts — protecting web-based traffic with WAF while ensuring non-web-based traffic is scrutinized by Azure Firewall.
• Description: This common implementation deploys WAF to fend off web-based attacks while leaving the inspection of other traffic types to Azure Firewall. It’s a balanced approach to network security.

4. WAF in Front:

• Ideal For: Needing client IP address information for web traffic.
• Use Case: When you require knowledge of client IP addresses for web traffic, which WAF can’t provide.
• Description: Placing WAF in front of Azure Firewall lets it protect your web applications. After WAF filters web traffic, Azure Firewall steps in to handle the rest. This setup is useful when client IP addresses are crucial, as WAF primarily focuses on HTTP headers and packets, not layer 4 properties.

5. Azure Firewall in Front:

• Ideal For: Centralized traffic inspection.
• Use Case: When you want Azure Firewall to inspect all incoming traffic before routing it to WAF and other workloads in your virtual network.
• Description: Azure Firewall takes the lead, scrutinizing all traffic before it reaches WAF and other resources. This setup offers centralized control over network security.

These are the possible deployment scenarios for Azure Firewall, WAF, or a combination of both, depending on your network’s specific requirements. By choosing the right configuration, you can ensure robust security for your Azure resources.

DDOS

In the digital world, keeping your network safe is a must. One key way to protect your Azure network is by using Distributed Denial of Service (DDoS) protection. Let’s explore what DDoS protection is all about:

1. Automatic Defense:

• Built-In Security: Azure includes DDoS protection by default in your virtual network.
• Two Options: You have two choices - basic and standard. Basic Tier - Offers essential protection. Standard Tier - Elevates your security with extra features, available through subscription.

2. Continuous Monitoring:

• Always On: DDoS protection works around the clock, keeping a close watch on your network.
• Adaptive Response: It uses smart technology to study incoming traffic patterns. If it detects any suspicious behavior that resembles a DDoS attack, it takes quick action to block harmful data.

3. Multiple Layers of Security and Alerts:

• Complete Protection: DDoS protection uses a layered approach to ensure multiple levels of security.
• Stay Informed: Advanced attack insights and real-time alerts keep you updated, so you can respond effectively.

4. Making the Right Choice:

• Basic or Standard: While basic protection is included, consider upgrading to the standard plan for important workloads.
• Public IPs: Especially if your resources are accessible via public IPs, it’s a good idea to go for the standard plan for stronger security.

5. How DDoS Standard Plan Works:

• When your virtual network is connected to the internet, it becomes susceptible to data packets coming in from various sources. The DDoS Standard Plan acts as a shield for your network. It utilizes a smart technology called adaptive tuning to monitor the incoming data. This technology is designed to learn and identify patterns that might indicate potential attacks. When such patterns are detected, the plan takes immediate action to block any harmful data. Despite this vigilant defense, legitimate traffic proceeds undisturbed, ensuring that your web servers can continue providing uninterrupted service.

In simple terms, DDoS protection acts as a shield against harmful attacks trying to disrupt your network. While basic protection is a good starting point, the standard plan, especially for important workloads or resources accessible via public IPs, provides stronger security and defenses. With constant monitoring, smart responses, and a multi-layered defense strategy, DDoS protection strengthens your network’s ability to withstand evolving threats.

Azure Bastion

Azure Bastion is a handy tool that simplifies how you connect to your virtual machines (VMs) deployed in Azure. Whether you need to use RDP, SSH, or a TLS/SSL connection, Bastion has got you covered. One standout feature of Bastion is that you can access your VMs without the need for any public IP addresses.

In the past, connecting to VMs without public IPs was cumbersome. You had to set up a jump box server or a jump host in the same virtual network, which did have a public IP. Users would connect to this jump server, and from there, they could RDP or SSH into other VMs in the network. This approach also applied when connecting to VMs in peer networks. However, managing this jump box came with its own set of challenges, including OS maintenance, updates, patching, and security.

To use Azure Bastion, this service deploys a Bastion host in a dedicated Azure Bastion Subnet within your virtual network. Instead of relying on traditional methods like using an RDP or SSH client and manually entering IP addresses, you can seamlessly access Azure Bastion by navigating to the Azure portal over a secure TLS/SSL connection. Once you’re in the Azure portal, you can effortlessly establish RDP or SSH connections directly to your VMs.

Azure Bastion offers several advantages. Firstly, it ensures secure connections, as there’s no reliance on public IPs. Secondly, it eliminates the need to expose ports to the internet, enhancing security. Lastly, it allows for centralization by deploying Bastion in a hub virtual network. This hub-and-spoke architecture simplifies access to VMs in various spoke networks, making management more efficient.

In summary, Azure Bastion streamlines remote access to VMs, making it more secure and user-friendly than traditional methods involving jump hosts and public IPs.

Just In Time (JIT) access

The next topic we’ll explore is JIT access, which stands for just-in-time access. JIT access allows you to obtain access to your virtual machines (in the context of virtual machines) precisely when needed. One of the key advantages of implementing JIT access is the ability to lock down inbound traffic. When JIT is enabled, Microsoft Defender for Cloud checks whether a “deny all traffic” rule exists for the selected ports, typically reserved for management tasks such as RDP or SSH. This rule effectively blocks access to the VM over these management ports, enhancing security against potential attacks.

JIT access is a feature that comes as part of the Microsoft Defender for Cloud plan, and it serves the purpose of providing on-demand access to your VMs. When you request access to a VM, the deny rule for the chosen management ports is temporarily lifted for a specified period. Once that timeframe expires, the rules are reinstated, restricting access once again. It’s important to note that this feature requires you to purchase the standard plan of Microsoft Defender for Cloud to utilize it effectively.

Now, let’s take a closer look at the decision-making process regarding JIT access.

Firstly, we check if JIT VM access is already enabled. If it is, the VM is classified as healthy. If not, we move on to the next question: Is the VM assigned to a network security group (NSG)? If the answer is yes, we evaluate whether the NSG allows traffic on ports 22, 3389. If it doesn’t, the VM is classified as healthy.

On the other hand, if the VM is assigned to an NSG that allows this traffic, we proceed to determine if there’s a firewall in front of the VM that might be blocking the traffic. If there’s no firewall or if the firewall isn’t blocking traffic on the management ports, our recommendation is to enable just-in-time access.

However, if the firewall is indeed blocking traffic on these ports, we once again classify the VM as healthy because both the NSG and the firewall restrict access to the management ports.

Returning to the left-hand side of the decision tree, if the VM is not assigned to an NSG, we then inquire whether the VM is protected by a firewall. If that’s not the case, we categorize the VM as “not applicable” to JIT access.

This decision-making process helps determine whether JIT access is necessary, not applicable, or if the VM can be considered healthy without JIT. That concludes our discussion for this module.

Conclusion

So far, we’ve built a strong foundation in understanding the vital components of Azure’s network infrastructure. In our introduction article of the ‘Mastering Network Infrastructure in Azure’ series, we’ve introduced you to StockCosmos Inc., a fictional company facing some intricate Azure networking challenges.

These challenges provide a real-world context for our journey through the complexities of Azure network architecture. As we bring this module to a close, I encourage you to stay with me on this exciting exploration. We’ll dive deep into practical solutions for StockCosmos Inc.’s networking hurdles in the upcoming article.

Keep an eye out for our next installment, and let’s continue this learning adventure together!