Compartilhar via

Perfis de entidade de serviço para aplicativos multilocatário no Power BI Embedded

  • Artigo

Este artigo explica como um ISV ou qualquer outra Power BI Embedded proprietário do aplicativo com muitos clientes pode usar perfis de entidade de serviço para mapear e gerenciar os dados de cada cliente como parte de sua inserção do Power BI para a solução de clientes. Os perfis da entidade de serviço permitem que o ISV crie aplicativos escalonáveis que permitem um melhor isolamento de dados do cliente e estabelecem limites de segurança mais rígidos entre os clientes. Este artigo aborda as vantagens e as limitações dessa solução.

Observação

Às vezes, a palavra locatário no Power BI pode se referir a um locatário Microsoft Entra. No entanto, neste artigo usamos o termo multilocatário para descrever uma solução em que uma só instância de um aplicativo de software atende a vários clientes ou organizações (locatários) que exigem separação física e lógica de dados. Por exemplo, o construtor de aplicativos do Power BI pode alocar um workspace separado para cada um de seus clientes (ou locatários), como mostramos abaixo. Esses clientes não são necessariamente locatários do Microsoft Entra, portanto, não confunda o termo aplicativo multilocatário que usamos aqui com aplicativo multilocatário do Microsoft Entra.

Um perfil de entidade de serviço é um perfil criado por uma entidade de serviço. O aplicativo ISV chama as APIs do Power BI usando um perfil de entidade de serviço, conforme explicado neste artigo.

A entidade de serviço de aplicativo ISV cria um perfil diferente do Power BI para cada cliente, ou locatário. Quando um cliente visita o aplicativo ISV, o aplicativo usa o perfil correspondente para gerar um token de inserção que será usado para renderizar um relatório no navegador.

O uso de perfis de entidade de serviço permite que o aplicativo ISV hospede vários clientes em um único locatário do Power BI. Cada perfil representa um cliente no Power BI. Em outras palavras, cada perfil cria e gerencia o conteúdo do Power BI para dados de um cliente específico.

Diagrama de Perfis SP e multilocatário.

Observação

Este artigo destina-se a organizações que desejam configurar um aplicativo multilocatário usando perfis de entidade de serviço. Se sua organização já tiver um aplicativo com suporte par cenários multilocatário e você quiser migrar para o modelo de perfil da entidade de serviço, confira Migrar para o modelo de perfis da entidade de serviço.

A configuração do conteúdo do Power BI envolve as seguintes etapas:

Todas as etapas acima podem ser totalmente automatizadas usando APIs REST do Power BI.

Pré-requisitos

Antes de criar perfis de entidade de serviço, você precisa:

  • Configure a entidade de serviço seguindo as três primeiras etapas de Inserir conteúdo do Power BI com entidade de serviço.
  • Em uma conta de administrador de locatários do Power BI, habilite a criação de perfis no locatário usando o mesmo grupo de segurança usado quando você criou a entidade de serviço.

Captura de tela do comutador do portal de administração.

Criar um perfil

Os perfis podem ser criados, atualizados e excluídos usando a API REST de Perfis.

Por exemplo, para criar um perfil:

POST https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…UUPA
Content-Type: application/json; charset=utf-8

{"displayName":"ContosoProfile"}

Uma entidade de serviço também pode chamar a API REST dos Perfis GET para obter uma lista de seus perfis. Por exemplo:

GET https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXA…UUPA

Permissões de perfil

Qualquer API que conceda permissão de usuário a itens do Power BI também pode conceder uma permissão de perfil para itens do Power BI. Por exemplo, Adicionar API de Usuário de Grupo pode ser usado para conceder uma permissão de perfil a um workspace.

Os seguintes pontos são importantes para entender ao usar perfis:

  • Um perfil pertence à entidade de serviço que o criou e só pode ser usado por essa entidade de serviço.
  • Um proprietário de perfil não pode ser alterado após a criação.
  • Um perfil não é uma identidade autônoma. Ele precisa da entidade de serviço Microsoft Entra token para chamar APIs REST do Power BI.

