Applications Azure Sur-Privilegiees dans Votre Tenant

Les Applications Azure Sur-Privilégiées figurent parmi les endroits d'un tenant où le privilège devient le plus facilement invisible. Une application enregistrée (app registration) peut ressembler à un simple détail d'intégration, alors que son service principal peut détenir des permissions d'application Microsoft Graph, des identifiants actifs et des chemins d'accès à l'échelle du tenant qui ne dépendent d'aucun utilisateur connecté.

Quels sont les risques des applications Azure enregistrées ?

Les applications Azure enregistrées (app registrations) sont les objets d'identité derrière les applications personnalisées, les automatisations, les intégrations et de nombreuses connexions SaaS tierces dans Microsoft Entra ID. Elles peuvent s'authentifier auprès de Microsoft Graph, des ressources Azure et d'autres API protégées.

Le risque apparaît lorsque ces applications conservent plus de permissions que nécessaire, gardent leurs identifiants plus longtemps qu'il ne faudrait, ou restent dans le tenant longtemps après que leur propriétaire d'origine a cessé de s'y intéresser. Dans cet état, l'application se comporte comme une identité privilégiée permanente, avec beaucoup moins de visibilité humaine au quotidien qu'un compte utilisateur administrateur.

Une bonne revue ne consiste pas seulement à trouver une permission dangereuse. Il s'agit de prouver quelles applications sont actives, lesquelles disposent d'un accès applicatif à privilège élevé, qui en est propriétaire, et comment leurs identifiants sont gouvernés.

Comment cela fonctionne

Les applications enregistrées s'authentifient généralement avec l'un des deux types d'identifiants suivants :

• client secrets
• certificats

L'application agit ensuite selon les permissions accordées à son service principal correspondant.

Deux grands modèles de permissions sont à distinguer :

• les permissions déléguées, où l'application agit dans le contexte d'un utilisateur connecté
• les permissions d'application, où l'application agit en son propre nom, sans utilisateur présent

La documentation Microsoft Graph est explicite sur cette différence : les permissions d'application sont des permissions propres à l'application, utilisées sans utilisateur connecté. Une app daemon ou un service backend peut les utiliser pour appeler des API en son propre nom. Si l'application détient une permission d'application étendue, le rayon d'impact est déterminé par cette permission et par la ressource concernée, et non par la session en cours d'un utilisateur interactif.

Les cas les plus à risque sont généralement des permissions d'application accordant un accès étendu aux données de tout le tenant ou une capacité de modification de l'annuaire. Si un attaquant obtient l'identifiant de l'application, il hérite de tout le pouvoir API que celle-ci détient déjà.

Applications Azure Sur-Privilégiées : ce qui les rend à haut risque

Le schéma dangereux est généralement une combinaison, pas une seule case à cocher :

• des permissions d'application étendues, comme un accès aux boîtes mail, fichiers ou à l'annuaire à l'échelle du tenant
• des identifiants à longue durée de vie, faiblement rotés, ou copiés à plusieurs endroits
• l'absence de propriétaire clair pour l'application ou son service principal
• l'absence d'activité de connexion récente, ce qui suggère que l'application est peut-être abandonnée mais reste néanmoins de confiance
• un consentement administrateur accordé il y a longtemps, sans revue récurrente

C'est pourquoi une revue des permissions sans revue de la propriété (ownership) reste incomplète. Une application aux permissions modérées et sans propriétaire peut tout de même devenir un incident grave lorsque le secret fuite et que personne ne remarque les connexions.

Une deuxième distinction pratique compte également : certaines applications sont risquées parce qu'elles peuvent écrire ou administrer, d'autres le sont parce qu'elles peuvent lire silencieusement de grands volumes de données du tenant. Les deux cas méritent une revue, même lorsque le portail les étiquette comme des ensembles de permissions différents.

Faits sur les permissions qui changent le risque

Ne traitez pas chaque permission Graph comme interchangeable. Microsoft documente que les permissions d'application peuvent fonctionner sans utilisateur connecté, et que certaines permissions autorisent un accès à l'échelle de toute l'organisation sur les données associées. Par exemple, une permission étendue de fichiers, de messagerie, d'annuaire ou de gestion des applications peut être plus dommageable qu'une permission déléguée qui ne fonctionne qu'à l'intérieur d'une session utilisateur restreinte.

