Langue :
Les applications enregistrées dans Microsoft Entra ID pour faciliter la connexion peuvent demander une authentification à tenant unique ou multi-tenant, également appelée « audience de connexion ». L'authentification à tenant unique restreint l'accès aux utilisateurs du même tenant, tandis que l'authentification multi-tenant autorise l'accès aux utilisateurs de n'importe quel tenant Entra. Cette différence entre les applications à tenant unique et les applications multi-tenant peut avoir des implications sur la sécurité. Le fait de ne pas configurer une application comme multi-tenant en ayant pleinement conscience de ce que cela implique et sans mettre en œuvre les précautions nécessaires peut poser des risques de sécurité.
L'exposition des applications multi-tenant est plus élevée en raison de la possibilité qu'un utilisateur Entra malveillant de n'importe quel tenant les découvre et y accède. Si le code de l'application ne prend pas en compte cette configuration, par exemple en ne vérifiant pas la présence du tenant source de l'utilisateur dans une liste de tenants autorisés, cela peut mener à un accès non autorisé. Les applications vulnérables sont celles qui partent du principe que l'authentification est légitime et qui accordent un accès sur la simple présentation d'un jeton valide, sans effectuer de vérifications supplémentaires. Ce type de vulnérabilité appartient au domaine des failles « authentification (AuthN) vs autorisation (AuthZ) ». Selon le « modèle de responsabilité partagée », Entra ID traite l'authentification des utilisateurs, tandis que l'aspect autorisation incombe à l'application.
Même Microsoft a été victime de cette confusion en mars 2023, comme l'indique l'étude de cas «BingBang ». Les chercheurs en sécurité ont pu exploiter cette mauvaise configuration pour compromettre plusieurs applications Microsoft, dont le portail de gestion du moteur de recherche Bing. Microsoft a traité cette vulnérabilité dans son application, mais cet incident souligne que des vulnérabilités similaires peuvent affecter vos propres applications et que vous devez les examiner et les corriger si nécessaire.
Les applications multi-tenants sont également sujettes à d'autres confusions en matière d'authentification, comme la faille nOAuth.
Il existe des cas d'utilisation légitimes pour les applications multi-tenants, en particulier si votre organisation héberge des applications destinées à l'accès d'autres organisations (par exemple, en tant qu'éditeur de logiciels ou dans le cadre d'une collaboration inter-organisation) ou d'utilisateurs d'un tenant différent mais au sein de la même organisation (par exemple, avec un tenant par sous-traitant). Ces applications ne sont vulnérables que si elles reposent uniquement sur une authentification réussie sans effectuer de contrôles d'autorisation supplémentaires. Cet indicateur d'exposition ne peut pas déterminer si une application est destinée à être publique ou si l'authentification multi-tenant a été délibérément activée. Il ne peut pas non plus déterminer si l'utilisation multi-tenant est réellement nécessaire. En l'absence d'accès au code de l'application, il ne peut pas non plus vérifier si les vérifications d'autorisation requises sont en place. Pour ces raisons, toutes les applications multi-tenants sont signalées comme des détections que vous devez examiner individuellement. Une fois confirmées, vous pouvez les marquer comme ignorées.
Examinez l'application avec l'aide de son propriétaire pour vérifier que sa nature multi-tenant correspond bien à ce qui est prévu. Assurez-vous que cette configuration a été activée en tenant pleinement compte des différences entre les applications à tenant unique et les applications multi-tenants. Confirmez que l'application peut prendre en charge les utilisateurs d'autres tenants en plus de celui dans lequel elle est enregistrée.
Si l'application est publique, vous pouvez également le spécifier afin que cet indicateur d'exposition puisse l'ignorer.
Si l'application ne nécessite pas d'authentification multi-tenant, vous pouvez la faire basculer à nouveau vers le mode tenant unique. Cependant, veuillez noter qu'Entra ID applique différentes règles de validation aux applications en fonction des types de comptes pris en charge. Par conséquent, il n'est pas toujours possible de passer au mode tenant unique sans ajuster d'autres paramètres. Soyez prudent et examinez attentivement les implications de chaque modification. Vous pouvez suivre les instructions de Microsoft pour mettre à jour l'audience ou utiliser la procédure suivante :
microsoft.directory/applications/audience/update
).Au contraire, si l'application nécessite une authentification multi-tenant, confirmez auprès de son développeur que le code inclut des contrôles d'autorisation supplémentaires sur les jetons d'authentification reçus. Cette étape est appelée validation des revendications.
Lorsque vous confirmez que ces vérifications sont en place, ou si l'application est destinée à être publique, vous pouvez marquer l'application de manière à ce que cet indicateur d'exposition l'ignore.
Remarque : les stratégies d'accès conditionnel ne s'appliquent qu'aux utilisateurs du même tenant. Par conséquent, elles ne peuvent pas restreindre l'accès à vos applications multi-tenants aux utilisateurs d'autres tenants.
En outre, nous recommandons de suivre les conseils officiels de Microsoft sur la mauvaise configuration potentielle de l'autorisation pour les applications multi-tenants à l'aide d'Entra ID, qui inclut des recommandations spécifiques supplémentaires.
Enfin, les administrateurs Entra et Azure doivent être formés à faire le bon choix entre les configurations à tenant unique et multi-tenants lors de la création d'applications, soit par le biais de la page d'inscription d'applications Entra, soit par le biais de la création d'un service d'application Azure.
Nom: Application permettant l'authentification multi-tenant
Nom de code: APPLICATION-ALLOWING-MULTI-TENANT-AUTHENTICATION
Sévérité: Low
Type: Microsoft Entra ID Indicator of Exposure