Os aplicativos ISV chamam AS APIs REST do Power BI fornecendo a entidade de serviço Microsoft Entra token no cabeçalho Autorização e a ID do perfil no cabeçalho X-PowerBI-Profile-Id. Por exemplo:

  GET https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
  Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUz.....SXBwasfg
  X-PowerBI-Profile-Id: 5f1aa5ed-5983-46b5-bd05-999581d361a5

Criar um workspace

Os workspaces do Power BI são usados para hospedar itens do Power BI, como relatórios e modelos semânticos.

Cada perfil precisa:

  • Criar pelo menos um workspace do Power BI

    POST https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
Authorization: Bearer eyJ0eXA…ZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "name": "ContosoWorkspace"
}

  • Conceda permissões de acesso ao workspace. O perfil da entidade de serviço deve ter acesso de Administrador ao workspace.

  • Atribuir o novo workspace a uma capacidade.

    POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/AssignToCapacity HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…wNkZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "capacityId": "13f73071-d6d3-4d44-b9de-34590f3e3cf6"
}

Leia mais sobre Auditoria do Power BI.

Importar relatórios e modelos semânticos

Use Power BI Desktop para preparar relatórios conectados aos dados do cliente ou dados de exemplo. Em seguida, você pode usar a API de Importação para importar o conteúdo para o workspace criado.

POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/imports?datasetDisplayName=ContosoSales HTTP/1.1
Authorization: Bearer eyJ...kZUiIsg
Content-Type: multipart/form-data; boundary="8b071895-b380-4769-9c62-7e586d717ed7"
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306
Fiddler-Encoding: base64

LS04YjA3MTg5NS1iMzgwLTQ3...Tg2ZDcxN2VkNy0tDQo=

Use parâmetros de conjunto de dados para criar um modelo semântico que possa se conectar a fontes de dados de clientes diferentes. Em seguida, use a API de Atualizar parâmetros para definir a quais dados de clientes o modelo semântico se conecta.

Definir a conexão do modelo semântico

Os ISVs geralmente armazenam os dados de seus clientes de uma das duas maneiras:

Em ambos os casos, você vai obter modelos semânticos de locatário único (um modelo semântico por cliente) no Power BI.

Um banco de dados separado para cada cliente

Se o aplicativo do ISV tiver um banco de dados separado para cada cliente, crie modelos semânticos de locatário único no Power BI. Forneça a cada modelo semântico os detalhes da conexão que apontem para o banco de dados correspondente. Use um dos seguintes métodos para evitar a criação de vários relatórios idênticos com detalhes de conexão diferentes:

  • Parâmetros do modelo semântico: Crie um modelo semântico com parâmetros nos detalhes da conexão (como nome do servidor SQL, nome do banco de dados SQL). Em seguida, importe um relatório para o workspace de um cliente e altere os parâmetros para corresponder aos detalhes do banco de dados do cliente.

  • Atualizar a API Datasource: crie um .pbix que aponta para uma fonte de dados com conteúdo de exemplo. Em seguida, importe o .pbix para o workspace de um cliente e altere os detalhes da conexão usando a API do Update Datasource.

Um banco de dados multilocatário

Se o aplicativo do ISV usar um banco de dados para todos os clientes, separe os clientes em diferentes modelos semânticos no Power BI da seguinte maneira:

Crie um relatório usando parâmetros que recuperam apenas os dados relevantes do cliente. Em seguida, importe um relatório para o workspace de um cliente e altere os parâmetros para recuperar apenas os dados do cliente relevante.

Inserir um relatório

Depois que a instalação for concluída, você poderá inserir relatórios de clientes e outros itens em seu aplicativo usando um token de inserção.

Quando um cliente visita seu aplicativo, use o perfil correspondente para chamar a API GenerateToken. Use o token de inserção gerado para inserir um relatório ou outros itens no navegador do cliente.

Para gerar um token de inserção:

POST https://api.powerbi.com/v1.0/myorg/GenerateToken HTTP/1.1
Authorization: Bearer eyJ0eXAiOi…kZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "datasets": [
    {
      "id": "3b1c8f74-fbbe-45e0-bf9d-19fce69262e3"
    }
  ],
  "reports": [
    {
      "id": "3d474b89-f2d5-43a2-a436-d24a6eb2dc8f"
    }
  ]
}

