# Riesgos de utilizar una solución que adopta Multi-tenant SaaS para Embedded Analytics ### Política de precios y contratación de la capacidad Trabajamos exclusivamente con los precios oficiales de Microsoft, sin ningún markup adicional sobre el costo de la capacidad. La contratación de la capacidad se realiza directamente en el portal de Azure, con total transparencia y seguimiento del cliente durante todo el proceso. Incluso, si el cliente ya tiene una capacidad contratada o desea contratarla con otro partner de Microsoft, no hay ningún problema. Power Embedded no exige que la contratación de la capacidad deba hacerse con AzureBrasil como partner de Azure, aunque resulta muy conveniente para los clientes. Este enfoque garantiza el cumplimiento de los términos de licenciamiento de Microsoft, la trazabilidad de la facturación y la gobernanza completa sobre los recursos aprovisionados. ### Cumplimiento del licenciamiento de Microsoft y prácticas prohibidas Existen prácticas en el mercado que intentan reducir el costo de Power BI Embedded utilizando enfoques no soportados por Microsoft, como: * Uso de licencias Power BI Pro o Premium Per User (PPU) para escenarios de embedding en producción (App Owns Data). * Técnicas para la reutilización de tokens vencidos o autenticación fuera del flujo soportado. De acuerdo con la documentación oficial de Microsoft, **las licencias Pro o PPU están destinadas únicamente a escenarios de desarrollo, prueba o embed para usuarios autenticados, y no sustituyen una capacidad dedicada en producción**. Para entornos productivos de embedding (especialmente con usuarios externos), **es obligatoria la contratación de una capacidad dedicada (SKU A, EM, P o F)**. La adopción de estas prácticas fuera de los escenarios soportados **viola los términos de licenciamiento de Microsoft** y puede resultar en penalidades contractuales, auditorías, suspensión de servicios y riesgos legales. Usar Pro/PPU + embed externo **puede ser explotado como data exfiltration vector**. Si un token se filtra (log, browser, proxy, devtools), **cualquier persona puede acceder a TODOS los informes de TODOS los clientes que están en ese tenant**. Por ese motivo, no implementamos soluciones que eludan el modelo oficial de licenciamiento, incluso cuando ello implica la pérdida de oportunidades comerciales. ### Estrategia de capacidad y aislamiento de clientes Otro enfoque común para reducir costos es consolidar múltiples clientes en una única capacidad compartida, en un único tenant, donde los datos son administrados por el fabricante del software y el cliente pasa a tener solo un usuario para acceder y publicar los paneles en lugar de ser el dueño de la información y contar con todos los controles de auditoría y seguridad del entorno. Aunque técnicamente es posible, esta práctica **impacta directamente el rendimiento, la previsibilidad y la gobernanza**, pues la capacidad es un recurso computacional compartido (CPU, memoria y throughput), sujeto a contención y throttling cuando se sobrecarga. Cuando múltiples clientes comparten el mismo tenant y la misma identidad técnica, cualquier error de configuración (RLS, dataset, workspace, app, token) puede **exponer datos de un cliente a otro** y este es **uno de los mayores riesgos de seguridad en Power BI Embedded SaaS.** Un único usuario técnico para todos los clientes significa: * Sin segregación de identidad * Sin RBAC real por cliente * Sin control de acceso granular * Sin Conditional Access por organización Esto **viola principios básicos de seguridad corporativa (Zero Trust)**. Cuando el cliente no es dueño del tenant: * No ve los logs de acceso * No controla la auditoría de Purview * No controla Defender for Cloud Apps * No controla quién accedió a qué datos * No puede demostrar el cumplimiento (compliance) Un único usuario de publicación/embedding significa: * Si la credencial se filtra → **todos los clientes quedan comprometidos** * Si alguien deja la empresa → riesgo de insider threat * Si se intercepta el token → acceso global El cliente deja de ser: * Data Controller * Tenant Owner * Responsible Party Bajo GDPR/LGPD, esto puede caracterizar **procesamiento sin control del controlador**, aumentando la responsabilidad legal. Microsoft recomienda: * aislamiento por tenant o capacidad * control de identidad mediante Entra ID * segregación arquitectónica multi-tenant * RLS + workspace segregation Multi-tenant SaaS con Power BI **es posible**, pero exige una arquitectura formal (App Owns Data + isolation patterns). El modelo “todos los clientes en un tenant con un usuario” **no se considera arquitectura enterprise**. Para garantizar la calidad del servicio, la previsibilidad del rendimiento y el aislamiento operativo, recomendamos e implementamos arquitecturas en las que cada cliente posee su propia capacidad dedicada o, como mínimo, aislamiento lógico controlado, conforme a las mejores prácticas de planificación de capacidad de Microsoft. ### Riesgos de seguridad La utilización de enfoques no soportados para reducir costos en Power BI Embedded introduce **riesgos críticos de seguridad, gobernanza y compliance**, incluyendo: #### **Exposición indebida de datos** El uso de licencias Pro o PPU en escenarios de embedding externo (App Owns Data) puede provocar fallas de aislamiento entre tenants, usuarios y workspaces, resultando en **fuga de datos entre clientes o usuarios finales**. Microsoft recomienda el uso de capacidad dedicada para garantizar el aislamiento de recursos y el control de acceso. #### **Riesgo de compromiso de tokens y autenticación** Prácticas como la reutilización de tokens vencidos, el caché manual de tokens o la autenticación fuera del flujo soportado (OAuth 2.0 con Azure AD / Entra ID) pueden: * Permitir **acceso no autorizado a informes y datasets** * Posibilitar el **secuestro de sesión (token hijacking)** * Violar políticas de Conditional Access y Zero Trust Microsoft define que los tokens deben emitirse y validarse conforme a los flujos oficiales de autenticación y autorización. #### **Ruptura del aislamiento entre clientes (multi-tenant risks)** Consolidar múltiples clientes en una única capacidad sin un aislamiento arquitectónico adecuado puede causar: * Acceso lateral entre tenants (cross-tenant data exposure) * Fallas de gobernanza y auditoría * Dificultad para aplicar políticas de retención, DLP y eDiscovery Microsoft recomienda el aislamiento por capacidad o la segregación arquitectónica para escenarios multi-tenant corporativos. #### **Imposibilidad de compliance corporativo** Las arquitecturas fuera del modelo oficial dificultan o inviabilizan: * SOC 2 / ISO 27001 * GDPR / LGPD * Auditorías de licenciamiento de Microsoft * Controles de RBAC, Purview y Microsoft Defender Los entornos corporativos exigen **arquitecturas soportadas oficialmente**, con pistas de auditoría y gobernanza nativas. ### Conclusión La adopción de prácticas no soportadas puede resultar en: * Violación de los Microsoft Product Terms y del contrato de licenciamiento * Auditorías de compliance y multas contractuales * Suspensión de servicios o del tenant * Riesgo legal y reputacional para la empresa Los entornos corporativos exigen **arquitecturas soportadas oficialmente**, con pistas de auditoría y gobernanza nativas. Por ese motivo, seguimos exclusivamente arquitecturas soportadas oficialmente por Microsoft y alineadas con las mejores prácticas de seguridad y gobernanza.