RICH MAN’S SOLUTION: NETWORK ISOLATION, A.K.A PRIVATE IN THE CLOUD
For a solid second layer-of-defence, we are going to make full use of network isolation in a VNet. This ensures that we set up a similar network as companies have on-premises.
In Azure, it might look like this:
- For IaaS services (such as Kubernetes and Virtual Machine), nothing will change. These, as we have already seen, are always deployed in a VNet.
- For many PaaS services, the firewall is closed, and we create a Private Endpoint in the VNet. More details follow below.
- For App Service (PaaS), an App Service Environment is created in the VNet, making the App Service entirely deployed in the VNet, and not accessible from the public Internet. More details for these also follow below.
- Using an Express Route, we create a permanent network connection between the office (on-premises) and the VNet in Azure. This is a two-way connection. Perhaps an Express Route is on the pricey side, in which case it can be done with a site-to-site VPN.
Through these modifications, an additional layer-of-defence has been added.
That hacker from Russia doesn’t stand a chance. The fort is locked! He will probably set his sights on someone else.
I have already briefly shown the use of Private Endpoints and App Service Environment. This is where it gets complex, however: virtually every PaaS (and SaaS) service has its own way for network isolation. These bring additional costs for Azure resources, as well as additional complexity that will translate to higher development costs. Hence, this is the Rich man’s solution.
Following are the most common PaaS services, with their corresponding solution for network isolation…
PRIVATE ENDPOINTS, FOR STORAGE SERVICES
- Storage Account
- SQL Database (Server)
- Cosmos DB
- Container Registry
- Key Vault
- And many others, see the documentation
With a Private Endpoint, you create a network interface with a private IP address in the VNet. This network interface is connected to the storage service. Also, a DNS record is created with the exact same name/URL as your storage connection string, but it refers to the private IP address instead of the public IP address. On the storage service, the firewall (of the public IP) is closed.
This whole thing ensures that without modifying the application, with the exact same connection string, you still connect to the storage service.
Cost: €9 /month, in addition to the storage service
Private Endpoints are the successor to Service Endpoints. Service Endpoints are still available and even easier to use, but also more limited in capabilities.
APP SERVICE ENVIRONMENT (ASE), FOR APP SERVICES AND FUNCTIONS
The App Service Environment is an environment within which multiple App Service Plans (Web servers) can be deployed, with the App Services (Web sites) on top of them. The big difference is that now App Services can only be accessed from the VNet, and access on-premises data resources.
If you are normally used to an App Service Plan having a SKU of Free, Basic or Standard, then on the App Service Environment it has a SKU of Isolated (I1, I2, I3).Cost: € +/- 950 /month per App Service Environment v2, on top of the I1, I2, I3 App Service Plan cost.
A major disadvantage of the current ASE (v2) is that it has a fixed (stamp) cost of about €950 /month, and on top of that the cost for the App Service Plans (e.g. for I1 it is €184 /month). But there is hope, as there is a new preview version of the ASE that is free of charge. See App Service Environment v3 (and Isolated v2 Plan). You then do not pay the fixed stamp cost of € 950 /month, but only the App Service Plans (I1v2, I2v2, I3v2), although the cheapest variant I1v2 is already € 350 /month.
It can also be done differently.
In case you’re thinking that App Services can be linked to a VNet even without an App Service Environment, that’s right. However, you then need to use 2 concepts:
- Access from VNet to app service: Private Endpoint (requires Premium App Service Plan)
- Access from app service to VNet: VNet integration
ON-PREMISE DATA GATEWAY, FOR POWER BI, POWER APPS AND LOGIC APPS
When using Power BI (reporting tooling), Power Apps (no-code/low-code application platform) and Logic Apps (no-code/low-code workflows), it is fairly obvious that they must also be able to access on-premises data resources, or securely access Azure data resources.
To achieve network isolation with Power BI, Power Apps and Logic Apps, you need to install the Data Gateway software on a Virtual Machine (Windows). This could be in Azure, but also on-premises.
Cost: Only the cost of the VM
INTEGRATED SERVICE ENVIRONMENT (ISE), FOR LOGIC APPS
With the previous solution “Data Gateway” for a Logic App, the compute is still running on a public-internet node. To ensure that not only data access but also compute is shielded, you can use an Integrated Service Environment (ISE).
The ISE is similar to the ASE, but specifically for Logic Apps. Various compute and storage resources are deployed that are managed by Microsoft.
- Developer: € +/- 750 /month
- Premium: € +/- 6,600/month
HYBRID RUNBOOK WORKER, FOR AUTOMATION ACCOUNTS (RUNBOOKS)
Automation Accounts are used for process automation, configuration management, update management and PowerShell desired state configuration (DSC).
To achieve network isolation with an Automation Account, you need to install the Hybrid Runbook Worker software on a Virtual Machine (Windows or Linux). This could be on Azure, but also on-premises.
Cost: Only the cost of the VM
INTEGRATION RUNTIME (IR), FOR AZURE DATA FACTORY (ADF)
Azure Data Factory is an ETL (Extract, Transform, Load) tool for copying and transforming data. For the old timers among us, this is the successor to SSIS (SQL Server Integration Services). Even with this service, it is very obvious that it must have access to on-premises data resources and/or network isolation.
To achieve network isolation with Azure Data Factory, you can choose from 2 options: A and B
A. SELF-HOSTED INTEGRATION RUNTIME
The Self-hosted integration runtime is again a software package that needs to be installed on a Virtual Machine (Windows). This could be in Azure, but also on-premises.
Cost: The cost of the VM + use of ADF.
- Can only copy data (data-copy), not transform (data-flow)!
B. MANAGED VIRTUAL NETWORK
It is also possible to use the (standard) Azure hosted Integration Runtime, but with a Managed Virtual Network. In this case, a VNet is created especially for the IR created by you, however, you yourself do not have access to this network. You can then create Private Endpoints towards Azure storage services, though, creating network isolation that way.
Cost: +/- 2x as much as the regular Azure Integration Runtime.
- Can access Azure storage services, but not on-premises data resources.
Using network isolation, it is possible to completely isolate a solution from public Internet. However, if less meticulous care is taken, a firewall may just be opened or a VM provided with a public IP address.
If you go to the trouble of making a solution secure, also look at safegaurds to keep the solution secure. This could be done with Azure policy, which ensures that, for example, it is not possible to deploy a VM with a public IP, and that a storage account always has the firewall on.