Partager via


Planifier un déploiement de proxy d'application Microsoft Entra

Le proxy d’application Microsoft Entra est une solution d’accès à distance simple, sécurisée et économique, destinée aux applications locales. Il fournit un chemin de transition immédiat pour les organisations « Cloud First » pour gérer l’accès aux applications locales héritées qui ne sont pas encore capables d’utiliser des protocoles modernes. Pour plus d’informations d’introduction, consultez Présentation du proxy d’application.

Le proxy d’application est recommandé pour permettre aux utilisateurs distants d’accéder aux ressources internes. Le proxy d’application évite d’avoir recours à un VPN ou à un proxy inverse dans les cas d’usage nécessitant un accès à distance. Il n’est pas destiné aux utilisateurs qui se trouvent sur le réseau d’entreprise. Ces utilisateurs qui utilisent le proxy d’application pour l’accès intranet peuvent rencontrer des problèmes de performances indésirables.

Cet article fournit les ressources dont vous avez besoin pour planifier, utiliser et gérer le proxy d’application Microsoft Entra.

Planifier l’implémentation

La section suivante fournit une vue d’ensemble des éléments de planification clés qui vous configurent pour une expérience de déploiement efficace.

Prérequis

Avant de commencer votre implémentation, vous devez respecter les prérequis suivants. Vous pouvez voir plus d’informations sur la configuration de votre environnement, y compris ces prérequis, dans le tutoriel.

  • Connecteurs : les connecteurs sont des agents légers que vous pouvez déployer sur :

    • Du matériel physique local
    • Une machine virtuelle hébergée dans n’importe quelle solution d’hyperviseur
    • Une machine virtuelle hébergée dans Azure permettant d’établir une connexion sortante au service Proxy d’application
  • Pour obtenir une vue d’ensemble plus détaillée, consultez Comprendre les connecteurs de réseau privé Microsoft Entra .

    • Les machines de connecteur doivent être activées pour TLS (Transport Layer Security) 1.2 avant d’installer les connecteurs.

    • Si possible, déployez des connecteurs dans le même réseau et le même segment que les serveurs d'applications web d'arrière-plan. Il est préférable de déployer les connecteurs après avoir lancé la découverte des applications.

    • Nous recommandons la présence d’au moins deux connecteurs par groupe de connecteurs à des fins de haute disponibilité et de mise à l’échelle. Avoir trois connecteurs est optimal pour la maintenance d’une machine à tout moment. Passez en revue la table de capacité du connecteur pour vous aider à décider du type de machine pour le connecteur.

  • Paramètres d’accès réseau : Les connecteurs de réseau privé Microsoft Entra se connectent à Azure via HTTPS (port TCP (Transmission Control Protocol) 443) et HTTP (port TCP 80).

    • La fin du trafic TLS du connecteur n’est pas prise en charge et empêche les connecteurs d’établir un canal sécurisé avec leurs points de terminaison de proxy d’application Microsoft Entra respectifs.

    • Évitez toute forme d’inspection inline sur les communications TLS sortantes établies entre les connecteurs et Azure. Vous pouvez réaliser une inspection interne entre un connecteur et une application back-end. Toutefois, cette pratique n’est pas recommandée, car elle peut dégrader l’expérience utilisateur.

    • L’équilibrage de charge des connecteurs n’est pas pris en charge, ni même nécessaire.

Points importants à prendre en compte avant de configurer le proxy d’application Microsoft Entra

