Planejamento da implementação do Power BI: auditoria no nível do locatário

Este artigo de planejamento de auditoria no nível do locatário destina-se principalmente a:

• Administradores do Power BI: os administradores responsáveis por supervisionar o Power BI na organização. Os administradores do Power BI podem precisar colaborar com equipes de TI, segurança, auditoria interna e outras equipes relevantes.
• Equipe do Centro de Excelência, TI e BI: as equipes que também são responsáveis por supervisionar o Power BI. Eles podem precisar colaborar com administradores do Power BI e outras equipes relevantes.

O objetivo de uma solução de auditoria em nível de locatário é capturar e analisar dados para todos os usuários, atividades e soluções implantadas em um locatário do Power BI. Esses dados de auditoria no nível do locatário são valiosos para muitas finalidades, permitindo que você analise os esforços de adoção, compreenda os padrões de uso, eduque os usuários, dê suporte aos usuários, reduza riscos, melhore a conformidade, gerencie os custos de licença e monitore o desempenho.

Criar uma solução de auditoria de ponta a ponta segura e pronta para produção é um projeto significativo que leva tempo. Pense nisso como construir business intelligence em business intelligence (BI on BI). Para obter informações sobre por que os dados de auditoria são tão valiosos, consulte Visão geral de auditoria e monitoramento.

Para auditoria no nível de relatório, destinada a criadores de relatórios, consulte Auditoria no nível de relatório.

Para auditar ativos de dados, que é direcionado a criadores de dados, consulte Auditoria no nível de dados.

O restante deste artigo se concentra na auditoria no nível do locatário.

Quando você planeja criar uma solução de auditoria no nível do locatário, planeje gastar tempo nas quatro fases seguintes.

• Fase 1: Planeamento e decisões
  • Requisitos e prioridades
  • Necessidades de dados
  • Tipo de solução de auditoria
  • Permissões e responsabilidades
  • Decisões técnicas
  • Decisões sobre a fonte de dados
• Fase 2: Pré-requisitos e configuração
  • Criar conta de armazenamento
  • Instalar software e configurar serviços
  • Registar uma aplicação Microsoft Entra
  • Definir configurações de locatário do Power BI
• Fase 3: Desenvolvimento e análise de soluções
  • Extrair e armazenar os dados brutos
  • Criar os dados selecionados
  • Criar um modelo de dados
  • Melhorar o modelo de dados
  • Criar relatórios analíticos
  • Tome medidas com base nos dados
• Fase 4: Manter, melhorar e monitorar
  • Operacionalizar e melhorar
  • Documentação e suporte
  • Ativar alertas
  • Gestão contínua

Fase 1: Planeamento e decisões

A primeira fase centra-se no planeamento e na tomada de decisões. Há muitos requisitos e prioridades a considerar, por isso recomendamos que dedique tempo suficiente para compreender os tópicos introduzidos nesta secção. O objetivo é tomar boas decisões iniciais para que as fases a jusante decorram sem problemas.

Requisitos e prioridades

Na fase inicial, o objetivo é identificar o que é mais importante. Concentre-se no que é mais importante e em como vai medir o impacto na sua organização. Esforce-se para definir requisitos orientados para os negócios em vez de requisitos orientados para a tecnologia.

Aqui estão algumas perguntas que você deve responder.

• Que perguntas-chave precisa de responder? Há um grande volume de dados de auditoria que você pode explorar. A maneira mais eficaz de abordar a auditoria é concentrar-se em responder a perguntas específicas.
• Quais são seus objetivos de adoção e cultura de dados? Por exemplo, talvez você tenha uma meta de aumentar o número de criadores de conteúdo de BI de autoatendimento na organização. Nesse caso, você precisará medir as atividades do usuário relacionadas à criação, edição e publicação de conteúdo.
• Que riscos imediatos estão presentes? Por exemplo, você pode saber que o compartilhamento excessivo de conteúdo ocorreu no passado. Desde então, o treinamento de usuários foi aprimorado e agora você deseja auditar as configurações e atividades de segurança continuamente.
• Existem indicadores-chave de desempenho (KPIs) ou metas organizacionais atuais? Por exemplo, talvez você tenha um KPI organizacional relacionado à transformação digital ou a se tornar uma organização mais orientada por dados. Os dados de auditoria no nível do locatário podem ajudá-lo a medir se sua implementação do Power BI está alinhada com essas metas.

Para obter mais ideias sobre como usar dados de auditoria, consulte Visão geral de auditoria e monitoramento.

Lista de verificação - Ao identificar requisitos e prioridades, as principais decisões e ações incluem:

Necessidades de dados

Depois de definir os requisitos e prioridades (descritos anteriormente), você estará pronto para identificar os dados de que precisará. A presente secção abrange quatro categorias de dados.

• Dados de atividade do utilizador
• Inventário do inquilino
• Dados de utilizadores e grupos
• Dados de segurança

A maioria dos dados de que você precisará vem das APIs de administração, que fornecem uma grande variedade de metadados sobre o locatário do Power BI. Para obter mais informações, consulte Escolher uma API de usuário ou uma API de administrador mais adiante neste artigo.

Dados de atividade do utilizador

Torne sua primeira prioridade obter dados sobre as atividades do usuário. As atividades do usuário, que também são chamadas de eventos ou operações, são úteis para uma ampla variedade de propósitos.

Na maioria das vezes, esses dados são chamados de log de atividades ou de eventos. Tecnicamente, há várias maneiras de adquirir dados de atividade do usuário (o log de atividades é um método). Para obter mais informações sobre as decisões e atividades envolvidas, consulte Acessar dados de atividade do usuário mais adiante neste artigo.

Aqui estão algumas perguntas comuns que os dados de atividade do usuário podem responder.

• Encontre os principais usuários e os principais conteúdos
  • Que conteúdo é visualizado com mais frequência e por que utilizadores?
  • Quais são as tendências diárias, semanais e mensais para visualização de conteúdo?
  • As visualizações de relatório estão com tendência para cima ou para baixo?
  • Quantos usuários estão ativos?
• Compreender o comportamento do utilizador
  • Que tipo de segurança é usado com mais frequência (aplicativos, espaços de trabalho ou compartilhamento por item)?
  • Os usuários estão usando navegadores ou aplicativos móveis com mais frequência?
  • Quais criadores de conteúdo estão publicando e atualizando conteúdo mais ativamente?
  • Que conteúdo é publicado ou atualizado, quando e por que utilizadores?
• Identificar oportunidades de educação e treinamento de usuários
  • Quem está a partilhar (demasiado) a partir do seu espaço de trabalho pessoal?
  • Quem está exportando uma quantidade significativa?
  • Quem descarrega regularmente conteúdos?
  • Quem está publicando muitos novos modelos semânticos, anteriormente conhecidos como conjuntos de dados?
  • Quem está a utilizar muito as subscrições?
• Melhorar os esforços de governança e conformidade
  • Quando as configurações de locatário são alteradas e por qual administrador do Power BI?
  • Quem iniciou uma avaliação do Power BI?
  • Que conteúdo é acedido por utilizadores externos, quem, quando e como?
  • Quem adicionou ou atualizou um rótulo de sensibilidade?
  • Que percentagem de visualizações de relatório se baseiam em modelos semânticos certificados?
  • Que percentagem de modelos semânticos suporta mais do que um relatório?
  • Quando um gateway ou fonte de dados é criado ou atualizado e por qual usuário?

Para obter mais informações sobre como usar esses dados, consulte Compreender padrões de uso.

Para obter mais informações, consulte Acessar dados de atividade do usuário mais adiante neste artigo.

Inventário do inquilino

Muitas vezes, a segunda prioridade é recuperar os dados para criar um inventário de locatário. Às vezes, é chamado de inventário de espaço de trabalho, metadados de espaço de trabalho ou metadados de locatário.

Um inventário de locatário é um instantâneo em um determinado momento. Ele descreve o que é publicado no locatário. O inventário do locatário não inclui os dados reais ou os relatórios reais. Em vez disso, são metadados que descrevem todos os espaços de trabalho e seus itens (como modelos semânticos e relatórios).

Aqui estão algumas perguntas comuns que o inventário do locatário pode responder.

• Entenda quanto conteúdo você tem e onde
  • Quais espaços de trabalho têm mais conteúdo?
  • Que tipo de conteúdo é publicado em cada espaço de trabalho (especialmente quando você está separando espaços de trabalho de relatório e espaços de trabalho de dados)?
  • Que dependências existem entre itens (como fluxos de dados que suportam muitos modelos semânticos ou um modelo semântico que é uma fonte para outros modelos compostos)?
  • Qual é a linhagem de dados (dependências entre itens do Power BI, incluindo fontes de dados externas)?
  • Existem relatórios órfãos (que estão desconectados de seu modelo semântico)?
• Compreender a proporção de modelos semânticos para relatórios
  • Quanta reutilização de modelo semântico está ocorrendo?
  • Existem modelos semânticos duplicados ou altamente semelhantes?
  • Existem oportunidades para consolidar modelos semânticos?
• Compreender as tendências entre pontos no tempo
  • O número de notificações está a aumentar ao longo do tempo?
  • O número de modelos semânticos está a aumentar ao longo do tempo?
• Encontrar conteúdo não utilizado
  • Que relatórios não são utilizados (ou subutilizados)?
  • Que modelos semânticos não são utilizados (ou subutilizados)?
  • Há oportunidades para aposentar conteúdo?

Um inventário de locatários ajuda você a usar nomes atuais ao analisar atividades históricas. O instantâneo dos itens em seu locatário contém os nomes de todos os itens naquele momento. É útil usar nomes de itens atuais para relatórios históricos. Por exemplo, se um relatório foi renomeado há três meses, o log de atividades naquele momento registra o nome do relatório antigo. Com um modelo de dados definido corretamente, você pode usar o inventário de locatário mais recente para localizar um item pelo nome atual (em vez do nome anterior). Para obter mais informações, consulte Criar um modelo de dados posteriormente neste artigo.

Para obter mais informações sobre maneiras de usar um inventário de locatário, consulte Compreender o conteúdo publicado.

Como um inventário de locatário é um instantâneo em um determinado momento, você precisará decidir com que frequência extrair e armazenar os metadados. Um instantâneo semanal é útil para fazer comparações entre os dois pontos no tempo. Por exemplo, se quiser investigar as configurações de segurança de um espaço de trabalho, você precisará do instantâneo de inventário de locatário anterior, dos eventos do log de atividades e do instantâneo de inventário de locatário atual.

Existem duas maneiras principais de construir um inventário de inquilinos. Para obter mais informações sobre as decisões e atividades envolvidas, consulte Acessar dados de inventário de locatários mais adiante neste artigo.

Dados de utilizadores e grupos

À medida que suas necessidades analíticas crescem, você provavelmente determinará que gostaria de incluir dados sobre usuários e grupos em sua solução de auditoria de ponta a ponta. Para recuperar esses dados, você pode usar o Microsoft Graph, que é a fonte autorizada para informações sobre usuários e grupos do Microsoft Entra ID (anteriormente conhecido como Azure Ative Directory).

Os dados recuperados das APIs REST do Power BI incluem um endereço de email para descrever o usuário ou o nome de um grupo de segurança. Esses dados são um instantâneo em um determinado momento.

Aqui estão algumas perguntas comuns que o Microsoft Graph pode responder.

• Identificar usuários e grupos
  • Qual é o nome de usuário completo (além do endereço de e-mail), departamento ou local proveniente de seu perfil de usuário?
  • Quem são os membros de um grupo de segurança?
  • Quem é o proprietário de um grupo de segurança (para gerenciar membros)?
• Obter informações adicionais do usuário
  • Que licenças — Power BI Pro ou Power BI Premium Por Utilizador (PPU) — são atribuídas aos utilizadores?
  • Que utilizadores iniciam sessão com mais frequência?
  • Quais usuários não entraram no serviço do Power BI recentemente?

Para obter mais informações e recomendações sobre como acessar dados do Microsoft Graph, consulte Acessar dados de usuários e grupos mais adiante neste artigo.

Dados de segurança

Você pode ter um requisito para realizar auditorias de segurança regulares.

Aqui estão algumas perguntas comuns que as APIs REST do Power BI podem responder.

• Identificar pessoas e aplicativos
  • A quais relatórios um usuário, grupo ou entidade de serviço tem acesso?
  • Quais usuários, grupos ou entidades de serviço são assinantes para receber relatórios com uma assinatura de email?
• Compreender as permissões de conteúdo
  • Quais funções de espaço de trabalho são atribuídas a quais usuários e grupos?
  • Quais usuários e grupos são atribuídos a cada público do aplicativo Power BI?
  • Quais permissões por item são atribuídas, para quais relatórios e para quais usuários?
  • Quais permissões por item são atribuídas, para quais modelos semânticos e para quais usuários?
  • Quais modelos semânticos e datamarts têm segurança em nível de linha (RLS) definida?
  • Quais itens são compartilhados com as pessoas em toda a organização?
  • Que artigos são publicados publicamente na Internet?
• Compreender outras permissões
  • Quem tem permissão para publicar usando um pipeline de implantação?
  • Quem tem permissão para gerenciar gateways e conexões de dados?
  • Quem tem permissão para gerenciar uma capacidade Premium?

Estas perguntas comuns não são uma lista exaustiva; há uma grande variedade de APIs REST do Power BI disponíveis. Para obter mais informações, consulte Usando as APIs REST do Power BI.

Para obter mais informações sobre como usar as APIs de administrador versus APIs de usuário (incluindo como isso afeta as permissões necessárias para o usuário que está extraindo os dados), consulte Escolher uma API de usuário ou uma API de administrador mais adiante neste artigo.

Lista de verificação - Ao identificar os dados necessários para a auditoria, as principais decisões e ações incluem:

Tipo de solução de auditoria

A auditoria no nível do locatário é feita manualmente ou com processos automatizados.

A maioria dos novos processos de auditoria começa como um processo manual, particularmente durante o desenvolvimento e enquanto os testes ocorrem. Um processo de auditoria manual pode evoluir para se tornar um processo automatizado. No entanto, nem todo processo de auditoria precisa ser totalmente automatizado.

Processos manuais de auditoria

A auditoria manual depende de scripts e processos que são executados sob demanda por um usuário (geralmente um administrador do Power BI). Quando necessário, o usuário executa consultas interativamente para recuperar dados de auditoria.

A auditoria manual é mais adequada para:

• Novos scripts que estão sendo desenvolvidos e testados.
• Necessidades ocasionais e pontuais de auditoria.
• Necessidades de auditoria exploratória.
• Processos de auditoria não essenciais que não requerem suporte total.

Processos de auditoria automatizados

Os dados de auditoria necessários de forma recorrente devem ser automatizados. É extraído e processado regularmente, e é conhecido como um processo automatizado. Às vezes, é referido como um processo autônomo.

Os objetivos de um processo automatizado são reduzir o esforço manual, reduzir o risco de erro, aumentar a consistência e eliminar a dependência de um usuário individual para executá-lo.

A auditoria automatizada é mais adequada para:

• Auditoria de processos que correm em produção.
• Processos autônomos que são executados em um cronograma regular.
• Scripts que foram totalmente testados.
• Processos de auditoria essenciais que têm outros relatórios (ou outros processos) que dependem dele como fonte de dados.
• Processos de auditoria documentados e suportados.

O tipo de processo — manual ou automatizado — pode afetar a forma como você lida com a autenticação. Por exemplo, um administrador do Power BI pode usar a autenticação do usuário para um processo de auditoria manual, mas usar uma entidade de serviço para um processo automatizado. Para obter mais informações, consulte Determinar o método de autenticação mais adiante neste artigo.

Lista de verificação - Ao considerar o tipo de solução de auditoria a desenvolver, as principais decisões e ações incluem:

Permissões e responsabilidades

Neste ponto, você deve ter uma ideia clara do que deseja realizar e dos dados de que precisará inicialmente. Agora é um bom momento para tomar decisões sobre permissões de usuário, bem como funções e responsabilidades.

Permissões de utilizador

Ao planejar criar uma solução de auditoria de ponta a ponta, considere permissões de usuário para outros usuários que precisarão acessar os dados. Especificamente, decida quem terá permissão para acessar e visualizar dados de auditoria.

Eis algumas considerações a ter em conta.

Acesso direto aos dados de auditoria

Você deve decidir quem pode acessar os dados de auditoria diretamente. Há várias maneiras de pensar sobre isso.

• Quem deve ser um administrador do Power BI? Um administrador do Power BI tem acesso a todos os metadados do locatário, incluindo as APIs de administração. Para obter mais informações sobre como decidir quem deve ser um administrador do Power BI, consulte Planejamento de segurança em nível de locatário.
• Quem pode usar uma entidade de serviço existente? Para usar uma entidade de serviço (em vez de permissões de usuário) para acessar dados de auditoria, um segredo deve ser fornecido aos usuários autorizados para que eles possam executar a autenticação baseada em senha. O acesso a segredos (e chaves) deve ser rigorosamente controlado.
• O acesso tem de ser rigorosamente controlado? Certos setores com requisitos regulatórios e de conformidade devem controlar o acesso de forma mais rigorosa do que outros setores.
• Existem grandes volumes de dados de atividade? Para evitar atingir os limites de limitação de API, talvez seja necessário controlar rigorosamente quem tem permissão para acessar diretamente as APIs que produzem dados de auditoria. Nesse caso, é útil garantir que não haja esforços duplicados ou sobrepostos.

Acesso a dados brutos extraídos

