Meilleures pratiques pour Azure RBAC

Cet article décrit quelques-unes des meilleures pratiques d'utilisation du contrôle d’accès en fonction du rôle Azure (Azure RBAC). Ces meilleures pratiques sont issues de notre expérience d’Azure RBAC, mais également de celle des clients, comme vous.

Accorder uniquement l’accès nécessaire aux utilisateurs

Avec Azure RBAC, vous pouvez séparer les tâches au sein de votre équipe et accorder aux utilisateurs uniquement les accès nécessaires pour accomplir leur travail. Plutôt que de donner à tous des autorisations illimitées au sein de votre abonnement ou de vos ressources Azure, vous pouvez autoriser uniquement certaines actions sur une étendue donnée.

Lorsque vous planifiez votre stratégie de contrôle d’accès, vous pouvez accorder aux utilisateurs les privilèges minimaux pour effectuer leur travail. Évitez d’attribuer des rôles plus larges à des étendues plus importantes, même s’ils semblent plus pratiques dans un premier temps. Lorsque vous créez des rôles personnalisés, incluez uniquement les autorisations dont les utilisateurs ont besoin. En limitant les rôles et les étendues, vous limitez les ressources menacées en cas de compromission du principal de sécurité.

Le diagramme suivant illustre un modèle suggéré pour l’utilisation d’Azure RBAC.

Azure RBAC et privilège minimum

Pour obtenir des informations sur la procédure d’attribution de rôles, consultez Attribuer des rôles Azure à l’aide du portail Azure.

Limiter le nombre de propriétaires d’abonnements

Vous devez disposer d'un maximum de trois propriétaires d’abonnement afin de réduire le risque de violation par un propriétaire compromis. Cette recommandation peut être surveillée dans Microsoft Defender pour le Cloud. Pour obtenir d’autres recommandations relatives aux identités et aux accès dans Security Center, consultez Recommandations de sécurité - Guide de référence.

Utiliser Azure AD Privileged Identity Management

Pour protéger des comptes privilégiés contre les cyberattaques malveillantes, vous pouvez utiliser Azure Active Directory Privileged Identity Management (PIM) afin de réduire le temps d’exposition des privilèges et d’augmenter la visibilité quant à leur utilisation via des rapports et des alertes. PIM permet de protéger les comptes privilégiés en fournissant un accès privilégié de type juste-à-temps aux ressources Azure AD et Azure. L’accès peut être lié au laps de temps après lequel les privilèges sont automatiquement révoqués.

Pour plus d’informations, consultez Qu’est-ce qu’Azure AD Privileged Identity Management ?.

Attribuer des rôles à des groupes et non à des utilisateurs

Pour faciliter la gestion des attributions de rôles, évitez d’attribuer des rôles directement aux utilisateurs. Attribuez plutôt des rôles à des groupes. L'attribution de rôles à des groupes plutôt qu'à des utilisateurs permet également de minimiser le nombre d'attributions de rôles, qui est limité à un nombre d'attributions de rôles par abonnement.

Affecter des rôles à l’aide de l’ID de rôle unique à la place du nom de rôle

Un nom de rôle peut changer dans certaines circonstances, par exemple :

  • Vous utilisez vos propres rôles personnalisés et vous décidez d’en modifier le nom.
  • Vous utilisez un rôle en préversion dont le nom contient (préversion) . Lorsque le rôle est publié, le rôle est renommé.

Même si un rôle est renommé, l’ID de rôle ne change pas. Si vous utilisez des scripts ou une automatisation pour créer vos attributions de rôles, il est recommandé d’utiliser l’ID de rôle unique au lieu du nom de rôle. Par conséquent, si un rôle est renommé, vos scripts sont plus susceptibles de fonctionner.

Pour plus d’informations, consultez affecter un rôle à l’aide de l’ID de rôle unique et Azure PowerShell et affecter un rôle à l’aide de l’ID de rôle unique et Azure CLI.

Évitez d’utiliser un caractère générique lors de la création de rôles personnalisés

Lors de la création de rôles personnalisés, vous pouvez utiliser le caractère générique (*) pour définir des autorisations. Il est recommandé de spécifier Actions et DataActions explicitement au lieu d’utiliser le caractère générique (*). Un accès et des autorisations supplémentaires accordés via des Actions ou des DataActions peuvent représenter un comportement non souhaité dû à l’utilisation du caractère générique. Pour plus d’informations, consultez Rôles Azure personnalisés.

Étapes suivantes