Applications Azure Sur-Privilegiees dans Votre Tenant

Applications Azure Sur doit s'appuyer sur des preuves de production, une responsabilité claire et un processus de revue qui survive au prochain changement d'infrastructure.

Que sont les Enregistrements d'Applications Azure ?

Les enregistrements d'applications dans Azure Entra ID permettent aux applications de s'authentifier et d'accéder à Microsoft Graph, aux ressources Azure et à d'autres APIs. Ils sont la couche d'identité pour chaque application personnalisée, script d'automatisation, intégration et outil SaaS tiers connecté à votre environnement Microsoft 365.

Les enregistrements d'applications s'accumulent au fil du temps comme les comptes utilisateurs. Le shadow IT en crée sans gouvernance. Les développeurs enregistrent des applications pour des tests rapides et ne les suppriment jamais. Les intégrations tierces demandent plus de permissions que nécessaire. Le résultat est un environnement rempli d'applications détenant un accès privilégié aux boîtes mail, SharePoint, Teams et ressources Azure — souvent avec des secrets clients qui n'expirent jamais et que personne ne surveille.

Compromettre un enregistrement d'application avec des permissions Microsoft Graph élevées équivaut à compromettre un compte utilisateur privilégié — souvent avec moins de signaux de détection.

Comment ca Fonctionne

Les enregistrements d'applications s'authentifient auprès d'Entra ID via :

• Secrets clients — mots de passe pour l'application, souvent avec des dates d'expiration longues
• Certificats — certificats X.509 utilisés pour l'authentification applicative

Une fois authentifiée, l'application agit selon ses permissions API. Deux types de permissions existent :

• Permissions déléguées — l'application agit au nom d'un utilisateur connecté
• Permissions applicatives — l'application agit par elle-même, sans contexte utilisateur

Les permissions applicatives sont les dangereuses. Une application avec la permission applicative Mail.ReadWrite peut lire et écrire dans toutes les boîtes mail du tenant sans aucune interaction utilisateur.

La Chaine d'Attaque

Etape 1 - Enumérer les Enregistrements et leurs Permissions

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

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

    [PSCustomObject]@{
        NomApp       = $app.DisplayName
        AppId        = $app.AppId
        Creee        = $app.CreatedDateTime
        ExpirSecret  = ($app.PasswordCredentials | Sort-Object EndDateTime | Select-Object -Last 1).EndDateTime
        Permissions  = ($appRoles.AppRoleId | ForEach-Object { $_.ToString() }) -join ", "
    }
} | Where-Object {$_.Permissions -ne ""}

Etape 2 - Cibler les Applications avec Permissions Elevées et Secrets Faibles

Cibles prioritaires :

• Applications avec permissions applicatives Mail.ReadWrite, Files.ReadWrite.All ou Directory.ReadWrite.All
• Applications avec des secrets expirant dans des années ou n'expirant jamais
• Applications avec des secrets non renouvelés depuis plus de 12 mois

Etape 3 - Extraire ou Brute-Forcer le Secret Client

Les secrets clients sont souvent stockés de façon non sécurisée — dans des dépôts de code, pipelines CI/CD, fichiers de configuration ou machines de développeurs. Les attaquants scannent GitHub pour les credentials Azure divulgués.

Etape 4 - S'Authentifier en tant qu'Application et Exfiltrer

import msal, requests

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

# Avec Mail.ReadWrite.All — dump de toutes les boîtes mail
r = requests.get("https://graph.microsoft.com/v1.0/users",
    headers={"Authorization": f"Bearer {token}"})

Détection

Logs d'Audit Microsoft Entra

Requete SIEM (Elastic KQL)

azure.auditlogs.operation_name: "Add password credential to service principal" AND
NOT azure.auditlogs.properties.initiated_by.user.roles: "*Admin*"

💡 Conseil : Activez les logs d'activité Microsoft Graph et routez-les vers votre SIEM. Les lectures en masse de boîtes mail ou l'énumération d'utilisateurs par une application sont de forts indicateurs d'exfiltration.

Remédiation

💡 Action Rapide : Exécutez le script d'audit ci-dessus et identifiez toute application avec des permissions applicatives Directory.ReadWrite.All ou Mail.ReadWrite. Chacune est un vecteur potentiel de compromission totale du tenant.

