← Todas las noticias
ARTÍCULO
22 de septiembre de 2026 Actualizado el 13 de octubre de 2026 2 min de lectura

MSP FAQ: un secreto de entidad de servicio no es identidad de carga

Añadir MFA a una cuenta de automatización no elimina el riesgo de un secreto de cliente. La propia guía de Microsoft favorece la federación de identidades de carga de trabajo.

En este artículo
  1. Por qué los secretos de cliente se consideran un enfoque heredado
  2. Qué elimina la federación de identidades de carga de trabajo
  3. Para un MSP que gestiona muchos inquilinos de clientes

Las cuentas de automatización y las integraciones pueden autenticarse con un secreto de cliente de entidad de servicio que cualquier script o ingeniero con acceso a él puede usar para actuar como esa identidad. Añadir autenticación multifactor al lado humano de una cuenta no cambia eso; el secreto en sí sigue siendo una credencial con su propio radio de impacto.

Foto: Cromemco System Three in United Solder-Wrap Workstation
Foto: Cromemco System Three in United Solder-Wrap Workstation.jpg. Cromemco (CC BY-SA 4.0), Wikimedia Commons. https://commons.wikimedia.org/wiki/File%3ACromemco_System_Three_in_United_Solder-Wrap_Workstation.jpg https://creativecommons.org/licenses/by-sa/4.0/

Por qué los secretos de cliente se consideran un enfoque heredado

La propia guía de Microsoft es explícita: las entidades de servicio con secretos de cliente pueden sustituirse por identidades administradas o federadas siempre que el entorno de alojamiento lo admita. Un secreto de cliente solo debería existir cuando una carga de trabajo realmente no pueda usar una credencial más sólida. El problema no es que los secretos sean imposibles de proteger, sino que tienen que almacenarse en algún lugar y rotarse según un calendario, y cada uno de esos pasos es un punto donde puede producirse un error.

Qué elimina la federación de identidades de carga de trabajo

La federación de identidades de carga de trabajo permite que una carga de trabajo externa —un pipeline de CI/CD, un clúster de Kubernetes, un script que se ejecuta fuera de Azure— confíe en tokens de su propio proveedor de identidad y los intercambie por tokens de acceso de Microsoft Entra de corta duración, sin que se genere, almacene o rote ningún secreto. La comparación de Microsoft de los tres modelos es directa: las entidades de servicio federadas y las identidades administradas no usan secretos, mientras que las entidades de servicio basadas en secretos no están libres de secretos y siguen arrastrando el riesgo operativo que conlleva cualquier credencial.

Para un MSP que gestiona muchos inquilinos de clientes

La dimensión del inquilino importa tanto como el tipo de credencial. Donde la federación aún no sea posible, trate el secreto de cliente como un riesgo: programe su eliminación una vez que la federación esté implantada.

Fuentes: Microsoft Learn — Federación de identidades de carga de trabajo, Microsoft Learn — Entidades de servicio e identidades administradas.