Gérer l’accès à une application

L’intégration d’une application dans le système d’identité de votre organisation pose des défis dans la gestion des accès, l’évaluation de l’utilisation et la création de rapports. Les administrateurs informatiques ou le personnel du support technique doivent généralement superviser l’accès aux applications. L’attribution d’accès peut revenir à une équipe informatique générale ou divisionnaire, mais dans l’idéal, les décisionnaires d’entreprise doivent être impliqués, en donnant l’approbation avant que le service informatique ne termine le processus.

D’autres organisations investissent dans l’intégration à un système automatisé de gestion des identités et des accès, tel que le contrôle d’accès en fonction du rôle (RBAC) ou le contrôle d’accès en fonction de l’attribut (ABAC). L’intégration et le développement de règles ont tous deux tendance à être spécialisés et coûteux. Quelle que soit la méthode de gestion, l’analyse ou la création de rapports représente un investissement distinct, coûteux et complexe.

Comment Microsoft Entra ID aide-t-il ?

Microsoft Entra ID prend en charge une gestion complète de l’accès pour les applications configurées, permettant aux organisations d’accomplir facilement les stratégies d’accès appropriées, allant de l’affectation automatique basée sur l’attribut (scénarios ABAC ou RBAC) à la gestion des administrateurs en passant par la délégation. Grâce à Microsoft Entra ID, vous pouvez facilement accomplir des stratégies complexes, en combinant plusieurs modèles de gestion pour une application unique, et pouvez même réutiliser les règles de gestion entre les applications avec le même public.

Avec Microsoft Entra ID, la création de rapports d’utilisation et d’affectation est entièrement intégrée, permettant aux administrateurs de créer facilement des rapports sur l’état des affectations, les erreurs d’affectation et même sur l’utilisation.

Attribution d’utilisateurs et de groupes à une application

L’affectation d’applications Microsoft Entra se concentre sur deux modes d’affectation principaux :

• Affectation individuelle : un administrateur informatique détenant des autorisations d’administrateur d’application cloud de l’annuaire peut sélectionner différents comptes d’utilisateurs et leur octroyer un accès à l’application.

• Affectation basée sur le groupe (nécessite Microsoft Entra ID P1 ou P2) : un administrateur informatique détenant des autorisations d’application cloud de l’annuaire peut affecter un groupe à l’application. L’accès dont bénéficie un utilisateur dépend de son appartenance éventuelle au groupe au moment où il essaie d’accéder à l’application. En d’autres termes, un administrateur peut créer une règle d’affectation qui stipule « tout membre actuel du groupe affecté dispose de l’accès à l’application ». Avec cette option d’affectation, les administrateurs peuvent tirer parti des options de gestion de groupe de Microsoft Entra, y compris les groupes à appartenance dynamique basée sur des attributs, les groupes de systèmes externes (par exemple, Active Directory local ou Workday), les groupes gérés par un administrateur, ou les groupes en libre-service. Un même groupe peut être facilement affecté à plusieurs applications ; ainsi, celles qui présentent une affinité d’affectation peuvent partager des règles d’affectation, réduisant la complexité globale de la gestion.

  Remarque

  Les appartenances à des groupes imbriqués ne sont pas prises en charge pour l’affectation basée sur le groupe à des applications à ce stade.

Avec ces deux modes d’affectation, les administrateurs peuvent mettre en œuvre toute approche de gestion d’affectation souhaitable.

Demande d’affectation d’utilisateurs pour une application

Avec certains types d’applications, vous avez la possibilité de demander que des utilisateurs soient affectés à l’application. En procédant ainsi, vous empêchez tous les utilisateurs de se connecter, à l’exception de ceux que vous affectez explicitement à l’application. Les types d’applications suivants prennent en charge cette option :

• Les applications configurées pour l’authentification unique (SSO) fédérée avec l’authentification basée sur SAML
• Les applications de proxy d’application qui utilisent la pré-authentification Microsoft Entra
• Les applications qui sont créées sur la plateforme d’application Microsoft Entra et qui utilisent l’authentification OAuth 2.0 / OpenID Connect après qu’un utilisateur ou administrateur a donné son consentement à l’application. Certaines applications d’entreprise offrent davantage de contrôle sur les personnes autorisées à se connecter.

Quand une affectation d’utilisateur est requise, seuls les utilisateurs que vous affectez à l’application (via une affectation directe ou une appartenance à un groupe) peuvent se connecter. Ils peuvent accéder à l’application via le portail Mes applications ou à l’aide d’un lien direct.

