Applications OAuth Microsoft 365 : auditer les consentements et permissions Graph

Pourquoi les applications OAuth méritent leur propre audit

Une application connectée à Microsoft 365 peut lire des profils, des fichiers, des sites SharePoint, des boîtes aux lettres ou l'annuaire. Avec des permissions déléguées, elle agit dans le contexte d'un utilisateur connecté. Avec des permissions d'application, elle peut fonctionner sans utilisateur et continuer tant que son identité et son consentement restent valides.

Le risque ne se limite donc pas aux applications inconnues. Une intégration légitime peut devenir excessive après un changement de fournisseur, un ajout de permission, le départ de son propriétaire ou la fuite d'un secret. Un consentement administrateur valide confirme qu'un administrateur a autorisé l'accès; il ne garantit ni que l'application demeure nécessaire ni que son identité est encore bien protégée.

Ce guide fournit une méthode de triage et des collectes en lecture seule. Il ne remplace pas une analyse complète des dépendances, du code, des journaux et des données réellement consultées par chaque application.

• Microsoft — Vue d'ensemble des permissions et du consentement ↗
• Microsoft — Applications et principaux de service ↗

Comprendre les objets avant de tirer des conclusions

Le même appId peut correspondre à une inscription dans le locataire d'origine et à un principal de service dans chacun des locataires clients. Supprimer seulement l'inscription ou seulement l'application d'entreprise n'a donc pas le même effet. Pour une application SaaS multilocataire, vous gérez généralement son principal de service local et les consentements accordés dans votre organisation.

Les permissions déléguées sont aussi limitées par les droits de l'utilisateur présent, alors qu'une permission d'application est portée directement par la charge de travail. Cette différence doit peser lourd dans la priorité, sans conclure qu'une permission déléguée est automatiquement bénigne.

• Microsoft — Permissions Microsoft Graph ↗

Définir le périmètre et le propriétaire d'affaires

Établissez aussi une date de décision. Une application sans propriétaire ou justification ne doit pas rester indéfiniment dans une file d'attente, mais son absence d'activité visible n'est pas une preuve suffisante pour la supprimer. Certaines intégrations ne fonctionnent qu'à la fin du mois, pendant un sinistre ou lors d'un renouvellement annuel.

• Quels services sont couverts : Exchange Online, SharePoint, Teams, OneDrive, Entra ID, Power BI ou API personnalisées?
• L'application est-elle interne, publiée par Microsoft, fournie par un éditeur ou ajoutée directement par un utilisateur?
• Qui accepte le risque et confirme le besoin d'affaires? Un propriétaire technique dans Entra ne remplace pas ce responsable.
• Quelle est la criticité, quelles données sont accessibles et quelles opérations seraient interrompues par un retrait?
• L'application est-elle monolocataire ou multilocataire, interactive ou sans utilisateur, et utilisée en production, test ou reprise?
• Quelles licences donnent accès aux journaux, à Defender for Cloud Apps, à App governance ou à la protection des identités de charge?

Inventaire PowerShell en lecture seule

Le SDK Microsoft Graph PowerShell permet d'exporter les principaux de service et les inscriptions locales. Utilisez un poste d'administration, un compte dédié et uniquement des étendues de lecture. Application.Read.All est la permission minimale documentée pour plusieurs commandes d'inventaire; les consentements délégués et les journaux peuvent demander des étendues additionnelles. Vérifiez toujours la page Permissions de chaque commande et faites approuver la session privilégiée.

L'exemple sépare les deux inventaires au lieu de supposer qu'un principal de service possède toujours une inscription locale. Il ne modifie rien et n'exporte aucune valeur secrète.

Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes @(
  'Application.Read.All',
  'Directory.Read.All',
  'DelegatedPermissionGrant.Read.All'
) -NoWelcome

$servicePrincipals = Get-MgServicePrincipal -All -Property @(
  'id','appId','displayName','servicePrincipalType','accountEnabled',
  'appOwnerOrganizationId','verifiedPublisher','createdDateTime','tags'
)

$applications = Get-MgApplication -All -Property @(
  'id','appId','displayName','signInAudience','createdDateTime',
  'passwordCredentials','keyCredentials'
)

$servicePrincipals | Select-Object DisplayName,AppId,Id,
  ServicePrincipalType,AccountEnabled,AppOwnerOrganizationId,CreatedDateTime |
  Export-Csv .\EnterpriseApps.csv -NoTypeInformation -Encoding UTF8

$applications | Select-Object DisplayName,AppId,Id,SignInAudience,
  CreatedDateTime,@{N='SecretCount';E={$_.PasswordCredentials.Count}},
  @{N='CertificateCount';E={$_.KeyCredentials.Count}} |
  Export-Csv .\AppRegistrations.csv -NoTypeInformation -Encoding UTF8

• Microsoft — Get-MgServicePrincipal ↗
• Microsoft — Get-MgApplication ↗

Relier propriétaires, consentements délégués et permissions d'application

