Microsoft AZ-500: Gestion des identités et des accès — Guide d'étude

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Security Engineer Associate AZ-500 — 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.

Vue d’ensemble

La gestion des identités et des accès (IAM) dans Microsoft Azure est centrée sur Microsoft Entra ID (anciennement Azure AD). Elle régit qui peut accéder à quelles ressources, dans quelles conditions et avec quels privilèges. Une architecture IAM efficace minimise les privilèges permanents, applique un accès conditionnel et basé sur les risques, et adopte une authentification moderne pour les humains comme pour les charges de travail, tout en prenant en charge les scénarios de collaboration hybrides et externes.

Constructions d’identité et portées de Microsoft Entra

• Tenants, utilisateurs et groupes
  • Un tenant représente la frontière d’identité et la structure de confiance de votre organisation. Les utilisateurs peuvent être des comptes membres ou invités (B2B). Utilisez des groupes de sécurité pour l’autorisation et des groupes Microsoft 365 pour les fonctionnalités de collaboration ; préférez les groupes dynamiques pour réduire la gestion manuelle des appartenances.
• Unités administratives (UA)
  • Les UA vous permettent de déléguer des rôles d’annuaire sur un sous-ensemble d’utilisateurs/appareils (par exemple, le support technique régional ne peut gérer que les utilisateurs en Europe). Cela favorise le moindre privilège pour les tâches d’annuaire.
• Rôles d’annuaire et portées d’attribution de rôle
  • Les rôles d’annuaire (par exemple, Global Administrator, User Administrator) s’appliquent aux ressources Microsoft Entra. Limitez la portée des rôles d’annuaire à une UA lorsque c’est possible pour restreindre le rayon d’impact (blast radius). Le rôle Global Administrator est requis pour configurer initialement Privileged Identity Management (PIM).
• Portées du contrôle d’accès basé sur les rôles Azure (Azure RBAC)
  • Azure RBAC régit l’accès aux ressources Azure. Attribuez des rôles au niveau du groupe d’administration, de l’abonnement, du groupe de ressources ou de la ressource. L’héritage s’applique de haut en bas ; choisissez toujours la portée la plus restreinte possible pour réduire les privilèges excessifs.
• Raisonnement opérationnel
  • Séparez les rôles d’annuaire (Entra) d’Azure RBAC (autorisation sur les ressources). Utilisez les UA et des portées RBAC restreintes pour limiter la portée administrative, réduire les opportunités de mouvement latéral et simplifier les révisions d’accès.

Contrôle d’accès avec Azure RBAC et le moindre privilège

• Rôles intégrés et moindre privilège
  • Préférez le rôle intégré le plus spécifique qui correspond à la tâche. Exemple : donnez un accès en lecture seule (pull) aux images de conteneur avec AcrPull et un accès en écriture/envoi (push) avec AcrPush, au lieu du rôle large Contributor. Pour Key Vault, n’accordez le contrôle administratif via RBAC qu’aux administrateurs du coffre, tout en utilisant des stratégies d’accès granulaires pour des opérations spécifiques sur les objets, comme la gestion des certificats.
• Héritage des attributions de rôle
  • Attribuez au niveau de la portée la plus basse possible. Les attributions au niveau du groupe d’administration ou de l’abonnement se propagent par héritage ; évitez les droits larges et hérités, sauf si c’est intentionnel. Lorsque vous avez besoin d’un RBAC cohérent sur plusieurs abonnements, appliquez des attributions de rôle cohérentes via Azure Blueprints (ou des alternatives IaC modernes) plutôt que par une attribution manuelle dans PIM.
• Attributions de refus (Deny)
  • Les attributions de refus bloquent explicitement des actions, indépendamment des attributions d’autorisation (allow), et sont généralement créées par des services Azure tels qu’Azure Policy ou Blueprints. Utilisez-les pour appliquer des garde-fous non négociables (par exemple, empêcher les règles de réseau public sur des ressources sensibles).
• Rôles personnalisés
  • Lorsque les rôles intégrés sont trop larges, définissez des rôles personnalisés avec uniquement les actions requises. Validez par des tests de moindre privilège et des révisions d’accès.

{
  "Name": "Storage Blob Reader (TagsBlocked)",
  "IsCustom": true,
  "Description": "Read blobs; no tag write",
  "Actions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/read",
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
  ],
  "NotActions": [
    "Microsoft.Resources/tags/write"
  ],
  "AssignableScopes": ["/subscriptions/00000000-0000-0000-0000-000000000000"]
}