Você deve decidir quem pode visualizar os dados brutos extraídos e gravados em um local de armazenamento. Mais comumente, o acesso a dados brutos é restrito a administradores e auditores. O Centro de Excelência (COE) também pode precisar de acesso. Para obter mais informações, consulte Determinar onde armazenar dados de auditoria posteriormente neste artigo.

Acesso a dados analíticos com curadoria

Você deve decidir quem pode visualizar os dados selecionados e transformados que estão prontos para análise. Estes dados devem ser sempre disponibilizados aos administradores e auditores. Às vezes, um modelo de dados é disponibilizado para outros usuários na organização, especialmente quando você cria um modelo semântico do Power BI com segurança em nível de linha. Para obter mais informações, consulte Planejar a criação de dados selecionados posteriormente neste artigo.

Funções e responsabilidades

Depois de decidir como as permissões de usuário funcionam, você está em uma boa posição para começar a pensar em funções e responsabilidades. Recomendamos que você envolva as pessoas certas desde o início, especialmente quando vários desenvolvedores ou equipes estiverem envolvidos na criação da solução de auditoria de ponta a ponta.

Decida quais usuários ou equipe serão responsáveis pelas seguintes atividades.

Função	Tipos de responsabilidades	Função tipicamente desempenhada por
Comunicar às partes interessadas	Atividades de comunicação e levantamento de requisitos.	COE em parceria com a TI. Também pode incluir pessoas selecionadas das principais unidades de negócios.
Decida prioridades e forneça orientação sobre os requisitos	Atividades de tomada de decisão relacionadas à solução de auditoria de ponta a ponta, incluindo como atender aos requisitos.	A equipe que supervisiona o Power BI na organização, como o COE. O patrocinador executivo ou um comitê diretor de governança de dados pode se envolver para tomar decisões críticas ou escalar problemas.
Extrair e armazenar os dados brutos	Criação de scripts e processos para acesso e extração dos dados. Também envolve gravar os dados brutos no armazenamento.	Equipe de engenharia de dados, geralmente em TI e em parceria com o COE.
Criar os dados selecionados	Limpeza de dados, transformação e criação dos dados selecionados no design de esquema em estrela.	Equipe de engenharia de dados, geralmente em TI e em parceria com o COE.
Criar um modelo de dados	Criação de um modelo de dados analíticos, com base nos dados selecionados.	Criador(es) de conteúdo do Power BI, geralmente em TI ou no COE.
Criar relatórios analíticos	Criação de relatórios para análise dos dados selecionados. Alterações contínuas nos relatórios com base em novos requisitos e quando novos dados de auditoria ficam disponíveis.	Criador(es) de relatórios do Power BI, geralmente em TI ou no COE.
Analisar os dados e agir sobre os resultados	Analise os dados e aja em resposta aos dados da auditoria.	A equipe que supervisiona o Power BI na organização, geralmente o COE. Também pode incluir outras equipes, dependendo dos resultados da auditoria e da ação. Outras equipes podem incluir segurança, conformidade, jurídico, gerenciamento de riscos ou gerenciamento de alterações.
Testar e validar	Teste para garantir que os requisitos de auditoria são atendidos e que os dados apresentados são precisos.	Criador(es) de conteúdo do Power BI, em parceria com a equipe que supervisiona o Power BI na organização.
Proteger os dados	Defina e gerencie a segurança para cada camada de armazenamento, incluindo os dados brutos e os dados selecionados. Gerencie o acesso a modelos semânticos criados para analisar os dados.	Administrador do sistema que armazena os dados, em parceria com a equipa que supervisiona o Power BI na organização.
Agendamento e automação	Operacionalizar uma solução e agendar o processo com a ferramenta de eleição.	Equipe de engenharia de dados, geralmente em TI e em parceria com o COE.
Apoie a solução	Monitore a solução de auditoria, incluindo execuções de tarefas, erros e suporte para problemas técnicos.	A equipe que lida com o suporte ao sistema do Power BI, que geralmente é TI ou o COE.

Muitas das funções e responsabilidades acima podem ser consolidadas se forem desempenhadas pela mesma equipe ou pela mesma pessoa. Por exemplo, seus administradores do Power BI podem executar algumas dessas funções.

Também é possível que pessoas diferentes desempenhem papéis diferentes, dependendo da circunstância. As ações serão contextuais em função dos dados da auditoria e da ação proposta.

Considere vários exemplos.

• Exemplo 1: Os dados de auditoria mostram que alguns utilizadores exportam frequentemente dados para o Excel. Ação tomada: O COE entra em contato com os usuários específicos para entender suas necessidades e ensiná-los melhores alternativas.
• Exemplo 2: Os dados de auditoria mostram que o acesso de usuários externos ocorre de forma inesperada. Ações tomadas: um administrador de sistema de TI atualiza as configurações relevantes do Microsoft Entra ID para acesso de usuário externo. O administrador do Power BI atualiza a configuração do locatário relacionada ao acesso de usuário externo. O COE atualiza a documentação e o treinamento para criadores de conteúdo que gerenciam a segurança. Para obter mais informações, consulte Estratégia para usuários externos.
• Exemplo 3: Os dados de auditoria mostram que vários modelos de dados definem a mesma medida de forma diferente (disponível nas APIs de verificação de metadados, se permitido pelas configurações detalhadas do locatário de metadados). Ação tomada: O comitê de governança de dados inicia um projeto para definir definições comuns. O COE atualiza a documentação e o treinamento para criadores de conteúdo que criam modelos de dados. O COE também trabalha com criadores de conteúdo para atualizar seus modelos, conforme apropriado. Para obter mais informações sobre como recuperar metadados detalhados, consulte Acessar dados de inventário de locatários mais adiante neste artigo.

Lista de verificação - Ao considerar permissões e responsabilidades, as principais decisões e ações incluem:

Decisões técnicas

Ao planejar uma solução de auditoria no nível do locatário, você precisará tomar algumas decisões técnicas importantes. Para melhorar a consistência, evitar retrabalho e melhorar a segurança, recomendamos que você tome essas decisões o mais cedo possível.

A primeira fase de planeamento envolve a tomada das seguintes decisões.

• Selecione uma tecnologia para acessar os dados de auditoria
• Determinar o método de autenticação
• Escolha uma API de usuário ou uma API de administrador
• Escolher APIs ou cmdlets do PowerShell
• Determinar onde armazenar dados de auditoria
• Planejar a criação de dados com curadoria

Selecione uma tecnologia para acessar os dados de auditoria

A primeira coisa que você precisa decidir é como acessar os dados de auditoria.

A maneira mais fácil de começar é usar os relatórios pré-criados disponíveis no espaço de trabalho de monitoramento de administradores.

Quando precisar acessar os dados diretamente e criar sua própria solução, você usará uma API (interface de programa de aplicativo). As APIs são projetadas para trocar dados pela Internet. As APIs REST do Power BI dão suporte a solicitações de dados usando o protocolo HTTP. Qualquer linguagem ou ferramenta pode invocar APIs REST do Power BI quando é capaz de enviar uma solicitação HTTP e receber uma resposta JSON.

Esta secção centra-se na sua escolha tecnológica. Para obter considerações sobre a origem para acessar tipos específicos de dados de auditoria, consulte Decisões de fonte de dados mais adiante neste artigo.

Opções da plataforma

Há muitas maneiras diferentes de acessar dados de auditoria. Dependendo da tecnologia escolhida, você pode se inclinar para um idioma preferido. Você também pode precisar tomar uma decisão específica sobre como agendar a execução de seus scripts. As tecnologias diferem muito na sua curva de aprendizagem e facilidade de começar.

Aqui estão algumas tecnologias que você pode usar para recuperar dados usando as APIs REST do Power BI.

Tecnologia	Boa escolha para processos manuais de auditoria	Boa escolha para processos de auditoria automatizados
Espaço de trabalho de monitoramento de administrador
Experimente-o
PowerShell
Power BI Desktop
Power Automate
Serviço preferencial do Azure
Ferramenta/idioma preferido
Pesquisa de log de auditoria do Microsoft Purview
Defender para Aplicações Cloud
Microsoft Sentinel

O restante desta seção fornece uma breve introdução a cada uma das opções apresentadas na tabela.

Espaço de trabalho de monitoramento de administrador

O espaço de trabalho de monitoramento de administrador contém relatórios predefinidos e modelos semânticos no serviço do Power BI. É uma maneira conveniente para os administradores do Fabric visualizarem dados de auditoria recentes e ajudá-los a entender as atividades do usuário.

Try-it na documentação da API

Try-it é uma ferramenta interativa que permite que você experimente a API REST do Power BI diretamente na documentação da Microsoft. É uma maneira fácil de explorar as APIs porque não requer outras ferramentas ou qualquer configuração em sua máquina.

Você pode usar o Try-it para:

• Envie manualmente uma solicitação para uma API para determinar se ela retorna as informações desejadas.
• Saiba como a URL é construída antes de escrever um script.
• Verifique os dados de forma informal.

Por ser interativo, o Try-it é mais adequado para aprendizagem, exploração e novos processos manuais de auditoria.

PowerShell e Azure Cloud Shell

Você pode criar e executar scripts do PowerShell de várias maneiras.

Aqui estão várias opções comuns.

• Visual Studio Code: Um editor de código-fonte moderno e leve. É uma ferramenta de código aberto disponível gratuitamente que é suportada em várias plataformas, incluindo Windows, macOS e Linux. Você pode usar o Visual Studio Code com muitos idiomas, incluindo o PowerShell (usando a extensão do PowerShell).
• Azure Data Studio: uma ferramenta para criar scripts e blocos de anotações. Ele é criado com base no Visual Studio Code. O Azure Data Studio está disponível de forma independente ou com o SQL Server Management Studio (SSMS). Há muitas extensões, incluindo uma extensão para o PowerShell.
• Azure Cloud Shell: uma alternativa para trabalhar com o PowerShell localmente. Você pode acessar o Azure Cloud Shell a partir de um navegador.
• Azure Functions: uma alternativa para trabalhar com o PowerShell localmente. O Azure Functions é um serviço do Azure que permite escrever e executar código em um ambiente sem servidor. O PowerShell é uma das várias linguagens suportadas.

Você pode usar o PowerShell de várias maneiras diferentes. Para obter mais informações sobre essa decisão técnica, consulte Choose APIs or PowerShell cmdlets mais adiante neste artigo.

Há muitos recursos online disponíveis para usar o PowerShell e, muitas vezes, é possível encontrar desenvolvedores experientes que podem criar e gerenciar soluções do PowerShell. O PowerShell é uma boa opção para criar processos de auditoria manuais e automatizados.

Power BI Desktop

Como o Power BI Desktop pode se conectar a APIs, você pode ficar tentado a usá-lo para criar sua solução de auditoria. No entanto, existem algumas desvantagens e complexidades significativas.

• Acumulando histórico: como o log de atividades do Power BI fornece até 30 dias de dados, a criação de toda a sua solução de auditoria envolve o acúmulo de um conjunto de arquivos ao longo do tempo que armazenam todos os eventos históricos. Acumular arquivos históricos é mais simples de realizar com outras ferramentas.
• Lidar com credenciais e chaves de forma segura: muitas soluções que encontra online a partir de bloggers da comunidade não são seguras porque codificam credenciais e chaves em texto simples nas consultas do Power Query. Embora essa abordagem seja fácil, ela não é recomendada porque qualquer pessoa que obtenha seu arquivo do Power BI Desktop pode ler os valores. Você não pode armazenar a senha (ao usar a autenticação do usuário) ou o segredo (ao usar uma entidade de serviço) com segurança no Power BI Desktop, a menos que:
  • Utilize um conector personalizado que foi desenvolvido com o SDK do Power Query. Por exemplo, um conector personalizado pode ler valores confidenciais do Cofre de Chaves do Azure ou de outro serviço que armazene com segurança o valor criptografado. Há também várias opções de conector personalizado disponíveis na comunidade global do Power BI.
  • Use a opção ApiKeyName , que funciona bem no Power BI Desktop. No entanto, não é possível armazenar o valor da chave no serviço do Power BI.
• Tipos de solicitações: você pode encontrar algumas limitações para o que pode ser executado no Power BI Desktop. Por exemplo, o Power Query não suporta todos os tipos de pedidos de API. Por exemplo, somente solicitações GET e POST são suportadas ao usar a função Web.Content . Para auditoria, normalmente você envia solicitações GET.
• Capacidade de atualização: você precisa seguir padrões de desenvolvimento específicos do Power Query para atualizar com êxito um modelo semântico no serviço do Power BI. Por exemplo, a opção deve estar presente ao usar Web.Contents para que o RelativePath Power BI possa verificar corretamente o local de uma fonte de dados sem gerar um erro no serviço do Power BI.

Na maioria dos casos, recomendamos que você use o Power BI Desktop apenas para duas finalidades. Você deve usá-lo para:

• Crie seu modelo de dados com base nos dados selecionados existentes (em vez de usá-lo para extrair inicialmente os dados de auditoria).
• Crie relatórios analíticos com base no seu modelo de dados.

Power Automate

Pode utilizar o Power Automate com o Power BI de várias formas. Em relação à auditoria, você pode usar o Power Automate para enviar solicitações para as APIs REST do Power BI e, em seguida, armazenar os dados extraídos no local de sua escolha.

Para obter outras ideias sobre formas de utilizar o Power Automate, procure o Power BI nos modelos do Power Automate.

Serviço preferencial do Azure

Há vários serviços do Azure que podem enviar solicitações para as APIs REST do Power BI. Você pode usar seu serviço preferido do Azure, como:

• Funções do Azure
• Automatização do Azure
• Fábrica de Dados do Azure
• Azure Synapse Analytics

Na maioria dos casos, você pode combinar um serviço de computação que lida com a lógica para a extração de dados com um serviço de armazenamento que armazena os dados brutos (e dados selecionados, quando apropriado). As considerações para tomar decisões de arquitetura técnica são descritas mais adiante neste artigo.

Ferramenta e/ou idioma preferidos

Você pode usar sua ferramenta preferida e seu idioma preferido para enviar solicitações para as APIs REST do Power BI. É uma boa abordagem quando sua equipe tem experiência com uma ferramenta ou linguagem específica, como:

• Python
• C# no .NET framework. Opcionalmente, você pode usar o SDK do Power BI .NET, que atua como um wrapper sobre as APIs REST do Power BI para simplificar alguns processos e aumentar a produtividade.
• JavaScript

Pesquisa de auditoria do Microsoft Purview

O portal de conformidade do Microsoft Purview (anteriormente o centro de conformidade do Microsoft 365) inclui uma interface de usuário que permite exibir e pesquisar os logs de auditoria. Os logs de auditoria unificados incluem o Power BI e todos os outros serviços que oferecem suporte aos logs de auditoria unificados do Microsoft 365.

Os dados capturados no log de auditoria unificado são exatamente os mesmos dados contidos no log de atividades do Power BI. Quando você faz uma pesquisa de log de auditoria no portal de conformidade do Microsoft Purview, ele adiciona sua solicitação à fila. Pode levar alguns minutos (ou mais, dependendo do volume de dados) para que os dados estejam prontos.

Aqui estão algumas maneiras comuns de usar a ferramenta de pesquisa de log de auditoria. Pode:

• Selecione a carga de trabalho do Power BI para exibir eventos de uma série de datas.
• Procure uma ou mais atividades específicas, tais como:
  • Relatório do Power BI excluído
  • Acesso de administrador adicionado a um espaço de trabalho pessoal no Power BI
• Exibir atividades de um ou mais usuários.

Para administradores com permissões suficientes, a ferramenta de pesquisa de log de auditoria no portal de conformidade do Microsoft Purview é uma boa opção para processos manuais de auditoria. Para obter mais informações, consulte o portal de conformidade do Microsoft Purview mais adiante neste artigo.

Interface de utilizador do Defender for Cloud Apps

O Defender for Cloud Apps está disponível para administradores no Microsoft Defender XDR (portal do Microsoft 365). Inclui uma interface de utilizador para ver e pesquisar registos de atividade para vários serviços na nuvem, incluindo o Power BI. Ele exibe os mesmos eventos de log que se originam no portal de conformidade do Microsoft Purview, além de outros eventos, como a atividade de entrada do usuário da ID do Microsoft Entra.

A interface de log de auditoria no Defender for Cloud Apps é uma boa opção para processos manuais de auditoria. Para obter mais informações, consulte Defender for Cloud Apps mais adiante neste artigo.

Microsoft Sentinel e KQL

O Microsoft Sentinel é um serviço do Azure que lhe permite recolher, detetar, investigar e responder a incidentes e ameaças de segurança. O Power BI pode ser configurado no Microsoft Sentinel como um conector de dados para que os logs de auditoria sejam transmitidos do Power BI para o Microsoft Sentinel Azure Log Analytics (que é um componente do serviço Azure Monitor ). Você pode usar a Kusto Query Language (KQL) para analisar os eventos do log de atividades armazenados no Azure Log Analytics.

Usar o KQL para pesquisar os dados no Azure Monitor é uma boa opção para exibir parte do log de auditoria. É também uma boa opção para processos manuais de auditoria. Para obter mais informações, consulte Microsoft Sentinel mais adiante neste artigo.

Considerações sobre a plataforma

Aqui estão algumas considerações sobre como você pode acessar os dados de auditoria.