Trois collections différentes sont nécessaires. Les propriétaires expliquent qui devrait répondre de l'application. Les oAuth2PermissionGrants représentent les permissions déléguées. Les appRoleAssignments accordées au principal de service représentent les permissions d'application. Les identifiants doivent ensuite être résolus contre le principal de service de l'API cible pour obtenir un nom lisible.

Dans un consentement délégué, ConsentType vaut généralement Principal pour un utilisateur ou AllPrincipals pour le locataire. Scope contient une liste de portées. Dans une affectation de rôle applicatif, AppRoleId doit être associé à la collection AppRoles de la ressource; conserver uniquement le GUID rend le rapport presque inutilisable.

$results = foreach ($sp in $servicePrincipals) {
  $owners = @(Get-MgServicePrincipalOwner -ServicePrincipalId $sp.Id -All)
  $delegated = @(Get-MgServicePrincipalOauth2PermissionGrant `
    -ServicePrincipalId $sp.Id -All)
  $appRoles = @(Get-MgServicePrincipalAppRoleAssignment `
    -ServicePrincipalId $sp.Id -All)

  [pscustomobject]@{
    DisplayName = $sp.DisplayName
    AppId = $sp.AppId
    ObjectId = $sp.Id
    Enabled = $sp.AccountEnabled
    Owners = ($owners | ForEach-Object {
      $_.AdditionalProperties['displayName']
    }) -join '; '
    DelegatedScopes = ($delegated.Scope | Sort-Object -Unique) -join '; '
    TenantWideDelegated = ($delegated.ConsentType -contains 'AllPrincipals')
    ApplicationRoleIds = ($appRoles.AppRoleId | Sort-Object -Unique) -join '; '
  }
}

