Optimiser le flux de trafic avec Microsoft Entra proxy d’application

Article
02/27/2024

Apprendre comment optimiser le flux du trafic ainsi que la topologie du réseau lors de l’utilisation du proxy d’application Microsoft Entra.

Flux de trafic

Lorsqu’une application est publiée via le proxy d’application Microsoft Entra, le trafic des utilisateurs vers les applications circule via trois connexions :

L’utilisateur se connecte au point de terminaison public du service de Proxy d'application Microsoft Entra sur Azure
Le connecteur de réseau privé se connecte au service proxy d’application (sortant)
Le connecteur de réseau privé se connecte à l’application cible

Optimiser les groupes de connecteurs afin d’utiliser le service cloud de proxy d’application le plus proche

Lorsque vous vous inscrivez pour un locataire Microsoft Entra, la région de votre locataire est appliquée avec la région que vous choisissez. Les instances de service cloud proxy d’application par défaut utilisent la même région ou la région la plus proche de votre locataire Microsoft Entra.

Par exemple, si la région de votre locataire Microsoft Entra est le Royaume-Uni, tous vos connecteurs de réseau privé par défaut sont attribués pour utiliser des instances de service dans des centres de données européens. Lorsque vos utilisateurs accèdent à des applications publiées, leur trafic passe par les instances du service cloud de proxy d’application à cet emplacement.

Si vous avez des connecteurs installés dans des régions différentes de votre région par défaut, il est avantageux de changer la région pour laquelle votre groupe de connecteurs est optimisé afin d’améliorer les performances d’accès à ces applications. Une fois qu’une région est spécifiée pour un groupe de connecteurs, elle se connecte aux services cloud du proxy d’application dans la région désignée.

Afin d’optimiser le flux de trafic et réduire la latence pour un groupe de connecteurs, affectez le groupe de connecteurs à la région la plus proche. Pour affecter une région :

Important

Les connecteurs doivent utiliser au moins la version 1.5.1975.0 pour utiliser cette fonctionnalité.

Connectez-vous au centre d’administration Microsoft Entra en tant qu’administrateur d’applications au moins.
Sélectionnez votre nom d’utilisateur en haut à droite. Vérifiez que vous êtes connecté à un répertoire qui utilise le service Proxy d’application. Si vous devez changer de répertoire, sélectionnez Changer de répertoire et choisissez un répertoire qui utilise le service Proxy d’application.
Accédez à Identité>Applications>Applications d’entreprise>Proxy d’application.
Sélectionnez Nouveau groupe de connecteurs et fournissez-lui un Nom.
Sous Paramètres avancés, sélectionner la liste déroulante sous Optimiser pour une région spécifique et sélectionnez la région la plus proche des connecteurs puis sélectionner Enregistrer.
Sélectionner les connecteurs à affecter au groupe de connecteurs.

Vous ne pouvez déplacer un connecteur vers votre groupe de connecteurs que s’il se trouve dans un groupe de connecteurs avec la région par défaut. Commencez par un connecteur dans le groupe de connecteurs par défaut. Déplacez-le ensuite vers le groupe de connecteurs approprié.

Vous ne pouvez modifier la région d’un groupe de connecteurs que s’il n’y a pas de connecteurs ou d’applications qui lui sont affectés.
Affecter le groupe de connecteurs à vos applications. Le trafic va vers le service cloud du proxy d’application dans la région pour laquelle le groupe de connecteurs est optimisé.

Considérations relatives à la réduction de la latence

Toutes les solutions de proxy ajoutent de la latence à votre connexion réseau. Quel que soit le proxy ou la solution VPN que vous choisissez comme solution d’accès à distance, cela comprend toujours un ensemble de serveurs permettant la connexion à votre réseau d’entreprise.

Les organisations comptent généralement des points de terminaison de serveur dans leur réseau de périmètre. Avec le proxy d’application Microsoft Entra, le trafic passe toutefois par le service de proxy dans le cloud tandis que les connecteurs se trouvent sur votre réseau d’entreprise. Aucun réseau de périmètre n’est requis.

Les sections suivantes contiennent plus de suggestions pour vous aider à réduire encore davantage la latence.

Placement d’un connecteur

Le proxy d’application choisit l’emplacement des instances pour vous, en fonction de l’emplacement de votre locataire. Cependant, vous pouvez décider de l’emplacement auquel installer le connecteur, ce qui vous donne la possibilité de définir les caractéristiques de latence de votre trafic réseau.

Lorsque vous configurez le service de proxy d’application, posez-vous les questions suivantes :

