Share via

Approches architecturales concernant l’identité dans les solutions multilocataires

  • Article

Presque toutes les solutions multilocataires nécessitent un système d’identité. Dans cet article, nous abordons les composants courants de l’identité, notamment l’authentification et l’autorisation, et nous discutons de la façon dont ces composants peuvent être appliqués dans une solution multilocataire.

Notes

Passez en revue les considérations architecturales relatives à l’identité dans une solution multilocataire pour en savoir plus sur les principales exigences et décisions que vous devez prendre, avant de commencer à créer un système d’identité pour une solution multilocataire.

Authentification

L’authentification est le processus par lequel l’identité d’un utilisateur est établie. Lorsque vous créez une solution multilocataire, il existe des considérations et des approches spéciales pour plusieurs aspects du processus d’authentification.

Fédération

Vous devrez peut-être fédérer avec d’autres fournisseurs d’identité (IDP). La fédération peut être utilisée pour activer les scénarios suivants :

  • Connexion sociale, par exemple en permettant aux utilisateurs d’utiliser leur compte Google, Facebook, GitHub ou Microsoft personnel.
  • Répertoires spécifiques aux locataires, tels que l’activation des locataires pour fédérer votre application avec leurs propres fournisseurs d’identité, de sorte qu’ils n’ont pas besoin de gérer les comptes à plusieurs emplacements.

Pour plus d’informations sur la fédération, consultez le modèle d’identité fédérée.

Si vous choisissez de prendre en charge les fournisseurs d’identité spécifiques au locataire, assurez-vous de clarifier les services et protocoles dont vous avez besoin pour la prise en charge. Par exemple, allez-vous prendre en charge le protocole OpenID Connecter et le protocole SAML (Security Assertion Markup Language) ? Ou allez-vous plutôt uniquement prendre en charge la fédération avec les instances Microsoft Entra ?

Lorsque vous implémentez un fournisseur d’identité, envisagez toute mise à l’échelle et les limites qui peuvent s’appliquer. Par exemple, si vous utilisez Azure Active Directory (Azure AD) B2C comme fournisseur d’identité, vous devrez peut-être déployer des stratégies personnalisées pour fédérer avec certains types de fournisseurs d’identité de locataire. Azure AD B2C limite le nombre de stratégies personnalisées que vous pouvez déployer, ce qui peut limiter le nombre de fournisseurs d’identité spécifiques au locataire que vous pouvez fédérer.

Vous pouvez également envisager de fournir une fédération en tant que fonctionnalité qui s’applique uniquement aux clients d’un niveau de produit supérieur.

Authentification unique

Les expériences d’authentification unique permettent aux utilisateurs de basculer en toute transparence entre les applications, sans être invités à se réauthentifier à chaque point.

Lorsque les utilisateurs visitent une application, celle-ci les dirige vers un fournisseur d’identité. Si le fournisseur d’identité voit qu’il dispose d’une session existante, il émet un nouveau jeton sans que les utilisateurs interagissent avec le processus de connexion. Un modèle d’identité fédéré prend en charge les expériences d’authentification unique, en permettant aux utilisateurs d’utiliser une identité unique sur plusieurs applications.

Dans une solution multilocataire, vous pouvez également activer une autre forme d’authentification unique. Si les utilisateurs sont autorisés à utiliser des données pour plusieurs locataires, vous devrez peut-être fournir une expérience transparente lorsque les utilisateurs changent leur contexte d’un locataire à un autre. Déterminez si vous devez prendre en charge des transitions transparentes entre les locataires, et si c’est le cas, si votre fournisseur d’identité doit réémettre des jetons avec des revendications de locataire spécifiques. Par exemple, un utilisateur connecté au portail Azure peut basculer entre différents répertoires Microsoft Entra, ce qui provoque une réauthentication, et réécrit le jeton à partir de l’instance Microsoft Entra nouvellement sélectionnée.

Évaluation des risques de connexion

Les plateformes d’identité modernes prennent en charge une évaluation des risques pendant le processus de connexion. Par exemple, si un utilisateur se connecte à partir d’un emplacement ou d’un appareil inhabituel, le système d’authentification peut nécessiter des vérifications d’identité supplémentaires, telles que l’authentification multifacteur (MFA), avant d’autoriser la demande de connexion à continuer.

Déterminez si vos locataires peuvent avoir des stratégies de risque différentes qui doivent être appliquées pendant le processus d’authentification. Par exemple, si vous avez certains locataires dans un secteur hautement réglementé, ils peuvent avoir des profils de risque et des exigences différents aux locataires qui travaillent dans des environnements moins réglementés. Vous pouvez également choisir d’autoriser les locataires à des niveaux tarifaires plus élevés pour spécifier des stratégies de connexion plus restrictives que les locataires qui achètent un niveau inférieur de votre service.

