Phase 1 : Découverte et étendue des applications
La découverte et l’analyse des applications sont un exercice fondamental pour bien commencer. Vous ne savez peut-être pas tout, donc préparez-vous pour les applications inconnues.
Rechercher vos applications
La première décision dans le processus de migration est de déterminer les applications à migrer, celles qui doivent rester le cas échéant et celles qui doivent être déconseillées. Il existe toujours une opportunité de déprécier les applications que vous n’utiliserez pas dans votre organisation. Il existe plusieurs façons de rechercher des applications dans votre organisation. Quand vous découvrez des applications, assurez-vous d’inclure les applications en développement et en planification. Utilisez Microsoft Entra ID pour l’authentification dans toutes les applications futures.
Découvrez les applications à l’aide d’ADFS :
Utiliser Microsoft Entra Connect Health pour ADFS : si vous disposez d’une licence Microsoft Entra ID P1 ou P2, nous vous recommandons de déployer Microsoft Entra Connect Health pour analyser l’utilisation des applications dans votre environnement local. Vous pouvez utiliser le rapport d’application ADFS pour découvrir les applications ADFS pouvant migrer et évaluer si l’application à migrer est prête.
Si vous n’avez pas de licence Microsoft Entra ID P1 ou P2, nous vous recommandons d’utiliser des outils de migration d’applications d’ADFS vers Microsoft Entra basés sur PowerShell. Reportez-vous au Guide de solution :
Notes
Cette vidéo couvre les phases 1 et 2 du processus de migration.
Utilisation d’autres fournisseurs d’identité (IdP)
Si vous utilisez actuellement Okta, consultez notre guide de migration Okta vers Microsoft Entra.
Si vous utilisez actuellement Ping Federate, envisagez d’utiliser l’API d’administration Ping pour découvrir des applications.
Si les applications sont intégrées à Active Directory, recherchez les principaux de service ou les comptes de service qui peuvent être utilisés pour les applications.
Utilisation des outils Cloud Discovery
Dans l’environnement cloud, vous avez besoin d’une visibilité accrue, d’un contrôle sur le déplacement des données et d’une analytique sophistiquée pour rechercher et combattre les cybermenaces sur l’ensemble de vos services cloud. Vous pouvez collecter votre inventaire d’applications cloud à l’aide des outils suivants :
- Cloud Access Security Broker (CASB) – un CASB fonctionne généralement avec votre pare-feu pour offrir une visibilité de l’utilisation des applications cloud par vos employés et vous aide à protéger vos données d’entreprise contre les menaces de cybersécurité. Le rapport CASB peut vous aider à déterminer les applications les plus utilisées au sein de votre organisation, ainsi que les premières cibles à migrer vers Microsoft Entra ID.
- Cloud Discovery : en configurant Microsoft Defender for Cloud Apps, vous obtenez une visibilité sur l’utilisation des applications cloud, et vous pouvez découvrir des applications non approuvées ou de type Shadow IT (informatique fantôme).
- Applications hébergées dans Azure : pour les applications connectées à l’infrastructure Azure, vous pouvez utiliser les API et les outils sur ces systèmes pour commencer à effectuer un inventaire des applications hébergées. Dans l’environnement Azure :
- Utilisez la cmdlet Get-AzureWebsite pour obtenir des informations sur les sites web Azure.
- Utilisez la cmdlet Get-AzureRMWebApp pour obtenir des informations sur vos applications web Azure.
- Interrogez Microsoft Entra ID à la recherche d’applications et de principaux de service.
Processus de découverte manuelle
Après avoir suivi les approches automatisées décrites dans cet article, vous avez une bonne maîtrise de vos applications. Toutefois, vous pouvez envisager d’effectuer les opérations suivantes pour garantir une bonne couverture de tous les domaines d’accès utilisateur :
- Contactez les différents propriétaires commerciaux de votre organisation pour trouver les applications utilisées dans votre organisation.
- Exécutez un outil d’inspection HTTP sur votre serveur proxy ou analysez les journaux de proxy pour déterminer où le trafic est généralement routé.
- Consultez les journaux web des sites populaires du portail d’entreprise pour voir les liens auxquels les utilisateurs accèdent le plus.
- Contactez les responsables ou d’autres membres clés de l’entreprise pour être certain d’avoir couvert les applications qui sont vitales pour l’entreprise.
Types d’applications à migrer
Une fois que vous avez trouvé vos applications, vous devez identifier ces types d’applications dans votre organisation :
- Applications qui utilisent des protocoles d’authentification modernes tels que Security Assertion Markup Language (SAML) ou OpenID Connect (OIDC)
- Applications qui utilisent l’authentification héritée, telles que Kerberos ou NT LAN Manager (NTLM), que vous choisissez de moderniser
- Applications qui utilisent des protocoles d’authentification hérités que vous choisissez de ne PAS moderniser
- Nouvelles applications métier (LOB)
Applications qui utilisent déjà une authentification moderne
Les applications déjà modernisées sont les plus susceptibles d’être déplacées vers Microsoft Entra ID. Ces applications utilisent déjà des protocoles d’authentification modernes, tels que SAML ou OIDC, et peuvent être reconfigurées pour s’authentifier avec Microsoft Entra ID.
Nous vous recommandons de rechercher et d’ajouter des applications à partir de la galerie d’applications Microsoft Entra. Si vous ne les trouvez pas dans la galerie, vous pouvez toujours intégrer une application personnalisée.
Applications héritées que vous choisissez de moderniser
Pour les applications héritées que vous souhaitez moderniser, le passage à Microsoft Entra ID pour l’authentification principale et l’autorisation libère toute l’énergie et la richesse des données offertes par Microsoft Graph et Intelligent Security Graph.
Nous vous recommandons de mettre à jour le code de la pile d’authentification pour ces applications à partir du protocole hérité (par exemple l’authentification Windows intégrée, Kerberos, l’authentification basée sur les en-têtes HTTP) à un protocole moderne (par exemple SAML ou OpenID Connect).
Applications héritées que vous choisissez de ne PAS moderniser
Pour certaines applications utilisant des protocoles d’authentification hérités, la modernisation de l’authentification n’est pas toujours une option judicieuse pour des raisons commerciales. Il s’agit entre autres des types d’application suivants :
- Applications conservées localement pour des raisons de conformité ou de contrôle.
- Applications connectées à une identité locale ou à un fournisseur de fédération que vous ne souhaitez pas changer.
- Applications développées à l’aide de normes d’authentification locales que vous ne prévoyez pas de migrer
Microsoft Entra ID peut apporter des avantages importants à ces applications héritées. Vous pouvez activer des fonctionnalités de sécurité et de gouvernance modernes de Microsoft Entra telles que l’authentification multifacteur, l’accès conditionnel, Protection des ID Microsoft Entra, l’accès délégué aux applications et les révisions d’accès sur ces applications sans toucher à l’application elle-même.
- Commencez par étendre ces applications dans le cloud avec le proxy d’application Microsoft Entra.
- Ou explorez l’utilisation de l’une de nos intégrations de partenaires SHA (Secure Hybrid Access) que vous avez peut-être déjà déployées.
Nouvelles applications métier (LOB)
En général, vous développez des applications métier pour l’utilisation interne dans votre organisation. Si vous avez de nouvelles applications en vue, nous vous recommandons d’utiliser la plateforme d’identités Microsoft pour implémenter OIDC.
Applications à déconseiller
Applications qui n’ont pas de propriétaire avéré, qui ne bénéficient pas d’une maintenance ni d’une surveillance claire, qui présentent un risque de sécurité pour votre organisation. Envisagez de déconseiller des applications dans les cas suivants :
- Leurs fonctionnalités sont hautement redondantes avec d’autres systèmes
- Il n’y a pas de propriétaire d’entreprise
- Il n’y a clairement aucune utilisation
Nous vous recommandons de ne pas déconseiller les applications qui ont un impact important et qui sont vitales pour l’entreprise. Dans ce cas, collaborez avec les propriétaires commerciaux pour déterminer la stratégie appropriée.
Critères de sortie
La réussite de cette phase dépend des éléments suivants :
- Une bonne compréhension des applications concernées par la migration, de celles qui nécessitent une modernisation, de celles qui doivent rester telles quelles ou de celles que vous avez marquées pour dépréciation.