Contrôle d'accès en fonction du rôle Azure
Les droits d’accès et les privilèges en fonction du groupe sont une bonne pratique. Le traitement des groupes plutôt que des utilisateurs individuels simplifie la maintenance des stratégies d’accès, offre une gestion cohérente des accès entre les équipes et réduit les erreurs de configuration. L’attribution et la suppression d’utilisateurs dans les groupes appropriés facilitent l’actualisation continue des privilèges d’un utilisateur spécifique. Le contrôle d’accès en fonction du rôle Azure (RBAC Azure) offre une gestion précise de l’accès aux ressources, organisée autour des rôles des utilisateurs.
Pour obtenir une vue d’ensemble des pratiques RBAC Azure recommandées dans le cadre d’une stratégie d’identité et de sécurité, consultez Bonnes pratiques en matière de sécurité du contrôle d’accès et de gestion des identités Azure.
Vue d’ensemble du contrôle d’accès en fonction du rôle Azure
En utilisant le contrôle d’accès en fonction du rôle Azure, vous pouvez séparer les tâches au sein de votre équipe et n’accorder que l’accès suffisant pour des utilisateurs, groupes, principaux de service ou identités managées Microsoft Entra spécifiques pour effectuer leurs tâches. Plutôt que de donner à tous un accès illimité à votre abonnement ou à vos ressources Azure, vous pouvez limiter les autorisations pour chaque ensemble de ressources.
Les définitions de rôle Azure listent les opérations autorisées ou interdites pour les utilisateurs ou les groupes affectés à ce rôle. L’étendue d’un rôle spécifie les ressources auxquelles ces autorisations définies s’appliquent. Les étendues peuvent être spécifiées à plusieurs niveaux : groupe d’administration, abonnement, groupe de ressources ou ressource. Les étendues sont structurées dans une relation parent-enfant.
Pour obtenir des instructions détaillées sur l’affectation d’utilisateurs et de groupes à des rôles spécifiques et l’attribution de rôles à des étendues, consultez Ajouter ou supprimer des attributions de rôle Azure à l’aide du portail Azure.
Lorsque vous planifiez votre stratégie de contrôle d’accès, utilisez un modèle d’accès basé sur le privilège minimum qui accorde uniquement aux utilisateurs les autorisations requises pour effectuer leur travail. Le diagramme suivant montre un modèle suggéré pour l’utilisation de RBAC Azure via cette approche.
Remarque
Plus les autorisations que vous définissez sont spécifiques ou détaillées, plus il est probable que vos contrôles d’accès deviennent complexes et difficiles à gérer. Cela est particulièrement vrai lorsque la taille de votre parc cloud augmente. Évitez les autorisations spécifiques aux ressources. Au lieu de cela, utilisez des groupes d’administration pour un contrôle d’accès au niveau de l’entreprise et des groupes de ressources pour un contrôle d’accès au sein d’abonnements. Évitez également les autorisations spécifiques à des utilisateurs. Au lieu de cela, attribuez l’accès aux groupes dans Microsoft Entra ID.
Utiliser les rôles intégrés Azure
Azure fournit de nombreuses définitions de rôle intégrées, avec trois rôles principaux pour fournir l’accès :
- Le rôle Propriétaire peut tout gérer, y compris l’accès aux ressources.
- Le rôle Contributeur peut tout gérer, sauf l’accès aux ressources.
- Le rôle Lecteur peut tout afficher, mais ne peut apporter aucune modification.
À partir de ces niveaux d’accès de base, des rôles intégrés supplémentaires fournissent des contrôles plus détaillés pour accéder à des types de ressources spécifiques ou à des fonctionnalités Azure. Par exemple, vous pouvez gérer l’accès aux machines virtuelles à l’aide des rôles intégrés suivants :
- Le rôle Connexion de l’administrateur aux machines virtuelles peut afficher les machines virtuelles dans le portail et se connecter en tant que
administrator. - Le rôle Contributeur de machines virtuelles peut gérer des machines virtuelles, mais ne peut pas accéder à ces dernières, au réseau virtuel ni au compte de stockage auquel elles sont connectées.
- Le rôle Connexion de l’utilisateur aux machines virtuelles peut afficher les machines virtuelles dans le portail et se connecter en tant qu’utilisateur standard.
Pour obtenir un autre exemple d’utilisation des rôles intégrés pour gérer l’accès à des fonctionnalités spécifiques, consultez la discussion sur le contrôle de l’accès aux fonctionnalités de suivi des coûts dans Suivre les coûts dans les unités commerciales, les environnements ou les projets.
Pour obtenir la liste complète des rôles intégrés disponibles, consultez Rôles intégrés Azure.
Utiliser des rôles personnalisés
Bien que les rôles intégrés à Azure prennent en charge un large éventail de scénarios de contrôle d’accès, ils peuvent ne pas répondre à tous les besoins de votre organisation ou équipe. Par exemple, si vous avez un seul groupe d’utilisateurs responsable de la gestion des machines virtuelles et des ressources Azure SQL Database, vous voudrez peut-être créer un rôle personnalisé pour optimiser la gestion des contrôles d’accès requis.
La documentation Azure RBAC contient des instructions sur la création de rôles personnalisés, ainsi que des détails sur le fonctionnement des définitions de rôle.
Séparation des responsabilités et des rôles pour les grandes organisations
RBAC Azure permet aux organisations d’affecter différentes équipes à différentes tâches d’administration au sein de grandes infrastructures cloud. Il permet aux équipes informatiques centrales de contrôler les fonctionnalités principales d’accès et de sécurité, tout en permettant aux développeurs de logiciels et aux autres équipes d’avoir un grand contrôle sur des charges de travail ou groupes de ressources spécifiques.
La plupart des environnements cloud peuvent également bénéficier d’une stratégie de contrôle d’accès qui utilise plusieurs rôles et met l’accent sur une séparation des responsabilités entre ces rôles. Cette approche nécessite que toute modification significative des ressources ou de l’infrastructure implique la réalisation de plusieurs rôles, de sorte que plusieurs personnes doivent passer en revue et approuver une modification. Cette séparation des responsabilités limite la capacité d’une seule personne à accéder à des données sensibles ou à introduire des vulnérabilités à l’insu des autres membres de l’équipe.
Le tableau suivant illustre un modèle commun de séparation des responsabilités informatiques en rôles personnalisés distincts :
| Groupe | Nom du rôle commun | Responsabilités |
|---|---|---|
| Opérations de sécurité | Responsables des opérations de sécurité | Fournit un aperçu général de la sécurité. Établit et applique la stratégie de sécurité, comme le chiffrement au repos. Gère les clés de chiffrement. Gère les règles de pare-feu. |
| Opérations réseau | NetOps | Gère la configuration et les opérations du réseau au sein de réseaux virtuels, tels que les itinéraires et les Peerings. |
| Opérations systèmes | SysOps | Spécifie les options d’infrastructure de calcul et de stockage et gère les ressources qui ont été déployées. |
| Développement, test et opérations | DevOps | Génère et déploie des fonctionnalités de charge de travail et des applications. Utilise des fonctionnalités et des applications pour répondre aux contrats de niveau de service et à d’autres standards de qualité. |
La décomposition des actions et des autorisations dans ces rôles standard est souvent identique dans vos applications, vos abonnements ou l’ensemble du parc cloud, même si ces rôles sont exécutés par différentes personnes à différents niveaux. En conséquence, vous pouvez créer un ensemble commun de définitions de rôle Azure à appliquer sur différentes étendues au sein de votre environnement. Les utilisateurs et les groupes peuvent ensuite se voir attribuer un rôle commun, mais uniquement pour l’étendue des ressources, des groupes de ressources, des abonnements ou des groupes d’administration qu’ils sont chargés de gérer.
Par exemple, dans une topologie de réseau hub-and-spoke avec plusieurs abonnements, vous pouvez avoir un ensemble commun de définitions de rôles pour le hub et tous les spokes de charge de travail. Le rôle NetOps d’un abonnement hub peut être attribué aux membres de l’équipe informatique centrale de l’organisation, qui sont chargés de gérer la mise en réseau pour les services partagés utilisés par toutes les charges de travail. Le rôle NetOps d’un abonnement spoke de charge de travail peut ensuite être attribué aux membres de cette équipe de charge de travail spécifique, ce qui leur permet de configurer la mise en réseau au sein de cet abonnement pour prendre en charge au mieux leurs exigences en matière de charge de travail. La même définition de rôle est utilisée pour les deux, mais les attributions basées sur l’étendue garantissent que les utilisateurs disposent uniquement de l’accès dont ils ont besoin pour effectuer leur travail.