Vous devez répondre aux exigences de base suivantes pour configurer et implémenter le proxy d’application Microsoft Entra.

  • Intégration Azure : avant de déployer le proxy d’application, les identités utilisateur doivent être synchronisées à partir d’un répertoire local ou créées directement dans vos locataires Microsoft Entra. La synchronisation d’identité permet à Microsoft Entra ID de préauthentifier les utilisateurs avant de leur accorder l’accès aux applications publiées par le proxy d’application et d’avoir les informations d’identificateur d’utilisateur nécessaires pour effectuer l’authentification unique (SSO).

  • Conditions d’accès conditionnel : nous vous déconseillons d’utiliser le proxy d’application pour l’accès intranet, car elle ajoute une latence qui affecte les utilisateurs. Nous vous recommandons d’utiliser le proxy d’application avec la pré-authentification et les stratégies d’accès conditionnel pour l’accès à distance à partir d’Internet. Pour permettre un accès conditionnel à l’intranet, vous pouvez moderniser les applications de sorte qu’elles puissent s’authentifier directement auprès de Microsoft Entra ID. Pour plus d’informations, consultez Ressources pour la migration d’applications vers l’ID Microsoft Entra.

  • Limites de service : pour vous protéger contre la surutilisation des ressources par des locataires individuels, il existe des limites de capacité définies par application et par locataire. Pour voir ces limites, reportez-vous aux limites et restrictions du service Microsoft Entra. Ces limites de limitation sont basées sur un benchmark au-delà du volume d’utilisation classique et fournissent une mémoire tampon suffisante pour la plupart des déploiements.

  • Certificat public : si vous utilisez des noms de domaine personnalisés, vous devez obtenir un certificat TLS. En fonction des exigences de votre organisation, l’obtention d’un certificat peut prendre un certain temps. Par conséquent, nous vous recommandons de démarrer le processus aussi tôt que possible. Le proxy d’application Azure prend en charge les certificats standard, wildcard ou SAN. Pour plus d’informations, consultez Configurer des domaines personnalisés avec le proxy d’application Microsoft Entra.

  • Exigences de domaine : pour utiliser la délégation Kerberos contrainte (KCD) pour l’authentification unique, vérifiez que le serveur de connecteur et le serveur d’applications sont joints à un domaine et qu’ils se trouvent dans le même domaine ou dans les domaines approuvés. Le service de connecteur s’exécute sous le compte système local et ne doit pas utiliser d’identité personnalisée. Pour plus d’informations, consultez KCD pour l’authentification unique.

  • Enregistrements DNS pour les URL

    • Avant d’utiliser des domaines personnalisés dans le proxy d’application, vous devez créer un enregistrement CNAME dans le système DNS (Domain Name System) public, ce qui permet aux clients de résoudre l’URL externe définie personnalisée vers l’adresse de proxy d’application prédéfinie. L’échec de la création d’un enregistrement CNAME pour une application qui utilise un domaine personnalisé empêche les utilisateurs distants de se connecter à l’application. Les étapes requises pour ajouter des enregistrements CNAME peuvent varier du fournisseur DNS au fournisseur. Découvrez donc comment gérer les enregistrements DNS et les jeux d’enregistrements à l’aide du Centre d’administration Microsoft Entra.

    • De même, les hôtes connecteurs doivent pouvoir résoudre l’URL interne des applications en cours de publication.

  • Droits et rôles d’administration

    • L’installation du connecteur nécessite des droits d’administrateur local sur le serveur Windows sur lequel il est installé. Il nécessite également un minimum d’un rôle Administrateur d’application pour authentifier et inscrire l’instance du connecteur auprès de votre locataire Microsoft Entra.

    • La publication et l’administration des applications nécessitent le rôle Administrateur d’application . Les administrateurs d’applications peuvent gérer toutes les applications dans l’annuaire, y compris les inscriptions, les paramètres d’authentification unique, les attributions d’utilisateurs et les attributions de groupes et les licences, les paramètres de proxy d’application et le consentement. Il n’accorde pas la possibilité de gérer l’accès conditionnel. Le rôle Administrateur d’application cloud a toutes les capacités de l’administrateur d’application, sauf qu’il n’autorise pas la gestion des paramètres de proxy d’application.

  • Licences : le proxy d’application est disponible via un abonnement Microsoft Entra ID P1 ou P2. Reportez-vous à la page de tarification De Microsoft Entra pour obtenir la liste complète des options et fonctionnalités de licence.

