0Pricing
Azure Fundamentals · Leçon

Conception de l’identité et des accès d’entreprise

Concevez un modèle RBAC à grande échelle à l’aide de groupes d’administration, de rôles personnalisés et de Privileged Identity Management afin d’imposer un accès juste-à-temps aux opérations sensibles.

Conception de l’identité et des accès d’entreprise est une leçon Azure Fundamentals gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Azure Fundamentals, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Azure Fundamentals comprend 4 leçons au total.

L’identité à l’échelle de l’entreprise

Dans les environnements Azure d’entreprise, la gestion des identités et des accès doit pouvoir s’étendre à des centaines d’abonnements, des milliers d’utilisateurs et des dizaines d’équipes, chacune ayant des besoins d’accès différents aux ressources. Un modèle d’identité bien conçu évite à la fois l’attribution excessive de permissions (utilisateurs disposant de trop d’accès) et l’attribution insuffisante de permissions (utilisateurs incapables d’effectuer leur travail). Le socle est constitué de Microsoft Entra ID, associé à Azure RBAC et à des outils de gouvernance tels que Privileged Identity Management (PIM).

Rappel des fondamentaux de RBAC

Azure Role-Based Access Control (RBAC) accorde les accès au moyen de trois composants :

  • principal de sécurité — qui (utilisateur, groupe, principal de service ou identité managée)
  • définition de rôle — quoi (un ensemble d’Actions autorisées, par exemple « Contributor »)
  • portée — où (groupe de gestion, abonnement, groupe de ressources ou ressource individuelle)

La combinaison de ces trois éléments crée une attribution de rôle. Les rôles sont hérités dans la hiérarchie : un rôle attribué au niveau d’un groupe de gestion s’applique à tous les abonnements qui en dépendent.

# Assign the Reader role at a management group level:
az role assignment create \
  --assignee 'user@company.com' \
  --role 'Reader' \
  --scope '/providers/Microsoft.Management/managementGroups/LandingZones'

Rôles intégrés ou personnalisés

Azure fournit plus de 100 rôles intégrés couvrant les scénarios courants (Owner, Contributor, Reader et rôles propres à certains services). Pour la plupart des cas d’utilisation en entreprise, les rôles intégrés sont suffisants. Toutefois, lorsque vous avez besoin de permissions qui ne correspondent à aucun rôle intégré — par exemple un rôle pouvant lire les VMs sans pouvoir les supprimer — vous pouvez créer un rôle personnalisé avec les permissions précises requises, conformément au principe du moindre privilège.

# Create a custom role:
az role definition create --role-definition '{
  "Name": "VM Operator",
  "Description": "Can start and stop VMs but cannot create or delete them",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/powerOff/action",
    "Microsoft.Compute/virtualMachines/read"
  ],
  "NotActions": [],
  "AssignableScopes": ["/subscriptions/<subscription-id>"]
}'

Attribution des accès fondée sur les groupes

Attribuez les rôles à des groupes Entra ID plutôt qu’à des utilisateurs individuels chaque fois que cela est possible. Lorsque vous attribuez un rôle à un groupe, tous ses membres héritent de ce rôle. Ajouter ou retirer un accès consiste alors à ajouter ou retirer un utilisateur du groupe, plutôt qu’à modifier des attributions de rôles dans plusieurs portées. Cela réduit considérablement la charge administrative et garantit une gestion cohérente des accès entre les membres d’une équipe qui exercent la même fonction.

# Create a group and assign a role to the group:
az ad group create \
  --display-name 'ProductionContributors' \
  --mail-nickname 'prod-contributors'

az role assignment create \
  --assignee '<group-object-id>' \
  --role 'Contributor' \
  --scope '/subscriptions/prod-subscription-id'

Privileged Identity Management (PIM)

Privileged Identity Management (PIM) est un service Entra ID qui fournit un accès privilégié juste-à-temps (JIT) aux ressources Azure et aux rôles Entra ID. Au lieu de disposer en permanence d’un accès Owner ou Global Administrator, les utilisateurs sont éligibles aux rôles privilégiés et doivent demander leur activation lorsqu’ils ont besoin d’un accès élevé. L’activation peut nécessiter une MFA, une justification et l’approbation d’un approbateur désigné.

# Workflow with PIM:
# 1. Security team makes 'alice@company.com' eligible for 'Owner' on prod subscription
# 2. Alice requests activation via PIM portal or myaccess.microsoft.com
# 3. Alice provides justification: 'Emergency patching for CVE-2026-1234'
# 4. Manager approves the request (optional step)
# 5. Alice receives Owner access for 4 hours, then access expires automatically
# 6. All activation events are logged in Entra ID audit logs

Avantages de PIM en entreprise

PIM offre plusieurs avantages en matière de sécurité dans les environnements d’entreprise :

  • surface d’attaque réduite — aucun compte d’administrateur permanent susceptible d’être compromis
  • piste d’audit — chaque activation est journalisée avec son horodatage, sa justification et son approbateur
  • revues des accès — PIM prend en charge des revues périodiques au cours desquelles les responsables confirment quels utilisateurs doivent rester éligibles
  • accès limité dans le temps — même un accès approuvé expire automatiquement, ce qui évite les permissions élevées oubliées