Aspectos de design

Antes de configurar uma solução multilocatário baseada em perfil, você deve estar ciente dos seguintes problemas:

Escalabilidade

Ao separar os dados em modelos semânticos distintos para cada cliente, você minimiza a necessidade de modelos semânticos grandes. Quando a capacidade fica sobrecarregada, ela pode remover modelos semânticos não usados para liberar a memória para modelos semânticos ativos. Essa otimização é impossível em um único modelo semântico grande. Ao usar vários modelos semânticos, você também pode separar os locatários em várias capacidades do Power BI, se necessário.

Sem perfis, uma entidade de serviço é limitada a 1.000 workspaces. Para superar esse limite, uma entidade de serviço pode criar vários perfis, em que cada perfil pode acessa/criar até 1.000 workspaces. Com vários perfis, o aplicativo ISV pode isolar o conteúdo de cada cliente usando contêineres lógicos distintos.

Depois que um perfil de entidade de serviço tiver acesso a um workspace, o acesso da entidade de serviço pai ao workspace poderá ser removido para evitar problemas de escalabilidade.

Mesmo com essas vantagens, você deve considerar a escala potencial do aplicativo. Por exemplo, o número de itens de workspace que um perfil pode acessar é limitado. Hoje, um perfil tem os mesmos limites que um usuário regular. Se o aplicativo ISV permitir que os usuários finais salvem uma cópia personalizada de seus relatórios inseridos, o perfil de um cliente terá acesso a todos os relatórios criados de todos os seus usuários. Esse modelo pode eventualmente exceder o limite.

Automação e complexidade operacional

Com a separação baseada em perfil do Power BI, pode ser necessário gerenciar centenas ou milhares de itens. Portanto, é essencial definir os processos que ocorrem com frequência no gerenciamento do ciclo de vida de seu aplicativo e verificar se você tem o conjunto certo de ferramentas para executar essas operações em grande escala. Algumas dessas operações incluem:

  • Adicionar um novo locatário
  • Atualizar um relatório para alguns ou todos os locatários
  • Atualizar o esquema do modelo semântico para alguns ou todos os locatários
  • Personalizações não planejadas para locatários específicos
  • Frequência de atualizações do modelo semântico

Por exemplo, criar um perfil e um workspace para um novo locatário é uma tarefa comum, que pode ser totalmente automatizada com a API REST do Power BI.

Necessidades do Multi-Geo

Suporte a Multi-Geo para o Power BI Embedded significa que ISVs e empresas que criam aplicativos usando o Power BI Embedded para inserir análise em seus aplicativos agora podem implantar os dados em diferentes regiões em todo o mundo. Para oferecer suporte a diferentes clientes em diferentes regiões, atribua o espaço de trabalho do cliente a uma capacidade na região desejada. Essa tarefa é uma operação simples que não envolve custo extra. No entanto, se você tiver clientes que precisam de dados de várias regiões, o perfil do locatário deverá duplicar todos os itens em vários workspaces atribuídos a diferentes capacidades regionais. Essa duplicação pode aumentar o custo e a complexidade de gerenciamento.

Por motivos de conformidade, talvez você ainda queira criar vários locatários do Power BI em regiões diferentes. Leia mais sobre várias áreas geográficas.

Redução de custos

Os desenvolvedores de aplicativo que usam o Power BI Embedded precisam adquirir uma capacidade do Power BI Embedded. O modelo de separação baseado em perfil funciona bem com capacidades porque:

  • O menor objeto que você pode atribuir de forma independente a uma capacidade é um workspace (você não pode atribuir um relatório, por exemplo). Ao separar os clientes por perfis, você obtém diferentes workspaces – um por cliente. Dessa forma, você obtém total flexibilidade para gerenciar cada cliente de acordo com suas necessidades de desempenho e otimizar a utilização da capacidade escalando para cima ou para baixo. Por exemplo, você pode gerenciar clientes grandes e essenciais com alto volume e volatilidade em uma capacidade separada para garantir um nível de serviço consistente, enquanto agrupa clientes menores em outra capacidade para otimizar custos.

  • Separar os workspaces também significa separar modelos semânticos entre locatários, para que os modelos semânticos possam vir em partes menores ao invés de em um único modelo semântico grande. Esses modelos menores permitem que a capacidade gerencie o uso de memória com mais eficiência. Modelos semânticos pequenos e não utilizados podem ser removidos após um período de inatividade, a fim de manter um bom desempenho.