Les permissions de gestion des applications méritent une attention particulière. La référence des permissions Microsoft Graph avertit que les permissions capables de gérer des identifiants peuvent permettre à une application d'agir comme d'autres entités et d'utiliser les privilèges qui leur ont été accordés. C'est une classe de risque différente de celle d'une application qui se contente de lire son propre profil.

Le consentement administrateur fait également partie de la frontière de contrôle. Les permissions d'application ne peuvent être consenties que par un administrateur, jamais par un utilisateur final. Spécifiquement pour les permissions d'application Microsoft Graph, Microsoft documente que seuls Privileged Role Administrator et Global Administrator peuvent donner leur consentement ; Application Administrator et Cloud Application Administrator peuvent consentir aux permissions d'application hors Microsoft Graph. Si le tenant ne dispose pas d'une revue récurrente des applications ayant reçu un consentement administrateur, le modèle d'accès effectif peut dériver pendant des années après la fin du projet d'origine.

La chaîne d'attaque

Étape 1 - Recenser les applications enregistrées et leurs permissions

Connect-MgGraph -Scopes 'Application.Read.All'

Get-MgApplication -All | ForEach-Object {
  $app = $_
  $sp = Get-MgServicePrincipal -Filter "appId eq '$($app.AppId)'"
  $appRoles = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id

  [PSCustomObject]@{
    AppName      = $app.DisplayName
    AppId        = $app.AppId
    Created      = $app.CreatedDateTime
    SecretExpiry = ($app.PasswordCredentials | Sort-Object EndDateTime | Select-Object -Last 1).EndDateTime
    Permissions  = ($appRoles | ForEach-Object { "$($_.ResourceDisplayName):$($_.AppRoleId)" }) -join ', '
  }
} | Where-Object { $_.Permissions -ne '' }

Étape 2 - Prioriser les combinaisons les plus sensibles

Concentrez-vous d'abord sur les applications qui combinent des permissions étendues au niveau du tenant avec des identifiants obsolètes ou une propriété peu claire. Les service principals qui détiennent directement des rôles admin Entra constituent un cas à part, souvent pire, traité dans Rôle Admin de Service Principal Entra Sur-Privilégié : Détection et Correction.

Un ordre de tri utile :

1. les applications disposant de permissions d'application vers Microsoft Graph ou des workloads Exchange
2. les applications disposant de permissions de gestion d'applications ou de gestion de l'annuaire
3. les service principals disposant d'identifiants actifs mais sans preuve de connexion récente
4. les applications avec plusieurs secrets ou certificats actifs qu'aucun propriétaire ne peut expliquer
5. les applications avec un consentement administrateur mais sans propriétaire métier actuel

Étape 3 - Récupérer l'identifiant

Les client secrets sont souvent exposés via des dépôts de code, des pipelines de déploiement, des fichiers de configuration locaux, ou des notes opérationnelles copiées. Le problème n'est pas que les secrets fuitent en théorie. Le problème est que de nombreux tenants s'appuient encore sur des secrets à longue durée de vie pour des applications à forte valeur.

Étape 4 - S'authentifier en tant qu'application et utiliser le scope accordé

import msal

app = msal.ConfidentialClientApplication(
    client_id='APP_CLIENT_ID',
    client_credential='STOLEN_SECRET',
    authority='https://login.microsoftonline.com/TENANT_ID'
)
result = app.acquire_token_for_client(scopes=['https://graph.microsoft.com/.default'])
token = result['access_token']

À ce stade, le chemin d'attaque est déterminé par les permissions déjà accordées à l'application, et non par un nouvel exploit administrateur.

Détection

Signaux d'audit et de connexion Entra

Microsoft documente les journaux de connexion des service principals séparément des connexions utilisateur interactives et non interactives. Ces journaux sont importants car une authentification purement applicative n'implique aucun utilisateur humain. Microsoft documente également que ces événements sont agrégés : les connexions sont regroupées en une seule ligne lorsque le nom ou l'ID du service principal, le statut, l'adresse IP et le nom ou l'ID de la ressource correspondent tous, donc développez une ligne avant de conclure qu'une application ne s'est connectée qu'une seule fois. Les connexions de managed identity n'apparaissent pas dans ce journal ; elles ont le leur. Pour les schémas de détection propres à ce journal, voir Entra Service Principal : Détection des Anomalies de Connexion, Angles Morts de l'Identité de Charge de Travail.

