📍 Article principal du cluster : Azure Solutions Architect Expert AZ-305 — guide complet 2026

Ce tutoriel fait partie du cluster certification AZ-305. Pour la vue d’ensemble, lisez d’abord le pilier.

Introduction

Le domaine 1 « Design identity, governance, and monitoring solutions » est le plus dense de l’examen AZ-305. Il combine trois sous-domaines testés simultanément dans les cas d’étude : identité (Entra ID, Conditional Access, PIM), gouvernance (management groups, Azure Policy, Landing Zones), et monitoring (Azure Monitor, Log Analytics, Application Insights, Sentinel). Ce tutoriel construit une architecture identity-governance-monitoring de référence sur un tenant Azure de pratique, avec des configurations identiques à ce que vous mettrez en place pour un client en mission consulting.

Prérequis

Compte Microsoft Azure avec abonnement Free Tier ou Pay-As-You-Go
Tenant Entra ID disponible (créé automatiquement à l’ouverture de votre compte Azure)
Azure CLI v2.65+ installé localement, et Microsoft Graph PowerShell modules
50 minutes

Étape 1 — Créer la hiérarchie de Management Groups

Les management groups organisent vos abonnements en hiérarchie pour appliquer policies et RBAC à grande échelle. La structure recommandée par le Cloud Adoption Framework Enterprise-Scale Landing Zone : Tenant Root → Platform / Landing Zones / Decommissioned / Sandbox. Pour un labo, on construit une version simplifiée.

az login
TENANT_ID=$(az account show --query tenantId -o tsv)

# Créer la hiérarchie
az account management-group create --name "platform" --display-name "Platform"
az account management-group create --name "landingzones" --display-name "Landing Zones"
az account management-group create --name "lz-corp" --display-name "LZ Corp" --parent landingzones
az account management-group create --name "lz-online" --display-name "LZ Online" --parent landingzones
az account management-group create --name "sandbox" --display-name "Sandbox"

az account management-group list --query '[].{name:name,displayName:displayName,parent:properties.details.parent.displayName}' -o table

Cette structure isole les workloads corporate (lz-corp, applications internes connectées on-premise) des workloads online (lz-online, applications publiques internet) et des expérimentations (sandbox). Chaque groupe peut recevoir des policies différentes — par exemple sandbox autorise n’importe quelle SKU et région, alors que lz-corp impose Europe seulement avec coût ≤ 500 USD/mois.

Étape 2 — Définir une Azure Policy de tagging obligatoire

Le tagging cohérent est la base de la traçabilité coût et conformité. Une policy qui force la présence des tags Environment, CostCenter et Owner sur toute ressource — bloque les déploiements sans ces tags.

cat > /tmp/require-tags-policy.json <<'EOF'
{
  "properties": {
    "displayName": "Require Environment, CostCenter, Owner tags",
    "policyType": "Custom",
    "mode": "Indexed",
    "parameters": {},
    "policyRule": {
      "if": {
        "anyOf": [
          { "field": "tags.Environment", "exists": "false" },
          { "field": "tags.CostCenter", "exists": "false" },
          { "field": "tags.Owner", "exists": "false" }
        ]
      },
      "then": {
        "effect": "deny"
      }
    }
  }
}
EOF

# Créer la policy au niveau management group
az policy definition create \
  --name "require-tagging" \
  --management-group landingzones \
  --rules /tmp/require-tags-policy.json

# Assigner la policy
az policy assignment create \
  --name "require-tagging-assignment" \
  --policy "require-tagging" \
  --scope "/providers/Microsoft.Management/managementGroups/landingzones"

Toute tentative de création de ressource sans les 3 tags retourne un PolicyViolation 403. Pattern qui économise des centaines d’heures d’audit a posteriori — en industrie, ces 3 tags sont le minimum vital.

Étape 3 — Initiative Azure Policy multi-règles

Une initiative regroupe plusieurs policies en un seul ensemble assignable. Pour le pattern Landing Zone Enterprise-Scale, l’initiative typique inclut : tagging obligatoire, location whitelist (West Europe, North Europe), SKU whitelist (Standard et au-dessus, pas de Basic), denial des publics IPs non autorisées.

