Ne pas confondre exposition privée, sortie réseau et sécurité applicative sur Azure

Dans beaucoup de conceptions Azure, le mot privé finit par désigner plusieurs choses différentes. Une application n’est plus exposée sur Internet. Une Function peut sortir vers un réseau interne. Un backend répond via Private Endpoint. Un flux passe par Application Gateway. Un service vérifie une identité managée. Chaque élément améliore quelque chose, mais aucun ne couvre tout le modèle.

Cette confusion produit des designs difficiles à expliquer. Une équipe pense avoir rendu une application privée parce qu’elle a activé l’intégration VNet. Une autre pense que Private Endpoint remplace l’authentification du backend. Une troisième publie une application derrière Application Gateway sans clarifier le chemin TLS vers le serveur. Le problème n’est pas l’outil Azure choisi. Le problème est de ne pas séparer les responsabilités.

Trois questions différentes

Une architecture privée doit répondre à trois questions séparées.

La première est l’exposition entrante : qui peut appeler le service ? La deuxième est la sortie réseau : vers quelles ressources l’application peut-elle initier des connexions ? La troisième est la sécurité applicative : quelle identité, quel secret, quel certificat ou quelle règle métier autorise réellement l’action ?

Exposition entrante
Private Endpoint
Application Gateway
API Management interne
Load Balancer interne

Sortie réseau
VNet Integration App Service ou Function
Routes et UDR
NAT Gateway
DNS utilisé par l'application

Sécurité applicative
Microsoft Entra ID
Identité managée
Certificat client
Secret applicatif
RBAC, ACL ou logique métier

La valeur de cette carte est simple : elle empêche de demander à un composant de résoudre un problème qui n’est pas le sien. VNet Integration n’expose pas une application en privé. Private Endpoint ne donne pas à l’application le droit de lire un secret. Application Gateway ne remplace pas l’autorisation du backend.

VNet Integration n’est pas une exposition privée

Pour App Service et Azure Functions, l’intégration VNet sert d’abord à la sortie. Elle permet à l’application d’initier des connexions vers un réseau privé : base de données, API interne, Key Vault, Storage, serveur DNS ou service on premises. Elle ne signifie pas que les clients appellent l’application via une adresse privée.

Si l’objectif est de rendre l’entrée privée, il faut traiter l’exposition entrante : Private Endpoint sur l’application, APIM interne, Application Gateway interne ou autre frontal selon le besoin. Les deux sujets peuvent coexister, mais ils ne sont pas interchangeables.

Besoin : l'application appelle une API interne
Utiliser VNet Integration
Vérifier routes, DNS, NSG et identité applicative

Besoin : les clients appellent l'application sans Internet
Utiliser Private Endpoint ou frontal interne
Vérifier DNS privé, accès public, TLS et contrôle applicatif

Besoin : gouverner une API interne
Utiliser APIM interne si politiques API nécessaires
Vérifier backend privé et authentification backend

Cette distinction est utile dès la conception, mais elle devient critique en diagnostic. Si un client public atteint encore l’application, ce n’est pas l’intégration VNet qu’il faut regarder en premier. Si l’application ne joint pas une base interne, ce n’est pas le Private Endpoint entrant qui explique le problème.

Private Endpoint ferme un chemin, pas tous les risques

Private Endpoint déplace l’accès réseau à un service PaaS dans un réseau privé. C’est un contrôle fort pour réduire l’exposition, mais il ne remplace pas la sécurité du service. Un Storage Account joint par Private Endpoint doit encore être protégé par RBAC, clés, SAS ou politiques adaptées. Un Key Vault doit encore vérifier l’identité. Une Function privée doit encore contrôler qui peut appeler son endpoint.

Un bon test doit donc prouver deux choses. D’abord, le nom se résout vers l’adresse privée depuis la source attendue. Ensuite, l’action applicative réussit seulement avec l’identité attendue. Un test anonyme qui reçoit un 403 n’est pas forcément un échec. Il peut prouver que le chemin réseau existe et que l’autorisation fait son travail.

Application Gateway et API Management ne servent pas le même besoin

Application Gateway est souvent pertinent pour publier proprement une application HTTP ou HTTPS avec listeners, certificats, probes, WAF et routage vers des backends. API Management devient pertinent quand le besoin est API : politiques, produits, subscriptions, transformation, quotas, versions, portail développeur ou gouvernance d’appels.

Il est possible d’utiliser les deux, mais le design doit dire pourquoi. Ajouter APIM uniquement pour faire un reverse proxy crée parfois plus de complexité que de contrôle. Utiliser Application Gateway pour un besoin de cycle de vie API peut aussi devenir limité. Le bon choix dépend du rôle attendu dans le flux.

Application Gateway est naturel quand
Le sujet principal est la publication HTTPS d'une application
Le WAF, les probes et les listeners sont les contrôles centraux
Le backend est une application web ou un reverse proxy

API Management est naturel quand
Le sujet principal est la gouvernance API
Les politiques, quotas, produits ou transformations sont nécessaires
Le consommateur doit être identifié comme client API

La bonne documentation est une matrice de responsabilités

Pour éviter les malentendus, la note d’architecture doit contenir une matrice simple. Chaque composant y est associé à ce qu’il garantit, ce qu’il ne garantit pas et comment on le vérifie. Cette matrice vaut souvent mieux qu’un grand schéma réseau où toutes les flèches finissent par se ressembler.

Composant              Garantit                         Ne garantit pas
Private Endpoint       Chemin réseau privé vers PaaS      Autorisation applicative
VNet Integration       Sortie privée de l'application     Entrée privée depuis les clients
Application Gateway    Publication HTTP contrôlée         Gouvernance complète d'API
APIM interne           Point d'entrée API privé           Sécurité backend automatique
DNS privé              Nom vers adresse attendue          Droit d'accès au service

Cette table devient aussi un support de revue. Quand une exception est demandée, l’équipe peut identifier le contrôle touché. Quand un incident arrive, elle sait quelle couche tester en premier.

Conclusion

Une architecture Azure privée fiable commence par des limites claires. Il faut séparer l’entrée, la sortie et l’autorisation. Il faut accepter que le réseau ne remplace pas l’identité, que le DNS ne remplace pas le routage, et qu’un frontal ne remplace pas une décision applicative.

La bonne question n’est donc pas seulement : le service est-il privé ? La question utile est : quel chemin est privé, depuis quelle source, vers quel nom, avec quelle identité, et quel contrôle prouve que l’action est autorisée ? C’est cette précision qui transforme un design Azure en architecture exploitable.