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 :

 

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

 

Grille d’analyse VNET Service Endpoint Policy Private Link EndPoint
Configuration Centralisé sur la configuration du Subnet donc configurable, configurable par Azure Policy. C’est la solution la plus simple. Configurable au niveau de chaque instance à exposer de manière privée. Réalisable mais implique d’avoir un Private Link Endpoint par sous-réseau. C’est plus complexe à mettre en œuvre de manière industrielle.
Sécurité Service Endpoint Policy ne prend en charge que les Storage Accounts. Par construction, les ressources sont exposées publiquement sur Internet. C’est à nous de mettre en œuvre Private Link EndPoint pour disposer d’un Endpoint privé pour lequel nous allons autoriser chaque ressource connectée. Cela implique donc une industrialisation de la mise en œuvre.
Niveau de configuration Sous-réseau au sein d’un Virtual Network Interface Private Link EndPoint.
Filtrage des ressources exposées ·        Storage Accounts d’une souscription

·        Storage Accounts d’un groupe de ressources donné

·        Storage Accounts d’une souscription

L’exposition de la ressource est effective qu’avec approbation du côté de la ressource.
Journalisation NSG Flow Log format V2 mais complexe à exploiter :

https://azure.microsoft.com/en-in/updates/nsgflowlogsversion2/

 

Mise à disposition de metrics

Utilisation de Network Watcher

Méthode d’accès à la ressource Accès à la ressource en utilisant le Endpoint publique

Control Access to PaaS Services over the public internet.

Accès à la ressource en utilisant le Endpoint privé (le nom DNS publique est un CNAME qui désignera le nom DNS du Endpoint privé)
Filtrage de la destination réseau La ressource sera toujours accédée via son adresse IP publique. Le seul moyen de restreindre les ressources sera d’utiliser les Services Tag des NSG pour les ressources autres que « Storage Account ». La ressource sera accédée via son adresse IP privée, à noter qu’actuellement, il n’est pas encore possible de filtrer l’accès au « Private Link EndPoint » via un « Network Security Group ».
Filtrage de la source réseau Plus complexe de filtrer le trafic « On-Premises » sans mettre en place un service tel qu’Azure Firewall. Facilité de prise en charge, aussi bien pour les réseaux « On-Premises » via ExpressRoute ou les service VPN standard.
Pricing

 

Le service est gratuit

 

Avant pour produire le même service, nous devions industrialiser Azure Firewall qui lui n’est pas gratuit.

·        Private Endpoint facturé €0.009 par heure

·        Traffic entrant facturé €0.009 le Gb

·        Traffic sortant facturé €0.009 le Gb

 

Même si Private Endpoint est payant, il reste bien moins cher qu’une instance Azure Firewall dont on devra industrialiser la configuration.

Limitations Actuellement, il n’est pas possible de faire coexister Private Link End Point avec Service Endpoint sur un même sous-réseau au sein d’un Virtual Network. Actuellement, il n’est pas possible de faire coexister Private Link EndPoint avec Service Endpoint sur un même sous-réseau au sein d’un Virtual Network.

Actuellement, Private Link EndPoint est incompatible avec « Network Security Group ».

 

 

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.