Service Endpoint versus Private Link

Introduction

Les services proposés sur la plateforme Cloud Azure évoluent en permanence pour répondre aux besoins des consommateurs. Les consommateurs ayant adopté la plateforme Cloud Azure veulent aujourd’hui mieux contrôler comment sont exposées leurs ressources, entre autres les services de type PaaS. Ces services ont été conçus avec un Endpoint public. Pour répondre à cette exigence, Microsoft a commencé par intégrer une solution de type « Firewall » au sein de ses services PaaS pour limiter l’exposition des ressources sur Internet. En parallèle, Microsoft propose depuis peu de nouvelles approches pour sécuriser nos ressources avec les services suivants :

• Service Endpoint / Service Endpoint Policy
• Private Link Endpoint

Une comparaison rapide des deux approches pourrait nous faire penser que les deux services sont équivalents. Or, il y a de vraies différences entre les deux, c’est ce que je vous propose de voir dans cet article.

The Big Picture

Quand on regarde Service Endpoint + Service Endpoint Policy et Private Link Endpoint d’un point de vue high-level, les deux services semblent identiques. La principale subtilité tient au fait que Service Endpoint permet de consommer la ressource en utilisant son « Endpoint publique » en le privatisant (seuls les sous-réseaux associés au Virtual Network peuvent y accéder). Private Link EndPoint prend lui une autre direction en permettant de consommer ce même service en créant un « Endpoint privé » qui prend la forme d’une interface réseau connectée à un sous-réseau de votre Virtual Network.

Présentation de Service Endpoint / Service Endpoint Policy

Pour comparer les deux services il faut comprendre que Service Endpoint agit comme un filtre qui va autoriser l’accès à un ou plusieurs de ces services pour un sous-réseau au sein d’un Virtual Network :

• Azure Storage
• Azure SQL Database
• Azure SQL Data Warehouse
• Azure Database for PostgreSQL server
• Azure Database for MySQL server
• Azure Database for MariaDB
• Azure Cosmos DB
• Azure Key Vault
• Azure Service Bus
• Azure Data Lake Store
• Azure Events Hubs
• Azure App Service

Conséquence, activer un Service Endpoint sur un sous-réseau permet de consommer toutes les instances de ces services, que celles-ci dépendent de ma souscription ou d’une autre appartenant à un autre consommateur Azure. C’est à ce niveau que Service Endpoint Policy intervient pour nous permettre de limiter les ressources qui seront exposées. Ce filtrage n’est disponible que pour les ressources « Storage Accounts » selon trois niveaux de granularités :

• Tous les « Storage Accounts » d’une souscription donnée
• Tous les « Storage Accounts » au sein d’un groupe de ressources donné au sein d’une souscription
• Un / plusieurs « Storage Account » dépendant d’une souscription donnée

Ce point posé, on comprend que Service Endpoint autorise l’accès à toutes les ressources et qu’on doit nécessairement utiliser Service Endpoint Policy pour restreindre les instances du service qui seront consommées. Point intéressant, tout Storage Account non référencé sera automatiquement inaccessible. Cela permet d’adresser des exigences tel que le risque d’exfiltration de données en utilisant des Storage Accounts d’une autre souscription. Cependant, cela implique de déclarer tous les Storage Accounts que nous devrons consommer depuis le sous-réseau.

On ne peut appliquer cette restriction que pour les ressources de type « Storage Account ». Appliqués à un sous-réseau au sein de votre « Virtual Network », « Service Endpoint » / « Service Endpoint Policy » vont nous permettre de limiter à quels « Storage Accounts » nos consommateurs Azure et « On-Premises » peuvent accéder.

Appliqué à un contexte Datalake, Service Endpoint / Service Endpoint Policy présente certains avantages. Dans la souscription « Spoke Subscription A », nous avons un Datalake qui a été sécurisé avec Service Endpoint / Service Endpoint Policy, uniquement accessible depuis le sous-réseau ou depuis les réseaux « On-Premises » auxquels le Virtual Network pourrait être raccordé. Dans la souscription « Spoke Subscription B », nous avons une autre équipe qui nécessite d’accéder au Datalake mais uniquement pour alimenter celui-ci, jouant le rôle de « Feeder ». Avec cette approche, les « Feeders » peuvent alimenter le « Storage Account » sans pour autant avoir de permissions sur les ressources dépendantes de la souscription « Spoke Subscription A ».

