Microsoft AZ-900: Gouvernance et conformité — Guide d'étude

By Laurynas Brazys · 22 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure AZ-900 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

La gouvernance dans Azure aligne l’utilisation du cloud sur les exigences métier, de sécurité et réglementaires grâce à un ensemble de contrôles à plusieurs niveaux : structure organisationnelle, stratégie, déploiements standardisés, protection contre les modifications accidentelles et audit continu. Ces fonctionnalités opèrent nativement dans le plan de contrôle d’Azure Resource Manager et s’adaptent d’un abonnement unique à de vastes environnements multi-locataires. Une bonne gouvernance réduit la dérive, garantit la cohérence et fournit des preuves de conformité sans entraver la vélocité des développeurs. La conformité dépend d’un inventaire et d’un historique des modifications solides. Azure offre une visibilité quasi en temps réel des ressources à travers les abonnements, des mappages réglementaires prescriptifs, ainsi que la découverte de données pour localiser et classifier les informations sensibles. Le résultat est une posture cloud défendable où les normes sont définies une seule fois, appliquées automatiquement, prouvées en continu et corrigées à grande échelle.

Azure Policy : définitions, initiatives, contrôles d’emplacement et remédiation

Azure Policy définit des garde-fous qui évaluent les configurations des ressources lors de leur création/mise à jour (et régulièrement par la suite) et appliquent les états souhaités. Une définition de stratégie utilise des conditions et des effets pour évaluer les propriétés des ressources exposées par les fournisseurs de ressources. Les effets principaux incluent Deny, Audit, Append, Modify, DeployIfNotExists, AuditIfNotExists et Disabled. Les stratégies peuvent être attribuées au niveau du groupe d’administration, de l’abonnement, du groupe de ressources ou de la ressource, et l’héritage garantit que les attributions plus larges sont appliquées aux niveaux inférieurs, sauf si elles sont exclues via notScopes. Les initiatives regroupent des définitions de stratégie connexes en un seul package avec des paramètres pour une attribution cohérente et reproductible. Par exemple, une initiative de référence en matière de sécurité peut inclure des stratégies qui exigent des paramètres de diagnostic, restreignent les points de terminaison publics, imposent le balisage et auditent l’absence de sauvegarde. L’attribution de l’initiative applique toutes les stratégies incluses en une seule action et produit une vue de conformité unique. Les stratégies intégrées « Emplacements autorisés » (Allowed locations) limitent les endroits où les groupes de ressources et les ressources peuvent être créés, empêchant le déploiement dans des régions non approuvées et aidant à la résidence et à la souveraineté des données. Lorsqu’une demande de création cible une région interdite, l’effet Deny bloque l’opération avant qu’elle n’atteigne le fournisseur de ressources, garantissant une conformité stricte. Lorsqu’une dérive est découverte, des tâches de remédiation remettent les ressources en conformité à grande échelle. Pour les stratégies DeployIfNotExists et Modify, l’identité managée d’une attribution de stratégie est utilisée pour reconfigurer les ressources non conformes (par exemple, en activant les paramètres de diagnostic sur les comptes de stockage ou en ajoutant les balises requises). Les tâches de remédiation peuvent avoir une portée restreinte ou s’exécuter sur des abonnements entiers, et les résultats de conformité sont présentés par stratégie et par ressource pour le traçage d’audit.

• Objectif
  • Définition de stratégie : Règle unique évaluant les propriétés des ressources
  • Initiative (Ensemble de stratégies) : Ensemble de définitions de stratégie avec des paramètres partagés
  • Portée de l’attribution : Groupe d’administration, abonnement, groupe de ressources ou ressource
  • Effets courants : Deny, Audit, Append, Modify, DeployIfNotExists, AuditIfNotExists
  • Prérequis pour la remédiation : Identité managée sur l’attribution ; applicable à Modify/DeployIfNotExists
