Secrets, certificats et informations d'identification fédérées : l'hygiène des applications Entra ID
Une application dotée d'autorisations Graph étendues vaut autant qu'un compte d'administrateur, et ses identifiants sont souvent bien moins protégés. Secrets oubliés dans un dépôt de code, certificats sans propriétaire, identifiants ajoutés discrètement à une application existante : c'est un terrain que les attaquants connaissent bien.
Trois types d'identifiants
Une application qui s'authentifie en son nom propre auprès d'Entra ID doit prouver son identité. Trois mécanismes sont disponibles :
- Le secret client : une chaîne de caractères, équivalente à un mot de passe. Simple à utiliser, simple à copier, simple à divulguer.
- Le certificat : l'application signe une assertion avec sa clé privée. La clé peut être conservée dans un coffre (Azure Key Vault, HSM) sans jamais être exposée en clair.
- L'identifiant fédéré (fédération d'identité de charge de travail) : l'application présente un jeton émis par un fournisseur de confiance, comme GitHub Actions, un cluster Kubernetes ou un autre fournisseur d'identité, échangé contre un jeton Entra ID. Aucun secret n'est stocké.
L'ordre de préférence est clair : identité managée lorsque le code tourne dans Azure, identifiant fédéré lorsque la plateforme le permet, certificat sinon, et secret client en dernier recours.
Expiration et renouvellement
Le portail limite la durée des secrets clients, mais des durées plus longues peuvent encore exister dans des locataires anciens ou avoir été créées par API. Les stratégies de gestion des applications permettent d'imposer des règles à l'échelle du locataire : durée maximale des secrets et certificats, voire interdiction des secrets pour les nouvelles applications. Les conditions de licence de cette fonctionnalité évoluent ; vérifiez-les pour votre contrat.
L'expiration a deux faces. Trop longue, elle laisse un identifiant volé exploitable pendant des années. Mal suivie, elle provoque des pannes le jour où le secret expire. Il faut donc un suivi : inventaire des dates d'expiration, alertes en amont, et un responsable identifié pour chaque renouvellement.
Les propriétaires, un chemin d'escalade
Les propriétaires d'une inscription d'application peuvent lui ajouter des identifiants. Si l'application dispose d'autorisations élevées, par exemple RoleManagement.ReadWrite.Directory ou Application.ReadWrite.All, un simple propriétaire peut s'authentifier en tant qu'application et exercer ces droits. Il en va de même pour les rôles d'administrateur d'applications et d'administrateur d'applications cloud, qui peuvent gérer les identifiants de toutes les applications.
Règle pratique. Les propriétaires d'une application privilégiée doivent être traités comme des administrateurs privilégiés. Une application capable d'accorder des rôles fait partie du niveau 0, et ses propriétaires aussi.
Les identifiants posés sur les principaux de service
Un identifiant peut être ajouté à l'objet application (visible dans les inscriptions d'applications) ou directement au principal de service de l'application dans le locataire. Ce second cas n'apparaît pas dans le panneau habituel « Certificats et secrets », et c'est précisément pour cela que des attaquants l'ont utilisé pour maintenir un accès discret à des applications existantes, y compris multilocataires.
Points de vigilance :
- inventorier via Microsoft Graph les identifiants présents sur les principaux de service, pas seulement sur les applications ;
- surveiller dans le journal d'audit les opérations d'ajout d'identifiants sur les applications et principaux de service ;
- pour vos propres applications multilocataires, activer le verrouillage des propriétés d'instance d'application, qui empêche l'ajout d'identifiants à leurs principaux de service dans les autres locataires ;
- examiner avec une attention particulière tout identifiant présent sur un principal de service d'application tierce ou Microsoft : la situation légitime est rare.
Où vivent les secrets
Un secret bien configuré dans Entra ID peut être compromis par la façon dont il est stocké. Nous en retrouvons dans des fichiers de configuration, des variables de pipeline en clair, des dépôts Git, des scripts partagés. La bonne pratique consiste à stocker secrets et certificats dans un coffre, à en restreindre l'accès aux seules charges de travail concernées, et à analyser régulièrement les dépôts de code à la recherche d'identifiants divulgués.
Ce qu'un audit vérifie
- La répartition des types d'identifiants : secrets, certificats, identifiants fédérés.
- Les durées de validité et les identifiants expirés ou proches de l'expiration.
- Les stratégies de gestion des applications en place.
- Les propriétaires des applications privilégiées et les titulaires des rôles d'administration d'applications.
- Les identifiants présents sur les principaux de service, en particulier d'applications tierces.
- La surveillance des ajouts d'identifiants dans les journaux d'audit.