Securely Connecting to Backend Resources from an App Service Environment
Since an App Service Environment is always created in either an Azure Resource Manager virtual network, or a classic deployment model virtual network, outbound connections from an App Service Environment to other backend resources can flow exclusively over the virtual network. With a recent change made in June 2016, ASEs can also be deployed into virtual networks that use either public address ranges, or RFC1918 address spaces (i.e. private addresses).
For example, there may be a SQL Server running on a cluster of virtual machines with port 1433 locked down. The endpoint may be ACLd to only allow access from other resources on the same virtual network.
As another example, sensitive endpoints may run on-premises and be connected to Azure via either Site-to-Site or Azure ExpressRoute connections. As a result, only resources in virtual networks connected to the Site-to-Site or ExpressRoute tunnels will be able to access on-premises endpoints.
For all of these scenarios, apps running on an App Service Environment will be able to securely connect to the various servers and resources. Outbound traffic from apps running in an App Service Environment to private endpoints in the same virtual network (or connected to the same virtual network), will only flow over the virtual network. Outbound traffic to private endpoints will not flow over the public Internet.
One caveat applies to outbound traffic from an App Service Environment to endpoints within a virtual network. App Service Environments cannot reach endpoints of virtual machines located in the same subnet as the App Service Environment. This normally should not be a problem as long as App Service Environments are deployed into a subnet reserved for exclusive use by only the App Service Environment.
Although this article refers to web apps, it also applies to API apps and mobile apps.
Outbound Connectivity and DNS Requirements
For an App Service Environment to function properly, it requires outbound access to various endpoints. A full list of the external endpoints used by an ASE is in the "Required Network Connectivity" section of the Network Configuration for ExpressRoute article.
App Service Environments require a valid DNS infrastructure configured for the virtual network. If for any reason the DNS configuration is changed after an App Service Environment has been created, developers can force an App Service Environment to pick up the new DNS configuration. Triggering a rolling environment reboot using the "Restart" icon located at the top of the App Service Environment management blade in the portal will cause the environment to pick up the new DNS configuration.
It is also recommended that any custom DNS servers on the vnet be setup ahead of time prior to creating an App Service Environment. If a virtual network's DNS configuration is changed while an App Service Environment is being created, that will result in the App Service Environment creation process failing. In a similar vein, if a custom DNS server exists on the other end of a VPN gateway, and the DNS server is unreachable or unavailable, the App Service Environment creation process will also fail.
Connecting to a SQL Server
A common SQL Server configuration has an endpoint listening on port 1433:
There are two approaches for restricting traffic to this endpoint:
Restricting Access With a Network ACL
Port 1433 can be secured using a network access control list. The example below whitelists client addresses originating from inside of a virtual network, and blocks access to all other clients.
Any applications running in App Service Environment in the same virtual network as the SQL Server will be able to connect to the SQL Server instance using the VNet internal IP address for the SQL Server virtual machine.
The example connection string below references the SQL Server using its private IP address.
Although the virtual machine has a public endpoint as well, connection attempts using the public IP address will be rejected because of the network ACL.
Restricting Access With a Network Security Group
An alternative approach for securing access is with a network security group. Network security groups can be applied to individual virtual machines, or to a subnet containing virtual machines.
First a network security group needs to be created:
New-AzureNetworkSecurityGroup -Name "testNSGexample" -Location "South Central US" -Label "Example network security group for an app service environment"
Restricting access to only VNet internal traffic is very simple with a network security group. The default rules in a network security group only allow access from other network clients in the same virtual network.
As a result locking down access to SQL Server is as simple as applying a network security group with its default rules to either the virtual machines running SQL Server, or the subnet containing the virtual machines.
The sample below applies a network security group to the containing subnet:
Get-AzureNetworkSecurityGroup -Name "testNSGExample" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName 'testVNet' -SubnetName 'Subnet-1'
The end result is a set of security rules that block external access, while allowing VNet internal access:
To get started with App Service Environments, see Introduction to App Service Environment
For details around controlling inbound traffic to your App Service Environment, see Controlling inbound traffic to an App Service Environment
If you want to get started with Azure App Service before signing up for an Azure account, go to Try App Service, where you can immediately create a short-lived starter web app in App Service. No credit cards required; no commitments.