Lorsque l’affectation d’utilisateurs n’est pas obligatoire, les utilisateurs non affectés ne voient pas l’application dans Mes applications, mais ils peuvent quand même se connecter à l’application elle-même (procédure également appelée « authentification initiée par le fournisseur de services »). Ils peuvent aussi utiliser l’URL d’accès utilisateur de la page Propriétés de l’application (action également appelée « authentification initiée par IDP »). Pour en savoir plus sur les exigences de configuration d’affectations d’utilisateurs, consultez Configurer une application

Ce paramètre n’a pas d’incidence sur l’apparition ou non d’une application dans le volet Mes applications. Les applications apparaissent dans le portail Mes applications des utilisateurs une fois que vous affectez un utilisateur ou un groupe à l’application.

Pour certaines applications, l’option permettant de demander l’affectation d’utilisateurs n’est pas disponible dans les propriétés de l’application. Dans ce cas, vous pouvez utiliser PowerShell pour définir la propriété appRoleAssignmentRequired sur le principal du service.

Détermination de l’expérience utilisateur pour l’accès aux applications

Microsoft Entra ID propose plusieurs méthodes personnalisables pour déployer des applications auprès des utilisateurs finaux de votre organisation :

• Mes applications Microsoft Entra
• Lanceur d'applications Microsoft 365
• Authentification directe pour les applications fédérées (service-pr)
• Liens profonds vers des applications fédérées, avec mot de passe ou des applications existantes

Vous pouvez déterminer si les utilisateurs attribués à une application d'entreprise peuvent voir celle-ci dans le lanceur d'applications Microsoft 365.

Exemple : affectation d’applications complexe avec Microsoft Entra ID

Considérez une application comme Salesforce. Dans de nombreuses organisations, Salesforce est principalement utilisé par des équipes commerciales et marketing. Souvent, les membres de l’équipe marketing disposent d’un accès hautement privilégié à Salesforce, contrairement aux membres de l’équipe de ventes. Dans de nombreux cas, la majorité des travailleurs de l’information n’obtiennent qu’un accès limité à l’application. Les exceptions à ces règles compliquent les choses. C’est souvent la prérogative des équipes de direction marketing ou de ventes d’accorder un accès à un utilisateur ou de modifier son rôle indépendamment de ces règles génériques.

Avec Microsoft Entra ID, les applications telles que Salesforce peuvent être préconfigurées pour l’authentification unique (SSO) et l’automatisation de l’approvisionnement. Dès que l’application est configurée, un administrateur peut créer et affecter des groupes appropriés en une seule action. Dans cet exemple, un administrateur peut exécuter les affectations suivantes :

• Les groupes dynamiques peuvent être définis pour représenter automatiquement tous les membres des équipes de ventes et de marketing à l’aide d’attributs tels que le service ou le rôle :

  • Tous les membres de groupes marketing sont affectés au rôle « marketing » dans Salesforce.
  • Tous les membres de groupes de ventes sont affectés au rôle « sales » dans Salesforce. Pour affiner les choses, plusieurs groupes représentant des équipes de ventes régionales affectées à différents rôles Salesforce peuvent être utilisés.

• Pour activer le mécanisme d’exception, un groupe libre-service peut être créé pour chaque rôle. Par exemple, le groupe « exception marketing dans Salesforce » peut être créé en tant que groupe libre-service. Le groupe peut être affecté au rôle marketing dans Salesforce, tandis que les membres de l’équipe de direction du marketing peuvent être définis en tant que propriétaires. Les membres de l’équipe de direction du marketing peuvent ajouter ou supprimer des utilisateurs, définir une stratégie de jonction ou même approuver ou refuser les demandes de jonction formulées par des utilisateurs spécifiques. Ce mécanisme repose sur une expérience de travailleur de l’information appropriée qui ne nécessite pas de formation spécialisée pour les propriétaires ou les membres.

Dans ce cas, tous les utilisateurs attribués seraient automatiquement configurés dans Salesforce. Comme ils sont ajoutés à différents groupes, leur attribution de rôle est mise à jour dans Salesforce. Les utilisateurs peuvent découvrir Salesforce et y accéder par le biais de Mes applications, de clients web Office, ou de la page de connexion à Salesforce de leur organisation. Les administrateurs peuvent facilement afficher l’état de l’utilisation et des affectations à l’aide du signalement Microsoft Entra ID.

Les administrateurs peuvent utiliser l’accès conditionnel Microsoft Entra pour définir des stratégies d’accès pour des rôles spécifiques. Ces stratégies peuvent indiquer si l’accès est autorisé en dehors de l’environnement de l’entreprise, et même inclure des exigences d’authentification multifacteur ou liées aux appareils déterminant l’octroi de l’accès dans divers cas.

