Compartir a través de

Guía para compartir flujos de nube y permisos

Esta guía puede ayudar a identificar escenarios adecuados de uso compartido de flujos y establecer permisos para administrar el acceso de los usuarios y garantizar la seguridad.

Administrar usuarios, permisos y roles en entornos de Power Automate

Administrar quién puede crear, editar o simplemente ejecutar flujos es fundamental para mantener un entorno de Power Automate seguro y ordenado. El modelo de seguridad de Power Automate opera en varios niveles de permisos:

  • Roles de entorno a nivel de ambiente (como Administrador de ambiente y Creador de ambiente): rigen la capacidad de un usuario para administrar o crear recursos en un ambiente determinado.
  • Roles de seguridad de Dataverse (si el ambiente tiene una base de datos de Dataverse): como Usuario Básico, Personalizador del Sistema y otros, que controlan el acceso a los datos y entidades. Por ejemplo, los usuarios suelen necesitar al menos el rol de usuario básico para ejecutar aplicaciones o flujos que usan datos de Dataverse.
  • Permisos de nivel de flujo: compartir la configuración de flujos individuales para que otros usuarios sean copropietarios (con derechos de edición) o usuarios de solo ejecución.

Funciones y seguridad del entorno

En cada ambiente, solo los usuarios con los roles adecuados pueden crear o administrar recursos.

  • Administrador del ambiente: tiene control administrativo total sobre el ambiente. Un administrador de ambiente puede administrar todos los recursos, incluida la visualización de todos los flujos, la adición y eliminación de usuarios y el establecimiento de políticas. En ambientes sin Dataverse, solo este rol puede realizar tareas administrativas. En ambientes habilitados de Dataverse, un rol de administrador del sistema en Dataverse tiene un propósito similar para las operaciones de datos.

  • Creador de ambiente: este rol permite a los usuarios crear nuevos recursos como flujos, aplicaciones y conexiones en el ambiente. El rol de Creador de entorno no otorga acceso a los datos existentes en Dataverse, solo confiere la capacidad de crear y compartir artefactos. Microsoft sigue un modelo de privilegios mínimos para roles predefinidos: El creador de entorno tiene el acceso mínimo necesario para crear aplicaciones o flujos sin exponer datos que no se les permite mostrar. Los creadores pueden compartir las aplicaciones o los flujos que crean con otros miembros de la organización según sea necesario, pero no pueden elevar sus propios privilegios para leer datos a menos que se les asignen roles adicionales de Dataverse.

  • Usuario del entorno (usuario básico): en los entornos respaldados de Dataverse, los usuarios finales habituales deben tener el rol de seguridad de usuario básico (a veces denominado usuario de Common Data Service) para ejecutar aplicaciones o utilizar flujos que interactúan con los datos de Dataverse. De forma predeterminada, agregar un usuario a un entorno, especialmente si el entorno tiene una base de datos de Dataverse, puede requerir la asignación explícita de dicho rol. Esto garantiza que puedan ejecutar las soluciones, pero solo con privilegios básicos sobre los datos. En entornos sin Dataverse, si se comparte un flujo con un usuario de solo ejecución, es posible que no aparezca en la lista de usuarios del entorno a menos que se agregue manualmente. Sus permisos son únicamente a través del uso compartido de flujos.

Permisos de uso compartido en el nivel de flujo

