Phase 2 : Classifier les applications et planifier le pilote

La classification de la migration de vos applications est un exercice important. Toutes les applications ne doivent pas faire l’objet d’une migration et d’une transition en même temps. Une fois que vous aurez recueilli des informations sur chacune des applications, vous pourrez rationaliser les applications à migrer en priorité et celles qui risquent de prendre plus de temps.

Classifier les applications dans l’étendue

On peut prendre en compte les axes suivants : caractère critique pour l’entreprise, utilisation et durée de vie, chacun de ces axes dépendant de plusieurs facteurs.

Caractère critique pour l’entreprise

Le caractère critique pour l’entreprise prend en compte différentes dimensions pour chaque entreprise, mais les deux mesures que vous devez prendre en considération sont les caractéristiques et fonctionnalités et les profils utilisateur. Attribuez aux applications ayant une fonctionnalité unique une valeur de point supérieur aux applications ayant des fonctionnalités redondantes ou obsolètes.

Utilisation

Les applications avec un nombre d’utilisations élevé doivent recevoir une valeur plus élevée que les applications dont l’utilisation est faible. Attribuez une valeur plus élevée aux applications avec des utilisateurs externes, des utilisateurs faisant partie des responsables ou de l’équipe de sécurité. Pour chaque application dans votre portefeuille de migration, effectuez ces évaluations.

Une fois que vous avez déterminé les valeurs pour le caractère critique pour l’entreprise et l’utilisation, vous pouvez déterminer la durée de vie de l’application et créer une matrice de priorité. Le diagramme montre la matrice.

Remarque

Cette vidéo couvre les phases 1 et 2 du processus de migration.

Hiérarchiser les applications pour la migration

Vous pouvez choisir de commencer la migration par les applications ayant la priorité la plus basse ou les applications ayant la priorité la plus élevée en fonction des besoins de votre organisation.

Dans un scénario dans lequel vous avez peu d’expérience avec Microsoft Entra ID et les services d’identité, commencez par déplacer vos applications ayant la priorité la plus basse vers Microsoft Entra. Cela permet de réduire l’impact sur votre activité et de créer une dynamique. Une fois que vous avez correctement migré ces applications et que vous avez acquis la confiance de la partie prenante, vous pouvez continuer à migrer les autres applications.

S’il n’existe aucune priorité claire, nous vous recommandons de déplacer d’abord les applications qui se trouvent dans la galerie Microsoft Entra et qui prennent en charge plusieurs fournisseurs d’identité, car elles sont plus faciles à intégrer. Il est probable que ces applications sont les applications dont la priorité est la plus élevée de votre organisation. Pour vous aider à intégrer vos applications SaaS à Microsoft Entra ID, nous avons développé une collection de tutoriels qui vous guident lors de la configuration.

Quand vous avez une échéance pour migrer les applications, les applications présentant la priorité la plus élevée constituent la charge de travail principale. Vous pouvez finalement sélectionner les applications présentant une priorité plus basse, car elles ne modifient pas le coût même si vous avez déplacé l’échéance.

En plus de cette classification et en fonction de l’urgence de votre migration, vous devez publier une planification de la migration dans laquelle les propriétaires d’applications doivent migrer leurs applications. À la fin de ce processus, vous devez disposer d’une liste de toutes les applications dans des compartiments classés par priorité pour la migration.

Documenter vos applications

Tout d’abord, commencez par collecter des détails clés sur vos applications. La feuille de calcul de découverte des applications (Application Discovery Worksheet) vous aide à prendre rapidement des décisions de migration et à transmettre des recommandations à votre groupe de travail en un rien de temps.

Les informations importantes pour prendre votre décision de migration incluent :

