Power Platform es maravilloso precisamente porque cualquier persona con una licencia puede montar una app o un flujo sin pedir permiso al departamento de IT. Ese mismo motivo es por el que necesitas un mecanismo de control: las políticas de prevención de pérdida de datos, o DLP.
El problema que resuelven
Imagina que alguien conecta, dentro del mismo flujo, un conector de SharePoint (donde vive información interna de la empresa) con un conector de una red social pública. Sin ninguna barrera de por medio, ese flujo podría publicar información sensible fuera de la organización sin que nadie lo revise. Las políticas DLP existen para poner freno a exactamente ese tipo de combinación, antes de que ocurra.
Cómo funcionan: grupos de conectores
Una política DLP no bloquea conectores uno a uno de forma arbitraria: los organiza en grupos, y solo permite combinar conectores que estén en el mismo grupo dentro de una misma app o flujo.
| Grupo | Qué significa |
|---|---|
| Business | Conectores que manejan datos sensibles o críticos de la organización. Solo pueden combinarse con otros conectores del grupo Business. |
| Non-Business | Conectores para datos no sensibles. Solo pueden combinarse entre sí, aislados de los grupos Business y Blocked. Es el grupo por defecto para conectores nuevos. |
| Blocked | Conectores prohibidos por completo allí donde la política se aplica: no se pueden usar en apps ni flujos nuevos ni existentes. |
El principio es sencillo de recordar: un conector solo puede compartir datos con otro conector de su mismo grupo. Si tienes SharePoint clasificado como Business y una red social clasificada como Blocked, la plataforma impide que convivan en el mismo flujo, sin que tengas que revisar cada automatización manualmente.
A qué nivel se aplican
Las políticas DLP se pueden definir a dos niveles distintos, y ambos conviven:
- Nivel de inquilino (tenant): las define un administrador de Power Platform y pueden aplicarse a varios entornos a la vez, o excluir entornos concretos. Un administrador de un entorno individual no puede modificar una política definida a nivel de tenant.
- Nivel de entorno: las define un administrador de ese entorno concreto (o un administrador de sistema sobre su base de datos de Dataverse), y solo afectan a ese entorno. No pueden anular lo que ya restringe una política de tenant, solo añadir restricciones adicionales.
En la práctica, esto permite un patrón de gobierno habitual: aplicar una política más permisiva en entornos de desarrollo o pruebas, donde makers y desarrolladores necesitan experimentar con conectores distintos, y una política más estricta en el entorno de producción, donde los datos reales de la organización están en juego.
Por qué es clave en una plataforma low-code: en Power Platform no hace falta abrir un ticket de desarrollo para crear una automatización nueva; cualquier maker con licencia puede hacerlo en minutos. Las políticas DLP son el mecanismo que permite mantener esa libertad sin perder el control sobre qué datos pueden salir de dónde.
Definir las políticas antes de que las necesites
La recomendación de Microsoft es clasificar los conectores y definir estas políticas antes de que los makers empiecen a construir soluciones en serio, no después de detectar un problema. Cuando las reglas están claras de antemano, quien diseña una app o un flujo sabe exactamente qué combinaciones de conectores están permitidas, y la política actúa de guía en lugar de sorpresa a mitad de proyecto.
- Una política de tenant siempre tiene prioridad sobre una política de entorno.
- Los conectores personalizados también se pueden clasificar dentro de estos mismos tres grupos.
- El grupo Non-Business es el que se asigna por defecto a los conectores que aún no has clasificado.
- Revisar y actualizar las políticas DLP debería ser una tarea recurrente, no algo que se configura una vez y se olvida.
¿Quieres repasar cómo se licencia lo que estas políticas terminan controlando?
Ver el artículo sobre licenciamiento