Découverte des applications

Compilez un inventaire de toutes les applications dans l’étendue qui sont publiées via le proxy d’application, en collectant les informations suivantes :

Type d’informations Informations à collecter
Type de service Par exemple : SharePoint, SAP, CRM, application web personnalisée, API
Plateforme d’application Par exemple : Windows Internet Information Services (IIS), Apache sur Linux, Tomcat, NGINX
Appartenance au domaine Nom de domaine complet (FQDN) du serveur web
Emplacement de l’application Emplacement du serveur web ou de la batterie de serveurs au sein de votre infrastructure
Accès interne URL exacte utilisée lors de l’accès à l’application en interne.
S’il s’agit d’une batterie de serveurs, quel type d’équilibrage de charge est utilisé ?
Indique si l’application extrait du contenu à partir de sources autres qu’elle-même.
Déterminer si l’application fonctionne sur des WebSockets.
Accès externe La solution du fournisseur à laquelle l’application pourrait déjà être exposée, de manière externe.
URL que vous souhaitez utiliser pour l’accès externe. Si SharePoint, vérifiez que les mappages d’accès alternatifs sont configurés conformément aux instructions. Si ce n’est pas le cas, vous devez définir des URL externes.
Certificat public Si vous utilisez un domaine personnalisé, obtenez un certificat avec un nom d’objet correspondant. S’il existe un certificat, notez le numéro de série et l’emplacement à partir duquel il peut être obtenu.
Type d'authentification Les types d’authentification pris en charge par l’application sont l’authentification de base, l’authentification Windows intégrée, l’authentification basée sur les formulaires, l’authentification basée sur les en-têtes, et les revendications.
Si l’application est configurée pour s’exécuter sous un compte de domaine spécifique, notez le nom de domaine complet (FQDN) du compte de service.
Pour une authentification basée sur SAML, ce sont l’URL de l’identificateur et l’URL de réponse.
Pour une authentification basée sur l’en-tête, il s’agit de la solution du fournisseur et d’une exigence spécifique concernant la gestion du type d’authentification.
Nom du groupe de connecteurs Nom logique du groupe de connecteurs désignés pour fournir le conduit et l’authentification unique à l’application back-end.
Accès des utilisateurs et des groupes Utilisateurs ou groupes d’utilisateurs auxquels l’accès externe est accordé à l’application.
Plus d’exigences Notez les exigences d'accès à distance ou de sécurité qui doivent être prises en compte lors de la publication de l'application.

Vous pouvez télécharger la feuille de calcul d’inventaire des applications pour inventorier vos applications.

Définir les exigences de l’organisation

Les domaines ci-dessous nécessitent que vous définissiez des besoins métier pour votre organisation. Des exemples de besoins métier sont cités pour chacun de ces domaines.

Accès

  • Les utilisateurs distants qui disposent d’appareils joints à un domaine ou joints à Microsoft Entra peuvent accéder aux applications publiées de façon sécurisée, grâce à l’authentification unique (SSO).

  • Les utilisateurs distants disposant d’appareils personnels approuvés peuvent accéder en toute sécurité aux applications publiées, à condition qu’ils soient inscrits à l’authentification multifacteur et inscrit l’application Microsoft Authenticator sur leur téléphone mobile en tant que méthode d’authentification.

Gouvernance

  • Les administrateurs peuvent définir et monitorer le cycle de vie des affectations d’utilisateurs aux applications publiées via le proxy d’application.

Sécurité

  • Seuls les utilisateurs associés aux applications (via leur appartenance à un groupe ou à titre individuel) peuvent accéder à ces applications.

Niveau de performance

  • Il n’existe aucune dégradation des performances de l’application par rapport à l’accès à l’application à partir du réseau interne.

Expérience utilisateur

  • Les utilisateurs savent comment accéder à leurs applications grâce aux URL de l’entreprise qui leur sont familières, et ce, sur n’importe quelle plateforme d’appareil.

