MSP FAQ: cómo gobernar el acceso entre tenants sin un administrador todopoderoso

Un modo de fallo habitual en las operaciones de los MSP es una cuenta de técnico o de automatización con derechos de administrador permanentes en todos los inquilinos de los clientes: un "administrador todopoderoso" que convierte una credencial comprometida en una brecha de toda la base de clientes. El modelo de privilegios de administración delegada granular (GDAP) de Microsoft, creado para su propio ecosistema de partners, ilustra la alternativa.

Qué cambia GDAP

Antes de GDAP, los agentes de administración de un partner podían asumir de forma indefinida un rol de administrador global en el inquilino de un cliente. GDAP lo sustituye por un acceso que es a la vez granular —limitado a roles administrativos específicos— y con límite temporal, y exige que el cliente conceda ese acceso de forma explícita en lugar de heredarlo automáticamente. La propia guía de roles de Microsoft va más allá y asigna cada tarea administrativa al rol integrado con menos privilegios capaz de realizarla, en lugar de recurrir por defecto a un rol de administrador amplio porque resulta cómodo.

Aplicar el mismo modelo más allá de Microsoft 365

El patrón GDAP se generaliza a cualquier pila SaaS que un MSP gestione en nombre de un cliente: cada inquilino de cliente debe ser su propia frontera de gobernanza, las identidades de técnicos y de automatización deben ser distintas, y el acceso elevado debe caducar en lugar de persistir. Un hilo del foro de MSP del Non-Human Identity Management Group plantea el riesgo subyacente con claridad: un aislamiento deficiente entre inquilinos convierte la comodidad operativa en riesgo compartido para todos los clientes de la plataforma.

Una lista de comprobación práctica

• Ningún rol de administrador global permanente, ni equivalente, que abarque todos los inquilinos de los clientes.
• Limitar los roles de partner o técnico por cliente y revisarlos con una periodicidad fija.
• Mantener una vía de emergencia independiente con elevación de privilegios limitada en el tiempo y vinculada a un ticket.
• Dar a la automatización su propia identidad con privilegios mínimos, distinta de la de cualquier técnico.
• Conservar registros de auditoría por inquilino que se puedan consultar por cliente.

La lección se generaliza más allá de Microsoft 365: sea cual sea la plataforma que un MSP utilice para acceder a los inquilinos de los clientes, el acceso debe ser limitado, con caducidad y por cliente, no una única identidad de administrador que abra todas las puertas.

Fuentes: Microsoft Learn — Introducción a GDAP, Non-Human Identity Management Group — Gestión SaaS multiinquilino para MSP.