# Initiative avec 3 policies built-in + 1 custom
cat > /tmp/initiative.json <<'EOF'
{
  "properties": {
    "displayName": "Landing Zone Baseline",
    "policyDefinitions": [
      {
        "policyDefinitionId": "/subscriptions/SUBID/providers/Microsoft.Authorization/policyDefinitions/require-tagging"
      },
      {
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c"
      },
      {
        "policyDefinitionId": "/providers/Microsoft.Authorization/policyDefinitions/0a914e76-4921-4c19-b460-a2d36003525a"
      }
    ]
  }
}
EOF

# Note: 'e56962a6...' = "Allowed locations" built-in
# '0a914e76...' = "Audit VMs without disaster recovery" built-in

az policy set-definition create \
  --name "lz-baseline" \
  --management-group landingzones \
  --definitions /tmp/initiative.json

Une initiative est plus puissante qu’une assignation individuelle car elle se modifie d’un seul endroit. Pattern critique en domaine 1 — les questions AZ-305 testent souvent « comment appliquer 5 règles cohérentes à 200 abonnements ».

Étape 4 — Configurer Conditional Access avec MFA

Conditional Access est le gardien d’Entra ID en 2026. Une politique typique : « Tous les utilisateurs admins doivent passer MFA + device compliant pour accéder au portail Azure ». Configuration via le portail ou via Microsoft Graph PowerShell.

Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess","Policy.Read.All"

# Récupérer l'ID du groupe Admins
$adminGroup = New-MgGroup -DisplayName "Cloud Admins" `
  -MailEnabled:$false -SecurityEnabled:$true `
  -MailNickname "cloudadmins"

$body = @{
    displayName = "Require MFA + Compliant Device for Admins"
    state = "enabled"
    conditions = @{
        users = @{
            includeGroups = @($adminGroup.Id)
        }
        applications = @{
            includeApplications = @("All")
        }
    }
    grantControls = @{
        operator = "AND"
        builtInControls = @("mfa", "compliantDevice")
    }
}

New-MgIdentityConditionalAccessPolicy -BodyParameter $body

Cette politique s’applique uniquement au groupe Cloud Admins. Pattern fortement recommandé : démarrer en mode « Report-only » pour mesurer l’impact, puis basculer en « On » après validation. Tombe en domaine 1 sur les questions « zero-trust posture ».

Étape 5 — Activer Privileged Identity Management

PIM transforme les rôles permanents en rôles « eligible » qui doivent être activés via une demande just-in-time. Réduit massivement la surface d’attaque — un attaquant qui compromet un compte n’a pas immédiatement les droits admin.

# PIM est inclus dans Entra ID P2. Activation via portail Azure
# Portal: Azure AD → Privileged Identity Management → Activate PIM

# Convertir un rôle permanent en eligible
az role assignment create \
  --assignee "user@tenant.onmicrosoft.com" \
  --role "Owner" \
  --scope "/subscriptions/SUBSCRIPTION_ID" \
  --condition "@Resource[Microsoft.Authorization/roleAssignments:Operation] StringEqualsIgnoreCase 'eligible'"

Une fois PIM activé, l’utilisateur doit cliquer « Activate » dans le portail PIM pour obtenir le rôle pendant 8 heures (durée configurable). MFA + justification text obligatoires. Audit trail complet exposé dans Log Analytics.

Étape 6 — Créer un Log Analytics workspace

Log Analytics est le pivot de l’observabilité Azure. Tous les logs (Activity Logs, Diagnostic Logs des ressources, Application Insights, Defender pour Cloud, Sentinel) atterrissent dans un workspace centralisé. KQL est le langage de requête.

az group create --name rg-monitoring --location westeurope

az monitor log-analytics workspace create \
  --resource-group rg-monitoring \
  --workspace-name law-az305-prod \
  --location westeurope \
  --sku PerGB2018 \
  --retention-time 90

WORKSPACE_ID=$(az monitor log-analytics workspace show \
  --resource-group rg-monitoring \
  --workspace-name law-az305-prod \
  --query customerId -o tsv)
echo "Workspace ID: $WORKSPACE_ID"

La rétention 90 jours est le standard pour la conformité. Pour la BCEAO et OHADA, certains workloads exigent 1-2 ans — augmenter via `–retention-time 730`. Le pricing est par Go ingéré (variable selon région, environ 2-4 USD/Go en 2026).