Accéder aux applications Microsoft

Les applications Microsoft (comme Exchange, SharePoint, Yammer, etc.) sont attribuées et gérées un peu différemment des applications SaaS non Microsoft et des autres applications que vous intégrez à Microsoft Entra ID pour l’authentification unique.

Il existe trois méthodes principales pour se connecter à une application publiée par Microsoft.

• Pour les applications faisant partie de Microsoft 365 ou d’autres suites payantes, les utilisateurs peuvent obtenir un accès via l’attribution de licence directement dans leur compte d’utilisateur ou via un groupe à l’aide de la fonctionnalité d’attribution de licence de groupe.

• Pour les applications publiées et fournies gratuitement par une organisation Microsoft ou non, les utilisateurs peuvent être autorisés à accéder via le consentement de l’utilisateur. Les utilisateurs se connectent à l’application avec leur compte professionnel ou scolaire Microsoft Entra et lui permettent d’accéder à certaines données de leur compte.

• Pour les applications publiées et fournies gratuitement par une organisation Microsoft ou non, les utilisateurs peuvent aussi être autorisés à accéder via le consentement de l’administrateur. Cela signifie qu’un administrateur a déterminé que l’application peut être utilisée par tous les membres de l’organisation. Il se connecte donc à l’application avec un Rôle d’administrateur privilégié et accorde l’accès à tous les membres de l’organisation.

Quelques applications combinent ces méthodes. Par exemple, certaines applications Microsoft font partie d'un abonnement Microsoft 365, mais exigent toujours le consentement.

Les utilisateurs peuvent accéder aux applications Microsoft 365 via leur portail Office 365. Vous pouvez également afficher ou masquer des applications Microsoft 365 dans Mes applications en activant/désactivant la visibilité d'Office 365 dans les Paramètres utilisateur de votre annuaire.

Comme pour les applications d'entreprise, vous pouvez attribuer des utilisateurs à certaines applications Microsoft via le centre d'administration Microsoft Entra ou à l'aide de PowerShell.

Empêcher l’accès aux applications via des comptes locaux

Microsoft Entra ID permet à votre organisation de configurer l’authentification unique pour protéger la façon dont les utilisateurs s’authentifient auprès des applications avec un accès conditionnel, une authentification multifacteur, etc. Certaines applications ont historiquement leur propre magasin d’utilisateurs local et permettent aux utilisateurs de se connecter à l’application à l’aide d’informations d’identification locales ou d’une méthode d’authentification de sauvegarde spécifique à l’application, au lieu d’utiliser l’authentification unique. Ces fonctionnalités d’application peuvent être mal utilisées et permettre aux utilisateurs de conserver l’accès aux applications, même quand ils ne sont plus affectés à l’application dans Microsoft Entra ID ou ne peuvent plus se connecter à Microsoft Entra ID, et peuvent permettre aux attaquants de tenter de compromettre l’application sans apparaître dans les journaux Microsoft Entra ID. Pour vous assurer que les connexions à ces applications sont protégées par Microsoft Entra ID :

• Identifiez les applications connectées à votre annuaire pour l’authentification unique afin de permettre aux utilisateurs finaux de contourner l’authentification unique avec des informations d’identification d’application locale ou une méthode d’authentification de secours. Vous devrez passer en revue la documentation fournie par le fournisseur d’applications pour comprendre si cela est possible et quels paramètres sont disponibles. Ensuite, dans ces applications, désactivez les paramètres qui permettent aux utilisateurs finaux de contourner le SSO. Testez l’expérience utilisateur final en ouvrant un navigateur dans InPrivate, en vous connectant à la page de connexion des applications, en fournissant l’identité d’un utilisateur de votre client et en vérifiant qu’il n’existe aucune autre option de connexion que Microsoft Entra.
• Si votre application fournit une API pour gérer les mots de passe utilisateur, supprimez les mots de passe locaux ou définissez un mot de passe unique pour chaque utilisateur à l’aide des API. Cela empêche les utilisateurs finaux de se connecter à l’application avec des informations d’identification locales.
• Si votre application fournit une API pour gérer les utilisateurs, configurez l’attribution d’utilisateurs Microsoft Entra sur cette application pour désactiver ou supprimer des comptes d’utilisateur lorsque les utilisateurs ne sont plus dans l’étendue de l’application ou du client.

Étapes suivantes

• Protection des applications avec un accès conditionnel
• Gestion des groupes en libre service/accès aux applications en libre-service