En el nivel de flujo individual, los propietarios pueden compartir un flujo de nube de dos maneras principales: agregar copropietarios o asignar usuarios de solo ejecución. Es esencial entender la diferencia.

  • Propietario/copropietario: un copropietario tiene esencialmente los mismos privilegios que el creador original del flujo. Los copropietarios pueden ver el historial de ejecución, editar el diseño del flujo, cambiar su configuración, iniciar y detener el flujo, administrar conexiones y agregar o quitar otros propietarios. En otras palabras, el control total se le da a cualquier copropietario, excepto que no pueden eliminar al creador original. Los copropietarios también muestran el flujo en su lista de flujos de equipo y pueden administrarlo como cualquier flujo que hayan creado ellos mismos. Debido a la amplitud de estos permisos, solo se deben agregar personas o grupos de confianza como copropietarios.

    Ejemplo: si Alice es copropietaria del flujo de Bob, Alice puede modificarlo o eliminarlo, por lo que el equipo de Bob solo debe agregar a Alice si se pretende tener dicho acceso.

  • Usuario de solo ejecución: un usuario de solo ejecución está restringido a ejecutar el flujo, normalmente a través de un desencadenador manual como un botón o elementos de SharePoint. No pueden abrir el flujo en modo de edición, ver su lógica interna ni ver el historial de ejecuciones anteriores. Esto es ideal para escenarios en los que se desea que los compañeros se beneficien de la automatización. Por ejemplo, ejecute un flujo de botón o una tarea de procesamiento de datos instantáneos sin darles privilegios de diseño. Los usuarios de solo ejecución muestran el nombre del flujo y pueden ejecutarlo, pero si intentan inspeccionar los detalles, la visibilidad es limitada. Tampoco pueden agregar otros ni alterar el flujo de ninguna manera.

    Ejemplo: Un departamento de soporte técnico tiene un flujo de botón de Power Automate para Crear ticket y enviar confirmación. Todos los empleados de primera línea se agregan como usuarios de solo ejecución para que puedan desencadenar el flujo desde sus dispositivos, pero no puedan cambiar lo que hace el flujo.

Seguridad específica de recursos frente a roles de ambiente

Los roles de ambiente y los permisos de uso compartido de flujos funcionan en conjunto. Ser administrador de ambiente o tener ciertos privilegios de Dataverse puede permitir a los usuarios ver o modificar flujos independientemente de que se compartan explícitamente, debido a su amplio acceso.

  • Un administrador de Power Platform o administrador de ambiente puede mostrar y administrar inherentemente todos los flujos del ambiente, incluso si no se comparten individualmente con ellos. Por ejemplo, un administrador global puede agregarse como propietario a cualquier flujo si es necesario.
  • Por el contrario, a un usuario sin rol en el ambiente se le puede dar acceso a un flujo específico mediante el uso compartido. En este caso, ese usuario se convierte en un participante de caso especial en ese flujo, pero es posible que no tenga acceso a otros recursos del ambiente.

Para administrar los permisos de manera eficaz, las organizaciones deben formalizar qué usuarios son creadores de flujo (creadores) y cuáles son consumidores* de flujo (ejecutores) y, a continuación, aplicar los roles en consecuencia. En las secciones siguientes se explican los procedimientos recomendados para implementar estas distinciones y minimizar el riesgo.

Niveles de permisos en Power Automate: propietarios frente a usuarios de solo ejecución

Un aspecto clave de la administración de la seguridad del flujo es comprender las capacidades de los diferentes niveles de permisos de uso compartido. En la siguiente tabla se resumen las diferencias entre copropietarios y usuarios de solo ejecución para un flujo de nube. Compara los permisos y las capacidades de los copropietarios del flujo con los de los usuarios de solo ejecución en Power Automate.

