Une subtile limite de conception dans l’implémentation des points de terminaison privés de Microsoft Azure crée un risque inattendu de déni de service (DoS) pour les environnements cloud qui dépendent fortement de Private Link pour assurer une connectivité sécurisée.
Le comportement du DNS Azure avec les points de terminaison privés et les zones DNS privées répartis sur plusieurs réseaux virtuels (VNET) peut interrompre la résolution des noms et provoquer des pannes, même lorsque le service et son point de terminaison public fonctionnent toujours.
La faille « … pourrait exposer les ressources Azure à des attaques par déni de service (DoS) », ont indiqué les chercheurs de l’Unit 42 de Palo Alto Networks.
Le problème du DNS des points de terminaison privés Azure
Au cœur de ce problème se trouve la manière dont Azure donne la priorité à la résolution DNS dès qu’une zone DNS privée est liée à un réseau virtuel.
Les points de terminaison privés sont conçus pour maintenir le trafic hors de l’Internet public en attribuant une adresse IP privée à un service Azure et en acheminant l’accès via le backbone d’Azure.
Pour assurer ce fonctionnement de manière transparente, Azure s’appuie sur des zones DNS privées — telles que privatelink[.]blob[.]core[.]windows[.]net — afin de traduire le nom d’hôte d’un service en l’adresse privée appropriée.
Dans un déploiement standard, cette zone DNS contient les enregistrements requis (généralement des enregistrements A), afin que les charges de travail du réseau connecté résolvent le nom du service vers l’adresse IP du point de terminaison privé plutôt que vers le point de terminaison public.
Le problème commence lorsque la même zone DNS privée est étendue à plusieurs VNET, notamment dans les environnements en étoile ou segmentés où tous les réseaux ne disposent pas de la même couverture en points de terminaison privés.
Le schéma de défaillance se présente généralement comme suit :
- Un point de terminaison privé est créé dans VNET2, et Azure génère ou utilise une zone DNS privée associée à ce point de terminaison.
- La zone DNS privée est ensuite liée à VNET1 pour permettre la résolution des noms entre les réseaux.
- Mais VNET1 ne possède pas d’enregistrement DNS A correspondant au compte de stockage cible (ou à un autre service).
Une fois cette liaison établie, le DNS Azure de VNET1 privilégie la zone DNS privée pour résoudre ce nom d’hôte.
Si l’enregistrement n’existe pas, la recherche peut échouer avec une réponse de type NXDOMAIN, ce qui signifie que le nom ne peut pas être résolu.
Il en résulte une situation de déni de service (DoS) dans laquelle les charges de travail de VNET1 perdent soudainement l’accès — alors même que la ressource Azure sous-jacente est toujours opérationnelle, que le point de terminaison public n’a pas changé et qu’aucune règle de pare-feu n’a été modifiée.
C’est ce qui rend ce problème particulièrement perturbant : la panne est entièrement causée par le comportement du DNS, et non par un attaquant qui mettrait la ressource hors service ou modifierait les paramètres de production du service lui-même.
Une simple modification des liaisons VNET ou des relations entre zones peut interrompre la connectivité entre les environnements en quelques secondes.
Les chercheurs ont constaté que cette faiblesse se manifeste généralement dans trois scénarios concrets :
- Mauvaise configuration interne accidentelle : au fil du temps, les équipes étendent la couverture des points de terminaison privés et introduisent involontairement des conflits DNS en liant des zones entre plusieurs réseaux.
- Déploiements de tiers : les fournisseurs de solutions de sécurité ou les services gérés peuvent déployer des points de terminaison privés à des fins d’analyse, de surveillance ou d’intégration, modifiant involontairement le comportement du DNS et perturbant les flux de trafic de production.
- Activité malveillante d’un initié ou d’un administrateur compromis : un attaquant disposant de suffisamment d’autorisations Azure pourrait détourner les liaisons entre les points de terminaison privés et les zones DNS pour bloquer intentionnellement l’accès — provoquant un déni de service sans avoir besoin d’inonder le trafic ou d’exploiter directement la ressource ciblée.
L’impact peut se propager au-delà d’une seule panne, car Azure Storage sous-tend de nombreux services, notamment Azure Functions, les pipelines CI/CD et les applications qui dépendent des blobs pour leur configuration et leur état.
Si des défaillances DNS bloquent l’accès au stockage, les pannes peuvent se propager — les fonctions échouent, les déploiements sont interrompus et les systèmes qui dépendent des secrets de Key Vault ou des artefacts de conteneur peuvent tomber en panne.
Atténuer les défaillances DNS des points de terminaison privés Azure
Les organisations ne sont pas obligées de considérer ce risque DNS de Private Link comme inévitable.
Avec une combinaison appropriée de gouvernance DNS, de contrôles d’accès et de surveillance, les équipes peuvent réduire le risque que des échecs de résolution se transforment en pannes.
- Activez le « repli vers Internet » (NxDomainRedirect) sur les liaisons VNET des zones DNS privées pour empêcher les échecs NXDOMAIN d’interrompre la résolution, tout en évaluant le compromis de sécurité lié à l’autorisation d’un repli vers le point de terminaison public.
- Conservez des enregistrements A DNS privés complets et exacts pour toutes les ressources compatibles avec Private Link sur les réseaux liés, afin d’éviter les lacunes de résolution susceptibles de provoquer des pannes.
- Centralisez et standardisez la résolution des noms des points de terminaison privés à l’aide d’Azure Private Resolver ou de serveurs DNS personnalisés avec une redirection conditionnelle pour les zones privatelink.* dans les environnements multiréseaux VNET et hybrides.
- Limitez les personnes autorisées à créer des points de terminaison privés ou à modifier les zones DNS privées en appliquant le contrôle d’accès en fonction des rôles (RBAC) selon le principe du moindre privilège, et ajoutez un contrôle des changements pour les mises à jour de la configuration DNS et de Private Link.
- Réduisez le rayon d’impact en limitant les liaisons des zones DNS privées aux seuls VNET qui en ont besoin et en séparant les zones DNS par environnement ou par charge de travail lorsque cela est pertinent.
- En continu, auditez et surveillez les modifications des points de terminaison privés et du DNS privé à l’aide d’Azure Policy, de requêtes Resource Graph et d’alertes signalant les modifications risquées des liaisons ou les pics de réponses NXDOMAIN.
Collectivement, ces contrôles aident les organisations à sécuriser leurs déploiements Private Link tout en réduisant le risque de pannes provoquées par le DNS.
Private Link peut provoquer des défaillances de type déni de service
Ce problème rappelle que les contrôles de sécurité cloud peuvent introduire des risques pour la disponibilité lorsqu’ils ne s’accompagnent pas d’une conception et d’une gouvernance DNS rigoureuses.
Azure Private Link réduit l’exposition publique, mais son comportement DNS « tout ou rien » signifie qu’un enregistrement manquant ou une liaison de zone trop large peut provoquer des pannes de type déni de service.
C’est cet équilibre entre une isolation renforcée et une résilience opérationnelle qui pousse les organisations à se tourner vers des solutions zero trust qui protègent les accès sans s’appuyer uniquement sur des hypothèses au niveau du réseau.