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 dont les utilisateurs ont besoin
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.
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.
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 Lister ou gérer les 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 laps de temps après lequel les privilèges sont automatiquement révoqués.
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 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 (*). L’accès et les autorisations supplémentaires accordés par le biais d’un futur Actions ou DataActions peuvent être indésirables à l’aide du caractère générique carte. Pour plus d’informations, consultez Rôles Azure personnalisés.