Recommandations relatives aux meilleures pratiques liées aux identités managées
Les identités managées pour les ressources Azure sont une fonctionnalité de Microsoft Entra ID. Les services Azure prenant en charge les identités managées pour ressources Azure sont soumis à leur propre chronologie. Assurez-vous de passer en revue l’état Disponibilité des identités gérées pour votre ressource et les problèmes connus avant de commencer.
Choix d’identités managées affectées par le système ou par l’utilisateur
Les identités managées affectées par l’utilisateur sont plus efficaces dans un plus grand nombre de scénarios que les identités managées affectées par le système. Consultez le tableau ci-dessous pour découvrir quelques scénarios et les recommandations relatives aux identités affectées par l’utilisateur ou par le système.
Les identités affectées par l’utilisateur peuvent être utilisées par plusieurs ressources, et leurs cycles de vie sont dissociés des cycles de vie des ressources auxquelles elles sont associées. Découvrez quelles ressources prennent en charge les identités managées.
Ce cycle de vie vous permet de séparer vos responsabilités en matière de création de ressources et d’administration des identités. Les identités affectées par l’utilisateur et leurs attributions de rôle peuvent être configurées avant les ressources qui en ont besoin. Les utilisateurs qui créent les ressources ont uniquement besoin de l’accès pour attribuer une identité affectée par l’utilisateur, sans avoir à créer de nouvelles identités ou attributions de rôle.
Comme les identités affectées par le système sont créées et supprimées en même temps que la ressource, les attributions de rôle ne peuvent pas être créées à l’avance. Cette séquence peut provoquer des échecs lors du déploiement d’une infrastructure si l’utilisateur qui crée la ressource n’a pas également accès à la création d’attributions de rôle.
Si votre infrastructure nécessite que plusieurs ressources aient accès aux mêmes ressources, une seule identité affectée par l’utilisateur peut leur être attribuée. La surcharge relative à l’administration sera moins importante, car il y a moins d’identités et d’attributions de rôle distinctes à gérer.
Si vous avez besoin que chaque ressource ait sa propre identité ou si vous avez des ressources qui nécessitent un ensemble unique d’autorisations et que vous souhaitez que l’identité soit supprimée en même temps que la ressource, vous devez utiliser une identité affectée par le système.
| Scénario | Recommandation | Notes |
|---|---|---|
| Création rapide de ressources (par exemple, calcul éphémère) avec des identités managées | Identité attribuée par l’utilisateur | Si vous tentez de créer plusieurs identités managées dans un court laps de temps (par exemple, en déployant plusieurs machines virtuelles avec leur propre identité affectée par le système), vous risquez de dépasser la limite de débit pour les créations d’objets Microsoft Entra, et la demande échouera avec une erreur HTTP 429. Si des ressources sont créées ou supprimées rapidement, vous risquez également de dépasser la limite du nombre de ressources dans Microsoft Entra ID si vous utilisez des identités affectées par le système. Bien qu’une identité affectée par le système qui a été supprimée ne soit plus accessible par aucune ressource, elle sera comptabilisée dans votre limite jusqu’à ce qu’elle soit supprimée définitivement après 30 jours. Le déploiement de ressources associées à une seule identité affectée par l’utilisateur nécessite la création d’un seul principal de service dans Microsoft Entra ID, ce qui permet d’éviter la limite du débit. L’utilisation d’une seule identité créée à l’avance réduira également le risque de retards de réplication qui pourraient se produire si plusieurs ressources sont créées, chacune avec sa propre identité. En savoir plus sur les limites du service d’abonnement Azure. |
| Ressources/applications répliquées | Identité attribuée par l’utilisateur | Les ressources qui effectuent la même tâche, par exemple, des serveurs web dupliqués ou des fonctionnalités identiques qui s’exécutent dans un service d’application et dans une application sur une machine virtuelle, requièrent généralement les mêmes autorisations. En utilisant la même identité affectée par l’utilisateur, moins d’attributions de rôle sont nécessaires, ce qui réduit la charge de gestion. Les ressources n’ont pas besoin d’être du même type. |
| Conformité | Identité attribuée par l’utilisateur | Si votre organisation exige que toute création d’identité passe par un processus d’approbation, l’utilisation d’une seule identité affectée par l’utilisateur sur plusieurs ressources nécessitera moins d’approbations que les identités affectées par le système, qui sont créées à mesure que de nouvelles ressources sont créées. |
| Accès requis avant le déploiement d’une ressource | Identité attribuée par l’utilisateur | Des ressources peuvent nécessiter un accès à certaines ressources Azure dans le cadre de leur déploiement. Dans ce cas, il se peut qu’une identité affectée par le système ne soit pas créée à temps ; il convient donc d’utiliser une identité affectée par l’utilisateur préexistante. |
| Journalisation d’audit | Identité attribuée par le système | Si vous devez enregistrer quelle ressource spécifique a effectué une action, plutôt que quelle identité, utilisez une identité affectée par le système. |
| Gestion du cycle de vie des autorisations | Identité attribuée par le système | Si vous souhaitez que les autorisations d’une ressource soient supprimées en même temps que cette ressource, utilisez une identité affectée par le système. |
Utilisation des identités affectées par l’utilisateur pour réduire l’administration
Les diagrammes illustrent la différence entre les identités affectées par le système et celles affectées par l’utilisateur lorsqu’elles sont utilisées pour permettre à plusieurs machines virtuelles d’accéder à deux comptes de stockage.
Le diagramme montre quatre machines virtuelles avec des identités affectées par le système. Chaque machine virtuelle a les mêmes attributions de rôle qui lui permettent d’accéder à deux comptes de stockage.
Lorsqu’une identité affectée par l’utilisateur est associée aux quatre machines virtuelles, seules deux attributions de rôle sont requises, contre huit avec des identités affectées par le système. Si l’identité des machines virtuelles requiert davantage d’attributions de rôle, elles seront accordées à toutes les ressources associées à cette identité.
Des groupes de sécurité peuvent également être utilisés pour réduire le nombre d’attributions de rôle requises. Ce diagramme illustre quatre machines virtuelles avec des identités affectées par le système, qui ont été ajoutées à un groupe de sécurité, avec les attributions de rôle ajoutées au groupe au lieu des identités affectées par le système. Bien que le résultat soit similaire, cette configuration n’offre pas les mêmes capacités de modèle Resource Manager que les identités affectées par l’utilisateur.
Plusieurs identités managées
Les ressources qui prennent en charge les identités managées peuvent avoir une identité affectée par le système et une ou plusieurs identités affectées par l’utilisateur.
Ce modèle offre la flexibilité nécessaire pour utiliser une identité affectée par l’utilisateur partagée et appliquer des autorisations granulaires si nécessaire.
Dans l’exemple ci-dessous, « Machine virtuelle 3 » et « Machine virtuelle 4 » peuvent accéder à la fois aux comptes de stockage et aux coffres de clés, selon l’identité affectée par l’utilisateur qu’elles utilisent lors de l’authentification.
Dans l’exemple ci-dessous, « Machine virtuelle 4 » possède à la fois une identité affectée par l’utilisateur et une autre affectée par le système, ce qui lui donne accès aux comptes de stockage et aux coffres de clés, selon l’identité qu’elle utilise lors de l’authentification. Les attributions de rôle pour l’identité affectée par le système sont spécifiques à cette machine virtuelle.
limites
Consultez les limites des identités managées et des rôles personnalisés et attributions de rôle.
Suivre le principe du moindre privilège lors de l’octroi de l’accès
Lorsque vous accordez une identité, y compris une identité managée, aux services, accordez toujours les autorisations minimales nécessaires pour effectuer les actions souhaitées. Par exemple, si une identité managée est utilisée pour lire des données à partir d’un compte de stockage, il n’est pas nécessaire d’autoriser les autorisations d’accès à écrire des données dans le compte de stockage. En accordant des autorisations supplémentaires, par exemple, en faisant de l’identité managée un contributeur sur un abonnement Azure lorsqu’il n’est pas nécessaire, augmente le rayon de sécurité associé à l’identité. L’un doit toujours réduire le rayon de sécurité pour compromettre l’identité.
Tenir compte de l’effet de l’attribution d’identités managées à des ressources Azure et/ou de l’octroi d’autorisations d’attribution à un utilisateur
Il est important de noter que lorsqu’une ressource Azure, telle qu’une application logique Azure, une fonction Azure ou une machine virtuelle, etc. reçoit une identité managée, toutes les autorisations accordées à l’identité managée sont désormais disponibles pour la ressource Azure. Ceci est important, car si un utilisateur a accès à l’installation ou à l’exécution de code sur cette ressource, il a accès à toutes les identités attribuées/associées à la ressource Azure. L’objectif d’une identité managée est de permettre au code s’exécutant sur un accès aux ressources Azure d’accéder à d’autres ressources, sans que les développeurs aient besoin de gérer ou de placer directement les informations d’identification dans le code pour obtenir cet accès.
Par exemple, si une identité managée (ClientId = 1234) a reçu un accès en lecture/écriture à StorageAccount7755 et qu’elle a été attribuée à LogicApp3388, Alice, qui n’a pas d’accès direct au compte de stockage, mais qui a l’autorisation d’exécuter du code dans LogicApp3388, peut également lire/écrire des données vers/à partir de StorageAccount7755 en exécutant le code utilisant l’identité managée.
De même, si Alice dispose des autorisations nécessaires pour attribuer elle-même l’identité managée, elle peut l’affecter à une autre ressource Azure et avoir accès à toutes les autorisations disponibles pour l’identité managée.
En général, lorsqu'on accorde à un utilisateur un accès administratif à une ressource qui peut exécuter du code (comme une Logic App) et qui a une identité gérée, il faut se demander si le rôle attribué à l'utilisateur peut installer ou exécuter du code sur la ressource, et dans l’affirmative, n'attribuer ce rôle que si l'utilisateur en a vraiment besoin.
Maintenance
Les identités affectées par le système sont automatiquement supprimées lorsque la ressource est supprimée, tandis que le cycle de vie d’une identité affectée par l’utilisateur est indépendant des ressources auxquelles elle est associée.
Vous devez supprimer manuellement une identité affectée par l’utilisateur lorsqu’elle n’est plus nécessaire, même si aucune ressource ne lui est associée.
Les attributions de rôle ne sont pas supprimées automatiquement lorsque les identités managées affectées par le système ou par l’utilisateur sont supprimées. Ces attributions de rôle doivent être supprimées manuellement afin de ne pas dépasser la limite d’attributions de rôle par abonnement.
Les attributions de rôle associées aux identités managées supprimées apparaissent avec le message « Identité introuvable » lorsqu’elles sont affichées dans le portail. En savoir plus.
Les attributions de rôles qui ne sont plus associées à un utilisateur ou à un principal de service s’affichent avec une valeur ObjectType de Unknown. Pour les supprimer, vous pouvez diriger plusieurs commandes Azure PowerShell ensemble pour obtenir d’abord toutes les attributions de rôles, filtrer uniquement celles avec une valeur ObjectType de Unknown, puis supprimer ensuite ces attributions de rôles d’Azure.
Get-AzRoleAssignment | Where-Object {$_.ObjectType -eq "Unknown"} | Remove-AzRoleAssignment
Limitation de l’utilisation des identités managées pour l’autorisation
L’utilisation de groupes Microsoft Entra ID pour accorder l’accès aux services est un excellent moyen de simplifier le processus d’autorisation. L’idée est simple : accordez des autorisations à un groupe et ajoutez des identités au groupe afin qu’elles héritent des mêmes autorisations. Il s’agit d’un modèle bien établi provenant de différents systèmes locaux et qui fonctionne bien lorsque les identités représentent des utilisateurs. Une autre option pour contrôler l’autorisation dans Microsoft Entra ID consiste à utiliser des Rôles d’application, ce qui vous permet de déclarer des rôles spécifiques à une application (plutôt que des groupes, qui sont un concept global dans l’annuaire). Vous pouvez ensuite attribuer des rôles d’application à des identités managées (ainsi qu’à des utilisateurs ou des groupes).
Dans les deux cas, pour les identités non-humaines comme les applications et les identités managées Microsoft Entra, le mécanisme exact de présentation de ces informations d’autorisation à l’application n’est pas parfaitement adapté aujourd’hui. L’implémentation actuelle avec Microsoft Entra ID et le contrôle d’accès en fonction du rôle (Azure RBAC) utilise des jetons d’accès émis par Microsoft Entra ID pour l’authentification de chaque identité. Si l’identité est ajoutée à un groupe ou à un rôle, elle est exprimée sous la forme de revendications dans le jeton d’accès émis par Microsoft Entra ID. Azure RBAC utilise ces revendications pour évaluer plus en détail les règles d’autorisation afin d’autoriser ou de refuser l’accès.
Étant donné que les groupes et les rôles de l’identité sont des revendications dans le jeton d’accès, les modifications d’autorisation ne prennent pas effet tant que le jeton n’est pas actualisé. Pour un utilisateur humain, ce n’est généralement pas un problème, parce qu’un utilisateur peut acquérir un nouveau jeton d’accès en se déconnectant et se reconnectant à nouveau (ou en patientant jusqu’à ce que le jeton expire, soit au bout d’une heure par défaut). En revanche, les jetons d’identité managée sont mis en cache par l’infrastructure Azure sous-jacente à des fins de performances et de résilience : les services back-end pour les identités managées conservent un cache par URI de ressource pendant 24 heures environ. Cela signifie que les modifications de l’appartenance à un rôle ou un groupe d’une identité managée peuvent prendre plusieurs heures avant de prendre effet. Aujourd’hui, il n’est pas possible de forcer l’actualisation du jeton d’une identité managée avant son expiration. Si vous modifiez l’appartenance à un rôle ou un groupe d’une identité managée pour ajouter ou supprimer des autorisations, il peut être nécessaire de patienter plusieurs heures avant que la ressource Azure utilisant l’identité dispose de l’accès approprié.
Si ce délai n’est pas acceptable pour vos exigences, considérez les alternatives à l’utilisation de groupes ou de rôles dans le jeton. Pour que les modifications apportées aux autorisations des identités managées prennent effet rapidement, nous vous recommandons de regrouper les ressources Azure à l’aide d’une identité managée affectée par l’utilisateur avec des autorisations appliquées directement à l’identité, au lieu d’ajouter ou de supprimer des identités managées dans un groupe Microsoft Entra disposant d’autorisations. Une identité managée attribuée par l'utilisateur peut être utilisée comme un groupe, car elle peut être attribuée à une ou plusieurs ressources Azure pour l’utiliser. L’opération d’assignation peut être contrôlée à l’aide du Contributeur d’identité managée et Rôle opérateur d’identité managée.