Modelos de inserción de informes

Conozca las formas correctas de incorporar informes

Antes de utilizar la tecnología de análisis integrado de Power BI para incorporar informes en portales y aplicaciones web, ya sea para reducir costos, obtener recursos avanzados y personalización, debe entender que existen 2 modelos de licenciamiento:

• Insertar para sus clientes: permite crear una aplicación que utiliza un Service Principal para autenticarse e interactuar con los datos en Power BI. Sus usuarios no necesitan iniciar sesión con credenciales de Power BI para ver el contenido insertado y el licenciamiento se realiza contratando una capacidad para licenciar los workspaces de los informes.
• Insertar para la organización: permite crear una aplicación que requiere el uso de una cuenta Pro de Power BI para cada usuario. Los usuarios registrados solo pueden consumir el contenido insertado al que tienen acceso en el servicio de Power BI.

1) User Owns Data (el usuario es dueño de los datos)

Este es el modelo más simple y directo:

• Cada usuario final se autentica en Power BI con su propia cuenta corporativa (mediante Entra ID).
• La aplicación actúa como un puente, pero la experiencia es personalizada por usuario.
• Cada usuario necesita una licencia Power BI Pro (o acceso a un workspace en capacidad Premium).
• La aplicación solo facilita el embed, pero el acceso a los informes se controla a través de Power BI.

Escenarios típicos:

• Aplicaciones internas para los colaboradores de una empresa.
• Soluciones corporativas que siguen políticas internas de seguridad e identidad.

Correcto:

• Usuarios internos autenticados en Entra ID.
• Licenciamiento Pro o SKU P.
• RLS controlado en el propio Power BI.

Incorrecto:

• Intentar usar User owns data con usuarios externos.
• Compartir credenciales o tokens manualmente.
• Ignorar el licenciamiento por usuario.

2) App Owns Data (la aplicación es dueña de los datos)

Este es el modelo ideal para ISV y soluciones SaaS como Power Embedded:

• La aplicación usa un Service Principal (o Master Account) para autenticarse en Power BI, en nombre de todos los usuarios.
• Los usuarios finales no necesitan cuenta de Power BI ni licencia Pro.
• Los informes se incorporan directamente en la interfaz de la aplicación.
• El control de permisos, RLS y visibilidad se realiza dentro de la aplicación, mediante el token de incorporación.

Modelo de Power Embedded - App Owns Data (multi-tenant)

Cada cliente tiene:

• Su propio tenant de Microsoft Entra ID
• Sus capacidades Premium (Power BI Embedded o Fabric)
• Sus propios workspaces con informes, asociados a 1 capacidad Premium
• Un service principal creado en su tenant, que concede permiso únicamente a los workspaces utilizados en el portal.

Power Embedded (en el tenant del ISV):

• Se autentica usando el client_id + secret del service principal del cliente
• Genera el token de embed con alcance mínimo
• Aplica seguridad y RLS con base en la base de datos interna del ISV
• No posee control ni alojamiento de los informes, solo los consume mediante API

Puntos importantes:

• Los usuarios pertenecen a su propio tenant o son usuarios externos, registrados por un administrador del portal mediante SSO o métodos alternativos (Entra ID, Google, correo electrónico/contraseña, etc.).
• El acceso a los informes se realiza mediante autenticación no interactiva, conforme a lo definido por Microsoft para ISV en el modelo "insertar para sus clientes".
• Power Tuning, como ISV, crea un Service Principal directamente dentro del tenant del cliente (con su consentimiento) y lo configura con los permisos adecuados para generar el token de embed.
• Power Embedded actúa como un middleware, pero el acceso y el embed ocurren utilizando el Service Principal de ese tenant, con la capacidad vinculada a ese tenant.
• Aunque el portal sea multicliente, cada tenant tiene su propia instancia de embed aislada, con su propio Service Principal y su propia capacidad.
• Los usuarios finales no necesitan licencias Power BI Pro, dado que los informes están asignados a una capacidad dedicada.
• Como el contenido y el Service Principal están en el mismo tenant del cliente, no hay violación del control de datos ni del aislamiento entre tenants.

✅ Esto cumple al 100% con el modelo "App owns data"

Errores comunes al utilizar el modelo App Owns Data

1) Portal que aloja informes de clientes

• Un único workspace por cliente dentro del tenant del ISV.
• Una capacidad compartida entre todos.
• Service Principal controlado por el ISV.
• Acceso segmentado por RLS o filtros.
• Ningún control real del cliente sobre sus informes.

Riesgo:

• Violación de las reglas de licenciamiento.
• Posible infracción contractual con Microsoft.
• Puede llevar a la suspensión de la cuenta por parte de Microsoft.
• Datos de múltiples clientes bajo el control de un único tenant = riesgo de seguridad y privacidad.

2) Uso de Master Account para todos los informes:

• La aplicación usa una cuenta "genérica" con licencia Pro para generar embed tokens.
• No utiliza Service Principal.
• No hay uso de capacidad Premium.
• Los usuarios finales acceden sin licencia.

Riesgos de licenciamiento:

• Totalmente fuera del modelo soportado actualmente.
• Práctica obsoleta y no recomendada por Microsoft.
• Altamente riesgosa para la escalabilidad, la seguridad y el compliance.
• Inviable para escala o auditoría.
• No está soportada oficialmente.
• Puede llevar a la suspensión de la cuenta.

Riesgos de seguridad:

• Es necesario almacenar usuario y contraseña (con riesgo de fuga).
• Los tokens se generan con permisos de un usuario humano.
• Sin autenticación granular ni alcance controlado.
• Si los tokens son interceptados, cualquier persona puede acceder al contenido incrustado.