Cuenta de servicio o entidad de servicio en Power Automate

Cuando un flujo se ejecuta en producción, la elección de la identidad subyacente determina si sigue funcionando incluso cuando una compañera está enferma, caduca una contraseña o alguien deja la empresa. Precisamente aquí surge una y otra vez la misma pregunta en Power Automate: ¿debe ejecutarse un flujo bajo una cuenta de servicio clásica, es decir, una cuenta de usuario compartida, o bajo una entidad de servicio, es decir, una identidad independiente y no humana en Microsoft Entra ID?

La respuesta breve de la documentación oficial es clara: Microsoft recomienda la entidad de servicio para flujos de producción críticos para el negocio y no clasifica explícitamente la cuenta de servicio clásica como práctica recomendada. Aun así, merece la pena examinar de cerca ambos modelos, ya que funcionan técnicamente de forma distinta y conllevan requisitos diferentes.

¿Qué es una cuenta de servicio en Power Automate?

Según la documentación de Microsoft sobre licencias de Power Automate una cuenta de servicio es una cuenta de usuario de Microsoft Entra completamente normal que se reutiliza para representar una entidad no humana, como una aplicación o un servicio. En la práctica, esto significa que un equipo crea una cuenta como flow-produccion@empresa.es, comparte la contraseña con varias compañeras y compañeros, y esta cuenta pasa a ser propietaria de los flujos de producción.

Microsoft señala directamente el problema: si varias personas tienen acceso a la misma cuenta, resulta casi imposible saber quién realizó qué cambio en un flujo. A esto se suma la gestión de contraseñas como tema recurrente, por ejemplo con cambios de contraseña forzados o inicios de sesión multifactor. Por ello, Microsoft recomienda explícitamente revisar periódicamente los permisos de las cuentas de servicio existentes, mantener el círculo de personas con acceso lo más reducido posible y usar cuentas separadas para escenarios distintos con el fin de reducir la superficie de ataque. En algunos casos se utiliza una cuenta de servicio para hacer que un flujo sea independiente de su creador original. Pero para ese propósito concreto, Microsoft recomienda explícitamente cambiar a una entidad de servicio.

¿Qué es una entidad de servicio?

Según la documentación de Microsoft sobre la compatibilidad con flujos propiedad de una entidad de servicio una entidad de servicio es una identidad de seguridad no humana que representa una aplicación o un servicio y puede poseer y administrar recursos de forma independiente en Azure y en Power Platform. Técnicamente, se basa en un registro de aplicación de Microsoft Entra. Para que una entidad de servicio pueda ser propietaria de flujos en Power Platform, primero debe crearse un llamado usuario de aplicación, ya sea a través del centro de administración de Power Platform o mediante la API.

Una vez configurado este usuario de aplicación, se le puede transferir la propiedad de un flujo en la nube: en el flujo, abres la sección Detalles, seleccionas Editar y sustituyes al propietario por el nombre del usuario de aplicación. Importante: según la documentación, una entidad de servicio no puede convertirse en copropietaria de un flujo, sino únicamente en propietaria exclusiva. En un flujo fuera de una solución, además, todas las conexiones utilizadas deben compartirse explícitamente con el usuario de aplicación; en un flujo de solución, este paso no es necesario.

Cuenta de servicio o entidad de servicio: la guía de decisión

Para el día a día, la decisión puede basarse en criterios claros, tal y como también describe la documentación de Microsoft sobre el acceso a los flujos de Power Automate:

• Flujos críticos para el negocio o de toda la empresa: aquí Microsoft recomienda explícitamente la entidad de servicio, porque así la propiedad del flujo queda totalmente desacoplada del ciclo de vida de una persona concreta. Si alguien deja la empresa o cambia de rol, el flujo permanece intacto.
• Canalizaciones de DevOps en varios entornos: quien despliegue flujos de forma automatizada de desarrollo a pruebas y luego a producción debería, según la documentación, apostar también por la entidad de servicio, ya que se puede administrar de forma limpia a través de la API.
• Auditabilidad: una entidad de servicio deja un rastro de auditoría claro e independiente de las personas. Con una cuenta de servicio compartida, a menudo no queda claro quién cambió qué y cuándo.
• Flujos interactivos o específicos de usuario: si un flujo necesita el contexto personal de una persona, por ejemplo para aprobaciones o permisos personalizados, una cuenta de usuario normal sigue siendo la opción correcta, ni una cuenta de servicio ni una entidad de servicio.
• Cuentas de servicio existentes: si quieres cambiar un flujo en ejecución de una cuenta de servicio a una entidad de servicio, deberías también comprobar los límites de licencias y solicitudes; más sobre esto a continuación.

No subestimes las licencias y los límites de solicitudes

