03 · Implémenter la gouvernance pour appliquer la sécurité et la conformité réglementaire

Version : 1.2 · Date : 2026-10-21 · Domaine 1 de l'examen : Manage identity, access, and governance (20 à 25 %)

En une phrase : Azure RBAC décide qui peut agir, Azure Policy décide à quoi les ressources doivent ressembler, les locks et les deny settings empêchent les suppressions, Defender for Cloud mesure la conformité aux normes, Azure Backup protégé garantit le retour arrière, et l'infrastructure en tant que code rend tout cela reproductible.

Ce que l'examen demande#

Repris mot pour mot du guide d'étude SC-500 :

1. Les bases à maîtriser avant tout#

1.1 La hiérarchie de gouvernance#

Tout dans Azure s'organise en quatre niveaux. Ce qui est affecté à un niveau (stratégie, rôle, lock…) s'hérite par tous les niveaux du dessous.

Deux réglages de la hiérarchie sont à connaître :

• par défaut, tout utilisateur du locataire peut créer un management group (il en devient Owner) : activer l'option Require write permissions for creating new management groups dans les Hierarchy settings pour l'empêcher ;
• définir un management group par défaut pour que les nouveaux abonnements n'arrivent pas sous la racine.

Rôles sur un management group :

Important : une assignment (rôle ou policy) sur le Root management group s'applique à toutes les ressources du locataire. Microsoft recommande de n'y mettre que l'indispensable.

1.2 Plan de contrôle et plan de données#

C'est la clé pour comprendre les locks, les rôles et les deny settings.

1.3 Qui fait quoi : ne pas confondre les outils#

Règle d'or (Microsoft) : même si une personne est autorisée à exécuter une action (RBAC), si le résultat est une ressource non conforme, Azure Policy bloque toujours la création ou la mise à jour. Les deux se combinent.

1.4 Complément AZ-500 : l'élévation d'accès (Elevate access) du Global Administrator#

Les rôles Entra et les rôles Azure sont séparés (voir le chapitre 01). Un Global Administrator peut toutefois s'attribuer le rôle User Access Administrator à l'étendue racine /, donc sur tous les abonnements et management groups du locataire :

• portail : Entra ID > Properties > Access management for Azure resources = Yes ;
• c'est un réglage par utilisateur, à remettre à No dès la tâche finie (désactiver le rôle PIM ne le remet pas à No) ;
• l'élévation et son retrait sont journalisés dans l'Activity log Azure et dans les audit logs Entra (service Azure RBAC (Elevated Access)), à surveiller (Sentinel, chapitre 11).

# Élever l'accès (Global Administrator), puis le retirer
az rest --method post --url "/providers/Microsoft.Authorization/elevateAccess?api-version=2016-07-01"
az role assignment list --role "User Access Administrator" --scope "/"
az role assignment delete --assignee [email protected] --role "User Access Administrator" --scope "/"

2. Azure Policy#

2.1 Les trois objets : definition, initiative, assignment#

Points d'examen :

• une stratégie peut être affectée à un management group, mais seules les ressources des abonnements et groupes de ressources sont évaluées ;
• Azure Policy est un système de refus explicite : on ne peut pas « assouplir » à un niveau enfant une stratégie de refus affectée plus haut. Il faut exclure l'enfant de l'assignment du parent, puis affecter une stratégie plus permissive à l'enfant ;
• une assignment utilise toujours la dernière version de sa définition : modifier la définition modifie toutes ses assignments ;
• tous les objets de stratégie (définitions, initiatives, assignments) sont lisibles par tous les rôles de l'étendue.

Limites utiles :

2.2 La structure d'une définition#

Une définition JSON contient : displayName, description, mode, version, metadata, parameters et policyRule (conditions logiques et effect).

Le mode détermine quels types de ressources sont évalués :

Piège : sans mode, Azure PowerShell met all, mais Azure CLI met null, qui équivaut à indexed.

Les conditions comparent un champ (field : name, type, location, tags, identity.type… ou un alias de propriété comme Microsoft.Storage/storageAccounts/…) ou une valeur (value, avec des fonctions de modèle) à une valeur attendue. Opérateurs logiques : allOf, anyOf, not.

Exemple de custom policy definition : refuser toute ressource sans le tag demandé.

{
  "properties": {
    "displayName": "Exiger une étiquette sur les ressources",
    "mode": "Indexed",
    "parameters": {
      "tagName": { "type": "String", "metadata": { "displayName": "Nom de l'étiquette" } }
    },
    "policyRule": {
      "if": { "field": "[concat('tags[', parameters('tagName'), ']')]", "exists": "false" },
      "then": { "effect": "deny" }
    }
  }
}

Piège : si une fonction de modèle dans value échoue, l'évaluation échoue et cela vaut un refus implicite. Tester une nouvelle définition avec enforcementMode = DoNotEnforce.

Stratégies selon l'identité : requestContext().identity permet de baser la règle sur qui fait la requête (par exemple bloquer la création, la mise à jour ou la suppression par un utilisateur qui ne s'est pas authentifié avec la MFA, ou empêcher la suppression manuelle de ressources critiques).

2.3 Les effets#

Ordre d'évaluation (création ou mise à jour) : disabled → append et modify → deny → audit → manual → auditIfNotExists → denyAction, puis, après le succès du Resource Provider, auditIfNotExists et deployIfNotExists.

Effets interchangeables : audit, deny, modify/append souvent ; auditIfNotExists et deployIfNotExists souvent ; manual jamais ; disabled avec tous.

Superposition : chaque assignment est évaluée séparément, le résultat est cumulatif et le plus restrictif l'emporte. Exemple Microsoft : stratégie 1 (Deny hors westus, abonnement A) et stratégie 2 (Audit hors eastus, resource group B) ; une nouvelle ressource dans B en westus est créée mais non conforme à la stratégie 2 ; si les deux étaient en Deny, toute nouvelle ressource de B serait refusée.

Détails de denyAction :

• protège une ressource contre sa suppression directe ;
• ne bloque pas la suppression d'un abonnement ;
• lors de la suppression d'un resource group, ne bloque que si cascadeBehaviors.resourceGroup = deny (valeur par défaut, mode indexed uniquement) ;
• ne protège pas les ressources enfants supprimées avec leur parent (suppression en cascade) ;
• ne s'applique jamais aux policy assignments, deny assignments, locks, deployment stacks et abonnements (pour éviter de se verrouiller soi-même).