• Nom de l’application – sous quel nom cette application est-elle connue dans l’entreprise ?
• Type d’application – s’agit-il d’une application SaaS tierce ? Une application web métier personnalisée ? Une API ?
• Caractère critique pour l’entreprise – cette application est-elle hautement critique ? Peu critique ? Ou bien se situe-t-elle entre les deux ?
• Volume d’accès utilisateur – cette application est-elle utilisée par tous les utilisateurs ou seulement quelques personnes ?
• Type d’accès utilisateur : qui doit accéder à l’application : employés, partenaires commerciaux, clients ou peut-être tous ?
• Durée de vie planifiée : combien de temps il s’agit de disponibilité ? Moins de six mois ? Plus de deux ans ?
• Fournisseur d’identité actuel – qui est le fournisseur d’identité (IdP) principal pour cette application ? AD FS, Active Directory ou Ping Federate ?
• Exigences de sécurité : l’application nécessite-t-elle l’authentification multifacteur ou le fait que les utilisateurs soient sur le réseau d’entreprise pour accéder à l’application ?
• Méthode d’authentification – l’application s’authentifie-t-elle à l’aide de normes ouvertes ?
• Si vous envisagez de mettre à jour le code de l’application – l’application est en développement planifié ou en cours de développement actif ?
• Si vous envisagez de conserver l’application en local – souhaitez-vous conserver l’application dans votre centre de données à long terme ?
• Si l’application dépend d’autres applications ou API – est-ce que l’application appelle actuellement d’autres applications ou API ?
• Si l’application se trouve dans la galerie Microsoft Entra : l’application est-elle actuellement déjà intégrée à la galerie Microsoft Entra ID ?

Voici d’autres données qui vous aideront ultérieurement, mais pour lesquelles vous n’avez pas besoin de prendre une décision de migration immédiate :

• URL de l’application – où les utilisateurs se rendent-ils pour accéder à l’application ?
• Logo de l’application : si vous migrez vers Microsoft Entra ID une application qui ne se trouve pas dans la galerie d’applications Microsoft Entra, nous vous recommandons de fournir un logo descriptif
• Description de l’application – brève description de la fonctionnalité de l’application
• Propriétaire de l’application – qui au sein de l’entreprise est le principal point de contact pour l’application ?
• Commentaires ou remarques générales – toutes les autres informations générales sur l’application ou la propriété commerciale

Une fois que vous avez classifié votre application et documenté les détails, vous devez vous assurer que vous avez obtenu l’assentiment du propriétaire commercial pour votre stratégie de migration planifiée.

Utilisateurs de l’application

Il existe deux catégories principales d’utilisateurs de vos applications et de ressources prises en charge par Microsoft Entra ID :

• Internes : Employés, sous-traitants et fournisseurs qui ont des comptes au sein de votre fournisseur d’identité. Cela peut nécessiter d’autres tableaux croisés dynamiques avec des règles différentes pour les responsables ou la direction par rapport aux autres employés.

• Externes : prestataires, fournisseurs, distributeurs ou autres partenaires commerciaux qui interagissent avec votre organisation dans le cadre d’une activité régulière avec la collaboration B2B Microsoft Entra.

Vous pouvez définir des groupes pour ces utilisateurs et remplir ces groupes de différentes façons. Vous pouvez choisir l’ajout manuel des membres à un groupe par un administrateur ou activer l’appartenance au groupe en libre-service. Des règles peuvent être établies pour ajouter automatiquement des membres à des groupes en fonction des critères spécifiés à l’aide de groupes dynamiques.

Les utilisateurs externes peuvent également faire référence à des clients. Azure AD B2C, un produit distinct prend en charge l’authentification du client. Toutefois, ce contenu sort du cadre de cet article.

Prévoir un pilote

L’application ou les applications que vous sélectionnez pour le pilote doivent représenter l’identité clé et les exigences de sécurité de votre organisation. Vous devez disposer de l’assentiment formel des propriétaires de l’application. Les pilotes s’exécutent généralement dans un environnement de test distinct.

N’oubliez pas vos partenaires externes. Assurez-vous qu’ils participent aux planifications et aux tests de la migration. Enfin, assurez-vous qu’ils disposent d’un moyen d’accéder à votre support technique en cas de problème cassant.

Planifier des limitations

