En terme de sécurité, l’une des bonnes pratiques pour réduire la surface d’attaque d’un service, est d’éviter d’exposer ce dernier sur Internet.
Cela vaut évidemment aussi pour les services PaaS déployés sur Azure, c’est pour cela qu’Azure propose différentes solutions pour y parvenir.
Aujourd’hui nous allons voir l’une d’entre elles, avec le Service Endpoint qui est une fonctionnalité permettant de consommer des services via le réseau interne de Azure, qu’on appelle aussi backbone Azure.
Avant de rentrer dans le vif du sujet, il est important de rappeler que dans la majorité des cas, lorsque vous déployer un nouveau service PaaS sur Azure, ce dernier est exposé sur Internet.
C’est volontaire de la part de Microsoft, afin que ce nouveau service puisse être rapidement accessible pour d’autres services, qu’ils soient hébergés, sur Azure, sur un environnement On-Premise, ou bien chez un autre fournisseur Cloud.
Afin de vous expliquer comment fonctionne Service Endpoint, nous allons déployer les éléments suivants sur Azure :
- Un Compte de Stockage – SA (Service PaaS qui sera pris comme exemple)
- Une Virtual Machine – VM
- Un disque dur – Disk
- Une interface réseau – NIC
- Un groupe de sécurité – NSG
- Un réseau virtuel – VNET
- Un subnet
- Une adresse IP publique
Mise en pratique
Pour notre cas d’usage, nous souhaitons que notre VM que nous avons précédemment déployé, puisse consommer des données stockées dans notre SA.
Nous allons voir quelles sont les possibilités, avec et sans la fonctionnalité Service Endpoint.
Service PaaS exposé sur Internet
Pour notre premier exemple, notre Compte de Stockage n’aura aucune limitation, et sera donc exposé sur Internet.
(Ce n’est évidemment pas à reproduire pour des raisons évidentes de sécurité, mais cela permet de mieux comprendre le mécanisme de Service Endpoint).
Voici un petit schéma qui explique comment notre SA va être consommé par notre VM, et potentiellement par d’autres services ou utilisateurs externes :
On peut voir, que lorsque notre VM sort sur Internet pour ensuite venir consommer notre SA via son DNS publique, dans notre cas https://demo736.blob.core.windows.net/
C’est donc un premier enseignement, lorsque une VM souhaite consommer un service déployé sur Azure, par défaut, le flux réseau sort sur Internet avant de venir consommer le service sur son point de terminaison publique.
Sachant que dans notre cas d’usage, seule notre VM, doit consommer notre SA, nous n’avons aucun intérêt à exposer notre SA sur Internet. Nous allons donc ajouter des restrictions au niveau du Firewall du SA.
Activation du Firewall sur le service PaaS
Comme nous l’avons vu dans notre exemple précédent, le SA était exposé sur Internet, en autorisant tout le trafic provenant d’Internet.
Afin de limiter l’accès uniquement à notre VM, dans la configuration Firewall du SA, nous allons autoriser uniquement sa adresse IP publique
Regardons à nouveau notre schéma :
Nous voyons maintenant que le trafic provenant d’Internet est bloqué et que seule l’adresse IP publique de notre VM est autorisée à se connecter au SA.
En terme de sécurité, c’est mieux, mais nous pouvons encore aller plus loin grâce au Service Endpoint.
Activation du Service Endpoint
La mise en place du Service Endpoint est très simple à réaliser. Elle s’effectue en deux étapes :
- La première, en sélectionnant le service que l’on souhaite consommé, au niveau du subnet dans lequel est déployée notre VM. Dans notre exemple, comme nous souhaitons consommer notre SA, le nom du service sera Microsoft.Storage. Après sélection, on voit le statut qui passe en New.
- La seconde, en ajoutant le subnet dans lequel est déployée notre VM au niveau du Firewall de notre SA. Nous en avons également profité pour supprimer l’adresse IP publique de notre VM qui n’est plus utile.
Un nouveau coup d’oeil sur notre schéma :
Nous constatons maintenant que le flux réseau de la VM, ne passe plus part Internet, mais directement via le réseau interne de Azure, ou backbone Azure.
Et bien évidemment, le trafic Internet est toujours bloqué.
Mais comment cela fonctionne t’il concrètement ?
En fait lorsqu’on active le Service Endpoint au niveau d’un subnet, les ressources qui sont déployées au sein de celui-ci, se voient attribuer de nouvelles routes qui vont diriger le flux réseau vers les Service Endpoint de Azure.
Voici par exemple les routes associées à notre NIC, et donc à notre VM :
A l’heure où nous écrivons ces quelques lignes, voici la liste des Service Endpoint disponibles dans Azure :
1 . En disposition générale
- Stockage Azure (Microsoft.Storage)
- Azure SQL Database (Microsoft.Sql)
- Azure Synapse Analytics (Microsoft.Sql)
- Serveur Azure Database pour PostgreSQL (Microsoft.Sql)
- Serveur Azure Database pour 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 . En préversion publique
- Azure Container Registry (Microsoft.ContainerRegistry)
Ces informations sont évidemment disponibles sur la documentation officielle de Microsoft.
Pour résumer, Service Endpoint est une excellente parade pour ne pas exposer ses services PaaS sur Internet, mais certains mettent en avant l’un de ces défauts.
En effet utilisant la fonctionnalité Service Endpoint, le trafic n’est pas dirigé directement sur un service (notre SA dans notre exemple), mais vers la catégorie Storage de Azure.
Et bien nous verrons que Microsoft propose une autre fonctionnalité à savoir Private Link, qui permet de consommer directement un services PaaS, en lui attribuant une adresse IP privée directement au sein d’un VNET.
Cela sera le thème d’un prochain post !