Si vous devez prendre en charge différentes stratégies de risque pour chaque locataire, votre système d’authentification doit savoir quel locataire l’utilisateur se connecte, afin qu’il puisse appliquer les stratégies appropriées.

Si votre fournisseur d’identité inclut ces fonctionnalités, envisagez d’utiliser les fonctionnalités d’évaluation des risques de connexion native du fournisseur d’identité. Ces fonctionnalités peuvent être complexes et sujettes aux erreurs pour vous implémenter vous-même.

Autrement, si vous fédérez les propres fournisseurs d’identité des locataires, alors leurs propres stratégies d’atténuation des connexions risquées peuvent être appliquées, et elles peuvent contrôler les stratégies et les contrôles qui doivent être appliqués. Toutefois, il est important d’éviter d’ajouter par inadvertance une charge inutile à l’utilisateur, par exemple en nécessitant deux défis MFA, l’un du fournisseur d’identité domestique de l’utilisateur et l’autre de votre propre. Assurez-vous de comprendre comment la fédération interagit avec chacun des fournisseurs d’identité de vos locataires et les stratégies qu’ils ont appliquées.

Emprunt d'identité

L’emprunt d’identité permet à un utilisateur de prendre l’identité d’un autre utilisateur, sans utiliser les informations d’identification de cet utilisateur.

En général, l’emprunt d’identité est dangereux et il peut être difficile d’implémenter et de contrôler. Néanmoins, dans certains scénarios, l’emprunt d’identité est obligatoire. Par exemple, si vous utilisez un logiciel en tant que service (SaaS), votre personnel du support technique peut avoir besoin de supposer l’identité d’un utilisateur afin qu’il puisse se connecter en tant qu’utilisateur et résoudre un problème.

Si vous choisissez d’implémenter l’emprunt d’identité, tenez compte de la façon dont vous auditez son utilisation. Assurez-vous que vos journaux incluent à la fois l’utilisateur réel qui a effectué l’action et l’identificateur de l’utilisateur qu’il a emprunté.

Certaines plateformes d’identité prennent en charge l’emprunt d’identité, soit en tant que fonctionnalité intégrée, soit en utilisant du code personnalisé. Par exemple, dans Azure AD B2C, vous pouvez ajouter une revendication personnalisée pour l’ID d’utilisateur emprunt d’identité ou remplacer la revendication d’identificateur d’objet dans les jetons émis.

Autorisation

L’autorisation est le processus de détermination de ce qu’un utilisateur est autorisé à faire.

Les données d’autorisation peuvent être stockées dans plusieurs emplacements, notamment dans les emplacements suivants :

  • Sélectionnez votre fournisseur d’identités. Par exemple, si vous utilisez Microsoft Entra ID comme fournisseur d’identité, vous pouvez utiliser des fonctionnalités telles que des rôles d’application et des groupes pour stocker des informations d’autorisation. Votre application peut ensuite utiliser les revendications de jeton associées pour appliquer vos règles d’autorisation.
  • Dans votre application. Vous pouvez créer votre propre logique d’autorisation, puis stocker des informations sur ce que chaque utilisateur peut faire dans une base de données ou un système de stockage similaire. Vous pouvez ensuite concevoir des contrôles affinés pour l’autorisation au niveau du rôle ou au niveau des ressources.

Dans la plupart des solutions multilocataires, les attributions de rôle et d’autorisation sont gérées par le locataire ou le client, et non par vous en tant que fournisseur du système multilocataire.

Pour plus d’informations, consultez Rôles d’application.

Ajouter des informations sur l’identité et le rôle du locataire aux jetons

Considérez la partie ou les parties de votre solution qui doivent effectuer des demandes d’autorisation, notamment déterminer si un utilisateur est autorisé à utiliser des données à partir d’un locataire spécifique.

Une approche courante est que votre système d’identité incorpore une revendication d’identificateur de locataire dans un jeton. Cette approche permet à votre application d’inspecter la revendication et de vérifier que les utilisateurs travaillent avec le locataire auquel ils sont autorisés à accéder. Si vous utilisez le modèle de sécurité basé sur le rôle, vous pouvez choisir d’étendre le jeton avec des informations sur le rôle qu’un utilisateur a au sein du locataire.

