Microsoft Entra : sécuriser les identités applicatives

Introduction : l'identité dépasse le périmètre humain

La gestion des identités dans Microsoft Entra ID a profondément évolué. Si l'administration des comptes utilisateurs reste un pilier fondamental, elle ne représente plus qu'une fraction du périmètre à sécuriser. Les applications cloud, les principaux de service (service principals) et, plus récemment, les agents d'intelligence artificielle constituent désormais des identités à part entière — souvent plus puissantes et moins surveillées que les comptes humains.

Cette réalité redéfinit la surface d'attaque de l'identité. Les équipes sécurité doivent aujourd'hui protéger non seulement des mots de passe humains, mais un écosystème complet d'identités non humaines, exposées au credential harvesting, aux déplacements latéraux et aux abus de permissions silencieux. Cet article propose une analyse structurée des risques liés aux enregistrements d'applications et un chemin concret vers une gouvernance Zero Trust appliquée aux workload identities.

Les risques cachés dans les enregistrements d'applications

Shadow Admins : des permissions sans supervision

Les permissions de type Application (App-only permissions) constituent le premier vecteur de risque. Contrairement aux permissions déléguées, qui s'exécutent dans le contexte d'un utilisateur authentifié, les permissions Application agissent de manière totalement autonome, sans présence utilisateur, sans validation en temps réel et sans périmètre borné par les droits d'un individu.

Un principal de service disposant de permissions Application opère en arrière-plan avec un niveau de privilège comparable à celui d'un administrateur invisible — ce que la communauté sécurité désigne comme un Shadow Admin. Ces identités ne déclenchent aucune alerte MFA, ne sont soumises à aucune politique de session et passent souvent sous le radar des revues d'accès classiques.

Secret Sprawl : la prolifération des secrets clients

Le deuxième risque majeur est celui du Secret Sprawl, ou prolifération des secrets clients (client_secret). Dans de nombreuses organisations, ces secrets sont :

• Partagés par e-mail entre développeurs
• Stockés en clair dans des fichiers de configuration
• Commités accidentellement dans des dépôts Git publics ou privés
• Prolongés indéfiniment sans rotation ni audit

Un secret divulgué équivaut à une porte d'entrée persistante sur le tenant. Contrairement à un mot de passe utilisateur, il ne déclenche pas de politique de verrouillage et peut rester actif pendant des mois si aucune surveillance n'est en place.

Scopes à haut risque : des autorisations trop larges

Le troisième vecteur concerne les périmètres d'API à haut risque. Des scopes tels que :

• Files.ReadWrite.All — accès en lecture/écriture à l'ensemble des fichiers SharePoint et OneDrive
• Groups.ReadWrite.All — contrôle total sur tous les groupes Microsoft 365
• Mail.ReadWrite.All — accès complet aux boîtes mail de tous les utilisateurs
• Directory.ReadWrite.All — modification de l'annuaire Entra ID

ces autorisations sont fréquemment attribuées par facilité lors du développement, puis maintenues en production. Un seul principal de service compromis disposant de ces scopes peut compromettre l'intégralité des données d'une organisation.

Audit des permissions : commandes PowerShell essentielles

L'audit régulier des enregistrements d'applications et de leurs permissions constitue une hygiène de sécurité non négociable. Voici des exemples concrets utilisant le module Microsoft Graph PowerShell.

Lister tous les principals de service avec des permissions Application

1# Connexion avec les droits nécessaires
2Connect-MgGraph -Scopes "Application.Read.All", "Directory.Read.All"
3 
4# Récupérer toutes les attributions de rôles d'application (App Role Assignments)
5$appRoleAssignments = Get-MgServicePrincipalAppRoleAssignment -All
6 
7# Filtrer et afficher les permissions critiques
8$appRoleAssignments | Select-Object PrincipalDisplayName, ResourceDisplayName, AppRoleId | Format-Table -AutoSize

Identifier les secrets clients arrivant à expiration

1# Récupérer toutes les applications avec leurs credentials
2$apps = Get-MgApplication -All
3 
4foreach ($app in $apps) {
5    foreach ($secret in $app.PasswordCredentials) {
6        $daysUntilExpiry = ($secret.EndDateTime - (Get-Date)).Days
7        if ($daysUntilExpiry -lt 90) {
8            [PSCustomObject]@{
9                AppDisplayName  = $app.DisplayName
10                AppId           = $app.AppId
11                SecretName      = $secret.DisplayName
12                ExpiryDate      = $secret.EndDateTime
13                DaysRemaining   = $daysUntilExpiry
14            }
15        }
16    }
17} | Format-Table -AutoSize

