Étiquettes et verrous de ressources

Les balises de ressources sont des paires nom-valeur de métadonnées que vous associez aux ressources Azure, aux groupes de ressources et aux abonnements. Contrairement aux structures de dossiers, les balises permettent de catégoriser une même ressource selon plusieurs dimensions simultanément. Par exemple, une VM peut posséder simultanément les balises Environment=Production, Team=Backend, CostCentre=CC-042 et Project=Phoenix, ce qui permet de filtrer indépendamment selon chacune de ces dimensions.

Les organisations définissent généralement une taxonomie standard de balisage couvrant plusieurs dimensions. Les balises financières (CostCentre, BudgetOwner) permettent de répartir les coûts. Les balises opérationnelles (Environment, Criticality, Owner) facilitent le filtrage et la génération d’alertes. Les balises de cycle de vie (AutoShutdown, ExpiryDate) permettent l’automatisation. Les balises de sécurité (DataClassification, Compliance) prennent en charge les outils de sécurité. Définir la taxonomie avant de déployer les ressources évite d’obtenir un ensemble de balises incohérent et impossible à interroger.

Les balises peuvent être appliquées via le portail Azure, CLI, les modèles ARM, Bicep et Terraform. La commande az tag gère les balises des ressources, tandis que az group update balise les groupes de ressources. Avec Azure Policy et l’effet Modify ou Append, vous pouvez ajouter automatiquement des balises au moment de la création d’une ressource, ou les rendre obligatoires — afin que chaque nouvelle ressource possède une balise CostCentre, sans dépendre de la mémoire des développeurs pour l’ajouter manuellement.

Une idée reçue courante est que les balises d’un groupe de ressources sont automatiquement propagées aux ressources qu’il contient. Ce n’est pas le cas : les balises Azure des ressources ne sont pas héritées des étendues parentes. Si vous attribuez la balise Environment=Production à un groupe de ressources, les VM et les bases de données de ce groupe ne reçoivent pas automatiquement cette balise. Pour imposer une attribution cohérente des balises, utilisez Azure Policy avec la définition intégrée Inherit a tag from the resource group, qui copie automatiquement la balise du groupe de ressources sur toutes les ressources qu’il contient.

Les balises sont particulièrement utiles lorsqu’elles sont associées à Azure Cost Management. Dans la vue Analyse des coûts, vous pouvez regrouper les dépenses selon n’importe quelle clé de balise — par exemple, afficher les dépenses mensuelles totales par CostCentre afin de voir quel service consomme le plus de ressources cloud. Vous pouvez également filtrer avec Environment=Production pour exclure les dépenses de développement des budgets de production. Azure Cost Management exige que la balise ait été appliquée avant le début de la période de facturation pour qu’elle apparaisse dans les données de coûts.

Les verrous de ressources protègent les ressources Azure contre toute suppression ou modification accidentelle, quelles que soient les autorisations RBAC détenues par l’utilisateur. Un utilisateur disposant des droits Owner ou Contributor peut tout de même être empêché de supprimer ou de modifier une ressource verrouillée. Les verrous sont appliqués au niveau de la ressource, du groupe de ressources ou de l’abonnement, et se propagent vers les niveaux inférieurs : un verrou placé sur un groupe de ressources protège toutes les ressources qu’il contient.

Azure prend en charge deux types de verrous. CanNotDelete (verrou de suppression) permet aux utilisateurs de lire et de modifier la ressource, mais interdit sa suppression. Il s’agit du verrou le plus courant : il est appliqué aux bases de données de production, aux comptes de stockage et aux VNets afin d’empêcher leur suppression accidentelle. ReadOnly interdit toutes les opérations d’écriture et de suppression, faisant se comporter la ressource comme si le rôle Reader était attribué à tout le monde. ReadOnly est plus restrictif et peut perturber les processus automatisés qui mettent à jour les propriétés des ressources.

Pour supprimer ou modifier une ressource verrouillée, l’utilisateur doit d’abord supprimer le verrou, ce qui nécessite l’autorisation Microsoft.Authorization/locks/delete (accordée par défaut aux rôles Owner et User Access Administrator). La suppression du verrou, la modification de la ressource et la réapplication éventuelle du verrou peuvent être intégrées à un processus de gestion des changements, afin que les ressources protégées puissent toujours être modifiées dans le cadre d’une procédure contrôlée avec une piste d’audit.

Un verrou appliqué à une étendue parente (abonnement ou groupe de ressources) est hérité par toutes les ressources enfants. Vous ne pouvez pas remplacer un verrou à une étendue inférieure : si un groupe de ressources possède un verrou CanNotDelete, les ressources individuelles qu’il contient ne peuvent pas être supprimées, même si aucun verrou ne leur est appliqué directement. Ajouter un verrou CanNotDelete au niveau de la ressource en plus d’un verrou parent ne change pas le comportement ; le verrou parent assure déjà la protection.

Les verrous ReadOnly peuvent provoquer des échecs inattendus dans les processus automatisés. Certaines opérations Azure qui semblent en lecture seule nécessitent en réalité un accès en écriture aux propriétés des ressources en arrière-plan. Par exemple, l’énumération des clés d’accès d’un compte de stockage est bloquée par un verrou ReadOnly, car cette action modifie la piste d’audit du compte. La mise à l’échelle d’une VM, le redémarrage d’un App Service et l’association d’un disque à une VM en cours d’exécution sont également bloqués. Testez les verrous ReadOnly dans des environnements hors production avant de les appliquer à des ressources critiques.

La combinaison des balises et des verrous permet de mettre en place un modèle de gouvernance puissant. Vous pouvez utiliser une balise telle que Protected=true pour marquer les ressources qui doivent posséder des verrous CanNotDelete, puis exécuter un Runbook Azure Automation qui recherche les ressources portant cette balise et crée le verrou s’il est absent. Ce modèle de gouvernance autoréparatrice garantit que, même si un administrateur supprime accidentellement un verrou, celui-ci est automatiquement réappliqué selon la planification du runbook.

Vérifiez votre compréhension des concepts Microsoft Azure Fundamentals (AZ-900) présentés dans cette leçon.

Dans cette leçon, vous avez appris que : les balises de ressources sont des paires de métadonnées nom-valeur qui permettent de répartir les coûts, de filtrer et d’automatiser selon n’importe quelle dimension, les balises ne sont pas héritées des groupes de ressources parents et doivent être imposées via Azure Policy, et les verrous de ressources (CanNotDelete et ReadOnly) protègent les ressources contre les modifications accidentelles, quelles que soient les autorisations RBAC. Nous allons maintenant découvrir Azure Blueprints pour regrouper des artefacts de gouvernance.