Définir des stratégies organisationnelles pour régir l’accès aux applications dans votre environnement
Une fois que vous avez identifié une ou plusieurs applications auxquelles vous souhaitez utiliser Microsoft Entra ID pour gérer l'accès, notez les politiques de l'organisation pour déterminer quels utilisateurs doivent avoir accès, ainsi que toute autre contrainte que le système doit fournir.
Sélectionner les applications et leurs rôles dans l’étendue
Les organisations ayant des exigences de conformité ou des plans de gestion des risques ont toutes des applications sensibles ou vitales pour l’entreprise. Si cette application existe déjà dans votre environnement, vous avez peut-être déjà documenté les stratégies d’accès pour définir qui « doit avoir accès » à cette application. Si ce n’est pas le cas, vous devrez peut-être vérifier auprès de différentes parties prenantes, notamment les équipes en charge de la conformité et de la gestion des risques, que les stratégies utilisées pour automatiser les décisions d’accès sont adaptées à votre scénario.
Collectez les rôles et autorisations que chaque application fournit. Certaines applications peuvent fournir un seul rôle, par exemple, le rôle « Utilisateur ». Des applications plus complexes peuvent faire apparaître plusieurs rôles à gérer via Microsoft Entra ID. Ces rôles d’application appliquent communément des contraintes générales sur l’accès accordé à un utilisateur ayant ce rôle dans l’application. Par exemple, une application avec un administrateur peut avoir deux rôles, « Utilisateur » et « Administrateur ». D'autres applications peuvent également s'appuyer sur des appartenances à des groupes ou des revendications pour des contrôles de rôle plus précis, qui peuvent être fournies à l'application à partir de Microsoft Entra ID lors du provisionnement ou des revendications émises à l'aide des protocoles SSO de fédération, ou écrites dans AD en tant qu'appartenance à un groupe de sécurité. Enfin, il peut y avoir des rôles spécifiques à l'application qui n'apparaissent pas dans Microsoft Entra ID – peut-être que l'application ne permet pas de définir les administrateurs dans Microsoft Entra ID, mais s'appuie plutôt sur ses propres règles d'autorisation pour identifier les administrateurs. SAP Cloud Identity Services n’a qu’un seul rôle, utilisateur, pouvant être affecté.
Remarque
Si vous utilisez une application de la galerie d'applications Microsoft Entra qui prend en charge le provisionnement, Microsoft Entra ID peut importer des rôles définis dans l'application et mettre automatiquement à jour le manifeste de l'application avec les rôles de l'application, une fois le provisionnement configuré.
Sélectionnez les rôles et les groupes dont les appartenances doivent être régies dans Microsoft Entra ID. Selon leurs exigences en matière de conformité et de gestion des risques, les organisations hiérarchisent souvent les groupes ou rôles d’application qui donnent un accès privilégié ou un accès aux informations sensibles.
Définir la stratégie de l’organisation avec les prérequis et autres contraintes pour l’accès à l’application
Dans cette section, vous allez écrire les stratégies organisationnelles que vous envisagez d’utiliser pour déterminer l’accès à l’application. Vous pouvez enregistrer ces informations sous forme de tableau dans une feuille de calcul, par exemple
| Rôle de l’application | Prérequis pour l’accès | Approbateurs | Durée par défaut de l’accès | Contraintes de séparation des tâches | Stratégies d’accès conditionnel |
|---|---|---|---|---|---|
| Ventes Ouest | Membre de l’équipe commerciale | Responsable de l’utilisateur | Révision annuelle | Accès Ventes Est non autorisé | Authentification multifacteur (MFA) et appareil inscrit requis pour l’accès |
| Ventes Ouest | Tous les employés hors commerciaux | Directeur du service Ventes | 90 jours | N/A | Authentification multifacteur et appareil inscrit requis pour l’accès |
| Ventes Ouest | Commercial non-employé | Directeur du service Ventes | 30 jours | N/A | Authentification multifacteur requise pour l’accès |
| Ventes Est | Membre de l’équipe commerciale | Responsable de l’utilisateur | Révision annuelle | Accès Ventes Ouest non autorisé | Authentification multifacteur et appareil inscrit requis pour l’accès |
| Ventes Est | Tous les employés hors commerciaux | Directeur du service Ventes | 90 jours | N/A | Authentification multifacteur et appareil inscrit requis pour l’accès |
| Ventes Est | Commercial non-employé | Directeur du service Ventes | 30 jours | N/A | Authentification multifacteur requise pour l’accès |
Si vous avez déjà une définition de rôle d’organisation, découvrez comment migrer un rôle organisationnel pour plus d’informations.
Identifiez s’il y a des prérequis ou des normes auxquels un utilisateur doit satisfaire pour obtenir l’accès à une application. Par exemple, dans la plupart des cas, seuls les employés à temps plein, ou ceux d’un service ou d’un centre de coûts particulier, doivent être autorisés à accéder à l’application du service en question. En outre, vous pouvez exiger que la stratégie de gestion des droits d’utilisation pour un utilisateur d’un autre service qui demande l’accès comporte un ou plusieurs approbateurs supplémentaires. Passer par plusieurs étapes d’approbation risque de ralentir le processus global d’obtention de l’accès par un utilisateur, mais ces étapes supplémentaires garantissent que les demandes d’accès sont fondées et que les décisions sont prises de manière responsable. Par exemple, les demandes d’accès d’un employé peuvent faire l’objet de deux approbations : d’abord par le responsable de l’utilisateur demandeur, puis par l’un des propriétaires de ressources responsables des données contenues dans l’application.
Déterminez la durée de validité de l’accès accordé à un utilisateur ainsi que la date à laquelle cet accès doit lui être retiré. Dans beaucoup d’applications, un utilisateur peut conserver l’accès indéfiniment, jusqu’à ce qu’il ne soit plus affilié à l’organisation. Dans certains cas, l’accès peut être lié à un projet ou des jalons particuliers : il sera alors supprimé automatiquement à la fin du projet. Ou encore, si seulement quelques personnes utilisent une application par le biais d’une stratégie, vous pouvez configurer des révisions trimestrielles ou annuelles de l’accès de chaque personne via cette stratégie afin de faire un point régulier.
Si votre organisation régit déjà l’accès avec un modèle de rôle organisationnel, prévoyez d’intégrer ce modèle de rôle organisationnel à Microsoft Entra ID. Vous pouvez avoir un rôle organisationnel défini qui attribue l’accès en fonction de la propriété d’un utilisateur, telle que son poste ou son service. Avec ces processus, vous êtes sûr que les utilisateurs perdent leur accès lorsqu’ils n’en ont plus besoin, même si aucune date de fin de projet n’a été prédéfinie.
Déterminez s’il y a des contraintes de séparation des tâches. Imaginons, par exemple, que vous avez une application avec deux rôles d’application, Ventes Ouest et Ventes Est, et que vous souhaitez vous assurer qu’un utilisateur ne peut avoir qu’un seul secteur de vente à la fois. Incluez une liste de paires de rôles d’application incompatibles pour votre application. Ainsi, si un utilisateur a l’un de ces rôles, il n’est pas autorisé à demander le deuxième rôle.
Sélectionnez la stratégie d’accès conditionnel appropriée pour accéder à l’application. Nous vous recommandons d’analyser vos applications et de les regrouper par applications partageant les mêmes exigences en ressources pour les mêmes utilisateurs. S’il s’agit de la première application SSO fédérée que vous intégrez à Gouvernance Microsoft Entra ID pour la gouvernance des identités, vous devrez peut-être créer une nouvelle stratégie d’accès conditionnel pour exprimer des contraintes, telles que les exigences d’authentification multifacteur (MFA) ou d’accès basé sur l’emplacement. Dans la configuration, vous pouvez demander en prérequis que les utilisateurs acceptent les conditions d’utilisation. Consultez l’article Planifier un déploiement d’accès conditionnel pour plus d’informations sur la définition d’une stratégie d’accès conditionnel.
Déterminez la façon dont les exceptions à vos critères doivent être gérées. Par exemple, dans le cas d’une application qui est habituellement disponible uniquement pour les employés désignés, il peut arriver qu’un auditeur ou un fournisseur ait besoin d’un accès temporaire pour un projet spécifique. Autre cas : un employé en déplacement peut avoir besoin d’un accès à partir d’un emplacement qui est normalement bloqué du fait que votre organisation n’est pas présente à cet emplacement. Dans ces situations, vous pouvez choisir d’avoir aussi une stratégie de gestion des droits d’utilisation pour un processus d’approbation ayant plusieurs étapes, une durée d’accès différente ou un autre approbateur. Un vendeur qui est connecté en tant qu’utilisateur invité sur votre locataire Azure AD n’a pas forcément de responsable associé. Par conséquent, ses demandes d’accès peuvent être approuvées par un commanditaire pour son organisation ou par un propriétaire de ressources, ou encore par un responsable sécurité.
Étant donné que la politique organisationnelle définissant les personnes devant avoir accès est en cours d'examen par les parties prenantes, vous pouvez alors commencer à intégrer l'application avec Microsoft Entra ID. De cette façon, à une étape ultérieure, vous serez prêt à déployer les stratégies d'accès approuvées par l'organisation dans Microsoft Entra ID Governance.