Où se trouve l’application ?
Où se trouvent la plupart des utilisateurs qui accèdent à l’application ?
Où se trouve l’instance de proxy d’application ?
Disposez-vous déjà d’une connexion réseau dédiée vers les centres de données Microsoft comme Azure ExpressRoute ou un VPN similaire ?

Le connecteur doit communiquer avec Microsoft Entra et vos applications. Les étapes 2 et 3 dans le diagramme de flux de trafic représentent la communication. Le positionnement du connecteur affecte la latence de ces deux connexions. Lorsque vous évaluez le placement du connecteur, tenez bien compte de ces facteurs.

Confirmer « ligne de site » entre le connecteur et le centre de données pour la délégation contrainte Kerberos (KCD). En outre, le serveur de connecteur doit être joint à un domaine.
Installer le connecteur aussi près que possible de l’application.

Approche générale pour la réduction de la latence

Réduire la latence du trafic de bout en bout en optimisant chaque connexion réseau.

Réduire la distance entre les deux extrémités du tronçon.
Choisir le réseau approprié à parcourir. Par exemple, parcourir un réseau privé au lieu de l’Internet public peut être plus rapide en raison des liaisons dédiées.

Envisagez d’utiliser un lien VPN ou ExpressRoute dédié entre Microsoft et votre réseau d’entreprise.

Concentrer votre stratégie d’optimisation

Vous avez peu de latitude pour contrôler la connexion entre vos utilisateurs et le service du proxy d’application. Les utilisateurs accèdent à vos applications à partir d’un réseau domestique, d’un café ou d’une autre région. Au lieu de cela, vous pouvez optimiser les connexions entre le service de proxy d’application et les connecteurs de réseau privé vers les applications. Envisagez d’intégrer les modèles suivants dans votre environnement.

Modèle 1 : Placer le connecteur à proximité de l’application

Placez le connecteur près de l’application cible dans le réseau du client. Cette configuration minimise l’étape 3 dans le schéma de topographie, car le connecteur et l’application sont proches.

Si votre connecteur a besoin d’une ligne de vue sur le contrôleur de domaine, ce modèle est avantageux. La plupart de nos clients utilisent ce modèle, car il fonctionne bien pour la majorité des scénarios. Ce modèle peut également être associé au modèle 2 pour optimiser le trafic entre le service et le connecteur.

Modèle 2 : Tirer parti d’ExpressRoute avec peering Microsoft

Si vous avez une installation ExpressRoute avec peering Microsoft, vous pouvez utiliser la connexion ExpressRoute plus rapide pour le trafic entre le proxy d’application et le connecteur. Le connecteur se trouve toujours sur votre réseau, à proximité de l’application.

Modèle 3 : Tirer parti d’ExpressRoute avec le peering privé

Si vous avez une installation VPN ou ExpressRoute dédiée avec le peering privé entre Azure et votre réseau d’entreprise, vous avez une autre option. Dans cette configuration, le réseau virtuel dans Azure est généralement considéré comme une extension du réseau de l’entreprise. Par conséquent, vous pouvez installer le connecteur dans le centre de données Azure tout en répondant aux exigences de faible latence de la connexion connecteur à application.

La latence n’est pas compromise, car le trafic circule sur une connexion dédiée. Vous obtenez également une meilleure latence entre le service de proxy d’application et le connecteur, car le connecteur est installé dans un centre de données Azure proche de l’emplacement de votre locataire Microsoft Entra.

Autres approches

Bien que cet article ait pour objectif le placement du connecteur, vous pouvez également modifier le placement de l’application pour obtenir de meilleures caractéristiques de latence.

De plus en plus d’organisations déplacent leurs réseaux dans des environnements hébergés. Le déplacement leur permet de placer leurs applications dans un environnement hébergé qui fait également partie de leur réseau d’entreprise tout en restant au sein du domaine. Dans ce cas, les modèles décrits dans les sections précédentes peuvent être appliqués au nouvel emplacement de l’application. Si vous envisagez cette option, consultez la page Services de domaine Microsoft Entra.

Envisagez également d’organiser vos connecteurs à l’aide de groupes de connecteurs pour les applications cibles qui se trouvent dans des réseaux et des emplacements différents.

Diagrammes pour les cas d’usage courants

Dans cette section, nous allons étudier quelques scénarios courants. Supposons que le locataire Microsoft Entra (et par conséquent le point de terminaison du service de proxy) se trouve aux États-Unis. Les considérations présentées dans ces cas d’utilisation s’appliquent également à d’autres régions du monde.

Dans ces scénarios, nous appelons chaque connexion un « tronçon » et nous les numérotons dans un souci de simplification :