Audit

  • Les administrateurs sont capables d’auditer les accès utilisateur.

Bonnes pratiques pour un pilote

Déterminez le temps et les efforts nécessaires afin de commissionner entièrement une application pour l’accès à distance à l’aide de l’authentification unique (SSO). Pour cela, exécutez un pilote qui effectue sa découverte initiale, sa publication et ses tests. L’utilisation d’une application web basée sur IIS simple déjà préconfigurée pour l’authentification Windows intégrée (IWA) permet d’établir une base de référence, car l’installation nécessite un effort minimal pour piloter l’accès à distance et l’authentification unique.

L’implémentation de votre pilote directement dans un locataire de production doit être facilitée par les éléments de conception suivants.

Gestion des connecteurs :

les connecteurs jouent un rôle essentiel dans la fourniture du conduit local vers vos applications. L’utilisation du groupe de connecteurs par défaut est adéquate pour les tests pilotes initiaux des applications publiées avant de les mettre en production. Les applications ayant réussi les tests peuvent ensuite être déplacées vers les groupes de connecteurs de production.

Gestion des applications :

vos employés sont davantage susceptibles de retenir une URL externe si elle leur est familière et si elle est explicite. Évitez de publier votre application à l’aide de nos suffixes msappproxy.net ou onmicrosoft.com prédéfinis. Au lieu de cela, fournissez un domaine vérifié de niveau supérieur familier, précédé d’un nom d’hôte logique tel que l’intranet.<>customers_domain.com.

Autorisez uniquement un groupe pilote à voir l’icône de l’application pilote en masquant son icône de lancement dans le portail Azure MyApps. Lorsque vous êtes prêt pour la production, vous pouvez cibler l'application vers son public ciblé respectif, soit dans la même instance de préproduction, soit en publiant l'application dans votre instance de production.

Paramètres d’authentification unique : certains paramètres d’authentification unique ont des dépendances spécifiques qui peuvent prendre du temps à configurer. Évitez donc les retards de contrôle des modifications en garantissant que les dépendances sont traitées à l’avance. Le processus inclut des hôtes de connecteur de jointure de domaine pour effectuer l’authentification unique à l’aide de la délégation Kerberos contrainte (KCD) et prendre soin d’autres activités fastidieuses.

TLS Entre l’hôte du connecteur et l’application cible : la sécurité est primordiale. Le protocole TLS entre l’hôte du connecteur et les applications cibles doit toujours être utilisé. en particulier si l’application web est configurée pour l’authentification basée sur les formulaires (FBA), car les informations d’identification utilisateur sont transmises en texte clair.

Implémentez de façon incrémentielle et testez chaque étape. Effectuez des tests fonctionnels de base après la publication d’une application pour vous assurer que toutes les exigences de l’utilisateur et de l’entreprise sont remplies :

Testez et validez l’accès général à l’application web avec la pré-authentification désactivée. Si elle réussit, activez la pré-authentification et attribuez des utilisateurs et des groupes. Ensuite, testez et validez l’accès. Ensuite, ajoutez la méthode d’authentification unique pour votre application et testez à nouveau pour valider l’accès. Enfin, appliquez des stratégies d’accès conditionnel et d’authentification multifacteur en fonction des besoins. Testez puis validez l’accès.

Outils de résolution des problèmes : commencez à résoudre les problèmes en vérifiant l’accès à l’application publiée directement à partir du navigateur sur l’hôte du connecteur. Vérifiez que l’application fonctionne comme prévu. Simplifiez votre configuration pour isoler les problèmes, tels que l’utilisation d’un seul connecteur et la désactivation de l’authentification unique. Les outils comme Fiddler de Telerik peuvent aider à déboguer les problèmes d’accès ou de contenu en traçant le trafic, notamment pour les plateformes mobiles telles que iOS et Android. Pour plus d’informations, consultez le guide de résolution des problèmes.

Implémenter votre solution

Déployer le proxy d’application