Étape 7 — Activer Diagnostic Settings sur tous les services

Sans Diagnostic Settings activées, vos ressources Azure ne logguent rien dans Log Analytics. C’est l’erreur classique des architectures naissantes — vous voyez le service tourner mais aucune trace en cas d’incident.

# Pour une VM
az monitor diagnostic-settings create \
  --name "vm-diag" \
  --resource "/subscriptions/SUB_ID/resourceGroups/rg/providers/Microsoft.Compute/virtualMachines/vm-name" \
  --workspace law-az305-prod \
  --logs '[{"category":"all","enabled":true}]' \
  --metrics '[{"category":"AllMetrics","enabled":true}]'

# Pour appliquer en masse, utiliser Azure Policy "DeployIfNotExists"
# Built-in: "Configure diagnostic settings to a Log Analytics workspace"

L’approche scalable est d’utiliser la policy built-in « DeployIfNotExists » qui auto-active Diagnostic Settings sur toute ressource créée. Configuration once, applicable à tous les abonnements via management group.

Étape 8 — Application Insights pour applications

Application Insights est l’APM de Microsoft pour applications .NET, Node.js, Python, Java. Trace les requêtes, dépendances, exceptions, métriques custom. Crée automatiquement un service map.

az monitor app-insights component create \
  --app ai-az305-app \
  --location westeurope \
  --resource-group rg-monitoring \
  --workspace law-az305-prod

INSTRUMENTATION_KEY=$(az monitor app-insights component show \
  --app ai-az305-app \
  --resource-group rg-monitoring \
  --query instrumentationKey -o tsv)

echo "Instrumentation Key: $INSTRUMENTATION_KEY"

Important en 2026 : Application Insights utilise désormais les Connection Strings (incluant l’instrumentation key + endpoint URL) plutôt que la simple instrumentation key. Le pattern « workspace-based App Insights » (créé avec `–workspace`) est le seul recommandé — l’ancien standalone est deprecated.

Étape 9 — Sentinel pour SIEM moderne

Microsoft Sentinel est le SIEM cloud-natif basé sur Log Analytics. Il ajoute la couche détection (analytic rules), réponse (playbooks Logic Apps), et investigation (workbooks) au-dessus du workspace.

az sentinel onboard --resource-group rg-monitoring --workspace-name law-az305-prod

# Connecter une data source — Activity Logs
az sentinel data-connector create \
  --resource-group rg-monitoring \
  --workspace-name law-az305-prod \
  --data-connector-id "AzureActivity" \
  --data-connector-properties '{"subscriptionId":"SUB_ID"}'

Sentinel coût additionnel d’environ 2-4 USD/Go au-dessus du Log Analytics standard. Pour une PME, environ 30-80 USD/mois pour une couverture sécurité décente — bien moins qu’un SIEM commercial type Splunk Enterprise. Tombe en domaine 1 sur les questions « SIEM design ».

Comprendre la différence Entra ID, AD DS, AAD DS

Trois services qui semblent similaires mais sont différents. Entra ID (anciennement Azure Active Directory) est l’identity provider cloud de Microsoft — pas un Active Directory au sens NT/Kerberos. Il sert OAuth2/OpenID/SAML pour les applis cloud. Active Directory Domain Services (AD DS) est l’AD on-premise classique avec Kerberos, GPO, LDAP. Inutilisable directement dans le cloud sauf à le faire tourner sur des VMs IaaS (anti-pattern). Azure AD Domain Services (AAD DS) est un service managé qui expose une instance AD DS « legacy » synchronisée avec Entra ID — utile pour les workloads legacy qui ont besoin de Kerberos ou GPO et qu’on ne veut pas refactoriser.

Question type AZ-305 : « Une application legacy demande Kerberos et NTLM, doit-on déployer un AD on-premise ou un service Azure ? » Réponse : Azure AD DS — c’est exactement ce service qui répond au cas. Erreur classique : confondre Entra ID (cloud-only OAuth) avec AAD DS (Kerberos managé).

Erreurs fréquentes