• Você está implementando um processo de auditoria manual ou automatizado? Certas ferramentas alinham-se fortemente com o processamento manual ou o processamento automatizado. Por exemplo, um usuário sempre executa a funcionalidade Try-it interativamente, portanto, ela é adequada apenas para processos manuais de auditoria.
• Como você vai autenticar? Nem todas as opções suportam todas as opções de autenticação. Por exemplo, a funcionalidade Try-it suporta apenas a autenticação do usuário.
• Como você armazenará as credenciais com segurança? Diferentes tecnologias têm diferentes opções para armazenar credenciais. Para obter mais informações, consulte Determinar o método de autenticação mais adiante neste artigo.
• Com que tecnologia a sua equipa já é competente? Se há uma ferramenta que sua equipe prefere e se sente confortável em usar, comece por aí.
• O que é que a sua equipa é capaz de apoiar? Se uma equipe diferente dará suporte à solução implantada, considere se essa equipe é capaz de suportá-la adequadamente. Considere também que suas equipes internas podem dar suporte ao desenvolvimento feito por consultores.
• Qual ferramenta você tem aprovação para usar? Certas ferramentas e tecnologias podem necessitar de aprovação. Pode ser devido ao custo. Também pode ser devido a políticas de segurança de TI.
• Qual é a sua preferência de agendamento? Algumas tecnologias tomam a decisão por si. Outras vezes, será outra decisão que você deve tomar. Por exemplo, se você optar por escrever scripts do PowerShell, há várias maneiras de programar a execução deles. Por outro lado, se você usar um serviço de nuvem como o Azure Data Factory, o agendamento será interno.

Recomendamos que você revise o restante deste artigo antes de escolher uma tecnologia para acessar dados de auditoria.

Lista de verificação - Ao decidir qual tecnologia usar para acessar dados de auditoria, as principais decisões e ações incluem:

Determinar o método de autenticação

Como você planeja configurar a autenticação é uma decisão crítica. Muitas vezes, é um dos aspetos mais difíceis quando você começa a auditar e monitorar. Deve considerar cuidadosamente as opções disponíveis para tomar uma decisão informada.

Nem todas as APIs na internet requerem autenticação. No entanto, todas as APIs REST do Power BI exigem autenticação. Quando você acessa dados de auditoria no nível do locatário, o processo de autenticação é gerenciado pela plataforma de identidade da Microsoft. É uma evolução do serviço de identidade Microsoft Entra que se baseia em protocolos padrão do setor.

Antes de recuperar dados de auditoria, você deve primeiro autenticar, o que é conhecido como entrar. Os conceitos de autenticação e autorização são separados, mas relacionados. Um processo de autenticação verifica a identidade de quem está fazendo a solicitação. Um processo de autorização concede (ou nega) acesso a um sistema ou recurso verificando o que o usuário ou a entidade de serviço tem permissão para fazer.

Quando um usuário ou entidade de serviço se autentica, um token de acesso do Microsoft Entra é emitido para um servidor de recursos, como uma API REST do Power BI ou uma API do Microsoft Graph. Por padrão, um token de acesso expira após uma hora. Um token de atualização pode ser solicitado, se necessário.

Existem dois tipos de tokens de acesso:

• Tokens de usuário: emitidos em nome de um usuário com uma identidade conhecida.
• Tokens somente de aplicativo: emitidos em nome de um aplicativo Microsoft Entra (entidade de serviço).

Para obter mais informações, consulte Objetos principais de aplicativo e serviço no Microsoft Entra ID.

A tabela a seguir descreve as duas opções de autenticação.

Tipo de autenticação	Descrição	Destinado a	Boa escolha para processos manuais de auditoria	Boa escolha para processos de auditoria automatizados
Autenticação do utilizador	Inicie sessão como utilizador utilizando o nome principal do utilizador (endereço de e-mail) e uma palavra-passe.	Uso ocasional e interativo
Autenticação do principal de serviço	Entre como uma entidade de serviço usando um segredo (chave) atribuído a um registro de aplicativo.	Operações contínuas, programadas e sem supervisão

Cada opção de autenticação é descrita com mais detalhes na seção a seguir.

Autenticação do utilizador

A autenticação do usuário é útil nas seguintes situações.

• Processos de auditoria manual: você deseja executar um script usando suas permissões de usuário. As permissões podem estar em um de dois níveis, dependendo do tipo de solicitação de API:
  • Permissões de administrador para APIs de administrador: você precisa usar suas permissões de administrador do Power BI para enviar uma solicitação para uma API de administrador.
  • Permissões de usuário para APIs de usuário: você precisa usar suas permissões de usuário do Power BI para enviar uma solicitação para uma API de usuário. Para obter mais informações, consulte Escolher uma API de usuário ou uma API de administrador.
• Início de sessão interativo: pretende iniciar sessão de forma interativa, o que requer que introduza o seu endereço de e-mail e palavra-passe. Por exemplo, você deve entrar interativamente para usar a experiência Try-it, que é encontrada na documentação da API da Microsoft.
• Rastreie quem acessou os metadados do locatário: quando usuários individuais e administradores enviam solicitações de API, convém auditar quem são esses indivíduos. Quando você se autentica com uma entidade de serviço (descrita a seguir), o ID de usuário capturado pelo log de atividades é o ID do aplicativo. Se vários administradores se autenticarem com a mesma entidade de serviço, pode ser difícil saber qual administrador acessou os dados.
• Conta de administrador compartilhada: algumas equipes de TI usam uma conta de administrador compartilhada. Dependendo de como é implementado e controlado, pode não ser uma prática recomendada. Em vez de uma conta compartilhada, você deve considerar o uso do Microsoft Entra Privileged Identity Management (PIM), que pode conceder direitos de administrador ocasionais e temporários do Power BI para um usuário.
• APIs que suportam apenas a autenticação do usuário: ocasionalmente, talvez seja necessário usar uma API que não ofereça suporte à autenticação por uma entidade de serviço. Na documentação, cada API observa se uma entidade de serviço pode chamá-la.

Autenticação do principal de serviço

A maioria das organizações tem um locatário do Microsoft Entra, portanto, os termos registro de aplicativo e entidade de serviço tendem a ser usados de forma intercambiável. Quando você registra um aplicativo Microsoft Entra, há dois componentes.

• Registro de aplicativo: um registro de aplicativo é exclusivo globalmente. É a definição global de um aplicativo Microsoft Entra registrado que pode ser usado por vários locatários. Um registro de aplicativo também é conhecido como um aplicativo cliente ou o ator. Normalmente, o termo aplicativo cliente implica uma máquina de usuário. No entanto, essa não é a situação para registros de aplicativos. No portal do Azure, os aplicativos do Microsoft Entra são encontrados na página Registros de aplicativos na ID do Microsoft Entra.
• Entidade de serviço: uma entidade de serviço é a representação local do registro do aplicativo para uso em seu locatário específico. A entidade de serviço é derivada do aplicativo Microsoft Entra registrado. Para organizações com vários locatários do Microsoft Entra, o mesmo registro de aplicativo pode ser referenciado por mais de uma entidade de serviço. No portal do Azure, as entidades de serviço podem ser encontradas na página Aplicativos empresariais no Microsoft Entra ID.

Como a entidade de serviço é a representação local, o termo autenticação da entidade de serviço é a maneira mais comum de se referir a logins.

A autenticação da entidade de serviço é útil nas seguintes situações.

• Processos de auditoria automatizados: você deseja executar um processo autônomo em um cronograma.
• Não é necessário entrar no serviço do Power BI: você só precisa se conectar e extrair dados. Uma entidade de serviço não pode entrar no serviço do Power BI.
• Acesso compartilhado a dados: você (pessoalmente) não é um administrador do Power BI, mas está autorizado a usar uma entidade de serviço. A entidade de serviço tem permissão para executar APIs de administrador para recuperar dados no nível do locatário (ou outras permissões específicas).
• Uso por vários administradores: você deseja permitir que vários administradores ou usuários usem a mesma entidade de serviço.
• Bloqueadores técnicos: Há um bloqueador técnico que impede o uso da autenticação do usuário. Os bloqueadores técnicos comuns incluem:
  • Autenticação multifator (MFA): os processos de auditoria automatizados (que são executados sem supervisão) não podem ser autenticados usando uma conta de usuário quando a autenticação multifator está habilitada.
  • Sincronização de hash de senha: o Microsoft Entra ID requer sincronização de hash de senha para autenticação de uma conta de usuário. Às vezes, a TI ou uma equipe de segurança cibernética pode desativar essa funcionalidade.

Finalidade do registro do aplicativo e convenção de nomenclatura

Cada registro de aplicativo deve ter um nome claro que descreva sua finalidade e o público-alvo (que pode usar o registro do aplicativo).

Considere a implementação de uma convenção de nomenclatura, como: <Carga de trabalho> - <Finalidade> - <Público-alvo> - <Tipo de objeto>

Aqui estão as partes da convenção de nomenclatura.

• Carga de trabalho: geralmente equivalente a uma fonte de dados (por exemplo, dados do Power BI ou dados do Microsoft Graph).
• Finalidade: Semelhante ao nível de permissões (por exemplo, Read versus ReadWrite). Conforme descrito abaixo, a finalidade ajuda você a seguir o princípio do menor privilégio ao criar registros de aplicativos separados que só podem ler dados.
• Público-alvo: Opcional. Dependendo da carga de trabalho e da finalidade, o público-alvo permite determinar os usuários pretendidos do registro do aplicativo.
• Tipo de objeto: EntraApp está incluído para maior clareza.

Sua convenção de nomenclatura pode ser mais específica quando você tem vários locatários ou vários ambientes (como desenvolvimento e produção).

A tabela a seguir mostra exemplos de registros de aplicativos que podem ser usados para extrair dados de auditoria no nível do locatário:

Nome de registo da aplicação	Objetivo	Público-alvo
PowerBIData-Read-AdminAPIs-EntraApp	Extraia metadados de todo o locatário para auditoria e administração do Power BI. As APIs de administrador são sempre somente leitura e podem não ter permissões concedidas no Microsoft Entra ID (somente configuração de locatário do Power BI).	Administradores do Power BI e o Centro de Excelência
PowerBIData-ReadWrite-PowerBIAdministrators-EntraApp	Gerencie o locatário do Power BI. Requer permissões de leitura/gravação para criar ou atualizar recursos.	Administradores do Power BI e o Centro de Excelência
GraphData-Read-PowerBIAdministrators-EntraApp	Extraia dados de usuários e grupos para auditoria e administração do Power BI. Requer permissões de leitura.	Administradores do Power BI e o Centro de Excelência

Gerenciar vários registros de aplicativos para finalidades diferentes envolve mais esforço. No entanto, pode beneficiar de várias vantagens.

• Veja para que o registro do aplicativo deve ser usado e por quê: Quando você vê a ID do cliente do registro do aplicativo aparecer em seus dados de auditoria, você terá uma ideia para que ele foi usado e por quê. Essa é uma vantagem significativa de criar registros de aplicativos separados (em vez de usar apenas um para todos os fins).
• Veja por quem o registro do aplicativo deve ser usado: Quando você vir a ID do cliente do registro do aplicativo aparecer em seus dados de auditoria, você terá uma ideia de quem estava usando-o.
• Evite permissões de provisionamento excessivo: você pode seguir o princípio do menor privilégio fornecendo registros de aplicativos separados para diferentes conjuntos de pessoas que têm necessidades diferentes. Você pode evitar permissões de provisionamento excessivo usando um registro de aplicativo somente leitura quando as permissões de gravação não forem necessárias. Por exemplo, você pode ter alguns usuários de autoatendimento altamente capazes que desejam coletar dados sobre seus modelos semânticos; Eles precisam ter acesso a uma entidade de serviço com permissão de leitura . Considerando que pode haver membros satélites do Centro de Excelência trabalhando para a equipe de Finanças que gerenciam programaticamente modelos semânticos; Eles precisam de acesso a uma entidade de serviço com permissão de gravação .
• Saiba quem deve estar na posse do segredo: O segredo para cada registro de aplicativo só deve ser compartilhado com as pessoas que precisam dele. Quando o segredo é girado (descrito mais adiante nesta seção), o impacto é menor quando você usa registros de aplicativos separados para necessidades diferentes. Isso é útil quando você precisa girar o segredo porque um usuário sai da organização ou muda de função.

Permissões do registo da aplicação

Há duas maneiras principais de um registro de aplicativo acessar dados e recursos. Envolve permissões e consentimento.

• Permissões somente para aplicativos: o acesso e a autorização são manipulados pela entidade de serviço sem um usuário conectado. Esse método de autenticação é útil para cenários de automação. Ao usar permissões somente para aplicativos, é fundamental entender que as permissões não são atribuídas no ID do Microsoft Entra. Em vez disso, as permissões são atribuídas de duas maneiras:
  • Para executar APIs de administrador: determinadas configurações de locatário do Power BI permitem acesso aos pontos de extremidade para as APIs de administração (que retornam metadados de auditoria em todo o locatário). Para obter mais informações, consulte Definir configurações de locatário do Power BI mais adiante neste artigo.
  • Para executar APIs de usuário: aplicam-se permissões de item e espaço de trabalho do Power BI. As permissões padrão do Power BI controlam quais dados podem ser retornados a uma entidade de serviço ao executar APIs de usuário (que retornam dados de auditoria com base nas permissões do usuário ou da entidade de serviço que está invocando a API).
• Permissões delegadas: permissões baseadas em escopo são usadas. A entidade de serviço acessa dados em nome do usuário que está conectado no momento. Isso significa que a entidade de serviço não pode acessar nada além do que o usuário conectado pode acessar. Esteja ciente de que este é um conceito diferente da autenticação somente para o usuário, descrita anteriormente. Como um aplicativo personalizado é necessário para lidar corretamente com a combinação de permissões de usuário e aplicativo, as permissões delegadas raramente são usadas para cenários de auditoria. Esse conceito é comumente mal compreendido, levando a muitos registros de aplicativos que são provisionados em excesso com permissões.

Para obter mais informações, consulte Registrar um aplicativo Microsoft Entra mais adiante neste artigo.

Segredos de registo da aplicação

Um registro de aplicativo geralmente tem um segredo atribuído a ele. O segredo é usado como uma chave para autenticação e tem uma data de validade. Portanto, você precisa planejar como girar a chave regularmente e como comunicar a nova chave para usuários autorizados.

Você também precisa se preocupar com onde armazenar o segredo com segurança. Um cofre de senhas organizacional, como o Azure Key Vault, é uma excelente escolha.

Gerencie credenciais com segurança

Independentemente de você usar a autenticação do usuário ou a autenticação da entidade de serviço, um dos maiores desafios é como gerenciar senhas, segredos e chaves com segurança.

Aqui estão vários métodos seguros que você pode usar para gerenciar senhas, segredos e chaves.

• Integre com o Azure Key Vault ou outro sistema de cofre de senhas organizacional, sempre que possível.
• Use credenciais e cadeias de caracteres seguras em seus scripts do PowerShell. Uma credencial funciona para autenticação de usuário e autenticação de entidade de serviço. No entanto, não é possível usar uma credencial quando a autenticação multifator está habilitada para uma conta de usuário.
• Solicite uma senha em seu script do PowerShell ou use a autenticação interativa com um navegador.
• Use o módulo Gerenciamento Secreto para PowerShell publicado pela Microsoft. Ele pode armazenar valores usando um cofre local. Ele também pode se integrar a um Cofre de Chaves do Azure remoto, que é útil quando há vários administradores em sua organização que trabalham com os mesmos scripts.
• Crie um conector personalizado para o Power BI Desktop para que ele possa lidar com credenciais com segurança. Alguns conectores personalizados estão disponíveis a partir de membros da comunidade (geralmente no GitHub).

Biblioteca de Autenticação da Microsoft

O suporte para a Biblioteca de Autenticação do Azure AD (ADAL) terminou em dezembro de 2022. No futuro, você deve usar a Biblioteca de Autenticação da Microsoft (MSAL). A equipe de segurança da sua organização deve estar familiarizada com essa alteração significativa.

Embora não seja importante para os profissionais do Power BI entender profundamente a transição para o MSAL, você deve seguir as recomendações a seguir.

• Use a versão mais recente do módulo de Gerenciamento do Power BI ao se autenticar com o cmdlet Connect-PowerBIServiceAccount PowerShell. Ele mudou de ADAL para MSAL na versão 1.0.946 (26 de fevereiro de 2021).
• Use o ponto de extremidade do Microsoft Entra V2 ao autenticar diretamente no script. O ponto de extremidade do Microsoft Entra V2 usa MSAL, enquanto o ponto de extremidade do Microsoft Entra V1 usa ADAL.
• Descontinue o uso de APIs e módulos que foram preteridos. Para obter mais informações, consulte APIs e módulos preteridos mais adiante neste artigo.
• Se você encontrar uma solução de comunidade on-line, certifique-se de que ela esteja usando o MSAL para autenticação em vez de ADAL.

Lista de verificação – Ao decidir como gerenciar a autenticação, as principais decisões e ações incluem:

Escolha uma API de usuário ou uma API de administrador

Ao planejar a recuperação de dados de auditoria, é importante usar o tipo certo de API.

Há dois tipos de APIs a considerar.

• APIs de usuário: confie nas permissões do usuário conectado (ou entidade de serviço) para enviar solicitações à API. Por exemplo, uma maneira de retornar uma lista de modelos semânticos em um espaço de trabalho é com uma API de usuário. A permissão para ler modelos semânticos pode ser concedida por função de espaço de trabalho ou permissões por item. Há duas maneiras de executar APIs de usuário:
  • Autenticação do usuário: o usuário conectado deve ter permissão para acessar o espaço de trabalho ou item.
  • Autenticação da entidade de serviço: a entidade de serviço deve ter permissão para acessar o espaço de trabalho ou item.