Questions pratiques de revue

• quelles applications détiennent des permissions d'application à portée sur tout le tenant
• quelles applications ont plusieurs secrets actifs, ou d'anciens secrets jamais supprimés
• quelles applications n'ont pas de connexion récente mais conservent un accès privilégié
• quelles applications n'ont pas de propriétaire actif ni de sponsor métier
• quelles applications peuvent gérer des applications, des service principals, des identifiants, des grants ou des attributions de rôles

Requête de détection SIEM (Elastic KQL)

data_stream.dataset: "azure.auditlogs"
    and azure.auditlogs.operation_name: "Add service principal credentials"
    and event.outcome: "success"

Utilisez le nom de l'activité exactement tel que Microsoft le publie dans la référence des activités d'audit. Un identifiant ajouté sur l'objet application lui-même est journalisé sous une activité différente, Update application - Certificates and secrets management, si bien qu'une règle surveillant uniquement l'activité du service principal manque la moitié des cas. Cet événement devient beaucoup plus utile lorsqu'on l'enrichit avec le propriétaire de l'application, l'inventaire précédent des identifiants, et le niveau de permission du service principal concerné.

Logique de détection qui réduit les faux positifs

Un nouveau secret sur une application de test à faible privilège n'est pas la même chose qu'un nouveau secret sur une application disposant de permissions d'application Graph et sans propriétaire. Priorisez en croisant l'activité d'audit avec l'inventaire des applications :

• les permissions actuelles de l'application et le statut de consentement
• si l'application utilise des permissions d'application ou des permissions déléguées
• le nombre d'identifiants et leurs dates d'expiration
• l'horodatage de la dernière connexion du service principal
• le nombre de propriétaires et s'ils sont toujours des employés actifs
• si l'IP source ou le workload a changé par rapport à la baseline historique

Remédiation

Gain rapide : recensez chaque application disposant de permissions d'application étendues et faites attester au propriétaire que la permission et l'identifiant restent nécessaires.

1. Supprimer ou désactiver les applications inutilisées

Partez de l'ancienneté, mais ne confondez pas ancienneté et non-usage. La requête ci-dessous liste les applications enregistrées il y a plus de 90 jours, ce qui dans un tenant mature représente la plupart d'entre elles. Elle produit une liste de candidates à la revue, pas une liste d'applications inutilisées.

$cutoff = (Get-Date).AddDays(-90)
Get-MgApplication -All | Where-Object { $_.CreatedDateTime -lt $cutoff } |
  Select-Object DisplayName, AppId, CreatedDateTime

Le signal de non-usage, c'est l'authentification, pas la date de création : vérifiez les journaux de connexion du service principal pour l'application, ou le rapport Service principal sign-in activity usage and insights, encore en préversion au moment de la rédaction. Combinez revue d'activité, de propriété et de dépendances. Si personne ne peut expliquer pourquoi l'application existe encore, elle ne devrait pas conserver un accès permanent.

2. Roter et réduire les identifiants

Get-MgApplication -All | ForEach-Object {
  $app = $_
  $app.PasswordCredentials |
    Where-Object { $_.EndDateTime -lt (Get-Date).AddDays(30) } |
    Select-Object @{n='AppName';e={$app.DisplayName}}, DisplayName, EndDateTime
}

Rotez les anciens secrets, supprimez les secrets remplacés, et évitez de laisser plusieurs identifiants valides actifs sans raison. Si un identifiant a été copié dans du code, des pipelines ou de la documentation, considérez la rotation comme une seule étape parmi d'autres. L'ancien emplacement de stockage doit lui aussi être nettoyé.

3. Préférer une gestion des identifiants plus robuste

Microsoft publie un ordre de préférence explicite, qui ne commence pas par les certificats. Utilisez une managed identity dès que le workload s'exécute sur Azure : Microsoft la qualifie d'option la plus sûre et la recommande fortement. Si le workload s'exécute ailleurs, sur une plateforme offrant une gestion automatisée des identifiants, utilisez plutôt la fédération d'identité de workload (workload identity federation). Ce n'est que lorsqu'aucune des deux n'est possible qu'il faut se rabattre sur des identifiants par certificat, stockés dans un key vault et émis par une autorité de certification de confiance plutôt qu'auto-signés.

