Microsoft Graph : gouverner les permissions, consentements et identités applicatives

Position recommandée

Les permissions delegated agissent au nom d’un utilisateur et restent bornées par ses droits; les application permissions permettent un accès sans utilisateur et portent souvent un impact tenant-wide. Le choix dépend du scénario, pas de la facilité du code.

Je pars de l’endpoint et de l’opération exacts, puis je sélectionne la permission la moins privilégiée dans la documentation. Directory.Read.All ou DeviceManagementConfiguration.ReadWrite.All ne sont pas des permissions génériques à accorder par défaut.

Chaque identité applicative possède un propriétaire, une finalité, un environnement, des permissions, une méthode d’authentification, une date de revue et un runbook de révocation. Les consentements sont audités dans les oauth2PermissionGrants et appRoleAssignments.

Les permissions delegated agissent au nom d’un utilisateur et restent bornées par ses droits; les application permissions permettent un accès sans utilisateur et portent souvent un impact tenant-wide. Le choix dépend du scénario, pas de la facilité du code.

Besoin, cas d’usage et périmètre de la recommandation

En delegated, l’application reçoit des scopes et agit dans le contexte d’un utilisateur connecté. La permission Graph et les droits effectifs de l’utilisateur peuvent tous deux limiter l’opération.

En application, le service principal reçoit des app roles et fonctionne sans utilisateur. Le consentement administrateur est requis et l’exposition peut couvrir toutes les ressources associées à la permission.

Je ne mélange pas delegated et application dans la même identité sauf justification forte. Séparer une collecte read-only, une remédiation et une interface interactive réduit le rayon d’impact et simplifie la révocation.

Critères de décision et options possibles

Pour Gouvernance des permissions Microsoft Graph, je commence par trois résultats concrets: Lister les opérations Graph exactes, Choisir delegated ou application et Accorder la permission minimale. Ils doivent être observables avant de comparer les méthodes disponibles.

L’architecture cible suit Workload → Identity → Consent → Token. Chaque composant a un propriétaire clair, un état vérifiable et une méthode de retour arrière; cette répartition évite qu’une seconde politique masque le résultat de la première.

Le pilote contrôle notamment Lister les opérations Graph exactes, Choisir delegated ou application et Accorder la permission minimale. La généralisation ne commence qu’après une période stable et après vérification des exceptions propres aux populations visées.

La recommandation devient mesurable lorsqu’elle relie le besoin à une cible vérifiable. Les résultats attendus sont Lister les opérations Graph exactes, Choisir delegated ou application et Accorder la permission minimale. Les responsabilités se répartissent ainsi: Workload: Définit opérations et données nécessaires. Identity: Utilisateur, application ou managed identity. Consent: Scopes ou app roles autorisés. Token: Porte les claims vérifiés par Graph. Cette répartition permet d’attribuer chaque écart au bon propriétaire et d’éviter qu’un second profil, une ancienne autorité ou une exception silencieuse ne produise un résultat apparemment correct mais impossible à exploiter dans la durée.

Les écarts « 403 malgré scope », « Permission ajoutée mais inactive », « Automation trop puissante » et « Secret expiré » servent de tests de décision. Pour chacun, la preuve indiquée dans la matrice doit permettre de choisir entre correction, exception temporaire et retour arrière. Le pilote surveille également les points suivants: ne jamais journaliser de token, éviter Directory.ReadWrite.All par confort, séparer lecture et écriture et tester avec identité dédiée. La valeur cible, le mode de distribution, les contrôles et la sortie de secours sont ainsi évalués ensemble.

Architecture cible et répartition des responsabilités

En delegated, l’application reçoit des scopes et agit dans le contexte d’un utilisateur connecté. La permission Graph et les droits effectifs de l’utilisateur peuvent tous deux limiter l’opération.

En application, le service principal reçoit des app roles et fonctionne sans utilisateur. Le consentement administrateur est requis et l’exposition peut couvrir toutes les ressources associées à la permission.

Je ne mélange pas delegated et application dans la même identité sauf justification forte. Séparer une collecte read-only, une remédiation et une interface interactive réduit le rayon d’impact et simplifie la révocation.

Prérequis, gouvernance et préparation

La préparation de Gouvernance des permissions Microsoft Graph couvre matrice opérations/endpoints, inventaire app registrations/service principals, rôles d’approbation séparés, vault ou managed identity, journalisation des sign-ins. Le propriétaire de chaque composant et la population pilote sont définis avant la création de la configuration.

L’état initial est mesuré avec Lister les opérations Graph exactes. Choisir delegated ou application. Accorder la permission minimale. Tester sans rôle parasite. Il servira de point de comparaison pendant le pilote et lors d’un éventuel retour arrière.

• matrice opérations/endpoints
• inventaire app registrations/service principals
• rôles d’approbation séparés
• vault ou managed identity
• journalisation des sign-ins
• procédure de rotation
• runbook de révocation

Fonctionnement détaillé de Gouvernance des permissions Microsoft Graph

En delegated, l’application reçoit des scopes et agit dans le contexte d’un utilisateur connecté. La permission Graph et les droits effectifs de l’utilisateur peuvent tous deux limiter l’opération.

En application, le service principal reçoit des app roles et fonctionne sans utilisateur. Le consentement administrateur est requis et l’exposition peut couvrir toutes les ressources associées à la permission.

Je ne mélange pas delegated et application dans la même identité sauf justification forte. Séparer une collecte read-only, une remédiation et une interface interactive réduit le rayon d’impact et simplifie la révocation.

• matrice opérations/endpoints
• inventaire app registrations/service principals
• rôles d’approbation séparés
• vault ou managed identity

Traitement, exploitation et cas limites de Gouvernance des permissions Microsoft Graph