• APIs de administrador: recupere metadados do locatário. Às vezes é referido como o escopo organizacional. Por exemplo, para retornar uma lista de todos os modelos semânticos no locatário, use uma API de administrador. Há duas maneiras de executar APIs de administração:
  • Autenticação de usuário: o usuário conectado deve ser um administrador do Power BI para executar APIs de administrador.
  • Autenticação da entidade de serviço: a entidade de serviço deve ter permissão para executar APIs de administrador (sem depender de permissões de segurança, como faz uma API de usuário).

Considere um exemplo em que você precisa obter uma lista de modelos semânticos. A tabela a seguir mostra seis opções de API que você pode usar para fazer isso. Quatro opções são APIs de usuário e duas opções são APIs de administrador. O escopo e o número de itens retornados são diferentes, dependendo da API escolhida.

Nome da API	Tipo de API	Scope	Número de modelos semânticos
Obter conjunto de dados	User	Espaço de trabalho pessoal	Um
Obter conjuntos de dados	User	Espaço de trabalho pessoal	Todos
Obter conjunto de dados no grupo	User	Um espaço de trabalho	Um, desde que o usuário conectado tenha permissão para ler o modelo semântico
Obter conjuntos de dados no grupo	User	Um espaço de trabalho	Todos, desde que o usuário conectado tenha permissão para ler cada modelo semântico
Obter conjuntos de dados no grupo como administrador	Admin	Um espaço de trabalho	Todos
Obter conjuntos de dados como administrador	Admin	Inquilino inteiro	Todos

Para obter informações sobre configurações de locatário, consulte Definir configurações de locatário do Power BI mais adiante neste artigo.

Lista de verificação - Ao escolher se deseja usar uma API de usuário ou uma API de administrador, as principais decisões e ações incluem:

Escolher APIs ou cmdlets do PowerShell

Uma decisão importante a ser tomada é usar cmdlets do PowerShell quando eles estiverem disponíveis para os dados específicos que você deseja recuperar. Essa decisão é importante se você decidiu que o PowerShell é uma das tecnologias que você usará para acessar dados de auditoria.

O PowerShell é uma solução de automação de tarefas. O termo PowerShell é um termo coletivo que se refere à linguagem de script, um aplicativo shell de linha de comando e uma estrutura de gerenciamento de configuração. O PowerShell Core é a versão mais recente do PowerShell, que é executado em Windows, Linux e macOS.

Um cmdlet do PowerShell é um comando que executa uma ação. Um módulo do PowerShell é um pacote que contém membros do PowerShell, como cmdlets, provedores, funções, fluxos de trabalho, variáveis e aliases. Você baixa e instala módulos.

Um módulo do PowerShell cria uma camada de abstração sobre as APIs. Por exemplo, o cmdlet Get-PowerBIActivityEvent recupera (ou obtém) eventos de auditoria para um locatário do Power BI. Este cmdlet do PowerShell recupera seus dados da API REST Get Activity Events . Geralmente, é mais simples começar usando os cmdlets porque simplifica o acesso às APIs subjacentes.

Apenas um subconjunto das APIs está disponível como cmdlets do PowerShell. À medida que você continua a expandir toda a sua solução de auditoria, é provável que use uma combinação de cmdlets e APIs. O restante desta seção ajuda você a decidir de que maneira você acessará os dados.

Módulos do PowerShell

A Microsoft publicou dois módulos do PowerShell que contêm cmdlets relacionados ao Power BI. Eles são o módulo Gerenciamento do Power BI e o módulo Gateway de Dados. Esses módulos do PowerShell atuam como um wrapper de API sobre as APIs REST do Power BI subjacentes. O uso desses módulos do PowerShell pode facilitar a escrita de scripts.

Módulo de Gerenciamento do Power BI

O módulo de Gerenciamento do Power BI é um módulo cumulativo que contém módulos específicos do Power BI para administração, capacidades, espaços de trabalho e muito mais. Você pode optar por instalar o módulo cumulativo para obter todos os módulos ou pode instalar módulos específicos. Todos os módulos de Gerenciamento do Power BI são suportados no Windows PowerShell e no PowerShell Core.

Aqui estão vários cmdlets comumente usados que você pode usar para recuperar dados de auditoria.

Módulo de gestão	Cmdlet	Objetivo
Perfil	Connect-PowerBIServiceAccount	Autentique um usuário ou entidade de serviço do Power BI.
Admin	Get-PowerBIActivityEvent	Exiba ou extraia eventos do log de atividades do Power BI para o locatário.
Áreas de Trabalho	Get-PowerBIWorkspace	Compile uma lista de espaços de trabalho.
Relatórios	Get-PowerBIReport	Compile uma lista de relatórios para um espaço de trabalho ou o locatário.
Dados	Get-PowerBIDataset	Compile uma lista de modelo semântico para um espaço de trabalho ou o locatário.
Perfil	Invoke-PowerBIRestMethod	Envie uma solicitação de API REST (comando). Esse cmdlet é uma boa opção porque pode invocar qualquer uma das APIs REST do Power BI. Também é uma boa opção quando você deseja usar a forma mais simples de autenticação usando o Connect-PowerBIServiceAccount cmdlet e poder invocar uma API que não tenha um cmdlet do PowerShell correspondente. Para obter mais informações, consulte Considerações sobre o uso de cmdlets do PowerShell mais adiante nesta seção.

Você pode baixar o módulo de Gerenciamento do Power BI na Galeria do PowerShell. A maneira mais simples de instalar módulos é usar o PowerShellGet.

Recomendamos que você instale o módulo cumulativo de atualizações do Power BI Management. Dessa forma, todos os cmdlets que você pode precisar estão disponíveis. No mínimo, você precisa do módulo Perfil (para autenticação) e de quaisquer módulos específicos que contenham os cmdlets que você deseja usar.

Módulo de gateway de dados

O módulo Gateway de Dados contém cmdlets que recuperam dados de um gateway de dados local e suas fontes de dados. O módulo Gateway de Dados é suportado apenas no PowerShell Core. Não há suporte para ele no Windows PowerShell.

Ao contrário do módulo de Gerenciamento do Power BI (descrito anteriormente), o módulo Gateway de Dados não inclui nenhum cmdlet admin. Muitos dos cmdlets (e as APIs de gateway correspondentes) exigem que o usuário tenha direitos de administrador de gateway.

Aqui estão vários cmdlets do módulo Gateway de Dados que você pode usar para recuperar dados de auditoria.

Cmdlet	Objetivo
Connect-DataGatewayServiceAccount	Autenticar um usuário do Power BI (geralmente requer que o usuário pertença à função de administrador do gateway).
Get-DataGatewayCluster	Compile uma lista de clusters de gateway.
Get-DataGatewayClusterDataSource	Compile uma lista de fontes de dados para um cluster de gateway.
Get-DataGatewayInstaller	Verifique quais usuários têm permissão para instalar e registrar gateways na organização.

Você pode baixar o módulo Gateway de Dados da Galeria do PowerShell.

Técnicas para usar o PowerShell

Você pode usar o PowerShell de várias maneiras diferentes. A decisão que você toma é importante.

A tabela a seguir descreve três técnicas diferentes para usar o PowerShell.

Técnica	Descrição	Exemplo
Use cmdlets do PowerShell para simplificar a autenticação e chamar APIs diretamente. Abordagem recomendada	Com esta técnica, há um equilíbrio entre simplicidade e flexibilidade. O cmdlet Invoke-PowerBIRestMethod está disponível no módulo Perfil de Gerenciamento do Power BI. Esse cmdlet é frequentemente chamado de canivete suíço porque você pode usá-lo para chamar qualquer uma das APIs REST do Power BI. A vantagem de usar essa técnica é que você pode simplificar a autenticação e, em seguida, chamar qualquer uma das APIs REST do Power BI. Recomendamos vivamente que utilize esta técnica.	Depois de autenticar com o cmdlet Connect-PowerBIServiceAccount , use o cmdlet Invoke-PowerBIRestMethod para recuperar dados de sua API preferida (por exemplo, Get Pipeline Users As Admin).
Use cmdlets do PowerShell tanto quanto possível, tanto para autenticação quanto para recuperação de dados.	Com essa técnica, o PowerShell é usado extensivamente. O PowerShell é usado para coordenar a execução do script e os módulos do PowerShell são usados sempre que possível para acessar os dados. Isso cria uma dependência maior do PowerShell a partir de vários aspetos.	Depois de autenticar com o cmdlet Connect-PowerBIServiceAccount , use um cmdlet (por exemplo, Get-PowerBIActivityEvent) para recuperar dados.
Use o PowerShell apenas para coordenar a execução do processo. Os módulos do PowerShell são usados o mínimo possível.	Com essa técnica, há menos dependência do PowerShell como ferramenta, já que seu uso principal é orquestrar chamadas de API invocadas. Apenas um módulo PowerShell genérico é usado para acessar APIs (nenhum dos módulos dos módulos de Gerenciamento do Power BI é usado).	Depois de autenticar usando a Microsoft Authentication Library (MSAL), chame sua API preferida (por exemplo, Get Pipeline Users As Admin) usando o cmdlet genérico Invoke-RestMethod para recuperar dados.

Na tabela acima, a primeira técnica descreve uma abordagem que equilibra facilidade de uso com flexibilidade. Esta abordagem fornece o melhor equilíbrio para as necessidades da maioria das organizações, razão pela qual é recomendada. Algumas organizações podem ter políticas de TI existentes e preferências de equipe que influenciam como você decide usar o PowerShell.

Os usuários técnicos (e administradores) podem usar os módulos de Gerenciamento do Power BI para recuperar dados ou automatizar certos aspetos do gerenciamento de conteúdo.

• Para administradores: defina o -Scope parâmetro para Organization acessar entidades em todo o locatário (por exemplo, para recuperar uma lista de todos os espaços de trabalho).
• Para usuários técnicos: defina o -Scope parâmetro como Individual (ou omita o parâmetro) para acessar entidades que pertencem ao usuário (por exemplo, para recuperar uma lista de espaços de trabalho que o usuário tem permissão para acessar).

Considere um cenário em que você precisa obter uma lista de modelos semânticos. Se você optar por trabalhar diretamente com as APIs, deverá especificar qual API chamar. No entanto, se você optar por usar o cmdlet Get-PowerBIDataset , poderá definir o parâmetro para recuperar uma lista de modelos semânticos específica do usuário ou de todo o -Scope locatário. A escolha que você fizer depende da sua decisão de como usar o PowerShell (abordada na tabela anterior).

A tabela a seguir descreve como os parâmetros usados no cmdlet do PowerShell se convertem para as chamadas do API PowerShell.

Parâmetros do cmdlet	API usada pelo cmdlet	Tipo de API	Scope	Itens recuperados
-DatasetID {DatasetID} -Scope Individual	Obter conjunto de dados	User	Espaço de trabalho pessoal	Um modelo semântico
-Scope Individual	Obter conjuntos de dados	User	Espaço de trabalho pessoal	Todos os modelos semânticos
-DatasetID {DatasetID} -GroupID {WorkspaceID}	Obter conjunto de dados no grupo	User	Um espaço de trabalho	Um modelo semântico, desde que o usuário conectado tenha permissão para ler o modelo semântico
-GroupID {WorkspaceID}	Obter conjuntos de dados no grupo	User	Um espaço de trabalho	Todos os modelos semânticos, desde que o usuário conectado tenha permissão para acessar o espaço de trabalho e ler o modelo semântico
-GroupID {WorkspaceID} -Scope Organization	Obter conjuntos de dados no grupo como administrador	Admin	Um espaço de trabalho	Todos os modelos semânticos
-Scope Organization	Obter conjuntos de dados como administrador	Admin	Inquilino inteiro	Todos os modelos semânticos

Considerações sobre o uso de cmdlets do PowerShell

Os cmdlets do PowerShell do Power BI são mais simples de usar porque abstraem parte da complexidade das chamadas da API REST.

Aqui estão algumas das maneiras pelas quais os cmdlets simplificam o acesso aos dados de auditoria.

• Autenticação: a maneira mais simples de autenticar em um script do PowerShell é usar o Connect-PowerBIServiceAccount cmdlet.
• Simplicidade: é mais simples começar porque as técnicas para recuperar dados de auditoria são simples. Considere que, ao usar o cmdlet Get-PowerBIActivityEvent , você recupera um dia de dados de auditoria. No entanto, quando você chama diretamente a API REST Get Activity Events , recupera uma hora de dados de auditoria. Portanto, quando você usa a API REST para recuperar um dia de dados de auditoria, você deve usar um loop para chamar a API 24 vezes para extrair cada hora do dia.
• Paginação de grandes conjuntos de resultados: Grandes conjuntos de resultados são recuperados eficientemente pela paginação. A paginação envolve a recuperação de uma parte dos resultados de cada vez. Os cmdlets gerenciam automaticamente a paginação para você. No entanto, quando você usa diretamente as APIs REST, seu script deve verificar um token de continuação para determinar se há mais resultados por vir. O script deve continuar recuperando partes de resultados até que nenhum token de continuação seja recebido. Para obter um exemplo de uso de um token de continuação, consulte API REST de eventos de atividade.
• Expirações do token de acesso: Após a autenticação, um token de acesso é retornado. Por padrão, ele expira após uma hora. Os cmdlets lidam com expirações de token de acesso para você. Dessa forma, você não precisa escrever lógica para solicitar um token de atualização.
• Formatação: os dados retornados por um cmdlet são formatados um pouco melhor do que os dados retornados pela API REST. A saída é mais fácil de usar. Para processos de auditoria automatizados, isso provavelmente não será um problema. No entanto, para processos de auditoria manual, a formatação mais agradável pode ser útil.

Considerações para usar as APIs REST diretamente

Às vezes, há vantagens em chamar as APIs REST do Power BI diretamente.

• Muito mais APIs disponíveis: há mais APIs REST disponíveis do que cmdlets do PowerShell. No entanto, não negligencie a flexibilidade do cmdlet Invoke-PowerBIRestMethod , que você pode usar para chamar qualquer uma das APIs REST do Power BI.
• Frequência das atualizações: a Microsoft atualiza as APIs REST com mais frequência do que atualiza os módulos do PowerShell. Por exemplo, se um novo atributo for adicionado à resposta da API Get Dataset , pode levar algum tempo até que ele fique disponível nos resultados do cmdlet Get-PowerBIDataset .
• Menos dependência de idioma/ferramenta: quando você usa as APIs REST diretamente (em vez de um cmdlet), não precisa usar o PowerShell. Ou, você pode optar por usar o PowerShell apenas para orquestrar a chamada de muitas APIs em um script. Ao remover (ou evitar) qualquer dependência do PowerShell, em algum momento no futuro você poderá reescrever sua lógica em um idioma diferente. Quando sua equipe de TI ou de desenvolvedores tem fortes preferências por ferramentas e idiomas, menos dependência pode ser uma consideração importante a ser levada em consideração.

Independentemente do método escolhido para usar, as APIs REST podem mudar ao longo do tempo. Quando uma tecnologia evolui, as APIs (e os módulos do PowerShell) podem ser preteridos e substituídos. Portanto, recomendamos que você crie propositalmente scripts que sejam simples de manter e resilientes à mudança.

Lista de verificação - Ao escolher se deseja acessar as APIs REST diretamente ou usando cmdlets do PowerShell, as principais decisões e ações incluem:

Determinar onde armazenar dados de auditoria

Ao planejar criar uma solução de auditoria de ponta a ponta, você precisará decidir onde armazenar os dados brutos (e os dados selecionados, que serão abordados na próxima seção). Suas decisões sobre armazenamento de dados estão relacionadas às suas preferências sobre como lidar com a integração de dados.

Ao extrair dados brutos de auditoria, mantenha-os simples. Recomendamos que você não selecione atributos específicos, execute transformações ou aplique qualquer formatação ao extrair os dados inicialmente. Em vez disso, extraia todos os atributos disponíveis e armazene os dados em seu estado original.

Aqui estão várias razões pelas quais armazenar os dados brutos em seu estado original é uma prática recomendada.

• Todos os dados disponíveis no histórico: Novos atributos e novos tipos de eventos ficarão disponíveis ao longo do tempo. Armazenar todos os dados brutos é uma boa maneira de garantir que você sempre terá acesso a quaisquer dados que estavam disponíveis no momento em que os extraiu. Mesmo quando você leva tempo — que pode ser semanas ou meses — para perceber que novos atributos de dados estão disponíveis, é possível analisá-los historicamente porque você os capturou nos dados brutos.
• Resiliente à mudança: se o formato de dados brutos mudar, o processo que extrai os dados não será afetado. Como alguns dados de auditoria são sensíveis ao tempo, é importante garantir que você projete um processo de extração de dados que não falhe quando ocorrer uma alteração na origem.
• Funções e responsabilidades: diferentes membros da equipe (como engenheiros de dados ou administradores de malha) podem ser responsáveis pela criação dos processos para acessar, extrair e armazenar os dados brutos de auditoria. A simplificação do processo de extração de dados facilita o trabalho conjunto de várias equipes.

Aqui estão algumas opções para armazenar dados brutos.

• Data lake ou armazenamento de objetos: um serviço em nuvem como o OneLake, especializado em armazenar arquivos de qualquer estrutura. É uma escolha ideal para armazenar os dados brutos de auditoria. Em uma arquitetura de data lake, os dados brutos devem ser armazenados na camada bronze.
• Sistema de arquivos: um sistema de arquivos (como Windows ou Linux) é uma escolha comum para armazenar os dados brutos de auditoria.
• Banco de dados: é possível armazenar dados JSON em um banco de dados relacional, como o Banco de Dados SQL do Azure. No entanto, é menos comum do que armazenar os dados em um data lake ou sistema de arquivos. Isso porque consultar e manter dados JSON pode se tornar desafiador e caro, especialmente à medida que os volumes de dados crescem.

