Microsoft Graph : choisir entre certificat et Managed Identity pour l’automatisation

Position recommandée

L’accès app-only utilise l’identité propre de l’application et des application permissions consenties par un administrateur. Il convient aux traitements sans utilisateur, mais son rayon d’action peut couvrir le tenant.

Une Managed Identity supprime le stockage et la rotation d’un secret dans le code. L’identité system-assigned suit le cycle de vie de la ressource; une user-assigned peut être partagée ou déplacée, au prix d’une gouvernance séparée.

Un certificat reste adapté aux runtimes non compatibles avec Managed Identity. Sa clé privée doit être protégée, sa date d’expiration surveillée et sa rotation réalisée avec une période de chevauchement contrôlée.

L’accès app-only utilise l’identité propre de l’application et des application permissions consenties par un administrateur. Il convient aux traitements sans utilisateur, mais son rayon d’action peut couvrir le tenant.

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

Le flux client credentials obtient un token pour le scope https://graph.microsoft.com/.default. Le token contient les rôles applicatifs déjà consentis; demander.default n’ajoute aucune permission par lui-même.

Une system-assigned Managed Identity crée un service principal lié à la ressource Azure. Supprimer la ressource supprime l’identité, ce qui simplifie le cycle de vie mais rend le partage impossible.

Une user-assigned Managed Identity existe indépendamment et peut être attachée à plusieurs ressources. Je l’utilise lorsque plusieurs runtimes doivent partager exactement le même rôle et le même cycle de révocation, jamais seulement par commodité.

Critères de décision et options possibles

Pour Authentification Graph sans secret, je commence par trois résultats concrets: Lister les appels Graph exacts, Choisir Managed Identity si le runtime la supporte et Créer une identité dédiée par environnement. Ils doivent être observables avant de comparer les méthodes disponibles.

L’architecture cible suit Runtime → 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 appels Graph exacts, Choisir Managed Identity si le runtime la supporte et Créer une identité dédiée par environnement. 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 appels Graph exacts, Choisir Managed Identity si le runtime la supporte et Créer une identité dédiée par environnement. Les responsabilités se répartissent ainsi: Runtime: Azure ou autre héberge le workload. Identity: Managed Identity ou application avec certificat. Consent: App roles Graph minimaux sont accordés. Token: Graph vérifie aud, roles, tenant et expiration. 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 Forbidden », « Connect Identity échoue », « Certificat introuvable » et « Mauvais tenant » 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 le token, séparer identité et compte d’approbation, éviter les permissions tenant-wide inutiles et tester la révocation. 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

Le flux client credentials obtient un token pour le scope https://graph.microsoft.com/.default. Le token contient les rôles applicatifs déjà consentis; demander.default n’ajoute aucune permission par lui-même.

Une system-assigned Managed Identity crée un service principal lié à la ressource Azure. Supprimer la ressource supprime l’identité, ce qui simplifie le cycle de vie mais rend le partage impossible.

Une user-assigned Managed Identity existe indépendamment et peut être attachée à plusieurs ressources. Je l’utilise lorsque plusieurs runtimes doivent partager exactement le même rôle et le même cycle de révocation, jamais seulement par commodité.

Prérequis, gouvernance et préparation

La préparation de Authentification Graph sans secret couvre matrice endpoints et permissions, runtime identifié, rôle d’approbation séparé, app registration si certificat, coffre ou magasin de certificats. 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 appels Graph exacts. Choisir Managed Identity si le runtime la supporte. Créer une identité dédiée par environnement. Accorder les app roles minimaux. Il servira de point de comparaison pendant le pilote et lors d’un éventuel retour arrière.

• matrice endpoints et permissions
• runtime identifié
• rôle d’approbation séparé
• app registration si certificat
• coffre ou magasin de certificats
• logs sans token
• rotation et révocation testées

Fonctionnement détaillé de Authentification Graph sans secret

Le flux client credentials obtient un token pour le scope https://graph.microsoft.com/.default. Le token contient les rôles applicatifs déjà consentis; demander.default n’ajoute aucune permission par lui-même.

Une system-assigned Managed Identity crée un service principal lié à la ressource Azure. Supprimer la ressource supprime l’identité, ce qui simplifie le cycle de vie mais rend le partage impossible.

Une user-assigned Managed Identity existe indépendamment et peut être attachée à plusieurs ressources. Je l’utilise lorsque plusieurs runtimes doivent partager exactement le même rôle et le même cycle de révocation, jamais seulement par commodité.

• matrice endpoints et permissions
• runtime identifié
• rôle d’approbation séparé
• app registration si certificat

Traitement, exploitation et cas limites de Authentification Graph sans secret

Les permissions Graph sont accordées directement au service principal de l’identité managée. Cette opération exige des rôles très privilégiés; elle est exécutée par un processus d’approbation distinct du runbook consommateur.