Capacidad / Acceso Copropietario (puede editar) Usuario de solo ejecución (puede ejecutar)
Ver y editar definición de flujo Sí. Tiene acceso completo para ver y modificar los pasos, la configuración y las conexiones del flujo. No. No se puede abrir el flujo en el editor ni obtener su configuración. Solo obtienen la interfaz de ejecución.
Ejecutar/Desencadenar el flujo Sí. Puede ejecutar manualmente el flujo y modificar los desencadenadores. Sí. Puede desencadenar el flujo (por ejemplo, seleccionar el botón o usar la acción de desencadenador designada) según lo permita el propietario del flujo.
Ver historial de ejecución (registros de ejecución) Sí. Puede ver las ejecuciones anteriores, el estado de éxito y error, y los resultados en el historial de ejecución. No. No se puede mostrar el historial de ejecución del flujo ni los detalles de ejecuciones anteriores.
Administrar flujo (habilitar/deshabilitar, cambiar nombre, eliminar) Sí. Puede cambiar las propiedades del flujo, activarlo o desactivarlo, actualizar las conexiones y eliminar el flujo por completo. No. No se pueden realizar cambios en el estado o la configuración del flujo. Solo tienen permiso para invocarlo.
Compartir el flujo con otros Sí. Pueden agregar o quitar otros copropietarios, excepto que no pueden quitar al creador original. También puede asignar usuarios de solo ejecución. No. No se puede compartir el flujo con nadie más. Es un beneficiario del acceso, no un otorgante de acceso.
Utilizar conexiones propias (invocador) N/D. Los copropietarios utilizan las conexiones definidas del flujo. Pueden actualizar las conexiones si es necesario. Depende. Es posible que los usuarios de solo ejecución deban usar sus propias conexiones cuando se ejecutan si el flujo está configurado con Proporcionado por un usuario de solo ejecución para un conector. De lo contrario, el flujo utiliza las conexiones del propietario.
Visibilidad en la interfaz de usuario de Power Automate Aparece en Flujos de equipo para todos los propietarios. El nombre del copropietario aparece en la Lista de Propietarios. Aparece en la lista de usuarios de Solo ejecución del flujo (página de detalles del flujo) para los propietarios; sin embargo, los usuarios de solo ejecución obtienen el flujo solo en contextos en los que pueden ejecutarlo (por ejemplo, en un botón o dentro de una aplicación; no aparece en sus flujos propios o de equipo).

En la práctica, estas distinciones significan que los copropietarios deben limitarse a los usuarios que realmente necesitan colaborar en el diseño o el mantenimiento de un flujo, mientras que el uso compartido de solo ejecución es preferible para una amplia distribución de la funcionalidad de un flujo. La guía de Microsoft refuerza esto: "Solo agregue copropietarios para la colaboración de flujo según sea necesario. En la mayoría de los casos, si es necesario compartir un flujo, compártalo con permisos de solo ejecución. Esto garantiza que los usuarios puedan beneficiarse de la automatización sin correr el riesgo de realizar modificaciones no autorizadas o exponer los componentes internos del flujo.

Mitigar los riesgos de compartir flujos fuera de su entorno

Permitir que los usuarios que no son miembros del entorno accedan a los flujos puede presentar algunos riesgos:

  • Puntos ciegos de gobernanza: es posible que los administradores no se den cuenta de quién tiene acceso.
  • Posible exposición de datos: si los flujos manejan datos confidenciales.
  • Acceso de solo ejecución: podría ser un problema si los desencadenadores permiten la visibilidad de entrada o salida de parámetros y la pérdida de control de cambios. Esto ocurre cuando los copropietarios ajenos al equipo realizan ediciones no deseadas.