Considere um exemplo envolvendo uma zona de dados brutos de um data lake. A zona tem uma hierarquia de pastas para armazenar dados do log de atividades: Raw > ActivityLog > YYYY > MM. As pastas são particionadas por ano e mês. Um arquivo armazenado na pasta month usa o seguinte formato: PBIActivityLog-YYYYMMDD-YYYYMMDDTTTT.json. AAAAMMDD representa os dados reais e AAAAMMDDTTTT representa o carimbo de data/hora de extração. Ao incluir o carimbo de data/hora de extração, você pode determinar qual arquivo é o mais recente (caso precise extrair os dados novamente). Por exemplo, se você extrair dados às 9h (UTC) de 25 de abril de 2023 para atividade em 23 de abril de 2023, o nome do arquivo será PBIActivityLog-20230523-202305250900.

É altamente recomendável que você use uma tecnologia que permita gravar os dados brutos em armazenamento imutável. O armazenamento imutável garante que, uma vez gravados, os dados não podem ser substituídos ou excluídos. Essa distinção é importante para os auditores e permite que você confie que os dados brutos são confiáveis.

Você também precisa considerar como armazenar com segurança os dados brutos. Normalmente, muito poucos usuários exigem acesso aos dados brutos. O acesso a dados brutos é normalmente fornecido com base nas necessidades, normalmente para engenheiros de dados e administradores de sistema. Seus auditores internos também podem precisar de acesso. Os membros da equipe responsáveis pela criação dos dados selecionados (descritos a seguir) também precisam ter acesso aos dados brutos.

Aqui estão algumas considerações para ajudá-lo a escolher seu armazenamento de dados brutos.

• É um processo de auditoria manual ou automatizado? Um processo de auditoria automatizado normalmente tem requisitos mais rígidos sobre como e onde os dados são armazenados.
• A área temática é particularmente sensível? Dependendo do tipo de dados e de quão confidenciais eles são, sua organização pode ter um requisito de como e onde eles são armazenados. Os dados de auditoria do Power BI contêm informações de identificação do usuário e endereços IP, portanto, devem ser armazenados em uma área segura.
• Existe uma tecnologia de armazenamento preferida? Pode haver uma tecnologia de armazenamento existente que esteja em uso na organização, portanto, é uma escolha lógica.
• Os usuários acessarão o armazenamento diretamente? O modelo de segurança é uma consideração importante. Normalmente, muito poucos usuários têm acesso a dados brutos. O acesso aos dados selecionados normalmente é disponibilizado aos criadores de conteúdo do Power BI que são responsáveis pela criação do modelo de dados centralizado (o modelo semântico que serve como camada para relatórios).
• Você tem requisitos de residência de dados? Algumas organizações têm requisitos legais ou regulatórios de residência de dados para armazenar dados em uma região de dados específica.
• Como serão organizados os dados? O uso da arquitetura medallion é uma prática comum, particularmente em implementações de data lake e lakehouse. O objetivo é armazenar seus dados em camadas de dados de bronze, prata e ouro. A camada de bronze contém os dados brutos originais. A camada prateada contém dados validados e desduplicados usados para transformações. A camada de ouro contém os dados selecionados e altamente refinados que estão prontos para análise.

Lista de verificação - Ao planejar o local para armazenar dados brutos, as principais decisões e ações incluem:

Planejar a criação de dados com curadoria

Os dados com curadoria suportam a análise e são projetados para serem fáceis de usar. Você precisa tomar algumas decisões sobre como e onde os dados selecionados serão criados. A tecnologia escolhida para armazenar os dados selecionados pode ser qualquer uma das tecnologias listadas na seção anterior.

O objetivo dos dados com curadoria é transformá-los em um formato mais amigável e otimizado para análise e relatórios. Ele forma a fonte de dados de um modelo de dados do Power BI, portanto, isso significa que você usa um modelo de dados do Power BI para analisar o uso do Power BI em sua organização. Aplica-se a orientação fundamental do modelo de dados: você deve adotar um design de esquema em estrela, que é otimizado para desempenho e usabilidade.

Você pode optar por criar dados com curadoria de diferentes maneiras. Você precisa decidir como fazer a integração de dados e até que ponto aplicar as transformações que preparam os dados para serem carregados em um esquema em estrela.

Data lake

Você pode aplicar transformações e criar arquivos de dados selecionados em um data lake. Você deve usar uma camada ouro para dados selecionados para que eles sejam logicamente separados dos dados brutos armazenados na camada bronze. Separar os dados em camadas também simplifica a configuração de diferentes permissões de acesso do usuário.

Use um data lake para transformar e organizar os dados quando:

• Você espera que haja vários modelos de dados do Power BI que servem para relatórios (o que justifica a criação de uma camada prata intermediária).
• Você precisa oferecer suporte a vários criadores de conteúdo de autoatendimento que precisam de acesso a dados de auditoria no nível do locatário.
• Você tem ferramentas e processos existentes que deseja usar para transformar e carregar dados.
• Você deseja minimizar a preparação de dados que precisa ser feita (e potencialmente duplicada) em um ou mais modelos de dados do Power BI.

Modelo de dados do Power BI

Talvez você consiga concluir todo o trabalho de transformação no Power BI. Utilize o Power Query para aceder e transformar os dados do seu estado bruto para o formato selecionado.

Use um modelo de dados do Power BI quando:

• Você deseja simplificar a arquitetura de ponta a ponta e carregar o modelo de dados diretamente dos dados brutos. (A atualização incremental pode ajudar a reduzir a duração da atualização.)
• Sua preferência é fazer todo o trabalho de transformação enquanto carrega o modelo de dados.
• Você espera ter um modelo de dados centralizado para os dados de auditoria no nível do locatário. Todos os relatórios (ou outros modelos de dados) podem usar o modelo semântico centralizado do Power BI como origem.
• Você deseja fornecer acesso de usuário somente ao modelo semântico centralizado do Power BI (e não a qualquer um dos dados de origem).

Para obter mais informações sobre quais tabelas de dimensões e tabelas de fatos você pode incluir em seu esquema em estrela, consulte Criar um modelo de dados mais adiante neste artigo.

Lista de verificação - Ao planejar como criar dados selecionados, as principais decisões e ações incluem:

Decisões sobre a fonte de dados

Neste ponto, você deve ser claro sobre requisitos, necessidades de dados e permissões. Foram tomadas decisões técnicas fundamentais. Agora você precisa tomar algumas decisões sobre a abordagem de como você obterá certos tipos de dados.

Acessar dados de atividade do usuário

Os dados de atividade do usuário do Power BI, que às vezes são chamados de log de atividades ou logs de auditoria, incluem uma grande variedade de informações para ajudá-lo a entender o que está acontecendo em seu locatário do Power BI. Para obter mais informações sobre como identificar suas necessidades de dados, consulte Dados de atividade do usuário anteriormente neste artigo.

O Power BI integra seus logs com o log de auditoria unificado do Microsoft Purview (anteriormente conhecido como log de auditoria unificado do Microsoft 365). Essa integração é uma vantagem porque significa que cada serviço no Microsoft 365 não precisa implementar sua própria maneira exclusiva de registro. Está ativada por predefinição.

Você tem várias opções para recuperar dados de atividade do usuário.

Técnica	Descrição	Dias padrão do histórico disponíveis	Boa escolha para processos manuais de auditoria	Boa escolha para processos de auditoria automatizados	Boa escolha para configurar alertas	Boa escolha para começar rapidamente
Manual (interface do utilizador)	Portal de conformidade do Microsoft Purview	90
Manual (interface do utilizador)	Defender para Aplicações Cloud	30
Programática	Log de atividades do Power BI (cmdlet da API ou do PowerShell)	30
Programática	API de Atividade de Gerenciamento do Office 365	7
Programática	Microsoft Sentinel (Azure Monitor)	30

O restante desta seção apresenta cada uma das técnicas apresentadas na tabela.

Portal de conformidade do Microsoft Purview

A ferramenta de pesquisa de auditoria no portal de conformidade do Microsoft Purview (anteriormente conhecido como o centro de conformidade do Microsoft 365) é um local conveniente para exibir atividades e alertas. Esta ferramenta não requer que você crie um script para extrair e baixar os dados. Você pode escolher uma carga de trabalho do Power BI para exibir todos os registros de log de auditoria por um intervalo de tempo. Você também pode restringir os resultados selecionando atividades e usuários específicos. Por exemplo, um gerente pede que você descubra quem excluiu um espaço de trabalho mais cedo naquele dia para que eles possam entrar em contato rapidamente com a pessoa para discutir a situação.

Os 90 dias de histórico mais recentes estão disponíveis com Auditoria (Padrão). Com a Auditoria (Premium), a retenção de longo prazo permite que você (opcionalmente) retenha os logs de auditoria por mais tempo. Como a retenção de longo prazo só se aplica a usuários licenciados do E5, ele exclui registros de auditoria para usuários não E5 e usuários convidados. Portanto, recomendamos que você confie apenas no histórico padrão de 90 dias para garantir que todas as atividades sejam capturadas.

Há requisitos de licenciamento para acessar os logs de auditoria no portal de conformidade do Microsoft Purview. Permissões elevadas do Exchange Online também são necessárias para acessar os logs de auditoria.

A interface do usuário no portal de conformidade do Microsoft Purview é útil para processos manuais de auditoria e investigações ocasionais das atividades do usuário.

Defender para Aplicações Cloud

O portal no Defender for Cloud Apps é um lugar conveniente para visualizar atividades e alertas sem a necessidade de criar um script para extrair e baixar os dados. Ele também permite que você exiba dados do log de atividades do Power BI e entradas de usuário.

O Defender for Cloud Apps inclui uma interface de utilizador para visualizar e pesquisar registos de atividade para vários serviços na nuvem, incluindo o Power BI. Ele exibe os mesmos eventos de log que se originam no log de auditoria unificado do Microsoft Purview e inclui outros eventos, como a atividade de entrada do usuário da ID do Microsoft Entra.

Como o portal de conformidade do Microsoft Purview (descrito na seção anterior), o Defender for Cloud Apps tem uma interface de usuário pesquisável. No entanto, as opções de filtro são diferentes. Além do histórico padrão de 30 dias, você pode usar o Defender for Cloud Apps para visualizar até seis meses de histórico de registro de atividades (em incrementos de sete dias).

Há requisitos de licenciamento para acessar o Defender for Cloud Apps. Permissões separadas também são necessárias.

A interface do usuário no Defender for Cloud Apps é útil para processos manuais de auditoria e investigações pontuais das atividades do usuário.

Log de atividades do Power BI

O log de atividades do Power BI é originado do log de auditoria unificado. Ele contém apenas atividades do usuário relacionadas ao serviço do Power BI.

Você tem duas opções para acessar o log de atividades do Power BI.

• Chame a API REST Get Activity Events usando a ferramenta de sua escolha.
• Use o cmdlet Get-PowerBIActivityEvent PowerShell. Ele está disponível no módulo Administração de Gerenciamento do Power BI.

Para obter informações sobre qual opção usar, consulte Escolher APIs ou cmdlets do PowerShell anteriormente neste artigo.

Os dados do log de atividades do Power BI estão disponíveis para todos os administradores de malha e administradores da Power Platform. Os dados podem ser acessados a partir do log de auditoria unificado, disponível para determinadas funções do Exchange Online. Para obter mais informações, consulte Controlar atividades do usuário no Power BI.

Recomendamos que você use o log de atividades do Power BI quando sua intenção for recuperar apenas os registros do log de auditoria do Power BI.

API de Atividade de Gerenciamento do Office 365

Você pode extrair dados do log de auditoria unificado para outros serviços, como SharePoint Online, Teams, Exchange Online, Dynamics 365 e Power BI. Quando seu objetivo é implementar uma solução de auditoria e monitoramento para vários serviços, recomendamos que você use a API de Atividade de Gerenciamento do Office 365. Como essa API retorna dados de muitos serviços, ela é conhecida como API de Auditoria Unificada (ou log de auditoria unificado). É uma das APIs de Gerenciamento do Office 365.

Antes de criar uma nova solução, recomendamos que você entre em contato com seu departamento de TI para determinar se os registros de auditoria existentes do Power BI estão disponíveis. É possível que um processo já extraia e armazene os dados. Também é possível que você obtenha permissão para acessar esses dados em vez de criar uma nova solução.

Você pode acessar os dados de duas maneiras.

• Chame a API de Atividade de Gerenciamento do Office 365 diretamente usando a ferramenta de sua escolha. Por padrão, a API retorna 24 horas de dados. Você pode recuperar um máximo de sete dias de histórico.
• Use o cmdlet Search-UnifiedAuditLog PowerShell. É um cmdlet do PowerShell do Exchange Online. Você pode recuperar um máximo de 90 dias de histórico.

Em geral, começar a usar a API de Atividade de Gerenciamento do Office 365 é mais desafiador do que usar o log de atividades do Power BI (descrito anteriormente). Isso ocorre porque a API retorna blobs de conteúdo e cada blob de conteúdo contém registros de auditoria individuais. Para grandes organizações, pode haver milhares de blobs de conteúdo por dia. Como os clientes e aplicativos de terceiros usam muito essa API, a Microsoft implementa a limitação para garantir que o uso do serviço não afete negativamente outras pessoas (conhecido como o problema do vizinho barulhento). Portanto, recuperar grandes volumes de história pode ser um desafio em organizações maiores. Para obter mais informações, consulte este artigo de solução de problemas.

Para usar essa API, você deve se autenticar com uma entidade de serviço à qual tenha sido concedida permissão para recuperar dados da API de Atividade de Gerenciamento do Office 365.

Recuperar os dados de auditoria programaticamente da API de Atividade de Gerenciamento do Office 365 é uma boa opção quando a TI precisa extrair e armazenar logs de auditoria de vários serviços (além do Power BI).

Microsoft Sentinel

O Microsoft Sentinel é um serviço do Azure que lhe permite recolher, detetar, investigar e responder a incidentes e ameaças de segurança. Você pode configurar o Power BI no Microsoft Sentinel como um conector de dados. Quando conectados, os logs de auditoria (que contêm um subconjunto de dados) são transmitidos do Power BI para o Azure Log Analytics, que é um recurso do Azure Monitor.

Como é um serviço do Azure separado, qualquer administrador ou usuário que você queira executar consultas KQL (Kusto Query Language ) deve receber permissões no Azure Log Analytics (Azure Monitor). Quando tiverem permissão, poderão consultar os dados de auditoria armazenados na tabela PowerBIActivity . No entanto, lembre-se de que, na maioria dos casos, você concederá aos usuários acesso aos dados selecionados na camada ouro em vez dos dados brutos na camada bronze.

Você usa o KQL para analisar os eventos do log de atividades armazenados no Azure Log Analytics. Se você tem experiência em SQL, encontrará muitas semelhanças com o KQL.

Há várias maneiras de acessar os eventos armazenados no Azure Log Analytics. Pode utilizar:

• O aplicativo de modelo Log Analytics for Power BI Semantic Models pré-criado.
• Conector do Power BI Desktop para o Azure Data Explorer (Kusto).
• Experiência de consulta baseada na Web no Azure Data Explorer.
• Qualquer ferramenta de consulta que possa enviar consultas KQL.

O período do histórico que você pode recuperar depende da política de retenção de dados para o espaço de trabalho do Azure Log Analytics. Considere o custo e o acesso a dados brutos ao decidir a quantidade de dados a reter.

O Microsoft Sentinel e o Azure Monitor são boas opções quando a TI já fez um investimento com o Microsoft Sentinel, o nível de detalhe capturado atende às suas necessidades e atividades como a deteção de ameaças são uma prioridade. No entanto, como o Microsoft Sentinel não captura todos os dados de atividade do Power BI, ele não oferece suporte à execução de análises abrangentes de uso e adoção do Power BI.

Considerações sobre dados de atividade do usuário

Aqui estão algumas considerações para ajudá-lo a escolher sua fonte para os dados de atividade do usuário.

• Será um processo de auditoria manual ou automatizado? As opções da interface do usuário funcionam bem para processos de auditoria manual e consultas pontuais ocasionais, especialmente quando você precisa investigar uma atividade específica. Um processo de auditoria automatizado que extrai os dados de atividade do usuário em um cronograma também será necessário para dar suporte à análise de dados históricos.
• Com que frequência você precisa dos dados de atividade do usuário? Para processos de auditoria automatizados, planeje extrair dados que estejam pelo menos um dia antes da data atual usando o Tempo Universal Coordenado (UTC), em vez da hora local. Por exemplo, se o seu processo for executado na manhã de sexta-feira (hora UTC), você deve extrair dados de quarta-feira. Há várias razões pelas quais você deve extrair dados com latência de um dia.
  • Seus arquivos serão mais simples de trabalhar quando você sempre extrair 24 horas completas de cada vez, o que evita resultados parciais do dia.
  • Você minimizará o risco de perder alguns eventos de auditoria. Normalmente, os eventos de auditoria chegam em 30 minutos. Ocasionalmente, alguns eventos podem levar até 24 horas para chegar ao log de auditoria unificado.
• Precisa de mais do que dados do Power BI? Considere a maneira mais eficiente de acessar o que você precisa.
  • Quando precisar apenas de dados de atividade do usuário do Power BI, use o log de atividades do Power BI.
  • Quando precisar de logs de auditoria de vários serviços, use a API de Atividade de Gerenciamento do Office 365 para acessar o log de auditoria unificado.