La documentation de chaque méthode Graph indique les permissions minimales selon delegated/application. Je vérifie aussi les rôles Entra ou Intune additionnels, car certaines API exigent une autorisation RBAC en plus du token.

Une managed identity supprime la gestion d’un secret applicatif lorsqu’un runtime Azure compatible est utilisé. Sinon, un certificat avec clé privée protégée est généralement préférable à un client secret longue durée.

Les credentials ont une expiration, un propriétaire et une rotation testée avant l’échéance. Aucun secret, certificat privé, token ou deltaLink n’est écrit dans le dépôt, la ligne de commande ou les logs.

• Inspecter token et résultat
• Auditer grants et credentials
• Programmer revue et expiration

Lire les états propres à Gouvernance des permissions Microsoft Graph

Le consentement produit des objets distincts: oauth2PermissionGrant pour les scopes delegated et appRoleAssignment pour les application permissions. Je les inventorie avec l’app registration et le service principal.

Les changements de permissions exigent souvent un nouveau consentement. Ajouter une permission dans le manifeste sans reconsent ne garantit pas qu’elle figure dans le token; je contrôle les claims et l’objet de grant.

La revue périodique supprime permissions inutilisées, credentials expirés, applications sans propriétaire et grants historiques. Le rollback révoque le grant ou désactive le service principal avant de supprimer définitivement l’identité.

• 403 malgré scope — Token claims et documentation
• Permission ajoutée mais inactive — Grant et token
• Automation trop puissante — App roles
• Secret expiré — Credential endDate

Pilote et suivi opérationnel de Gouvernance des permissions Microsoft Graph

Le pilote couvre le périmètre Microsoft Graph, Permissions, Consent, Service principal et contrôle Lister les opérations Graph exactes. Choisir delegated ou application. Accorder la permission minimale. Les résultats sont segmentés selon les populations réellement concernées par Gouvernance des permissions Microsoft Graph.

Les cas d’échec « 403 malgré scope », « Permission ajoutée mais inactive », « Automation trop puissante » sont reproduits lorsque c’est possible. Ils vérifient que l’écart reste visible et que la procédure indique une preuve exploitable.

Le suivi après déploiement conserve ne jamais journaliser de token, éviter Directory.ReadWrite.All par confort, séparer lecture et écriture, tester avec identité dédiée. Une évolution de version, de licence ou de dépendance déclenche une nouvelle lecture de ces points.

Configuration recommandée et déploiement par étapes

La méthode retenue pour Gouvernance des permissions Microsoft Graph se déploie par les étapes « Mesurer l’état de départ », « Configurer la population pilote », « Observer les indicateurs », « Décider la généralisation ». Chaque passage produit un résultat vérifiable avant l’ouverture du suivant.

Paramètres, commandes et automatisation

Les commandes et valeurs de cette section servent à vérifier Lister les opérations Graph exactes. Choisir delegated ou application. Accorder la permission minimale. Tester sans rôle parasite. Chaque exemple précise l’état attendu et les éléments à comparer dans le service.

Le contexte d’exécution, les permissions et les effets sur Workload, Identity, Consent, Token doivent rester explicites lorsque la configuration est automatisée.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
  $servicePrincipalId = '<ServicePrincipalObjectId>'
  $appRoles = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/servicePrincipals/$servicePrincipalId/appRoleAssignments"
  $delegated = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/oauth2PermissionGrants?%24filter=clientId eq '$servicePrincipalId'"
  [pscustomobject]@{ApplicationRoles=$appRoles.value;DelegatedGrants=$delegated.value}
} catch { Write-Error "Inventaire des consentements impossible : $($_.Exception.Message)"; exit 1 }

Validation, indicateurs et critères GO / NO-GO

La décision repose sur Lister les opérations Graph exactes, Choisir delegated ou application, Accorder la permission minimale et Tester sans rôle parasite. Ces indicateurs couvrent le résultat technique, l’état du service et l’effet réel sur la population pilote.

• Lister les opérations Graph exactes.
• Choisir delegated ou application.
• Accorder la permission minimale.
• Tester sans rôle parasite.
• Inspecter token et résultat
• Auditer grants et credentials
• Programmer revue et expiration

Exploitation, journaux et contrôle continu

La chronologie de Gouvernance des permissions Microsoft Graph relie Workload, Identity, Consent, Token. Les heures et identifiants communs permettent de savoir si les états appartiennent à la même tentative.

La collecte commence par Lister les opérations Graph exactes. Choisir delegated ou application. Accorder la permission minimale. Tester sans rôle parasite. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « Rôle/RBAC ou consent absent », « Reconsent non effectué », « Permission tenant-wide » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Lister les opérations Graph exactes.
• Choisir delegated ou application.
• Accorder la permission minimale.
• Tester sans rôle parasite.
• Inspecter token et résultat
• Auditer grants et credentials
• Programmer revue et expiration

Exceptions, erreurs connues et traitement

Les exceptions à prévoir pour Gouvernance des permissions Microsoft Graph apparaissent notamment sous la forme 403 malgré scope, Permission ajoutée mais inactive, Automation trop puissante, Secret expiré. La preuve associée indique s’il faut corriger la configuration ou conserver une exception documentée.

Coût de maintien des exceptions

Une exception à Gouvernance des permissions Microsoft Graph crée une charge récurrente: elle doit être identifiée, surveillée et réévaluée jusqu’à sa suppression. Sans propriétaire ni date de revue, cette charge finit par devenir une configuration parallèle difficile à tester.

Rollback, gestion du changement et points de vigilance

Le rollback de Gouvernance des permissions Microsoft Graph restaure explicitement l’affectation, la valeur ou l’autorité précédente. Les actions et points de vigilance ci-dessous précisent ce qui doit être contrôlé après ce retour.