FAQ MSP : séparer les accès humains et machines entre les locataires

Les MSP qui gèrent l'accès des techniciens et l'automatisation sur des dizaines de locataires clients font face à une version spécifique d'un problème croissant dans l'industrie : les identités non humaines — comptes de service, clés API, jetons d'automatisation — doivent être gouvernées différemment des humains qui les créent.

Pourquoi les NHI ont besoin d'une gouvernance distincte

Le projet OWASP Non-Human Identity Top 10 note que les identités machines ne sont pas intrinsèquement liées à une personne et que les contrôles de sécurité humains courants, tels que la MFA, ne s'y appliquent pas directement. Le décalage porte principalement sur le cycle de vie : lorsqu'un technicien quitte l'entreprise, son compte est généralement désactivé en quelques heures, mais les comptes de service et les clés API qu'il a créés peuvent continuer à fonctionner avec toutes les permissions, sauf si quelqu'un les trouve et les révoque explicitement. Comme les identités non humaines peuvent largement surpasser les comptes humains dans les environnements modernes, un MSP qui gouverne les deux de la même manière laisse en réalité sa plus grande population d'identités sans gestion.

Préférer les jetons éphémères aux jetons permanents

La recommandation constante de l'OWASP et de la Cloud Security Alliance est de remplacer les secrets à longue durée de vie par des jetons éphémères à courte durée de vie qui expirent automatiquement, plutôt que par des identifiants qui fonctionnent indéfiniment une fois émis. Un jeton à longue durée de vie divulgué donne à un attaquant un temps illimité ; un jeton qui expire en quelques minutes ou heures limite les dégâts même en cas de fuite.

Ce que cela implique dans le modèle de locataires d'un MSP

• Utiliser des fournisseurs d'identité ou des principaux de service distincts pour les techniciens humains et pour l'automatisation.
• Ne jamais laisser un identifiant de secours d'un technicien servir également de identifiant de service pour un pipeline.
• Lier les jetons machines à un seul locataire client — ne jamais émettre une clé permanente qui couvre tous les locataires.
• Maintenir les durées de vie des jetons mesurées en minutes ou en heures, et les renouveler à chaque changement de personnel ou d'automatisation.
• Journaliser la classe d'identité (humaine ou non humaine) avec l'ID du locataire sur chaque enregistrement d'accès.

La solution ne réside pas dans un outil unique, mais dans une habitude de gouvernance : traiter l'automatisation comme une population d'identités à part entière, avec son propre périmètre de moindre privilège par locataire, plutôt que comme une extension du technicien qui l'a configurée.

Sources : OWASP Non-Human Identities Top 10, Cloud Security Alliance — Defining Non-Human Identity.