Détecter les applications sans propriétaire défini

1# Identifier les enregistrements d'applications orphelins
2$apps = Get-MgApplication -All
3 
4foreach ($app in $apps) {
5    $owners = Get-MgApplicationOwner -ApplicationId $app.Id
6    if ($owners.Count -eq 0) {
7        [PSCustomObject]@{
8            DisplayName = $app.DisplayName
9            AppId       = $app.AppId
10            CreatedDate = $app.CreatedDateTime
11        }
12    }
13} | Format-Table -AutoSize

Gouvernance Zero Trust : trois leviers opérationnels

L'application du modèle Zero Trust aux identités applicatives repose sur trois piliers concrets.

Levier 1 : repenser la propriété des applications

L'assignation d'utilisateurs réguliers comme propriétaires d'enregistrements d'applications crée des points de défaillance uniques. Si ce compte est compromis ou supprimé, la gouvernance de l'application devient opaque.

Les bonnes pratiques recommandées sont les suivantes :

• Utiliser des métadonnées et des tags pour documenter le propriétaire fonctionnel et technique
• Exploiter la notion de Sponsors disponible dans Entra ID pour les identités de charge de travail
• Ne jamais assigner un compte personnel comme seul propriétaire d'une application critique
• Maintenir un registre de toutes les applications avec leur contexte métier

Levier 2 : imposer des appareils gérés pour les agents IA

Les agents d'IA s'exécutant sur des équipements personnels ou des environnements non maîtrisés échappent à toute visibilité organisationnelle. L'absence de contrôle sur l'environnement d'exécution annule la pertinence de toute politique d'accès.

La recommandation est d'exiger des appareils Entra-joined (ou Hybrid Entra-joined) pour tout workload accédant à des ressources sensibles. Cette exigence peut être appliquée via les politiques de Conditional Access en ciblant l'état de conformité de l'appareil.

Levier 3 : étendre l'accès conditionnel aux workload identities

L'accès conditionnel ne doit plus être réservé aux utilisateurs humains. Microsoft Entra Workload Identity Conditional Access permet d'appliquer des restrictions granulaires aux principaux de service, notamment :

• Restrictions basées sur la localisation réseau (IP ranges autorisées)
• Blocage des connexions depuis des emplacements inhabituels ou à risque
• Alertes en cas d'utilisation d'un secret depuis une géographie non attendue

1# Exemple : créer une politique Conditional Access pour les Workload Identities
2# via Microsoft Graph API
3 
4$policy = @{
5    displayName = "Block Workload Identities - Outside Trusted IPs"
6    state = "enabled"
7    conditions = @{
8        clientAppTypes = @("servicePrincipal")
9        servicePrincipalRiskLevels = @("high", "medium")
10        locations = @{
11            includeLocations = @("All")
12            excludeLocations = @("AllTrusted")
13        }
14    }
15    grantControls = @{
16        operator = "OR"
17        builtInControls = @("block")
18    }
19}
20 
21# Appel API Graph pour créer la politique
22New-MgIdentityConditionalAccessPolicy -BodyParameter $policy

Mise en œuvre progressive : feuille de route recommandée

1# Activer une System-assigned Managed Identity sur une Azure Function
2Update-AzFunctionApp -Name "MyFunctionApp" `
3    -ResourceGroupName "MyResourceGroup" `
4    -IdentityType SystemAssigned

Conclusion : les identités non humaines, priorité stratégique de sécurité

Sécuriser Microsoft Entra en 2025, c'est accepter une réalité fondamentale : les identités les plus dangereuses dans un tenant ne sont pas toujours humaines. Les applications, les principaux de service et les agents d'IA doivent être soumis à la même rigueur de gouvernance que les comptes à privilèges.

En combinant un audit rigoureux des permissions, une gestion saine des secrets clients, la migration vers les Managed Identities et l'extension du Zero Trust aux workload identities, les organisations peuvent réduire significativement leur surface d'attaque applicative.

La maîtrise de l'écosystème applicatif n'est plus une option : elle est indissociable de toute stratégie de cybersécurité moderne.