• Cas d’utilisation
  • Définition de stratégie : Imposer des références SKU, TLS, des balises, des points de terminaison privés
  • Initiative (Ensemble de stratégies) : Appliquer une référence de sécurité ou de gouvernance
  • Portée de l’attribution : Application large avec héritage et exclusions
  • Effets courants : Application stricte ou audit à des fins de preuve uniquement
  • Prérequis pour la remédiation : Autorisations suffisantes pour modifier les ressources cibles

Azure Blueprints : empaquetage des normes avec stratégie, RBAC, groupes de ressources et modèles

Azure Blueprints empaquette des artefacts de gouvernance pour que les organisations puissent déployer de manière cohérente des environnements conformes. Une définition de blueprint peut inclure des attributions de stratégie, des attributions de contrôle d’accès basé sur les rôles (RBAC) Azure, des définitions de groupes de ressources et des artefacts de déploiement tels que des modèles ARM (y compris Bicep) pour provisionner une infrastructure standard. Les paramètres permettent une personnalisation par attribution tout en conservant une source de vérité unique et versionnée. Les blueprints aident à séparer « ce qui doit exister et qui peut faire quoi » du code de la charge de travail. Par exemple, un blueprint de référence peut créer des groupes de ressources spoke, attribuer le rôle Lecteur aux équipes d’audit et Contributeur aux équipes de plateforme, déployer un modèle de réseau en étoile (hub-and-spoke) et attribuer des initiatives pour le diagnostic et la sécurité. L’attribution du blueprint à un ou plusieurs abonnements applique tous les artefacts dans le bon ordre et enregistre l’état de conformité. Le versionnage prend en charge les mises à jour contrôlées, et le verrouillage des artefacts peut protéger les composants critiques après le déploiement.

• Objectif principal
  • Azure Policy : Garde-fous de configuration et de conformité
  • Modèles ARM/Bicep : Déploiement déclaratif de ressources
  • Azure Blueprints : Empaquetage et gouvernance des normes à travers les abonnements
• Inclut le RBAC
  • Azure Policy : Non (attribution séparée)
  • Modèles ARM/Bicep : Non (attribution séparée)
  • Azure Blueprints : Oui (attributions de rôle en tant qu’artefacts)
• Inclut la stratégie (Policy)
  • Azure Policy : S/O
  • Modèles ARM/Bicep : Non (peut déployer des ressources de stratégie, mais pas les attribuer)
  • Azure Blueprints : Oui (attributions de stratégie en tant qu’artefacts)
• Crée des groupes de ressources
  • Azure Policy : Peut exiger/imposer un nommage/des balises
  • Modèles ARM/Bicep : Peut déployer dans ou créer via des déploiements imbriqués
  • Azure Blueprints : Oui (définit des artefacts de RG dans le cadre du blueprint)
• Utilisation typique
  • Azure Policy : Restreindre les références SKU, imposer les diagnostics, les balises
  • Modèles ARM/Bicep : Provisionner des VNet, des Key Vaults, des App Services
  • Azure Blueprints : Déployer des zones d’atterrissage conformes avec stratégie + RBAC + infra

Organisation et normes : groupes d’administration, abonnements, groupes de ressources, nommage et étiquettes

La hiérarchie de gestion d’Azure permet une gouvernance à grande échelle. Les groupes d’administration se situent au-dessus des abonnements et fournissent un emplacement pour appliquer des stratégies et un contrôle d’accès en fonction du rôle (RBAC) qui sont hérités par tous les abonnements enfants. Les abonnements définissent la facturation, les quotas de service et une limite de sécurité pour la plupart des contrôles. Les groupes de ressources contiennent des ressources ayant un cycle de vie, des autorisations et une logique de déploiement alignés ; chaque ressource appartient à un seul groupe de ressources et à un seul abonnement. Les normes de nommage et d’étiquetage (tagging) traduisent l’intention de gouvernance en clarté opérationnelle. Les noms doivent encoder des abréviations de type de ressource, la charge de travail (workload), l’environnement et la région (par exemple, kv-payroll-prod-eus2) dans les limites du service. Les étiquettes (tags) ajoutent un contexte métier aux ressources pour la répartition des coûts, la propriété, la classification des données et les clés d’automatisation (par exemple, costCenter=FIN, owner=ops-team@contoso.com, dataSensitivity=Confidential). Azure Policy, avec les effets Modify et Append, impose la présence des étiquettes et des modèles de valeur, et peut hériter des étiquettes des groupes de ressources vers les ressources. La cohérence à ce niveau permet d’obtenir des rapports de coûts fiables, des révisions d’accès et une automatisation du cycle de vie.