2.4 L'assignment en détail#

Mise en œuvre avec Azure CLI (affecter la built-in policy Allowed locations à un resource group) :

az policy definition list --query "[?displayName=='Allowed locations'].name" -o tsv   # ID de la définition intégrée
az policy assignment create --name "emplacements-autorises" \
  --display-name "Emplacements autorisés : France" \
  --policy "<id-definition>" \
  --scope "/subscriptions/<sub>/resourceGroups/rg-app-prd" \
  --params '{ "listOfAllowedLocations": { "value": ["francecentral", "francesouth"] } }'

Et en Terraform (fournisseur azurerm, arguments vérifiés dans la documentation du registre) :

data "azurerm_subscription" "courant" {}

resource "azurerm_policy_definition" "etiquette_obligatoire" {
  name         = "exiger-etiquette-environnement"
  policy_type  = "Custom"
  mode         = "Indexed"
  display_name = "Exiger l'étiquette environnement"
  policy_rule  = <<POLICY
{ "if": { "field": "tags['environnement']", "exists": "false" }, "then": { "effect": "deny" } }
POLICY
}

resource "azurerm_subscription_policy_assignment" "etiquette_obligatoire" {
  name                 = "exiger-etiquette-environnement"
  policy_definition_id = azurerm_policy_definition.etiquette_obligatoire.id
  subscription_id      = data.azurerm_subscription.courant.id
  enforce              = false # DoNotEnforce le temps de mesurer l'impact
  non_compliance_message {
    content = "Ajoutez l'étiquette « environnement » (prd, rec, dev)."
  }
}

2.5 Évaluation et conformité#

Une ressource est évaluée :

1. à sa création ou mise à jour dans une étendue affectée ;
2. quand une étendue reçoit une nouvelle assignment ;
3. quand une stratégie ou initiative déjà affectée est modifiée ;
4. pendant le cycle d'évaluation standard, toutes les 24 heures.

États de conformité : Compliant, Non-compliant, Exempt (avec un sous-état qui dit ce que serait l'état sans l'exemption). Les résultats se consultent dans Policy > Compliance ou à grande échelle avec Azure Resource Graph :

PolicyResources
| where type == 'microsoft.policyinsights/policystates'
| where properties.complianceState == 'NonCompliant'
| extend ressource = tostring(properties.resourceId), affectation = tostring(properties.policyAssignmentName)
| project ressource, affectation

2.6 La correction (remediation)#

Les ressources existantes non conformes à une stratégie deployIfNotExists ou modify se corrigent par une remediation task, qui agit avec la managed identity de l'assignment.

flowchart LR
    A["Définition DINE ou Modify<br/>roleDefinitionIds"] --> B["Assignment<br/>avec managed identity"]
    B --> C{"Créée dans<br/>le portail ?"}
    C -- Oui --> D["Rôles accordés<br/>automatiquement"]
    C -- "Non : CLI, PowerShell, SDK" --> E["Accorder les rôles<br/>à la main"]
    D --> F["Remediation task"]
    E --> F
    F --> G["Ressources corrigées<br/>onglet Deployed resources"]

À retenir :

• une définition personnalisée DINE ou Modify doit lister les rôles nécessaires dans roleDefinitionIds (ID complets, pas les noms) ; les définitions intégrées les ont déjà ;
• les rôles sont accordés automatiquement seulement par le portail ; par SDK, CLI ou PowerShell, ou si la ressource corrigée est hors de l'étendue de l'assignment, il faut les accorder à la main, sinon la correction échoue ;
• accorder un rôle à l'identité de l'assignment demande le User Access Administrator (ou Owner) ; le Contributor peut lancer une correction mais pas créer d'assignment ;
• modifier roleDefinitionIds plus tard ne met pas à jour l'identité : accorder les nouveaux rôles à la main ;
• une remediation task corrige une stratégie DINE ou Modify à la fois (dans une initiative, on choisit laquelle) ;
• paramètres : seuil d'échec (100 % par défaut), nombre de ressources (500 par défaut, 50 000 au plus), déploiements parallèles (10 par défaut, de 1 à 30) ;
• pour une assignment au niveau d'un management group, la tâche se crée après l'évaluation de conformité ;
• une correction peut être lancée même en DoNotEnforce.

az policy remediation create --name correction-diag \
  --policy-assignment "/subscriptions/<sub>/providers/Microsoft.Authorization/policyAssignments/<affectation>"

Start-AzPolicyRemediation -Name 'correction-diag' `
  -PolicyAssignmentId '/subscriptions/<sub>/providers/Microsoft.Authorization/policyAssignments/<affectation>' `
  -ResourceCount 5000 -ParallelDeploymentCount 20

2.7 Exclusions et exemptions#

Les deux catégories d'exemption :

• Mitigated (atténuée) : l'intention de la stratégie est satisfaite par un autre moyen ;
• Waiver (dérogation) : la non-conformité est acceptée temporairement.

Autres points :

• resourceSelectors dans une exemption, y compris userPrincipalId et groupPrincipalId : exemption selon l'identité (un groupe à privilèges élevés peut contourner l'assignment) ;
• assignmentScopeValidation = DoNotValidate (préversion) : créer une exemption hors de l'étendue de l'assignment, pour déplacer un abonnement vers un autre management group sans être bloqué ;
• droits : Microsoft.Authorization/policyExemptions/write sur l'étendue, et l'action exempt/Action sur l'assignment visée (rôles Resource Policy Contributor et Security Admin) ;
• si la ressource parente est supprimée, l'exemption l'est aussi ; revoir régulièrement les exemptions.

2.8 Les droits pour gérer Azure Policy#

3. Defender for Cloud : security standards, Regulatory compliance et recommendations#

Ce chapitre couvre toute la partie Regulatory compliance, normes et recommandations. Les plans de protection, Defender CSPM, le multicloud et l'EASM sont au chapitre 10.

3.1 Le modèle : security policies, standards, controls, recommendations#