• Quem desenvolverá a solução? Planeje investir algum tempo para construir a solução. Pode ser necessário um esforço significativo para produzir um script pronto para produção.

Lista de verificação - Ao planejar como acessar os dados de atividade do usuário, as principais decisões e ações incluem:

Acessar dados de inventário de locatários

Um inventário de inquilinos é uma parte inestimável e necessária de uma solução madura de auditoria e monitoramento. Ele ajuda você a entender quais espaços de trabalho e conteúdo (modelos semânticos, relatórios e outros itens) existem no Power BI e é um excelente complemento para os dados de atividade do usuário (descritos na seção anterior). Para obter mais informações sobre como identificar suas necessidades de dados, consulte Inventário de locatários anteriormente neste artigo.

As atividades do usuário (descritas anteriormente) são eventos auditados; eles são um registro de ações que um usuário tomou em uma data e hora específicas. No entanto, o inventário do inquilino é diferente. O inventário do locatário é um instantâneo em um determinado momento. Ele descreve o estado atual de todos os itens publicados no serviço do Power BI no momento em que você o extraiu.

Para analisar corretamente o que está acontecendo em seu locatário do Power BI, você precisa dos dados de atividade do usuário e do inventário do locatário. Combiná-los permite que você entenda quanto conteúdo você tem e onde ele está localizado. Ele também permite que você encontre conteúdo não utilizado ou subutilizado (porque não haverá eventos para ele no registro de atividades). O inventário do locatário também ajuda a compilar uma lista de nomes atuais para todos os itens, o que é útil quando os nomes dos itens são alterados.

Para obter mais informações sobre o valor do inventário do locatário, consulte Inventário do locatário anteriormente neste artigo.

Você pode obter dados de inventário de locatários de duas maneiras diferentes.

Técnica	Descrição	Mais adequado para	Boa escolha para processos manuais de auditoria	Boa escolha para processos de auditoria automatizados
Programática	A Get Groups as Admin API ou o Get-PowerBIWorkspace cmdlet do PowerShell pode fornecer uma lista de espaços de trabalho para todo o locatário. Opcionalmente, itens individuais (como modelos semânticos e relatórios) por espaço de trabalho podem ser incluídos.	Organizações menores ou baixo volume de dados
Programática	Um conjunto de APIs de administração assíncronas, conhecidas coletivamente como APIs de verificação de metadados ou APIs de scanner, pode retornar uma lista de espaços de trabalho e itens individuais. Opcionalmente, metadados detalhados (como tabelas, colunas e expressões de medida) também podem ser incluídos.	Organizações com alto volume de dados e/ou necessidade de obter resultados detalhados

O restante desta seção apresenta cada uma das técnicas apresentadas na tabela.

Cmdlet de APIs de grupos ou espaços de trabalho

Para recuperar uma lista de espaços de trabalho, você pode usar uma das várias APIs REST, como Obter grupos como API de administração (usando a ferramenta de sua escolha). Os resultados incluem metadados extras, como a descrição e se o espaço de trabalho está armazenado em uma capacidade Premium.

A Get Groups as Admin API REST inclui o parâmetro útil $expand . Esse parâmetro permite que você expanda opcionalmente os resultados para que eles incluam uma lista de itens publicados no espaço de trabalho (como modelos semânticos e relatórios). Você também pode passar o users tipo de dados para o $expand parâmetro para incluir os usuários atribuídos a uma função de espaço de trabalho.

Você também pode usar o cmdlet Get-PowerBIWorkspace PowerShell. É do módulo Espaços de Trabalho de Gerenciamento do Power BI. Quando você define o -Scope parâmetro organization, ele funciona como a Get Groups as Admin API. O cmdlet também aceita o -Include parâmetro (que é o equivalente ao $expand parâmetro na API REST) para incluir itens publicados no espaço de trabalho (como modelos semânticos e relatórios).

Para ajudá-lo a escolher qual opção usar, consulte Escolher APIs ou cmdlets do PowerShell anteriormente neste artigo.

A Get Groups as Admin API REST ou o Get-PowerBIWorkspace cmdlet PowerShell é mais adequado para processos manuais de auditoria e investigações pontuais. Organizações maiores com alto volume de dados normalmente acham essas opções difíceis de usar. A API REST e o cmdlet sempre extraem um conjunto completo de dados, para que possam levar muito tempo para serem executados. Assim, também é provável que organizações maiores encontrem limitações no número de solicitações permitidas por hora (conhecido como limitação, que é feito para proteger a saúde do serviço). As APIs de verificação de metadados (descritas a seguir) fornecem uma alternativa mais confiável e escalável.

APIs de verificação de metadados

As APIs de verificação de metadados, comumente chamadas de APIs de scanner, são um conjunto de APIs que retornam uma lista de espaços de trabalho e seus itens do Power BI (modelos semânticos, relatórios e outros itens). Conceitualmente, eles fornecem os mesmos dados (e mais) que as APIs de grupos ou o cmdlet de espaço de trabalho, que são descritos na seção anterior. No entanto, o método usado para recuperar os dados é diferente e mais adequado para extrair o inventário do locatário.

Há dois motivos principais pelos quais você deve considerar o uso das APIs de verificação de metadados em vez da API REST Get Groups as Admin ou do Get-PowerBIWorkspace cmdlet (descrito anteriormente).

• Extração incremental de dados: as APIs do scanner extraem apenas dados alterados desde a última vez em que foram executados. Por outro lado, a Get Groups as Admin API REST e o Get-PowerBIWorkspace cmdlet são operações síncronas que extraem o conjunto completo de dados sempre que são executados.
• Nível de detalhe mais granular: as APIs do scanner podem recuperar detalhes granulares (como tabelas, colunas e expressões de medida), fornecendo permissão concedida pelas duas configurações de locatário para metadados detalhados. Por outro lado, o nível mais baixo de detalhe disponível com a Get Groups as Admin API REST e o Get-PowerBIWorkspace cmdlet é por tipo de item (por exemplo, uma lista de relatórios em um espaço de trabalho).

Usar as APIs do scanner envolve mais esforço porque você precisa chamar uma série de APIs. Além disso, eles são executados como um processo assíncrono . Um processo assíncrono é executado em segundo plano e, portanto, você não precisa esperar que ele termine. Talvez seja necessário colaborar com a TI ou com um desenvolvedor na hora de criar um script pronto para produção que será agendado.

Aqui está a sequência de etapas que seu processo deve seguir ao usar as APIs do scanner.

1. Entrar: entre no serviço do Power BI usando uma conta de administrador do Power BI ou uma entidade de serviço que tenha permissão para executar APIs de administrador. Para obter mais informações, consulte Determinar o método de autenticação anteriormente neste artigo.
2. Obter as IDs da área de trabalho: envie uma solicitação para recuperar uma lista de IDs da área de trabalho. Na primeira vez que for executado, você não terá uma data de modificação, portanto, ele retornará uma lista completa de espaços de trabalho. Normalmente, você passará a data de modificação para recuperar apenas espaços de trabalho que foram alterados desde esse momento. A data de alteração deve ser dentro dos últimos 30 dias.
3. Iniciar uma verificação de metadados: inicie uma chamada para solicitar uma verificação de informações do espaço de trabalho passando as IDs do espaço de trabalho recuperadas na Etapa 2. Observe que esta é uma API POST (em vez de uma API GET , que é mais comum ao recuperar dados de auditoria). Uma API POST é uma solicitação HTTP que cria ou grava dados para um recurso especificado. Esta consulta especifica o nível de detalhe que será extraído, como detalhes da fonte de dados, esquema de modelo semântico, expressões de modelo semântico ou usuários. Quando enviada, uma ID para a verificação é retornada pela API. Ele também retorna a data e a hora da verificação, que você deve registrar como a data do instantâneo.
4. Verificar o estado da análise: utilize o ID da análise obtido no Passo 3 para obter o estado da análise. Talvez seja necessário chamar essa API mais de uma vez. Quando o status retornado for Bem-sucedido, poderá prosseguir para a próxima etapa. O tempo necessário para digitalizar depende da quantidade de dados solicitada.
5. Obter os resultados: Use o ID da verificação obtido na Etapa 3 para obter o resultado da verificação e extrair os dados. Deve efetuar este passo no prazo de 24 horas após concluir o Passo 4. Lembre-se de que o carimbo de data/hora do instantâneo deve ser correlacionado com a Etapa 3 em vez da Etapa 5 (quando há um atraso significativo). Dessa forma, você terá um carimbo de data/hora de instantâneo preciso. Guarde os resultados na sua localização de armazenamento de dados preferida. Conforme descrito neste artigo, recomendamos que você armazene os dados brutos em seu estado original.
6. Prepare-se para o próximo processo: Registre o carimbo de data/hora da verificação na Etapa 3 para que você possa usá-la na Etapa 2 na próxima vez que executar o processo. Dessa forma, você só extrairá dados que foram alterados desde aquele momento. No futuro, todas as extrações de dados subsequentes serão alterações incrementais em vez de instantâneos completos.

Lista de verificação - Ao planejar o acesso aos dados de inventário do inquilino, as principais decisões e ações incluem:

Aceder a dados de utilizadores e grupos

Além das informações de identificação (como um endereço de e-mail) incluídas nos dados de atividade do usuário, é valioso recuperar informações adicionais, como localização ou detalhes organizacionais. Você pode usar o Microsoft Graph para recuperar dados sobre usuários, grupos, entidades de serviço e licenças. O Microsoft Graph compreende um conjunto de APIs e bibliotecas de clientes que permitem recuperar dados de auditoria de uma ampla variedade de serviços.

Aqui estão alguns detalhes sobre os objetos do Microsoft Entra que você pode acessar.

• Usuário: uma identidade que existe no Microsoft Entra ID como uma conta de trabalho, escola ou Microsoft. O termo usuário de domínio é frequentemente usado para descrever usuários organizacionais, enquanto o termo formal é nome principal do usuário (UPN). Um UPN é geralmente o mesmo valor que o endereço de e-mail do usuário (no entanto, se um endereço de e-mail mudar, o UPN não mudará porque é imutável). Há também uma ID exclusiva do Microsoft Graph para cada usuário. Muitas vezes, uma conta de usuário está associada a uma pessoa. Algumas organizações criam usuários que são contas de serviço usadas para atividades automatizadas ou para tarefas administrativas.
• Entidade de serviço: um tipo diferente de identidade, que é provisionado quando você cria um registro de aplicativo. Uma entidade de serviço destina-se a atividades autônomas e automatizadas. Para obter mais informações, consulte Determinar o método de autenticação anteriormente neste artigo.
• Grupo: uma coleção de usuários e entidades de serviço. Há vários tipos de grupos que você pode usar para simplificar o gerenciamento de permissões. Para obter mais informações, consulte Estratégia para usar grupos.

Os dados de usuários e grupos que você recupera são um instantâneo que descreve o estado atual em um determinado momento.

Atributos analíticos

Para auditoria no nível de locatário do Power BI, você pode extrair e armazenar os seguintes atributos do Microsoft Graph.

• Nome completo dos usuários: muitas fontes de dados incluem apenas o endereço de e-mail do usuário que realizou uma atividade ou que está atribuído a uma função. Use esse atributo quando quiser exibir o nome completo (nome para exibição) em relatórios analíticos. O uso do nome completo torna os relatórios mais fáceis de usar.
• Outras propriedades do usuário: Outros atributos descritivos sobre os usuários podem estar disponíveis no Microsoft Entra ID. Alguns exemplos de atributos de perfil de usuário internos que têm valor analítico incluem cargo, departamento, gerente, região e local do escritório.
• Membros de um grupo de segurança: a maioria das fontes de dados fornece o nome de um grupo (por exemplo, o log de atividades do Power BI registra que um grupo de segurança foi atribuído a uma função de espaço de trabalho). Recuperar a associação ao grupo melhora sua capacidade de analisar completamente o que um usuário individual está fazendo ou tem acesso.
• Licenças de usuário: é útil analisar quais licenças de usuário — gratuitas, Power BI Pro ou Power BI Premium por usuário (PPU) — são atribuídas aos usuários. Esses dados podem ajudá-lo a identificar quem não está usando sua licença. Ele também ajuda você a analisar todos os usuários (usuários distintos com uma licença) versus usuários ativos (com atividades recentes). Se estiver a considerar adicionar ou expandir as suas licenças do Power BI Premium, recomendamos que analise os dados de licença do utilizador juntamente com os dados de atividade do utilizador para efetuar uma análise de custos.
• Membros das funções de administrador: você pode compilar uma lista de seus administradores do Power BI (o que inclui administradores da Power Platform).

Para obter a referência autoritativa das informações de licença do Power BI que você pode encontrar nos dados de auditoria do Microsoft Graph, consulte Nomes de produtos e identificadores de plano de serviço para licenciamento.

Aqui estão alguns outros atributos que você pode extrair e armazenar.

• Tipo de usuário: os usuários são membros ou convidados. Mais comumente, os membros são usuários internos e os convidados são usuários externos (B2B). Armazenar o tipo de usuário é útil quando você precisa analisar as atividades de usuários externos.
• Alterações de função: quando você executa uma auditoria de segurança, é útil entender quando um usuário mudou de função na organização (por exemplo, quando eles são transferidos para um departamento diferente). Dessa forma, você pode verificar se as configurações de segurança do Power BI foram — ou deveriam ser — atualizadas.
• Usuários desabilitados: quando um usuário sai da organização, geralmente um administrador desativa sua conta. Você pode criar um processo para verificar se os usuários desabilitados são administradores de espaço de trabalho ou proprietários de modelos semânticos.

Recuperar dados de usuários e grupos

Você pode recuperar dados sobre usuários e grupos de diferentes maneiras.

Técnica	Descrição	Boa escolha para processos manuais de auditoria	Boa escolha para processos de auditoria automatizados
Manual	Explorador de Gráficos
Programática	APIs e SDKs do Microsoft Graph
Programática	Módulo do PowerShell Az

O restante desta seção apresenta cada uma das técnicas apresentadas na tabela. Outras técnicas, que são preteridas e não devem ser usadas para novas soluções, são descritas no final desta seção.

Microsoft Graph Explorer

O Microsoft Graph Explorer é uma ferramenta de desenvolvedor que permite que você aprenda sobre as APIs do Microsoft Graph. É uma maneira simples de começar, porque não requer outras ferramentas ou configuração em sua máquina. Você pode entrar para recuperar dados de seu locatário ou recuperar dados de exemplo de um locatário padrão.

Você pode usar o Graph Explorer para:

• Envie manualmente uma solicitação para uma API do Microsoft Graph para verificar se ela retorna as informações desejadas.
• Veja como construir a URL, os cabeçalhos e o corpo antes de escrever um script.
• Verifique os dados de forma informal.
• Determine quais permissões são necessárias para cada API. Você também pode fornecer consentimento para novas permissões.
• Obtenha trechos de código para usar ao criar scripts.

Use este link para abrir o Graph Explorer.

APIs e SDKs do Microsoft Graph

Use as APIs do Microsoft Graph para recuperar dados de usuários e grupos. Você também pode usá-lo para recuperar dados de serviços como Microsoft Entra ID, SharePoint Online, Teams, Exchange, Outlook e muito mais.

Os SDKs do Microsoft Graph atuam como um wrapper de API sobre as APIs subjacentes do Microsoft Graph. Um SDK é um kit de desenvolvimento de software que reúne ferramentas e funcionalidades. Os SDKs do Microsoft Graph expõem todo o conjunto de APIs do Microsoft Graph.

Você pode optar por enviar solicitações diretamente para as APIs. Como alternativa, você pode adicionar uma camada de simplificação usando seu idioma preferido e um dos SDKs. Para obter mais informações, consulte Escolher APIs ou cmdlets do PowerShell anteriormente neste artigo.

Os SDKs do Microsoft Graph oferecem suporte a vários idiomas e também há os módulos do Microsoft Graph PowerShell . Outros SDKs estão disponíveis para Python, C# e outras linguagens.

Você pode instalar os módulos do Microsoft Graph PowerShell a partir da Galeria do PowerShell. Como o Microsoft Graph funciona com muitos serviços do Microsoft 365, há muitos módulos do PowerShell que você instala.

Para auditoria no nível de locatário do Power BI, aqui estão os módulos mais comuns do PowerShell que você precisará instalar.

• Autenticação (para iniciar sessão)
• Utilizadores
• Grupos
• Aplicativos (e entidades de serviço)
• Objetos de diretório (e detalhes da licença)

Módulo do PowerShell Az

Você também pode usar o módulo Az PowerShell para recuperar dados de usuários e grupos. Ele se concentra nos recursos do Azure.

Você pode usar o cmdlet Invoke-AzRestMethod quando não houver um cmdlet correspondente para uma API. É uma abordagem flexível que permite enviar uma solicitação para qualquer API do Microsoft Graph usando o módulo Az PowerShell.

A partir da versão 7 do Az, os cmdlets Az agora fazem referência à API do Microsoft Graph. Portanto, o módulo Az atua como um wrapper de API sobre o Microsoft Graph. Os módulos Az têm um subconjunto de funcionalidade contido nas APIs do Microsoft Graph e nos módulos do PowerShell. Para novas soluções, recomendamos que você use o SDK do Microsoft Graph PowerShell.

APIs e módulos preteridos

Você pode encontrar artigos e postagens de blog on-line que sugerem opções alternativas que não são apresentadas nesta seção. É altamente recomendável que você não crie novas soluções (e/ou migre suas soluções existentes) usando qualquer uma das seguintes APIs ou módulos.

