--- title: "Seguridad en Power Platform: Roles y DLP" description: "Aprende cómo las directivas DLP y los roles de seguridad protegen tu tenant de Power Platform: conectores, Dataverse y buenas prácticas para líderes de TI." image: https://www.procimple.net/hubfs/hero_blog_dlp_2_procimple.jpg --- [Go Back Up](https://www.procimple.net/power-automatizate-blog/seguridad-power-platform-roles-dlp#top) [Skip to Content](https://www.procimple.net/power-automatizate-blog/seguridad-power-platform-roles-dlp#body) [![Empresa de automatización de procesos - Licencias Microsoft](https://www.procimple.net/hs-fs/hubfs/Procimple%20Logo%20Horizontal%20PNG%20(2).png?width=834&height=264&name=Procimple%20Logo%20Horizontal%20PNG%20(2).png "Empresa de automatización de procesos - Licencias Microsoft")](https://procimple.com/) Toggle Menu - [Get Started](https://www.example.com) - Open Search Search Submit Search # Seguridad en Power Platform: Roles y DLP [Gobernanza](https://www.procimple.net/power-automatizate-blog/topic/gobernanza) • [power platform](https://www.procimple.net/power-automatizate-blog/topic/power-platform) • 17/10/2026 • Escrito por: Equipo Procimple ![](https://www.procimple.net/hubfs/hero_blog_dlp_2_procimple.jpg) Share article # Las dos capas que todo líder de TI debe gobernar   Power Platform permite que un área de negocio construya una aplicación o una automatización en horas. Esa velocidad es su mayor ventaja y, sin controles, también su mayor riesgo: un flujo que copia datos de SharePoint a un servicio personal, o un usuario con permisos que nadie recuerda haber asignado, bastan para convertir una solución útil en un incidente de seguridad. En este artículo revisamos las dos capas de control que sostienen la seguridad de la plataforma: las **directivas de prevención de pérdida de datos (DLP)**, que gobiernan *qué conectores pueden convivir*, y los **roles de seguridad**, que gobiernan *quién puede hacer qué* y sobre qué datos. Incluimos ejemplos concretos para que puedas replicarlos en tu tenant. ## 1. Dónde viven la seguridad y la identidad Antes de configurar cualquier directiva conviene tener clara la arquitectura. Power Platform opera dentro de un tenant de Microsoft 365 cuya identidad se apoya en el directorio activo (Microsoft Entra ID). Sobre esa base se montan aplicaciones, automatizaciones, agentes, modelos de IA y reportes, y todos ellos llegan a los datos a través de una misma capa: los conectores (SharePoint, Outlook, Excel, Dataverse, Teams, Word y cientos más). Esa capa de conectores es el punto de control natural: si un componente no puede usar un conector, no puede mover los datos que ese conector expone. Por eso la DLP actúa ahí. Y como el acceso a la plataforma y a sus datos se resuelve por identidad, los roles actúan sobre las personas y los grupos. Control de acceso y control de conectores son, en la práctica, las dos puertas de entrada. ![modGeneralPowerPlatform-procimple-blueprint](https://www.procimple.net/hs-fs/hubfs/modGeneralPowerPlatform-procimple-blueprint.png?width=1033&height=562&name=modGeneralPowerPlatform-procimple-blueprint.png) ## 2. Capa uno: directivas de datos (DLP) De acuerdo con la documentación de Microsoft, las directivas de datos funcionan como límites de protección que reducen el riesgo de que los usuarios expongan datos de la organización sin querer. Se administran en el centro de administración de Power Platform y afectan a Power Apps, Power Automate y Copilot Studio. ### Los conectores que vas a gobernar Los cuatro tipos de conector que conviene conocer responden a preguntas distintas, así que los agrupamos en dos ejes: quién los construye y valida, y cómo exponen su funcionalidad. **Por origen: quién los construye y los valida** - **Certificados:** Microsoft los prueba y certifica para que cumplan sus estándares de seguridad, confiabilidad y cumplimiento. - **Personalizados:** los crean tus propios equipos para integrar sistemas no cubiertos por el catálogo estándar. Dan flexibilidad, pero exigen revisar que cumplan las directivas de datos. **Por naturaleza: cómo exponen su funcionalidad** - **Virtuales:** aparecen en las directivas para que los administradores los controlen, pero no se basan en una API REST. Muchos sirven para activar o desactivar funciones de Copilot Studio. - **MCP (Protocolo de contexto de modelo):** exponen puntos de conexión de API habilitados para MCP, llamados *herramientas*, que alimentan las experiencias de IA generativa en Copilot Studio. ### Con qué herramienta se gobierna cada uno Las directivas de datos (DLP) son el control base. Las directivas de conector avanzadas (ACP) son una herramienta complementaria, no un tipo de conector, y su alcance es distinto según el tipo: | Tipo de conector | Cómo se gobierna | Qué tener en cuenta | | --- | --- | --- | | Certificados | ACP es la característica de gobernanza más sólida para los conectores certificados reales | Es el foco principal de ACP | | Personalizados | Deben cumplir las directivas de datos | Revisa cada uno antes de habilitarlo | | Virtuales | Aparecen en las directivas de datos; ACP no los admite | Los de Copilot Studio migran a reglas de gobernanza propias; los de flujos de escritorio pasan a conectores certificados, que luego administra ACP | | MCP | ACP permite administrar y restringir estos conectores y sus servidores MCP | Es la vía de control para la IA generativa en Copilot Studio | La consecuencia práctica: no diseñes toda tu gobernanza sobre ACP si dependes de conectores virtuales, porque quedarán fuera de su alcance. ### Los tres grupos y la regla de no mezclar En una directiva de datos cada conector se clasifica en un grupo: - Empresarial - No empresarial - Bloqueado Los grupos determinan cuales conectores se pueden utilizar en el tenant. ![blog\_dlp\_grupos](https://www.procimple.net/hs-fs/hubfs/blog_dlp_grupos.png?width=1600&height=900&name=blog_dlp_grupos.png) **Ejemplo práctico.** Tu organización decide que SharePoint, Outlook, Dataverse y Teams son conectores *Empresarial*, y que servicios personales de almacenamiento como Dropbox van en *No empresarial*. Un creador intenta armar un flujo que toma un archivo de SharePoint y lo envía a Dropbox. Al guardar, la plataforma lo rechaza con un error que indica que la directiva bloquea esa combinación. El dato nunca sale, y no dependió de que el creador conociera la norma. Para conocer detalles adicionales, consulta la guía [Administrar directivas de datos](https://learn.microsoft.com/es-es/power-platform/admin/prevent-data-loss). ### Tiempo de diseño frente a ejecución Bloquear un conector tiene efectos en dos momentos distintos, y confundirlos genera tickets de soporte innecesarios: - **Tiempo de diseño:** el creador no puede guardar una app o flujo que use un conector bloqueado. Por ejemplo, si bloqueas el conector Gmail, recibe un error indicando que la directiva lo impide. - **Tiempo de ejecución:** lo que ya estaba corriendo, como un flujo programado todos los días a las 3:00 a.m., falla cuando su conexión queda inactiva. Si el creador intenta repararla, recibe de nuevo el error de diseño. ### Qué ocurre cuando cambias una directiva Crear o modificar una directiva dispara un proceso en cascada: 1. La configuración se guarda a nivel de tenant. 2. Se propaga a cada entorno. 3. Los recursos (apps, flujos y bots) consultan periódicamente si hay cambios. 4. Al detectar uno, cada recurso se evalúa contra la política. 5. Los que infringen quedan en estado *suspendido* o de *cuarentena*. 6. Si se bloquea un conector completo, sus conexiones quedan *deshabilitadas*. 7. Cualquier ejecución que use una conexión inactiva, una acción, un desencadenador o un servidor MCP bloqueado produce error. La latencia depende del volumen de entornos y recursos: normalmente se aplica en menos de una hora, y en casos extremos puede llegar a 24 horas. La implicación operativa es clara: un cambio de DLP puede dejar soluciones productivas suspendidas. Nuestra recomendación es validar la política en un entorno de desarrollo, inventariar qué usa cada conector antes de bloquearlo y avisar a los dueños de las soluciones. ![blog\_dlp\_proceso\_cambio](https://www.procimple.net/hs-fs/hubfs/blog_dlp_proceso_cambio.png?width=1600&height=900&name=blog_dlp_proceso_cambio.png) ## 3. Capa dos: roles de seguridad Dataverse usa un modelo de seguridad basado en roles. La combinación de permisos y niveles de acceso de un rol determina qué aplicaciones y datos ve el usuario y cómo interactúa con ellos. Lo primero que debes dominar es que no hay un solo tipo de rol, sino cuatro, en ámbitos distintos: | Tipo de rol | Ejemplos | Ámbito | | --- | --- | --- | | Administrador de nivel de tenant | Administrador global, Administrador de Power Platform, Administrador de Dynamics 365 | Todo el tenant; se asigna en el centro de administración de Microsoft 365 | | Nivel de entorno | Administrador del entorno, Creador de entornos | Un entorno sin Dataverse | | Seguridad de Dataverse | Administrador del sistema, Personalizador del sistema, Usuario básico | Un entorno con Dataverse | | Específicos de aplicación | Roles de Dynamics 365 Sales o Servicio al cliente | Un entorno con Dataverse | ### Un detalle importante sobre roles Los roles de tenant como administrador de Power Platform conceden acceso administrativo entre entornos, pero no dan acceso automático a los datos de Dataverse. Para trabajar con datos en un entorno hay que asignar además el rol administrador del sistema en ese entorno específico. Esta es una buena noticia para el gobierno de datos: administrar la plataforma y leer la información son privilegios separados. Otro matiz fácil de pasar por alto: el rol *Administrador del entorno* solo aplica a entornos sin Dataverse. En entornos con Dataverse, el equivalente con privilegios completos es *Administrador del sistema*. ![blog\_roles\_capas](https://www.procimple.net/hs-fs/hubfs/blog_roles_capas.png?width=1600&height=900&name=blog_roles_capas.png) ### Mínimo privilegio en la práctica Los roles predefinidos siguen el principio de acceso mínimo necesario, y los que Microsoft entrega no se pueden editar. A continuación mencionamos dos casos que ilustran cómo aplicarlo: - **Creador de entornos (environment maker).** Puede crear aplicaciones, conexiones, API personalizadas y flujos, y compartir lo que crea, pero no tiene privilegios para acceder a los datos del entorno. Es el rol adecuado para un creador ciudadano que construye soluciones sobre SharePoint. - **Creador de entornos + Personalizador del sistema.** Quien crea apps que se conectan a Dataverse y necesita crear o actualizar tablas debe sumar el rol Personalizador del sistema. Ninguno de los dos puede crear ni actualizar roles de seguridad. Esta matriz resume qué puede crear cada rol: | Recurso | Creador de entornos | Administrador de entorno | Personalizador del sistema | Administrador del sistema | | --- | --- | --- | --- | --- | | Aplicación de lienzo | Sí | Sí | Sí | Sí | | Flujo de nube | Sí | Sí | Sí | Sí | | Conexión | Sí | Sí | Sí | Sí | | Puerta de enlace de datos | No | Sí | No | Sí | | Tablas de Dataverse | No | No | Sí | Sí | | Aplicación basada en modelo | Sí | No | Sí | Sí | | Flujo de escritorio | No | No | Sí | Sí | | AI Builder | No | No | Sí | Sí | Observa un efecto práctico: un creador de entornos puede construir un flujo de nube dentro de alguna solución. Esto conecta la seguridad con el ciclo de vida de las aplicaciones (ALM). ### Errores de acceso por roles Cuando un usuario ve el mensaje «Uno o varios comandos no están disponibles debido a los privilegios actuales de este entorno», casi siempre su rol no incluye el privilegio necesario. Si no puede acceder a un entorno, probablemente no tiene un rol asignado allí o le falta la licencia de Dataverse. Y si no puede asignar o modificar roles: solo el administrador del sistema o un administrador de tenant pueden hacerlo. ## 4. Cómo se combinan las dos capas: un caso de aprobación de compras Imagina una aplicación de aprobación de órdenes de compra: la solicitud se registra en Dataverse, un flujo notifica por Outlook y publica en Teams, y los documentos viven en SharePoint. - **DLP:** SharePoint, Outlook, Teams y Dataverse están en el grupo empresarial, así que el flujo se guarda sin problemas. Si alguien intenta sumar un servicio personal de mensajería o almacenamiento, la directiva lo detiene en diseño. - **Roles:** el analista de negocio que construye la solución tiene el rol 'creador de entornos'; el líder técnico que define tablas suma el rol 'personalizador del sistema' solo en el entorno de desarrollo; en producción únicamente un administrador del sistema asigna roles; los aprobadores reciben un rol con los privilegios mínimos sobre las tablas que usan. - **Resultado:** cada capa cubre el hueco de la otra. La DLP evita que el dato salga por un conector inadecuado, y los roles evitan que dentro del perímetro cada persona vea más de lo que necesita. ## 5. De los controles aislados a un modelo de gobernanza DLP y roles no funcionan bien como configuraciones sueltas. En nuestros acompañamientos los ubicamos dentro de cuatro pilares de gobernanza: - **Ambientes:** estrategia de entornos y ubicación de los desarrollos actuales. Las directivas se aplican por entorno, así que sin esta base no hay políticas diferenciadas para desarrollo, pruebas y producción. - **Accesos:** roles, grupos y políticas. Aquí vive el diseño de quién tiene qué rol y dónde. - **Soluciones:** administración de requerimientos, arquitectura y procedimiento de monitoreo. - **Educación:** capacitación en administración, gestión del cambio y formación para el desarrollo interno. Una política que los creadores no entienden termina vista como un obstáculo. Todo esto se articula con el ciclo de vida de las aplicaciones: planeación, desarrollo, pruebas y ajustes, despliegues entre ambientes, operación y monitoreo con mejora continua. La seguridad no se agrega al final: se verifica en cada fase. ## 6. Checklist para tu próxima revisión de seguridad 1. ¿Tienes inventariados los conectores que usan hoy tus apps y flujos, antes de cambiar una directiva? 2. ¿Cada conector está clasificado de forma deliberada, y no por defecto? 3. ¿Tus conectores personalizados pasaron revisión antes de habilitarse? 4. ¿Probaste el cambio de DLP en un entorno de desarrollo y avisaste a los dueños de las soluciones? 5. ¿Quién tiene rol de administrador de tenant, y lo necesita realmente? 6. ¿Distingues el rol 'administrador del entorno' (sin Dataverse) del 'administrador del sistema' (con Dataverse)? 7. ¿Los creadores ciudadanos tienen asignados únicamente los roles 'creador de entornos' y 'personalizador del sistema' solo donde crean tablas? 8. ¿Tus roles se asignan a grupos y no usuario por usuario? 9. ¿Hay un procedimiento de monitoreo y de revisión periódica de accesos? 10. ¿Tus creadores (desarrolladores ciudadanos) saben por qué existen estas reglas? ## Conclusión La DLP controla por dónde pueden viajar los datos; los roles controlan quién puede tocarlos. Ninguna reemplaza a la otra, y ambas rinden más cuando forman parte de una estrategia de ambientes, accesos, soluciones y educación. Si quieres revisar en qué punto está tu tenant, en Procimple acompañamos a equipos de TI en la definición o mejora de estos procedimientos. Podemos conversar sobre tu caso cuando lo necesites. --- **Fuentes:** [Directivas de datos, Microsoft Learn](https://learn.microsoft.com/es-es/power-platform/admin/wp-data-loss-prevention)  [Roles de seguridad basados en jerarquía para Dataverse, Microsoft Learn](https://learn.microsoft.com/es-es/power-platform/admin/database-security) ### Listo para mejorar el control de tus procesos? [Iniciar](https://www.procimple.com/contacto) ![](https://www.procimple.net/hubfs/Procimple_Favicon.png) [mailto:comercial@procimple.com](mailto:comercial@procimple.com) ###### Equipo Procimple Nuestro equipo experto en procesos y soluciones low code le apasiona compartir su conocimiento adquirido durante +10 años de experiencia en procesos y tecnología Te podrían interesar estos artículos de Procimple ![](https://www.procimple.net/hs-fs/hubfs/hero_blog_dlp_2_procimple.jpg?width=700&name=hero_blog_dlp_2_procimple.jpg) ### [Seguridad en Power Platform: Roles y DLP](https://www.procimple.net/power-automatizate-blog/seguridad-power-platform-roles-dlp) ![](https://www.procimple.net/hs-fs/hubfs/Portada%20Blog%20Procimple%207.png?width=700&name=Portada%20Blog%20Procimple%207.png) ### [Después del terremoto: ¿Está preparada tu empresa para seguir operando cuando ocurre una emergencia?](https://www.procimple.net/power-automatizate-blog/despues-del-terremoto-resiliencia-empresarial) ![](https://www.procimple.net/hs-fs/hubfs/heroImageResizeSharepoint.png?width=700&name=heroImageResizeSharepoint.png) ### [Gestión documental con SharePoint](https://www.procimple.net/power-automatizate-blog/gestion-documental-sharepoint) [![Empresa de automatización de procesos - Licencias Microsoft](https://www.procimple.net/hs-fs/hubfs/Procimple%20Logo%20Horizontal%20PNG%20(2).png?width=834&height=264&name=Procimple%20Logo%20Horizontal%20PNG%20(2).png "Empresa de automatización de procesos - Licencias Microsoft")](https://procimple.com/) - [Nuestros Servicios](https://procimple.com/servicios/) - [Sobre Nosotros](https://procimple.com/sobre-nosotros/) - [Contacto](https://procimple.com/contacto/) --- ♥ Copyright © 2026 Procimple | Elaborado por PROCIMPLE SAS | [Política de privacidad](https://procimple.com/politica-privacidad/) ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Equipo Procimple", "url" : "https://www.procimple.net/power-automatizate-blog/author/equipo-procimple" }, "dateModified" : "2026-10-19T14:05:42.002Z", "datePublished" : "2026-10-17T17:07:54.000Z", "headline" : "Seguridad en Power Platform: Roles y DLP", "image" : [ "https://www.procimple.net/hubfs/hero_blog_dlp_2_procimple.jpg" ], "mainEntityOfPage" : { "@id" : "https://www.procimple.net/power-automatizate-blog/seguridad-power-platform-roles-dlp", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://www.procimple.net/hubfs/Procimple%20Logo%20Horizontal%20PNG%20(2).png" }, "name" : "PROCIMPLE SAS" } } ```