Les étapes de déploiement de votre proxy d’application sont décrites dans le tutoriel pour l’ajout d’une application locale pour l’accès à distance. Si l’installation ne réussit pas, sélectionnez Résoudre les problèmes de proxy d’application dans le portail ou utilisez le guide de résolution des problèmes liés à l’installation du connecteur agent proxy d’application.

Publier des applications via le proxy d’application

La publication d’applications suppose que vous avez satisfait tous les prérequis et que vous avez plusieurs connecteurs affichés comme inscrits et actifs dans la page proxy d’application.

Vous pouvez également publier des applications à l’aide de PowerShell.

Bonnes pratiques à suivre lors de la publication d’une application :

  • Utilisez des groupes de connecteurs : affectez un groupe de connecteurs désigné pour la publication de chaque application respective. Nous recommandons la présence d’au moins deux connecteurs par groupe de connecteurs à des fins de haute disponibilité et de mise à l’échelle. Le fait de disposer de trois connecteurs est optimal si vous devez traiter un ordinateur à tout moment. En outre, consultez Comprendre les groupes de connecteurs de réseau privé Microsoft Entra pour voir comment vous pouvez également utiliser des groupes de connecteurs pour segmenter vos connecteurs par réseau ou par emplacement.

  • Définir le délai d’expiration de l’application back-end : le paramètre est utile dans les scénarios où l’application peut nécessiter plus de 75 secondes pour traiter une transaction cliente. Par exemple, lorsqu’un client envoie une requête à une application web qui agit en tant que front-end à une base de données. Le serveur frontal envoie la requête à son serveur de base de données back-end et attend une réponse, mais au moment où elle reçoit une réponse, le côté client de la conversation expire. La définition du délai d’expiration sur Long fournit 180 secondes pour que les transactions plus longues se terminent.

  • Utiliser les types de cookies appropriés

    • HTTP-Only Cookie : fournit une sécurité supplémentaire en ayant un proxy d’application incluant l’indicateur HTTPOnly dans les en-têtes de réponse HTTP set-cookie. Le paramètre permet d’atténuer les attaques telles que l’écriture de scripts intersites (XSS). Laissez la valeur Non pour les clients/agents utilisateur qui nécessitent l’accès au cookie de session. (par exemple, pour un client RDP/MTSC se connectant à la passerelle des services Bureau à distance publiée via le proxy d’application).

    • Cookie sécurisé : lorsqu’un cookie est défini avec l’attribut Secure, l’agent utilisateur (application côté client) inclut uniquement le cookie dans les requêtes HTTP si la requête est transmise via un canal sécurisé TLS. Le paramètre permet d’atténuer le risque de compromission d’un cookie sur les canaux de texte clair. Il doit donc être activé.

    • Cookie persistant : permet au cookie de session proxy de l’application de conserver entre les fermetures de navigateur en restant valides jusqu’à ce qu’elle expire ou soit supprimée. Utilisé pour les scénarios où une application enrichie, telle qu'Office, accède à un document dans une application web publiée, sans que l'utilisateur soit sollicité à nouveau pour l'authentification. Activer avec précaution toutefois, car les cookies persistants peuvent finalement laisser un service à risque d’accès non autorisé, s’il n’est pas utilisé avec d’autres contrôles de compensation. Ce paramètre doit être utilisé uniquement pour les applications plus anciennes qui ne peuvent pas partager de cookies d’un processus à l’autre. Il est préférable de mettre à jour votre application pour gérer le partage de cookies entre les processus au lieu d’utiliser le paramètre.

  • Traduire des URL dans les en-têtes : vous activez le paramètre pour les scénarios où le DNS interne ne peut pas être configuré pour correspondre à l’espace de noms public de l’organisation (a.k.a Split DNS). Sauf si votre application requiert l’en-tête d’hôte d’origine dans la demande cliente, laissez la valeur définie sur Oui. Une autre solution consiste à configurer le connecteur pour qu’il utilise le nom de domaine complet dans l’URL interne dans le but de router le trafic, et qu’il utilise le nom de domaine complet dans l’URL externe comme en-tête de l’hôte. Dans la plupart des cas, l’alternative doit permettre à l’application de fonctionner normalement, lorsqu’elle est accessible à distance, mais vos utilisateurs perdent les avantages d’avoir une correspondance à l’intérieur et à l’extérieur de l’URL.

  • Traduire des URL dans le corps de l’application : activez la traduction de liens corps de l’application pour une application lorsque vous souhaitez que les liens de cette application soient traduits dans les réponses au client. Si elle est activée, la fonction fournit une tentative optimale de traduction de tous les liens internes trouvés par le proxy d’application dans les réponses HTML et CSS retournées aux clients. Il est utile lors de la publication d'applications contenant soit des liens absolus codés en dur, soit des liens NetBIOS de nom court dans le contenu, ou des applications avec du contenu qui lient à d'autres applications locales.

