Reduce attack surface by enforcing private network access to PaaS services¶
Business Problem¶
Attackers require some form of network access to any services they would like to target. PaaS offerings usually 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.
Solution¶
Many enterprises require access to cloud native solutions to be restricted to designated Virtual Networks (VNets) to minimize the number of endpoints accessible from 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 by using appliances such as firewalls and gateways, or specialized cloud services such as Azure Application Gateway at each layer 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 services also offer 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, an organization can reduce the potential attack surface of the overall solution to attackers who only have access to public endpoints. Attackers would need 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, at the cost of increased costs and complexity.
Logical Architecture¶
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.
Isolation¶
Isolation is used to ensure that all inbound network traffic to a PaaS service is restricted to a specific virtual network. In addition, all existing public traffic to the PaaS service should be disabled. Disabled public access ensures that only workloads inside a virtual network will have network access to a PaaS service. 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 that provides private routes from the virtual network to the Azure Private Link capable Azure Function App. All existing public endpoints and access to the Azure Function App are disabled. Disabled public access ensures that only workloads from within the virtual network can access the Azure Function App.
Integration¶
Integration is used to ensure that all outbound network traffic from a PaaS service will be directed into a specific virtual network. This ensures that a PaaS service 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. Neither PaaS service is deployed to the virtual network, but all traffic between the services is constrained to the virtual network. The Azure Web App is integrated with the virtual network via App Service VNet Integration, and the Azure Private Link capable Azure Storage Account has inbound access isolated to the virtual network via a Private Endpoint. The 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.
Implementations¶
You will 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 becomes important.
- Network Filters and Rules - When a higher degree of control of traffic between subnets or in/out of virtual network is required, then consider how network filters and rules can be leveraged.
Azure Function triggered from 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.
This implementation uses isolation to ensure that the Event Hub can only be accessed via services within the virtual network, creating a secure messaging layer. The implementation also uses integration to restrict all outbound traffic from the Azure Function to services within the virtual network, enabling creation of workloads that execute on message ingestion, through 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 only allow 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. The implementation also 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.