Azure Policy

Azure Policy est un service de gouvernance qui vous permet de définir, d’attribuer et de gérer des règles, appelées définitions de stratégie, qui contrôlent ou vérifient la configuration des ressources Azure. Contrairement à RBAC, qui contrôle qui peut effectuer des actions, Azure Policy contrôle quelle configuration la ressource résultante est autorisée à avoir. Vous pouvez l’utiliser pour imposer des normes organisationnelles telles que les conventions de nommage, les types de ressources approuvés et les configurations de sécurité requises.

Une définition de stratégie est un document JSON qui définit une condition à évaluer pour une ressource et un effet à appliquer lorsque la condition est remplie. Azure fournit des centaines de définitions de stratégie intégrées couvrant les scénarios courants. Vous pouvez également créer des définitions de stratégie personnalisées lorsque les stratégies intégrées ne répondent pas à votre exigence. Les définitions de stratégie sont des objets réutilisables qui doivent être attribués à une portée avant de prendre effet.

L’effet d’une définition de stratégie détermine ce qui se produit lorsque la condition de la stratégie est déclenchée. Les principaux effets sont les suivants : Deny — bloque la création ou la mise à jour de la ressource qui enfreint la stratégie ; Audit — autorise l’action, mais consigne un avertissement dans le rapport de conformité ; Append — ajoute les champs requis (comme les balises) à une ressource avant sa création ; Modify — modifie une propriété de ressources existantes ou nouvelles ; DeployIfNotExists — déploie une ressource associée si une condition n’est pas remplie (par exemple, une extension de diagnostic sur chaque VM).

Une attribution de stratégie applique une définition de stratégie à une portée précise : groupe de gestion, abonnement ou groupe de ressources. Toutes les ressources de cette portée (et des portées enfants) sont évaluées par rapport à la stratégie attribuée. Les attributions peuvent inclure des paramètres ; par exemple, une stratégie qui limite les régions Azure autorisées peut être paramétrée afin que la même définition soit attribuée avec différentes listes de régions dans différents groupes de gestion.

Une définition d’initiative (également appelée ensemble de stratégies) regroupe plusieurs définitions de stratégies associées dans un seul package pouvant être attribué. Au lieu d’attribuer 20 stratégies individuelles, vous attribuez une seule initiative. Azure fournit des initiatives intégrées pour des cadres de conformité tels que ISO 27001, NIST SP 800-53, Azure Security Benchmark et PCI DSS. Par exemple, l’attribution de l’initiative CIS Microsoft Azure Foundations Benchmark évalue simultanément votre abonnement par rapport à plus de 180 contrôles de sécurité.

Après l’attribution d’une stratégie, Azure évalue toutes les ressources existantes dans la portée et génère un rapport de conformité. Le rapport présente le pourcentage global de conformité (ressources conformes / nombre total de ressources), l’état de conformité de chaque ressource et les conditions précises de la stratégie qui ont échoué. Vous pouvez filtrer par initiative de stratégie, portée ou type de ressource. Les ressources non conformes sont répertoriées avec la règle exacte de la stratégie qu’elles ont enfreinte, ce qui facilite la correction.

Pour les stratégies utilisant l’effet DeployIfNotExists ou Modify, Azure peut créer des tâches de correction afin de mettre en conformité les ressources existantes non conformes. Par exemple, une stratégie DeployIfNotExists qui déploie un agent Log Analytics sur chaque VM peut déclencher une tâche de correction pour installer l’agent sur toutes les VM existantes qui n’en disposent pas encore. Les nouvelles ressources sont automatiquement corrigées lors de leur création ; les ressources existantes nécessitent une tâche de correction explicite.

Il arrive que certaines ressources doivent légitimement être exclues d’une stratégie : une ressource Legacy qui ne peut pas être modifiée ou une exception approuvée et documentée dans une demande de changement. Les exemptions de stratégie vous permettent d’exclure une ressource ou un groupe de ressources précis d’une attribution de stratégie sans supprimer la stratégie globalement. Les exemptions possèdent une date d’expiration facultative et une catégorie (Waiver ou Mitigated) permettant de documenter le motif de l’exception.

DeployIfNotExists est l’un des effets de stratégie les plus puissants. Lorsqu’une ressource est créée sans une ressource associée requise (par exemple, une VM sans extension de diagnostic), la stratégie déclenche automatiquement le déploiement d’un modèle ARM pour ajouter le composant manquant. Azure Policy peut ainsi devenir un outil automatisé de gestion de la configuration : chaque VM dispose toujours d’agents de supervision, chaque compte de stockage dispose toujours d’une protection avancée contre les menaces et chaque base de données SQL dispose toujours de l’audit activé.

Les organisations utilisent Azure Policy dans de nombreux scénarios de gouvernance. Restrictions de localisation — autoriser uniquement les ressources dans les régions Azure approuvées pour respecter la souveraineté des données. Types de ressources autorisés — empêcher le déploiement de services coûteux ou non approuvés. Imposition des balises — exiger les balises CostCentre et Environment sur toutes les ressources. Restrictions de SKU — limiter les tailles de VM à des niveaux adaptés aux coûts dans les abonnements hors production. Référentiels de sécurité — imposer TLS 1.2 au minimum, désactiver l’accès réseau public aux comptes de stockage et exiger des points de terminaison privés.

Il est important de comprendre les rôles différents de RBAC et d’Azure Policy. RBAC contrôle qui peut effectuer des opérations : il accorde ou refuse des actions en fonction de l’identité. Azure Policy contrôle ce que doit être la configuration de la ressource : il évalue et impose les propriétés, quelle que soit la personne qui effectue l’action. Les deux sont nécessaires dans un environnement correctement gouverné : RBAC garantit que seules les personnes autorisées déploient des ressources, et Azure Policy garantit que ces ressources respectent les normes de configuration.

Testez votre compréhension des concepts fondamentaux de Microsoft Azure (AZ-900) abordés dans cette leçon.

Dans cette leçon, vous avez appris que Azure Policy définit des conditions et des effets pour contrôler la configuration des ressources à n’importe quelle portée, que les définitions d’initiatives regroupent plusieurs stratégies dans un seul package de conformité pouvant être attribué, et que DeployIfNotExists permet d’imposer automatiquement la configuration des composants manquants à grande échelle. Nous allons maintenant étudier les balises de ressources et les verrous de ressources pour protéger les ressources Azure.