Alors que certaines applications migrent facilement, d’autres peuvent prendre plus de temps en raison de serveurs ou d’instances multiples. Par exemple, la migration SharePoint peut prendre plus de temps en raison des pages de connexion personnalisées.

De nombreux fournisseurs d’applications SaaS peuvent ne pas fournir de moyen libre-service pour reconfigurer l’application, et peuvent facturer la modification de la connexion d’authentification unique. Consultez-les et prévoyez ces détails.

Approbation du propriétaire du rôle

Les applications à caractère critique pour l’entreprise et universelles peuvent avoir besoin d’un groupe d’utilisateurs pilotes à des fins de test au cours de la phase pilote. Une fois que vous avez testé une application dans l’environnement de préproduction ou pilote, veillez à ce que les propriétaires commerciaux des applications aient validé les performances avant la migration de l’application, et que tous les utilisateurs en production utilisent Azure AD pour l’authentification. Vous devez également vous assurer que tous les utilisateurs migrent vers l’utilisation de production de l’ID Microsoft Entra pour l’authentification.

Planifier la posture de sécurité

Avant de lancer le processus de migration, prenez le temps de prendre en compte la posture de sécurité que vous souhaitez développer pour votre système d’identité d’entreprise. Pour ce faire, collectez ces informations : identités, appareils et localisations ayant accès à vos applications et données.

Identités et données

La plupart des organisations ont des exigences spécifiques en matière d’identité et de protection des données qui varient en fonction des secteurs d’activité et des postes dans les organisations. Reportez-vous aux configurations d’accès aux identités et aux appareils pour nos recommandations. Les recommandations incluent un ensemble prescrit de stratégies d’accès conditionnel et de fonctionnalités associées.

Vous pouvez utiliser ces informations pour protéger l’accès à tous les services intégrés à Microsoft Entra ID. Ces recommandations sont alignées sur le niveau de sécurité Microsoft et le score d’identité dans Microsoft Entra ID. Le degré de sécurisation vous aide à accomplir les tâches suivantes :

• Évaluer votre méthode de sécurité relative aux identités de façon objective
• Planifier les améliorations à apporter à la sécurité des identités
• Évaluer la réussite de vos améliorations

Cela vous aide également à mettre en œuvre les cinq étapes de sécurisation de votre infrastructure d’identité. Utilisez les conseils comme point de départ pour votre organisation et ajustez les stratégies pour répondre aux besoins spécifiques de votre organisation.

Appareil/emplacement utilisé pour accéder aux données

L’appareil et l’emplacement qu’un utilisateur utilise pour accéder à une application sont également importants. Les appareils physiquement connectés à votre réseau d’entreprise sont plus sécurisés. Les connexions extérieures au réseau via VPN peuvent nécessiter des contrôles.

En tenant compte de ces aspects de la ressource, de l’utilisateur et de l’appareil, vous pouvez choisir d’utiliser les capacités de l’accès conditionnel Microsoft Entra. L’accès conditionnel dépasse les autorisations utilisateur. Elle dépend d’une combinaison de facteurs tels que :

• Identité d’un utilisateur ou d’un groupe
• Réseau auquel l’utilisateur est connecté
• L’appareil et l’application que l’utilisateur utilise
• La sensibilité des données auxquelles l'utilisateur tente d'accéder.

L’accès accordé à l’utilisateur s’adapte à ce jeu de conditions plus large.

Critères de sortie

Pour la réussite de cette phase, vous devez :

• Documenté entièrement les applications que vous envisagez de migrer.

• Des applications hiérarchisées en fonction de leur caractère critique pour l’entreprise, du volume d’utilisation et de la durée de vie.

• Sélectionné des applications qui représentent vos besoins pour un pilote.

• Avoir l’assentiment du propriétaire commercial pour votre stratégie de hiérarchisation et de stratégie

• Compris vos besoins en matière de posture de sécurité et la façon de les implémenter.

Étapes suivantes

• Phase 3 : planifier la migration et le test