$results | Export-Csv .\OAuthPermissions.csv `
  -NoTypeInformation -Encoding UTF8

• Microsoft — Lister les consentements délégués ↗
• Microsoft — Get-MgServicePrincipalAppRoleAssignment ↗
• Microsoft — Référence des permissions Graph ↗

Interpréter le risque sans liste noire simpliste

Ces signaux servent à prioriser, pas à déclarer une application malveillante. Une sauvegarde Microsoft 365 peut légitimement nécessiter un accès large; elle exige alors un propriétaire, une architecture de justificatifs robuste, des journaux, un contrat et une revue périodique proportionnels à cette portée.

La vérification de l'éditeur améliore le signal de provenance, mais elle ne certifie pas le code ni l'usage futur. À l'inverse, une application interne non vérifiée n'est pas automatiquement dangereuse. Le contexte et les preuves restent déterminants.

Auditer les secrets, certificats et identités sans les exposer

Inspectez le type, la date d'expiration, le propriétaire, l'emplacement d'exécution et la procédure de rotation de chaque justificatif. N'exportez jamais la valeur d'un secret dans un rapport. Microsoft n'affiche d'ailleurs la valeur d'un secret client qu'au moment de sa création.

Pour une charge Azure, privilégiez une identité managée. Pour une plateforme externe compatible, la fédération d'identité de charge évite un secret partagé. Si ces options ne conviennent pas, Microsoft recommande un certificat avant un secret client. Un certificat reste toutefois un secret opérationnel : sa clé privée, son stockage, sa rotation et sa surveillance doivent être gérés.

$credentialReport = foreach ($app in $applications) {
  foreach ($secret in $app.PasswordCredentials) {
    [pscustomobject]@{
      App=$app.DisplayName; AppId=$app.AppId; Type='ClientSecret'
      CredentialId=$secret.KeyId; Start=$secret.StartDateTime
      End=$secret.EndDateTime
    }
  }
  foreach ($cert in $app.KeyCredentials) {
    [pscustomobject]@{
      App=$app.DisplayName; AppId=$app.AppId; Type='Certificate'
      CredentialId=$cert.KeyId; Start=$cert.StartDateTime
      End=$cert.EndDateTime
    }
  }
}
$credentialReport | Sort-Object End |
  Export-Csv .\OAuthCredentialExpiry.csv -NoTypeInformation -Encoding UTF8

• Microsoft — Bonnes pratiques de sécurité pour les inscriptions ↗
• Microsoft — Fédération d'identité de charge ↗

Utiliser les journaux sans confondre absence de preuve et preuve d'absence

Les journaux de connexion des principaux de service montrent les authentifications sans utilisateur, notamment par certificat ou secret. Ils sont regroupés lorsque le principal, l'état, l'adresse IP et la ressource correspondent; il faut développer la ligne pour voir les horodatages individuels. Les connexions d'identités managées ont leur propre catégorie.

Les journaux d'audit permettent de rechercher la création d'un principal de service, l'ajout d'un consentement ou d'un rôle applicatif et la modification d'un justificatif. La disponibilité, la rétention et l'accès aux journaux dépendent des licences et de la configuration d'export. Pour les applications critiques, routez les catégories nécessaires vers un espace Log Analytics ou un SIEM selon votre politique de conservation.

Une application ne doit jamais être classée inutilisée à partir de sa date de création, de sa dernière modification ou d'une fenêtre de journaux trop courte. Croisez connexions, audit, propriétaire, facturation, documentation, flux réseau et calendrier d'affaires.

• Microsoft — Journaux de connexion des principaux de service ↗
• Microsoft — Accéder aux journaux d'activité Entra ↗
• Microsoft — Examiner la création d'un principal de service ↗

Classer les applications et produire un plan d'action

Le rapport devrait contenir au minimum le nom, appId, objectId, locataire éditeur, audience, état, propriétaires techniques et d'affaires, permissions résolues, type de consentement, justificatifs et échéances, dernière activité démontrable, criticité, décision, approbateur et date de prochaine revue.

Gardez la preuve brute séparée du résumé de direction. Les identifiants, permissions et événements sont nécessaires à l'enquête, mais ils peuvent eux-mêmes révéler l'architecture et doivent être protégés.

Retirer un accès de façon contrôlée

Ne commencez pas par supprimer l'inscription. Confirmez l'objet concerné, son propriétaire, les dépendances, les permissions et le scénario de retour arrière. Pour contenir une application compromise, désactiver son principal de service peut être plus rapide et réversible; pour corriger une portée excessive, retirez le consentement ou l'affectation précise. Une rotation de justificatif n'annule pas automatiquement tous les jetons et consentements existants.

Après le changement, testez à la fois ce qui doit fonctionner et ce qui doit être refusé, puis surveillez les erreurs et connexions. Supprimez le principal de service ou l'inscription seulement lorsque la période d'observation et le propriétaire confirment le retrait. Une application multilocataire peut continuer d'exister chez son éditeur même si son instance locale est supprimée.

• Préserver les journaux et les détails du consentement avant toute action en cas de suspicion.
• Désactiver temporairement le principal de service si une interruption contrôlée est acceptable.
• Retirer seulement le grant délégué ou l'app role assignment non requis.
• Révoquer ou remplacer le justificatif compromis et mettre à jour la charge de travail.
• Valider les scénarios métiers, les refus attendus et les alertes après changement.
• Documenter la décision, l'approbateur, le retour arrière et la suppression finale.

• Microsoft — Examiner les permissions des applications d'entreprise ↗
• Microsoft — Accorder ou révoquer les permissions par Graph ↗

Réduire le prochain risque de consentement

Le flux de consentement administrateur donne aux utilisateurs une voie contrôlée pour demander une application au lieu de contourner le processus. Il ne remplace pas l'analyse : le réviseur doit comprendre la permission, la donnée, le mode délégué ou applicatif, le fournisseur, le propriétaire et le mécanisme de justificatif avant d'accepter.

Defender for Cloud Apps et App governance peuvent enrichir l'analyse des applications OAuth et de leur comportement lorsque les licences correspondantes sont disponibles. Ces signaux accélèrent le triage, mais la décision doit toujours tenir compte du contexte métier et des dépendances.

• Limiter le consentement utilisateur aux permissions à faible impact et aux applications qui répondent à votre politique.
• Activer un flux de demande de consentement administrateur avec réviseurs, contexte et échéance définis.
• Exiger un propriétaire technique et un propriétaire d'affaires avant l'approbation.
• Préférer les permissions Selected ou spécifiques à une portée globale lorsqu'elles répondent au besoin.
• Surveiller les ajouts de justificatifs, consentements et rôles applicatifs ainsi que les connexions anormales.
• Réviser périodiquement les applications, y compris celles publiées par un fournisseur reconnu.

• Microsoft — Configurer le consentement utilisateur ↗
• Microsoft — Configurer le flux de consentement administrateur ↗
• Microsoft — Examiner les applications OAuth risquées ↗

Checklist réutilisable

• Exporter inscriptions, principaux de service, état et locataire propriétaire.
• Résoudre les propriétaires techniques et confirmer le responsable d'affaires.
• Résoudre toutes les permissions déléguées et d'application en noms lisibles.
• Identifier le type de consentement, les affectations et les utilisateurs concernés.
• Inventorier secrets, certificats, fédérations, dates et procédure de rotation sans exporter de secret.
• Croiser connexions, audit, SIEM, contrats, facturation et calendrier métier.
• Classer les risques selon portée, données, activité, provenance, justificatif et criticité.
• Faire approuver chaque réduction ou retrait avec test et retour arrière.
• Surveiller après changement et fixer la prochaine revue.

L'objectif est une gouvernance continue, pas un grand ménage annuel

Un bon audit ne cherche pas seulement les applications à supprimer. Il rend chaque accès explicable : qui en est responsable, pourquoi il existe, quelles données il atteint, avec quelle identité, pendant combien de temps et comment son retrait sera testé.

Les scripts ci-dessus accélèrent l'inventaire, mais ils ne voient pas le contrat, le processus d'affaires, le code du fournisseur ni toutes les dépendances. Une évaluation Microsoft 365 complète remet les permissions OAuth en contexte avec les rôles, le partage, Conditional Access, les comptes privilégiés, les journaux et le plan de réponse aux incidents.

• Service — Audit de sécurité Microsoft 365 et Entra ID →
• Article — Remplacer AzureAD et MSOnline par Microsoft Graph PowerShell →
• Article — Vol de jetons Microsoft 365 et attaques AiTM →