Meilleures pratiques pour Azure RBAC

Cet article décrit certaines bonnes pratiques pour l’utilisation du contrôle d’accès en fonction du rôle Azure (Azure RBAC). Ces bonnes pratiques sont dérivées de notre expérience avec Azure RBAC et les expériences des clients comme vous.

N'accorder aux utilisateurs que les accès dont ils ont besoin

À l’aide d’Azure RBAC, vous pouvez séparer les tâches au sein de votre équipe et accorder uniquement la quantité d’accès aux utilisateurs dont ils ont besoin pour effectuer leurs travaux. Au lieu de donner à tout le monde des autorisations illimitées dans votre abonnement Ou vos ressources Azure, vous pouvez autoriser uniquement certaines actions dans une étendue particulière.

Lors de la planification de votre stratégie de contrôle d’accès, il est recommandé d’accorder aux utilisateurs le moins de privilèges pour effectuer leur travail. Évitez d’attribuer des rôles plus larges à des étendues plus larges, même s’il semble initialement plus pratique de le faire. Lors de la création de 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 montre un modèle suggéré pour l’utilisation d’Azure RBAC.

Pour plus d’informations sur l’attribution de rôles, consultez Affecter des rôles Azure à l’aide du portail Azure.

Limiter le nombre de propriétaires d’abonnements

Vous devez disposer d’un maximum de 3 propriétaires d’abonnements pour réduire le risque de violation par un propriétaire compromis. Cette recommandation peut être surveillée dans Microsoft Defender pour cloud. Pour obtenir d’autres recommandations d’identité et d’accès dans Defender pour cloud, consultez les recommandations de sécurité - un guide de référence.

Limiter les attributions de rôles d’administrateur privilégié

Certains rôles sont identifiés comme des rôles d’administrateur privilégié. Envisagez de prendre les mesures suivantes pour améliorer votre posture de sécurité :

• Supprimez les attributions de rôles privilégiées inutiles.
• Évitez d’attribuer un rôle d’administrateur privilégié lorsqu’un rôle de fonction de travail peut être utilisé à la place.
• Si vous devez attribuer un rôle d’administrateur privilégié, utilisez une étendue étroite, telle que le groupe de ressources ou la ressource, au lieu d’une étendue plus large, telle que le groupe d’administration ou l’abonnement.
• Si vous attribuez un rôle avec l’autorisation de créer des attributions de rôles, envisagez d’ajouter une condition pour limiter l’attribution de rôle. Pour plus d’informations, consultez Déléguer la gestion des attributions de rôles Azure à d’autres personnes avec des conditions.

Pour plus d’informations, consultez la liste ou la gestion des attributions de rôles d’administrateur privilégié.

Utiliser Microsoft Entra Privileged Identity Management

Pour protéger les comptes privilégiés contre les cyber-attaques malveillantes, vous pouvez utiliser Microsoft Entra Privileged Identity Management (PIM) pour réduire le temps d’exposition des privilèges et augmenter votre visibilité sur leur utilisation par le biais de rapports et d’alertes. PIM permet de protéger les comptes privilégiés en fournissant un accès privilégié juste-à-temps aux ressources Microsoft Entra ID et Azure. L’accès peut être lié au temps après quoi les privilèges sont révoqués automatiquement.

Pour plus d’informations, consultez Qu’est-ce que Microsoft Entra Privileged Identity Management ?.

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

Pour rendre les attributions de rôles plus gérables, évitez d’attribuer des rôles directement aux utilisateurs. Au lieu de cela, attribuez des rôles à des groupes. L’attribution de rôles à des groupes au lieu d’utilisateurs permet également de réduire le nombre d’attributions de rôles, qui a une limite d’attributions de rôles par abonnement.

Attribuer des rôles à l’aide de l’ID de rôle unique au lieu du nom du rôle

Il existe plusieurs fois où un nom de rôle peut changer, par exemple :

• Vous utilisez votre propre rôle personnalisé et vous décidez de modifier le nom.
• Vous utilisez un rôle de préversion dans lequel (préversion) apparaît dans le nom. Lorsque le rôle est libéré, 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 d’Azure PowerShell et attribuer un rôle à l’aide de l’ID de rôle unique et d’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 futurs 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

• Résoudre les problèmes liés à Azure RBAC