1. Supprimer les Applications Non Utilisées

$cutoff = (Get-Date).AddDays(-90)
Get-MgApplication | Where-Object {$_.CreatedDateTime -lt $cutoff} | ForEach-Object {
    $sp = Get-MgServicePrincipal -Filter "appId eq '$($_.AppId)'"
    $dernièreConnexion = (Get-MgServicePrincipalSignInActivity -ServicePrincipalId $sp.Id).LastSignInDateTime
    if ($dernièreConnexion -lt $cutoff -or $null -eq $dernièreConnexion) {
        [PSCustomObject]@{App=$_.DisplayName; DernièreConnexion=$dernièreConnexion}
    }
}

2. Remplacer les Secrets par des Certificats

Les secrets clients sont plus facilement divulgués que les certificats. Migrez les applications à hauts privilèges vers l'authentification par certificat.

$cert = New-SelfSignedCertificate -Subject "CN=NomApp" -CertStoreLocation "Cert:\CurrentUser\My" `
    -KeyExportPolicy Exportable -KeySpec Signature -NotAfter (Get-Date).AddYears(2)
$certData = [Convert]::ToBase64String($cert.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Cert))
$keyCredential = @{Type="AsymmetricX509Cert"; Usage="Verify"; Key=[Convert]::FromBase64String($certData)}
Update-MgApplication -ApplicationId $appId -KeyCredentials @($keyCredential)

3. Appliquer le Moindre Privilège aux Permissions

• Remplacer Mail.ReadWrite par Mail.Read si l'écriture n'est pas nécessaire
• Remplacer Directory.ReadWrite.All par des permissions de lecture spécifiques
• Utiliser des permissions déléguées plutôt qu'applicatives quand le contexte utilisateur est disponible

Comment EtcSec Détecte Cela

EtcSec audite tous les enregistrements d'applications et principaux de service dans votre tenant Azure.

La catégorie Applications vérifie : les applications avec des permissions applicatives trop larges, les applications avec des secrets expirés ou expirant, les applications sans activité de connexion récente, et les applications avec consentement admin accordé à des permissions sensibles sans révision.

ℹ️ Note : EtcSec audite tous les enregistrements d'applications Azure automatiquement. Lancez un audit gratuit pour découvrir les applications sur-privilégiées et oubliées dans votre tenant.

Articles connexes : Accès Privilégié Azure | Sécurité Identités Azure

Priorites de Revue

Applications Azure Sur-Privilegiees dans Votre Tenant doit etre traite comme une exposition reelle dans votre tenant Entra ID et Azure, pas comme un simple parametre isole. La premiere etape consiste a definir le vrai perimetre de revue : quels admins, comptes invites, service principals, app registrations, exclusions de politiques et comptes break-glass sont concernes, quelles dependances metier existent, quels privileges sont exposes et quelles exceptions d'urgence ont ete ajoutees avec le temps. Ce cadrage evite une remediation superficielle, car le symptome technique est souvent plus petit que le rayon d'impact operationnel. En documentant le chemin complet entre configuration, privilege et usage reel, l'equipe peut prioriser des changements qui reduisent le risque sans bloquer l'activite.

Controles Adjacents a Revoir

Quand un attaquant arrive dans votre tenant Entra ID et Azure, il ne s'arrete presque jamais au premier point faible. Autour de Applications Azure Sur-Privilegiees dans Votre Tenant, il cherche en general a enchainer avec auth legacy, gouvernance invite insuffisante, consentements trop larges, comptes d'urgence obsoletes et roles jamais revises. Cela signifie que la defense doit revoir non seulement la faiblesse principale, mais aussi toutes les dependances qui transforment un acces initial en persistance ou en escalation. Verifiez quelles identites, quels roles, quelles permissions et quelles hypotheses de confiance peuvent etre reutilises. Si le correctif ferme un seul objet mais laisse intactes les voies adjacentes, le risque reel change peu. Une revue des chaines d'abus est donc indispensable pour obtenir un resultat durable.

Preuves et telemetry a collecter

Une bonne reponse a Applications Azure Sur-Privilegiees dans Votre Tenant repose sur des preuves que l'ingenierie et la detection peuvent relire ensemble. Collectez journaux de connexion, journaux d'audit, changements de roles, evenements de consentement, rotations de secrets et signaux de risque, comparez les changements recents avec les fenetres de maintenance attendues et isolez les comptes ou objets qui ont change de comportement sans justification claire. Ces elements doivent permettre de repondre a trois questions simples : quand l'exposition est apparue, qui peut encore l'utiliser, et si des variantes similaires existent ailleurs dans votre tenant Entra ID et Azure. La collecte de preuves aide aussi a distinguer une dette technique ancienne d'un usage actif. Cette distinction est essentielle pour choisir le bon niveau d'urgence et la bonne sequence de remediation.

Faiblesses voisines a revoir

Tres peu d'environnements contiennent Applications Azure Sur-Privilegiees dans Votre Tenant seul. Dans la pratique, la meme zone du tenant ou de l'annuaire contient souvent aussi auth legacy, gouvernance invite insuffisante, consentements trop larges, comptes d'urgence obsoletes et roles jamais revises, et ce sont ces faiblesses voisines qui determinent si l'exposition reste limitee ou devient critique. Revoyez les owners communs, les permissions heritees, les exceptions dupliquees et les raccourcis administratifs qui n'ont jamais ete retires. Verifiez si la meme logique de contournement a ete approuvee a plusieurs endroits, car cela revele souvent une faille de processus plus qu'un bug unique. Cette revue elargie donne une meilleure chance d'eliminer le chemin d'attaque complet.

Ordre de remediation recommande

Pour Applications Azure Sur-Privilegiees dans Votre Tenant, l'ordre de remediation doit privilegier la reduction de risque avant la perfection. Commencez par fermer les chemins qui augmentent le plus vite le privilege, puis verrouillez les objets ou identites a plus forte valeur, et ensuite seulement traitez les ecarts de hygiene secondaires. Utilisez Conditional Access, PIM, moindre privilege, access reviews, validation des owners applicatifs, workflows d'approbation et MFA fort comme ensemble de controles cible. Chaque changement doit avoir un owner, une note de rollback et une etape de validation. Cette discipline evite que les programmes de correction s'arretent apres le premier gain technique. Si une refonte complete n'est pas possible tout de suite, formalisez des controles intermediaires et planifiez le travail structurel dans le prochain revue operationnelle hebdomadaire et revue de durcissement mensuelle.

Validation apres chaque changement

Apres toute modification liee a Applications Azure Sur-Privilegiees dans Votre Tenant, validez le resultat sous deux angles : administration legitime et chemin d'attaque. Confirmez que les utilisateurs et systemes attendus continuent de fonctionner, puis prouvez que la voie dangereuse ne donne plus le meme levier. Rejouez la collecte sur journaux de connexion, journaux d'audit, changements de roles, evenements de consentement, rotations de secrets et signaux de risque, relisez les approbations et verifiez qu'aucun objet voisin ne conserve une voie de contournement. La validation doit aussi inclure une definition ecrite du succes, afin que tout le monde sache ce qui constitue une fermeture acceptable. Dans les equipes matures, un correctif n'est accepte que lorsque le chemin risque est ferme et que l'etat final correspond vraiment a l'objectif de durcissement.

Lectures Associees

Pour traiter ce sujet correctement, comparez-le aussi avec Durcissement du Tenant Azure : Corriger les Configs à Risque, Acces Privilegie Azure : Trop d'Admins Globaux, Failles d'Accès Conditionnel Azure : Contournement du MFA, Comptes Invités Azure : Risques du Tenant et Azure Identity Protection : Automatiser la Réponse aux Credentials Divulgués. Ensemble, ces articles montrent comment les memes faiblesses d'identite s'enchainent dans une vraie evaluation de securite.

• Durcissement du Tenant Azure : Corriger les Configs à Risque
• Acces Privilegie Azure : Trop d'Admins Globaux
• Failles d'Accès Conditionnel Azure : Contournement du MFA
• Comptes Invités Azure : Risques du Tenant
• Azure Identity Protection : Automatiser la Réponse aux Credentials Divulgués

Ces liens internes permettent de verifier si vous corrigez un symptome isole ou un chemin d'exposition complet.

Questions a Trancher Avant la Validation Finale

Avant qu'une equipe considere un sujet identite comme vraiment traite, elle devrait pouvoir repondre a quelques questions simples avec des preuves concretes. Quel compte, quel groupe ou quel systeme reste aujourd'hui le chemin d'exception le plus sensible ? Quelle dependance operationnelle a empeche une remediation plus complete, et qui a accepte ce risque de facon explicite ? Quel controle compensatoire, quelle regle de supervision ou quelle frequence de revue couvre desormais l'exposition residuelle en production ? Ces questions comptent parce qu'une faiblesse d'identite revient souvent lorsque la note de remediaton est plus forte que la realite d'exploitation. Si l'organisation ne peut pas expliquer clairement le proprietaire, la dependance metier et la prochaine date de revue, le controle n'est generalement pas aussi stable qu'il en a l'air.

Preuves a Conserver pour la Revue Suivante

Les equipes les plus solides conservent juste assez de preuves pour rendre la revue suivante plus rapide et plus fiable. Cela inclut en general le proprietaire actuel de l'actif concerne, le changement de configuration exact qui a reduit le risque, la liste des exceptions encore acceptees et la preuve technique montrant que le nouvel etat est bien applique en production. Cette discipline est utile parce que les problemes d'identite et de privilege ne sont presque jamais des decouvertes uniques. Ils reviennent plutot via le turnover administrateur, la derive applicative ou des dependances historiques mal comprises au premier passage. En documentant a la fois la correction et la raison pour laquelle elle a ete acceptee, les equipes reduisent le risque de refaire la meme analyse a chaque cycle ou de reintroduire la meme faiblesse en corrigeant un autre sujet operationnel.

Applications Azure Sur : validation avant clôture

Une revue solide de Applications Azure Sur doit se terminer par des preuves de production, pas par l'hypothèse que le chemin risqué a disparu. Avant de clôturer le constat, revalidez les attributions de rôles, la portée des politiques, les permissions applicatives ou les paramètres guest, les preuves de connexion, d'audit ou de risque sur le tenant réel et le chemin d'exception qui pourrait recréer l'exposition. Confirmez que l'état plus sûr s'applique bien au périmètre qui compte réellement : l'OU de production, l'attribution de rôle effective, le chemin applicatif ou le chemin de délégation et de confiance qu'un attaquant pourrait réellement exploiter. Documentez le propriétaire technique, la dépendance métier et la condition de retour arrière afin que le prochain cycle sache si l'état plus sûr a été maintenu.

Utilisez une checklist de clôture courte :

• vérifier que l'état risqué a disparu du point de vue attaquant, pas seulement dans une capture d'écran admin
• conserver un export avant/après ou un échantillon de log prouvant que la portée concernée a changé
• documenter le propriétaire et la décision d'exception si le contrôle ne peut pas être appliqué complètement

Pour les expositions adjacentes, recoupez le résultat avec Audit de sécurité Active Directory : checklist pratique, Comment auditer la sécurité Microsoft Entra ID (Azure AD) : guide pratique, Acces Privilegie Azure : Trop d'Admins Globaux, et Mots de passe dans les descriptions AD : détection et correction. Le même défaut de contrôle réapparaît souvent dans des chemins d'identité voisins, des manques de journalisation ou des délégations trop larges, d'où l'importance de cette validation finale.

Applications Azure Sur : preuves à conserver pour le prochain cycle

Le prochain relecteur ne devrait pas avoir à reconstruire le dossier de mémoire. Conservez la preuve qui justifiait le constat initial, la preuve que le changement a été appliqué, et la note qui explique pourquoi l'état final est acceptable. Pour ce sujet, les preuves les plus utiles combinent généralement l'export ou la capture montrant la portée réellement concernée, les logs de connexion, d'audit ou la preuve de politique confirmant l'application du contrôle et le propriétaire, l'approbation et la note d'exception sur l'état final. Ce paquet compact accélère fortement les revues trimestrielles ou après changement et permet d'expliquer si le problème a été supprimé, réduit ou accepté formellement.

Si un changement d'admin, de politique ou d'application rouvre plus tard le chemin, cet historique permet aussi de démontrer précisément ce qui a dérivé. C'est ce qui transforme Applications Azure Sur en processus d'assurance répétable plutôt qu'en contrôle ponctuel.