• Raisonnement opérationnel
  • La limitation de la portée RBAC et les rôles personnalisés réduisent les droits excessifs et la surface d’audit. Les attributions de refus encodent des contraintes de conformité « dures » qui ne peuvent pas être contournées par des autorisations « allow » trop larges accordées par erreur, améliorant ainsi la résilience de la posture de sécurité.

Accès à privilèges, accès conditionnel et protection de l’identité

• Privileged Identity Management (PIM)

  • Éligible vs actif : les attributions éligibles n’accordent pas de permissions permanentes ; les utilisateurs doivent activer le rôle en JIT (Just-In-Time) pour devenir actifs. Imposez une approbation, une justification et une MFA lors de l’activation ; définissez des durées limitées et exigez des références de ticket pour la traçabilité. Commencez par découvrir les rôles à privilèges pour comprendre l’exposition actuelle. Utilisez des révisions d’accès périodiques, idéalement avec les propriétaires de ressources ou de groupes comme réviseurs, pour valider le besoin continu.

• Accès conditionnel (Conditional Access - CA)

  • Les attributions ciblent les utilisateurs/groupes, les identités de charge de travail, les applications cloud et les actions. Les conditions incluent le risque de connexion, la plateforme/l’état de l’appareil, les emplacements, les applications clientes et les filtres pour les appareils et les applications. Les contrôles d’octroi peuvent exiger la MFA, des appareils conformes ou joints à Azure AD en mode hybride, des stratégies de protection des applications ou des conditions d’utilisation. Les contrôles de session limitent la fréquence de connexion, les sessions persistantes et les restrictions appliquées par l’application (par exemple, accès web uniquement pour SharePoint). Utilisez le mode rapport seul (report-only) pour valider en toute sécurité l’impact d’une stratégie avant de l’appliquer. Maintenez des exclusions pour les comptes d’urgence (break-glass) et pour les déploiements progressifs afin d’éviter les blocages d’accès.

• Identity Protection

  • Le risque utilisateur reflète la probabilité qu’un compte soit compromis ; le risque de connexion reflète la probabilité qu’une session spécifique soit risquée. Configurez des stratégies pour exiger une remédiation sécurisée :
    • Utilisateurs avec des informations d’identification divulguées : traitez comme un risque utilisateur Élevé ; forcez la réinitialisation du mot de passe et bloquez l’accès jusqu’à la remédiation.
    • Connexions depuis des adresses IP avec une activité suspecte : traitez au minimum comme un risque de connexion Moyen ; exigez une MFA ou bloquez l’accès pour les applications sensibles.
  • Intégrez avec l’Accès Conditionnel (CA) pour adapter la confiance en temps réel. Suivez l’historique des risques et la remédiation pour mesurer l’efficacité.

• Raisonnement opérationnel

  • PIM élimine les privilèges permanents et impose une activation forte et auditable. L’Accès Conditionnel (CA) et Identity Protection appliquent le principe du Zero Trust — en vérifiant chaque tentative d’accès en fonction de l’utilisateur, de l’appareil, de la session et du risque — réduisant ainsi les vols d’identifiants et les rejeux de jetons (token replay).

Identités hybrides et de charge de travail

• Options d’identité hybride
  • Synchronisation de hachage de mot de passe (PHS) : synchronise les hachages de mot de passe avec Entra ID. Simple et résilient ; n’applique pas les stratégies de connexion sur site au moment de l’authentification.
  • Authentification directe (PTA) : valide les mots de passe auprès des contrôleurs de domaine sur site via des connecteurs légers ; applique les stratégies de mot de passe et les restrictions de compte sur site en temps réel, sans AD FS.
  • Fédération (par ex., AD FS) : déplace l’authentification vers un STS sur site. À n’utiliser que si nécessaire pour des revendications complexes ou des scénarios hérités ; cela introduit plus de serveurs et une surcharge opérationnelle.
  • Authentification unique transparente (Seamless SSO) : connecte les utilisateurs sur des appareils joints au domaine à l’intérieur du réseau d’entreprise avec un minimum d’invites.
  • Choix opérationnel : pour appliquer les stratégies de mot de passe et les restrictions de compte sur site tout en minimisant le nombre de serveurs, déployez PTA et Seamless SSO et activez également PHS pour la résilience/le basculement des scénarios non dépendants de PTA. La fédération seule augmente la complexité et ne répond pas à l’objectif de « minimiser le nombre de serveurs ».
