FAQ MSP : comment gouverner les accès entre locataires sans administrateur absolu

Un mode de défaillance courant dans les opérations des MSP est un compte de technicien ou d'automatisation disposant de droits d'administrateur permanents sur chaque locataire client — un « administrateur absolu » qui transforme un seul identifiant compromis en une violation de toute la base de clients. Le modèle Granular Delegated Admin Privileges (GDAP) de Microsoft, conçu pour son propre écosystème de partenaires, illustre l'alternative.

Ce que change GDAP

Avant GDAP, les agents d'administration d'un partenaire pouvaient endosser indéfiniment un rôle d'administrateur global dans le locataire d'un client. GDAP remplace cela par un accès à la fois granulaire — limité à des rôles administratifs précis — et temporaire, et il exige que le client accorde explicitement cet accès plutôt que d'en hériter automatiquement. Les recommandations de rôles de Microsoft vont plus loin, en associant chaque tâche administrative au rôle intégré le moins privilégié capable de l'exécuter, plutôt que de recourir par défaut à un rôle d'administrateur étendu par simple commodité.

Appliquer le même modèle au-delà de Microsoft 365

Le schéma GDAP se généralise à toute pile SaaS qu'un MSP gère pour le compte d'un client : chaque locataire client doit constituer sa propre frontière de gouvernance, les identités des techniciens et de l'automatisation doivent être distinctes, et les accès élevés doivent expirer plutôt que persister. Un fil de discussion du forum MSP du Non-Human Identity Management Group formule clairement le risque sous-jacent : une faible isolation des locataires transforme la commodité opérationnelle en risque partagé pour tous les clients de la plateforme.

Une liste de contrôle pratique

• Aucun rôle d'administrateur global permanent, ou équivalent, couvrant tous les locataires clients.
• Limiter les rôles des partenaires/techniciens par client et les réexaminer selon un calendrier fixe.
• Conserver un chemin de secours distinct avec une élévation temporaire liée à un ticket.
• Donner à l'automatisation sa propre identité à moindre privilège, distincte de celle de tout technicien.
• Conserver des journaux d'audit par locataire, consultables par client.

La leçon se généralise au-delà de Microsoft 365 : quelle que soit la plateforme qu'un MSP utilise pour atteindre les locataires de ses clients, les accès doivent être limités, temporaires et propres à chaque client — et non une identité d'administrateur unique qui ouvre toutes les portes.

Sources : Microsoft Learn — Introduction à GDAP, Non-Human Identity Management Group — gestion SaaS multi-locataire pour les MSP.