Dans les scénarios où une application publiée est liée à d’autres applications publiées, activez la traduction de liens pour chaque application de manière à pouvoir contrôler l’expérience utilisateur de chacune d’elles séparément.

Prenons un exemple : vous disposez de trois applications qui sont publiées via le proxy d’application et qui sont toutes liées entre elles (Bénéfices, Dépenses et Transports). Vous disposez également d’une quatrième application (Commentaires) qui n’est pas publiée via le proxy d’application.

Diagramme montrant la traduction de liens. Lorsque la traduction de liens est activée pour l’application Avantages, les liens vers les applications Expenses and Travel sont redirigés vers leurs URL externes, ce qui permet aux utilisateurs externes d’y accéder. Toutefois, les liens de Expenses and Travel back to Benefits ne fonctionnent pas, sauf si la traduction de liens est également activée pour ces applications. Le lien de l’application Commentaires n’est pas redirigé, car il n’a pas d’URL externe, empêchant les utilisateurs externes de l’accéder via l’application Avantages. Pour plus d’informations, consultez les options de traduction et de redirection des liens.

Accéder à votre application

Gérez l’accès aux ressources publiées du proxy d’application en sélectionnant l’approche qui convient le mieux à vos besoins en matière de scénario et d’extensibilité. Les méthodes courantes incluent la synchronisation de groupes locaux via Microsoft Entra Connect, la création de groupes dynamiques dans Microsoft Entra ID en fonction des attributs utilisateur, l’activation de groupes en libre-service gérés par les propriétaires de ressources ou la combinaison de ces stratégies. Explorez les ressources liées pour comprendre les avantages de chaque méthode.

Le moyen le plus simple d’affecter aux utilisateurs l’accès à une application est d’accéder aux options Utilisateurs et Groupes à partir du volet gauche de votre application publiée et d’affecter directement des groupes ou des individus.

Image 24

Vous pouvez également accorder aux utilisateurs un accès en libre-service à votre application, en affectant un groupe dont ils ne sont pas membres et en configurant les options d’accès en libre-service.

Image 25

Si cette option est activée, les utilisateurs se connectent au portail MyApps pour demander l’accès. Ils sont automatiquement approuvés et ajoutés au groupe libre-service ou nécessitent l’approbation d’un approbateur désigné.

Les utilisateurs invités peuvent également être invités à accéder aux applications internes publiées via le proxy d’application via Microsoft Entra B2B.

Pour les applications locales qui sont normalement accessibles anonymement, sans authentification, vous pouvez désactiver l’option située dans les propriétés de l’application.

Image 26

Laisser l’option définie sur Non permet aux utilisateurs d’accéder à l’application locale via le proxy d’application Microsoft Entra sans autorisations. Utilisez donc avec précaution.

Une fois que l’application est publiée, vous devez pouvoir y accéder en tapant son URL dans un navigateur externe ou en cliquant sur son icône à l’adresse https://myapps.microsoft.com.

Activer la pré-authentification