Una entidad de servicio que es propietaria de un flujo se considera en Power Automate un usuario de aplicación no interactivo y, por tanto, no puede recibir una licencia de usuario habitual. En su lugar, se aplican límites de solicitudes propios y sin licencia, y en cuanto el flujo utiliza conectores premium, necesita una licencia de proceso de Power Automate o una licencia por flujo, o bien la pertenencia a un grupo de flujos con la licencia correspondiente.

En cambio, para una cuenta de servicio clásica se aplica la lógica de licencias habitual para cuentas de usuario, complementada con una regla especial contra el llamado multiplexado: si varias personas comparten las credenciales de una cuenta de servicio y el flujo usa funciones premium, la documentación recomienda una licencia de proceso para el flujo en cuanto muchas personas distintas usen la cuenta, para que los nuevos usuarios que se añadan cumplan automáticamente con las licencias. No hay que confundir la cuenta de servicio con las cuentas de usuario no interactivas que Dataverse prevé para procesos en segundo plano, como las migraciones de datos: de estas se permiten un máximo de siete por inquilino, y Power Automate en sí aún no admite este tipo de cuenta especial como propietaria de un flujo, según la documentación.

¿Y qué pasa con la identidad administrada?

Quien venga del mundo de Azure pensará rápidamente, para identidades no humanas, en las identidades administradas, es decir, identidades asignadas por el sistema o por el usuario que hacen completamente innecesarias las credenciales. Sin embargo, para los flujos en la nube de Power Automate este concepto no es, por ahora, una opción directa: las identidades administradas están ancladas sobre todo en Azure Logic Apps, donde ciertos conectores integrados y administrados, como Azure Key Vault, Azure Blob Storage o Azure SQL, pueden autenticarse a través de ellas. En el propio Power Automate, la entidad de servicio asume la tarea comparable de dar a un flujo una identidad estable, independiente de personas concretas. Quien opere flujos y Logic Apps en paralelo debería tener presente esta diferencia en lugar de equiparar mentalmente ambos conceptos.

La transición en la práctica: de la cuenta de servicio a la entidad de servicio

El cambio se realiza en tres pasos: primero, creas un registro de aplicación en Microsoft Entra ID y, a partir de él, creas un usuario de aplicación en Power Platform. A continuación, compartes explícitamente con este usuario de aplicación todas las conexiones que utiliza el flujo, salvo que se trate de un flujo de solución. Por último, cambias en el flujo el propietario al nuevo usuario de aplicación y vuelves a activar el flujo. Reserva para este último paso una breve prueba antes de desactivar la cuenta de servicio anterior, para que los procesos productivos no se queden sin efecto.

Quien no quiera llevar a cabo por su cuenta la migración de varios flujos de producción de cuentas de servicio a entidades de servicio encontrará apoyo en la oferta de Power Automate de NordFlux, desde la configuración del registro de aplicación hasta la protección de la estructura de licencias y permisos. Así conservas el control sobre quién posee y opera cada automatización, incluso a medida que crece tu panorama de flujos.

Preguntas frecuentes

¿Está prohibida una cuenta de servicio para flujos de producción?

No está prohibida, pero Microsoft no la clasifica explícitamente como práctica recomendada. Para flujos críticos para la empresa o de larga duración, la documentación recomienda claramente en su lugar la entidad de servicio, porque no depende de personas concretas ni de contraseñas compartidas.

¿Puede una entidad de servicio ser copropietaria de un flujo?

No. Según la documentación, un usuario de aplicación de entidad de servicio solo puede ser propietario exclusivo de un flujo, nunca copropietario. Por eso ni siquiera aparece en el cuadro de diálogo de edición de copropietarios.

¿Necesita una entidad de servicio su propia licencia de Power Automate?

Una entidad de servicio es un usuario de aplicación no interactivo y, por tanto, no puede recibir una licencia de usuario habitual. En cuanto el flujo utiliza conectores premium, necesita en su lugar una licencia de proceso de Power Automate o una licencia por flujo, o la pertenencia a un grupo de flujos con la licencia adecuada.

¿Se puede usar también la identidad administrada en Power Automate?

No directamente para poseer un flujo en la nube. Las identidades administradas son ante todo un concepto de Azure Logic Apps para la autenticación frente a determinados recursos de Azure. En Power Automate, la entidad de servicio asume el papel comparable de una identidad de flujo estable y no humana.

¿Qué ocurre con las conexiones existentes al cambiar de propietario?

Las conexiones no pasan automáticamente al nuevo propietario. Si se trata de un flujo fuera de una solución, debes además compartir explícitamente todas las conexiones utilizadas con el nuevo usuario de aplicación de la entidad de servicio; de lo contrario, la ejecución fallará. En un flujo de solución, este paso no es necesario, según la documentación.