Gestion des identités et des accès pour les charges de travail SaaS sur Azure
L’identité d’application est un domaine essentiel pour les charges de travail SaaS, car elle sert de première ligne de défense pour la protection des données. Il est souvent négligé jusqu’à la fin d’un projet, mais de nombreuses décisions concernant d’autres éléments de l’application dépendent d’une stratégie d’identité solide. Ne sous-estimez pas l’importance de l’identité pour aider à protéger les données de vos clients.
Dans le contexte des charges de travail SaaS, il existe deux types d’identité distincts.
L’identité d’application, également appelée gestion des identités et des accès des clients (CIAM), permet aux utilisateurs finaux de s’authentifier et d’utiliser votre application SaaS. Il existe deux méthodes principales pour connecter des utilisateurs à un fournisseur d’identité d’application :
Identités fédérées. Les utilisateurs se connectent avec des informations d’identification existantes conservées par un autre fournisseur d’identité. Ce fournisseur peut être un fournisseur d’identité sociale tel que Google, Facebook ou LinkedIn, ou un fournisseur d’identité d’entreprise que vos clients utilisent, tel que Microsoft Entra ou Okta. La maintenance du compte de l’utilisateur est la responsabilité du fournisseur d’identité fédéré.
Identités locales. Les utilisateurs créent un compte uniquement pour votre application. Le compte est sécurisé par nom d’utilisateur et mot de passe, clé secrète ou d’autres méthodes d’authentification. La maintenance du compte de l’utilisateur est votre responsabilité.
L’identité d’entreprise est la solution d’identité utilisée pour authentifier les utilisateurs internes et les charges de travail aux outils de productivité métier, aux outils ou services internes et aux services Azure. Vous utilisez une solution d’identité d’entreprise pour vos utilisateurs et charges de travail internes pour les authentifier auprès des outils de productivité métier, des outils internes ou des services Azure.
Reportez-vous à LA gestion des identités et des accès SE :05.
Les identités d’application et d’entreprise servent à des fins différentes et peuvent utiliser différents fournisseurs d’identité. Cet article se concentre sur les considérations relatives à la conception de l’identité d’application, bien que les deux types soient susceptibles d’être présents dans votre environnement de charge de travail SaaS.
La gestion des identités implique deux problèmes connexes : l’authentification (vérification de l’identité d’un utilisateur) et l’autorisation (octroi d’autorisations basées sur l’identité). Les trois premières sections de cet article se concentrent sur l’authentification pour SaaS. La dernière section traite des considérations relatives à l’autorisation pour les fournisseurs SaaS.
Identité dans une application mutualisée
La séparation des données client dans une application mutualisée est essentielle. Cette segmentation est pilotée par votre choix d’authentification et d’autorisation utilisateur effectives. En outre, le choix du modèle de location influence considérablement vos décisions sur le fournisseur d’identité. Hiérarchiser l’identité comme périmètre principal.
Reportez-vous aux recommandations SE :04 pour la segmentation.
Considérations sur la conception
Comprendre les modèles de location et de déploiement pour votre application. Il peut y avoir des nuances qui influencent votre stratégie d’identité. Par exemple, il est faux que le modèle Empreintes de déploiement nécessite un fournisseur d’identité dans chaque tampon. Pour la plupart des fournisseurs d’identité, vous pouvez souvent utiliser un autre modèle d’isolation.
Lorsque vous choisissez votre fournisseur d’identité pour l’architecture mutualisée, évaluez l’impact des défaillances. Les configurations incorrectes peuvent potentiellement réduire l’intégralité de votre application pour tous les locataires. Pesez les coûts de surcharge par rapport au risque du rayon potentiel d’impact.
Si vous déployez votre solution dans l’environnement Azure d’un client et que vous la gérez pour son compte, vous devrez peut-être l’intégrer à son fournisseur d’identité d’entreprise. Comprenez clairement ces aspects :
- Les types d’utilisateurs et leurs besoins d’accès lorsqu’ils interagissent avec vos locataires d’application. Par exemple, l’utilisateur A peut avoir uniquement besoin d’accéder à la connexion au locataire 1, mais l’utilisateur B peut avoir besoin d’accéder à la connexion à la fois au locataire 1 et au locataire 2.
- Conformité aux réglementations de résidence des données, si elles s’appliquent à votre fournisseur d’identité. Dans certains cas, les données stockées par un fournisseur d’identité peuvent être soumises à des réglementations. De nombreux fournisseurs d’identité fournissent des conseils et des fonctionnalités spécifiques pour ce scénario. Évaluez si ce scénario est pertinent pour vous et prenez les mesures nécessaires pour garantir la conformité.
Recommandations de conception
| Recommandation | Avantage |
|---|---|
| Suivez les bonnes pratiques et recommandations de votre fournisseur d’identité pour partitionner la solution pour plusieurs locataires. | L’isolation des locataires vous aide à atteindre vos objectifs de sécurité et de conformité. |
| Évitez d’avoir plusieurs comptes pour le même utilisateur. Un utilisateur doit avoir un seul compte avec un ensemble d’informations d’identification, même s’il a besoin d’accéder à plusieurs locataires. Accordez l’accès à chaque locataire en fonction des besoins plutôt que de créer plusieurs comptes pour le même utilisateur. | La création de plusieurs comptes pour le même utilisateur augmente les risques de sécurité et peut confondre les utilisateurs qui doivent mémoriser plusieurs noms d’utilisateur et mots de passe pour le même logiciel. |
| Lorsque vous envisagez la résidence des données, envisagez de stocker des données utilisateur dans des emplacements distincts. Si vous déployez un tampon de déploiement distinct pour vos utilisateurs dans d’autres zones géographiques, vous pouvez également avoir besoin de fournisseurs d’identité distincts. Vérifiez que vous disposez d’un moyen d’identifier l’emplacement de stockage des données des utilisateurs afin de pouvoir les diriger vers la région appropriée pour la connexion, si nécessaire. |
Vous serez en mesure de prendre en charge vos exigences de conformité et d’améliorer l’expérience utilisateur en acheminant les utilisateurs vers l’expérience de connexion appropriée pour leur emplacement. |
Sélection du fournisseur d’identité
Chaque fournisseur d’identité offre des fonctionnalités uniques, des limitations, des modèles tarifaires et des modèles d’implémentation. Microsoft Entra et Okta sont des options d’identité populaire en tant que service (IDaaS). Il existe également d’autres fournisseurs code source ouvert, tels que Keycloak et Authentik.
Considérations sur la conception
Documentez vos exigences d’identité. Commencez par répertorier les fonctionnalités dont votre application a besoin maintenant et en aurez besoin à l’avenir. Les fonctionnalités classiques à prendre en compte sont les suivantes :
-
- Prise en charge du fournisseur d’identité fédérée pour s’intégrer aux solutions d’identité des clients. Cette fonctionnalité vous permet d’éviter de créer de nouvelles identités.
- Flux de connexion/inscription personnalisable pour modifier l’apparence et l’apparence de votre personnalisation. Cette fonctionnalité permet également d’injecter une logique métier personnalisée dans le processus de connexion/d’inscription.
- Séparation des données de locataire en silos distincts pour maintenir l’isolation du locataire.
- Prise en charge de l’audit pour conserver ou exporter les journaux de connexion pour la gestion de la sécurité.
Important
Considérez votre croissance de l’utilisateur planifiée lorsque vous évaluez le coût d’une solution d’identité. Une solution peut ne pas rester rentable ou évolutive à long terme, mais elle peut être utile pour l’instant. Disposez d’un plan de migration que vous pouvez utiliser si le besoin se produit.
Par exemple, une solution peut être abordable pour 500 utilisateurs, mais non durable pour 5 millions. S’il nécessite une configuration minimale et est convivial et facile à migrer, il peut toujours être le bon choix jusqu’à ce que les coûts de mise à l’échelle justifient le passage à une autre solution.
Recherchez minutieusement les fonctionnalités du fournisseur d’identité. Vérifiez que la solution d’identité correspond à votre liste de fonctionnalités requises. Même si vous n’avez pas besoin de scénarios complexes comme l’identité fédérée, tenez compte des besoins futurs. Pour les solutions SaaS métier à entreprise (B2B), l’identité fédérée sera probablement nécessaire.
Facteur de surcharge de gestion. Différents fournisseurs d’identité nécessitent différents niveaux de surcharge de gestion. Les solutions IDaaS connues ont généralement moins de surcharge, car elles gèrent l’hébergement, la maintenance et la sécurité. Toutefois, la surcharge supplémentaire d’une solution code source ouvert peut être utile si la solution est mieux adaptée à vos besoins spécialisés.
Recommandations de conception
| Recommandation | Avantage |
|---|---|
| Ne créez pas votre propre solution d’identité. L’identité est un domaine hautement spécialisé et la création d’une solution d’identité est complexe et coûteuse. Il est difficile de créer une solution d’identité sécurisée et fiable. | Vous éviterez l’antimodèle de la création de votre propre fournisseur et améliorerez la sécurité, la fiabilité et l’efficacité opérationnelle de votre solution. |
| Créez une matrice de fonctionnalités des fonctionnalités offertes par les fournisseurs d’identité et mappez-les à vos exigences d’identité. | Vous serez en mesure d’évoluer sans être contraint par un ensemble limité de fonctionnalités d’identité. |
| Préférer les options IDaaS aux solutions code source ouvert. L’hébergement d’une solution code source ouvert vous-même entraîne une surcharge opérationnelle et des risques de sécurité importants. Toutefois, vous pouvez choisir cette option pour répondre à des exigences spécifiques en matière de conformité, de résidence des données ou de fiabilité qu’un fournisseur ne peut pas remplir. Pour plus d’informations, consultez fournisseurs d’identité IDaaS. |
En utilisant un fournisseur d’identité IDaaS, vous éviterez une complexité inutile et vous pouvez concentrer vos efforts sur votre activité principale. |
Identité fédérée
L’identité fédérée, également appelée authentification unique (SSO), permet aux utilisateurs de se connecter avec les informations d’identification qu’ils utilisent déjà ailleurs. Vous activez l’identité fédérée en établissant une relation d’approbation entre votre fournisseur d’identité d’application et le fournisseur d’identité existant du client. L’identité fédérée est une exigence courante pour les solutions SaaS, en particulier dans B2B, car les clients préfèrent que leurs employés utilisent des informations d’identification d’entreprise. Il offre plusieurs avantages pour les solutions B2B, telles que la gestion centralisée des identités et la gestion automatique du cycle de vie. Dans les produits SaaS B2C, l’intégration à des fournisseurs d’identité sociale est courante pour permettre aux utilisateurs de se connecter avec des informations d’identification existantes.
Compromis : complexité et efficacité opérationnelle. En travaillant avec des fournisseurs d’identité fédérés, vous déchargez la complexité de la gestion des identités de vos utilisateurs. Toutefois, vous prenez le coût de l’intégration à un autre fournisseur d’identité. Décidez où vous souhaitez concentrer vos efforts opérationnels.
Bien que l’implémentation d’une identité fédérée soit initialement simple, elle devient plus complexe à mesure que le nombre de fournisseurs d’identité pris en charge augmente. Une planification minutieuse est essentielle, en particulier si chaque client utilise un fournisseur d’identité unique. Même s’ils utilisent le même fournisseur d’identité, les relations d’approbation uniques sont souvent requises pour chaque client en raison de détails de configuration spécifiques.
Cette image montre la relation entre votre application, votre fournisseur d’identité d’application et les fournisseurs d’identité en aval que vous pouvez choisir d’implémenter à l’aide de la fédération d’identité.
Considérations sur la conception
Estimer les types et le nombre de fournisseurs d’identité que vous devez prendre en charge. Vous aurez peut-être besoin d’un nombre statique de fournisseurs d’identité sociale, ou vous aurez peut-être besoin de fournisseurs d’identité fédérés uniques pour chaque client. Vous devez savoir si vos clients utilisent OpenID Connect (OIDC), Security Assertion Markup Language (SAML) ou les deux pour l’intégration.
Mapper l’expérience de connexion. Visualisez le flux utilisateur du processus d’inscription et de connexion. Notez les exigences particulières susceptibles de modifier votre conception de flux utilisateur. Par exemple :
Personnalisation personnalisée. Étiquetage blanc ou domaines de connexion personnalisés par client.
Informations personnalisées. Collecte d’informations utilisateur supplémentaires lors de l’inscription ou de la connexion, telles que la sélection du locataire pour les utilisateurs ayant accès à plusieurs locataires.
Sélection du fournisseur d’identité. Si vous utilisez un seul fournisseur d’identité d’application qui a de nombreux fournisseurs d’identité fédérés qui lui font confiance, décidez comment sélectionner un fournisseur. Cette sélection peut être effectuée manuellement via un bouton ou automatiquement en fonction des informations utilisateur connues. À mesure que le nombre de fournisseurs augmente, la sélection automatique devient plus pratique. Cette fonctionnalité est connue sous le nom de découverte de domaine d’accueil.
Recommandations de conception
| Recommandation | Avantage |
|---|---|
| Choisissez un fournisseur d’identité qui peut être mis à l’échelle pour prendre en charge le nombre de fournisseurs d’identité fédérés dont vous avez besoin. N’oubliez pas les limites strictes du fournisseur, qui ne peuvent pas être dépassées. |
Vous allez vous assurer que votre solution d’identité peut évoluer à mesure que vous augmentez. |
| Planifiez l’intégration de chaque fournisseur d’identité fédérée et automatisez le processus autant que possible. Cet effort collaboratif entre votre organisation et vos clients implique l’échange d’informations pour établir une relation d’approbation, généralement via des protocoles OIDC ou SAML. |
L’intégration des identités peut prendre du temps et des efforts pour vous et vos clients. En planifiant le processus, vous améliorerez votre efficacité opérationnelle. |
| Reflètez la complexité et le coût de l’identité fédérée dans votre tarification et votre modèle métier. Permettre aux clients d’utiliser leur propre fournisseur d’identité augmente la complexité opérationnelle et les coûts en raison de la surcharge liée à la gestion de plusieurs relations d’approbation d’identité fédérée. Il est courant dans les solutions SaaS pour les entreprises de payer pour un niveau supérieur qui permet la connexion fédérée. |
La fédération avec le fournisseur d’identité d’un client peut être un coût masqué dans les solutions SaaS. En la planifiant, vous éviterez les coûts inattendus pendant l’implémentation. |
| Planifiez la sélection du fournisseur d’identité d’un utilisateur pendant le flux de connexion. Envisagez d’utiliser la découverte de domaine d’accueil. Microsoft Entra ID fournit la découverte intégrée du domaine d’accueil. |
Vous allez simplifier votre expérience client et vous assurer que les utilisateurs sont dirigés vers le processus de connexion approprié. |
Autorisation
L’autorisation utilisateur est essentielle pour les applications SaaS, qui stockent souvent des données pour plusieurs locataires. Définissez clairement comment les utilisateurs seront autorisés à accéder uniquement à leurs données sans accéder par inadvertance aux données d’autres locataires. En outre, fournissez une autorisation granulaire au sein d’un locataire, ce qui permet aux utilisateurs de lire ou d’accéder à certaines informations tout en limitant les mises à jour ou l’accès à d’autres données.
Considérations sur la conception
Choisissez le modèle d’autorisation approprié pour le cas d’usage. Il existe deux types principaux :
- Autorisation basée sur les rôles. Les utilisateurs sont affectés à des rôles ou groupes, et des fonctionnalités spécifiques sont limitées à certains rôles. Par exemple, les administrateurs peuvent effectuer n’importe quelle action, mais les utilisateurs d’autres rôles disposent d’autorisations limitées.
- Autorisation basée sur les ressources. Chaque ressource a son propre ensemble d’autorisations. Un utilisateur peut être administrateur pour une ressource, mais n’a pas accès à une autre.
Déterminez où stocker les données d’autorisation. Les données d’autorisation pour votre application peuvent être stockées dans :
- Votre fournisseur d’identité. Tirez parti des groupes ou rôles intégrés, en exposant les autorisations en tant que revendications dans le jeton émis à votre application. Votre application peut ensuite appliquer des règles d’autorisation à l’aide de ces revendications de jeton.
- Votre application. Développez votre propre logique d’autorisation et stockez les autorisations utilisateur dans une base de données ou un système similaire, ce qui permet des contrôles d’autorisation précis basés sur des rôles ou au niveau des ressources.
Compromis : complexité, flexibilité et sécurité. Le stockage des données d’autorisation dans un fournisseur d’identité et la présentation par le biais de revendications de jetons est généralement plus simple que la gestion de votre propre système d’autorisation. Toutefois, l’autorisation basée sur les revendications limite votre flexibilité et vous devez accepter que les revendications soient actualisées uniquement lorsqu’un jeton est réédité, ce qui peut entraîner un retard dans l’application des autorisations modifiées.Évaluez l’impact de la gestion déléguée. Dans la plupart des applications SaaS, en particulier dans les applications B2B, la gestion des rôles et des autorisations est déléguée aux clients. Sans cette fonctionnalité, vous pouvez augmenter votre surcharge de gestion si les clients modifient fréquemment les autorisations de leurs utilisateurs.
Évaluez l’accès multilocataire. Dans certains systèmes, un seul utilisateur peut avoir besoin d’accéder aux données de plusieurs locataires. Par exemple, les consultants peuvent avoir besoin d’accéder aux données de plusieurs locataires. Planifiez la façon dont les clients accorderont l’accès à ces utilisateurs et la façon dont votre flux de connexion prendra en charge la sélection et le basculement entre les locataires.
Recommandations de conception
| Recommandation | Avantage |
|---|---|
| Empêcher les utilisateurs d’accéder aux données au-delà des limites du locataire, sauf si cet accès est explicitement autorisé. | L’accès non autorisé aux données d’un autre locataire, même accidentelle, peut être considéré comme un incident de sécurité majeur et éroder la confiance des clients dans votre plateforme. Le blocage de l’accès inutile vous aidera à éviter ces situations. |
| Si les données sont statiques et changent rarement, stockez-les dans le fournisseur d’identité. Si des modifications fréquentes sont nécessaires pendant que l’utilisateur utilise le logiciel, stockez les données d’autorisation dans votre application. | La sélection du meilleur magasin de données pour vos données d’autorisation améliore votre efficacité opérationnelle et vous aide à répondre à vos besoins d’extensibilité. |
| Si vous délèguez la gestion des autorisations aux clients, fournissez une méthode claire pour gérer les autorisations. Par exemple, créez un portail web accessible uniquement aux administrateurs clients pour modifier les autorisations utilisateur. | Vous allez fournir davantage de contrôle à vos clients et éviter les charges opérationnelles inutiles sur votre équipe de support technique. |
Ressources supplémentaires
L’architecture multilocataire est une méthodologie métier de base pour la conception de charges de travail SaaS. Ces articles fournissent plus d’informations sur la gestion des identités et des accès :
- Considérations architecturales relatives à l’identité dans les solutions mutualisées
- Approches architecturales pour l’identité dans les solutions mutualisées
Étape suivante
Découvrez comment choisir votre modèle d’hébergement de calcul, les aspects opérationnels et comment optimiser les options technologiques pour vous aider à respecter vos contrats et objectifs de niveau de service.