Conception du modèle RBAC

Un modèle RBAC d’entreprise bien conçu comporte généralement les niveaux suivants :

  • niveau du groupe de gestion — accès général en lecture pour les équipes de gouvernance ; attributions de stratégies
  • niveau de l’abonnement — accès Contributor au niveau de l’équipe pour les équipes applicatives qui gèrent un abonnement
  • niveau du groupe de ressources — rôles propres à un service (par exemple Storage Blob Contributor pour une application qui n’a besoin d’accéder qu’aux objets blob)
  • niveau de la ressource — uniquement dans les cas exceptionnels nécessitant un contrôle précis

Identités de service et identités managées

Les applications et les processus automatisés ne doivent pas utiliser de comptes utilisateur pour s’authentifier auprès d’Azure. Utilisez plutôt :

  • Identités de service — inscriptions d’applications dans Entra ID avec un identifiant client et un secret ou un certificat ; utilisées par les pipelines CI/CD et l’automatisation sur site
  • Identités managées — informations d’identification gérées automatiquement pour les ressources hébergées dans Azure (VM, App Service, AKS) ; aucun secret à gérer ou à renouveler

Attribuez aux identités de service et aux identités managées les rôles RBAC strictement nécessaires.

# Assign a role to a managed identity:
az role assignment create \
  --assignee-object-id '<managed-identity-object-id>' \
  --assignee-principal-type ServicePrincipal \
  --role 'Storage Blob Data Contributor' \
  --scope '/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>'

Accès conditionnel aux ressources

Les stratégies d’accès conditionnel d’Entra ID ajoutent de l’intelligence aux décisions d’authentification. Pour la gestion des ressources Azure, vous pouvez exiger que l’accès administrateur (portail Azure, CLI) soit autorisé uniquement depuis :

  • Des appareils conformes (gérés par Intune)
  • Des emplacements nommés (réseau d’entreprise ou VPN)
  • Après MFA (toujours imposé pour les actions privilégiées)

La combinaison de l’accès conditionnel et de PIM crée une posture de sécurité très robuste pour l’accès administratif à Azure.

Révisions des accès

Les révisions des accès d’Entra ID permettent aux administrateurs de vérifier périodiquement que les utilisateurs ont toujours besoin des accès qui leur ont été accordés. Les révisions peuvent être déléguées aux propriétaires des ressources ou aux responsables, qui répondent « Oui, cette personne a toujours besoin de cet accès » ou « Non, supprimez cet accès » pour chaque utilisateur. Les révisions des accès peuvent être planifiées chaque trimestre et automatiser la suppression des accès qui ne sont plus approuvés, afin d’empêcher l’accumulation des accès au fil du temps.

Comptes d’accès d’urgence

Chaque entreprise devrait conserver au moins deux comptes d’accès d’urgence (comptes de secours) — des comptes Administrateur général qui ne sont pas protégés par les exigences d’accès conditionnel ou de MFA (ils utilisent à la place des clés matérielles FIDO2). Ces comptes sont utilisés uniquement lorsque les systèmes Entra ID ou MFA sont indisponibles et que les comptes administrateur habituels ne sont pas accessibles. Toute utilisation d’un compte d’accès d’urgence doit déclencher immédiatement des alertes de sécurité et faire l’objet d’un audit rigoureux.

Vérification rapide

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

Récapitulatif de la leçon

Dans cette leçon, vous avez appris que le RBAC d’entreprise utilise des attributions fondées sur des groupes au niveau du groupe d’administration, de l’abonnement et de l’étendue du groupe de ressources ; que la gestion des identités privilégiées fournit un accès juste-à-temps afin d’éliminer les rôles d’administrateur permanents ; et que les identités managées et les identités de service doivent être utilisées pour l’authentification des applications plutôt que les comptes utilisateur. Félicitations : vous avez terminé la section consacrée à l’architecture et à la gouvernance d’entreprise du parcours AZ-900 !

Questions Fréquemment Posées

La leçon « Conception de l’identité et des accès d’entreprise » est-elle gratuite ?

Oui — le texte complet de « Conception de l’identité et des accès d’entreprise » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Azure Fundamentals, passe à CoddyKit PRO. Le cours Azure Fundamentals comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Conception de l’identité et des accès d’entreprise » ?

Concevez un modèle RBAC à grande échelle à l’aide de groupes d’administration, de rôles personnalisés et de Privileged Identity Management afin d’imposer un accès juste-à-temps aux opérations sensibl… Tu pratiques Azure Fundamentals avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Azure Fundamentals ?

Aucune expérience préalable n'est requise. Azure Fundamentals sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.

Combien de temps prend la leçon « Conception de l’identité et des accès d’entreprise » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Azure Fundamentals ?

Oui. Chaque leçon Azure Fundamentals inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Présentation du Cloud Adoption Framework
  2. Zones d’atterrissage Azure
  3. Topologie réseau en étoile
  4. Conception de l’identité et des accès d’entreprise
← Retour à Azure Fundamentals