• Módulos do AzureRM PowerShell: Preteridos e serão desativados. Eles foram substituídos pelo módulo Az PowerShell.
• API do Azure AD Graph e módulo do Azure AD PowerShell: preterido e será desativado. Essa alteração é o resultado da migração do Azure AD Graph para o Microsoft Graph (observe que o Graph aparece em ambos os nomes, mas o Microsoft Graph é a direção futura). Todos os investimentos futuros do PowerShell serão feitos no SDK do Microsoft Graph PowerShell. (O Microsoft Entra ID agora é conhecido como Microsoft Entra ID.)
• Módulo PowerShell do MS Online (MSOL): Preterido e será desativado. Todos os investimentos futuros do PowerShell serão feitos no SDK do Microsoft Graph PowerShell.

Lista de verificação - Ao planejar o acesso a dados de usuários e grupos, as principais decisões e ações incluem:

Acessar dados de APIs REST do Power BI

Talvez como uma prioridade mais baixa, você também pode recuperar outros dados usando as APIs REST do Power BI.

Por exemplo, você pode recuperar dados sobre:

• Todos os aplicativos na organização.
• Todos os modelos semânticos importados na organização.
• Todos os pipelines de implantação na organização.
• Todas as capacidades Premium na organização.

Durante uma auditoria de segurança, convém identificar:

• Itens que foram amplamente compartilhados com toda a organização.
• Itens que estão disponíveis na Internet pública usando publicar na Web.

Para obter mais informações sobre os outros tipos de APIs, consulte Escolher uma API de usuário ou uma API de administrador anteriormente neste artigo.

Lista de verificação - Ao planejar o acesso a dados das APIs do Power BI, as principais decisões e ações incluem:

Fase 2: Pré-requisitos e configuração

A segunda fase do planejamento e implementação de uma solução de auditoria no nível do locatário concentra-se nos pré-requisitos e na configuração que devem ser feitos antes de iniciar o desenvolvimento da solução.

Criar conta de armazenamento

Neste ponto, você decidiu um local para armazenar dados brutos e como criar dados selecionados. Com base nessas decisões, você está pronto para criar uma conta de armazenamento. Dependendo dos processos da sua organização, isso pode envolver o envio de uma solicitação à TI.

Conforme descrito anteriormente, recomendamos o uso de uma tecnologia que permita gravar os dados brutos em armazenamento imutável. Depois que os dados são gravados, eles não podem ser alterados ou excluídos. Você pode então ter confiança nos dados brutos porque sabe que um administrador com acesso não pode alterá-los de forma alguma. Os dados selecionados, no entanto, não precisam (geralmente) ser armazenados em armazenamento imutável. Os dados selecionados podem mudar ou podem ser regenerados.

Lista de verificação – Ao criar uma conta de armazenamento, as principais decisões e ações incluem:

Instalar software e configurar serviços

Neste ponto, você tomou suas decisões sobre qual tecnologia usar para acessar dados de auditoria. Com base nessas decisões, você está pronto para instalar software e configurar serviços.

Configure o ambiente de desenvolvimento preferido para cada administrador. O ambiente de desenvolvimento permitirá que eles escrevam e testem scripts. O Visual Studio Code é uma ferramenta moderna para desenvolver scripts, por isso é uma boa opção. Além disso, muitas extensões estão disponíveis para trabalhar com o Visual Studio Code.

Se você tomou a decisão (descrita anteriormente) de usar o PowerShell, instale o PowerShell Core e os módulos necessários do PowerShell em:

• A máquina de cada administrador/desenvolvedor que escreverá ou testará scripts de auditoria.
• Cada máquina virtual ou servidor que executará scripts agendados.
• Cada serviço online (como o Azure Functions ou a Automação do Azure).

Se você optou por usar quaisquer serviços do Azure (como Azure Functions, Azure Automation, Azure Data Factory ou Azure Synapse Analytics), você deve provisioná-los e configurá-los também.

Lista de verificação – Ao instalar software e configurar serviços, as principais decisões e ações incluem:

Registar uma aplicação Microsoft Entra

Neste ponto, você decidiu como autenticar. Recomendamos que você registre um aplicativo Microsoft Entra (entidade de serviço). Comumente chamado de registro de aplicativo, ele deve ser usado para operações autônomas que você automatizará.

Para obter mais informações sobre como criar um registro de aplicativo para recuperar dados de auditoria no nível do locatário, consulte Habilitar a autenticação da entidade de serviço para APIs de administração somente leitura.

Lista de verificação - Ao registrar um aplicativo Microsoft Entra, as principais decisões e ações incluem:

Definir configurações de locatário do Power BI

Há várias configurações de locatário no portal de administração do Power BI que são relevantes para extrair dados de auditoria no nível do locatário.

APIs de administrador

Há três configurações de locatário que são relevantes para executar APIs de administrador.

A configuração de locatário Permitir que entidades de serviço usem APIs de administração do Power BI somente leitura permite definir quais entidades de serviço podem chamar APIs de administrador. Essa configuração também permite que o Microsoft Purview analise todo o locatário do Power BI para que ele possa preencher o catálogo de dados.

A configuração Aprimorar respostas da API de administração com metadados detalhados do locatário permite definir quais usuários e entidades de serviço podem recuperar metadados detalhados. Os metadados são recuperados usando as APIs de verificação de metadados e incluem tabelas, colunas e muito mais. Essa configuração também permite que o Microsoft Purview acesse informações no nível do esquema sobre modelos semânticos do Power BI para que possa armazená-las no catálogo de dados.

A configuração de locatário Aprimorar respostas da API de administração com DAX e expressões de mashup permite definir quais usuários e entidades de serviço podem recuperar metadados detalhados. Os metadados são recuperados das APIs de verificação de metadados e podem incluir consultas e expressões de medida de modelo semântico.

APIs do usuário

Há uma configuração de locatário que se aplica à chamada de APIs de usuário. Nessa situação, as permissões do Power BI também são necessárias para a entidade de serviço (por exemplo, uma função de espaço de trabalho).

A configuração de locatário Permitir que entidades de serviço usem APIs do Power BI permite definir quais entidades de serviço têm acesso para executar APIs REST (excluindo as APIs de administrador, que são concedidas por uma configuração de locatário diferente, descrita acima).

Há outras configurações de locatário relacionadas a APIs, que permitem o acesso às APIs de incorporação, APIs de streaming, APIs de exportação e à API de consultas de execução. No entanto, essas APIs estão fora do escopo deste artigo.

Para obter mais informações sobre as configurações de locatário para métricas de uso, consulte Auditoria no nível de relatório.

Lista de verificação - Ao configurar as configurações de locatário do Power BI, as principais decisões e ações incluem:

Fase 3: Desenvolvimento e análise de soluções

A terceira fase do planejamento e implementação de uma solução de auditoria em nível de locatário se concentra no desenvolvimento e análise de soluções. Neste ponto, todo o planejamento e tomada de decisão ocorreu, e você atendeu aos pré-requisitos e concluiu a configuração. Agora você está pronto para começar o desenvolvimento de soluções para que possa realizar análises e obter insights de seus dados de auditoria.

Extrair e armazenar os dados brutos

Neste ponto, seus requisitos e prioridades devem ser claros. As principais decisões técnicas foram tomadas sobre como acessar os dados de auditoria e o local para armazenar os dados de auditoria. As ferramentas preferidas foram selecionadas e os pré-requisitos e configurações foram configurados. Durante as duas fases anteriores, você pode ter concluído um ou mais pequenos projetos (provas de conceito) para provar a viabilidade. A próxima etapa é configurar um processo para extrair e armazenar os dados brutos de auditoria.

Como acontece com os dados retornados pela maioria das APIs da Microsoft, os dados de auditoria são formatados como JSON. Os dados formatados em JSON são autodescritivos porque são textos legíveis por humanos que contêm estrutura e dados.

JSON representa objetos de dados que consistem em pares atributo-valor e matrizes. Por exemplo, "state": "Active" é um exemplo em que o valor do atributo state é Ative. Uma matriz JSON contém uma lista ordenada de elementos separados por uma vírgula e que estão entre colchetes ([ ]). É comum encontrar matrizes aninhadas nos resultados JSON. Depois de se familiarizar com a estrutura hierárquica de um resultado JSON, é simples entender a estrutura de dados, como uma lista (matriz) de modelos semânticos em um espaço de trabalho.

Aqui estão algumas considerações para quando você extrai e armazena os dados brutos recuperados das APIs.

• Que convenção de nomenclatura será usada? Para um sistema baseado em arquivos, uma convenção de nomenclatura é necessária para arquivos, pastas e zonas de data lake. Para um banco de dados, uma convenção de nomenclatura é necessária para tabelas e colunas.
• Que formato será usado para armazenar os dados brutos? À medida que o Power BI continua a introduzir novos recursos, novas atividades aparecerão que não existem hoje. Por esse motivo, recomendamos que você extraia e mantenha os resultados JSON originais. Não analise, filtre ou formate os dados enquanto eles são extraídos. Dessa forma, você pode usar os dados brutos originais para regenerar seus dados de auditoria selecionados.
• Que local de armazenamento será utilizado? Um data lake ou armazenamento de blob é comumente usado para armazenar dados brutos. Para obter mais informações, consulte Determinar onde armazenar dados de auditoria anteriormente neste artigo.
• Quanta história você vai armazenar? Exporte os dados de auditoria para um local onde você possa armazenar o histórico. Planeje acumular pelo menos dois anos de história. Dessa forma, você pode analisar tendências e alterações além do período de retenção padrão de 30 dias. Você pode optar por armazenar os dados indefinidamente ou pode optar por um período mais curto, dependendo das políticas de retenção de dados da sua organização.
• Como você vai acompanhar quando o processo foi executado pela última vez? Configure um arquivo de configuração, ou equivalente, para registrar os carimbos de data/hora quando um processo for iniciado e concluído. Da próxima vez que o processo for executado, ele poderá recuperar esses carimbos de data/hora. É especialmente importante que você armazene carimbos de data/hora ao extrair dados usando as APIs de verificação de metadados.
• Como você vai lidar com a limitação? Algumas APIs REST do Power BI e a API do Microsoft Graph implementam a limitação. Você receberá um erro 429 (muitas solicitações) se sua solicitação de API for limitada. A limitação pode ser um problema comum para organizações maiores que precisam recuperar um grande volume de dados. Como você evita tentativas fracassadas devido à limitação depende da tecnologia que você usa para acessar e extrair os dados. Uma opção é desenvolver lógica em seus scripts que responda a um erro 429 "Muitas solicitações" tentando novamente após um período de espera.
• Os dados de auditoria são necessários para a conformidade? Muitas organizações usam os registros brutos de log de auditoria para fazer auditorias de conformidade ou responder a investigações de segurança. Nesses casos, é altamente recomendável armazenar os dados brutos em armazenamento imutável. Dessa forma, uma vez que os dados são gravados, eles não podem ser alterados ou excluídos por um administrador ou outro usuário.
• Quais camadas de armazenamento são necessárias para dar suporte às suas necessidades? Os melhores locais para armazenar dados brutos são um data lake (como o Azure Data Lake Storage Gen2) ou o armazenamento de objetos (como o Armazenamento de Blobs do Azure). Um sistema de arquivos também pode ser usado se os serviços de nuvem não forem uma opção.

Lista de verificação - Ao extrair e armazenar os dados brutos, as principais decisões e ações incluem:

Para obter mais informações sobre como uma solução de auditoria e monitoramento cresce ao longo do tempo, consulte Operacionalizar e melhorar mais adiante neste artigo.

Criar os dados selecionados

Neste ponto, os dados brutos são extraídos e armazenados. A próxima etapa é criar uma camada de dados ouro separada para os dados selecionados. Seu objetivo é transformar e armazenar os arquivos de dados em um esquema em estrela. Um esquema em estrela compreende tabelas de dimensões e tabelas de fatos, e é intencionalmente otimizado para análise e relatórios. Os arquivos na camada de dados selecionada se tornam a fonte de um modelo de dados do Power BI (descrito no próximo tópico).

Lista de verificação - Ao criar a camada de dados selecionada, as principais decisões e ações incluem:

Criar um modelo de dados

O tópico é sobre a configuração de um modelo de dados analíticos. Um modelo de dados é um recurso de dados consultável otimizado para análise. Às vezes é referido como um modelo semântico, ou simplesmente um modelo. Para sua solução de auditoria e monitoramento, o modelo de dados provavelmente será implementado como um modelo semântico do Power BI.

No contexto de auditoria e monitoramento, um modelo de dados obtém dados da camada de dados curada (ouro). Se você optar por não criar uma camada de dados selecionada, o modelo de dados obtém seus dados diretamente dos dados brutos.

Recomendamos que seu modelo de dados do Power BI implemente um design de esquema em estrela. Quando os dados de origem são a camada de dados selecionada, o esquema em estrela do modelo de dados do Power BI deve espelhar o esquema em estrela da camada de dados selecionada.

Como em qualquer projeto do Power BI, a criação de um modelo de dados é um processo iterativo. Você pode adicionar novas medidas conforme necessário. Você também pode adicionar novas tabelas e colunas à medida que novos eventos de auditoria ficam disponíveis. Com o tempo, você pode até integrar novas fontes de dados.

Aqui estão algumas tabelas de dimensão úteis que você pode incluir no modelo de dados.

• Data: um conjunto de atributos de data para permitir a análise (fatiamento e corte) de dados por dia, semana, mês, trimestre, ano e outros períodos de tempo relevantes.
• Tempo: Se você precisar analisar por hora do dia e tiver um volume muito grande de dados de auditoria, considere armazenar a parte de tempo separadamente da data. Essa abordagem pode ajudar a melhorar o desempenho da consulta.
• Usuários: atributos que descrevem usuários (como departamento e região geográfica) que podem filtrar muitos assuntos de dados de auditoria. O objetivo é remover todos os detalhes do usuário das tabelas de fatos e armazená-los nessa tabela de dimensões para que eles possam filtrar muitas tabelas de fatos. Você também pode armazenar entidades de serviço nesta tabela.
• Eventos de atividade: atributos que agrupam e descrevem os eventos de atividade (operações). Para aprimorar seus relatórios, você pode criar um dicionário de dados que descreva cada evento de atividade. Você também pode criar uma hierarquia que agrupe e classifique eventos de atividade semelhantes. Por exemplo, você pode agrupar todos os eventos de criação de itens, excluir eventos e assim por diante.
• Espaços de trabalho: uma lista de espaços de trabalho nas propriedades do locatário e do espaço de trabalho, como tipo (pessoal ou padrão) e descrição. Algumas organizações registram mais detalhes sobre espaços de trabalho (possivelmente usando uma lista do SharePoint). Você pode integrar esses detalhes nesta tabela de dimensões. Você precisa decidir se essa tabela de dimensão armazena apenas o estado atual do espaço de trabalho ou se armazena dados versionados que refletem alterações significativas no espaço de trabalho ao longo do tempo. Por exemplo, quando um nome de espaço de trabalho é alterado, o relatório histórico mostra o nome do espaço de trabalho atual ou o nome do espaço de trabalho que estava atualizado naquele momento? Para obter mais informações sobre controle de versão, consulte Alterando lentamente as dimensões.
• Tipos de item: uma lista de tipos de item do Power BI (modelos semânticos, relatórios e outros).
• Capacidades: Uma lista de capacidades Premium no inquilino.
• Gateways: uma lista de gateways de dados no locatário.
• Fontes de dados: uma lista de fontes de dados usadas por qualquer modelo semântico, fluxo de dados ou datamart.

Aqui estão algumas tabelas de fatos úteis (assuntos) que você pode incluir no modelo de dados.

• Atividades do usuário: os dados de fato que são originados dos dados JSON originais. Todos os atributos que não têm valor analítico são removidos. Todos os atributos que pertencem às tabelas de dimensão (acima) também são removidos.
• Inventário do locatário: um instantâneo point-in-time de todos os itens publicados no locatário. Para obter mais informações, consulte Inventário de locatários anteriormente neste artigo.
• Modelos semânticos: Inclui a atividade do usuário envolvendo modelos semânticos (como alterações de modelo semântico) ou fontes de dados relacionadas.
• Atualizações de modelo semântico: armazena operações de atualização de dados, incluindo detalhes sobre o tipo (agendado ou sob demanda), duração, status e qual usuário iniciou a operação.
• Funções do espaço de trabalho: um instantâneo point-in-time das atribuições de função do espaço de trabalho.
• Licenças de usuário: um instantâneo point-in-time das licenças de usuário. Embora você possa ficar tentado a armazenar a licença de usuário na tabela de dimensões Usuários , essa abordagem não suportará a análise de alterações e tendências de licença ao longo do tempo.
• Associações a grupos de usuários: um instantâneo point-in-time de usuários (e entidades de serviço) atribuídos a um grupo de segurança.
• Atividades comunitárias: Inclui factos relacionados com a comunidade, tais como eventos de formação. Por exemplo, você pode analisar as atividades do usuário do Power BI em comparação com a participação no treinamento. Estes dados poderão ajudar o Centro de Excelência a identificar potenciais novos campeões.

As tabelas de fatos não devem incluir colunas que os criadores de relatórios filtrarão. Em vez disso, essas colunas pertencem a tabelas de dimensões relacionadas. Esse design não só é mais eficiente para consultas, mas também promove a reutilização de tabelas de dimensões por vários fatos (conhecidos como drill across). Esse último ponto é importante para produzir um modelo de dados útil e fácil de usar que seja extensível quando você adiciona novas tabelas de fatos (assuntos).