Cependant, si un seul utilisateur est autorisé à accéder à plusieurs locataires, vous devrez peut-être indiquer à quel locataire il envisage de travailler pendant le processus de connexion. Après avoir sélectionné leur locataire actif, le fournisseur d’identité peut inclure la revendication et le rôle d’identificateur de locataire appropriés pour ce locataire, dans le jeton qu’il émet. Vous devez également prendre en compte la façon dont les utilisateurs peuvent basculer entre les locataires, ce qui nécessite l’émission d’un nouveau jeton.

Autorisation basée sur les autorisations

Une autre approche consiste à rendre le système d’identité indépendant des identificateurs de locataire et des rôles. Les utilisateurs sont identifiés à l’aide de leurs informations d’identification ou d’une relation de fédération, et les jetons n’incluent pas de revendication d’identificateur de locataire. Une liste ou une base de données séparée contient les utilisateurs qui ont été autorisés à accéder à chaque locataire. Ensuite, le niveau d’application peut vérifier si l’utilisateur spécifié doit être autorisé à accéder aux données d’un locataire spécifique, en fonction de la recherche de cette liste.

Utiliser Microsoft Entra ID ou Azure AD B2C

Microsoft fournit Microsoft Entra ID et Azure AD B2C, qui sont des plateformes d’identité managées que vous pouvez utiliser dans votre propre solution multilocataire.

De nombreuses solutions multilocataires sont des logiciels en tant que service (SaaS). Votre choix entre Microsoft Entra ID et Azure AD B2C dépend, en partie, de la façon dont vous définissez vos locataires ou votre base de clients.

  • Si vos locataires ou vos clients sont des organisations, ils peuvent déjà utiliser Microsoft Entra ID pour des services tels qu’Office 365, Microsoft Teams ou pour leurs propres environnements Azure. Vous pouvez créer une application multilocataire dans votre propre annuaire Microsoft Entra pour rendre votre solution disponible auprès d’autres répertoires Microsoft Entra. Vous pouvez même répertorier votre solution dans la Place de marché Azure et la rendre facilement accessible aux organisations qui utilisent Microsoft Entra ID.
  • Si vos locataires ou clients n’utilisent pas Microsoft Entra ID, ou s’ils sont des individus plutôt que des organisations, envisagez d’utiliser Azure AD B2C. Azure AD B2C fournit un ensemble de fonctionnalités pour contrôler la façon dont les utilisateurs s’inscrivent et se connectent. Par exemple, vous pouvez restreindre l’accès à votre solution uniquement aux utilisateurs que vous avez déjà invités, ou vous pouvez autoriser l’inscription en libre-service. Utilisez des stratégies personnalisées dans Azure AD B2C pour contrôler entièrement la façon dont les utilisateurs interagissent avec la plateforme d’identité. Vous pouvez utiliser la marque personnalisée et vous pouvez fédérer Azure AD B2C avec votre propre locataire Microsoft Entra pour permettre à votre propre personnel de se connecter. Azure AD B2C active également la fédération avec d’autres fournisseurs d’identité.
  • Certaines solutions mutualisées sont destinées aux deux situations répertoriées ci-dessus. Certains locataires peuvent avoir leurs propres locataires Microsoft Entra quand d’autres n’en ont pas forcément. Vous pouvez également utiliser Azure AD B2C pour ce scénario et utiliser des stratégies personnalisées pour autoriser la connexion utilisateur à partir du répertoire Microsoft Entra d’un locataire. Toutefois, si vous utilisez des stratégies personnalisées pour établir la fédération entre les locataires, veillez à prendre en compte les limites du nombre de stratégies personnalisées qu’un seul annuaire Azure AD B2C peut utiliser.

Pour plus d’informations, consultez Considérations relatives à l’utilisation d’Azure Active Directory B2C dans une architecture multilocataire.

Antimodèles à éviter

Création ou exécution de votre propre système d’identité

La création d’une plateforme d’identité moderne est complexe. Il existe un éventail de protocoles et de normes à prendre en charge, et il est facile d’implémenter incorrectement un protocole et d’exposer une vulnérabilité de sécurité. Les normes et protocoles changent, et vous devez également mettre à jour continuellement votre système d’identité pour atténuer les attaques et prendre en charge les fonctionnalités de sécurité récentes. Il est également important de s’assurer qu’un système d’identité est résilient, car tout temps d’arrêt peut avoir des conséquences graves pour le reste de votre solution. En outre, dans la plupart des cas, l’implémentation d’un fournisseur d’identité n’ajoute pas d’avantage à l’entreprise, et il s’agit simplement d’une partie nécessaire de l’implémentation d’un service mutualisé. Il est préférable d’utiliser plutôt un système d’identité spécialisé conçu, exploité et sécurisé par des experts.

