In terms of security, one of the best practices for reducing the attack surface of a service is to avoid exposing it to the Internet.
This obviously also applies to PaaS services deployed on Azure, which is why Azure offers different solutions to achieve this.
Today we are going to see one of them, with the Service Endpoint which is a functionality allowing to consume services via the internal network of Azure, also called Azure backbone .
Before getting to the heart of the matter, it is important to remember that in the majority of cases, when you deploy a new PaaS service on Azure, it is by default exposed on the Internet.
This is voluntary on Microsoft's part, so that this new service can be quickly accessible for other services, whether they are hosted on Azure, on an On-Premise environment, or with another Cloud provider.
In order to explain how Service Endpoint works , we will deploy the following components on Azure:
- Storage Account – SA (PaaS Service which will be taken as an example)
- Virtual Machine – VM
- Hard drive – Disk
- Network interface – NIC
- Security group – NSG
- Virtual network – VNET
- Subnet
- Public IP address
Put into practice
For our use case, we want our VM that we have previously deployed to be able to consume data stored in our SA.
We'll see what the possibilities are afford, with and without the Service Endpoint feature .
PAAS SERVICE EXPOSED ON THE INTERNET
For our first example, our Storage Account will have no limitation, and will therefore be exposed on the Internet.
(Obviously this is not to be reproduced for obvious security reasons, but it helps to better understand the Service Endpoint mechanism ).
Here is a small diagram that explains how our SA will be consumed by our VM, and potentially by other services or external users:
We can see that when our VM goes out on the Internet and then comes to consume our SA via its public DNS, in our case https://demo736.blob.core.windows.net/
We have a first lesson. When a VM wishes to consume a service deployed on Azure, by default, the network flow goes out on the Internet before coming to consume the service on its public endpoint.
Knowing that in our use case, only our VM must consume our SA, we have no interest in exposing our SA on the Internet. We are therefore going to add restrictions at the level of the SA Firewall.
ACTIVATION OF THE FIREWALL ON THE PAAS SERVICE
As we saw in our previous example, the SA is exposed to the internet, allowing all traffic from the internet.
In order to limit access only to our VM, in the Firewall configuration of the SA, we will only authorize the public IP address of our VM:
Have a look at our diagram again:
Now we see that traffic from the internet is blocked and only our VM's public IP address is allowed to connect to the SA.
In terms of security, it's better, but we can go even further with to the Service Endpoint.
ENABLING THE SERVICE ENDPOINT
Setting up the Endpoint Service is very easy to do. It is done in two steps:
- The first, by selecting the service that we want to consume, at the level of the subnet in which our VM is deployed. In our example, as we want to consume our SA, the service name will be Microsoft.Storage . After selection, we see the status which changes to New .
- The second, by adding the subnet in which our VM is deployed at the Firewall level of our SA. We also took the opportunity to remove the public IP address of our VM which is no longer useful.
A new look at our diagram:
We now see that the VM's network flow no longer goes through the Internet, but directly via Azure's internal network (Azure backbone).
And of course, Internet traffic is still blocked.
But how does it work in practice?
In fact, when you activate the Service Endpoint at the level of a subnet, the resources that are deployed within it are assigned new routes that will forward the network flow to the Azure Service Endpoint.
For example, here are the routes associated with our NIC, and therefore with our VM:
At the time of writing this post, here is the list of Service Endpoints available in Azure:
1 . In general availability
- Azure Storage (Microsoft.Storage)
- Azure SQL Database (Microsoft.Sql)
- Azure Synapse Analytics (Microsoft.Sql)
- Azure Database Server for PostgreSQL (Microsoft.Sql)
- Azure Database Server for MySQL (Microsoft.Sql)
- Azure Database for MariaDB (Microsoft.Sql)
- Azure Cosmos DB (Microsoft.AzureCosmosDB)
- Azure Key Vault (Microsoft.KeyVault)
- Azure Service Bus (Microsoft.ServiceBus)
- Azure Event Hubs (Microsoft.EventHub)
- Azure Data Lake Store Gen 1 (Microsoft.AzureActiveDirectory)
- Azure App Service (Microsoft.Web)
- Azure Cognitive Services (Microsoft.CognitiveServices)
2 . In public preview
- Azure Container Registry (Microsoft.ContainerRegistry)
This information is obviously available on the official Microsoft documentation .
CONCLUSION
To summarize, Service Endpoint is an excellent solution for not exposing its PaaS services on the Internet, but some point to one of these flaws.
Indeed, using the Service Endpoint feature, the traffic is not directed directly to a service (our SA in our example), but to the Storage category of Azure.
Well, we will see that Microsoft offers another feature, namely Private Link, which allows you to directly consume a PaaS service, by assigning it a private IP address directly within a VNET.
This will be the subject of a future post!