Gouvernez l’accès en migrant un modèle de rôle organisationnel vers Microsoft Entra ID Governance
Le contrôle d’accès en fonction du rôle (RBAC) fournit un framework pour classifier les utilisateurs et les ressources informatiques. Ce framework vous permet de rendre explicite leur relation ainsi que les droits d’accès appropriés conformément à cette classification. Par exemple, si vous affectez à un utilisateur des attributs qui spécifient son poste et ses affectations de projet, il peut avoir accès aux outils nécessaires pour son travail et aux données dont il a besoin pour participer à un projet particulier. Quand l’utilisateur passe à une autre tâche et reçoit d’autres affectations de projets, le changement des attributs qui spécifient son poste et ses projets bloque automatiquement l’accès aux ressources exclusivement réservées à la fonction antérieure de l’utilisateur.
Dans Microsoft Entra ID, vous pouvez utiliser des modèles de rôle de plusieurs manières pour gérer l'accès à grande échelle grâce à la gouvernance des identités.
- Vous pouvez utiliser des packages d’accès pour représenter des rôles organisationnels dans votre organisation, comme « représentant commercial ». Un package d’accès représentant ce rôle organisationnel inclut tous les droits d’accès dont un représentant commercial peut généralement avoir besoin, sur plusieurs ressources.
- Les applications peuvent définir leurs propres rôles. Par exemple, si vous avez une application commerciale et que cette application a le rôle d’application « salesperson » dans son manifeste, vous pouvez inclure ce rôle à partir du manifeste de l’application dans un package d’accès. Les applications peuvent également utiliser des groupes de sécurité dans des scénarios où un utilisateur peut avoir simultanément plusieurs rôles propres à l’application.
- Vous pouvez utiliser des rôles pour déléguer l’accès administratif. Si vous disposez d’un catalogue pour tous les packages d’accès nécessaires aux ventes, vous pouvez affecter une personne responsable de ce catalogue, en lui attribuant un rôle spécifique au catalogue.
Cet article explique comment modéliser les rôles organisationnels, à l'aide des packages d'accès à la gestion des droits, afin que vous puissiez migrer vos définitions de rôles vers Microsoft Entra ID pour imposer l'accès.
Migration d’un modèle de rôle organisationnel
Le tableau suivant établit une correspondance entre les concepts des définitions de rôles organisationnels que vous connaissez peut-être dans d’autres produits et les fonctionnalités de gestion des droits d’utilisation.
| Concept dans la modélisation des rôles organisationnels | Représentation dans la gestion des droits d’utilisation |
|---|---|
| Gestion déléguée des rôles | Déléguer aux créateurs de catalogues |
| Collection d’autorisations sur une ou plusieurs applications | Créer un package d’accès avec des rôles de ressources |
| Restreindre la durée d’accès fournie par un rôle | Définir les paramètres de cycle de vie de la stratégie d’un package d’accès pour qu’ils aient une date d’expiration |
| Affectation individuelle à un rôle | Créer une affectation directe à un package d’accès |
| Affectation de rôles aux utilisateurs en fonction de propriétés (telles que leur service) | Établir une affectation automatique à un package d’accès |
| Les utilisateurs peuvent demander un rôle et être approuvés pour celui-ci | Configurer les paramètres de stratégie définissant qui peut demander un package d’accès |
| Renouvellement de certification d’accès des membres de rôle | Définir des paramètres de révision d’accès périodiques dans une stratégie de package d’accès |
| Séparation des tâches entre les rôles | Définir deux packages d’accès ou plus comme incompatibles |
Par exemple, une organisation peut avoir un modèle de rôle organisationnel existant similaire à celui indiqué dans le tableau suivant.
| Nom du rôle | Autorisations accordées par le rôle | Affectation automatique au rôle | Affectation au rôle basée sur une demande | Vérifications de la séparation des tâches |
|---|---|---|---|---|
| Salesperson | Membre de l’équipe commerciale | Oui | Non | None |
| Gestionnaire de solutions de vente | Les autorisations de Vendeur et le rôle d’application Gestionnaire de solutions dans l’application de vente | None | Un vendeur peut formuler une demande, nécessite l’approbation d’un responsable et fait l’objet d’une révision trimestrielle | Le demandeur ne peut pas être un gestionnaire de compte des ventes |
| Gestionnaire de comptes des ventes | Les autorisations de Vendeur et le rôle d’application Gestionnaire de comptes dans l’application de vente | None | Un vendeur peut formuler une demande, nécessite l’approbation d’un responsable et fait l’objet d’une révision trimestrielle | Le demandeur ne peut pas être un gestionnaire de solution de vente |
| Support commercial | Mêmes autorisations qu’un vendeur | None | Tout non-vendeur peut formuler une demande. Il nécessite l’approbation d’un responsable et fait l’objet d’une révision trimestrielle | Le demandeur ne peut pas être un vendeur |
Cela pourrait être représenté dans Microsoft Entra ID Governance comme un catalogue de packages d'accès contenant quatre packages d'accès.
| Package d’accès | Rôles de ressources | Stratégies | Package d’accès incompatible |
|---|---|---|---|
| Salesperson | Membre de l’équipe commerciale | Affectation automatique | |
| Gestionnaire de solutions de vente | Rôle d’application Gestionnaire de solutions dans l’application de vente | Basé sur la demande | Gestionnaire de comptes des ventes |
| Gestionnaire de comptes des ventes | Rôle d’application Gestionnaire de comptes dans l’application de vente | Basé sur la demande | Gestionnaire de solutions de vente |
| Support commercial | Membre de l’équipe commerciale | Basé sur la demande | Salesperson |
Les sections suivantes décrivent le processus de migration, créant les artefacts Microsoft Entra ID et Microsoft Entra ID Governance pour implémenter l'accès équivalent d'un modèle de rôle organisationnel.
Connectez les applications dont les autorisations sont référencées dans les rôles organisationnels à Microsoft Entra ID
Si vos rôles organisationnels sont utilisés pour attribuer des autorisations qui contrôlent l'accès aux applications non-Microsoft SaaS, aux applications sur site ou à vos propres applications cloud, vous devrez alors connecter vos applications à Microsoft Entra ID.
Pour qu'un package d'accès représentant un rôle organisationnel puisse faire référence aux rôles d'une application comme autorisations à inclure dans le rôle, pour une application qui a plusieurs rôles et prend en charge les normes modernes telles que SCIM, vous devez intégrer l'application avec Microsoft Entra ID et assurez-vous que les rôles de l'application sont répertoriés dans le manifeste de l'application.
Si l'application n'a qu'un seul rôle, vous devez quand même intégrer l'application avec Microsoft Entra ID. Pour les applications qui ne prennent pas en charge SCIM, Microsoft Entra ID peut écrire des utilisateurs dans le répertoire existant ou la base de données SQL d'une application, ou ajouter des utilisateurs AD dans un groupe AD.
Remplir le schéma Microsoft Entra utilisé par les applications et pour les règles de portée des utilisateurs dans les rôles organisationnels
Si vos définitions de rôle incluent des déclarations du type « tous les utilisateurs avec ces valeurs d'attribut sont automatiquement affectés au rôle » ou « les utilisateurs avec ces valeurs d'attribut sont autorisés à demander », vous devrez alors vous assurer que ces attributs sont présents dans Microsoft Entra. IDENTIFIANT.
Vous pouvez étendre le schéma Microsoft Entra, puis remplir ces attributs soit à partir d'AD sur site, via Microsoft Entra Connect, soit à partir d'un système RH tel que Workday ou SuccessFactors.
Créer des catalogues pour la délégation
Si la maintenance continue des rôles est déléguée, vous pouvez déléguer l’administration des packages d’accès en créant un catalogue pour chaque partie de l’organisation à laquelle vous allez déléguer.
Si vous devez créer plusieurs catalogues, vous pouvez utiliser un script PowerShell pour créer chaque catalogue.
Si vous n’envisagez pas de déléguer l’administration des packages d’accès, vous pouvez conserver les packages d’accès dans un catalogue unique.
Ajouter des ressources aux catalogues
Maintenant que vous avez identifié les catalogues, ajoutez les applications, les groupes ou les sites qui seront inclus dans les packages d’accès représentant les rôles organisationnels aux catalogues.
Si vous disposez de nombreuses ressources, vous pouvez utiliser un script PowerShell pour ajouter chaque ressource à un catalogue. Pour plus d’informations, consultez Créer un package d’accès dans la gestion des droits d’utilisation pour une application avec un rôle unique à l’aide de PowerShell.
Créer des packages d’accès correspondant aux définitions de rôle organisationnel
Chaque définition de rôle organisationnel peut être représentée avec un package d’accès dans ce catalogue.
Vous pouvez utiliser un script PowerShell pour créer un package d’accès dans un catalogue.
Une fois que vous avez créé un package d’accès, vous liez un ou plusieurs rôles des ressources du catalogue au package d’accès. Cela représente les autorisations du rôle organisationnel.
En outre, vous créez une stratégie pour l’affectation directe, dans le cadre de ce package d’accès, qui peut être utilisée pour suivre les utilisateurs qui ont déjà des attributions de rôles organisationnels individuelles.
Créer des affectations de package d’accès pour des attributions de rôles organisationnels individuelles existantes
Si certains de vos utilisateurs ont déjà des appartenances à un rôle organisationnel qu’ils ne recevraient pas via l’affectation automatique, vous devez créer des affectations directes pour ces utilisateurs aux packages d’accès correspondants.
Si de nombreux utilisateurs ont besoin d’affectations, vous pouvez utiliser un script PowerShell pour affecter chaque utilisateur à un package d’accès. Cela lie les utilisateurs à la stratégie d’affectation directe.
Ajouter des stratégies à ces packages d’accès pour l’affectation automatique
Si la définition de vos rôles organisationnels inclut une règle basée sur les attributs de l’utilisateur qui, en fonction de ces derniers, régit l’affectation et la suppression automatiques de l’accès, vous pouvez représenter cela en utilisant une stratégie d’affectation automatique. Un package d’accès peut avoir au maximum une stratégie d’affectation automatique.
Si vous avez de nombreuses définitions de rôle qui ont chacune une définition de rôle, vous pouvez utiliser un script PowerShell pour créer chaque stratégie d’affectation automatique dans chaque package d’accès.
Définir des packages d’accès comme incompatibles pour la séparation des tâches
Si vous avez des contraintes de séparation des tâches qui empêchent un utilisateur d’assumer un rôle organisationnel alors qu’il en a déjà un autre, vous pouvez empêcher l’utilisateur de demander l’accès dans la gestion des droits d’utilisation en marquant ces combinaisons de package d’accès comme incompatibles.
Pour chaque package d’accès qui doit être marqué comme incompatible avec un autre, vous pouvez utiliser un script PowerShell afin de configurer les packages d’accès comme incompatibles.
Ajouter des stratégies aux packages d’accès pour que les utilisateurs soient autorisés à formuler une demande
Si les utilisateurs qui n’ont pas encore de rôle organisationnel sont autorisés à formuler une demande et à bénéficier d’une approbation pour assumer un rôle, vous pouvez également configurer la gestion des droits d’utilisation pour permettre aux utilisateurs de demander un package d’accès. Vous pouvez ajouter des stratégies à un package d’accès et, dans chaque stratégie, spécifier quels utilisateurs peuvent formuler une demande et qui doit accorder l’approbation.
Configurer des révisions d’accès dans les stratégies d’affectation de package d’accès
Si vos rôles organisationnels nécessitent une révision régulière de leur appartenance, vous pouvez configurer des révisions d’accès périodiques dans les stratégies d’affectation directe et basées sur les demandes.