> For the complete documentation index, see [llms.txt](https://docs.powerembedded.com.br/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.powerembedded.com.br/perguntas-frequentes/licenciamento/riscos-de-se-utilizar-solucao-que-adota-multi-tenant-saas-para-embedded-analytics.md). # Riscos de se utilizar solução que adota Multi-tenant SaaS para Embedded Analytics ### Política de preços e contratação da capacidade Trabalhamos exclusivamente com os preços oficiais da Microsoft, sem qualquer markup adicional sobre o custo da capacidade. A contratação da capacidade é realizada diretamente no portal do Azure, com total transparência e acompanhamento do cliente durante todo o processo. Inclusive, se o cliente já tiver capacidade contratada ou quiser contratar a capacidade com outro parceiro Microsoft, não tem problema nenhum. O Power Embedded não exige que a contratação da capacidade precise ser feita tendo a AzureBrasil como parceira de Azure, embora seja bem interessante para os clientes. Essa abordagem garante conformidade com os termos de licenciamento da Microsoft, rastreabilidade da cobrança e governança completa sobre os recursos provisionados. ### Conformidade com licenciamento Microsoft e práticas proibidas Existem práticas no mercado que tentam reduzir o custo do Power BI Embedded utilizando abordagens não suportadas pela Microsoft, como: * Uso de licenças Power BI Pro ou Premium Per User (PPU) para cenários de embedding em produção (App Owns Data). * Técnicas para reutilização de tokens expirados ou autenticação fora do fluxo suportado. De acordo com a documentação oficial da Microsoft, **licenças Pro ou PPU são destinadas apenas a cenários de desenvolvimento, teste ou embed para usuários autenticados, e não substituem uma capacidade dedicada em produção**. Para ambientes produtivos de embedding (especialmente com usuários externos), **é obrigatória a contratação de uma capacidade dedicada (A, EM, P ou F SKU)**. A adoção dessas práticas fora dos cenários suportados **viola os termos de licenciamento da Microsoft** e pode resultar em penalidades contratuais, auditorias, suspensão de serviços e riscos legais. Usar Pro/PPU + embed externo **pode ser explorado como data exfiltration vector**. Se um token vazar (log, browser, proxy, devtools), **qualquer pessoa pode acessar TODOS os relatórios de TODOS os clientes que estão naquele tenant**. Por esse motivo, não implementamos soluções que burlam o modelo oficial de licenciamento, mesmo quando isso implica a perda de oportunidades comerciais. ### Estratégia de capacidade e isolamento de clientes Outra abordagem comum para redução de custos é consolidar múltiplos clientes em uma única capacidade compartilhada, em um único tenant, onde os dados são gerenciados pelo fabricante do software e o cliente passa a ter apenas um usuário para acessar e publicar os painéis ao invés de ser o dono da informação e com todos os controles de auditoria e segurança do ambiente. Embora tecnicamente possível, essa prática **impacta diretamente desempenho, previsibilidade e governança**, pois a capacidade é um recurso computacional compartilhado (CPU, memória e throughput), sujeito a contenção e throttling quando sobrecarregado. Quando múltiplos clientes compartilham o mesmo tenant e a mesma identidade técnica, qualquer erro de configuração (RLS, dataset, workspace, app, token) pode **expor dados de um cliente para outro** e esse é **um dos maiores riscos de segurança em Power BI Embedded SaaS.** Um único usuário técnico para todos os clientes significa: * Sem segregação de identidade * Sem RBAC real por cliente * Sem controle de acesso granular * Sem Conditional Access por organização Isso **viola princípios básicos de segurança corporativa (Zero Trust)**. Quando o cliente não é dono do tenant: * Ele não vê logs de acesso * Não controla auditoria Purview * Não controla Defender for Cloud Apps * Não controla quem acessou quais dados * Não pode provar compliance Um único usuário de publicação/embedding significa: * Se a credencial vazar → **todos os clientes são comprometidos** * Se alguém sair da empresa → risco insider threat * Se token for interceptado → acesso global O cliente deixa de ser: * Data Controller * Tenant Owner * Responsible Party Em GDPR/LGPD, isso pode caracterizar **processamento sem controle do controlador**, aumentando responsabilidade legal. A Microsoft recomenda: * isolamento por tenant ou capacidade * controle de identidade via Entra ID * segregação multi-tenant arquitetural * RLS + workspace segregation Multi-tenant SaaS com Power BI **é possível**, mas exige arquitetura formal (App Owns Data + isolation patterns). O modelo “todos os clientes em um tenant com um usuário” **não é considerado arquitetura enterprise**. Para garantir qualidade de serviço, previsibilidade de performance e isolamento operacional, recomendamos e implementamos arquiteturas onde cada cliente possui sua própria capacidade dedicada ou, no mínimo, isolamento lógico controlado, conforme as melhores práticas de planejamento de capacidade da Microsoft. ### Riscos de segurança A utilização de abordagens não suportadas para reduzir custos no Power BI Embedded introduz **riscos críticos de segurança, governança e compliance**, incluindo: #### **Exposição indevida de dados** O uso de licenças Pro ou PPU em cenários de embedding externo (App Owns Data) pode levar a falhas de isolamento entre tenants, usuários e workspaces, resultando em **vazamento de dados entre clientes ou usuários finais**. A Microsoft recomenda o uso de capacidade dedicada para garantir isolamento de recursos e controle de acesso. #### **Risco de comprometimento de tokens e autenticação** Práticas como reutilização de tokens expirados, cache manual de tokens ou autenticação fora do fluxo suportado (OAuth 2.0 com Azure AD / Entra ID) podem: * Permitir **acesso não autorizado a relatórios e datasets** * Viabilizar **sequestro de sessão (token hijacking)** * Violar políticas de Conditional Access e Zero Trust A Microsoft define que os tokens devem ser emitidos e validados conforme os fluxos oficiais de autenticação e autorização. #### **Quebra de isolamento entre clientes (multi-tenant risks)** Consolidar múltiplos clientes em uma única capacidade sem isolamento arquitetural adequado pode causar: * Acesso lateral entre tenants (cross-tenant data exposure) * Falhas de governança e auditoria * Dificuldade de aplicação de políticas de retenção, DLP e eDiscovery A Microsoft recomenda isolamento por capacidade ou segregação arquitetural para cenários multi-tenant corporativos. #### **Impossibilidade de compliance corporativo** Arquiteturas fora do modelo oficial dificultam ou inviabilizam: * SOC 2 / ISO 27001 * GDPR / LGPD * Auditorias de licenciamento Microsoft * Controles de RBAC, Purview e Microsoft Defender Ambientes corporativos exigem **arquiteturas suportadas oficialmente**, com trilhas de auditoria e governança nativas. ### Conclusão A adoção de práticas não suportadas pode resultar em: * Violação dos Microsoft Product Terms e contrato de licenciamento * Auditorias de compliance e multas contratuais * Suspensão de serviços ou tenant * Risco legal e reputacional para a empresa Ambientes corporativos exigem **arquiteturas suportadas oficialmente**, com trilhas de auditoria e governança nativas. Por esse motivo, seguimos exclusivamente arquiteturas suportadas oficialmente pela Microsoft e alinhadas às melhores práticas de segurança e governança.