Para mitigar estos riesgos, las organizaciones deben adoptar una combinación de directivas, controles técnicos y supervisión.

  • Aplicar controles de acceso al ambiente: una práctica recomendada fundamental es restringir la pertenencia al ambiente mediante grupos de seguridad Microsoft Entra (Azure AD). Al asociar un grupo de seguridad a un ambiente, solo los usuarios de ese grupo pueden agregarse a los roles delambiente. Esto significa que incluso si un creador intenta compartir un flujo con alguien fuera del grupo, esa persona no se agrega al ambiente automáticamente. En ambientes con un grupo de seguridad asociado, cualquier usuario que no esté en el grupo es esencialmente un externo y tiene capacidades limitadas hasta que un administrador concede acceso. Esta configuración impide que personas ajenas accedan a los recursos del ambiente, a menos que un administrador los agregue explícitamente al grupo de seguridad por directiva.

    Por ejemplo, si el entorno HR Apps de Contoso está vinculado al grupo de seguridad de HR-Team, un usuario de Finanzas no puede convertirse en copropietario de un flujo en HR Apps a menos que un administrador lo agregue primero al grupo. El uso de grupos de seguridad de esta manera ayuda a las organizaciones a mantener un límite claro de quién está aprobado para usar cada entorno de HR-Team.

  • Revise y limite la copropiedad: el intercambio de flujos con los copropietarios debe hacerse con moderación. Cada copropietario se convierte efectivamente en propietario de pleno derecho del flujo, por lo tanto, limite el número de copropietarios a solo los necesarios. Si un flujo se compartió con una persona externa, por ejemplo, un desarrollador o un consultor de otro equipo para solucionar problemas, asegúrese de eliminar su copropiedad después de que se resuelva el problema. Hazlo a menos que haya una necesidad continua. Las organizaciones pueden implementar procesos de gobernanza en los que la adición de un copropietario fuera del entorno desencadena una alerta o requiere aprobación. Esto se puede lograr mediante el uso de herramientas de gobernanza de Power Automate (por ejemplo, un flujo de administración que usa los conectores de Power Platform de administración para detectar cuándo se agrega un nuevo propietario a un flujo). A continuación, notifican al departamento de TI o a un equipo del Centro de excelencia de Power Platform.

  • Prefiera compartir solo ejecución para usuarios externos: si compartir con usuarios que no son miembros del entorno es inevitable o está justificado, use permisos de solo ejecución siempre que sea posible en lugar de derechos de edición completos. El acceso de solo ejecución reduce significativamente el riesgo: el usuario no puede ver la lógica de flujo ni modificarla, y obtiene datos de ejecución anteriores, que pueden contener cargas útiles confidenciales.

    Por ejemplo, si un flujo envía datos de clientes a través de correo electrónico, un usuario de solo ejecución puede desencadenar ese envío de correo electrónico, pero no puede abrir el flujo para obtener los detalles del cliente que se procesaron ayer. Este principio se alinea con el privilegio mínimo: otorgar el acceso mínimo necesario para el rol del usuario. El uso compartido de solo ejecución a menudo puede lograr el requisito empresarial de permitir que alguien desencadene o utilice un flujo sin ceder el control.

  • Usar roles de seguridad para segmentar tareas: asegúrese de que los usuarios que solo deben ejecutar flujos, pero no crearlos, no tengan el rol de Creador de entorno. Al mantener a estos usuarios como usuarios básicos del entorno, o completamente fuera del entorno con solo acceso a flujos de solo ejecución, se reduce la posibilidad de que puedan crear o importar flujos no autorizados. Solo los creadores designados deben tener privilegios de creador, mientras que otros pueden consumir solo las salidas de los flujos.

    Obtenga más información en Usar roles y grupos de seguridad: administrar creadores frente a usuarios de solo ejecución.

  • Implementar políticas de prevención de pérdida de datos (DLP): aunque las políticas DLP tienen más que ver con el control del uso de conectores, ayudan indirectamente a mitigar el riesgo al evitar que los flujos compartidos usen conectores prohibidos. Por ejemplo, si a un usuario externo se le otorga acceso de solo ejecución a un flujo, una directiva DLP estricta garantiza que el flujo no pueda comenzar a insertar datos repentinamente en un servicio no autorizado. DLP no detiene el uso compartido en sí, pero limita el daño potencial si un flujo se utiliza indebidamente de forma accidental o intencionada. Como procedimiento recomendado, clasifique los conectores en categorías Negocio y No de negocio y bloquee cualquier combinación peligrosa. De esta manera, incluso si los flujos se comparten ampliamente, no se filtrarán datos a puntos de conexión no aprobados.

  • Auditoría y supervisión periódicas: establezca una rutina (por ejemplo, mensual o trimestral) para auditar los permisos de flujo. Como parte de esta revisión, identifique los flujos que tengan un uso compartido inusual, especialmente aquellos con propietarios externos o grandes listas de usuarios de solo ejecución. Revíselos si aún son necesarios. La documentación de Microsoft fomenta las revisiones periódicas de los permisos para asegurarse de que se alinean con las necesidades empresariales actuales y para eliminar el acceso a los usuarios que ya no lo necesitan.

    La supervisión se puede automatizar. Por ejemplo, un administrador puede configurar un flujo de Power Automate mediante el conector de administración que envía un informe de todos los flujos con sus propietarios y las fechas de la última modificación. El flujo resalta los flujos que tienen propietarios fuera de una lista específica de personas aprobadas. Además, considere la posibilidad de aprovechar los paneles de análisis de administración de Power Platform. Puede mostrar el uso general y, potencialmente, filtrarse para saber cuántos usuarios están ejecutando cada flujo.

  • Educar a los creadores y hacer cumplir las políticas: A veces, el riesgo se introduce por la falta de conciencia. Documente y comunique una política clara sobre el uso compartido, por ejemplo, no agregue usuarios de fuera del entorno X como copropietarios sin aprobación. Use el acceso de solo ejecución si es necesario para usuarios ajenos al equipo. Al capacitar a creadores de Power Automate en estas pautas, se reduce la exposición accidental. Si su organización tiene una comunidad interna de Power Platform o una red de promotores, comparta recordatorios sobre las implicaciones de compartir flujos de forma generalizada. En última instancia, los usuarios deben comprender que, si bien Power Automate facilita el uso compartido, existen pasos de cumplimiento y seguridad que deben seguirse para cualquier colaboración entre entornos.

  • Utilice entornos separados para el uso compartido amplio: en algunos casos, puede ser prudente tener un entorno dedicado para los flujos que debe utilizar una amplia audiencia. Por ejemplo, una organización podría crear un entorno de Servicios compartidos que esté abierto a muchos usuarios con un grupo de seguridad adecuado. Los flujos destinados a un consumo amplio se pueden desarrollar y alojar allí, en lugar de compartirlos fuera de un entorno más restringido. De esta manera, se mantienen los límites del entorno. Sus entornos altamente controlados siguen siendo estrictos, y el entorno abierto está diseñado para el intercambio multifuncional con la supervisión adecuada. Si adopta esta estrategia, asegúrese de que el entorno abierto siga contando con directivas y supervisión sólidas de DLP, ya que tiene una base de usuarios más grande por diseño.

  • Considere la posibilidad de copiar flujos en lugar de compartirlos directamente: si los usuarios de un entorno diferente necesitan la funcionalidad de un flujo, otro enfoque es exportar el flujo como un paquete y compartir el paquete en lugar de compartir el flujo en vivo. Microsoft recomienda este enfoque en escenarios en los que el usuario no es miembro de su entorno de Power Automate: puede enviarle una copia del flujo, que ellos importen a su propio entorno. A continuación, el destinatario configura sus propias conexiones y ejecuta el flujo de forma independiente. Esto mitiga el riesgo al evitar cualquier acceso directo al flujo del entorno original. Básicamente, les entrega la solución sin darles un punto de apoyo en su entorno. La desventaja es que cualquier actualización del flujo no se sincronizará automáticamente, ya que es una copia independiente. Sin embargo, para necesidades puntuales o para compartir con equipos externos, este método garantiza una separación limpia.

