Partilhar via

Perfis de entidade de serviço para aplicativos de multilocação no Power BI Embedded

  • Artigo

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

Nota

A palavra locatário no Power BI às vezes pode se referir a um locatário do Microsoft Entra. Neste artigo, no entanto, usamos o termo multilocação para descrever uma solução em que uma única 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 espaço de trabalho separado para cada um de seus clientes (ou locatários), conforme 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 o aplicativo multilocatário 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 incorporaçã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 os dados de um cliente específico.

Diagrama de Perfis SP e multilocação.

Nota

Este artigo destina-se a organizações que desejam configurar um aplicativo multilocatário usando perfis de entidade de serviço. Se a sua organização já tiver um aplicativo que ofereça suporte à multilocação e você quiser migrar para o modelo de perfil da entidade de serviço, consulte 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 Incorporar conteúdo do Power BI com a entidade de serviço.
  • A partir de uma conta de administrador de locatário do Power BI, habilite a criação de perfis no locatário usando o mesmo grupo de segurança usado quando criou a entidade de serviço.

Captura de ecrã do interruptor 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 de 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 uma permissão de usuário para 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 espaço de trabalho.

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 independente. Ele precisa do token Microsoft Entra da entidade de serviço para chamar APIs REST do Power BI.

Os aplicativos ISV chamam APIs REST do Power BI fornecendo o token Microsoft Entra da entidade de serviço no cabeçalho Authorization 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 uma área de trabalho

Os espaços de trabalho 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 espaço de trabalho 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 espaço de trabalho. O perfil da entidade de serviço deve ter acesso de administrador ao espaço de trabalho.

  • Atribuir o espaço de trabalho 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 espaços de trabalho do Power BI.

Importar relatórios e modelos semânticos

Use o Power BI Desktop para preparar relatórios conectados aos dados ou dados de exemplo do cliente. Em seguida, você pode usar a API de importação para importar o conteúdo para o espaço de trabalho 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 diferentes fontes de dados de clientes. Em seguida, use a API de parâmetros de atualização 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 duas maneiras:

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

Uma base de dados separada para cada cliente

Se o aplicativo 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 detalhes de conexão que apontem para seu 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 espaço de trabalho de um cliente e altere os parâmetros para corresponder aos detalhes do banco de dados do cliente.

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

Um único banco de dados multilocatário

Se o aplicativo ISV usar um banco de dados para todos os seus clientes, separe os clientes em modelos semânticos diferentes 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 espaço de trabalho de um cliente e altere os parâmetros para recuperar apenas os dados relevantes do cliente.

Incorporar um relatório

Após a conclusão da configuração, você pode incorporar relatórios de clientes e outros itens em seu aplicativo usando um token de incorporação.

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

Para gerar um token de incorporaçã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"
    }
  ]
}

Aspetos do design

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

Escalabilidade

Ao separar os dados em modelos semânticos separados 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 utilizados para liberar memória para modelos semânticos ativos. Essa otimização é impossível para um único modelo semântico grande. Usando vários modelos semânticos, você também pode separar locatários em várias capacidades do Power BI, se necessário.

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

Quando um perfil de entidade de serviço tem acesso a um espaço de trabalho, o acesso da entidade de serviço pai ao espaço de trabalho pode ser removido para evitar problemas de escalabilidade.

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

Automação e complexidade operacional

Com a separação baseada em perfil do Power BI, talvez seja necessário gerenciar centenas ou milhares de itens. Portanto, é importante definir os processos que acontecem com frequência no gerenciamento do ciclo de vida do aplicativo e garantir que você tenha o conjunto certo de ferramentas para fazer essas operações em escala. Algumas dessas operações incluem:

  • Adicionar um novo inquilino
  • Atualizar um relatório para alguns ou todos os inquilinos
  • Atualizando 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 espaço de trabalho para um novo locatário é uma tarefa comum, que pode ser totalmente automatizada com a API REST do Power BI.

Necessidades Multi-Geo

O suporte multigeográfico para o Power BI Embedded significa que ISVs e organizações que criam aplicativos usando o Power BI Embedded para incorporar análises em seus aplicativos agora podem implantar seus dados em diferentes regiões ao redor do 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. Esta tarefa é uma operação simples que não envolve custos adicionais. No entanto, se você tiver clientes que precisam de dados de várias regiões, o perfil do locatário deve duplicar todos os itens em vários espaços de trabalho atribuídos a diferentes capacidades regionais. Essa duplicação pode aumentar os custos e a complexidade do gerenciamento.

Por motivos de conformidade, você ainda pode querer criar vários locatários do Power BI em regiões diferentes. Leia mais sobre multi-geo.

Eficiência de custos

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

  • O menor objeto que você pode atribuir independentemente a uma capacidade é um espaço de trabalho (não é possível atribuir um relatório, por exemplo). Ao separar os clientes por perfis, você obtém diferentes espaços de trabalho - 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 aumentando ou diminuindo a escala. Por exemplo, você pode gerenciar clientes grandes e essenciais com alto volume e volatilidade em uma capacidade separada para garantir um nível consistente de serviço, enquanto agrupa clientes menores em outra capacidade para otimizar custos.

  • Separar espaços de trabalho também significa separar modelos semânticos entre locatários para que os modelos de dados estejam em partes menores, em vez de um único modelo semântico grande. Esses modelos menores permitem a capacidade de gerenciar o uso da memória de forma mais eficiente. 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 do número de atualizações paralelas, pois os processos de atualização podem precisar de capacidade extra quando você tiver vários modelos semânticos.

Segurança ao Nível da Linha

Este artigo explica como usar perfis para criar um modelo semântico separado para cada cliente. Como alternativa, os aplicativos ISV podem armazenar todos os dados de seus clientes em um modelo semântico grande e usar segurança em nível de linha (RLS) 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 para manter
  • O processo de integração para novos clientes pode ser simplificado

Antes de usar a SPI, no entanto, certifique-se de entender suas limitações. Todos os dados de 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 se você usar perfis de entidade de serviço para separar os dados de seus clientes, ainda poderá usar a RLS dentro de um modelo semântico de um único cliente para dar acesso a diferentes grupos a diferentes partes dos dados. Por exemplo, você pode usar a 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 Power BI .NET e do ponto de extremidade XMLA e do Modelo de Objeto Tabular (TOM) ao usar bibliotecas de cliente do Analysis Services versão 16.0.139.27 ou superior. Os Perfis da Entidade de Serviço não são suportados no Power BI através do ponto de extremidade XMLA ou do Modelo de Objeto Tabular (TOM) com bibliotecas de cliente mais antigas.
  • Os perfis da entidade de serviço não são suportados com o Azure Analysis Services (AAS) no modo de conexão ao vivo.
  • O máximo de perfis que uma única entidade de serviço pode ter é de 100.000.

Limitações de capacidade do Power BI

  • Cada capacidade só pode usar sua memória alocada e núcleos V, de acordo com o SKU adquirido. Para o tamanho de modelo semântico recomendado para cada SKU, consulte modelos semânticos grandes Premium.
  • Para usar um modelo semântico maior que 10 GB, use uma capacidade Premium e habilite a configuração Modelos semânticos grandes.
  • Para o número de atualizações que podem ser executadas simultaneamente em uma capacidade, consulte o gerenciamento e a otimização de recursos.

Gerir principais 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. 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 espaços de trabalho relevantes. Muitas vezes, o aplicativo ISV precisa salvar um mapeamento entre um ID de perfil e um ID de 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 quer perder acidentalmente dados de todos os seus perfis associados.

Se você excluir a entidade de serviço no diretório ativo, todos os seus perfis no Power BI serão excluídos. No entanto, o Power BI não excluirá o conteúdo imediatamente, para que o administrador do locatário ainda possa acessar os espaços de trabalho. 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 espaços de trabalho relevantes e atualizar as IDs de perfil no banco de dados do 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 o cliente impede que um cliente veja o conteúdo de outro cliente. O uso de uma única entidade de serviço requer que a entidade de serviço tenha acesso a todos os diferentes espaços de trabalho em todos os perfis.

Para adicionar 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 espaços de trabalho usando perfis diferentes. A atribuição de 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 este caminho somente se 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 incorporação usando um perfil específico do locatário gerará um token de incorporação para esse perfil específico, o que lhe dará separação do cliente no consumo.

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

Geralmente, 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, terá de atualizar todos os relatórios para todos os inquilinos. Embora você possa automatizar isso, é mais fácil de gerenciar se você tiver apenas uma cópia do relatório. Crie um espaço de trabalho que contenha o relatório a ser incorporado. Durante um tempo de execução da sessão, vincule o relatório ao modelo semântico específico do locatário. Leia as ligações dinâmicas para obter mais detalhes.

Personalização e criação de 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, é fácil exceder as limitações do modelo semântico. Se você decidir dar aos usuários recursos de edição, monitore de perto a geração de conteúdo deles e aumente a escala conforme necessário. Pelo mesmo motivo, não recomendamos o uso desse recurso para personalização de conteúdo, onde cada usuário pode fazer pequenas alterações em um relatório e salvá-lo para si mesmo. Se o aplicativo ISV permitir a personalização de conteúdo, considere a introdução de políticas de retenção de espaço de trabalho 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, saem da empresa ou param de usar a plataforma.

Identidade gerenciada pelo sistema

Em vez de uma entidade de serviço, você pode usar uma identidade gerenciada atribuída pelo usuário ou pelosistema 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 ao sistema for desativada acidentalmente, você perderá o acesso aos perfis. Esta situação é semelhante a um caso em que uma entidade de serviço é excluída.
  • Uma identidade gerenciada atribuída ao 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 (aplicativos Web diferentes 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 obter um exemplo de como usar perfis de entidade de serviço para gerenciar um ambiente multilocatário com a incorporação do Power BI e App-Owns-Data, baixe o repositório multilocatário de dados do App possui do Power BI Dev Camp (site de terceiros).

Conteúdos relacionados