Vérifiez que votre application est accessible via le proxy d’application en y accédant via l’URL externe.

  1. Accédez à Entra ID>Applications d’entreprise>Toutes les applications et choisissez l’application que vous souhaitez gérer.

  2. Sélectionnez le proxy d’application.

  3. Dans le champ Pré-authentification , utilisez la liste déroulante pour sélectionner l’ID Microsoft Entra, puis sélectionnez Enregistrer. Une fois la pré-authentification activée, l’ID Microsoft Entra authentifie d’abord les utilisateurs. Si l’authentification unique est configurée, l’application principale vérifie également l’utilisateur avant d’accorder l’accès. Le passage du mode de pré-authentification de Passthrough à Microsoft Entra ID sécurise l'URL externe avec HTTPS, garantissant ainsi que toute application initialement utilisant HTTP fonctionne désormais sur HTTPS.

Activer l’authentification unique

L’authentification unique améliore l’expérience utilisateur et la sécurité en permettant aux utilisateurs de se connecter une fois avec l’ID Microsoft Entra. Après la pré-authentification, le connecteur de réseau privé se connecte à l’application locale pour l’utilisateur, ce qui lui permet d’apparaître comme si l’utilisateur s’est connecté directement.

Le choix de l’option Passthrough permet aux utilisateurs d’accéder à l’application publiée sans avoir à s’authentifier auprès de l’ID Microsoft Entra.

Pour activer l’authentification unique, votre application doit préauthentifier les utilisateurs avec l’ID Microsoft Entra. Sans pré-authentification, les options d’authentification unique ne sont pas disponibles.

Lisez la connexion unique aux applications dans Microsoft Entra ID pour vous aider à choisir la méthode SSO la plus appropriée lorsque vous configurez vos applications.

Utilisation des autres types d’applications

Le proxy d’application Microsoft Entra prend en charge les applications créées avec la bibliothèque d’authentification Microsoft (MSAL). Il gère les applications clientes natives à l’aide de jetons d’ID Microsoft Entra dans les en-têtes de demande client pour préauthentifier les utilisateurs.

Découvrez les configurations disponibles du proxy d’application. Lisez sur la publication d’applications clientes natives et mobiles et les applications à base de revendications.

Renforcer la sécurité avec l’accès conditionnel

La sécurité des applications nécessite un ensemble de fonctionnalités de sécurité avancées capables de protéger les applications locales et les applications cloud contre les menaces complexes. Utilisez des stratégies d’accès conditionnel pour contrôler l’accès à vos applications en fonction de nombreuses conditions telles que l’emplacement, le risque, le type d’appareil, la conformité des appareils, etc. Pour obtenir des exemples de stratégies que vous pouvez déployer, consultez l’article Modèles d’accès conditionnel.

Les fonctionnalités suivantes peuvent être utilisées pour prendre en charge le proxy d’application Microsoft Entra :

  • Accès conditionnel basé sur l’utilisateur et l’emplacement : conservez les données sensibles protégées en limitant l’accès utilisateur en fonction de l’emplacement géographique ou d’une adresse IP avec des stratégies d’accès conditionnel basées sur l’emplacement.

  • Accès conditionnel basé sur l’appareil : assurez-vous que seuls les appareils inscrits, approuvés et conformes peuvent accéder aux données d’entreprise avec l’accès conditionnel basé sur les appareils.

  • Accès conditionnel basé sur les applications : l’utilisateur peut continuer de travailler, même après avoir quitté le réseau de l’entreprise. Sécurisez l’accès au cloud d’entreprise et aux applications locales et gérez le contrôle avec l’accès conditionnel.

  • Accès conditionnel basé sur les risques : protégez vos données contre les pirates malveillants avec une stratégie d’accès conditionnel basée sur les risques qui peut être appliquée à toutes les applications et à tous les utilisateurs, qu’ils soient locaux ou dans le cloud.

  • Mes applications Microsoft Entra : une fois votre service Proxy d’application déployé et vos applications publiées de façon sécurisée, proposez à vos utilisateurs un hub simple à partir duquel ils pourront découvrir et accéder à toutes leurs applications. Augmentez la productivité avec des fonctionnalités en libre-service, telles que la possibilité de demander l’accès à de nouvelles applications et groupes ou de gérer l’accès à ces ressources pour le compte d’autres utilisateurs, via Mes applications.