En resumen, la mitigación de los riesgos asociados con el uso compartido de flujos se reduce en general a un control estricto del acceso al entorno, un uso prudente de las opciones de uso compartido y una supervisión vigilante. Al combinar las medidas de seguridad técnicas (como los entornos controlados por grupos de seguridad y las directivas DLP) con las medidas de seguridad de los procesos (como las aprobaciones para agregar propietarios y las auditorías periódicas), las organizaciones pueden disfrutar de las ventajas de Power Automate la colaboración mientras minimizan los problemas de seguridad y cumplimiento.

La siguiente sección se centra en un aspecto específico de la gobernanza: el uso de roles y grupos para definir quién es un creador y quién es simplemente un ejecutor de flujos.

Usar roles y grupos de seguridad: Administrar creadores frente a usuarios de solo ejecución

Una decisión crítica de gobernanza consiste en determinar qué usuarios deben ser creadores, quiénes pueden crear y poseer flujos, y cuáles deben limitarse a ejecutar flujos, quiénes quizás pueden consumir los resultados. Power Automate y Power Platform ofrecen varios mecanismos para hacer cumplir esta distinción, principalmente a través de roles de seguridad y grupos de seguridad.

Distinguir a los creadores de los no creadores

En un escenario empresarial, no todos los usuarios con una licencia de Power Automate deben crear necesariamente flujos en todos los ambientes. Por diseño, un Creador de entorno puede crear flujos y otros recursos en ese entorno. En el caso de los entornos dedicados, debe asignar intencionadamente el rol de Creador de ambiente solo a aquellos usuarios o grupos que sean responsables de crear soluciones. Por ejemplo, puede decidir que en el ambiente de Automatización financiera, solo el equipo de TI de finanzas y algunos usuarios avanzados tengan permisos de creador.

