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.