Rotation des secrets App Registration Entra : détection et remédiation

Qu'est-ce que l'hygiène des identifiants d'App Registration dans Entra

Les secrets de rotation des identifiants Entra App Registration sont les client secrets, certificats et identifiants fédérés que vos applications utilisent pour s'authentifier — et c'est l'un des angles morts les plus négligés de la surface d'attaque identité d'un tenant. Chaque App Registration qui s'authentifie en son propre nom, qu'il s'agisse d'un daemon, d'un pipeline CI/CD ou d'une intégration API, a besoin d'un identifiant pour prouver qu'elle est bien ce qu'elle prétend être. Cet identifiant est un passwordCredential (un client secret), un keyCredential (une clé publique de certificat téléversée), ou un identifiant fédéré (une relation de confiance avec un fournisseur d'identité externe, sans aucune matière secrète). Oublier de faire tourner l'un de ces identifiants, c'est la façon dont un secret de routine devient discrètement une porte dérobée permanente, sans invite MFA et souvent sans propriétaire pour la surveiller.

C'est important car l'identifiant d'une App Registration donne accès à tout ce que les permissions de cette application autorisent : scopes Microsoft Graph, permissions déléguées ou applicatives, parfois un accès en lecture/écriture à l'échelle de l'annuaire. Les recommandations de Microsoft sont explicites : les client secrets sont moins sécurisés que les identifiants par certificat ou fédérés, et ne devraient pas être utilisés en production ; avec la fédération d'identité de workload, vous éliminez la charge de maintenance liée à la gestion manuelle des identifiants ainsi que le risque de fuite de secrets ou d'expiration de certificats. Un tenant qui n'inventorie jamais les identifiants applicatifs n'a aucun moyen de distinguer un secret de routine d'un secret qui a discrètement survécu à tous les administrateurs qui savaient à quoi il servait.

C'est un angle différent de celui des App Registrations sur-privilégiées (traité dans Applications Azure Sur-Privilegiees dans Votre Tenant) — cet article-là porte sur ce qu'une application peut faire ; celui-ci porte sur combien de temps ses clés de la porte restent valides, et sur qui surveille la serrure. Un secret à longue durée de vie divulgué est exploité de la même façon qu'un token OAuth hameçonné dans OAuth Consent Phishing : silencieusement, avec les permissions propres de l'application, jusqu'à ce que quelqu'un remarque que l'activité ne correspond pas au comportement normal de l'application.

Comment ça fonctionne : secrets, certificats, et pourquoi la rotation est sautée

Chaque objet application et servicePrincipal dans Microsoft Graph expose deux collections d'identifiants :

• passwordCredentials — les client secrets, chacun avec un keyId, un startDateTime et un endDateTime. Selon la référence de la ressource passwordCredential, endDateTime est l'horodatage ISO 8601 UTC après lequel le secret cesse de fonctionner.
• keyCredentials — les clés publiques de certificats téléversées, utilisées pour l'authentification par certificat (CBA), chacune avec sa propre expiration.

Les client secrets créés depuis le portail sont plafonnés à une durée de vie maximale de 24 mois, et Microsoft recommande explicitement de fixer une expiration inférieure à 12 mois plutôt que d'utiliser le maximum par défaut. En pratique, les équipes font souvent l'inverse : elles choisissent l'expiration la plus longue proposée pour ne rien casser de façon imprévue, puis laissent l'application tranquille. Deux ans plus tard, la personne qui l'a configurée est partie, le secret est toujours valide, et plus personne ne se souvient de quel pipeline ou script en dépend.

Un problème lié mais distinct est l'étalement des identifiants (credential sprawl) : une application qui accumule plusieurs secrets actifs au fil du temps parce que la rotation a consisté à ajouter un nouveau secret plutôt qu'à remplacer l'ancien. Chaque secret actif supplémentaire est une porte d'entrée de plus à suivre, révoquer et auditer — et les anciens secrets issus d'une rotation qui « a fonctionné » ne sont pratiquement jamais nettoyés. Il est courant de trouver des App Registrations vieilles de plusieurs années portant trois ou quatre secrets actifs, chacun créé par un administrateur différent lors d'un incident différent, dont aucun n'a jamais été révoqué.

L'authentification par certificat est généralement le type d'identifiant le plus sûr des deux — la clé privée d'un certificat n'a jamais besoin d'être transmise ou collée dans un fichier de configuration comme l'est la valeur d'un secret. Mais un certificat CBA actif reste un identifiant vivant, avec une expiration et un rayon d'impact en cas de compromission de la clé privée, et Microsoft recommande que les certificats soient émis par une autorité de certification de confiance, avec une politique imposant des émetteurs de confiance plutôt que des certificats auto-signés à confiance indéfinie.

Détecter les secrets de rotation Entra App Registration périmés ou étalés

Commencez par un inventaire, pas par un sondage ponctuel — vous ne pouvez pas faire tourner ce que vous n'avez pas recensé.

Inventorier chaque identifiant via Microsoft Graph

Interrogez directement les identifiants de chaque application :

GET https://graph.microsoft.com/v1.0/applications
    ?$select=id,displayName,passwordCredentials,keyCredentials

La réponse inclut endDateTime pour chaque secret et certificat, ce qui permet de signaler tout ce qui est déjà expiré ou proche de l'expiration.

Scripter à l'échelle du tenant avec PowerShell

Le SDK PowerShell Microsoft Graph facilite l'exécution à l'échelle du tenant plutôt qu'application par application :

# Requires: Connect-MgGraph -Scopes "Application.Read.All"
Get-MgApplication -All -Property Id, DisplayName, PasswordCredentials, KeyCredentials |
  ForEach-Object {
    $app = $_
    $app.PasswordCredentials | ForEach-Object {
      [PSCustomObject]@{
        App        = $app.DisplayName
        Type       = "Secret"
        KeyId      = $_.KeyId
        Expires    = $_.EndDateTime
        DaysLeft   = ($_.EndDateTime - (Get-Date)).Days
      }
    }
    $app.KeyCredentials | ForEach-Object {
      [PSCustomObject]@{
        App        = $app.DisplayName
        Type       = "Certificate"
        KeyId      = $_.KeyId
        Expires    = $_.EndDateTime
        DaysLeft   = ($_.EndDateTime - (Get-Date)).Days
      }
    }
  } | Sort-Object DaysLeft

Lire les signaux qui comptent

À partir de cet inventaire, associez les constats à un risque concret :

Confirmer l'usage réel dans les journaux de connexion

Vérifiez comment les identifiants sont réellement utilisés, pas seulement ce qui existe, via les journaux de connexion des service principals. Chaque événement de connexion porte un champ ClientCredentialType : une valeur client secret indique une authentification par mot de passe, tandis que l'authentification par certificat apparaît comme client assertion, accompagnée d'un ClientCredentialKeyID que vous pouvez rapprocher du keyId précis dans la liste d'identifiants de l'application. Ce rapprochement indique quel identifiant est réellement vivant en production, par rapport à ceux qui sont du poids mort que personne n'a retiré — une distinction que l'inventaire brut des identifiants ne peut pas donner à lui seul. Si un identifiant apparaît signalé dans une détection de risque plutôt que dans une connexion de routine, traitez-le comme le recommande Azure Identity Protection : Automatiser la Réponse aux Credentials Divulgués pour tout autre signal d'identifiant divulgué.

Suivre les changements d'identifiants dans le journal d'audit

Pour un suivi historique des changements, filtrez le journal d'audit Entra par Catégorie = ApplicationManagement : les ajouts et suppressions d'identifiants d'application et de service principal sont journalisés comme des modifications de propriété sur la ressource cible, consultables par application — voir la référence des activités du journal d'audit Microsoft Entra. Exportez-les vers un SIEM ou un espace de travail Log Analytics si vous avez besoin d'une rétention plus longue que la fenêtre par défaut du centre d'administration, selon la présentation des journaux d'audit.

Remédiation : faire tourner, restreindre, et sortir des secrets

Inventorier d'abord, faire tourner ensuite

Exécutez la requête Graph ci-dessus sur toutes les applications avant de toucher quoi que ce soit — vous devez savoir quels secrets sont réellement référencés par un workload en production avant de les révoquer. Faire tourner ou supprimer un secret encore utilisé casse le workload qui en dépend, cette étape n'est donc pas optionnelle.

Remplacer, ne pas ajouter

Lors d'une rotation, créez le nouveau secret ou certificat, mettez à jour le workload consommateur, vérifiez qu'il s'authentifie correctement, puis supprimez l'ancien identifiant. Ajouter un nouveau secret en laissant l'ancien « au cas où » est exactement ce qui provoque l'étalement multi-secrets au départ.

Passer aux certificats ou aux identifiants fédérés

Microsoft recommande les certificats plutôt que les client secrets avant qu'une application n'atteigne la production, et les identifiants fédérés là où la plateforme du workload le permet — ce qui élimine le problème de rotation au lieu de simplement mieux le gérer.

Appliquer la norme à l'échelle du tenant

Plutôt que de compter sur l'auto-discipline de chaque propriétaire d'application, imposez des standards d'identifiants via une Application Management Policy. Ces politiques se configurent via Microsoft Graph ou Graph PowerShell (pas d'interface portail) et peuvent plafonner la durée de vie des certificats et bloquer purement et simplement les nouveaux identifiants par mot de passe :