Para ello, haga lo siguiente:

  • Asigne el rol de seguridad creador de entorno directamente a usuarios específicos en la configuración del entorno.
  • Utilizar un grupo de seguridad de Azure active directory (AD). Agregue todos los creadores previstos a un grupo (por ejemplo, Grupo de creadores financieros) y, si el entorno no tiene Dataverse, asigne a todo ese grupo el rol de Creador de ambiente. En ambientes habilitados de Dataverse, es posible que deba agregar miembros del grupo individualmente o usar equipos de grupo con roles de seguridad.
  • Para un control amplio, asocie el ambiente con un grupo de seguridad para que solo los miembros puedan estar en el ambiente. Luego, dentro de eso, otorgue roles de creador al subconjunto apropiado. Este enfoque de dos niveles significa que los forasteros no pueden entrar sin ser detectados como creadores, y entre los iniciados, solo algunos tienen el papel de creadores. Una guía de buena reputación sugiere aplicar la característica de grupo de seguridad de ambiente a todos los ambientes de producción y confidenciales para evitar la presencia de usuarios no deseados.

Usar grupos de seguridad para acceso de solo ejecución

Si bien no hay un rol de solo ejecución en el entorno, puede administrar los permisos de solo ejecución a gran escala mediante grupos. Al compartir un flujo, los propietarios pueden introducir un nombre de grupo en lugar de usuarios individuales para el acceso de copropietario o de solo ejecución. Esto significa que podría crear un grupo de seguridad como Usuarios de flujo de informes de ventas y asignar ese grupo como usuario de sólo ejecución en los flujos relevantes. Todos los miembros del grupo heredarían el permiso de ejecución para esos flujos. La gestión se vuelve más fácil. Para revocar el acceso de un usuario en particular, elimínelo del grupo. Pierden el acceso de ejecución a todos los flujos a los que se asignó ese grupo. Del mismo modo, para conceder a una nueva persona acceso de ejecución a varios flujos, agréguelos al grupo. De este modo, los grupos de seguridad ayudan a simplificar la administración de permisos al externalizarla.

Los flujos de Power Automate no necesitan listar 50 usuarios como sólo ejecución; listan un grupo, y su administrador de Azure AD o Microsoft 365 procesa la pertenencia.

Nota

Si el ambiente en sí está restringido a un grupo de seguridad, el grupo utilizado para compartir el flujo debe ser el mismo o un subconjunto. Si comparte un flujo con un grupo que contiene personas ajenas a los usuarios permitidos del ambiente, es posible que en realidad no puedan ejecutarlo, según la configuración del ambiente. Debe coordinar el uso del grupo con las directivas de acceso al ambiente.

Asignación de roles para desarrolladores frente a usuarios de ejecución