Por exemplo, a tabela de dimensão Usuários estará relacionada a cada tabela de fatos. Ele deve estar relacionado à tabela de fatos de atividades do usuário (quem realizou a atividade), à tabela de fatos do inventário do locatário (quem criou o item publicado) e a todas as outras tabelas de fatos. Quando um relatório é filtrado por um usuário na tabela de dimensão Usuários , os elementos visuais desse relatório podem mostrar fatos para esse usuário a partir de qualquer tabela de fatos relacionada.

Ao projetar seu modelo, certifique-se de que um atributo esteja visível uma vez, e apenas uma vez, no modelo. Por exemplo, o endereço de e-mail do usuário só deve estar visível na tabela de dimensões Usuários . Ele também existirá em outras tabelas de fatos (como uma chave de dimensão para apoiar uma relação de modelo). No entanto, você deve escondê-lo em cada tabela de fatos.

Recomendamos que você crie seu modelo de dados separado dos relatórios. A dissociação de um modelo semântico e seus relatórios resulta em um modelo semântico centralizado que pode servir a muitos relatórios. Para obter mais informações sobre como usar um modelo semântico compartilhado, consulte o cenário de uso de BI de autoatendimento gerenciado.

Considere configurar a segurança em nível de linha (RLS) para que outros usuários — além do Centro de Excelência, auditores e administradores — possam analisar e relatar dados de auditoria. Por exemplo, você pode usar regras de RLS para permitir que criadores de conteúdo e consumidores relatem suas próprias atividades de usuário ou esforços de desenvolvimento.

Lista de verificação - Ao criar o modelo de dados, as principais decisões e ações incluem:

Melhorar o modelo de dados

Para analisar efetivamente o uso do conteúdo e as atividades do usuário, recomendamos que você enriqueça seu modelo de dados. Os aprimoramentos do modelo de dados podem ser feitos de forma gradual e iterativa ao longo do tempo, à medida que você descobre oportunidades e novos requisitos.

Criar classificações

Uma maneira de aprimorar o modelo e aumentar o valor dos dados é adicionar classificações ao modelo de dados. Certifique-se de que essas classificações sejam usadas de forma consistente pelos seus relatórios.

Você pode optar por classificar os usuários com base em seu nível de uso ou classificar o conteúdo com base em seu nível de uso.

Classificação de uso do usuário

Considere as seguintes classificações para uso do usuário.

• Utilizador frequente: Atividade registada na última semana e em nove dos últimos 12 meses.
• Usuário ativo: atividade registrada no mês anterior.
• Usuário ocasional: atividade registrada nos últimos nove meses, mas sem atividade no último mês.
• Usuário inativo: Nenhuma atividade registrada nos últimos nove meses.

Classificação de uso de conteúdo

Considere as seguintes classificações para uso de conteúdo.

• Conteúdo usado com frequência: atividade registrada na última semana e em nove dos últimos 12 meses.
• Conteúdo usado ativamente: atividade registrada no mês passado.
• Conteúdo usado ocasionalmente: atividade registrada nos últimos nove meses, mas sem atividade no último mês.
• Conteúdo não utilizado: Nenhuma atividade registrada nos últimos nove meses.

Classificação do tipo de utilizador

Considere as seguintes classificações para o tipo de usuário.

• Criador de conteúdo: atividade registrada nos últimos seis meses que criou, publicou ou editou conteúdo.
• Visualizador de conteúdo: atividade registrada nos últimos seis meses que visualizou conteúdo, mas sem qualquer atividade de criação de conteúdo.

Considere recenticidade versus tendências

Você deve decidir se as classificações de uso para usuários ou conteúdo devem ser baseadas apenas em como uma atividade ocorreu recentemente . Você também pode considerar considerar o uso médio ou em tendência ao longo do tempo.

Considere alguns exemplos que demonstram como a lógica de classificação simples pode deturpar a realidade.

• Um gerente viu um relatório esta semana. No entanto, até essa semana, o gestor não tinha visto nenhum relatório nos últimos seis meses. Você não deve considerar esse gerente como um usuário frequente com base apenas no uso recente.
• Um criador de relatórios publica um novo relatório todas as semanas. Quando você analisa o uso por usuários frequentes, a atividade regular do criador do relatório parece ser positiva. No entanto, após uma investigação mais aprofundada, você descobre que esse usuário está republicando um novo relatório (com um novo nome de relatório) toda vez que edita o relatório. Seria útil que o criador do relatório tivesse mais formação.
• Um executivo vê um relatório esporadicamente e, portanto, sua classificação de uso muda com frequência. Talvez seja necessário analisar certos tipos de usuários, como executivos, de forma diferente.
• Um auditor interno visualiza relatórios críticos uma vez por ano. O auditor interno pode parecer ser um usuário inativo devido ao seu uso pouco frequente. Alguém pode tomar medidas para remover sua licença Pro ou PPU. Ou, alguém pode acreditar que um relatório deve ser retirado, uma vez que é usado com pouca frequência.

Lista de verificação – Ao criar dados de classificação de uso, as principais decisões e ações incluem:

Criar relatórios analíticos

Neste ponto, os dados de auditoria foram extraídos e armazenados, e você publicou um modelo de dados. O próximo passo é criar relatórios analíticos.

Concentre-se nas principais informações mais relevantes para cada público. Você pode ter vários públicos para seus relatórios de auditoria. Cada público estará interessado em informações diferentes, e para fins diferentes. Os públicos que você pode atender com seus relatórios incluem:

• Patrocinador executivo
• Centro de Excelência
• Administradores do Power BI
• Administradores do Espaço de Trabalho
• Administradores de capacidade premium
• Administradores de gateway
• Desenvolvedores e criadores de conteúdo do Power BI
• Auditores

Aqui estão alguns dos requisitos analíticos mais comuns com os quais você pode querer começar ao criar seus relatórios de auditoria.

• Principais visualizações de conteúdo: seu patrocinador executivo e equipes de liderança podem estar predominantemente interessados em informações resumidas e tendências ao longo do tempo. Os administradores, desenvolvedores e criadores de conteúdo do seu espaço de trabalho estarão mais interessados nos detalhes.
• Principais atividades do usuário: seu Centro de Excelência estará interessado em quem está usando o Power BI, como e quando. Seus administradores de capacidade Premium estarão interessados em saber quem está usando a capacidade para garantir sua integridade e estabilidade.
• Inventário de locatário: seus administradores do Power BI, administradores de espaço de trabalho e auditores estarão interessados em entender qual conteúdo existe, onde, linhagem e suas configurações de segurança.

Esta lista não é completa. Destina-se a fornecer ideias sobre como criar relatórios analíticos que visam necessidades específicas. Para obter mais considerações, consulte Necessidades de dados anteriormente neste artigo e Visão geral de auditoria e monitoramento. Esses recursos incluem muitas ideias sobre como você pode usar dados de auditoria e os tipos de informações que você pode optar por apresentar em seus relatórios.

Lista de verificação - Ao planejar relatórios de auditoria analítica, as principais decisões e ações incluem:

Tome medidas com base nos dados

Os dados de auditoria são valiosos porque ajudam você a entender o que está acontecendo em seu locatário do Power BI. Embora possa parecer óbvio, agir explicitamente com base no que você aprende com os dados de auditoria pode ser facilmente ignorado. Por esse motivo, recomendamos que você designe alguém responsável por acompanhar melhorias mensuráveis, em vez de apenas revisar relatórios de auditoria. Dessa forma, você pode fazer avanços graduais e mensuráveis em sua adoção e nível de maturidade com o Power BI.

Você pode tomar muitas ações diferentes com base em seus objetivos e no que aprende com os dados de auditoria. O restante desta seção fornece várias ideias.

Utilização de conteúdos

Aqui estão algumas ações que você pode tomar com base em como o conteúdo é usado.

• O conteúdo é usado com frequência (diariamente ou semanalmente): verifique se qualquer conteúdo crítico é certificado. Confirme se a propriedade é clara e se a solução é adequadamente suportada.
• Alto número de modos de exibição de espaço de trabalho: quando ocorrer um grande número de modos de exibição de espaço de trabalho, investigue por que os aplicativos do Power BI não estão em uso.
• O conteúdo raramente é usado: entre em contato com os usuários-alvo para determinar se a solução atende às suas necessidades ou se os requisitos foram alterados.
• A atividade de atualização ocorre com mais frequência do que as visualizações: entre em contato com o proprietário do conteúdo para entender por que um modelo semântico é atualizado regularmente sem qualquer uso recente do modelo semântico ou relatórios relacionados.

Atividades do utilizador

Aqui estão algumas ações que você pode tomar com base nas atividades do usuário.

• Primeira ação de publicação de um novo usuário: identifique quando um tipo de usuário muda de consumidor para criador, o que você pode identificar quando eles publicam conteúdo pela primeira vez. É uma ótima oportunidade para enviar um e-mail padrão que fornece orientação e links para recursos úteis.
• Envolvimento com os criadores de conteúdo mais frequentes: convide os seus criadores mais ativos para se juntarem à sua rede de campeões ou para se envolverem com a sua comunidade de prática.
• Gerenciamento de licenças: verifique se os criadores inativos ainda precisam de uma licença Pro ou PPU.
• Ativação de avaliação do usuário: uma ativação de licença de avaliação pode solicitar que você atribua uma licença permanente ao usuário antes que a avaliação termine.

Oportunidades de formação de utilizadores

Aqui estão algumas oportunidades de treinamento de usuários que você pode identificar a partir dos dados de auditoria.

• Grande número de modelos semânticos publicados pelo mesmo criador de conteúdo: ensine os usuários sobre modelos semânticos compartilhados e por que é importante evitar a criação de modelos semânticos duplicados.
• Compartilhamento excessivo de um espaço de trabalho pessoal: entre em contato com um usuário que está compartilhando muito de seu espaço de trabalho pessoal. Ensine-os sobre espaços de trabalho padrão.
• Visualizações de relatório significativas de um espaço de trabalho pessoal: entre em contato com um usuário que possui conteúdo com um alto número de visualizações de relatório. Ensine-lhes como os espaços de trabalho padrão são melhores do que os espaços de trabalho pessoais.

Segurança

Aqui estão algumas situações de segurança que você pode querer monitorar ativamente.

• Muitos usuários atribuídos à função de administrador de malha de alto privilégio.
• Muitos administradores de espaço de trabalho (quando a função de espaço de trabalho Membro, Colaborador ou Visualizador seria suficiente).
• Permissões de compilação excessivas atribuídas a modelos semânticos (quando permissão de Ler seria suficiente).
• Alto uso de permissões por item, quando as permissões do aplicativo Power BI ou a função Visualizador do espaço de trabalho seriam uma escolha melhor para os consumidores de conteúdo.
• Como o conteúdo é compartilhado com usuários externos.

Para obter mais informações, consulte os artigos de planejamento de segurança.

Governação e mitigação de riscos

Aqui estão algumas situações que você pode encontrar. Considere procurar explicitamente esses tipos de situações em seus relatórios de auditoria, para que você esteja preparado para agir rapidamente.

• Alto número de visualizações para relatórios (e modelos semânticos subjacentes) que não são endossados.
• Utilização significativa de fontes de dados desconhecidas ou não sancionadas.
• Locais de arquivos que não estão alinhados com as diretrizes de governança para onde os arquivos de origem devem ser localizados.
• Os nomes dos espaços de trabalho não estão alinhados com os requisitos de governança.
• Os rótulos de sensibilidade são usados para proteção de informações.
• Falhas consistentes de atualização de dados.
• Uso significativo e recorrente da impressão.
• Utilização inesperada ou excessiva de subscrições.
• Uso inesperado de gateways pessoais.

As ações específicas a serem tomadas em cada situação dependerão de suas políticas de governança. Para obter mais informações, consulte Governança no roteiro de adoção do Fabric.

Lista de verificação - Ao planear potenciais ações com base nos dados da auditoria, as principais decisões e ações incluem:

Fase 4: Manter, melhorar e monitorar

A quarta fase de planejamento e implementação de uma solução de auditoria no nível do locatário concentra-se na manutenção, melhorias e monitoramento. Neste ponto, sua solução de auditoria está em uso em produção. Agora, você está preocupado principalmente em manter, aprimorar e monitorar a solução.

Operacionalizar e melhorar

Normalmente, considera-se que os processos de auditoria estão em execução na produção quando o desenvolvimento e os testes iniciais estão concluídos e você automatizou o processo. Os processos de auditoria automatizados executados na produção têm maiores expectativas (do que os processos manuais) em termos de qualidade, confiabilidade, estabilidade e suporte.

Foi operacionalizado um processo de auditoria ao nível da produção. Uma solução operacionalizada geralmente inclui muitas das seguintes características.

• Seguro: as credenciais são armazenadas e gerenciadas com segurança. Os scripts não contêm senhas ou chaves em texto sem formatação.
• Agendamento: Um sistema de agendamento confiável está em vigor.
• Gerenciamento de alterações: o uso de práticas de gerenciamento de alterações e vários ambientes são usados para garantir que o ambiente de produção seja protegido. Você também pode trabalhar com ambientes de desenvolvimento e teste ou apenas um ambiente de desenvolvimento.
• Suporte: A equipa que suporta a solução está claramente definida. Os membros da equipe foram treinados e entendem as expectativas operacionais. Os membros de backup foram identificados e o treinamento cruzado acontece quando apropriado.
• Alerta: Quando algo corre mal, os alertas notificam automaticamente a equipa de suporte. De preferência, o alerta inclui logs e e-mail (em vez de apenas e-mail). Um log é útil para analisar erros e avisos registrados.
• Log: os processos são registrados para que haja um histórico de quando os dados de auditoria foram atualizados. As informações registradas devem registrar a hora de início, a hora de término e a identidade do usuário ou aplicativo que executou o processo.
• Tratamento de erros: scripts e processos manipulam e registram erros (como sair imediatamente, continuar ou esperar e tentar novamente). As notificações de alerta são enviadas para a equipe de suporte quando ocorre um erro.
• Padrões de codificação: Boas técnicas de codificação que funcionam bem são usadas. Por exemplo, os loops são propositadamente evitados, exceto quando necessário. Padrões de codificação, comentários, formatação e sintaxe consistentes são usados para que a solução seja mais fácil de manter e suportar.
• Reutilização e modularização: para minimizar a duplicação, os valores de código e configuração (como cadeias de conexão ou endereços de e-mail para notificações) são modularizados para que outros scripts e processos possam reutilizá-los.

Lista de verificação - Ao planejar a operacionalização e melhoria de uma solução de auditoria, as principais decisões e ações incluem:

Documentação e suporte

A documentação e o suporte são essenciais para qualquer solução de nível de produção. É útil criar vários tipos de documentação, dependendo do público-alvo e da finalidade.

Documentação técnica

A documentação técnica destina-se à equipa técnica que criou a solução e que irá gradualmente melhorar e expandir a solução ao longo do tempo. Também é um recurso útil para a equipe de suporte.

A documentação técnica deve incluir:

• Um resumo dos componentes e pré-requisitos da arquitetura.
• Quem detém e gere a solução.
• Quem apoia a solução.
• Um diagrama de arquitetura.
• Decisões de projeto, incluindo metas, razões pelas quais certas escolhas técnicas foram feitas e restrições (como custo ou habilidades).
• Decisões e escolhas de segurança.
• Convenções de nomenclatura usadas.
• Codificação e normas técnicas e diretrizes.
• Requisitos de gestão de alterações.
• Instruções de implantação, configuração e instalação.
• Áreas conhecidas de dívida técnica (áreas que podem ser melhoradas se houver oportunidade para o fazer).

Documentação de suporte

Dependendo do nível de criticidade para sua solução de auditoria, você pode ter um suporte técnico ou uma equipe de suporte caso surjam problemas urgentes. Eles podem estar disponíveis o dia todo, todos os dias.

A documentação de suporte às vezes é chamada de base de dados de conhecimento ou runbook. Esta documentação destina-se ao suporte técnico ou à equipa de suporte e deve incluir:

• Orientação de solução de problemas para quando algo dá errado. Por exemplo, quando há uma falha de atualização de dados.
• Ações a empreender numa base contínua. Por exemplo, pode haver algumas etapas manuais que alguém precisa fazer regularmente até que um problema seja resolvido.

Documentação do criador de conteúdo

Você obtém mais valor de sua solução de auditoria fornecendo análises de uso e adoção para outras equipes em toda a organização (com segurança em nível de linha imposta, se necessário).

A documentação do criador de conteúdo é direcionada a criadores de conteúdo de autoatendimento que criam relatórios e modelos de dados que originam os dados de auditoria selecionados. Inclui informações sobre o modelo de dados, incluindo definições de dados comuns.

Lista de verificação – Ao planejar a documentação e o suporte para sua solução de auditoria, as principais decisões e ações incluem:

Ativar alertas

Talvez você queira gerar alertas com base em condições específicas nos dados de auditoria. Por exemplo, você pode gerar um alerta quando alguém exclui um gateway ou quando um administrador do Power BI altera uma configuração de locatário.

Para obter mais informações, consulte Monitoramento no nível do locatário.

Gestão contínua

Você precisa realizar o gerenciamento contínuo de toda a solução de auditoria. Talvez seja necessário estender ou alterar sua solução de auditoria quando:

• A organização descobre novos requisitos de dados.
• Novos eventos de auditoria aparecem nos dados brutos extraídos das APIs REST do Power BI.
• A Microsoft faz alterações nas APIs REST do Power BI.
• Os funcionários identificam maneiras de melhorar a solução.

Lista de verificação - Ao planejar o gerenciamento contínuo da solução de auditoria, as principais decisões e ações incluem:

Conteúdos relacionados

No próximo artigo desta série, saiba mais sobre o monitoramento no nível do locatário.