• Authentification d’application à Azure SQL depuis des appareils Windows joints en mode hybride
  • Utilisez l’authentification intégrée Active Directory pour minimiser les invites et tirer parti de Kerberos/SSO le cas échéant.
• Identités managées et principaux de service
  • Les identités managées (affectées par le système ou par l’utilisateur) sont le premier choix pour les charges de travail hébergées sur Azure car elles éliminent les secrets et renouvellent automatiquement les informations d’identification. Attribuez un RBAC avec le moindre privilège à l’identité au niveau de la ressource.
  • Les principaux de service soutiennent les inscriptions d’applications ; utilisez des informations d’identification de certificat plutôt que des secrets client et définissez la durée de vie la plus courte possible.
• Fédération d’identité de charge de travail
  • Utilisez la fédération OIDC pour permettre aux identités de charge de travail externes (par ex., GitHub Actions, Kubernetes) d’obtenir des jetons pour les applications Entra sans stocker de secrets. Définissez précisément les revendications d’émetteur (issuer), de sujet (subject) et d’audience pour limiter qui peut échanger des jetons.

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"gh-actions-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:contoso/api:environment:prod",
    "audiences":["api://AzureADTokenExchange"]
  }'

• Accès de AKS à ACR
  • Accordez à l’identité managée du cluster AKS le rôle AcrPull sur le registre cible en utilisant le flux attach-acr, qui automatise la définition correcte de la portée et évite les attributions erronées.

az aks update -n aks-prod -g rg-aks --attach-acr myRegistry

• Raisonnement opérationnel
  • PTA+PHS+Seamless SSO applique les contrôles sur site en temps réel tout en maintenant la résilience du cloud. Les identités managées et la fédération suppriment les secrets statiques des pipelines et de l’environnement d’exécution, fermant ainsi les voies de vol d’informations d’identification à haute fréquence.

Collaboration externe, méthodes d’authentification et accès aux applications

• Identités externes et collaboration B2B
  • Utilisez des comptes invités B2B avec des paramètres d’accès inter-locataires, des conditions d’utilisation et un accès conditionnel (CA) ciblant les invités. Limitez les personnes autorisées à inviter et préférez un accès juste-à-temps via la gestion des droits d’utilisation.
• Gestion des droits d’utilisation et packages d’accès
  • Regroupez des groupes, des applications et des sites SharePoint dans des packages d’accès avec des stratégies définissant qui peut en faire la demande (y compris les utilisateurs externes), les flux d’approbation, les durées d’affectation et les révisions d’accès. Pour la sélection des réviseurs, utilisez les Propriétaires de groupe (Group Owners) pour maintenir la responsabilité métier auprès des dépositaires des ressources.
• Méthodes d’authentification et sans mot de passe
  • Standardisez l’utilisation de méthodes fortes : clés de sécurité FIDO2, Windows Hello for Business et connexion par téléphone avec Microsoft Authenticator. Utilisez l’enregistrement combiné des informations de sécurité (SSPR + MFA) et appliquez une stratégie d’enregistrement MFA pour tous les utilisateurs. Activez le SSPR avec réécriture locale (on-prem writeback) si nécessaire ; exigez des méthodes sécurisées et limitez-vous aux facteurs gérés par l’entreprise lorsque cela est possible. Désactivez les protocoles d’authentification hérités/de base et bloquez la MFA faible par SMS uniquement lorsque le risque le justifie.
• Microsoft Entra application proxy
  • Publiez des applications web locales (on-premises) sans ouvertures de pare-feu entrantes. Utilisez des groupes de connecteurs pour la haute disponibilité (HA), la pré-authentification avec Entra ID, et superposez l’accès conditionnel (CA), la conformité des appareils et Identity Protection pour une confiance zéro (zero trust) sur les applications héritées.
• Sécurité de l’inscription d’application
  • Exigez des flux de travail de consentement administrateur ; limitez les personnes autorisées à créer des applications ; classifiez les autorisations ; préférez les autorisations d’application uniquement lorsqu’aucun contexte utilisateur n’est requis et limitez la portée des API au minimum. Désactivez l’octroi implicite lorsque c’est possible, exigez l’affectation pour les applications d’entreprise et préférez les certificats aux secrets avec une rotation automatisée.

az ad app update --id <app-id> --required-resource-access @permissions.json
az ad sp update --id <sp-id> --set appRoleAssignmentRequired=true

• Raisonnement opérationnel
  • Les packages d’accès et l’app proxy fournissent un accès externe gouverné et auditable. Les méthodes fortes et sans mot de passe augmentent la résistance au hameçonnage (phishing). Des contrôles stricts sur l’inscription d’applications empêchent les consentements trop larges et réduisent le risque d’usurpation d’application.