# Requires: Connect-MgGraph -Scopes "Policy.ReadWrite.ApplicationConfiguration"
$policy = @{
  displayName    = "Enforce credential standards"
  isEnabled      = $true
  applications   = @{
    keyCredentials = @(
      @{
        restrictionType = "asymmetricKeyLifetime"
        maxLifetime     = "P180D"
        state           = "enforced"
      }
    )
    passwordCredentials = @(
      @{
        restrictionType = "passwordAddition"
        state           = "enforced"
      }
    )
  }
}
New-MgPolicyAppManagementPolicy -BodyParameter $policy

Consultez le tutoriel sur l'application des standards de secrets et de certificats et la configuration des restrictions de politique de gestion des applications pour la liste complète des types de restrictions disponibles, y compris le ciblage d'une politique sur des applications spécifiques ou sur tout le tenant.

Assigner un propriétaire et réviser sur une cadence régulière

Un identifiant que personne ne possède est un identifiant que personne ne fait tourner ni ne révoque quand il le faudrait. Associez la propriété à une revue récurrente de la requête d'inventaire ci-dessus — au minimum mensuelle pour les applications détenant des permissions Graph privilégiées.

Vérifier la confiance du certificat, pas seulement son expiration

Pour le CBA en particulier, confirmez que les certificats actifs proviennent d'une autorité de certification de confiance selon vos bonnes pratiques de sécurité pour les propriétés d'App Registration, et non d'un certificat auto-signé dont plus personne ne se souvient de l'émission.

Lecture connexe : Certificat de signature SAML Entra expiré : pourquoi la connexion fédérée tombe en panne couvre ce qui se passe quand un autre type de certificat — la signature SAML — est laissé expirer sans surveillance, et Comment auditer la sécurité Microsoft Entra ID (Azure AD) : guide pratique détaille la revue des permissions applicatives dans le cadre d'un audit de tenant plus large.

Comment EtcSec détecte cela

L'audit Entra d'EtcSec vérifie directement les identifiants des applications et des service principals via Microsoft Graph à chaque scan. APP_NO_CREDENTIAL_ROTATION signale les applications dont les identifiants sont devenus périmés sans activité de remplacement ; APP_SECRET_LONG_EXPIRY et APP_SECRET_EXPIRED détectent les secrets configurés avec une durée de vie excessive ou déjà passés leur endDateTime ; APP_MULTIPLE_SECRETS révèle l'étalement d'identifiants dû à une rotation additive ; SP_STALE_CREDENTIAL étend le même contrôle aux service principals ; et CBA_CERTIFICATES_ACTIVE inventorie chaque application s'appuyant actuellement sur l'authentification par certificat, afin que vous puissiez vérifier la confiance et l'expiration délibérément plutôt que de le découvrir au moment de la panne.