En los ambientes de Dataverse, los roles de seguridad se pueden superponer para ajustar lo que pueden hacer los desarrolladores frente a los usuarios de ejecución.

  • Creadores: como mínimo, necesitan el rol de Creador de entorno para crear flujos. Si sus flujos interactúan con tablas de Dataverse, es posible que también necesiten roles de Dataverse adicionales, como Personalizador del sistema, o privilegios en tablas específicas, para diseñarlos y probarlos correctamente. La combinación de Creador de entorno más un rol que otorga acceso a los datos (si es necesario) les permite crear soluciones completas. Se recomienda conceder a los creadores solo los privilegios que necesitan. Por ejemplo, si un creador solo automatiza SharePoint y envía correos electrónicos, es posible que no necesite ningún rol de Dataverse aparte de estar presente en el ambiente. Sin embargo, si un creador crea un flujo para actualizar un registro de Dataverse, necesita permiso en esa tabla. Planifique sus roles de seguridad de modo que los creadores obtengan un rol de datos de creador independiente si es necesario, en lugar de asignarles roles demasiado amplios.
  • Usuarios de solo ejecución: estos usuarios no necesitan Creador de entorno. Si el entorno tiene una base de datos de Dataverse y el flujo toca datos de Dataverse, es posible que requiera el rol de usuario básico (u otro rol) para tener acceso de lectura y escritura a los datos subyacentes cuando el flujo se ejecute en su contexto. Por ejemplo, un flujo de desencadenador manual podría crear un registro de Dataverse en nombre del ejecutor. Si es así, el ejecutor necesita permiso para crear ese registro. Cuando se usa la opción El usuario de solo ejecución proporciona la conexión, el flujo se ejecuta en el contexto de las credenciales del usuario de solo ejecución. En tales casos, debe asegurarse de que esos usuarios tengan los derechos mínimos necesarios a través de roles de Dataverse o permisos del sistema relevantes para realizar las acciones que ejecuta el flujo. Si el flujo usa siempre la conexión del propietario, es posible que el usuario de solo ejecución no necesite ningún rol especial en Dataverse: está presionando un botón y el flujo usa el privilegio del propietario. Este matiz debe ser considerado cuidadosamente. Un enfoque seguro es dar a los usuarios de solo ejecución acceso de lectura a los datos que pueden mostrar y nada más. Muchas empresas crean un rol de Dataverse personalizado o utilizan un usuario básico con derechos de lectura mínimos y lo asignan a todos los usuarios finales para satisfacer este requisito de ejecutar aplicaciones y flujos.

Administrar roles teniendo en cuenta la gobernanza

Realice un seguimiento de quién tiene qué función. Un administrador de Power Platform puede enumerar todos los usuarios de un entorno y sus roles de seguridad asignados desde el centro de administración o a través de PowerShell. Esto se puede comparar con la lista esperada de creadores. Mantener un inventario es una práctica recomendada de gobernanza, por ejemplo, Entorno X creadores: Alice, Bob, Carol; solo ejecución/consumidores del entorno X: todos los usuarios del departamento de marketing. Al tener esto claro, cuando llegue una solicitud para agregar un nuevo creador, puede verificar si está aprobado por el grupo u obtener las aprobaciones necesarias para expandir el círculo.

Escenarios y ejemplos