Les recommandations de Microsoft sur les secrets sont sans détour : « Don't use password credentials, also known as secrets ». Les secrets sont pratiques, et c'est précisément pour cela qu'ils finissent copiés dans les outillages de développement et d'exploitation. Les politiques de gestion des applications peuvent aussi plafonner la durée de vie des secrets ou en bloquer purement et simplement l'usage.

4. Réduire le périmètre des permissions

Vérifiez si l'application a réellement besoin de permissions d'application. Dans la mesure du possible :

• remplacez les permissions d'écriture étendues par des permissions de lecture ou plus restreintes
• privilégiez les permissions déléguées lorsqu'un vrai contexte utilisateur existe
• supprimez le consentement administrateur qui n'est plus justifié par le workload
• évitez d'accorder des permissions de gestion d'applications sauf si le workload gère réellement des applications
• documentez pourquoi chaque permission d'application restante est nécessaire

5. Verrouiller qui peut créer des applications et donner son consentement

Microsoft fournit des paramètres de tenant et des rôles délégués pour contrôler qui peut enregistrer des applications et qui peut consentir aux applications. Désactivez l'enregistrement large d'applications par les utilisateurs et le consentement utilisateur là où le métier n'en a pas besoin, puis attribuez des rôles explicites aux équipes qui en ont besoin.

Ce n'est pas seulement de la gouvernance. Cela empêche le tenant de réintroduire le même problème après le nettoyage. Si n'importe qui peut créer des applications et demander des permissions étendues sans passer par une revue, la prolifération d'applications privilégiées reviendra.

Valider avant de clore le constat

Une revue des applications enregistrées n'est pas terminée simplement parce que le portail paraît plus propre. Validez le résultat par rapport au comportement réel du tenant.

• exportez les applications à haut risque restantes, leurs propriétaires, leurs identifiants actifs et leurs permissions effectives
• confirmez que les anciens secrets ont été supprimés, et non simplement remplacés pendant que l'identifiant précédent restait actif
• vérifiez que l'application fonctionne toujours après réduction des permissions ou rotation des identifiants
• confirmez que les applications abandonnées ont réellement été désactivées ou supprimées, plutôt que laissées comme exceptions non documentées
• passez en revue les journaux de connexion du service principal après le changement pour confirmer qu'il ne reste ni IP source ni ressource inattendue
• revérifiez les permissions ayant reçu un consentement administrateur et confirmez que la liste correspond à l'inventaire des applications

Passez également en revue le chemin de gouvernance environnant : qui peut créer des applications, qui peut accorder un consentement administrateur, et qui doit approuver un accès applicatif privilégié. Sans ce contrôle, le même schéma reviendra au prochain cycle de projet.

Comment EtcSec détecte cela

EtcSec rend les constats sur les applications enregistrées exploitables en combinant privilège, ancienneté des identifiants, lacunes de propriété et signaux d'activité. Un tenant échoue rarement parce qu'il compte de nombreuses applications. Il échoue parce qu'un petit nombre d'applications cumulent des permissions étendues, une hygiène des identifiants faible, et l'absence de chemin de revue clair.

Le modèle de détection est fondé sur l'exposition : permissions d'application étendues, identifiants qui restent valides, propriété peu claire, et activité de service principal qui ne correspond pas au cas d'usage documenté. Chacun de ces éléments correspond à un contrôle dédié : permissions dangereuses de messagerie, de fichiers, d'annuaire et de rôles accordées à une application ; applications cumulant plusieurs secrets actifs ou sans rotation d'identifiants ; applications et service principals sans propriétaire ; consentements accordés à l'échelle de tout le tenant ; et service principals détenant encore des identifiants obsolètes. La valeur réside dans le croisement, pas dans un seul indicateur isolé.

Lectures complémentaires

• Durcissement du Tenant Azure : Corriger les Configs à Risque
• Acces Privilegie Azure : Trop d'Admins Globaux
• Failles acces conditionnel Entra ID : quelles mauvaises configurations laissent une vraie exposition
• Sécurité des comptes invités Azure : la surface d'attaque oubliée de votre tenant
• Azure Identity Protection : Bloquer les Identifiants Divulgués

Références principales

• Microsoft Graph permissions overview
• Microsoft Graph permissions reference
• Permissions and consent in the Microsoft identity platform
• Service principal sign-in logs in Microsoft Entra ID
• Security best practices for application properties
• Delegate application management administrator permissions
• Microsoft Entra audit log activity reference