Scénario de problème pratique

Adobe Inc. doit accorder à un fournisseur tiers un accès administratif temporaire à un sous-ensemble de ressources Azure et publier une application web héritée interne pour ce fournisseur, en appliquant une authentification forte et le principe de zéro privilège permanent.

1. Définir la portée et modéliser l’accès

• Créez un groupe de ressources rg-vendor-ops et déplacez-y uniquement les ressources requises. Attribuez les rôles Azure RBAC minimaux (par ex., Contributeur sur rg-vendor-ops ; Lecteur sur un groupe de ressources de diagnostics).
• Justification : Une portée restreinte empêche le mouvement latéral. L’héritage des rôles est confiné à rg-vendor-ops, ce qui contient le rayon d’impact (blast radius).

2. Gouverner l’identité et l’activation avec PIM

• Rendez les administrateurs du fournisseur éligibles, et non permanents, pour les rôles requis ; exigez une approbation, un ID de ticket, la MFA à l’activation, et limitez l’activation à 4 heures. Commencez par exécuter la fonction “Découvrir les rôles privilégiés” de PIM pour établir une base de référence des affectations existantes.
• Justification : Les affectations éligibles suppriment le privilège permanent. L’approbation et la MFA appliquent un accès JIT (juste-à-temps) aligné sur les fenêtres de support et fournissent un contrôle auditable.

3. Appliquer l’accès conditionnel et les stratégies de risque

• Créez une stratégie d’accès conditionnel (CA) ciblant le groupe du fournisseur ainsi que le portail Azure et les API ARM, exigeant la MFA, un appareil conforme/joint hybride, et bloquant l’accès depuis des emplacements à risque. Activez d’abord le mode rapport seul (report-only), puis appliquez la stratégie. Configurez Identity Protection : bloquez les utilisateurs à risque élevé (informations d’identification divulguées) jusqu’à la réinitialisation du mot de passe ; exigez la MFA pour les connexions à risque moyen (adresse IP suspecte).
• Justification : L’accès conditionnel lie l’accès à la confiance de l’appareil et au risque en temps réel. Le mode rapport seul évite les interruptions de service pendant le déploiement. Les stratégies de risque corrigent automatiquement les sessions et les comptes compromis.

4. Publier l’application héritée avec Microsoft Entra application proxy

• Déployez deux connecteurs dans des sous-réseaux distincts exposés au fournisseur pour la haute disponibilité (HA). Configurez la pré-authentification avec Entra ID, exigez l’affectation à l’application d’entreprise et appliquez la même stratégie d’accès conditionnel. Utilisez des packages d’accès pour accorder aux utilisateurs du fournisseur un accès limité dans le temps à la fois à l’application d’entreprise et aux rôles du groupe de ressources ; définissez les Propriétaires de groupe (Group Owners) comme réviseurs.
• Justification : L’app proxy élimine l’exposition entrante et centralise l’authentification. La gestion des droits d’utilisation standardise l’intégration/le départ (onboarding/offboarding) et garantit des révisions périodiques par les propriétaires de ressources.

5. Sécuriser les informations d’identification des charges de travail et des applications

• Remplacez tout secret client par des informations d’identification par certificat pour les principaux de service ; pour le CI/CD, utilisez la fédération d’identité de charge de travail au lieu de stocker des secrets. Pour les charges de travail AKS qui nécessitent des images, attachez l’ACR au cluster pour accorder le rôle AcrPull à l’identité managée.
• Justification : La suppression des secrets statiques ferme un vecteur de violation courant ; la fédération et les identités managées fournissent un accès à moindre privilège et à rotation automatique.

6. Protéger les comptes d’urgence (break-glass) et surveiller

• Excluez deux comptes d’urgence de l’accès conditionnel, mais protégez-les avec des mots de passe longs et aléatoires stockés hors ligne. Activez les révisions d’accès trimestrielles et exportez les journaux de PIM et de l’accès conditionnel vers un espace de travail Log Analytics avec des alertes sur les activations anormales.
• Justification : Les comptes d’urgence empêchent le verrouillage du locataire (tenant) tout en étant sûrs sur le plan opérationnel. La surveillance continue détecte rapidement les abus, maintenant ainsi la conformité et la préparation à la réponse aux incidents.

Tous les domaines · Architecture de sécurité réseau →

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

Parcourir Microsoft →