• Groupe d’administration (Management Group)
  • Objectif : Gouverner à grande échelle sur plusieurs abonnements
  • Usages courants : Appliquer des stratégies, du RBAC et des initiatives aux unités commerciales ou aux environnements
  • Peut contenir : Des groupes d’administration enfants et des abonnements
  • Notes clés : Jusqu’à 6 niveaux de profondeur (hors racine) ; l’héritage se propage vers le bas
• Abonnement (Subscription)
  • Objectif : Limite de facturation et de service
  • Usages courants : Isolation des charges de travail, ségrégation des coûts, gestion des quotas
  • Peut contenir : Des groupes de ressources et des ressources
  • Notes clés : Les attributions de stratégies/RBAC à ce niveau affectent tous les groupes de ressources qu’il contient
• Groupe de ressources (Resource Group)
  • Objectif : Limite de cycle de vie et d’autorisations pour les ressources
  • Usages courants : Déployer, mettre à jour et supprimer ensemble les ressources associées
  • Peut contenir : Des ressources
  • Notes clés : Une ressource ne peut exister que dans un seul RG ; les déplacements entre RG/abonnements ont des contraintes spécifiques au service

Verrous de ressources et prévention de la suppression accidentelle

Les verrous de ressources constituent une dernière ligne de défense contre les modifications involontaires. Les verrous sont appliqués au niveau de l’abonnement, du groupe de ressources ou de la ressource et sont hérités vers le bas. Il existe deux types de verrous : CanNotDelete empêche la suppression mais autorise les opérations de lecture et d’écriture, et ReadOnly restreint toutes les opérations d’écriture et de suppression (autorisant de fait uniquement les opérations de lecture). Les verrous protègent contre les actions provenant du portail, de la CLI, de PowerShell, d’ARM/Bicep et des outils IaC tiers. Utilisez CanNotDelete sur l’infrastructure partagée ou critique — réseaux virtuels, tables de routage, zones DNS, Key Vaults de production — afin que la maintenance puisse se poursuivre pendant que les suppressions sont bloquées. Utilisez ReadOnly avec parcimonie pour les artefacts qui doivent rester complètement statiques, tels que les comptes de stockage archivés ou les conteneurs de preuves réglementaires ; de nombreux services nécessitent des écritures pour leur fonctionnement normal et échoueront sous un verrou ReadOnly. Seuls les principaux disposant des autorisations suffisantes (par exemple, le rôle Propriétaire avec Microsoft.Authorization/locks/*) peuvent supprimer un verrou, et la suppression d’un verrou est elle-même une opération auditable dans l’Activity Log.

• CanNotDelete
  • Lectures : Autorisées
  • Écritures/Mises à jour : Autorisées
  • Suppressions : Bloquées
  • Cas d’usage typiques : Protéger les VNets, les tables de routage, les Key Vaults de production, les RG critiques
  • Considérations : Autorise les changements de configuration ; les opérations de suppression échouent jusqu’à ce que le verrou soit retiré
• ReadOnly
  • Lectures : Autorisées
  • Écritures/Mises à jour : Bloquées
  • Suppressions : Bloquées
  • Cas d’usage typiques : Préserver les magasins de preuves, le stockage d’archivage, les configurations immuables
  • Considérations : De nombreux services ne fonctionnent pas sous ReadOnly ; les mises à jour et la mise à l’échelle sont bloquées

Audit, inventaire et conformité réglementaire : Resource Graph, Activity Log, Defender for Cloud et Microsoft Purview

Azure Resource Graph fournit des requêtes d’inventaire et de posture rapides et à grande échelle sur les abonnements et les groupes d’administration à l’aide du Kusto Query Language (KQL). Il permet de répondre à des questions telles que : quels comptes de stockage ne disposent pas de chiffrement, quels réseaux virtuels (VNets) exposent des adresses IP publiques et quelles ressources ne sont pas conformes aux stratégies. Les résultats alimentent les tableaux de bord, la synchronisation des CMDB et les pipelines de remédiation. Resource Graph peut également faire apparaître les états de conformité des stratégies, la distribution des balises (tags) et les dimensions d’attribution des coûts lorsqu’il est combiné avec les données de Cost Management. L’Azure Activity Log enregistre les opérations du plan de contrôle sur les ressources, y compris qui a fait quoi et quand, avec une rétention par défaut de 90 jours. Transférez l’Activity Log vers Log Analytics, Azure Storage ou Event Hubs pour une rétention à long terme, une corrélation et une ingestion SIEM. L’analyse de l’historique des modifications identifie la dérive de configuration, soutient la réponse aux incidents et fournit des preuves pour les audits. Microsoft Defender for Cloud traduit la posture technique en vues réglementaires en mappant les évaluations à des normes telles que Azure Security Benchmark, ISO/IEC 27001, NIST SP 800-53, PCI DSS et CIS. Le tableau de bord de conformité réglementaire affiche les contrôles réussis/échoués, les ressources affectées et les conseils de remédiation. L’activation de l’approvisionnement automatique intègre les agents et les stratégies là où c’est nécessaire, et le score de sécurité offre un prisme de priorisation. Microsoft Purview découvre, classifie et catalogue les données à travers les sources Azure, multicloud et sur site (on-premises). Les analyses identifient les données sensibles (par exemple, financières, PII, de santé) dans Azure Storage, SQL, Synapse, Power BI, et bien d’autres, en appliquant des classifieurs intégrés ou personnalisés. Le Purview Data Map and Catalog fournissent le lignage, la propriété et l’étiquetage de sensibilité qui s’intègrent avec Microsoft Information Protection, permettant la prévention de la perte de données et des décisions de stratégie d’accès alignées sur les obligations réglementaires.

• Fonction principale
  • Azure Resource Graph : Requêtes d’inventaire et de posture à grande échelle
  • Activity Log : Piste d’audit du plan de contrôle des opérations
  • Defender for Cloud (Réglementaire) : Mapper la posture aux normes et prioriser les correctifs
  • Microsoft Purview : Découverte, classification, catalogue et lignage des données
• Portée
  • Azure Resource Graph : Sur les groupes d’administration/abonnements
  • Activity Log : Par locataire (tenant) avec routage vers LA/Storage/Event Hub
  • Defender for Cloud (Réglementaire) : Par abonnement/locataire (tenant) avec des attributions d’initiatives
  • Microsoft Purview : Sur les sources de données (Azure, M365, sur site, multicloud)
• Sorties typiques
  • Azure Resource Graph : Résultats de requêtes KQL, tableaux de bord, exportations
  • Activity Log : Qui/quoi/quand, statut, codes d’erreur
  • Defender for Cloud (Réglementaire) : Statut de conformité des contrôles, score de sécurité, recommandations
  • Microsoft Purview : Actifs de données, étiquettes de sensibilité, schéma, graphes de lignage

Problème pratique : Standardisation des zones d’atterrissage conformes chez Fabrikam Retail Group

Scénario : Fabrikam Retail Group opère en Amérique du Nord et dans l’UE avec des obligations strictes en matière de résidence des données et de conformité PCI DSS. De multiples équipes applicatives déploient des charges de travail chaque mois, et les déploiements ponctuels antérieurs ont conduit à un étiquetage incohérent, à des ressources dans des régions non approuvées et à la suppression occasionnelle de ressources réseau partagées. La direction exige des zones d’atterrissage standardisées et conformes, une preuve continue de l’efficacité des contrôles et la découverte des données sensibles à travers les plateformes de stockage et d’analyse.

Défi : Concevoir et mettre en œuvre une approche de gouvernance Azure qui applique des restrictions de région, standardise les déploiements avec des stratégies et le RBAC, empêche la suppression accidentelle de l’infrastructure de base, maintient un inventaire et un historique des modifications, génère des rapports de conformité avec ISO 27001 et PCI DSS, et découvre/classifie les données sensibles.

Approche recommandée :

1. Créer une hiérarchie de groupes d’administration : racine /Fabrikam ; enfants /Corp (services partagés), /NA et /EU ; sous chacun, ajouter /Prod et /NonProd. Déplacer les abonnements dans les groupes d’administration appropriés.
2. Créer des initiatives de stratégie au niveau du groupe d’administration : (a) Emplacements autorisés par zone géographique, (b) Étiquettes requises (costCenter, owner, dataSensitivity) avec les effets Modifier/Ajouter, (c) Appliquer les paramètres de diagnostic vers Log Analytics pour les services principaux, (d) Restrictions sur les références SKU et l’accès réseau public pour les services PaaS. Attribuer les initiatives à /NA et /EU avec des paramètres de région appropriés et exclure les abonnements de secours via notScopes.
3. Empaqueter un blueprint pour la zone d’atterrissage standard : les artefacts incluent la création de groupes de ressources hub et applicatifs, les attributions RBAC (Contributeur de réseau à l’équipe plateforme, Lecteur à l’audit), les attributions de stratégie pour les diagnostics et les étiquettes, et les modèles ARM pour déployer les VNet, les peerings, Key Vault et Log Analytics. Versionner le blueprint et l’attribuer à tous les abonnements Prod et NonProd.
4. Appliquer des verrous de ressource : CanNotDelete sur les VNet du hub, les tables de routage, les zones DNS partagées et les espaces de travail Log Analytics ; ReadOnly sur un compte de stockage d’archivage pour les exportations réglementaires. Valider que les Propriétaires des abonnements de services partagés peuvent supprimer les verrous avec les approbations requises lorsque des modifications sont planifiées.
5. Activer l’exportation du journal d’activité de tous les abonnements vers un espace de travail Log Analytics central et l’archivage vers un compte de stockage avec une rétention immuable (basée sur le temps) de sept ans. Créer des tableaux de bord Resource Graph qui listent les ressources non conformes, les étiquettes manquantes et les actifs par région et par étiquette dataSensitivity.
6. Activer Microsoft Defender for Cloud sur l’ensemble du tenant. Sélectionner ISO/IEC 27001 et PCI DSS comme normes réglementaires, activer le provisionnement automatique et examiner les recommandations. Créer des éléments de travail à partir des résultats de haute gravité et suivre les améliorations du score de sécurité par abonnement.
7. Déployer Microsoft Purview dans l’abonnement des services partagés /Corp. Inscrire Azure SQL, Storage, Synapse et Power BI comme sources de données. Configurer des analyses planifiées avec les types d’informations sensibles intégrés et classifier les jeux de données. Publier le catalogue de données et attribuer des propriétaires de données. Exporter les étiquettes de sensibilité découvertes pour alimenter l’accès conditionnel et la DLP.

Justification pour Azure : Cette approche commence par le ciblage par groupe d’administration afin que la stratégie et le RBAC héritent de manière prévisible, puis applique les contrôles fondamentaux avec Azure Policy et des initiatives pour prévenir la non-conformité au moment du déploiement. Le blueprint empaquette la stratégie, le RBAC, les groupes de ressources et les modèles d’infrastructure pour créer des zones d’atterrissage cohérentes tout en permettant la paramétrisation par région et par environnement. Les verrous de ressource protègent les services partagés critiques contre la suppression accidentelle sans entraver la configuration quotidienne lorsque cela est approprié. La rétention centralisée du journal d’activité et Resource Graph fournissent un inventaire fiable et une preuve des modifications. Defender for Cloud offre une cartographie en temps réel des contrôles réglementaires et une remédiation priorisée, tandis que Microsoft Purview découvre et classifie les données sensibles pour soutenir les contrôles PCI DSS et de résidence des données à travers le parc analytique de Fabrikam.

← Gestion des coûts et économie des services · Tous les domaines · Surveillance →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Microsoft →