Gérer l’implémentation

Rôles nécessaires

Microsoft applique le principe des privilèges minimum pour l’exécution de tâches à l’aide de Microsoft Entra ID. Passez en revue les différents rôles Azure disponibles et choisissez celui qui convient pour répondre aux besoins de chaque personne. Certains rôles doivent être appliqués temporairement et supprimés une fois le déploiement terminé.

Rôle d’entreprise Tâches d’entreprise Rôles Microsoft Entra
Administrateur du support technique Gère les tâches de support utilisateur de base telles que la réinitialisation des mots de passe, l’invalidation des jetons d’actualisation et la vérification de l’intégrité du service. Administrateur du support technique
Administrateur d’identité Pour déboguer les problèmes liés au proxy d’application, lisez les rapports de connexion et les journaux d’audit Microsoft Entra. Lecteur de sécurité
Propriétaire de l’application Pour créer et gérer tous les aspects des applications d’entreprise, des inscriptions d’applications et des paramètres du proxy d’application. Administrateur d’application
Administrateur d’infrastructure Propriétaire de la substitution de certificat Administrateur d’application

La réduction du nombre de personnes qui ont accès à des informations ou ressources sécurisées permet de réduire le risque qu’un acteur malveillant obtienne un accès non autorisé ou qu’un utilisateur autorisé affecte par inadvertance une ressource sensible.

Pour gérer efficacement l’accès administratif et garantir un audit approprié, nous vous recommandons d’utiliser l’accès juste-à-temps (JIT) avec Privileged Identity Management. Cette approche fournit un accès privilégié à la demande aux ressources Azure et à l’ID Microsoft Entra uniquement si nécessaire.

Création de rapports et surveillance

Microsoft Entra ID fournit plus d’informations sur l’utilisation de l’application et l’intégrité opérationnelle de votre organisation via les journaux d’audit et les rapports. Le proxy d’application facilite également la surveillance des connecteurs à partir du Centre d’administration Microsoft Entra et des journaux d’événements Windows.

Journaux d’audit des applications

Ces journaux fournissent des informations détaillées sur les connexions aux applications configurées avec le proxy d’application, ainsi que sur l’appareil et l’utilisateur qui accèdent à l’application. Les journaux d’audit se trouvent dans le Centre d’administration Microsoft Entra et dans l’API Audit pour l’exportation. En outre, les rapports d’utilisation et d’insights sont également disponibles pour votre application.

Surveillance du connecteur de réseau privé

Les connecteurs et le service se chargent de toutes les tâches de haut niveau de disponibilité. Vous pouvez monitorer l’état de vos connecteurs à partir de la page Proxy d’application dans le centre d’administration Microsoft Entra. Pour plus d’informations sur la maintenance des connecteurs, consultez Comprendre les connecteurs de réseau privé Microsoft Entra.

Journaux des événements Windows et compteurs de performances

Les connecteurs ont des journaux d’activité de session et d’administration. Les journaux d’activité admin incluent les événements principaux et leurs erreurs. Les journaux d’activité de session incluent toutes les transactions et les détails de traitement. Les journaux et compteurs se trouvent dans les journaux des événements Windows. Pour plus d’informations, consultez Comprendre les connecteurs de réseau privé Microsoft Entra. Suivez le tutoriel pour configurer les sources de données du journal des événements dans Azure Monitor.

Guide de résolution des problèmes

Découvrez plus en détail les problèmes courants et comment les résoudre avec notre guide de résolution des messages d’erreur.

Les articles suivants abordent des scénarios courants qui peuvent également être utilisés dans le but de créer des guides de dépannage pour votre organisation.