FAQ MSP : un secret de service principal permanent n'est pas une identité workload

Les comptes d’automatisation et les intégrations s’authentifient souvent avec un secret client de principal de service : une longue chaîne, valable pendant des mois, que tout script ou ingénieur y ayant accès peut utiliser pour agir en tant que cette identité. Ajouter une authentification multifacteur au côté humain d’un compte n’y change rien ; le secret lui-même reste un identifiant permanent avec son propre rayon d’impact.

Pourquoi les secrets clients sont considérés comme hérités

Les recommandations de Microsoft sont explicites : les principaux de service avec secrets clients doivent être traités comme une approche héritée, à remplacer par des identités managées ou fédérées partout où l’environnement d’hébergement le permet. Un secret client ne devrait exister que lorsqu’une charge de travail ne peut réellement pas utiliser un identifiant plus robuste. Le problème n’est pas que les secrets sont impossibles à sécuriser — c’est qu’ils doivent être stockés quelque part, renouvelés selon un calendrier et révoqués manuellement en cas de fuite, et chacune de ces étapes est une occasion d’erreur.

Ce que supprime la fédération d’identité de charge de travail

La fédération d’identité de charge de travail permet à une charge de travail externe — un pipeline CI/CD, un cluster Kubernetes, un script exécuté hors d’Azure — de faire confiance aux jetons de son propre fournisseur d’identité et de les échanger contre des jetons d’accès Microsoft Entra à courte durée de vie, sans qu’aucun secret ne soit jamais généré, stocké ou renouvelé. La comparaison des trois modèles par Microsoft est directe : les principaux de service fédérés et les identités managées sont sans secret et fonctionnent aussi bien dans les environnements hébergés, auto-hébergés et sur site, tandis que les principaux de service basés sur des secrets ne sont pas sans secret et conservent le risque opérationnel inhérent à tout identifiant à longue durée de vie.

Pour un MSP gérant plusieurs locataires clients

La dimension locataire compte autant que le type d’identifiant. Un seul principal de service partagé entre plusieurs locataires clients transforme un secret divulgué en incident inter-clients ; l’identité doit être liée à la portée d’un seul locataire, quel que soit le modèle d’identifiant utilisé. Là où la fédération n’est pas encore possible, traitez le secret client comme un risque permanent : recensez où il est utilisé, fixez son expiration à 90 jours ou moins, et planifiez sa suppression une fois la fédération en place.

Sources : Microsoft Learn — Fédération d’identité de charge de travail, Microsoft Learn — Principaux de service et identités managées.