Private in the Azure Public Cloud
The major cloud providers have an extensive offering of services, which can be connected to each other with the least effort. Convenience comes first. But what about security and risk management? After all, it’s the public cloud when we talk about Azure, AWS, and Google Cloud (GCP).
In terms of network security, you must choose a different strategy for a public cloud platform than you do for on-premises. Traditionally, applications run on a private network on-premises (in a data center or your own physical servers). These cannot be accessed from the public internet. They usually have 2 layers-of-defense:
- Network access / security
- Authentication / authorization.
A hacker from Russia will have a hard time penetrating those on-premises servers.
Public in the cloud
As soon as we deploy a solution without thinking too much about it in the public cloud, then we often only have 1 layer-of-defense, namely authentication/authorization. This will often be done via username/password authentication, single sign-on, access-keys or other secrets.
Take a look at the diagram below. We take 3 compute services (Kubernetes, Virtual Machines and App Services), and 3 storage services (Container registry, Storage Account and SQL Database). Other variations are also possible, but in this case only Kubernetes and the Virtual Machine are in a VNet (Virtual Network). All other services have a public IP address and no integration with the VNet.
This is a party for that hacker from Russia, who has every chance to penetrate on services with a public IP address.
Characteristics:
- Infrastructure as a Service (IaaS) services (such as Kubernetes and Virtual Machines) already have VNet integration by default.
- Platform as a Service (PaaS) services (such as Container registry, Storage Account, SQL Database and App Service) do not have VNet integration out-of-the-box.
- Azure services do not have access to on-premises data sources.
Poor man’s solution: IP whitelisting
An easy way to add a second layer-of-defense is to apply IP whitelisting. All PaaS (and SaaS) services have this capability. With IP whitelisting you specify which IP addresses are allowed (think of the office, home workers and other Azure services).
This method is a common way. It is easy to start with, and in a short time you can achieve a lot.
This makes it a lot more difficult for that hacker from Russia, but not impossible.
However, this solution has a few drawbacks:
- IP addresses sometimes want to change, especially for home workers.
- Several PaaS services only have the IP addresses (without a name) in the firewall. Without administration, it is impossible to find out which IP address was intended for whom. As a result, they are never (or hard) to clean up.
- Sometimes you need to add IP addresses of Azure services (see Download Azure IP Ranges and Service Tags),which are very spacious. Hackers can also purchase Azure services that come in the same IP range, and thus penetrate through your second layer-of-defense.
I won’t go into too much detail about it either as there’s plenty to be found about it. Let’s see if there’s a Rich man’s solution…
Rich man’s solution: Network Isolation, a.k.a. Private in the cloud
For a solid second layer-of-defense we will 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 could look like this:
Characteristics:
- For IaaS services (such as Kubernetes and Virtual Machines) nothing will change. As we have already seen, these are always deployed into 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, so that the App Service is fully plotted in the VNet and cannot be reached from public internet. Also, for these follow more details below.
- Through 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 a bit expensive, then it can also be achieved with a site-to-site VPN.
Through these adjustments an extra layers-of-defense has been added.
That hacker from Russia doesn’t stand a chance. The fort is locked! He’s going to set his sights on someone else.
I have already briefly shown that private endpoints and App Service Environment are used. Here, however, it becomes complex: almost every PaaS (and SaaS) service has its own way of network isolation. This entails additional costs for the Azure resources, but also additional complexity that will translate into higher development costs. Hence, this is the Richman’s solution.
Below are the most common PaaS services, with their accompanying solution for network isolation.
Private Endpoints: Storage Services
Applies to:
- Storage Account
- SQL Database (Server)
- Cosmos DB
- MySQL
- PostgreSQL
- 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. A DNS record is also created with exactly the same name/URL as your storage connection string, but then it refers to the private IP address instead of the public IP address. On the storage service, the firewall (for the public IP) is closed.
This ensures that without modifying the application, with the exact same connection string, you still connect to the storage service.
Cost: € 9 /month, on top of the storage service
Private Endpoints are the successor to Service Endpoints. The Service Endpoints are still available and even easier to use, but also more limited in possibilities.
Documentation:
App Service Environment (ASE): App Services and Functions
The App Service Environment is an environment in which multiple App Service Plans (webservers) can be plotted, with the App Services (websites) on it. The big difference is that now the App Services are only accessible from the VNet and have access to on-premises data sources.
If you are normally used to an App Service Plan having a SKU of Free, Basic or Standard, then it has an SKU from Isolated (I1, I2, I3) on the App Service Environment.
Cost: €+/- 950/month per App Service Environment v2, on top of the I1, I2, I3 App Service Plan costs.
A big disadvantage of the current ASE (v2) is that it has fixed (stamp) costs of about € 950 /month, and on top of that the costs for the App Service Plans (for example for I1 that is € 184 / month). But there’s hope, as recently a new version of the ASE has been released that’s free of charge. See App Service Environment v3 (and Isolated v2Plan). You do not pay the fixed stamp costs of € 950 /month, but only the AppService Plans (I1v2, I2v2, I3v2), although the cheapest variant I1v2 is already € 350 / month.
Documentation:
It can also be done differently
If you think that App Services can also be linked to a VNet without an App Service Environment, then that is correct. However, you need to use the folllowing two concepts:
- Access from VNet to App Service: Private Endpoint (Requires Premium App Service Plan)
- Access from app service to VNet: VNet integration
Documentation:
On-premises Data Gateway: 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 obvious that these should also be able to access on-premises data sources and Azure data sources, in a secure way.
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 done in Azure, but also on-premises.
Cost: Only the cost of the VM
Documentation:
Integrated Service Environment (ISE): Logic apps
With the previous “Data Gateway” solution for a Logic App, the compute is still running on a public-internet node. To ensure that not only the data access, but also the compute is shielded, you can use an Integrated Service Environment (ISE).
The ISE is similar to the ASE, but specific to Logic Apps. Various compute and storage resources are deployed that are managed by Microsoft.
Cost:
- Developer: € +/- 750 /month
- Premium: € +/- 6.600 /month
Documentation:
Hybrid Runbook Worker: 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 done on Azure, but also on-premises.
Cost: Only the cost of the VM
Documentation:
Integration Runtime (IR): Azure Data Factory (ADF)
Azure Data Factory is an ETL (Extract, Transform, Load) tool to copy and transform data. This is the successor of SSIS (SQL Server Integration Services). Also, with this service it is obvious that he must have access to on-premises data-sources 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 must be installed on a Virtual Machine (Windows). This could be done in Azure, but also on-premises.
Cost: The cost of the VM + use of ADF
Constraint:
- Can only copy data (data-copy), not transform (data-flow)!
Documentation:
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 you, in which the IR is created, but you do not have access to this network yourself. You can then create Private Endpoints towards Azure storage services, and thus create network isolation.
Cost: +/- 2x as much as the regular Azure Integration Runtime.
Constraint:
- Can connect with Azure storage services, but not with on-premises data sources.
Documentation:
Safeguard
With the help of network isolation, it is possible to completely shield a solution from public internet. However, when being careless, it can just happen that a firewall is opened or a VM is provided with a public IP address.
If you take care of making a solution secure, also look at safeguards to keep it like that. This could be done with Azure policy, which for example blocks the deployment of a VM with a public IP, and that a storage account always has the firewall on.
Conclusion
You must provide multiple layers-of-defense in the public cloud yourself. The first will be authentication and authorization. The second will be at the network level. This can be done (as Poor man’s solution) with IP whitelisting, or (as Rich man’s solution) with network isolation a.k.a. Private in the public cloud.
Depending on the Azure service, the solution for network isolation is very different. Below is a short summary:
With an advanced network isolation solution, you need to have safeguards against misconfiguration. You can do that with Azure Policies.
Disclaimer
The Russian hacker used is a metaphor for a malicious earthling and can be of any other nationality.
My name is Marco Vervoort.
I’m an Azure solution architect and .NET developer from Team Rockstars IT. Feel free to contact me when you have questions about this article.
