Azure PaaS Network Security Best Practices

Introduction

Azure PaaS services simplify deployment and management of infrastructure, but out of the box, many are configured to allow access from any IP address. The good news is that Azure provides a range of powerful tools to allow you to restrict access to your PaaS resources and reduce your attack surface. If you work in a regulated industry such as finance, healthcare or defence, and/or your organisation is working towards or needs to maintain a certification like ISO 27001 or SOC 2, then understanding and using these tools to secure your PaaS resources is essential.

Public Network Access – The Default (Mostly)

By default, most Azure PaaS services are accessible from any IP address. While this might sound risky, access is still governed by Azure RBAC (Role-Based Access Control). Only authenticated and authorised users or services can interact with the resource. However, this leaves you much more vulnerable to credential stuffing and brute force attacks – an attacker can keep trying as many credentials as they like, and if you used a weak or compromised set of admin credentials (for those resources that allow you to specify them) for your resource, then they may be able to gain access.

Network Restrictions

To tighten security, you can restrict access to specific IP ranges, subnet IDs, or even individual Azure resources. For example:

• IP restrictions: Limit access to specified ranges of IP addresses. For example, the IP address of your office, or the IP addresses of cloud engineers who administer the resource. The main benefits of this approach are its simplicity and low cost – it doesn’t require additional infrastructure such as VPNs or private endpoints, and you can add IP restrictions to most PaaS resources without incurring additional costs. The disadvantage is that your traffic still traverses the public internet: if your PaaS database is misconfigured and you don’t enforce an encrypted connection, you just sent your credentials in plain text across the internet. There is also the problem of scalability – each time a new person joins your team, you have to add their IP address. If their IP address changes, you need to update the network restriction. If they leave, you need to remove it. This can create an ever-larger administrative burden as time goes on.

• Subnet restrictions: Allow traffic only from specific subnets within your VNet in Azure, e.g., the subnet where your VMs are, or the subnet you have your VNet integration set for your App Service. By adding a service endpoint to the subnet you are allowing access from, you ensure that your traffic to and from your PaaS resource traverses the Azure backbone rather than the public internet. This provides a much higher level of security than your traffic traversing the public internet – it reduces your attack surface dramatically and you are much less vulnerable to eavesdropping.

• Resource restrictions: This is useful for granting access to PaaS resources that you are unwilling or unable to use VNet integration or private endpoints with. It’s not supported by or for all Azure resources yet, but it can be a powerful and simple way of ensuring that only the resources you specify can access your resource.

Private Endpoints

Private endpoints provide a secure way to access PaaS services over a private IP address within your virtual network, and are the gold standard in network security. All of your traffic stays within your VNet, protected from prying eyes. Here’s a quick overview of how to configure them:

• Create a private endpoint and link it to your PaaS service (e.g., Storage Account, Key Vault).
• To simplify access, link the private endpoint to a private DNS zone so that a record is created – this enables resources that use this zone for resolution to access your PaaS resource by DNS name.
• Once the private endpoint is verified and working, disable public network access to enforce private-only connectivity.

Private endpoints are a requirement for PCI DSS and recommended for ISO 27001 and SOC 2.

Conclusion

Although Azure RBAC is a powerful tool for controlling access, it is just one tool available to you. Combining RBAC with network restrictions provides defence in depth: multiple layers of protection. If your RBAC is misconfigured, your resource is still protected by network restrictions and vice versa, and is a powerful way of protecting your data and ensuring that only legitimate users can access your resources.

Enforcing network restrictions is also essential for meeting compliance standards such as ISO 27001, SOC 2 and PCI DSS, and in regulated industries such as healthcare, defence, finance and law enforcement.