Ao comprar uma capacidade, considere o limite de atualizações paralelas, pois os processos de atualização podem precisar de capacidade adicional quando você tem vários modelos semânticos.

Segurança em nível de linha

Este artigo explica como usar perfis para criar um modelo semântico separado para cada cliente. Como alternativa, os aplicativos do ISV podem armazenar todos os dados de clientes em um grande modelo semântico e usar a RLS (segurança em nível de linha) para proteger os dados de cada cliente. Essa abordagem pode ser conveniente para ISVs que têm relativamente poucos clientes e modelos semânticos de pequeno a médio porte porque:

  • Há apenas um relatório e um modelo semântico a serem mantidos
  • O processo de integração para novos clientes pode ser simplificado

No entanto, antes de usar o RLS, verifique se você entende suas limitações. Todos os dados para todos os clientes estão em um grande modelo semântico do Power BI. Esse modelo semântico é executado em uma única capacidade com seu próprio dimensionamento e outras limitações.

Mesmo que você use perfis de entidade de serviço para separar os dados dos clientes, você ainda poderá usar a RLS dentro do modelo semântico de um único cliente para dar a diferentes grupos acesso a diferentes partes dos dados. Por exemplo, você pode usar o RLS para impedir que membros de um departamento acessem dados de outro departamento na mesma organização.

Considerações e limitações

  • Os Perfis da Entidade de Serviço só têm suporte por meio da API REST do Power BI, do SDK do .NET do Power BI e do ponto de extremidade XMLA e do TOM (Modelo de Objeto Tabular) ao usar as bibliotecas de clientes do Analysis Services versão 16.0.139.27 ou superior. Não há suporte para perfis de entidade de serviço no Power BI por meio do ponto de extremidade XMLA ou do TOM (Modelo de Objeto Tabular) com bibliotecas de cliente mais antigas.
  • Não há suporte para perfis de entidade de serviço com AAS (Azure Analysis Services) no modo de conexão dinâmica.
  • O máximo de perfis que uma única entidade de serviço pode ter é 100.000.

Limitações de capacidade do Power BI

Gerenciar entidades de serviço

Alterar uma entidade de serviço

No Power BI, um perfil pertence à entidade de serviço que o criou. Isso significa que um perfil não pode ser compartilhado com outras entidades de segurança. Com essa limitação, se você quiser alterar a entidade de serviço por qualquer motivo, precisará recriar todos os perfis e fornecer aos novos perfis acesso aos workspaces relevantes. Geralmente, o aplicativo ISV precisa salvar um mapeamento entre uma ID de perfil e uma ID do cliente para escolher o perfil certo quando necessário. Se você alterar a entidade de serviço e recriar os perfis, as IDs também serão alteradas e talvez seja necessário atualizar o mapeamento no banco de dados do aplicativo ISV.

Excluir uma entidade de serviço

Aviso

Tenha muito cuidado ao excluir uma entidade de serviço. Você não deseja perder dados acidentalmente de todos os seus perfis associados.

Se você excluir a entidade de serviço no active directory, todos os seus perfis no Power BI serão excluídos. No entanto, o Power BI não excluirá o conteúdo imediatamente, portanto, o administrador do locatário ainda pode acessar os workspaces. Tenha cuidado ao excluir uma entidade de serviço usada em um sistema de produção, especialmente quando você criou perfis usando essa entidade de serviço no Power BI. Se você excluir uma entidade de serviço que criou perfis, lembre-se de que precisará recriar todos os perfis, fornecer aos novos perfis acesso aos workspaces relevantes e atualizar as IDs de perfil no banco de dados de aplicativo ISV.