Erreur	Cause	Solution
Policy assigment ne s’applique pas	Scope mal défini	Vérifier le scope ARM (subscription vs RG vs management group)
Conditional Access bloque l’admin global	Pas d’exclusion break-glass account	Toujours créer 2 break-glass accounts exclus de toutes les CA policies
PIM disponible mais grisé	License Entra ID P2 manquante	Souscrire à Entra ID P2 (10 USD/utilisateur/mois) ou tier supérieur Microsoft 365
Log Analytics ne reçoit aucun log	Diagnostic Settings non activées	Auto-déployer via policy DeployIfNotExists au niveau management group
Sentinel coûts explosent	Trop de data sources sans filtrage	Utiliser Data Collection Rules (DCR) pour filtrer les logs avant ingestion

Adaptation au contexte ouest-africain

Pour les organisations dakaroises et abidjanaises qui démarrent leur transformation Azure, l’investissement dans Entra ID P2 + PIM + Conditional Access est très rentable : environ 10 USD/utilisateur/mois pour la P2, déployable progressivement (P2 uniquement pour les admins critiques, P1 pour le reste). Cette posture identité couvre 80 % des risques cyber liés à l’humain (phishing, credentials volés, lateral movement). Pour une banque ou fintech régulée BCEAO, c’est un investissement obligatoire pour les audits SI annuels.

Tutoriels frères

Stockage Azure end-to-end — Cosmos DB, SQL Database, Data Lake (à venir)
Disaster recovery avec Azure Site Recovery et Backup (à venir)

Pour aller plus loin

🔝 Retour au pilier : AZ-305 — guide complet
Microsoft Entra ID : learn.microsoft.com/fr-fr/entra/identity
Azure Policy : learn.microsoft.com/fr-fr/azure/governance/policy
Microsoft Sentinel : learn.microsoft.com/fr-fr/azure/sentinel

FAQ

Entra ID Free, P1 ou P2 ?
Free pour début (limité aux fonctions basiques). P1 (6 USD/user/mois) pour Conditional Access + Self-Service Password Reset. P2 (9 USD/user/mois) pour PIM + Identity Protection. La majorité des architectures AZ-305 production tournent en P2.

Combien de management groups maximum ?
10 000 par tenant Microsoft, 6 niveaux de profondeur. Largement suffisant pour 99,99 % des organisations.

Mots-clés secondaires : entra id conditional access, azure policy initiative, management groups hierarchy, pim privileged identity, log analytics workspace, sentinel siem, application insights connection string

Identity, governance et monitoring Azure pour AZ-305 en 2026

Introduction

Prérequis

Étape 1 — Créer la hiérarchie de Management Groups

Étape 2 — Définir une Azure Policy de tagging obligatoire

Étape 3 — Initiative Azure Policy multi-règles

Étape 4 — Configurer Conditional Access avec MFA

Étape 5 — Activer Privileged Identity Management

Étape 6 — Créer un Log Analytics workspace

Étape 7 — Activer Diagnostic Settings sur tous les services

Étape 8 — Application Insights pour applications

Étape 9 — Sentinel pour SIEM moderne

Comprendre la différence Entra ID, AD DS, AAD DS

Erreurs fréquentes

Adaptation au contexte ouest-africain

Tutoriels frères

Pour aller plus loin

FAQ

Confiez-nous la Création de Votre Site Web

Introduction

Prérequis

Étape 1 — Créer la hiérarchie de Management Groups

Étape 2 — Définir une Azure Policy de tagging obligatoire

Étape 3 — Initiative Azure Policy multi-règles

Étape 4 — Configurer Conditional Access avec MFA

Étape 5 — Activer Privileged Identity Management

Étape 6 — Créer un Log Analytics workspace

Étape 7 — Activer Diagnostic Settings sur tous les services

Étape 8 — Application Insights pour applications

Étape 9 — Sentinel pour SIEM moderne

Comprendre la différence Entra ID, AD DS, AAD DS

Erreurs fréquentes

Adaptation au contexte ouest-africain

Tutoriels frères

Pour aller plus loin

FAQ

Confiez-nous la Création de Votre Site Web

Articles Similaires

Trivy, Cosign et supply chain security Kubernetes CKS 2026

CKS Certified Kubernetes Security Specialist — guide complet 2026

Networking Azure hub-spoke — VNet peering, Firewall, Private Endpoints AZ-305