Lorsque vous exécutez votre propre système d’identité, vous devez stocker des hachages de mot de passe ou d’autres formes d’informations d’identification, qui deviennent une cible tentante pour les attaquants. Même le hachage et le sel de mots de passe sont souvent insuffisants, car la puissance de calcul disponible pour les attaquants peut permettre de compromettre ces formes d’informations d’identification.

Lorsque vous exécutez un système d’identité, vous êtes également responsable de la génération et de la distribution de codes MFA ou de mot de passe à usage unique (OTP). Ces exigences signifient alors que vous avez besoin d’un mécanisme pour distribuer ces codes, à l’aide de SMS ou de courrier électronique. En outre, vous êtes responsable de la détection des attaques ciblées et par force brute, de limitation des tentatives de connexion, d’audit, et ainsi de suite.

Au lieu de créer ou d’exécuter votre propre système d’identité, il est recommandé d’utiliser un service ou un composant hors service. Par exemple, envisagez d’utiliser Microsoft Entra ID ou Azure AD B2C, qui sont des plateformes d’identité managée. Les fournisseurs de plateforme d’identité managée prennent en charge l’exploitation de l’infrastructure pour leurs plateformes, et généralement pour prendre en charge les normes actuelles d’identité et d’authentification.

Échec de la prise en compte des exigences de vos locataires

Les locataires ont souvent des opinions fortes sur la façon dont l’identité doit être gérée pour les solutions qu’ils utilisent. Par exemple, de nombreux clients d’entreprise nécessitent une fédération avec leurs propres fournisseurs d’identité, pour activer des expériences d’authentification unique et éviter de gérer plusieurs ensembles d’informations d’identification. D’autres locataires peuvent nécessiter l’authentification multifacteur ou d’autres formes de protection autour des processus de connexion. Si vous n’avez pas conçu pour ces exigences, il peut être difficile de les mettre à niveau ultérieurement.

Veillez à comprendre les exigences d’identité de vos locataires avant de finaliser la conception de votre système d’identité. Passez en revue les considérations architecturales relatives à l’identité dans une solution multilocataire pour comprendre certaines exigences spécifiques qui apparaissent souvent.

Confusion des utilisateurs et des locataires

Il est important de prendre clairement en compte la façon dont votre solution définit un utilisateur et un locataire. Dans de nombreuses situations, la relation peut être complexe. Par exemple, un locataire peut contenir plusieurs utilisateurs, et un seul utilisateur peut rejoindre plusieurs locataires.

Vérifiez que vous disposez d’un processus clair pour le suivi du contexte du locataire, dans votre application et vos demandes. Dans certains cas, ce processus peut nécessiter que vous incluiez un identificateur de locataire dans chaque jeton d’accès et que vous validiez l’identificateur de locataire sur chaque requête. Dans d’autres cas, vous stockez les informations d’autorisation du locataire séparément des identités utilisateur, et vous utilisez un système d’autorisation plus complexe pour gérer les utilisateurs qui peuvent effectuer les opérations sur lesquelles les locataires.

Le suivi du contexte client d’un utilisateur ou d’un jeton s’applique à n’importe quel modèle de location, car une identité utilisateur possède toujours un contexte de locataire dans une solution multilocataire. Il est même recommandé de suivre le contexte du locataire lorsque vous déployez des tampons indépendants pour un seul locataire, ce qui prouve votre codebase pour d’autres formes de multilocataire.

Conflatage du rôle et de l’autorisation des ressources

Il est important de sélectionner un modèle d’autorisation approprié pour votre solution. Les approches de sécurité basées sur des rôles peuvent être simples à implémenter, mais l’autorisation basée sur les ressources fournit un contrôle plus précis. Tenez compte des exigences de vos locataires et indiquez si vos locataires doivent autoriser certains utilisateurs à accéder à des parties spécifiques de votre solution, et non à d’autres parties.

Échec de l’écriture des journaux d’audit

Les journaux d’audit sont un outil important pour comprendre votre environnement et comment les utilisateurs implémentent votre système. En auditant chaque événement lié à l’identité, vous pouvez souvent déterminer si votre système d’identité est en cours d’attaque et vous pouvez examiner la façon dont votre système est utilisé. Vérifiez que vous écrivez et stockez les journaux d’audit au sein de votre système d’identité. Déterminez si les journaux d’audit des identités de votre solution doivent être mis à la disposition des locataires à examiner.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

Autres contributeurs :

Étapes suivantes

Passez en revue les Considérations architecturales pour une solution multilocataire.