Separação de dados

Quando os dados são separados por perfis de entidade de serviço, um mapeamento simples entre um perfil e um cliente impede que um cliente veja o conteúdo de outro cliente. O uso de uma única entidade de serviço exige que a entidade de serviço tenha acesso a todos os diferentes workspaces em todos os perfis.

Para adicionar uma separação extra, atribua uma entidade de serviço separada a cada locatário, em vez de ter uma única entidade de serviço acessando vários workspaces usando perfis diferentes. Atribuir entidades de serviço separadas tem várias vantagens, incluindo:

  • Um erro humano ou um vazamento de credenciais não fará com que os dados de vários locatários sejam expostos.
  • A rotação de certificados pode ser feita separadamente para cada locatário.

No entanto, o uso de várias entidades de serviço vem com um alto custo de gerenciamento. Selecione esse caminho somente se você precisar da separação extra. Lembre-se de que a configuração de quais dados mostrar a um usuário final é definida quando você gera o token de incorporação, um processo somente de back-end que os usuários finais não podem ver ou alterar. Solicitar um token de inserção usando um perfil específico do locatário gerará um token de inserção para esse perfil específico, o que lhe dará separação do cliente no consumo.

Um relatório, vários modelos semânticos

Em geral, você tem um relatório e um modelo semântico por locatário. Se você tiver centenas de relatórios, terá centenas de modelos semânticos. Às vezes, você pode ter um formato de relatório, com modelos semânticos diferentes (por exemplo, parâmetros diferentes ou detalhes de conexão). Sempre que tiver uma nova versão do relatório, você precisará atualizar todos os relatórios para todos os locatários. Embora você possa automatizar isso, é mais fácil gerenciar se você tiver apenas uma cópia do relatório. Crie um workspace que contém o relatório a inserir. Durante um runtime de sessão, associe o relatório ao modelo semântico específico do locatário. Leia associações dinâmicas para obter mais detalhes.

Personalizando e criando conteúdo

Ao criar conteúdo, considere cuidadosamente quem tem permissão para editá-lo. Se você permitir que vários usuários em cada locatário editem, será fácil exceder as limitações do modelo semântico. Se você decidir dar aos usuários capacidade de edição, monitore de perto a geração de conteúdo e aumentar conforme necessário. Pelo mesmo motivo, não recomendamos o uso dessa funcionalidade para personalização do conteúdo, quando cada usuário pode fazer pequenas alterações em um relatório e salvá-lo por conta própria. Se o aplicativo ISV permitir personalização de conteúdo, considere introduzir políticas de retenção de workspace para conteúdo específico do usuário. As políticas de retenção facilitam a exclusão de conteúdo quando os usuários mudam para uma nova posição, deixam a empresa ou param de usar a plataforma.

Identidade gerenciada do sistema

Em vez de uma entidade de serviço, você pode usar umaidentidade gerenciada atribuída pelo usuário ou atribuída pelo sistema para criar perfis. As identidades gerenciadas reduzem a necessidade de segredos e certificados.

Tenha cuidado ao usar uma identidade gerenciada pelo sistema porque:

  • Se uma identidade gerenciada atribuída pelo sistema for desativada acidentalmente, você perderá o acesso aos perfis. Essa situação é semelhante a um caso em que uma entidade de serviço é excluída.
  • Uma identidade gerenciada atribuída pelo sistema está conectada a um recurso no Azure (aplicativo Web). Se você excluir o recurso, a identidade será excluída.
  • O uso de vários recursos (diferentes aplicativos Web em regiões diferentes) resultará em várias identidades que precisam ser gerenciadas separadamente (cada identidade terá seus próprios perfis).

Devido às considerações acima, recomendamos que você use uma identidade gerenciada atribuída pelo usuário.

Exemplo

Para ver um exemplo de como usar perfis de entidade de serviço para gerenciar um ambiente multilocatário com o Power BI e a inserção Aplicativo Possui Dados, baixe o repositório Aplicativo possui dados multilocatário do Power BI Dev Camp (site de terceiros).

Conteúdo relacionado