Avant l’introduction de Service Endpoint / Service Endpoint Policy, la seule alternative pour produire ce scénario impliquait la mise en place d’une Microsoft Virtual Applicance, ou une instance du Service Azure Firewall hébergée dans une souscription de type « Hub ». Ce service était chargé de gérer les flux réseaux entre les deux souscriptions. Techniquement, ce type d’infrastructure fonctionne mais économiquement, c’est une autre histoire car pour alimenter le Datalake, les « Feeders » doivent nécessairement passer par la souscription Hub ce qui engendre des coûts de bande passante au niveau Peerings et Azure Firewall. Or, dans un contexte Datalake, le volume de données sera nécessairement très important.

Présentation de Private Endpoint

Private Endpoint se présente comme une interface réseau que nous connectons à un sous-réseau au sein de notre Virtual Network. Cette interface sera le point d’accès privé à des ressources Azure telles que :

• Azure SQL Database
• Azure Synapse Analytics
• Azure Storage
• Azure Datalake Storage Gen2
• Azure Cosmos DB
• Azure Database for PostgreSQL -Single server
• Azure Database for MySQL
• Azure Database for MariaDB
• Azure Key Vault
• Azure Synapse Analytics
• Azure Kubernetes Services
• Azure Container Registry (Preview)
• Azure App Services (Preview)
• Azure Cognitive Search (Preview)
• Azure Event Hubs (Preview)
• Azure Service Bus (Preview)
• Azure Relay (Preview)
• Azure Backup (Preview)
• Azure Event Grid (Topic & Domain) (Preview)

Notre ressource disposera donc de deux points Endpoints :

• Le « Public Endpoint »
• Le « Private Endpoint »

C’est au moment de la création de la ressource que l’on va sélectionner de créer / utiliser un Private Endpoint.

Pour certaines ressources comme « Storage Account », il est même possible de spécifier quel service sera exposé, ce que « Service EndPoint Policy » ne permet pas.

L’établissement d’un lien entre le « Private Endpoint » et la ressources Azure passe par un processus d’approbation au niveau de la ressource qui peut être manuelle ou automatique comme illustré ci-dessous :

D’un point de vue sécurité, cela pose un problème car il est tout à fait possible de se retrouver à devoir accepter / refuser une demande pour un « Private Endpoint » qui se trouve dans une souscription distincte qui dépend d’un Tenant Azure AD qui n’est pas le nôtre. Si le propriétaire de la ressource venait à approuver cette demande, il exposait sa ressource à l’extérieur en dehors de tout contrôle de flux réseau. Il faudra être vigilant sur ce point. Heureusement on peut maîtriser qui peut approuver les demandes (Permission RBAC).

Un élément différenciateur de Privale Link Service est son intégration avec Azure DNS Private Zone. Dès lors la connexion approuvée, toute tentative de résolution DNS du Endpoint publique conduit à la résolution du nom DNS de notre Private Link Endpoint avec son adresse IP privée (CNAME) comme illustré ci-dessous :

Avec Private Link Endpoint, le scénario de l’exfiltration de données est adressé en privatisant la ressources. Il reste effectivement un Endpoint public mais celui-ci renvoie invariablement vers le Endpoint privé qui n’est accessible que depuis les réseaux Azure / On-Premises sécurisés.

Grille d’analyse

Conclusion

Les deux services se ressemblent beaucoup. De mon point de vue, Microsoft a proposé une première solution avec Service Endpoint / Service Endpoint Policy mais n’a réellement développé que le use-case « Storage » pour permettre le scénario « Datalake Feeder ». La solution Service Endpoint présente l’avantage d’être gratuite. La solution Private Link Endpoint représente la solution d’avenir. Prenant en charge beaucoup plus de ressources Azure voire même les services que nous développons pour les exposer directement dans les souscriptions de nos consommateurs. A terme, Microsoft vise à supprimer les Endpoints publics de ses ressources. Quel que soit la solution retenue, une révision de la segmentation réseau sera nécessaire avant de mettre en œuvre l’une ou l’autre solution.