• Une security policy Defender for Cloud définit comment les ressources Azure, AWS et GCP sont évaluées. Elle contient des security standards ; dans Azure, ces normes reposent sur des initiatives Azure Policy.
• Chaque norme se compose de compliance controls, des groupes logiques de recommandations.
• Quand une ressource ne satisfait pas un contrôle, Defender for Cloud produit une recommandation : description, étapes de correction, ressources concernées, severity, risk factors, contexte d'attack path.

3.2 Les normes par défaut et les normes disponibles#

Activées par défaut quand on active Defender for Cloud :

Exemples de normes disponibles (liste complète dans la référence) : ISO/IEC 27001:2022, 27002, 27017, PCI DSS v4.0.1, NIST SP 800-53 R5.1.1, NIST CSF v2.0, NIST 800-171 Rev3, CIS Azure Foundations (v2.1.0 et v3.0), CIS Controls v8.1, CIS AKS, GDPR, NIS2, DORA, EU AI Act, SOC 2, HITRUST, HIPAA et FedRAMP (Azure), CSA CCM, SWIFT CSCF, ENS espagnol…

3.3 Ajouter (attribuer) une norme réglementaire#

Prérequis :

• avoir activé un plan Defender for Cloud payant, sauf Defender for Servers Plan 1 et Defender for APIs Plan 1 ;
• avoir le rôle Owner ou Policy Contributor pour ajouter une norme.

Étapes : Defender for Cloud > Regulatory compliance > Manage compliance policies > choisir l'étendue (management group ou abonnement, compte AWS, projet GCP) > Security policies > passer la norme à On (certaines demandent des paramètres).

À savoir :

• choisir l'étendue la plus haute possible pour agréger la conformité ;
• une norme affectée n'apparaît pas dans le tableau de bord s'il n'y a aucune ressource concernée ;
• les contrôles qui ne peuvent pas être évalués automatiquement apparaissent grisés (souvent des contrôles organisationnels, effet manual) ;
• la configuration et l'assignment des normes se font dans l'Azure portal ; le Microsoft Defender portal n'offre qu'une vue de suivi.

3.4 Le Regulatory compliance dashboard#

Il permet de : voir les normes affectées et leur taux de réussite, explorer chaque contrôle (cercle vert = conforme, rouge = non conforme, grisé = non évaluable), télécharger des audit reports, consulter les offres de conformité de Microsoft, créer un workbook Compliance over time, interroger les données.

