Making applications more secure by enforcing private network access to PaaS
This solution reduces the risk of unauthorized access or attacks by ensuring that Platform as a Service (PaaS) resources are not directly exposed to the public internet.
Business problem
Attackers require some form of network access to any services they target. PaaS offerings often default to exposing functionality on a public endpoint to increase ease of adoption while minimizing costs. This approach however, also increases the potential attack surface of the overall solution. Most PaaS offerings do have features to enable a greater level of network access restrictions but correctly configuring these features can be complicated.
Control traffic to and from a service
Many enterprises require access to cloud native solutions to be restricted to designated Virtual Networks (VNets) to minimize the number of endpoints accessible through the public intranet and reduce the available attack surface. Administrators can manage the potential attack surface at the network transport level by restricting which traffic is routed between the public endpoints, VNets, and subnets within those VNets. It's common practice to layer access to these VNets using security appliances such as firewalls and gateways, or specialized cloud services such as Azure Application Gateway at each layer. Then controlling traffic to the next layer using rules. These rules may use the traffic source and other characteristics to allow or deny traffic to be routed to particular endpoints. PaaS offerings also provide functionality to control traffic routing to and from the service. Correctly configuring the combination of available features, services, and appliances allows applications to conform to the enterprise requirements, effectively reducing the available surface.
Value proposition
By implementing these network restrictions, organizations reduce the potential attack surface of the overall solution to attackers who only have access to public endpoints. Attackers would have to first gain the ability to execute code or forward traffic to the services in the private networks to access these components. This approach increases the security of the overall solution; however, it also increases costs and complexity.
Logical architecture of network segregation
Network access restrictions are required to provide a solution for the business problem described. These network access restrictions can be achieved by using the Network segregation capability. Within this capability, the Isolation and Integration characteristics can be used to solve different permutations of the business problem.
Restrict traffic to a specific VNet
Isolation is used to ensure that all inbound network traffic to a PaaS is restricted to a specific virtual network. In addition, all existing public traffic to the PaaS should be disabled. Disabled public access ensures that only workloads inside a virtual network have network access to a PaaS. All other access will be denied.
The following example demonstrates how isolation could be implemented. All inbound access to the Azure Function App is restricted to workloads deployed in the Azure Virtual Network. The isolation is achieved by using a Private Endpoint which creates private routes from the virtual network to the Azure Function App that is capable of using Azure Private Link. All existing public endpoints and access to the Azure Function App are disabled. Disabling public access ensures that only workloads from within the virtual network can access the Azure Function App.
Direct traffic to a specific VNet
Integration is used to ensure that all outbound network traffic from a PaaS is directed into a specific virtual network. This ensures that PaaS can access workloads within a virtual network.
Integration is often combined with isolation to enable PaaS services to communicate with one another privately through a virtual network.
The following example demonstrates combining isolation and integration to ensure that all network traffic between two PaaS services occurs via an Azure Virtual Network. Although the PaaS services are not deployed within the virtual network, all traffic between them is restricted to the virtual network. The Azure Web App is integrated with the virtual network via App Service VNet Integration, while the Azure Private Link capable Azure Storage Account has inbound access isolated to the virtual network via a Private Endpoint. This isolation and integration ensures that the web app can only communicate with the storage account via the virtual network. All existing public endpoints and access to the Azure Storage Account are disabled.
Implementation
You need to consider the following when using/building implementations for the solution:
- Networking: A basic understanding of core concepts such as ip address ranges and subnets is required. Additionally, an understanding of traffic routing is useful for more complex network topologies.
- DNS: When moving traffic to private networks, DNS configuration becomes more important to ensure that the fully qualified domain name (FQDN) for services can be resolved. A basic understanding of DNS, zone files, and how to configure them is important.
- Network Filters and Rules: When a higher degree of control over traffic between subnets or in/out of a virtual network is required, then consider how network filters and rules can be leveraged.
Azure Functions triggered from a private Event Hub
This implementation addresses a scenario where an Azure Functions based workload is triggered by messages on an Event Hub. All network traffic between the Azure Function and the Event Hub must be constrained to a virtual network.
In this implementation, isolation ensures the Event Hub can only be accessed via services within the virtual network, creating a secure messaging layer. The implementation restricts all outbound traffic from the Azure Function to services within the virtual network. This restriction enables the creation of workloads that are automatically executed when messages ingested, facilitated by input bindings.
Azure Function with private HTTP trigger
This implementation addresses a scenario where there is a requirement to only allow network access to an Azure Function HTTP Trigger from a specific virtual network.
This implementation uses isolation to ensure that only clients connected to the specified virtual network are able to access the Azure Function HTTP trigger. The isolation for inbound network traffic to the Azure Function is configured via a Private Endpoint. The Azure Function's Private Endpoint is assigned an IP address from the specified Private Endpoint subnet.
Azure Web App with private HTTP Endpoint
This implementation addresses a scenario where there is a requirement to only allow network access to an Azure Web App from a specific virtual network.
This implementation uses isolation to ensure that only clients connected to the specified virtual network are able to access the Azure Web App. The isolation for inbound network traffic to the Azure Web App is configured via a Private Endpoint.
Azure Application Gateway with private API Management and Web App
This implementation addresses a scenario where there is a requirement to allow only network access to an Azure Web App from a specific virtual network.
This implementation uses isolation to ensure that the Azure Web App is only accessible from within the virtual network. It provides advanced security and networking functionality like firewalls, SSL offloading, etc., via network services deployed into the virtual network. Only clients that are connected to the specified virtual network or able to bypass the firewall and networking rules, can access the Azure Web App.
Azure Databricks in a Virtual Network
This implementation shows how to deploy Azure Databricks in a secured networking environment without inbound or outbound public access.
This implementation uses isolation to ensure connectivity from Azure Databricks to common services such as Azure Storage, Azure SQL and Azure Key Vault, while keeping connections private using Private Endpoints.
Azure Data Factory in a Managed Virtual Network
This implementation shows how to correctly configure an Azure Data Factory instance that utilizes a Managed VNet.
This implementation uses isolation to ensure connectivity from Azure Data Factory to common services such as Azure Storage and Azure Key Vault while keeping connections private using Private Endpoints. It also provides access to those common services to customer workloads via a customer vnet through additional Private Endpoints.
Azure Purview in a Virtual Network
This implementation shows how to correctly configure an Azure Purview instance that utilizes a Managed VNet.
This implementation uses isolation to ensure connectivity from the Azure Purview instance to common services such as Azure Storage, Azure SQL and Azure Key Vault while keeping connections private using Private Endpoints. It also provides access to those common services to customer workloads via a customer vnet through additional Private Endpoints.
Azure Synapse in a Managed Virtual Network
This implementation shows how to correctly configure an Azure Synapse instance that utilizes a Managed VNet.
This implementation uses isolation to ensure connectivity from the Azure Synapse instance to common services such as Azure Storage and Azure Key Vault while keeping connections private using Private Endpoints.