Azure Private Endpoint : construire une matrice de validation avant la mise en production

Un Private Endpoint Azure est souvent validé trop vite. Le service répond depuis une machine de test, le portail montre une interface réseau privée, et l’équipe considère que la mise en production peut continuer. En environnement réel, ce niveau de contrôle ne suffit pas. Le chemin privé dépend du DNS, du réseau source, des zones privées, des liens VNet, des règles de firewall applicatif, du plan de service et parfois d’un agent de déploiement qui utilise encore un chemin public.

Le scénario pris ici est volontairement courant : une application interne utilise plusieurs services PaaS Azure, par exemple Storage, Key Vault et une Azure Function. Les workloads sont dans un spoke Azure, les administrateurs peuvent venir d’un réseau on premises, et les noms doivent rester standards. L’objectif n’est pas de prouver une seule requête réussie. L’objectif est de construire une matrice qui dit clairement depuis quelle source chaque nom doit résoudre, quel chemin réseau est attendu et quel échec est normal.

Commencer par les flux, pas par les objets

Avant de créer ou de fermer quoi que ce soit, il faut décrire les flux applicatifs. Un Private Endpoint ne rend pas toute l’application privée. Il rend privé l’accès à un sous-ressource précis d’un service. Une Function peut avoir un endpoint HTTP privé tout en dépendant d’un Storage Account, d’un Key Vault ou d’un registre d’artefacts qui restent à traiter séparément.

Application interne
Lit des secrets dans Key Vault
Ecrit des fichiers dans Storage
Expose une API HTTP via Azure Function

Chemins attendus
Workload Azure -> Key Vault via Private Endpoint
Workload Azure -> Storage blob via Private Endpoint
Client interne -> Function via nom public résolu en privé
On premises -> zones privatelink via DNS hybride

Chemins non attendus
Accès direct par IP privée
Fichier hosts pour corriger un test
Accès public laissé actif sans raison documentée

Cette étape évite de confondre réussite technique et design exploitable. Si l’application appelle vault.azure.net, le test doit porter sur ce nom. Si l’équipe utilise un nom interne comme api.internal.example.com, il faut savoir s’il pointe vers un service applicatif, vers APIM, vers Application Gateway ou vers un alias qui finit sur un Private Endpoint.

Construire une matrice source, nom, résultat

La matrice de validation doit couvrir les sources réelles. Une VM de test placée dans le bon subnet ne représente pas forcément un pod, une Function avec intégration VNet, un poste d’administration on premises ou un agent CI. Chaque source peut utiliser un résolveur DNS différent, une route différente et des règles différentes.

Source                         Nom testé                         Résultat attendu
vm-spoke-app                    myvault.vault.azure.net            IP du Private Endpoint Key Vault
vm-spoke-app                    mystorage.blob.core.windows.net     IP du Private Endpoint Storage
agent-deploy                    func-app.azurewebsites.net          IP privée ou échec documenté
poste-onprem                    myvault.vault.azure.net             IP privée via forwarder hybride
poste-internet                  myvault.vault.azure.net             Refus réseau ou accès public désactivé
vm-spoke-non-autorise           mystorage.blob.core.windows.net     Résolution possible, accès refusé par contrôle service

La résolution privée n’est pas toujours suffisante pour autoriser l’accès. Elle prouve seulement que le nom pointe vers une interface privée depuis la source testée. Le service doit encore appliquer ses propres règles : identité managée, firewall, ACL, SAS, RBAC, secret applicatif ou certificat client selon le cas.

Séparer DNS, transport et autorisation

Une erreur fréquente consiste à analyser un 403, un timeout ou un problème TLS comme un même incident réseau. La matrice doit séparer trois couches.

Le DNS répond à la question : le nom résout-il vers l’adresse attendue depuis la source attendue ? Le transport répond à la question : la source peut-elle ouvrir une connexion vers cette adresse et ce port ? L’autorisation répond à la question : le service accepte-t-il cette identité, ce secret ou cette requête ?

nslookup myvault.vault.azure.net
nslookup myvault.privatelink.vaultcore.azure.net

curl -vk https://myvault.vault.azure.net/

az keyvault secret show --vault-name myvault --name app-secret --query id -o tsv

Un 403 peut être un bon signe si le chemin privé fonctionne mais que l’identité n’est pas autorisée. Un timeout peut indiquer une route, un NSG, un firewall ou un service qui n’écoute pas. Un certificat invalide apparaît souvent quand un test contourne le hostname normal et utilise une adresse IP privée. Ces différences doivent être écrites dans le runbook, sinon chaque incident repart de zéro.

Ne fermer l’accès public qu’après preuve du chemin privé

La fermeture de l’accès public est une étape de sécurité, mais elle peut rendre le diagnostic confus si elle arrive trop tôt. La bonne séquence consiste à créer le Private Endpoint, vérifier la résolution privée depuis les sources prévues, vérifier l’accès applicatif, puis seulement désactiver l’accès public lorsque les dépendances de déploiement et d’exploitation sont comprises.

Pour une Function, il faut notamment penser à SCM si le déploiement passe encore par l’endpoint de build. Pour Storage, il faut vérifier les sous-ressources réellement utilisées : blob, file, queue ou table. Pour Key Vault, il faut vérifier les agents qui récupèrent les secrets pendant le déploiement. Un design qui protège l’exécution mais casse la livraison applicative n’est pas encore prêt.

Garder des preuves exploitables

La validation ne doit pas rester dans l’historique d’un terminal. Elle doit produire une preuve que l’équipe pourra relire : date, source du test, nom testé, adresse obtenue, statut HTTP ou résultat CLI, compte ou identité utilisé, et décision associée.

Validation Private Endpoint
Date : 2026-05-15
Source : vm-spoke-app-01
Resolver : DNS Azure via hub
Nom : myvault.vault.azure.net
Résolution : 10.42.20.7
Résultat transport : HTTPS joignable
Résultat applicatif : secret lu avec identité managée app-prod
Décision : chemin privé validé, accès public peut être fermé

Ce format est simple, mais il change la qualité de l’exploitation. Il devient possible de comparer deux environnements, de rejouer les contrôles après un changement DNS ou de prouver qu’un incident vient d’une autorisation et non d’un Private Endpoint.

Conclusion

Un Private Endpoint prêt pour la production n’est pas seulement une interface réseau privée créée dans Azure. C’est un ensemble de noms, de routes, de zones DNS, de règles de service et de contrôles applicatifs qui doivent rester lisibles. La matrice de validation sert à éviter les faux positifs : une requête réussie depuis la bonne VM ne prouve pas que tous les chemins utiles sont maîtrisés.

La base saine est concrète : une liste des flux, une matrice par source, des tests DNS et applicatifs séparés, une fermeture progressive de l’accès public et des preuves conservées. Avec cette discipline, Private Endpoint devient un mécanisme d’architecture exploitable, pas seulement une case cochée dans un design privé.