Les données de conformité remontent aussi dans Microsoft Purview Compliance Manager (vue unique de la conformité de l'organisation).

Piège de rôle : pour voir les données de conformité, le rôle Reader de l'abonnement suffit, mais pas le rôle Security Reader. Pour gérer, il faut au minimum Resource Policy Contributor et Security Admin.

3.5 Les recommandations et leur gestion#

• Severity : Critical, High, Medium, Low. Avec Defender CSPM, la risk prioritization (exposition à Internet, données sensibles, mouvement latéral, chemins d'attaque) ; elle n'affecte pas le Secure Score.
• Gérer les recommandations MCSB : Defender for Cloud > Environment settings > Security policies > MCSB > Manage recommendations ; pour chacune : Audit (active), Disabled (désactive, y compris ses sous-recommandations), Deny.
• Enforce : depuis la page d'une recommandation, déploie une stratégie DeployIfNotExists qui corrige automatiquement les nouvelles ressources ; Deny empêche de créer une ressource non conforme. Disponible sur un sous-ensemble de recommandations Azure ; prise en compte jusqu'à 12 heures.
• Fix : correction rapide sur plusieurs ressources, quand elle existe.
• Custom recommendations : requêtes KQL dans un custom standard (plan Defender CSPM requis ; recommandations basées sur Azure Policy possibles pour tous) ; créer un standard demande Owner, une recommandation Security Admin.

Rôles Defender for Cloud :

3.6 Exempter une ressource ou une recommandation#

À savoir :

• les exemptions reposent sur l'initiative MCSB, qui doit être affectée à l'abonnement ;
• les créer dans le portail Defender for Cloud : il crée automatiquement l'exemption dans toutes les initiatives qui contiennent la recommandation (par l'API Azure Policy, il faut une exemption par initiative) ;
• droits : Owner ou Security Admin (recommandé) à l'étendue, et l'action Microsoft.Authorization/policyAssignments/exempt/action sur toutes les assignments concernées ; au niveau d'un management group, donner le rôle Reader au resource provider Microsoft Azure Security ;
• jusqu'à 24 heures pour prendre effet ; 5 000 ressources exemptées par abonnement ;
• pas d'exemption pour les recommandations personnalisées ; une nouvelle initiative ne reprend pas les exemptions existantes.

3.7 Le Secure Score, en bref#

• Seules les recommandations intégrées MCSB (en disponibilité générale) comptent ; les recommandations en préversion ne comptent pas.
• Chaque security control a un score maximal ; on n'obtient les points d'un contrôle qu'en corrigeant toutes ses recommandations pour toutes les ressources. Calcul de chaque contrôle toutes les 8 heures.
• Deux modèles : le Secure Score classique (Azure portal) et le Cloud Secure Score fondé sur le risque (Microsoft Defender portal). Détails au chapitre 10.

4. Les resource locks#

4.1 Les deux niveaux#

4.2 Les règles#

• Le lock s'impose à tous les utilisateurs et rôles, même à l'Owner : il remplace les autorisations.
• Héritage : un lock sur un abonnement ou un resource group s'applique à toutes ses ressources, même celles créées plus tard ; le plus restrictif l'emporte. Les ressources d'extension (ex. diagnostic setting) héritent du lock de leur ressource.
• Étendues : abonnement, resource group, ressource. Pas de lock sur un management group.
• Un lock Delete sur une ressource bloque toute la suppression de son resource group (pas de suppression partielle).
• Un lock ne bloque pas l'annulation d'un abonnement (les ressources sont désactivées, puis supprimées après un délai).
• Les locks ne s'appliquent qu'au plan de contrôle. Exemple : un lock ReadOnly sur un serveur SQL logique empêche de le modifier, mais on peut toujours créer, modifier et supprimer des données dans les bases.
• Qui gère les locks : les actions Microsoft.Authorization/* ou Microsoft.Authorization/locks/*, donc Owner et User Access Administrator (et des custom roles). Le Contributor ne peut pas créer ni supprimer de lock.
• Applications managées (ex. Azure Databricks) : le resource group d'infrastructure est verrouillé par une application système ; on supprime le service, pas le lock.

4.3 Les effets de bord (très demandés à l'examen)#

Les locks bloquent aussi les requêtes POST vers Azure Resource Manager, ce qui surprend :

4.4 Mise en œuvre#

az lock create --name verrou-rg --lock-type CanNotDelete --resource-group rg-data-prd --notes "Ne pas supprimer"
az lock create --name verrou-st --lock-type ReadOnly --resource-group rg-data-prd \
  --resource-name stdataprd --resource-type Microsoft.Storage/storageAccounts
az lock list --resource-group rg-data-prd

New-AzResourceLock -LockName verrou-rg -LockLevel CanNotDelete -ResourceGroupName rg-data-prd
Get-AzResourceLock -ResourceGroupName rg-data-prd

// Déployé à l'étendue du resource group : pas de propriété scope, le lock porte sur le groupe
resource verrouRg 'Microsoft.Authorization/locks@2016-09-01' = {
  name: 'verrou-rg'
  properties: {
    level: 'CanNotDelete'
    notes: 'Le groupe de ressources de production ne doit pas être supprimé.'
  }
}

resource "azurerm_management_lock" "rg_data_prd" {
  name       = "verrou-rg"
  scope      = azurerm_resource_group.data_prd.id
  lock_level = "CanNotDelete"
  notes      = "Le groupe de ressources de production ne doit pas être supprimé."
}

4.5 Resource lock, denyAction ou deny settings ?#

5. Azure RBAC : built-in roles et role assignments#

5.1 La role assignment : qui, quoi, où#

Une role assignment associe un security principal (utilisateur, groupe, service principal, managed identity), une role definition et un scope (étendue). L'accès est accordé en créant l'attribution et retiré en la supprimant.

Les propriétés d'une role definition :

Format d'une action : {Société}.{Fournisseur}/{typeDeRessource}/{action} avec * (tout), read (GET), write (PUT, PATCH), action (POST, ex. redémarrer), delete (DELETE). Droits effectifs : Actions − NotActions et DataActions − NotDataActions ; plusieurs rôles s'additionnent.

Exemple : le rôle Contributor a Actions: * mais NotActions contient Microsoft.Authorization/*/Write, Microsoft.Authorization/*/Delete et Microsoft.Authorization/elevateAccess/Action : il gère tout sauf les accès.

Séparation des plans : un Owner d'abonnement (Actions: *) ne peut pas lire les blobs par défaut avec son identité Entra : il lui faut un rôle avec des DataActions (ex. Storage Blob Data Reader), ou passer par les clés du compte.

5.2 Les built-in roles à connaître#

Un rôle est dit d'administrateur privilégié s'il contient l'une de ces actions : *, */delete, */write, Microsoft.Authorization/roleAssignments/write ou /delete, Microsoft.Authorization/roleDefinitions/write ou /delete, Microsoft.Authorization/denyAssignments/write ou /delete. Le portail (Access control (IAM), onglet Privileged administrator roles) permet de lister et gérer ces attributions privilégiées à part, et l'onglet Check access montre les role assignments et les deny assignments d'un principal à l'étendue choisie et héritées d'au-dessus (pas celles des étendues enfants) ; les attributions éligibles PIM sont dans l'onglet Eligible assignments.

Attribuer un rôle :

az role assignment create --assignee-object-id <objectId-groupe> --assignee-principal-type Group \
  --role "Virtual Machine Contributor" --scope /subscriptions/<sub>/resourceGroups/rg-app-prd
az role assignment list --scope /subscriptions/<sub>/resourceGroups/rg-app-prd -o table

New-AzRoleAssignment -ObjectId <objectId-groupe> -RoleDefinitionName "Reader" -Scope "/subscriptions/<sub>"

5.3 Les deny assignments#

Une deny assignment bloque des actions même si une role assignment les accorde.

Elles sont créées par Azure, notamment par les deny settings des deployment stacks (voir 9.2). Le principal spécial All Principals (GUID 00000000-0000-0000-0000-000000000000, type SystemDefined) combiné à ExcludePrincipals refuse à tous sauf à quelques-uns. Elles se consultent dans Access control (IAM) > onglet Deny assignments, ou avec Get-AzDenyAssignment. Limite : 2 000 deny assignments gérées par le système par abonnement.

5.4 Conditions ABAC et délégation conditionnelle#

Une condition (Azure ABAC) ajoute un contrôle plus fin à une attribution, selon des attributs. Exemple : ne lire que les blobs dont le blob index tag Project vaut Cascade.

((!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'} AND NOT SubOperationMatches{'Blob.List'}))
 OR (@Resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags:Project<$key_case_sensitive$>] StringEquals 'Cascade'))

La délégation conditionnelle applique des conditions aux role assignments elles-mêmes : au lieu de donner Owner ou User Access Administrator (qui permettent d'attribuer n'importe quel rôle à n'importe qui, y compris à soi-même), on donne Role Based Access Control Administrator avec une condition qui limite les rôles, les types de principaux ou les principaux précis, différemment pour l'ajout et la suppression.

• Le rôle Key Vault Data Access Administrator a déjà une condition intégrée : il ne peut attribuer que les rôles Key Vault (pas Owner ni User Access Administrator).
• Fonction gratuite, incluse dans l'abonnement.
• On ne peut pas déléguer avec conditions la gestion des custom roles via PIM.

5.5 Les limites#

Pour réduire le nombre d'attributions : attribuer à des groupes plutôt qu'à des personnes, supprimer les doublons à plusieurs étendues, remplacer plusieurs built-in roles par un custom role, rendre les attributions éligibles dans PIM, ou utiliser des conditions ABAC et des custom security attributes Entra.

6. Les custom roles : Azure et Microsoft Entra#

6.1 Les custom roles Azure#

Démarche : partir d'un built-in role proche, choisir les actions, créer le rôle (portail, PowerShell, CLI, REST), le tester.

{
  "Name": "Opérateur de machines virtuelles",
  "IsCustom": true,
  "Description": "Démarrer, redémarrer et arrêter les VM, sans les créer ni les supprimer.",
  "Actions": [
    "Microsoft.Compute/virtualMachines/read",
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/restart/action",
    "Microsoft.Compute/virtualMachines/deallocate/action"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": ["/subscriptions/<sub>"]
}

az role definition create --role-definition @operateur-vm.json
az role definition update --role-definition @operateur-vm.json

Règles des custom roles :

• 5 000 par locataire, partagés entre les abonnements qui font confiance au même locataire ;
• AssignableScopes : pas /, pas de joker, un seul management group au plus (non vérifié à l'existence) ;
• un seul joker par chaîne d'action ;
• un rôle avec des DataActions ne peut pas être attribué à l'étendue d'un management group (mais il peut lister un management group dans AssignableScopes et être attribué aux abonnements de ce management group) ;
• éviter de mettre des ressources individuelles dans AssignableScopes : créer le rôle à l'abonnement ou au management group, et l'attribuer à une étendue étroite.

6.2 Les custom roles Microsoft Entra#

Créer un rôle qui ne gère que les propriétés de base et les identifiants des App registrations, puis l'attribuer sur une seule application :

POST https://graph.microsoft.com/v1.0/roleManagement/directory/roleDefinitions
{ "displayName": "Administrateur support des applications", "isEnabled": true,
  "rolePermissions": [ { "allowedResourceActions": [
      "microsoft.directory/applications/basic/update",
      "microsoft.directory/applications/credentials/update" ] } ] }

POST https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments
{ "principalId": "<id-utilisateur>", "roleDefinitionId": "<id-role>", "directoryScopeId": "/<id-objet-application>" }

Une permission de création (ex. microsoft.directory/applications/create) doit être attribuée à l'étendue de l'annuaire : attribuée sur une ressource, elle ne permet pas de créer.

6.3 Comparaison#

7. Détecter et corriger les privilèges excessifs#

flowchart LR
    A["Découvrir<br/>IAM, Resource Graph,<br/>alertes PIM, CIEM"] --> B["Analyser<br/>trop d'Owners ?<br/>identités inactives ?<br/>étendue trop large ?"]
    B --> C["Corriger<br/>rôle plus étroit, étendue réduite,<br/>groupes, éligible PIM"]
    C --> D["Prévenir<br/>délégation conditionnelle,<br/>access reviews, alertes"]
    D --> A

7.1 Les outils de détection#

Statut : Microsoft Entra Permissions Management n'est plus vendu depuis le 1er avril 2025 et a été retiré le 1er octobre 2025. Les capacités CIEM de Defender for Cloud (plan Defender CSPM) ne sont pas touchées : c'est l'outil à citer.

Activer le CIEM pour Azure : Defender for Cloud > Environment settings > abonnement > plan Defender CSPM > Settings > Permissions Management (CIEM) (rôle Security Admin sur l'abonnement).

// Nombre d'attributions par principal (Resource Graph)
authorizationresources
| where type =~ "microsoft.authorization/roleassignments"
| extend principalId = tostring(properties.principalId), etendue = tostring(properties.scope)
| summarize attributions = count() by principalId
| order by attributions desc

7.2 Corriger#

1. Remplacer Owner par un rôle plus étroit (Contributor, ou rôle de service) et retirer les rôles inutilisés.
2. Réduire l'étendue (resource group plutôt qu'abonnement), supprimer les attributions en double à plusieurs niveaux.
3. Attribuer aux groupes, pas aux personnes.
4. Rendre les rôles privilégiés éligibles dans PIM (chapitre 01), avec approbation et MFA.
5. Remplacer les User Access Administrators par des Role Based Access Control Administrators avec conditions.
6. Retirer l'élévation d'accès des Global Administrators (Entra ID > Properties > Manage elevated access users).
7. Programmer des access reviews régulières.

8. Protéger les sauvegardes avec Azure Backup#

8.1 Les deux types de vaults#

Les données sauvegardées en vault sont stockées dans un abonnement et un locataire gérés par Microsoft, isolés de la production ; transit en HTTPS et TLS 1.2 ou plus ; chiffrement au repos par clés de la plateforme par défaut.

8.2 Les rôles de sauvegarde#

8.3 Le soft delete (secure by default)#

• Les données de sauvegarde supprimées sont conservées 14 jours par défaut, durée réglable de 14 à 180 jours ; les 14 premiers jours sont gratuits.
• Secure by default : activé d'office ; pour les Recovery Services vaults elle est en disponibilité générale et ne peut plus être désactivée (aucune version d'API) ; état toujours active possible.
• S'applique aussi aux vaults (un vault supprimé passe en soft delete et peut être récupéré) et aux recovery points supprimés par une réduction de rétention.
• Désactiver le soft delete est une opération critique protégée par MUA.

8.4 L'Immutable vault#

Opérations bloquées : arrêter la protection avec suppression des données, réduire la rétention d'une backup policy, remplacer une backup policy par une autre de rétention plus courte. Deux options : immutability selon la backup policy (par défaut) ou pour une durée fixe (ex. 30 jours sur une rétention de 180). L'immutability ne s'applique pas aux operational backups (blobs, fichiers, disques).

8.5 La Multi-user authorization (MUA) avec Resource Guard#

Principe : les opérations critiques sur un vault demandent aussi une autorisation sur une autre ressource, le Resource Guard, détenue par une autre équipe (sécurité).

sequenceDiagram
    actor B as Administrateur de sauvegarde
    participant V as Vault
    participant G as Resource Guard
    actor S as Administrateur de la sécurité
    B->>V: Réduire la rétention (opération critique)
    V->>G: Le demandeur a-t-il un rôle sur le Resource Guard ?
    G-->>B: Refusé
    B->>S: Demande d'accès (ticket ou PIM)
    S->>B: Backup MUA Operator, juste-à-temps
    B->>V: Nouvelle tentative
    V->>G: Vérification
    G-->>V: Autorisé
    Note over S,B: Le rôle est retiré après l'opération (PIM)

Règles :

• l'administrateur de sauvegarde a besoin du rôle Reader sur le Resource Guard pour activer la MUA sur le vault ;
• il ne doit jamais avoir Contributor, Backup MUA Admin ni Backup MUA Operator de façon permanente sur le Resource Guard : cela annule la protection ;
• donner de préférence Backup MUA Operator (opérations critiques seulement, pas de suppression du Resource Guard) plutôt que Backup MUA Admin ou Contributor (qui permettent de supprimer le Resource Guard) ;
• la MUA protège les opérations sur les sauvegardes en vault, pas les opérations directes sur la source de données.

8.6 Le chiffrement par customer-managed key (CMK)#

Exigences :

• activer la managed identity du vault (system-assigned ou user-assigned) et lui donner accès à la clé : rôle Key Vault Crypto Service Encryption User (Key Vault en Azure RBAC) ou autorisations Get, Wrap, Unwrap (access policies) ;
• le Key Vault doit avoir le soft delete et la purge protection activés ;
• clés RSA ou RSA-HSM de 2 048, 3 072 ou 4 096 bits, activées et non expirées (Key Vault ou Managed HSM) ;
• pour un Recovery Services vault, configurer la CMK avant de protéger le premier élément : un élément sauvegardé avec les clés de la plateforme le reste.

8.7 Les autres protections#

• Private endpoints pour le vault (sauvegarde des SQL et SAP HANA dans des VM, et des serveurs locaux avec l'agent MARS) ; la sauvegarde des VM Azure n'a pas besoin d'accès Internet (réseau principal d'Azure).
• Agent MARS : données chiffrées par une passphrase avant l'envoi ; Security PIN pour les opérations critiques ; données supprimées conservées 14 jours.
• Alertes et Backup reports sur les activités suspectes.

Security levels d'un vault :

9. La sécurité par l'infrastructure en tant que code#

9.1 Les langages#

Tout contrôle de ce chapitre se code : policy assignments (Microsoft.Authorization/policyAssignments), role assignments (Microsoft.Authorization/roleAssignments), resource locks (Microsoft.Authorization/locks), Backup vaults et leurs réglages. Microsoft recommande de gérer Azure Policy en tant que code avec des revues manuelles des modifications.

9.2 Les deployment stacks (piles de déploiement)#

Une deployment stack (Microsoft.Resources/deploymentStacks) gère un ensemble de ressources comme une unité : on lui donne un fichier Bicep ou ARM, elle suit les ressources gérées, et peut empêcher qu'on les modifie ou supprime.

Règles :

• stack créée à l'étendue resource group, abonnement ou management group ; Microsoft conseille de placer la stack à l'étendue parente (ex. au management group pour protéger un abonnement), pour que les équipes applicatives ne puissent pas la modifier ;
• les deny settings ne s'appliquent qu'au plan de contrôle et qu'aux ressources créées explicitement (pas aux ressources implicites, ex. les VM d'un cluster AKS) ;
• rôles : Azure Deployment Stack Contributor (sans gérer les refus) et Azure Deployment Stack Owner (avec les refus).

az stack sub create --name pile-socle --location francecentral \
  --template-file socle.bicep --deployment-resource-group rg-socle-prd \
  --action-on-unmanage detachAll --deny-settings-mode denyDelete \
  --deny-settings-excluded-principals "<objectId-groupe-pipeline>"

Statut : Azure Blueprints (préversion) est retiré le 31 janvier 2027, avec un retrait progressif depuis le 31 juillet 2026. Migrer vers les deployment stacks (recommandé) et les template specs.

9.3 Analyser le code avant de déployer#

Defender for Cloud DevOps security : connecteurs Azure DevOps, GitHub et GitLab ; inventaire et posture des dépôts, résultats d'analyse du code, des secrets, des dépendances et de l'IaC, corrélés avec le contexte cloud. Inclus dans le Foundational CSPM (gratuit) et Defender CSPM.

• Microsoft Security DevOps (extension Azure DevOps ou action GitHub) exécute notamment Template Analyzer (ARM, Bicep), Checkov (Terraform, Bicep, ARM, Kubernetes…), Terrascan, Trivy (images, IaC), Bandit, ESLint, BinSkim.
• Pull request annotations : les erreurs de configuration IaC apparaissent dans la PR (seule catégorie prise en charge aujourd'hui), avec un seuil de gravité.
• Agentless code scanning (préversion) : analyse quotidienne de la branche par défaut sans modifier les pipelines.

9.4 Un pipeline sans secret#

Le pipeline s'authentifie par workload identity federation (OIDC, voir le chapitre 01) : aucun secret à stocker ni à faire tourner, et le pipeline n'est pas concerné par la MFA obligatoire d'Azure.

permissions:
  id-token: write   # nécessaire pour obtenir le jeton OIDC de GitHub
  contents: read
steps:
  - uses: azure/login@v2
    with:
      client-id: ${{ vars.AZURE_CLIENT_ID }}
      tenant-id: ${{ vars.AZURE_TENANT_ID }}
      subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}

L'identité du pipeline reçoit le moindre privilège (Contributor sur le seul resource group visé, ou custom role) ; Azure Policy en Deny reste le dernier filet de sécurité au déploiement.

10. Labs conseillés#

Dans un abonnement de test, avec un resource group dédié (tout supprimer à la fin). Ne jamais verrouiller l'immutability d'un Backup vault de test : c'est irréversible.

Lab 1. Une stratégie Deny, d'abord sans l'appliquer.

1. Affecter la built-in policy Allowed locations (listOfAllowedLocations = francecentral) au resource group, en DoNotEnforce.
2. Créer un storage account en westeurope : il est créé.
3. az policy state trigger-scan --resource-group <rg>, puis Policy > Compliance : la ressource est Non-compliant.
4. Repasser l'assignment en Default et recréer : refus RequestDisallowedByPolicy, avec votre message de non-conformité.

Lab 2. Corriger l'existant (DeployIfNotExists).

1. Créer un Key Vault et un Log Analytics workspace.
2. Affecter dans le portail une built-in policy DINE de diagnostic settings pour Key Vault vers Log Analytics.
3. Observer la managed identity créée avec l'assignment, et son rôle accordé automatiquement.
4. Créer une remediation task : le diagnostic setting apparaît sur le Key Vault existant (onglet Deployed resources).

Lab 3. Les resource locks et leurs effets de bord.

1. Lock CanNotDelete sur le resource group : la suppression échoue, même en Owner.
2. Lock ReadOnly sur un storage account : la page Access keys ne liste plus les clés (POST listKeys bloqué) ; l'accès aux blobs avec un rôle de données Entra continue.
3. Avec un compte Contributor, tenter de retirer le lock : refusé.

Lab 4. Custom role et délégation conditionnelle.

1. Créer le rôle « Opérateur de machines virtuelles » de la section 6.1 et l'attribuer à un utilisateur de test.
2. Avec lui : démarrer et désallouer une VM fonctionne, la supprimer est refusé.
3. Attribuer Role Based Access Control Administrator à un autre utilisateur avec la condition « seulement le rôle AcrPull » : il peut donner AcrPull, pas Contributor.
4. Contrôler le résultat avec Access control (IAM) > Check access.

Lab 5. Une sauvegarde protégée.

1. Recovery Services vault, sauvegarde d'une petite VM.
2. Créer un Resource Guard dans un autre resource group (idéalement un autre abonnement), vous donner Reader dessus, activer la MUA sur le vault.
3. Tenter de réduire la rétention de la backup policy : bloqué tant que vous n'avez pas le rôle Backup MUA Operator sur le Resource Guard.
4. Activer l'Immutable vault (sans verrouiller) et observer les opérations refusées ; consulter le Security level du vault.

11. Les pièges d'examen#

12. Scénarios d'entraînement#

1. Contoso veut que toutes les ressources soient créées en France uniquement, sur tous ses abonnements actuels et futurs. Le resource group rg-netw-global doit pouvoir déployer en Europe de l'Ouest.

Affecter la built-in policy Allowed locations (effet Deny) au management group racine de Contoso (ou à son management group principal) avec francecentral et francesouth, avec rg-netw-global dans les exclusions (notScopes). Affecter ensuite à rg-netw-global une seconde assignment plus permissive. Penser à un management group par défaut pour que les nouveaux abonnements héritent.

2. La sécurité exige que tous les Key Vaults envoient leurs journaux à Log Analytics, y compris les vaults existants.

Stratégie DeployIfNotExists (diagnostic setting) affectée avec une managed identity qui a le rôle nécessaire (accordé automatiquement dans le portail), puis remediation task pour les Key Vaults existants. Audit ou AuditIfNotExists ne corrigent pas.

3. Un administrateur a affecté une stratégie Deny par PowerShell ; elle bloque un script d'autoscaling en production.

Passer l'assignment en DoNotEnforce le temps d'analyser (évaluation sans application, pas d'entrée dans l'Activity log), corriger la définition ou ajouter une exemption, puis repasser en Default. Bonne pratique : commencer en Audit.

4. Le RSSI demande un rapport de conformité ISO 27001:2022 pour tous les abonnements de production.

Activer un plan Defender for Cloud payant (pas seulement Servers P1), puis avec un compte Owner ou Policy Contributor, ajouter la norme ISO/IEC 27001:2022 dans Regulatory compliance > Manage compliance policies au niveau du management group de production. Télécharger l'audit report ; les contrôles grisés sont manuels.

5. Un storage account partagé est utilisé par une application qui lit les blobs avec la clé du compte. Le chef de projet veut « un lock ReadOnly pour le protéger ».

Le ReadOnly casse l'application (listKeys bloqué) et ne protège pas les blobs (plan de données). Mettre un CanNotDelete pour éviter la suppression du compte, et protéger les données par le soft delete des blobs, le blob versioning et l'immutability (chapitre 04).

6. L'équipe AKS doit pouvoir donner le rôle AcrPull aux managed identities de ses clusters, sans pouvoir donner d'autres rôles.

Lui attribuer Role Based Access Control Administrator sur le registre avec une condition qui limite les attributions au rôle AcrPull et au type de principal ServicePrincipal. Ne pas donner User Access Administrator ni Owner.

7. Fabrikam veut un rôle qui permet seulement de démarrer, redémarrer et arrêter les VM d'un abonnement.

Custom role Azure avec Microsoft.Compute/virtualMachines/read, start/action, restart/action, deallocate/action, AssignableScopes = l'abonnement, créé avec az role definition create, attribué à un groupe. Vérifier qu'aucun lock ReadOnly ne bloque les POST.

8. Un audit révèle 40 Owners permanents sur l'abonnement de production et des comptes de service jamais utilisés.

Utiliser les PIM alerts (Too many permanent owners assigned to a resource), le CIEM de Defender CSPM (identités inactives, surprovisionnées), puis : réduire au strict nécessaire, passer les rôles privilégiés en éligibles dans PIM avec approbation, attribuer à des groupes, lancer des access reviews trimestrielles.

9. Après une attaque par rançongiciel, l'attaquant (administrateur de sauvegarde compromis) a tenté de supprimer les sauvegardes. Comment l'empêcher à l'avenir ?

Soft delete (toujours active, 14 à 180 jours), Immutable vault activé et verrouillé, MUA avec un Resource Guard dans un autre locataire détenu par l'équipe sécurité, rôle Backup MUA Operator accordé juste-à-temps via PIM. Niveau de sécurité Excellent.

10. Le socle réseau (hub, pare-feu) est déployé par un pipeline GitHub. Des administrateurs le modifient à la main et créent des écarts.

Déployer le socle avec une deployment stack placée au management group parent, --deny-settings-mode denyWriteAndDelete, le principal du pipeline (fédération OIDC) et un groupe de secours en principaux exclus. Analyser le Bicep dans la PR (Microsoft Security DevOps, Defender for Cloud).

13. Pour aller plus loin (au-delà de l'examen)#

• Complément AZ-500 : tags et stratégies de tags : les tags ne sont pas un mécanisme de regroupement de premier niveau, mais Azure Policy s'en sert (mode indexed) : Add or replace a tag on resources, Inherit a tag from the resource group (effet Modify, corrigeable).
• Complément AZ-500 : Azure Advisor : ses recommandations de sécurité viennent de Defender for Cloud ; un lock ReadOnly sur l'abonnement l'empêche de fonctionner.
• Complément AZ-500 : Azure Resource Graph : inventaire et conformité à l'échelle du locataire (Resources, PolicyResources, AuthorizationResources), base des recommandations personnalisées KQL de Defender CSPM.
• Service groups (groupes de services) : regroupent des ressources partagées entre étendues, sans héritage d'assignments (à ne pas confondre avec les management groups).
• Azure landing zones (Cloud Adoption Framework) : hiérarchie type (Platform, Landing zones Corp et Online, Sandbox), peu d'assignments à la racine, management group par défaut pour les nouveaux abonnements.
• Azure Verified Modules : modules IaC maintenus par Microsoft, alignés sur le Well-Architected Framework.
• Custom security attributes Entra + ABAC : passer à l'échelle (exemple Microsoft : 256 000 attributions évitées).

14. Fiche à retenir#

• Hiérarchie : racine (ID = locataire) › management groups (6 niveaux, 10 000) › abonnements › resource groups › ressources ; tout s'hérite.
• RBAC = qui ; Policy = état de la ressource ; resource lock = pas de suppression ou de modification, même pour l'Owner.
• Policy : definition → initiative → assignment ; seules les ressources des abonnements et resource groups sont évaluées.
• Mode all (défaut recommandé) ou indexed (tags, locations) ; CLI sans mode = indexed.
• Ordre : disabled → append/modify → deny → audit → manual → AINE → denyAction ; puis AINE et DINE après succès.
• Le plus restrictif l'emporte ; on n'assouplit pas un Deny hérité : exclusion ou exemption.
• Évaluation : création ou mise à jour, nouvelle assignment, définition modifiée, toutes les 24 h.
• DINE et Modify : managed identity, roleDefinitionIds, rôles accordés automatiquement seulement dans le portail, remediation task (500 par défaut, 50 000 max).
• DoNotEnforce : évalue sans appliquer, sans Activity log.
• Exemption : Mitigated ou Waiver, expiresOn ; droit exempt/Action sur l'assignment.
• Defender for Cloud : MCSB par défaut ; normes réglementaires = plan payant (hors Servers P1, API P1) + Owner ou Policy Contributor.
• Contrôle grisé = non évaluable ; Reader voit la conformité, pas Security Reader.
• Recommandation : Audit, Disabled, Deny, Enforce (DINE), Fix ; exemption Mitigated = saine, Waiver = exclue.
• Secure Score : MCSB en disponibilité générale (management group) seulement, préversion exclue.
• Resource locks : CanNotDelete, ReadOnly ; abonnement, resource group, ressource, pas management group ; plan de contrôle seulement ; gérés par Owner et User Access Administrator.
• ReadOnly bloque les POST : listKeys, démarrage de VM, scale App Service, runbooks.
• Rôle : Actions − NotActions, DataActions − NotDataActions ; NotActions n'est pas un refus.
• Deny assignments : créées par Azure (deployment stacks), l'emportent sur les rôles.
• Role Based Access Control Administrator + condition = délégation sans donner les clés.
• Limites : 5 000 attributions par abonnement (éligibles PIM exclues), 500 par management group, 5 000 custom roles.
• Custom role Azure : pas de /, pas de joker dans AssignableScopes, 1 management group max, DataActions non attribuables à un management group.
• Custom role Entra : P1, Privileged Role Administrator, applications, consentement, appareils, utilisateurs, groupes ; pas d'Azure CLI.
• Privilèges excessifs : alertes PIM, CIEM Defender CSPM, access reviews ; Permissions Management retiré le 01/10/2025.
• Sauvegarde : Backup Contributor / Backup Operator (pas de suppression ni backup policy) / Backup Reader ; soft delete 14 à 180 j ; Immutable vault verrouillé irréversible.
• MUA : Resource Guard d'une autre équipe (idéalement autre locataire), Backup MUA Operator juste-à-temps ; Excellent = immutability locked ou soft delete always-on + MUA.
• CMK de sauvegarde : managed identity, Key Vault avec soft delete et purge protection, avant la première protection.
• IaC : deployment stacks (denyDelete, denyWriteAndDelete, 5 principaux exclus), Blueprints retiré le 31/01/2027, analyse MSDO dans la PR, pipeline OIDC.

Références#

Toutes lues le 21/10/2026 sur Microsoft Learn :

• Guide d'étude de l'examen SC-500
• Management groups Azure
• Élever l'accès pour gérer tous les abonnements et management groups
• Présentation d'Azure Policy
• Concepts de base de l'effet des définitions Azure Policy
• Effet denyAction
• Structure de définition Azure Policy
• Structure d'assignment Azure Policy (enforcementMode)
• Corriger les ressources non conformes
• Structure d'exemption Azure Policy
• Requêtes Resource Graph pour Azure Policy
• Stratégies de sécurité dans Defender for Cloud
• Regulatory compliance standards dans Defender for Cloud
• Attribuer des Regulatory compliance standards
• Améliorer la Regulatory compliance
• Gérer les recommandations MCSB
• Exempter des ressources des recommandations
• Secure Score dans Defender for Cloud
• Verrouiller vos ressources Azure
• Comprendre les définitions de rôles Azure
• Custom roles Azure
• Deny assignments Azure
• Check access d'un utilisateur à une ressource Azure
• Exemples de requêtes Resource Graph (table authorizationresources)
• Opérations des fournisseurs de ressources : Microsoft.Compute
• FAQ Azure Backup : sources de données par type de vault
• Déléguer la gestion de l'accès Azure (conditions)
• Résoudre les problèmes de limites Azure RBAC
• Exemples de conditions de role assignment pour le stockage Blob
• Vue d'ensemble du contrôle d'accès en fonction du rôle Microsoft Entra
• Créer un custom role dans Microsoft Entra ID
• PIM security alerts pour les Azure roles
• CIEM dans Defender for Cloud et Activer le CIEM
• Retrait de Microsoft Entra Permissions Management (archives des nouveautés Entra, mars 2025)
• Fonctionnalités de sécurité d'Azure Backup
• Soft delete sécurisé par défaut (enhanced soft delete)
• Immutable vault pour Azure Backup
• Multi-user authorization à l'aide de Resource Guard
• Chiffrer les données de sauvegarde avec des customer-managed keys
• Deployment stacks Azure
• Migrer les blueprints vers les deployment stacks
• Sécurité DevOps de Defender for Cloud
• Configurer l'action GitHub Microsoft Security DevOps
• Registre Terraform : azurerm_subscription_policy_assignment et azurerm_management_lock