Avec un certificat, l’application prouve la possession de la clé privée. Le certificat public est enregistré dans l’app registration, tandis que la clé privée reste dans un magasin ou coffre protégé et n’entre jamais dans le dépôt.

La rotation de certificat ajoute le nouveau credential, valide un run complet, bascule le runtime puis retire l’ancien. Je conserve une courte période de chevauchement, une alerte d’expiration et un test de révocation.

• Tester une lecture et un refus attendu
• Exercer rotation ou remplacement
• Révoquer l’ancienne identité puis contrôler

Lire les états propres à Authentification Graph sans secret

Connect-MgGraph -Identity utilise la Managed Identity du runtime compatible; le ClientId permet de sélectionner une user-assigned identity. Pour un certificat, tenant ID, client ID et empreinte ou objet certificat doivent être explicités.

Le token n’est jamais écrit en clair. Pour le diagnostic, je contrôle le contexte Graph, le tenant, le mode AuthType et les permissions attendues, puis j’utilise request-id et date pour les erreurs de ressource.

Le choix final documente portabilité, séparation dev/test/prod, permissions, propriétaire, coût d’exploitation, récupération et délai de révocation. Une identité par workload critique réduit le rayon d’impact.

• 403 Forbidden — Token roles et documentation
• Connect Identity échoue — Resource identity et ClientId
• Certificat introuvable — Cert store et expiration
• Mauvais tenant — Get-MgContext

Pilote et suivi opérationnel de Authentification Graph sans secret

Le pilote couvre le périmètre Microsoft Graph, Managed Identity, Certificate authentication, App-only et contrôle Lister les appels Graph exacts. Choisir Managed Identity si le runtime la supporte. Créer une identité dédiée par environnement. Les résultats sont segmentés selon les populations réellement concernées par Authentification Graph sans secret.

Les cas d’échec « 403 Forbidden », « Connect Identity échoue », « Certificat introuvable » 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 le token, séparer identité et compte d’approbation, éviter les permissions tenant-wide inutiles, tester la révocation. 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 Authentification Graph sans secret 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 appels Graph exacts. Choisir Managed Identity si le runtime la supporte. Créer une identité dédiée par environnement. Accorder les app roles minimaux. 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 Runtime, Identity, Consent, Token doivent rester explicites lorsque la configuration est automatisée.

# Collecte de diagnostic
$ErrorActionPreference = 'Stop'
try {
  Connect-MgGraph -Identity -NoWelcome
  $context = Get-MgContext
  $organization = Invoke-MgGraphRequest -Method GET -Uri 'https://graph.microsoft.com/v1.0/organization?%24select=id,displayName'
  [pscustomobject]@{TenantId=$context.TenantId;AuthType=$context.AuthType;AppName=$context.AppName;Organization=$organization.value.displayName}
} catch { Write-Error "Validation Graph impossible : $($_.Exception.Message)"; exit 1 }
finally { Disconnect-MgGraph -ErrorAction SilentlyContinue }

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

La décision repose sur Lister les appels Graph exacts, Choisir Managed Identity si le runtime la supporte, Créer une identité dédiée par environnement et Accorder les app roles minimaux. Ces indicateurs couvrent le résultat technique, l’état du service et l’effet réel sur la population pilote.

• Lister les appels Graph exacts.
• Choisir Managed Identity si le runtime la supporte.
• Créer une identité dédiée par environnement.
• Accorder les app roles minimaux.
• Tester une lecture et un refus attendu
• Exercer rotation ou remplacement
• Révoquer l’ancienne identité puis contrôler

Exploitation, journaux et contrôle continu

La chronologie de Authentification Graph sans secret relie Runtime, 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 appels Graph exacts. Choisir Managed Identity si le runtime la supporte. Créer une identité dédiée par environnement. Accorder les app roles minimaux. Ces contrôles conservent l’état qui explique le symptôme avant une nouvelle évaluation.

Les résultats sont lus avec les causes « App role absent ou RBAC ressource », « Identité non attachée », « Store ou empreinte » en tête, sans déduire une correction d’un code ou d’un statut isolé.

• Lister les appels Graph exacts.
• Choisir Managed Identity si le runtime la supporte.
• Créer une identité dédiée par environnement.
• Accorder les app roles minimaux.
• Tester une lecture et un refus attendu
• Exercer rotation ou remplacement
• Révoquer l’ancienne identité puis contrôler

Exceptions, erreurs connues et traitement

Les exceptions à prévoir pour Authentification Graph sans secret apparaissent notamment sous la forme 403 Forbidden, Connect Identity échoue, Certificat introuvable, Mauvais tenant. 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 à Authentification Graph sans secret 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 Authentification Graph sans secret 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.