Dans le prolongement de notre précédent blog sur Azure Policy, nous poursuivons le thème de la sécurité et couvrons le contrôle d’accès basé sur les rôles (RBAC), qui fait partie du cadre de Gestion des Identités et des Accès d’Azure.
RBAC est formidable car vous pouvez attribuer les autorisations par rôle plutôt qu’à des personnes une par une, ce qui permet de gagner beaucoup de temps. Vous allez soit utiliser beaucoup de rôles intégrés, soit créer des rôles personnalisés qui représentent les tâches communes au sein de votre entreprise : service clientèle, service commercial, service technique. Vous pouvez créer des règles et donner un accès très granulaire à ces personnes. Au lieu de créer 20 rôles différents pour chaque personne, vous pouvez attribuer un rôle par département et une personne peut être attribuée à plusieurs rôles.
RBAC est en fait un concept plutôt qu'un service ou une ressource spécifique que vous pouvez déployer dans Azure. Vous trouverez la carte des Contrôle d’Accès (IAM) sur la plupart des ressources Azure :
(Click image to enlarge)
Si vous avez déjà travaillé avec une forme quelconque de gestion des utilisateurs et des groupes dans le passé, Azure IAM fonctionne sur un principe similaire. Vous assignez des utilisateurs à des groupes, et des groupes (ou des utilisateurs individuels) à des rôles. Il y a beaucoup de rôles intégrés. La capture d’écran ci-dessous ne montre que les plus importants :
(Click image to enlarge)
Derrière chacune de ces définitions de rôle se trouve un ensemble de restrictions à un point d’extrémité spécifique de l’API Azure. Sur une base quotidienne, via le portail Azure, vous n’avez pas tendance à vous soucier beaucoup des points d’extrémité de l’API, mais vous devez les comprendre si vous voulez créer des rôles personnalisés.
Mon conseil est de vous en tenir à des solutions prêtes à l'emploi ; elles répondent généralement à 90 % des exigences. Ne vous plongez dans les rôles personnalisés que si vous avez besoin de quelque chose de spécial, par exemple un rôle qui sera utilisé par plusieurs applications internes qui doivent accéder à un petit sous-ensemble de fonctionnalités d’Azure.
Avec un nouvel abonnement Azure, j’ai tendance à commencer avec deux groupes, un pour les propriétaires d’abonnement (au niveau de l’abonnement) et un pour les contributeurs aux groupes de ressources (au niveau des groupes de ressources). Les propriétaires d’abonnement ont un rôle de propriétaire, appliqué sur l’abonnement lui-même. Les contributeurs aux groupes de ressources ont un rôle de contributeur, et ce rôle est appliqué individuellement sur les groupes de ressources au fur et à mesure que vous les créez. J’ai un très petit nombre de personnes (une ou deux) dans le groupe des propriétaires d’abonnement, et toutes les autres personnes qui sont responsables du déploiement des ressources dans le groupe des contributeurs de ressources.
Cela a des avantages et des inconvénients (comme tout le reste). Les changements au niveau de l’abonnement ont tendance à être une réponse directe aux besoins des entreprises, alors que dans les groupes de ressources eux-mêmes, vous avez tendance à obtenir des changements opérationnels de type BAU (Business As Usual) ou de projets. C’est une bonne chose du point de vue de la gouvernance, mais cela a les effets secondaires suivants :
-
Personne dans le groupe des contributeurs de ressources ne peut réellement créer le groupe de ressources ; cela doit être fait par quelqu’un dans le groupe des propriétaires d’abonnement.
-
Le propriétaire de l’abonnement devra également appliquer le groupe des contributeurs de ressources au groupe de ressources (vous pourriez utiliser Azure Policy pour le faire automatiquement).
-
Parfois, un déploiement de ressources (effectué par une personne du groupe des contributeurs de ressources) nécessitera qu’un fournisseur de ressources soit enregistré au niveau de l’abonnement. L’installation affichera généralement un gros message d’erreur rouge. Une personne du groupe des propriétaires d’abonnement devra l’enregistrer manuellement. Habituellement, le propriétaire devra le faire via Az Cli.
Si vous souhaitez en savoir plus sur l’impact du RBAC lors des migrations SAP vers Azure ou si vous avez besoin d’aide ou de conseils sur Microsoft Azure, n’hésitez pas à nous contacter.
Liens utiles :
Leave a Comment: