Planejamento de implementação do Power BI: planejamento de segurança do criador de conteúdo

Este artigo de planejamento de segurança descreve estratégias para criadores de conteúdo responsáveis pela criação de modelos semânticos, fluxos de dados, datamarts, relatórios ou painéis. Ele é voltado principalmente para:

• Administradores do Power BI: os administradores responsáveis por supervisionar o Power BI na organização.
• Equipe do Centro de Excelência, de TI e de BI: as equipes que também são responsáveis por supervisionar o Power BI. Talvez seja necessário colaborar com administradores do Power BI, equipes de segurança da informação e outras equipes relevantes.
• Criadores e proprietários de conteúdo: criadores de BI de autoatendimento que precisam criar, publicar, proteger e gerenciar conteúdo que outras pessoas consomem.

A série de artigos tem a finalidade de expandir o conteúdo no white paper sobre segurança do Power BI. Embora o white paper de segurança do Power BI se concentre em tópicos técnicos importantes, como autenticação, residência de dados e isolamento de rede, o objetivo principal da série é fornecer considerações e decisões para ajudá-lo a planejar a segurança e a privacidade.

Em uma organização, muitos usuários são criadores de conteúdo. Criadores de conteúdo produzem e publicam conteúdo que é exibido por outras pessoas. Eles são o foco deste artigo.

Estratégia para criadores de conteúdo

A base de um sistema de BI de autoatendimento bem controlado começa com criadores e proprietários de conteúdo. Eles criam e validam relatórios e modelos semânticos. Em muitos casos, os criadores de conteúdo também configuram permissões para gerenciar a segurança do conteúdo.

Para fins de segurança e permissões, considere que há dois tipos de criadores de conteúdo: criadores de dados e criadores de relatórios. Eles podem ser responsáveis por criar e gerenciar conteúdo de BI corporativo ou de BI de autoatendimento.

Criadores de dados

Um criador de dados é qualquer usuário do Power BI que cria modelos semânticos, fluxos de dados ou datamarts.

Veja alguns cenários comuns relacionados a criadores de dados.

• Criar um novo modelo semântico: criar e testar um novo modelo semântico no Power BI Desktop. Ele é em seguida publicado no serviço do Power BI para que possa ser usado como um modelo semântico compartilhado por muitos relatórios. Para saber mais sobre a reutilização de modelos semânticos compartilhados, consulte o cenário de uso da BI de autoatendimento gerenciada.
• Estender e personalizar um modelo semântico: criar uma conexão dinâmica a um modelo semântico compartilhado existente no Power BI Desktop. Converta a conexão dinâmica em um modelo local, o que permite estender o design do modelo com novas tabelas ou colunas. Para saber mais sobre como estender e personalizar modelos semânticos compartilhados, consulte o cenário de uso da BI de autoatendimento gerenciada personalizável.
• Criar um novo fluxo de dados: no serviço do Power BI, criar um novo fluxo de dados para que ele possa ser usado como fonte por muitos modelos semânticos. Para saber mais sobre a reutilização de atividades de preparação de dados, consulte o cenário de uso de preparação de dados de autoatendimento.
• Criar um datamart. No serviço do Power BI, crie um novo datamart.

Muitas vezes, criadores de dados são encontrados em equipes de BI corporativo e no COE (Centro de Excelência). Eles também desempenham um papel fundamental em unidades de negócios e departamentos descentralizados que mantêm e gerenciam os próprios dados.

Para ver outras considerações sobre BI orientado por negócios, BI de autoatendimento gerenciado e BI empresarial, consulte o artigo Propriedade e gerenciamento de conteúdo.

Criadores de relatório

Os criadores de relatórios criam relatórios e dashboards para visualizar dados provenientes de modelos semânticos existentes.

Veja alguns cenários comuns relacionados a criadores de relatórios.

• Criar um relatório, incluindo um modelo de dados: crie e teste um relatório e um modelo de dados no Power BI Desktop. O arquivo do Power BI Desktop que contém uma ou mais páginas de relatório e inclui um modelo de dados é publicado no serviço do Power BI. Os criadores de conteúdo novo costumam usar esse método antes de conhecerem o uso dos modelos semânticos compartilhados. Também é apropriado para raros casos de uso que não têm necessidade de reutilização de dados.
• Criar um relatório de conexão dinâmica: criar um relatório do Power BI que se conecta a um modelo semântico compartilhado no serviço do Power BI. Para saber mais sobre a reutilização de modelos semânticos compartilhados, consulte o cenário de uso da BI de autoatendimento gerenciada.
• Criar uma pasta de trabalho do Excel conectada: criar um relatório do Excel novo que se conecta a um modelo semântico compartilhado no serviço do Power BI. Experiências conectadas no Excel, em vez de downloads de dados, são altamente incentivadas.
• Criar um relatório do DirectQuery: crie um relatório do Power BI que se conecta a uma fonte de dados com suporte no modo DirectQuery. Uma situação em que esse método é útil é quando você deseja aproveitar a segurança do usuário implementada pelo sistema de origem.

Há criadores de relatórios em todas as unidades de negócios da organização. Geralmente, há muito mais criadores de relatórios em uma organização do que criadores de dados.

Permissões para criadores

Esta seção descreve as permissões mais comuns para criadores de dados e de relatórios.

Ela não tem a finalidade de ser uma lista completa de todas as permissões possíveis. Em vez disso, o objetivo é ajudar no planejamento de sua estratégia para dar suporte a diferentes tipos de criadores de conteúdo. Seu objetivo deve ser seguir o princípio de privilégios mínimos. Esse princípio permite permissões suficientes para que os usuários sejam produtivos, mas sem o provisionamento excessivo de permissões.

Criando conteúdo

As permissões a seguir geralmente são necessárias para criar conteúdo.

Permissão	Cria relatórios	Criador de modelos semânticos	Criador de fluxo de dados	Criador de datamart
Acesso à fonte de dados subjacente
Permissões de Leitura e de Build de modelos semânticos
Permissão de Leitura do fluxo de dados (quando um fluxo de dados é usado como fonte, por meio da função Visualizador do workspace)
Acesso em que o arquivo original do Power BI Desktop é armazenado
Permissão para usar visuais personalizados

Publicando permissões de conteúdo

As permissões a seguir geralmente são necessárias para publicar conteúdo.

Permissão	Cria relatórios	Criador de modelos semânticos	Criador de fluxo de dados	Criador de datamart
Função no workspace: Colaborador, Membro ou Administrador
Permissão de Gravação de modelos semânticos (quando o usuário não pertence a uma função do workspace)
Função no pipeline de implantação para publicar itens (opcional)

Atualizando dados

As permissões a seguir geralmente são necessárias para atualizar dados.

Permissão	Cria relatórios	Criador de modelos semânticos	Criador de fluxo de dados	Criador de datamart
Proprietário atribuído (quem definiu as configurações ou assumiu o item)
Acesso à fonte de dados subjacente (quando um gateway não é usado)
Acesso à fonte de dados em um gateway (quando a origem é local ou em uma rede virtual)

O restante deste artigo traz considerações sobre permissões do criador de conteúdo.

Lista de verificação – ao planejar a estratégia de segurança para criadores de conteúdo, as principais decisões e ações incluem:

Descobrir conteúdo para criadores

Os usuários podem contar com a descoberta de dados para localizar modelos semânticos e datamarts. A descoberta de dados é um recurso do Power BI que permite que criadores de conteúdo localizem ativos de dados existentes, mesmo quando eles não têm nenhuma permissão para esse conteúdo.

A descoberta de dados existentes é útil para:

• Criadores de relatório que desejam usar um modelo semântico existente para um novo relatório.
• Criadores de relatório que desejam consultar dados de um datamart existente.
• Criadores de modelo semântico que desejam usar um modelo semântico existente para um novo modelo composto.

Você pode configurar um modelo semântico ou um datamart como detectável quando ele foi endossado (certificado ou promovido). Quando ele é detectável, os criadores de conteúdo podem encontrá-lo no hub de dados.

Um criador de conteúdo também pode solicitar acesso ao modelo semântico ou ao datamart. Essencialmente, uma solicitação de acesso solicita a permissão Build, que é necessária para criar conteúdo com base nele. Ao responder a solicitações de acesso, considere usar grupos em vez de usuários individuais. Para saber mais sobre como usar grupos para essa finalidade, consulte Fluxo de trabalho de solicitação de acesso para consumidores.

Considere os três exemplos a seguir.

• O modelo semântico Resumo de Vendas foi certificado. É a fonte confiável e autoritativa para acompanhamento de vendas. Muitos criadores de relatórios de autoatendimento na organização usam esse modelo semântico. Portanto, há muitos relatórios e modelos compostos baseados no modelo semântico. Para incentivar outros criadores a localizar e usar o modelo semântico, ele é definido como detectável.
• O modelo semântico Estatísticas de inventário está certificado. Ele é uma fonte confiável e autoritativa para análise de estoque. O modelo semântico e os relatórios relacionados são mantidos e distribuídos pela equipe de BI empresarial. Devido ao design complexo do modelo semântico, somente a equipe de BI empresarial tem permissão para criar e manter o conteúdo de estoque. Como o objetivo é desencorajar que os criadores de relatórios usem o modelo semântico, ele não é definido como detectável.
• O modelo semântico Bônus Executivos contém informações altamente confidenciais. As permissões para exibir ou atualizar esse modelo semântico são restritas a alguns usuários. Esse modelo semântico não é definido como detectável.

A captura de tela a seguir mostra um modelo semântico no hub de dados no serviço do Power BI. Especificamente, mostra um exemplo de uma mensagem de Solicitação de acesso para um modelo semântico detectável. Essa mensagem é mostrada quando o usuário não tem acesso no momento. A mensagem de Solicitação de acesso foi personalizada nas configurações do modelo semântico.

A mensagem de Solicitação de acesso diz: Para relatórios de vendas padrão do MTD/QTD/YTD, esse modelo semântico é a fonte autoritativa e certificada. Solicite acesso ao modelo semântico concluindo o formulário localizado em https://COE.contoso.com/RequestAccess. Você será solicitado a obter uma breve justificativa de negócios e o gerente do Centro de Excelência também será obrigado a aprovar a solicitação. O acesso será auditado a cada seis meses.

Há três configurações de locatário relacionadas à descoberta.

• A configuração de locatário Descobrir conteúdo permite que administradores do Power BI definam quais grupos de usuários têm permissão para descobrir dados. Ele é direcionado principalmente aos criadores de relatórios que talvez precisem localizar os modelos semânticos existentes ao criar relatórios. Também é útil para criadores de modelos semânticos que podem procurar dados existentes para serem usados no desenvolvimento de modelos compostos. Embora seja possível defini-la para grupos de segurança específicos, é uma boa ideia habilitar a configuração para toda a organização. A configuração da descoberta em modelos semânticos e fluxos de dados individuais controlará o que é detectável. Com menos frequência, você pode considerar restringir essa funcionalidade apenas a criadores de conteúdo aprovados.
• A configuração de locatário Tornar conteúdo certificado detectável permite que os administradores do Power BI definam quais grupos podem definir conteúdo como detectável (quando eles também têm permissão para editar o item, bem como para certificar o conteúdo, que é concedido pela configuração de locatário de Certificação). A capacidade de certificar conteúdo deve ser controlada de modo restrito. Na maioria dos casos, os mesmos usuários que têm permissão para certificar conteúdo devem ter permissão para defini-lo como detectável. Em algumas situações, talvez você queira restringir essa funcionalidade apenas a criadores de dados aprovados.
• A configuração de locatário Tornar conteúdo promovido detectável permite que os administradores do Power BI definam quais grupos podem definir conteúdo como detectável (quando eles também têm permissões para editar os dados). Como a capacidade de promover conteúdo está aberta a todos os criadores de conteúdo, na maioria dos casos, essa funcionalidade deve estar disponível para todos os usuários. Com menos frequência, você pode considerar restringir essa funcionalidade apenas a criadores de conteúdo aprovados.

Lista de verificação – ao planejar a descoberta de dados para criadores de conteúdo, as principais decisões e ações incluem:

Fluxo de trabalho de solicitação de acesso para criadores

Um usuário pode solicitar acesso a conteúdo de duas maneiras.

• Para consumidores de conteúdo: um usuário recebe um link para um relatório ou aplicativo existente no serviço do Power BI. Para exibir o item, o consumidor pode selecionar o botão Solicitar acesso. Para saber mais, confira o artigo Planejamento de segurança do consumidor de relatórios.
• Para criadores de conteúdo: o usuário descobre um modelo semântico ou datamart no hub de dados. Para criar um relatório ou um modelo composto com base nos dados existentes, o criador de conteúdo pode selecionar o botão Solicitar acesso. Essa experiência é o foco desta seção.

Por padrão, uma solicitação de acesso a um modelo semântico ou a um datamart vai para o proprietário. O proprietário é o usuário que agendou uma atualização de dados ou inseriu credenciais pela última vez. Depender de um usuário para processar solicitações de acesso pode ser aceitável para modelos semânticos de equipe. No entanto, isso pode não ser prático ou confiável.

Em vez de contar com um proprietário, você pode definir instruções personalizadas que são apresentadas aos usuários quando eles solicitam acesso a um modelo semântico ou datamart. Instruções personalizadas são úteis quando:

• O modelo semântico é definido como detectável.
• A aprovação da solicitação de acesso será feita por alguém diferente do proprietário dos dados.
• Há um processo em vigor que precisa ser seguido para solicitações de acesso.
• É necessário rastrear quem solicitou acesso, quando e por que por motivos de auditoria ou conformidade.
• É necessária uma explicação de como solicitar acesso, além de definir expectativas.

A captura de tela a seguir mostra um exemplo de configuração das instruções personalizadas que um usuário vê quando solicita a permissão Build. As instruções personalizadas diziam: Para relatórios de vendas padrão do MTD/QTD/YTD, esse modelo semântico é a fonte autoritativa e certificada. Solicite acesso ao modelo semântico concluindo o formulário localizado em https://COE.contoso.com/RequestAccess. Você será solicitado a obter uma breve justificativa de negócios e o gerente do Centro de Excelência também será obrigado a aprovar a solicitação. O acesso será auditado a cada seis meses.

Há muitas opções para criar um formulário. O Power Apps e o Microsoft Forms são opções com pouco código e fáceis de usar. Recomendamos que você crie um formulário de modo que não dependa de somente um usuário. É crucial que o formulário seja criado, gerenciado e monitorado pela equipe adequada.

Recomendamos que você crie informações úteis para:

• Criadores de conteúdo, para que saibam o que esperar quando solicitam acesso.
• Proprietários e administradores de conteúdo, para que saibam como gerenciar solicitações enviadas.

Lista de verificação – ao planejar o fluxo de trabalho Solicitar acesso, as principais decisões e ações incluem:

Criar e publicar conteúdo

Esta seção inclui aspectos de segurança que se aplicam a criadores de conteúdo.

Funções de workspace

Você concede acesso ao workspace adicionando usuários ou grupos (incluindo grupos de segurança, grupos do Microsoft 365 e listas de distribuição) a funções de workspace. Atribuir usuários a funções de workspace permite que você especifique o que eles podem fazer com o workspace e o respectivo conteúdo.

Como o objetivo principal de um workspace é a colaboração, o acesso ao workspace é mais relevante para usuários que são proprietários do conteúdo e o gerenciam. Ao começar a planejar as funções do workspace, é útil fazer a si mesmo as perguntas a seguir.

• Quais são as expectativas de como a colaboração ocorrerá no workspace?
• Quem será responsável por gerenciar o conteúdo no workspace?
• A intenção é atribuir usuários ou grupos individuais a funções do workspace?

Há quatro funções de workspace do Power BI: Administrador, Membro, Colaborador e Visualizador. As três primeiras funções são relevantes para criadores de conteúdo, que criam e publicam conteúdo. A função Visualizador é relevante para consumidores somente leitura.

As quatro permissões de função de workspace são aninhadas. Isso significa que os administradores de workspaces têm todos os recursos disponíveis para membros, colaboradores e visualizadores. Da mesma forma, os membros têm todos os recursos disponíveis para colaboradores e visualizadores. Os colaboradores têm todos os recursos disponíveis para os visualizadores.

Administrador do workspace

Usuários que recebem a função Administrador se tornam administradores do workspace. Eles podem gerenciar todas as configurações e executar todas as ações, incluindo adicionar ou remover usuários (incluindo outros administradores do workspace).

Os administradores do workspace podem atualizar ou excluir o aplicativo Power BI (se houver). Eles também podem permitir que colaboradores atualizem o aplicativo do workspace. Para saber mais, consulte Variações nas funções de workspace mais adiante neste artigo.

Tenha cuidado para garantir que apenas indivíduos confiáveis sejam administradores de workspace. Os administradores de workspace têm privilégios elevados. Eles têm acesso para exibir e gerenciar todo o conteúdo no workspace. Eles podem adicionar e remover usuários (incluindo outros administradores) a qualquer função do workspace. Também podem excluir o workspace.

Recomendamos que haja pelo menos dois administradores para que um deles sirva como backup caso o administrador primário fique indisponível. Um workspace que não tem um administrador é conhecido como workspace órfão. O status de órfão ocorre quando um usuário sai da organização e não há nenhum administrador alternativo atribuído ao workspace. Para saber mais sobre como detectar e corrigir workspaces órfãos, consulte o artigo Exibir workspaces.

Idealmente, você deve ser capaz de determinar quem é responsável pelo conteúdo do workspace avaliando quem são os administradores e os membros do workspace (e os contatos especificados para o workspace). No entanto, algumas organizações adotam uma estratégia de gerenciamento e propriedade de conteúdo que restringe a criação de workspaces a usuários ou grupos específicos. Normalmente, eles têm um processo de criação de espaço de trabalho estabelecido gerenciado pelo departamento de TI. Nesse caso, os administradores do espaço de trabalho podem ser o departamento de TI em vez dos usuários que criam e publicam diretamente o conteúdo.

Membro do workspace

Usuários que recebem a função Membro podem adicionar outros usuários ao workspace (mas não administradores). Eles também podem gerenciar permissões para todo o conteúdo no workspace.

Os membros do workspace podem publicar ou cancelar a publicação do aplicativo no workspace, compartilhar um item de workspace ou o aplicativo e permitir que outros usuários compartilhem itens de workspace do aplicativo.

Os membros do workspace devem ser limitados a usuários que precisam gerenciar a criação de conteúdo do workspace e publicar o aplicativo. Em alguns casos, os administradores do workspace desempenham essas tarefas, portanto talvez você não precise atribuir a função Membro a usuários ou grupos. Quando os administradores do workspace não estão diretamente relacionados ao conteúdo dele (por exemplo, porque a TI gerencia o processo de criação do workspace), os membros do workspace podem ser os verdadeiros proprietários responsáveis pelo conteúdo.

Colaborador do workspace

Usuários que recebem a função Colaborador podem criar, editar ou excluir conteúdo do workspace.

Colaboradores não podem atualizar o aplicativo do Power BI (quando existe um para o workspace), a menos que isso seja permitido pela configuração do workspace. Para saber mais, consulte Variações nas funções de workspace mais adiante neste artigo.

A maioria dos criadores de conteúdo na organização são colaboradores do workspace.

Visualizador do workspace

Usuários que recebem a função Visualizador podem exibir e interagir com todo o conteúdo do workspace.

A função Visualizador é relevante para consumidores somente leitura para pequenas equipes e cenários informais. Ela é totalmente descrita no artigo Planejamento de segurança do consumidor de relatórios.

Considerações sobre a propriedade do workspace

Considere um exemplo em que as ações a seguir são executadas para configurar um novo workspace.

1. Campeões específicos do Power BI e membros satélites do COE (Centro de Excelência) receberam permissão nas configurações de locatário para criar workspaces. Eles foram treinados em estratégias de organização e padrões de nomenclatura de conteúdo.
2. Você (um criador de conteúdo) envia uma solicitação para criar um workspace para um novo projeto que gerenciará. O workspace incluirá relatórios que acompanham o progresso do projeto.
3. Um campeão do Power BI de sua unidade de negócios recebe a solicitação. Ele determina que um novo workspace é justificado. Em seguida, ele cria um workspace e atribui ao grupo de segurança de campeões do Power BI (da unidade de negócios dele ) a função de Administrador do workspace.
4. O campeão do Power BI atribui a você (o criador de conteúdo) a função Membro do workspace.
5. Você atribui a um colega de confiança a função Membro do workspace para garantir que haja um backup caso você esteja ausente.
6. Você atribui a outros colegas a função Colaborador do workspace porque eles serão responsáveis por criar o conteúdo do workspace, incluindo modelos semânticos e relatórios.
7. Você atribui ao seu gerente a função Visualizador do workspace porque ele solicitou acesso para monitorar o progresso do projeto. O gerente gostaria de examinar o conteúdo no workspace antes de publicar um aplicativo.
8. Você assume a responsabilidade de gerenciar outras propriedades do workspace, como a descrição e os contatos. Você também assume a responsabilidade de gerenciar continuamente o acesso ao workspace.

O exemplo anterior mostra uma maneira eficaz de permitir que uma unidade de negócios descentralizada aja de modo independente. Também demonstra o princípio de privilégios mínimos.

Para conteúdo controlado, ou conteúdo crítico que é gerenciado de modo mais restrito, é uma melhor prática atribuir a grupos, em vez de contas de usuário individuais, funções de workspace. Dessa forma, você pode gerenciar a associação de grupo separadamente do workspace. No entanto, quando você atribui funções a grupos, é possível que os usuários recebam várias funções de espaço de trabalho (porque o usuário pertence a vários grupos). Nesse caso, as permissões efetivas são baseadas na função mais alta atribuída ao usuário. Para conferir mais considerações, consulte Estratégia para usar grupos.

Quando um workspace é de propriedade conjunta de vários indivíduos ou equipes, o gerenciamento do conteúdo pode ser complicado. Tente evitar cenários de propriedade de várias equipes separando workspaces. Assim, as responsabilidades são claras e as atribuições de função são simples de configurar.

Variações das funções de workspace

Há duas variações das quatro funções de workspace (descritas anteriormente).

• Por padrão, somente administradores e membros do workspace podem criar, publicar e atualizar o aplicativo para o workspace. A configuração Permitir que colaboradores atualizem o aplicativo deste workspace é uma configuração do nível do workspace que permite que administradores do workspace deleguem a colaboradores a capacidade de atualizar o aplicativo. No entanto, colaboradores não podem publicar um novo aplicativo nem alterar quem tem permissão para editá-lo. Essa configuração é útil quando você deseja que os colaboradores possam atualizar o aplicativo (quando há um para o workspace), mas não quer conceder as outras permissões disponíveis para membros.
• A configuração de locatário Bloquear a republicação e desabilitar a atualização de pacote permite apenas que os proprietários do modelo semântico publiquem atualizações. Quando habilitada, administradores, membros e colaboradores do workspace não podem publicar alterações, a menos que primeiro assumam o modelo semântico como proprietários. Como essa configuração se aplica a toda a organização, habilite-a com alguma cautela, pois ela afeta todos os modelos semânticos do locatário. Não deixe de comunicar aos criadores do modelo semântico o que esperar, pois ela altera o comportamento normal das funções de workspace.

Lista de verificação – ao planejar as funções do workspace, as principais decisões e ações incluem:

Permissões do criador de aplicativo

Criadores de conteúdo que são administradores ou membros do workspace podem criar e publicar um aplicativo do Power BI.

Um administrador de espaço de trabalho também pode especificar uma configuração no espaço de trabalho que permite que os colaboradores do espaço de trabalho atualizem o aplicativo. Trata-se de uma variação da segurança de função do workspace porque concede aos colaboradores uma outra permissão que eles normalmente não teriam. Essa configuração é definida por workspace.

Lista de verificação – ao planejar as permissões do criador de aplicativo, as principais decisões e ações incluem:

Permissões de fonte de dados

Quando um criador de dados inicia um novo projeto, as permissões necessárias para acessar fontes de dados externas são uma das primeiras considerações relacionadas à segurança. Ele também pode precisar de diretrizes sobre outros assuntos relacionados à fonte de dados, incluindo níveis de privacidade, consultas de bancos de dados nativos e conectores personalizados.

Acesso à fonte de dados

Quando um criador de dados cria um modelo semântico, um fluxo de dados ou um datamart, ele precisa se autenticar nas fontes de dados para recuperar dados. Normalmente, a autenticação envolve credenciais de usuário (conta e senha), que podem ser de uma conta de serviço.

Às vezes, é útil criar contas de serviço específicas para acessar fontes de dados. Verifique com o departamento de TI as diretrizes sobre como as contas de serviço devem ser usadas na organização. Quando elas são permitidas, o uso de contas de serviço pode:

• Centralizar as permissões necessárias para as fontes de dados.
• Reduzir o número de usuários individuais que precisam de permissões para uma fonte de dados.
• Evite falhas de atualização de dados quando um usuário sai da organização.

Ao acessar fontes de dados, aplique o princípio de privilégio mínimo para garantir que os usuários (ou contas de serviço) tenham permissão para ler apenas os dados de que precisam. Eles nunca devem ter permissão para executar modificações de dados. Os administradores de banco de dados que criam essas contas de serviço devem perguntar sobre as consultas e as cargas de trabalho esperadas e adotar medidas para garantir que as otimizações (como índices) e os recursos adequados estejam em vigor.

As credenciais (conta e senha) podem ser aplicadas de duas maneiras.

• Power BI Desktop: as credenciais são criptografadas e armazenadas localmente no computador do usuário.
• Serviço do Power BI: as credenciais são criptografadas e armazenadas com segurança para:
  • O modelo semântico (quando um gateway de dados não está em uso para acessar a fonte de dados).
  • A fonte de dados do gateway (quando um gateway padrão ou um serviço de gateway de rede virtual é usado para acessar a fonte de dados).

As credenciais são criptografadas e armazenadas separadamente do modelo de dados no Power BI Desktop e no serviço do Power BI. Essa separação de dados tem as vantagens de segurança a seguir.

• Isso facilita a reutilização de credenciais para vários modelos semânticos, fluxos de dados e datamarts.
• Quando alguém analisa os metadados de um modelo semântico, não é possível extrair as credenciais.
• No Power BI Desktop, outro usuário não pode se conectar à fonte de dados original para atualizar dados sem primeiro aplicar as credenciais.

Algumas fontes de dados dão suporte ao SSO (logon único), que pode ser definido ao inserir as credenciais no serviço do Power BI (para fontes de dados de gateway ou de modelos semânticos). Quando você habilita o SSO, o Power BI envia as credenciais do usuário autenticado à fonte de dados. Essa opção permite que o Power BI cumpra as configurações de segurança definidas na fonte de dados, como a segurança no nível da linha. O SSO é especialmente útil quando as tabelas no modelo de dados usam o modo de armazenamento DirectQuery.

Níveis de privacidade

Os níveis de privacidade de dados especificam os níveis de isolamento que definem o grau em que uma fonte de dados é isolada de outras fontes de dados. Quando definidos adequadamente, eles garantem que o Power Query transmita apenas dados compatíveis entre fontes. Quando o Power Query pode transmitir dados entre fontes de dados, isso pode resultar em consultas mais eficientes que reduzem o volume de dados enviados ao Power BI. Quando não é possível transmitir dados entre fontes de dados, isso pode resultar em um desempenho mais lento.

Há três níveis de privacidade.

• Privado: inclui dados confidenciais que precisam ser isolados de todas as outras fontes de dados. Esse nível é o mais restritivo. Os dados da fonte de dados privada não podem ser compartilhados com nenhuma outra fonte de dados. Por exemplo, um banco de dados de recursos humanos que contém valores dos salários dos funcionários deve ser definido com o nível de privacidade privado.
• Organizacional: isolada de todas as fontes de dados públicas, mas visível para outras fontes de dados organizacionais. Esse nível é o mais comum. Os dados de uma fonte de dados organizacional podem ser compartilhados com fontes de dados privadas ou com outras fontes de dados organizacionais. A maioria dos bancos de dados operacionais internos pode ser definida com o nível de privacidade Organizacional.
• Público: dados não confidenciais que podem ser visíveis para qualquer fonte de dados. Esse nível é o menos restritivo. Os dados de uma fonte de dados pública podem ser compartilhados com qualquer outra fonte de dados. Por exemplo, um relatório censitário obtido de um site do governo pode ser definido com o nível de privacidade público.

Ao combinar consultas de diferentes fontes de dados, é importante definir os níveis de privacidade corretos. Quando os níveis de privacidade são definidos corretamente, há o potencial de que os dados de uma fonte de dados sejam transmitidos para outra fonte de dados para consultar dados com eficiência.

Considere um cenário em que um criador de modelo semântico tem duas fontes de dados: uma pasta de trabalho do Excel e uma tabela em um Banco de Dados SQL do Azure. Ele quer filtrar os dados na tabela do Banco de Dados SQL do Azure usando um valor obtido da pasta de trabalho do Excel. A maneira mais eficiente do Power Query gerar uma instrução SQL para o Banco de Dados SQL do Azure é aplicar uma cláusula WHERE para executar a filtragem necessária. No entanto, essa instrução SQL conterá um predicado da cláusula WHERE com um valor obtido da pasta de trabalho do Excel. Se a pasta de trabalho do Excel contiver dados confidenciais, isso poderá representar uma violação de segurança porque o administrador do banco de dados poderia exibir a instrução SQL usando uma ferramenta de rastreamento. Embora seja menos eficiente, a alternativa é que o mecanismo de mashup do Power Query baixe todo o conjunto de resultados da tabela do banco de dados e execute a filtragem por conta própria no serviço do Power BI. Essa abordagem será lenta e menos eficiente, mas segura.

Os níveis de privacidade podem ser definidos para cada fonte de dados:

• Por modeladores de dados no Power BI Desktop.
• Por proprietários de modelos semânticos no serviço do Power BI (para fontes de dados de nuvem, que não exigem um gateway).
• Por criadores e proprietários da fonte de dados do gateway no serviço do Power BI (para fontes de dados de gateway).

Há uma opção de segurança do Power BI Desktop que permite ignorar os níveis de privacidade para aprimorar o desempenho. Você pode usar essa opção para aprimorar o desempenho de consulta ao desenvolver um modelo de dados quando não há risco de violação da segurança de dados (porque você está trabalhando com dados de desenvolvimento ou de teste que não são confidenciais). No entanto, essa configuração não é adotada pelo serviço do Power BI.

Para obter mais informações, confira Níveis de privacidade do Power BI Desktop.

Consultas de banco de dados nativo

Para criar consultas eficientes do Power Query, você pode usar uma consulta nativa para acessar dados. Uma consulta nativa é uma instrução escrita em uma linguagem compatível com a fonte de dados. Consultas nativas só têm suporte em fontes de dados específicas, que normalmente são bancos de dados relacionais, como o Banco de Dados SQL do Azure.

Elas podem representar um risco à segurança porque podem executar uma instrução SQL mal-intencionada. Uma instrução mal-intencionada pode executar modificações de dados ou excluir registros do banco de dados (quando o usuário tem as permissões necessárias na fonte de dados). Por esse motivo, por padrão, as consultas nativas exigem aprovação do usuário para serem executadas no Power BI Desktop.

Há uma opção de segurança do Power BI Desktop que permite desabilitar o requisito de pré-aprovação. Recomendamos que você deixe a configuração padrão que requer aprovação do usuário, especialmente quando prever que o arquivo do Power BI Desktop pode ser atualizado por outros usuários.

Conectores personalizados

Desenvolvedores podem usar o SDK do Power Query para criar conectores personalizados. Conectores personalizados permitem acesso a fontes de dados proprietárias ou implementam uma autenticação específica com extensões de dados personalizadas. Alguns conectores personalizados são certificados e distribuídos pela Microsoft como conectores certificados. Conectores certificados foram auditados e revisados para garantir que atendam a determinados requisitos de código especificados que a Microsoft testou e aprovou.

Há uma opção de segurança de extensão de dados do Power BI Desktop que restringe o uso de conectores não certificados. Por padrão, um erro é gerado quando é feita uma tentativa de carregar um conector não certificado. Quando é definida essa opção de permitir conectores não certificados, conectores personalizados são carregados sem validação ou aviso.

Recomendamos que você mantenha o nível de segurança da extensão de dados no nível mais elevado, que impede o carregamento de código não certificado. No entanto, pode haver casos em que você deseja carregar conectores específicos, talvez conectores que você desenvolveu ou conectores fornecidos a você por um consultor ou fornecedor confiável fora do caminho de certificação da Microsoft.

Lista de verificação – ao planejar as permissões da fonte de dados, as principais decisões e ações incluem:

Permissões de criador de modelos semânticos

Você pode atribuir a permissão para editar um modelos semântico a um usuário ou grupo de maneiras diferentes.

• Função de workspace: a atribuição de qualquer uma das funções de workspace fornece acesso a todos os modelos semânticos no workspace. A capacidade de exibir ou editar um modelo semântico existente depende da função de workspace que você atribui. Administradores, membros e colaboradores podem publicar ou editar conteúdo em um workspace.
• Links de permissão por item: se um link de compartilhamento foi criado para um relatório, a permissão para ler o modelo semântico (e, opcionalmente, compilar, gravar e/ou compartilhar) também é concedida indiretamente pelo link.
• Permissões de acesso direto por item: você pode atribuir a permissão de acesso direto a um modelo semântico específico.

Na captura de tela a seguir, observe as permissões atribuídas ao modelo semântico Dados de Call Center. Um usuário tem permissão de Leitura, que foi concedida usando permissões de acesso direto por item. Os usuários e grupos restantes têm permissões porque funções de workspace foram atribuídas a eles.

Permissões de modelo semântico

Você pode atribuir as seguintes permissões de modelo semântico.

• Leitura: direcionada principalmente aos consumidores de relatórios, essa permissão permite que um relatório consulte dados no modelo semântico. Para saber mais sobre as permissões para exibir conteúdo somente leitura, consulte o artigo Planejamento de segurança do consumidor de relatórios.
• Build: direcionada aos criadores de relatórios, essa permissão permite que os usuários criem relatórios com base no modelo semântico compartilhado. Para saber mais, consulte a seção Permissão do criador de relatórios mais adiante neste artigo.
• Gravação: Direcionada aos criadores de modelos semânticos que criam, publicam e gerenciam modelos semânticos, essa permissão permite que os usuários editem o modelo semântico. Ela é descrita posteriormente nesta seção.
• Recompartilhamento: direcionada a qualquer pessoa com uma permissão existente de modelo semântico, essa permissão permite que os usuários compartilhem o modelo semântico com outro usuário. Ela é descrita posteriormente nesta seção.

Um administrador ou membro do workspace pode editar as permissões de um modelo semântico.

Permissão de Leitura de modelo semântico

A permissão de leitura de modelo semântico é direcionada principalmente aos consumidores. Ela é necessária para que os usuários possam ver os dados exibidos em relatórios. Lembre-se de que os relatórios baseados no modelo semântico também precisam ter permissão de Leitura; caso contrário, o relatório não será carregado. Para saber mais sobre a configuração de permissões de Leitura de relatório, consulte o artigo Planejamento de segurança do consumidor de relatórios.

Permissão de Build de modelo semântico

Além da permissão de Leitura do modelo semântico, os criadores de conteúdo também precisam da permissão de Build de modelo semântico. Especificamente, a permissão Build permite aos criadores de relatórios:

• Criar novos relatórios do Power BI com base no modelo semântico.
• Conectar-se ao modelo semântico usando o recurso Analisar no Excel.
• Consultar o modelo semântico usando o ponto de extremidade XMLA.
• Exportar dados subjacentes do visual do relatório do Power BI (em vez dos dados resumidos recuperados pelo visual).
• Criar uma conexão DirectQuery a um modelo semântico do Power BI. Nesse caso, o novo modelo semântico se conecta a um ou mais modelos semânticos existentes do Power BI ( o que é conhecido como encadeamento). Para consultar modelos semânticos encadeados, o criador do modelo semântico precisará da permissão de Build para todos os modelos semânticos upstream. Para obter mais informações, consulte modelos semânticos encadeados mais adiante neste artigo.

Você pode conceder permissão de Build a um usuário ou grupo, direta ou indiretamente, de diferentes maneiras.

• Conceda permissão de Build:
  • Definindo permissões de modelo semântico na página configurações do modelo semântico no serviço do Power BI.
  • Definindo permissões de modelo semântico usando a API REST do Power BI.
• Conceda a permissão de Build indiretamente:
  • Compartilhando um relatório ou dashboard e definindo a opção para conceder permissão de Build de modelo semântico.
  • Publicando um aplicativo do Power BI e definindo a opção avançada (para um público-alvo) para conceder permissão de Build nos modelos semânticos relacionados.
  • Atribuir usuários às funções de workspace de Administrador, Membro ou Colaborador.

Definir a permissão de Build diretamente para um modelo semântico é apropriado quando você deseja gerenciar a segurança de modo granular, por item. Definir a permissão de Build indiretamente é apropriado quando os usuários que exibirão ou usarão o conteúdo por meio de um dos métodos indiretos também criarão conteúdo.

Permissão de Gravação de modelo semântico

Normalmente, a definição de permissões para quem pode editar e gerenciar modelos semânticos será feita atribuindo aos usuários a função de workspace de Administrador, Membro ou Colaborador. No entanto, também é possível definir a permissão de Gravação para um modelo semântico específico.

Recomendamos que você use funções de workspace sempre que possível, pois é a maneira mais simples de gerenciar e auditar permissões. Use as permissões de Gravação de modelo semântico por item quando você optar por criar menos workspaces e um workspace contiver modelos semânticos de diferentes áreas de assunto que exigem gerenciamento de permissões diferentes.

Permissão de Recompartilhamento de modelo semântico

A permissão de Recompartilhamento de modelo semântico permite que um usuário com uma permissão existente compartilhe o modelo semântico com outros usuários. Você pode conceder essa permissão quando o conteúdo no modelo semântico pode ser compartilhado livremente, com base no discernimento do usuário.

Em muitos casos, recomendamos limitar o uso da permissão de Recompartilhamento para garantir que as permissões de modelo semântico sejam controladas atentamente. Obtenha aprovação do(s) proprietário(s) do modelo semântico antes de conceder a permissão de Recompartilhamento.

Segurança de dados de modelo semântico

Você pode planejar criar menos modelos semânticos e relatórios impondo a segurança de dados. O objetivo é impor a segurança de dados com base na identidade do usuário que está exibindo o conteúdo.

Um criador de modelos semânticos pode impor a segurança de dados de duas maneiras.

• A RLS (segurança no nível da linha) permite que um modelador de dados restrinja o acesso a um subconjunto de dados.
• A OLS (segurança no nível do objeto) permite que um modelador de dados restrinja o acesso a tabelas e colunas específicas, bem como aos respectivos metadados.

A implementação da RLS e da OLS é voltada para os consumidores de relatórios. Para saber mais, confira o artigo Planejamento de segurança do consumidor de relatórios. Ele descreve como e quando a RLS e a OLS são impostas para consumidores que têm permissão somente de exibição do modelo semântico.

Para a RLS e a OLS voltadas para outros criadores de relatórios, confira a segurança de dados na seção Permissões do criador de relatórios mais adiante neste artigo.

Modelos semânticos encadeados

Os modelos semânticos do Power BI podem se conectar a outros modelos semânticos em um processo conhecido como encadeamento, que são conexões com modelos semânticos upstream. Para obter mais informações, confira Usando o DirectQuery para os modelos semânticos do Power BI e para o Analysis Services.

A configuração de locatário Permitir conexões DirectQuery a modelos semânticos do Power BI permite que os administradores do Power BI configurem quais grupos de criadores de conteúdo podem criar modelos semânticos encadeados. Se você não quiser impedir que os criadores de modelos semânticos os encadeiem, você poderá deixar essa configuração habilitada para toda a organização e contar com o acesso de workspace e com as permissões de modelo semântico para esse controle. Em alguns casos, você pode considerar restringir essa funcionalidade a criadores de conteúdo aprovados.

Consultas de API de modelo semântico

Em algumas situações, talvez você queira executar uma consulta DAX usando a API REST do Power BI. Por exemplo, talvez você queira executar validações de qualidade de dados. Para obter mais informações, consulte Conjuntos de dados – Executar consultas.

A configuração de locatário da API REST Executar Consultas do Conjunto de Dados permite que os administradores do Power BI definam quais grupos de usuários podem enviar consultas DAX usando a API REST do Power BI. Na maioria dos casos, você pode deixar essa configuração habilitada para toda a organização e contar com o acesso ao workspace e com as permissões de modelo semântico. Em alguns casos, você pode considerar restringir essa funcionalidade a criadores de conteúdo aprovados.

Lista de verificação – ao planejar as permissões do criador de modelos semânticos, as principais decisões e ações incluem:

Permissões do criador de relatórios

Criadores de relatórios precisam de acesso ao workspace para criar relatórios no serviço do Power BI ou publicá-los do Power BI Desktop. Eles precisam ser administradores, membros ou colaboradores no workspace de destino.

Sempre que possível, os criadores de relatórios devem usar um modelo semântico compartilhado existente (por meio de uma conexão dinâmica ou DirectQuery). Assim, o processo de criação de relatório é dissociado do processo de criação de modelos semânticos. Esse tipo de separação oferece muitos benefícios para cenários de segurança e de desenvolvimento em equipe.

Um criador de relatórios precisa ser um administrador, membro ou colaborador do workspace.

Ao contrário dos modelos semânticos, não há uma permissão de Gravação para relatórios. Para dar suporte a criadores de relatórios, as funções de workspace devem ser usadas. Por esse motivo, o design ideal do workspace é importante para equilibrar as necessidades de segurança e organização de conteúdo.

Permissões de Leitura e de Build para modelo semântico subjacente

Os criadores de relatório precisam ter permissões de Leitura e de Build nos modelos semânticos que seus relatórios usarão, o que inclui os modelos semânticos encadeados. Essa permissão pode ser concedida explicitamente nos modelos semânticos individuais ou pode ser concedida implicitamente para os modelos semânticos do workspace quando o criador do relatório é um administrador, membro ou colaborador do workspace.

A configuração de locatário Usar modelos semânticos entre workspaces permite que administradores do Power BI configurem quais grupos de usuários podem criar relatórios que usam modelos semânticos localizados em outros workspaces. Essa configuração tem como destino os criadores de modelo semântico e de relatórios. Normalmente, recomendamos que você deixe essa configuração habilitada para toda a organização e confie nas configurações de acesso ao workspace e nas permissões do modelo semântico. Dessa forma, você pode incentivar o uso de modelos semânticos existentes. Em alguns casos, você pode considerar restringir essa funcionalidade apenas aos criadores de conteúdo aprovados.

Há também a configuração de locatário Permitir conexões dinâmicas, que permite que administradores do Power BI configurem quais grupos de usuários podem criar conexões dinâmicas com modelos semânticos no Power BI Desktop ou no Excel. Ela é voltada especificamente para criadores de relatórios e também requer que eles tenham permissão de Leitura e de Build no modelo semântico que o relatório usará. Recomendamos que você deixe essa configuração habilitada para toda a organização e dependa do acesso ao workspace e das permissões de modelo semântico. Dessa forma, você pode incentivar o uso de modelos semânticos existentes. Em alguns casos, você pode considerar restringir essa funcionalidade apenas aos criadores de conteúdo aprovados.

Segurança de dados para um modelo semântico subjacente

A RLS e a OLS (descritas anteriormente neste artigo) são voltadas para consumidores de relatórios. No entanto, às vezes, também precisam ser impostas para criadores de relatórios. A criação de workspaces separados é justificada quando a RLS precisa ser imposta para criadores de relatórios e também para consumidores de relatórios.

Considere o cenário a seguir.

• Modelos semânticos compartilhados centralizados com RLS: a equipe de BI empresarial publicou modelos semânticos de vendas no workspace Dados de Vendas. Esses modelos semânticos impõem a RLS para mostrar os dados de vendas para a região de vendas atribuída do consumidor de relatórios.
• Criadores de relatórios de autoatendimento descentralizados: a unidade de negócios de vendas e marketing tem muitos analistas capazes que criam os próprios relatórios. Eles publicam relatórios no workspace Análise de Vendas.
• Permissões de Leitura e de Build para modelos semânticos: sempre que possível, os analistas usam os modelos semânticos do workspace Dados de Vendas para evitar a duplicação desnecessária de dados. Como os analistas têm apenas permissões de Leitura e de Build nesses modelos semânticos (sem permissões de gravação ou edição), a RLS é imposta para os criadores de relatórios (e também para os consumidores de relatórios).
• Editar permissões para o workspace de relatório: os analistas têm mais direitos no workspace de Análise de Vendas. As funções de administrador, membro ou colaborador do workspace permitem que eles publiquem e gerenciem seus relatórios.

Para saber mais sobre a RLS e a OLS, consulte o artigo Planejamento de segurança do consumidor de relatórios. Ele descreve como e quando a RLS e a OLS são impostas para consumidores que têm permissão somente de exibição do modelo semântico.

Conectando-se a modelos semânticos externos

Quando um criador de relatório se conecta a um modelo semântico compartilhado para seu relatório, ele geralmente se conecta a um modelo semântico compartilhado que foi publicado em seu locatário do Power BI. Quando a permissão é concedida, também é possível se conectar a um modelo semântico compartilhado em outro locatário. O outro locatário pode ser um parceiro, cliente ou fornecedor.

Essa funcionalidade é conhecida como compartilhamento de modelo semântico no local (também conhecido como compartilhamento de modelo semântico entre locatários). Os relatórios criados pelo criador de relatórios (ou modelos compostos criados por um criador de modelos semânticos) são armazenados e protegidos em seu locatário do Power BI usando seu processo normal. O modelo semântico compartilhado original permanece no locatário original do Power BI e todas as permissões são gerenciadas lá.

Para saber mais, consulte o artigo Planejamento de segurança no nível do locatário. Isso inclui informações sobre as configurações de locatário e as configurações do modelo semântico que fazem o compartilhamento externo funcionar.

Tabelas em destaque

No Power BI Desktop, os criadores de modelos semânticos podem definir uma tabela de modelo para se tornar uma tabela em destaque. Quando o modelo semântico é publicado no serviço do Power BI, os criadores de relatório podem usar a Galeria de Tipos de Dados do Excel para localizar a tabela em destaque, permitindo que adicionem dados da tabela em destaque para aumentar suas planilhas do Excel.

A configuração de locatário Permitir conexões com tabelas em destaque permite que os administradores do Power BI configurem quais grupos de usuários podem acessar tabelas em destaque. Ela é voltada para usuários do Excel que desejam acessar tabelas em destaque do Power BI em tipos de dados da organização do Excel. Recomendamos que você deixe essa configuração habilitada para toda a organização e dependa do acesso ao workspace e das permissões de modelo semântico. Dessa forma, você pode incentivar o uso de tabelas em destaque.

Permissões de visuais personalizados

Além dos visuais principais, os criadores de relatórios do Power BI podem usar visuais personalizados. No Power BI Desktop, visuais personalizados podem ser baixados no Microsoft AppSource. Eles também podem ser desenvolvidos internamente usando o SDK do Power BI e instalados abrindo o arquivo do visual (.pbviz).

Alguns visuais disponíveis para download no AppSource são visuais certificados. Os visuais certificados atendem a determinados requisitos de código especificados que a equipe do Power BI testou e aprovou. Os testes verificam se os visuais não acessam serviços ou recursos externos.

A configuração de locatário Permitir visuais criados pelo SDK do Power BI permite que os administradores do Power BI controlem quais grupos de usuários podem usar visuais personalizados.

Também há a configuração de locatário Adicionar e usar apenas visuais certificados, que permite que os administradores do Power BI bloqueiem o uso de visuais não certificados no serviço do Power BI. Essa configuração pode ser habilitada ou desabilitada para toda a organização.

O Power BI Desktop tem a opção de mostrar um aviso de segurança quando um criador de relatório adiciona um visual personalizado ao relatório. Os criadores de relatório podem desabilitar essa opção. Essa opção não testa se o visual é certificado.

Os administradores do Power BI podem aprovar e implantar visuais personalizados para suas organizações. Os criadores de relatórios podem descobrir, atualizar e usar esses visuais com facilidade. Os administradores podem gerenciar esses visuais atualizando as versões ou desabilitando e habilitando visuais personalizados específicos. Essa abordagem é útil quando você deseja disponibilizar um visual desenvolvido internamente para seus criadores de relatório ou quando adquire um visual personalizado de um fornecedor que não está no AppSource. Para saber mais, consulte Visuais organizacionais do Power BI.

Considere uma estratégia equilibrada de habilitar apenas visuais personalizados certificados na organização (com a configuração de locatário e a política de grupo descritas anteriormente), enquanto implanta visuais organizacionais para lidar com exceções.

Lista de verificação – ao planejar as permissões do criador de relatórios, as principais decisões e ações incluem:

Permissões do criador de fluxos de dados

Os fluxos de dados são úteis para centralizar a preparação de dados para que o trabalho feito no Power Query não seja repetido em muitos modelos semânticos. Eles são um bloco de construção para alcançar uma fonte única de verdade, impedir que os analistas precisem de acesso direto às fontes e ajudar a executar operações de ETL (extração, transformação e carregamento) em escala.

Um criador de fluxos de dados precisa ser um administrador, membro ou colaborador do workspace.

Para consumir um fluxo de dados (por exemplo, de um modelo de dados novo criado no Power BI Desktop ou em outro workspace), um criador de modelos semânticos pode pertencer a qualquer função de workspace, incluindo a função Visualizador. Não há um conceito de RLS para fluxos de dados.

Além das funções de workspace, a configuração de locatário Criar e usar fluxos de dados deve ser habilitada. Essa configuração de locatário se aplica a toda a organização.

Considere o cenário a seguir.

• Muitos modelos semânticos na organização precisam impor a RLS dinâmica. Ela exige que os UPNs (nomes de entidade de segurança do usuário) sejam armazenados no modelo semântico (para filtrar pela identidade do consumidor do relatório).
• Um criador de fluxo de dados, que pertence ao departamento de Recursos Humanos, cria um fluxo de dados de detalhes dos funcionários atuais, incluindo os UPNs deles. Ele configura o fluxo de dados para ser atualizado diariamente.
• Os criadores de modelos semânticos então consomem o fluxo de dados em seus designs de modelo para configurar a RLS.

Para obter mais informações sobre o uso de fluxos de dados, consulte os cenários de uso de preparação de dados de autoatendimento e preparação de dados avançada.

Lista de verificação – ao planejar as permissões de criador de fluxo de dados, as principais decisões e ações incluem:

Permissões do criador de datamarts

Um datamart é uma solução de análise de autoatendimento que permite que os usuários armazenem e explorem dados carregados em um banco de dados relacional totalmente gerenciado. Ele também inclui um modelo semântico gerado automaticamente.

Os datamarts fornecem uma experiência simples com pouco código para ingerir dados de diferentes fontes de dados e extrair, transformar e carregar (ETL) os dados usando o Power Query Online. Os dados são carregados em um Banco de Dados SQL do Azure que é totalmente gerenciado e não exige ajuste nem otimização. O modelo semântico gerado automaticamente é sempre sincronizado com o banco de dados gerenciado porque está no modo DirectQuery.

Você pode criar um datamart quando é administrador, membro ou colaborador do workspace. As funções de workspace também são mapeadas para funções de nível de banco de dados no Banco de Dados SQL do Azure (no entanto, como o banco de dados é totalmente gerenciado, as permissões de usuário não podem ser editadas nem gerenciadas no banco de dados relacional).

A configuração de locatário Criar datamarts permite que os administradores do Power BI configurem quais grupos de usuários podem criar datamarts.

Compartilhamento de datamart

Para datamarts, o termo compartilhamento assume um significado diferente de outros tipos de conteúdo do Power BI. Normalmente, uma operação de compartilhamento é voltada para um consumidor porque fornece permissão somente leitura para um item, como um relatório.

O compartilhamento de um datamart é voltado para criadores de conteúdo (e não para consumidores). Ele concede as permissões de Leitura e de Build, o que permite que os usuários consultem o modelo semântico ou o banco de dados relacional, o que preferirem.

Compartilhar um datamart permite que os criadores de conteúdo:

• Criar conteúdo usando o modelo semântico gerado automaticamente: o modelo semântico é a camada semântica na qual os relatórios do Power BI podem ser criados. A maioria dos criadores de relatórios deve usar o modelo semântico.
• Conectar-se e consultar o Banco de Dados SQL do Azure: o banco de dados relacional é útil para os criadores de conteúdo que desejam criar novos modelos semânticos ou relatórios paginados. Eles podem gravar consultas SQL (linguagem de consulta estruturada) para recuperar dados usando o ponto de extremidade SQL.

Segurança no nível da linha do datamart

Você pode definir a RLS para datamarts para restringir o acesso a dados para usuários especificados. A RLS é configurada no editor de datamart no serviço do Power BI e é aplicada automaticamente ao modelo semântico gerado automaticamente e ao banco de dados SQL do Azure (como regras de segurança).

Independentemente de como um usuário opta por se conectar ao datamart (ao modelo semântico ou ao banco de dados), permissões de RLS idênticas são impostas.

Lista de verificação – ao planejar as permissões de criador de datamart, as principais decisões e ações incluem:

Permissões do criador de scorecard

As métricas no Power BI permitem que você colete métricas específicas e as rastreie em relação aos principais objetivos empresariais. As métricas são adicionadas a scorecards, que podem ser compartilhados com outros usuários e exibidos em um painel.

Os scorecards podem ser protegidos com três níveis de permissões:

• Espaço de trabalho.
• Permissões de scorecard (por item).
• Métricas (dentro do scorecard).

Um usuário que cria ou gerencia totalmente um scorecard precisa ser um administrador, membro ou colaborador do workspace.

Como as métricas geralmente abrangem várias áreas de atuação, recomendamos que você crie um workspace separado para que possa gerenciar permissões de maneira independente para criadores e consumidores.

A configuração de locatário Criar e usar métricas permite que os administradores do Power BI configurem quais grupos de usuários podem criar métricas de scorecard.

Permissões de scorecard

Você pode atribuir as seguintes permissões de scorecard.

• Leitura: essa permissão permite que um usuário exiba o scorecard.
• Recompartilhamento: voltada para qualquer pessoa com uma permissão existente para o scorecard, essa permissão permite que os usuários compartilhem o scorecard com outro usuário.

Consistente com outros tipos de conteúdo no serviço do Power BI, as permissões por item são úteis quando a intenção é compartilhar um item com outro usuário. É recomendável usar funções de workspace e permissões de aplicativo sempre que possível.

Permissões no nível da métrica

Cada scorecard tem um conjunto de permissões de nível de métrica que você pode definir nas configurações do scorecard. No entanto, a imagem pode revelar inadvertidamente dados que o usuário receptor não tem permissão para ver.

As funções de nível de métrica permitem que você defina:

• Quem pode exibir métricas individuais em um scorecard.
• Quem pode atualizar métricas individuais:
  • Atualizando o status durante um check-in.
  • Adicionando anotações durante um check-in.
  • Atualizando o valor atual durante um check-in.

Para reduzir o nível de manutenção futura, é possível definir permissões padrão que serão herdadas por submétricas criadas no futuro.

Lista de verificação – ao planejar as permissões do criador de métricas, as principais decisões e ações incluem:

Publicando conteúdo

Esta seção inclui tópicos relacionados à publicação de conteúdo relevantes para criadores de conteúdo.

Workspaces

Os criadores de conteúdo precisarão de acesso à função de administrador, membro ou colaborador para publicar conteúdo em um workspace. Para saber mais, consulte as funções de workspace descritas anteriormente neste artigo.

Exceto pela BI pessoal, os criadores de conteúdo devem ser incentivados a publicar conteúdo em workspaces padrão, em vez de seu workspace pessoal.

A configuração de locatário Bloquear republicação e desabilitar a atualização de pacote altera o comportamento da publicação de modelos semânticos. Quando habilitada, os administradores, membros ou colaboradores do workspace não podem publicar alterações em um modelo semântico. Somente o proprietário do modelo semântico tem permissão para publicar uma atualização (forçando a tomada de controle de um modelo semântico antes de publicar um modelo semântico atualizado). Como essa configuração de locatário se aplica a toda a organização, habilite-a com alguma cautela, pois ela afeta todos os modelos semânticos do locatário. Não deixe de comunicar aos criadores do modelo semântico o que esperar, pois essa configuração altera o comportamento normal das funções de workspace.

Sincronização do Power Apps

É possível criar uma solução do Power Apps que inclui relatórios do Power BI inseridos. O processo do Power Apps criará automaticamente um workspace dedicado do Power BI para armazenar e proteger os relatórios e os modelos semânticos do Power BI. Para gerenciar itens que existem no Power Apps e no Power BI, há um processo de sincronização.

O processo sincroniza as funções de segurança para garantir que o Power BI herde as mesmas funções configuradas inicialmente no Power Apps. Ele também permite que o criador de conteúdo gerencie as permissões relacionadas a quem pode exibir os relatórios do Power BI (e os modelos semânticos relacionados) inseridos em um Power App.

Para obter mais informações sobre como sincronizar funções do Power Apps com funções de workspace do Power BI, consulte Sincronização de permissões entre o ambiente do Power Apps e o workspace do Power BI.

Acesso ao pipeline de implantação

Criadores e proprietários de conteúdo podem usar os pipelines de implantação do Power BI para a publicação de conteúdo de autoatendimento. Os pipelines de implantação simplificam o processo de publicação e aprimoram o nível de controle ao liberar novos conteúdos.

Você gerencia as permissões do pipeline (para usuários que podem implantar conteúdo com um pipeline de implantação) separadamente das funções de workspace. O acesso ao workspace e ao pipeline de implantação é necessário para os usuários que conduzem uma implantação.

Os criadores de conteúdo também podem precisar de:

• Permissões de criação de workspace (quando workspaces precisam ser criados pelo pipeline).
• Permissões de capacidade Premium ou do Fabric (quando os workspaces são atribuídos pelo pipeline).

Para saber mais, confira Acesso ao pipeline de implantação.

Ponto de extremidade XMLA

O ponto de extremidade XMLA usa o protocolo XMLA para expor todos os recursos de um modelo de dados tabular, incluindo algumas operações de modelagem de dados que não têm suporte do Power BI Desktop. Você pode usar a API de TOM (Modelo de Objeto Tabular) para fazer alterações programáticas em um modelo de dados.

O ponto de extremidade XMLA também fornece conectividade. Você só pode se conectar a um modelo semântico quando o workspace tem o modo de licença definido como Premium por usuário, Premium por capacidade ou Embedded. Após a conexão ser feita, uma ferramenta compatível com XMLA pode operar no modelo de dados para ler ou gravar dados. Para obter mais informações sobre como você pode usar o ponto de extremidade XMLA para gerenciar um modelo semântico, consulte o cenário de uso de gerenciamento avançado de modelo de dados.

O acesso por meio do ponto de extremidade XMLA respeitará as permissões existentes. Os administradores, membros e colaboradores do workspace têm implicitamente a permissão de Gravação de modelo semântico, o que significa que eles podem implantar novos modelos semânticos do Visual Studio e executar scripts TMSL (Linguagem de Script de Modelagem Tabular) no SSMS (SQL Server Management Studio).

Os usuários com a permissão de Build de modelo semântico podem usar o ponto de extremidade XMLA para se conectar e procurar modelos semânticos para consumo e visualização de dados. As regras RLS são respeitadas e os usuários não podem ver os metadados internos do modelo semântico.

A configuração de locatário Permitir pontos de extremidade XMLA e Analisar no Excel com modelos semânticos locais refere-se a duas funcionalidades: ela controla quais grupos de usuários podem usar o ponto de extremidade XMLA para consultar e/ou manter modelos semânticos no serviço do Power BI. Ela também determina se Analisar no Excel pode ser usado com modelos locais do SSAS (SQL Server Analysis Services).

Publicar na Web

Publicar na Web é um recurso que fornece acesso aos relatórios do Power BI para qualquer pessoa na Internet. Ele não requer autenticação e o acesso não é registrado para fins de auditoria. Como os consumidores do relatório não precisam pertencer à organização nem ter uma licença do Power BI, essa técnica é adequada para o jornalismo de dados, um processo em que os relatórios são integrados em postagens de blog, sites, emails ou mídias sociais.

A configuração de locatário Publicar na Web permite que administradores do Power BI controlem quais grupos de usuários podem publicar relatórios na Web. Para manter um nível mais alto de controle, recomendamos que você não inclua outros grupos nessa configuração de locatário (como administradores do Power BI ou outros tipos de criadores de conteúdo). Em vez disso, imponha o acesso de usuário específico usando um grupo de segurança, como publicação pública do Power BI. Certifique-se de que o grupo de segurança seja bem gerenciado.

Inserindo em aplicativos personalizados

A configuração de locatário Inserir conteúdo em aplicativos permite que os administradores do Power BI controlem quais usuários podem inserir conteúdo do Power BI fora do serviço do Power BI. Quando você planejar inserir conteúdo do Power BI em aplicativos personalizados, habilite essa configuração para grupos específicos, como desenvolvedores de aplicativos.

Inserindo no PowerPoint

A configuração de locatário Habilitar suplemento do Power BI para o PowerPoint permite que os administradores do Power BI controlem quais usuários podem inserir páginas de relatório do Power BI em apresentações do PowerPoint. Quando apropriado, habilite essa configuração para grupos específicos, como criadores de relatório.

Instrua os criadores de relatório a serem cautelosos sobre onde salvam suas apresentações do PowerPoint e com quem as compartilham. Isso ocorre porque uma imagem dos visuais de relatório do Power BI é mostrada aos usuários quando eles abrem a apresentação. Essa imagem é capturada da última vez que o arquivo do PowerPoint foi conectado. No entanto, a imagem pode revelar inadvertidamente dados que o usuário receptor não tem permissão para ver.

Aplicativos de modelo

Aplicativos de modelo permitem que fornecedores de software e parceiros do Power BI criem aplicativos com pouca ou nenhuma codificação e os implantem para qualquer cliente do Power BI.

A configuração de locatário Publicar aplicativos de modelo permite que os administradores do Power BI controlem quais usuários podem publicar aplicativos de modelo fora da organização, por exemplo, por meio do Microsoft AppSource. Para a maioria das organizações, essa configuração de locatário deve ser desabilitada ou controlada de maneira restrita. Considere usar um grupo de segurança, como Criadores de aplicativos de modelo externos do Power BI.

Assinaturas de email

Você pode inscrever a si mesmo e a outras pessoas nos relatórios, dashboards e relatórios paginados do Power BI. Em seguida, o Power BI enviará um email segundo um agendamento definido. Esse email conterá o instantâneo e um link para o relatório ou painel.

Você pode criar uma assinatura que inclui outros usuários quando você é um administrador, membro ou colaborador do workspace. Se o relatório estiver em um workspace Premium, você poderá assinar grupos (estejam eles em seu domínio ou não) e usuários externos. Ao configurar a assinatura, também há a opção de conceder permissões ao item. Permissões de acesso direto por item são usadas para essa finalidade e são descritas no artigo Planejamento de segurança do consumidor de relatórios.

A configuração de locatário Assinaturas de email permite que os administradores do Power BI controlem se esse recurso é habilitado ou desabilitado para toda a organização.

Há algumas limitações relacionadas a anexos decorrentes de restrições de licenciamento e configuração de locatário. Para saber mais, confira Assinaturas de email para relatórios e dashboards no serviço do Power BI.

Lista de verificação – ao planejar a publicação de conteúdo, as principais decisões e ações incluem:

Atualizar dados

Depois de publicados, os criadores de dados devem garantir que os modelos semânticos e os fluxos de dados (que contêm dados importados) sejam atualizados periodicamente. Você também deve decidir sobre as estratégias apropriadas para os proprietários do modelo semântico e do fluxo de dados.

Proprietário do modelo semântico

Cada modelo semântico tem um proprietário, que é uma conta de usuário. O proprietário do modelo semântico é necessário para configurar a atualização do modelo semântico e definir os parâmetros do modelo semântico.

Por padrão, o proprietário do modelo semântico também recebe solicitações de acesso de criadores de relatório que desejam permissões de Build (a menos que as Configurações de solicitação de acesso para o modelo semântico estejam definidas para fornecer instruções personalizadas). Para saber mais, consulte a seção Fluxo de trabalho de solicitação de acesso para criadores neste artigo.

Há duas maneiras de o Power BI obter credenciais para atualizar um modelo semântico.

• O proprietário do modelo semântico armazena credenciais nas configurações do modelo semântico.
• O proprietário do modelo semântico faz referência a um gateway nas configurações do modelo semântico (que contém uma fonte de dados com as credenciais armazenadas).

Se um usuário diferente precisar configurar a atualização ou definir os parâmetros do modelo semântico, ele deverá assumir a propriedade do modelo semântico. A propriedade do modelo semântico pode ser assumida por um administrador, membro ou colaborador do workspace.

Idealmente, o proprietário do modelo semântico é o usuário responsável pelo modelo semântico. Você deve atualizar o proprietário do modelo semântico quando ele sair da organização ou mudar de função. Além disso, lembre-se de que, quando a conta de usuário do proprietário do modelo semântico é desabilitada na ID do Microsoft Entra, a atualização de dados é desabilitada automaticamente. Nesse caso, outro usuário precisa assumir a propriedade do modelo semântico para permitir que as operações de atualização de dados sejam retomadas.

Proprietário do fluxo de dados

Assim como os modelos semânticos, os fluxos de dados também têm um proprietário, que é uma conta de usuário. As informações e as diretrizes fornecidas no tópico anterior sobre proprietários de modelos semânticos também se aplicam aos proprietários de fluxo de dados.

Lista de verificação – ao planejar a segurança relacionada aos processos de atualização de dados, as principais decisões e ações incluem:

Conteúdo relacionado

Para obter outras considerações, ações, critérios de tomada de decisão e recomendações para ajudar você com as decisões de implementação do Power BI, veja as áreas de atuação a serem consideradas.