En la siguiente lista se explican algunos escenarios y ejemplos de soluciones para ellos.

  • Escenario: un entorno departamental en el que solo un equipo pequeño debería crear flujos, pero muchos en el departamento los ejecutan.
  • Solución: al responsable de TI del departamento se le asigna Administrador de entorno. Un grupo de Azure AD Dept Makers contiene las cinco personas que crean aplicaciones y flujos. Ese grupo se agrega al rol Creador de entornos. Esto se hace directamente o se asigna a las personas si la asignación de grupo no está disponible. Todos los miembros del departamento están en el grupo Dept Users, que está asociado con el entorno, por lo que todos tienen acceso para ser usuarios. Los flujos creados en el entorno que deben ser ejecutados por todo el departamento se comparten con el grupo Dept Users como de solo ejecución. De esta manera, los creadores crean y comparten. Un miembro del departamento puede ejecutar, pero las personas que no pertenecen al departamento no pueden acceder porque no están en el grupo del ambiente.
  • Escenario: un ambiente de producción con flujos confidenciales que nadie debe editar excepto dos propietarios de la solución.
  • Solución: Solo esas dos personas son makers del ambiente. Nadie más tiene el rol de creador. Si otros usuarios necesitan desencadenar flujos, se les otorga acceso de solo ejecución. Posiblemente, una cuenta de servicio dedicada o una entidad de servicio sea en realidad la propietaria de los flujos para la estabilidad, con los dos propietarios como copropietarios para el mantenimiento. El uso de una entidad de servicio como propietario principal mejora la gobernanza de los flujos críticos. Todos los empleados regulares no están en ese entorno o solo tienen el rol de usuario. El entorno podría vincularse a un grupo de seguridad que contenga solo las cuentas necesarias para garantizar aún más la exclusividad.
  • Escenario: Un entorno de Centro de Excelencia donde los equipos de gobernanza crean flujos de supervisión en todos los entornos.
  • Solución: Solo el equipo del Centro de Excelencia tiene acceso. Son creadores de entornos por función. No es necesario compartir solo para ejecución porque estos flujos son más internos. Aquí, su gente crucial del Centro de Excelencia quizás tenga el rol de administrador en el nivel de inquilino de Power Platform, lo que implícitamente les otorga derechos en todos los entornos.

Beneficios de la segregación de roles

Al delimitar claramente el creador frente al ejecutor, se consigue lo siguiente:

  • Privilegio mínimo: los usuarios obtienen solo los permisos que necesitan. Un usuario de solo ejecución no puede empezar de repente a crear flujos que omitan la supervisión de TI, porque carece de ese rol. Los creadores tienen libertad para crear, pero dado que esa población es más pequeña y conocida, puede entrenarlos y vigilarlos más fácilmente.
  • Gestión simplificada del ciclo de vida: cuando un empleado se va o cambia de función, es más fácil actualizar el acceso. Por ejemplo, si Joe era un creador y se va del equipo, debe eliminarlo del grupo de seguridad Creadores. Pierde instantáneamente la capacidad de crear y editar en ese entorno, mientras conserva el acceso de ejecución si permanece en el grupo de usuarios. A continuación, puede agregar su reemplazo al grupo Creadores. Este mantenimiento basado en grupos es más limpio que agregar y eliminar manualmente docenas de permisos de flujo.
  • Alineación de cumplimiento: muchas regulaciones exigen un acceso controlado. Ser capaz de mostrar a un auditor que solo estas personas específicas pueden modificar la automatización en este entorno; todos los demás pueden simplemente desencadenar flujos aprobados, puede ayudar a demostrar controles internos sólidos. A los auditores también se les puede dar exportación de las asignaciones de roles del entorno como evidencia de cumplimiento.
  • Evite confusiones: si todos tuvieran derechos de creador, menos usuarios técnicos podrían crear o modificar flujos sin darse cuenta, o confundirse con la interfaz de Power Automate. Al limitar la función del creador, se asegura de que solo el personal capacitado diseñe flujos, lo que puede reducir los errores.

Estas medidas deben revisarse periódicamente. A medida que cambian las necesidades empresariales, es posible que alguien que sea un consumidor deba convertirse en creador (por ejemplo, un usuario avanzado surge en un nuevo equipo) o un creador puede necesitar convertirse en consumidor. El modelo de gobernanza debe ser lo suficientemente flexible como para adaptarse a esto con las aprobaciones adecuadas. Documente los criterios para que se le concedan privilegios de creador de entorno y el proceso para solicitarlo, de modo que haya transparencia y coherencia. Del mismo modo, defina qué condiciones pueden desencadenar la revocación del acceso del creador, por ejemplo, al mudarse a un departamento diferente.

Al usar roles y grupos de seguridad en conjunto, las organizaciones pueden lograr una separación clara y fácil de mantener entre quienes crean la automatización y quienes la usan. Esto mejora tanto la seguridad como la productividad en entornos de Power Automate.