Gestion de l’identité et des accès d’application
Cet article décrit les considérations et les recommandations que les propriétaires d’applications et les développeurs peuvent utiliser pour concevoir la gestion des identités et des accès pour les applications natives du cloud.
Si votre équipe migre ou crée des applications natives du cloud, vous devez prendre en compte les exigences d’authentification et d’accès pour les applications. Ces exigences déterminent comment les utilisateurs s’authentifient aux applications et comment les ressources des applications s’authentifient entre elles, par exemple lorsqu’une application web accède à une base de données SQL.
Dans le domaine de conception de l’automatisation des plate-formes et DevOps, nous recommandons que votre équipe d’application migre les charges de travail vers la distribution d’abonnements. Dans le cadre du processus de distribution d’abonnements, votre équipe d’application doit fournir les exigences d’identité et d’accès à l’équipe de plate-forme afin qu’ils puissent créer les abonnements appropriés. Les propriétaires d’applications sont responsables de la gestion de l’identité et des accès des applications individuelles. Ils devraient gérer leur application en utilisant les services centralisés que l’équipe de plate-forme fournit.
Considérations sur la conception
Pour contribuer à réduire le risque d’accès non autorisé à vos applications, intégrez les considérations suivantes dans votre conception.
Il existe plusieurs normes d’authentification et d’autorisation, comme OAuth 2.0, OpenID Connect, les jetons web JSON (JWTs) et SAML (Security Assertion Markup Language). Déterminez quelles normes d’authentification et d’autorisation utiliser pour votre application.
Lorsque vous demandez une zone d’atterrissage d’application à l’équipe de plate-forme, vous pouvez aider à garantir qu’ils créent les abonnements appropriés en leur posant les questions suivantes :
Comment les utilisateurs finaux vont-ils s’authentifier et accéder à l’application ?
Qui a besoin des permissions de contrôle d’accès basé sur les rôles (RBAC) pour les ressources et services que l’application utilise ?
Les rôles intégrés existants couvrent-ils les exigences d’accès RBAC pour l’accès au plan de contrôle et au plan de données, ou devez-vous créer de nouveaux rôles personnalisés ?
L’équipe de plate-forme a-t-elle mis en œuvre des politiques de conformité qui pourraient poser problème à l’application ?
Quels composants de l’application doivent communiquer entre eux ?
Y a-t-il des exigences pour accéder aux ressources partagées, telles que les services de domaine Microsoft Entra, qui sont déployés dans la zone d’atterrissage de la plate-forme ?
Azure Key Vault et identités gérées
Les violations de sécurité des ressources du cloud public proviennent souvent de références divulguées qui sont intégrées dans le code ou d’autres textes. Vous pouvez utiliser les identités gérées et Key Vault pour mettre en œuvre un accès programmatique et aider à réduire le risque de vol de références.
Si votre application ou charge de travail nécessite un service pour stocker en toute sécurité les références, vous pouvez utiliser Key Vault pour gérer les secrets, les clés et les certificats.
Pour éviter d’avoir des références dans votre code, vous pouvez utiliser des identités gérées avec les VM Azure pour vous authentifier à tout service qui prend en charge l’authentification Microsoft Entra ID. Pour plus d’informations, veuillez consulter la rubrique Utiliser des identités gérées pour les ressources Azure sur une VM pour acquérir un jeton d’accès.
Les identités gérées fournissent un principe d’identité géré automatiquement que les applications et les ressources utilisent lorsqu’elles se connectent à des ressources qui prennent en charge l’authentification Microsoft Entra ID. Les applications peuvent utiliser des identités gérées pour obtenir des jetons Microsoft Entra ID sans avoir à gérer des références.
Vous pouvez utiliser des identités managées attribuées par le système ou attribuées par l’utilisateur.
Il est facile de confondre comment les principaux de service et les identités managées accèdent aux ressources Azure. Pour comprendre la différence entre les deux, veuillez consulter la rubrique Démystifier les principes de service - Identités gérées.
Si possible, utilisez des identités gérées pour prendre en charge l’authentification plutôt que d’utiliser des principes de service et des inscriptions d’applications Microsoft Entra ID. Vous devez avoir les rôles RBAC d’Administrateur d’application ou de Développeur d’application pour créer des principes de service et des inscriptions d’applications. Ces rôles privilégiés sont généralement attribués à l’équipe de plate-forme ou à l’équipe d’identité. Utilisez des identités gérées pour éliminer le besoin pour l’équipe de plate-forme de créer des principes de service et des inscriptions d’applications pour votre équipe d’application.
Vous pouvez utiliser les identités managées pour vous authentifier auprès de tout service qui prend en charge l’authentification Microsoft Entra. Cependant, tous les services ne prennent pas en charge les identités gérées pour accéder à d’autres services. Pour certains services, il peut être nécessaire de stocker des références. Vous devriez stocker en toute sécurité les références, éviter de partager des références avec d’autres services et suivre le principe du moindre privilège. Pour plus d’informations, veuillez consulter la rubrique Azure services that can use managed identities to access other services.
Vous pouvez utiliser des identités gérées avec les machines virtuelles Azure pour vous authentifier à tout service qui prend en charge l’authentification Microsoft Entra ID. Pour plus d’informations, veuillez consulter la rubrique Utiliser des identités gérées pour les ressources Azure sur une VM pour acquérir un jeton d’accès.
Il existe des restrictions sur le déplacement de ressources avec des identités gérées entre les abonnements et les régions. Par exemple, vous pourriez déplacer des ressources entre les abonnements ou les régions pour une fusion, une acquisition, ou un rapatriement de ressources pour des raisons de souveraineté des données.
Si une ressource Azure a des identités assignées par l’utilisateur ou par le système, vous ne pouvez pas transférer la ressource vers un autre abonnement Azure ou région. Vous devez supprimer les identités gérées avant de déplacer la ressource. Après le déplacement, vous devez recréer les identités gérées et les attribuer à la ressource. Pour plus d’informations, consultez la page Déplacer des ressources vers un nouveau groupe de ressources ou un abonnement.
Si vous déplacez un abonnement d’un répertoire à un autre, les identités gérées ne sont pas préservées. Vous devez déplacer la ressource, puis recréer manuellement les identités gérées.
Tout comme les affectations de rôles RBAC utilisateur, suivez le principe du moindre privilège lors de l’octroi d’un accès par identité gérée à une ressource.
Utilisateurs externes
Vous pouvez évaluer des scénarios impliquant la configuration d’utilisateurs externes, de clients ou de partenaires pour qu’ils puissent accéder aux ressources. Déterminez si ces scénarios impliquent des configurations Microsoft Entra B2B ou Azure Active Directory B2C (Azure AD B2C). Pour plus d’informations, veuillez consulter la Présentation de Microsoft Entra External ID.
Recommandations de conception
Prenez en compte les recommandations suivantes lors de la conception de la gestion des identités et des accès de vos applications.
OpenID Connect
Si votre équipe d’application utilise des pipelines d’intégration continue et de déploiement continu (CI/CD) pour déployer des applications de manière programmée, configurez l’authentification OpenID Connect pour vos services Azure. OpenID Connect utilise un jeton temporaire et sans références pour s’authentifier auprès des services Azure. Pour plus d’informations, veuillez consulter la Fédération d’identité de charge de travail.
Si OpenID Connect n’est pas pris en charge, créez un principe de service et attribuez les autorisations nécessaires pour permettre le déploiement de l’infrastructure ou du code d’application. Pour plus d’informations, consultez le module de formation, Authentifiez votre pipeline de déploiement Azure en utilisant des principes de service.
Contrôle d’accès en fonction de l’attribut
Pour restreindre davantage l’accès et prévenir l’accès non autorisé aux données, utilisez le contrôle d’accès basé sur les attributs (ABAC) là où il est pris en charge, par exemple avec Azure Blob Storage.
Accès à la machine virtuelle
Dans la mesure du possible, utilisez les identités Microsoft Entra ID pour contrôler l’accès aux machines virtuelles Azure. Utilisez Microsoft Entra ID au lieu de l’authentification locale pour fournir un accès aux machines virtuelles, en profitant de l’authentification conditionnelle Microsoft Entra, de l’audit et de l’authentification multi-facteurs (MFA) de Microsoft Entra. Cette configuration réduit le risque que les attaquants exploitent des services d’authentification locaux non sécurisés. Pour plus d’informations, veuillez consulter la rubrique Se connecter à une machine virtuelle Linux dans Azure en utilisant Microsoft Entra ID et OpenSSH et Se connecter à une machine virtuelle Windows dans Azure en utilisant Microsoft Entra ID, y compris sans mot de passe.
Plateforme d’identité Microsoft
Lorsque les développeurs construisent une application native du cloud, ils devraient utiliser la plate-forme d’identité Microsoft pour les développeurs en tant que fournisseur d’identité pour leurs applications. La plate-forme d’identité Microsoft fournit un service d’authentification conforme à la norme OpenID Connect que les développeurs peuvent utiliser pour authentifier plusieurs types d’identités, notamment :
Comptes professionnels ou scolaires, provisionnés par le biais de Microsoft Entra ID
Pour les comptes Microsoft personnels (Skype, Xbox, Outlook.com)
Des comptes sociaux ou locaux, en utilisant Microsoft Entra ID.
La liste de contrôle des bonnes pratiques et recommandations de la plate-forme d’identité Microsoft fournit des conseils sur l’intégration efficace de l’application avec la plate-forme d’identité Microsoft.
Identités managées
Pour permettre l’accès entre les ressources Azure qui n’ont pas besoin d’utiliser des références, utilisez des identités gérées.
Vous ne devez pas partager de références ou d’identités gérées entre différents environnements ou applications. Par exemple, n’utilisez pas les identités pour les ressources de production et également dans les ressources de dev/test, même pour la même application. Créez des références distinctes pour chaque instance d’une application afin de réduire la probabilité qu’une instance de test compromise affecte les données de production. Des références séparées facilitent également la révocation des références lorsqu’elles ne sont plus nécessaires.
Lorsqu’il est nécessaire d’utiliser des identités gérées à grande échelle, utilisez une identité gérée attribuée par l’utilisateur pour chaque type de ressource dans chaque région. Cette approche empêche un changement d’identités. Par exemple, Azure Monitor Agent nécessite une identité gérée sur les VM Azure surveillées, ce qui peut amener Microsoft Entra ID à créer (et supprimer) un nombre important d’identités. Vous pouvez créer des identités gérées attribuées par l’utilisateur une fois et les partager entre plusieurs VM. Utilisez Azure Policy pour mettre en œuvre cette recommandation.
Key Vault
Vous pouvez utiliser Key Vault pour gérer les secrets, les clés, les certificats que les applications utilisent.
Pour gérer l’accès aux secrets (plan de données) et pour l’accès administratif (plan de contrôle), utilisez RBAC.
Pour contrôler l’accès des applications à Key Vault, utilisez des identités gérées.
Vous devriez utiliser des coffres de clés séparés pour chaque environnement d’application (développement, préproduction, production) dans chaque région. Utilisez RBAC pour gérer l’accès aux secrets, clés et certificats (opérations de plan de données) et l’accès à Key Vault (plan de contrôle). Déployez les coffres de clés contenant les secrets d’application dans les zones d’atterrissage d’application.
Proxy d’application Microsoft Entra
Pour accéder à distance via Microsoft Entra ID à des applications utilisant l’authentification sur site, utilisez le proxy d’application Microsoft Entra. Le proxy d’application Microsoft Entra fournit un accès distant sécurisé aux applications web locales, y compris les applications qui utilisent des protocoles d’authentification plus anciens. Après une connexion unique à Microsoft Entra ID, les utilisateurs peuvent accéder à la fois aux applications cloud et sur site via une URL externe ou un portail d’application interne.
Vous pouvez déployer le proxy d’application Microsoft Entra en tant qu’instance unique dans un locataire Microsoft Entra ID. La configuration nécessite au moins le rôle Microsoft Entra ID privilégié d’Administrateur d’application. Si votre organisation utilise la démocratisation de l’abonnement en tant que modèle d’attribution de rôles, les propriétaires d’applications peuvent ne pas avoir les autorisations nécessaires pour configurer le proxy d’application Microsoft Entra. Dans ce cas, l’équipe de plate-forme devrait configurer le proxy d’application Microsoft Entra pour le propriétaire de l’application.
Si vous utilisez des pipelines de déploiement CI/CD avec des autorisations suffisantes, les propriétaires d’applications peuvent configurer le proxy d’application Microsoft Entra en utilisant l’API Microsoft Graph.
Si l’application utilise des protocoles hérités, tels que Kerberos, assurez-vous que la zone d’atterrissage de l’application dispose d’une connectivité réseau aux contrôleurs de domaine dans l’abonnement plate-forme d’identités Microsoft.