Tronçon 1 : utilisateur vers le service de proxy d’application
Tronçon 2: service proxy d’application vers le connecteur de réseau privé
Tronçon 3: connecteur de réseau privé à l’application cible

Cas d’utilisation 1

Scénario : l’application se trouve dans un réseau d’entreprise aux États-Unis avec des utilisateurs dans la même région. Aucun ExpressRoute ou VPN n’existe entre le centre de données Azure et le réseau d’entreprise.

Recommandation : suivez le modèle 1, expliqué dans la section précédente. Pour une latence améliorée, envisagez l’utilisation d’ExpressRoute, si nécessaire.

Optimiser le tronçon 3 en plaçant le connecteur à proximité de l’application. Ce connecteur est généralement installé avec la ligne de vue vers l’application et le centre de données pour effectuer des opérations de KCD.

Cas d’utilisation 2

Scénario : l’application se trouve dans un réseau d’entreprise aux États-Unis avec des utilisateurs répartis dans le monde. Aucun ExpressRoute ou VPN n’existe entre le centre de données Azure et le réseau d’entreprise.

Recommandation : suivez le modèle 1, expliqué dans la section précédente.

Là encore, le modèle courant consiste à optimiser le tronçon 3, où vous placez le connecteur à proximité de l’application. Le tronçon 3 n’est généralement pas coûteux, si le tout est contenu dans la même région. Toutefois, le tronçon 1 peut être plus coûteux selon l’emplacement de l’utilisateur, car les utilisateurs du monde entier doivent accéder à l’instance du proxy d’application aux États-Unis. Il est important de noter que toutes les solutions de proxy ont des caractéristiques similaires en ce qui concerne les utilisateurs répartis globalement.

Cas d’utilisation 3

Scénario : l’application se trouve dans un réseau d’entreprise aux États-Unis. ExpressRoute avec peering Microsoft existe entre Azure et le réseau d’entreprise.

Recommandation : suivez les modèles 1 et 2, comme expliqué dans la section précédente.

Tout d’abord, placez le connecteur aussi près que possible de l’application. Le système utilise automatiquement ExpressRoute pour le tronçon 2.

Si la liaison ExpressRoute utilise le peering Microsoft, le trafic entre le proxy et le connecteur suit cette liaison. Le tronçon 2 utilise une latence optimale.

Cas d’utilisation 4

Scénario : l’application se trouve dans un réseau d’entreprise aux États-Unis. ExpressRoute avec le peering privé existe entre Azure et le réseau d’entreprise.

Recommandation : suivez le modèle 3, expliqué dans la section précédente.

Placez le connecteur dans le centre de données Azure qui est connecté au réseau d’entreprise par le biais du peering privé ExpressRoute.

Le connecteur peut être placé dans le centre de données Azure. Dans la mesure où le connecteur a toujours une ligne de vue à l’application et le centre de données via le réseau privé, le tronçon 3 reste optimisé. En outre, le tronçon 2 est davantage optimisé.

Cas d’utilisation 5

Scénario : l’application se trouve dans le réseau d’une organisation en Europe, la région du locataire par défaut est États-Unis, la plupart des utilisateurs se trouvant Europe.

Étant donné que les utilisateurs d’Europe ont accès à une instance de proxy d’application qui se trouve dans la même région, le tronçon 1 n’est pas onéreux. Le tronçon 3 est optimisé. Envisagez d’utiliser ExpressRoute pour optimiser le tronçon 2.

Cas d’utilisation 6

Scénario : l’application se trouve dans le réseau d’une organisation en Europe, la région du locataire par défaut est États-Unis, la plupart des utilisateurs se trouvant aux États-Unis.

Recommandation : placez le connecteur près de l’application. Mettez à jour le groupe de connecteurs afin qu’il utilise des instances du service de proxy d’application en Europe. Pour connaître les étapes, consultez Optimiser les groupes de connecteurs afin d’utiliser le service cloud de proxy d’application le plus proche. Le tronçon 1 peut être plus onéreux, car tous les utilisateurs américains doivent accéder à l’instance de proxy d’application en Europe.

Vous pouvez également envisager d’utiliser une autre variante dans cette situation. Si la plupart des utilisateurs de l’organisation sont aux États-Unis, il est probable que votre réseau « s’étende » aussi vers les États-Unis. Placez le connecteur aux États-Unis, continuez à utiliser la région des États-Unis par défaut pour vos groupes de connecteurs, et utilisez la ligne de réseau d’entreprise interne dédiée à l’application en Europe. Les tronçons 2 et 3 sont ainsi optimisés.