Share via

Planejamento de implementação do Power BI: auditoria em nível de dados

  • Artigo

Observação

Este artigo faz parte da série de artigos sobre o Planejamento de implantação do Power BI. Esta série se concentra principalmente na carga de trabalho do Power BI dentro do Microsoft Fabric. Para ter uma introdução a essa série, confira Planejamento de implementação do Power BI.

Este artigo sobre o planejamento de auditoria em nível de locatário é direcionado principalmente para:

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

Importante

Recomendamos que você siga de perto o plano de lançamento do Power BI para saber mais sobre os aprimoramentos futuros dos recursos de auditoria e monitoramento.

A finalidade 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 em nível de locatário são valiosos para muitas finalidades, permitindo que você analise os esforços de adoção, entenda os padrões de uso, eduque os usuários, dê suporte aos usuários, reduza o risco, melhore a conformidade, gerencie os custos de licença e monitore o desempenho.

Criar uma solução de auditoria de ponta a ponta que esteja segura e pronta para produção é um projeto significativo que leva tempo. Pense nisso como a criação de business intelligence no business intelligence (BI no 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 em nível de relatório, que é direcionada para os criadores de relatório, consulte Auditoria em nível de relatório.

Para auditoria de ativos de dados, que é direcionada para os criadores de dados, consulte Auditoria em nível de dados.

O restante deste artigo se concentra na auditoria em nível de locatário.

Dica

O foco principal deste artigo é ajudá-lo a planejar a criação de uma solução de auditoria de ponta a ponta. Como o conteúdo deste artigo é organizado em quatro fases, você precisará de informações em várias fases. Por exemplo, você encontrará informações na Fase 1 sobre como planejar o uso de uma entidade de serviço e informações na Fase 2 sobre pré-requisitos e configuração.

Portanto, recomendamos que você leia este artigo inteiro primeiro para se familiarizar com o que está envolvido. Em seguida, você deve estar bem preparado para planejar e criar sua solução de auditoria de maneira iterativa.

Ao planejar criar uma solução de auditoria em nível de locatário, planeje gastar tempo nas quatro fases a seguir.

Fase 1: planejamento e decisões

A primeira fase se concentra no planejamento e na tomada de decisões. Há muitos requisitos e prioridades a serem considerados, portanto, recomendamos que você reserve tempo suficiente para entender os tópicos introduzidos nesta seção. O objetivo é tomar boas decisões antecipadas para que as fases downstream sejam executadas sem problemas.

Diagrama de fluxo descrevendo a Fase 1, que se concentra no planejamento e nas decisões para construir uma solução de auditoria em nível de locatário.

Requisitos e prioridades

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

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

  • Quais perguntas-chave você precisa responder? Há um grande volume de dados de auditoria que você pode explorar. A maneira mais eficaz de abordar a auditoria é se concentrar em responder a perguntas específicas.
  • Quais são suas metas 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.
  • Quais 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 do usuário foi aprimorado e agora você deseja auditar as configurações e atividades de segurança continuamente.
  • Existem KPIs (indicadores chave de desempenho) ou metas organizacionais atuais? Por exemplo, talvez você tenha um KPI organizacional relacionado à transformação digital ou se tornando uma organização mais controlada por dados. Os dados de auditoria em nível de locatário podem ajudá-lo a medir se a implementação do Power BI está alinhada com essas metas.

Dica

Verifique os requisitos de auditoria e defina prioridades com seu patrocinador executivo e com o Centro de Excelência. É tentador extrair dados de auditoria e começar a criar relatórios com base em muitos dados interessantes. No entanto, é improvável que você derive alto valor de sua solução de auditoria quando ela não for orientada por perguntas que você precisa responder e ações que você pretende executar.

Para obter mais ideias sobre maneiras de 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:

  • Identificar requisitos: colete e documente os principais requisitos de negócios para auditar seu locatário do Power BI.
  • Priorizar requisitos: defina prioridades para os requisitos classificando-as como imediatas, de curto, médio e longo prazos (lista de pendências).
  • Criar um plano para as prioridades imediatas: coloque um plano em vigor para começar a coletar dados para que eles fiquem disponíveis quando você precisar.
  • Reavaliar requisitos regularmente: crie um plano para reavaliar os requisitos regularmente (por exemplo, duas vezes por ano). Verifique se a solução de auditoria e monitoramento atende aos requisitos declarados. Atualize os itens de ação em seu plano conforme necessário.

Necessidades de dados

Depois de definir os requisitos e as prioridades (descritos anteriormente), você estará pronto para identificar os dados necessários. Quatro categorias de dados são abordadas nesta seção.

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

Dados da atividade do usuário

Defina como prioridade a obtenção de 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 finalidades.

Na maioria das vezes, esses dados são chamados de log de atividades ou log de eventos. Tecnicamente, há várias maneiras de adquirir dados de atividade do usuário (sendo o log de atividades um dos métodos). 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.

  • Localizar os principais usuários e conteúdo
    • Qual conteúdo é exibido com mais frequência e por quais usuários?
    • Quais são as tendências diária, semanal e mensal para exibir conteúdo?
    • As visualizações de relatório estão aumentando ou diminuindo?
    • Quantos usuários estão ativos?
  • Noções básicas do comportamento do usuário
    • Que tipo de segurança é usado com mais frequência (aplicativos, workspaces 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?
    • Qual conteúdo é publicado ou atualizado, quando e por quais usuários?
  • Identificar oportunidades de treinamento e educação do usuário
    • Quem está fazendo muito compartilhamento de seu workspace pessoal?
    • Quem está fazendo uma quantidade significativa de exportações?
    • Quem está baixando conteúdo regularmente?
    • Quem está publicando muitos modelos semânticos novos, anteriormente conhecidos como conjuntos de dados?
    • Quem está usando muito as assinaturas?
  • Aprimorar 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?
    • Qual conteúdo é acessado por usuários externos, por quem, quando e como?
    • Quem adicionou ou atualizou um rótulo de sensibilidade?
    • Qual porcentagem de exibições de relatório se baseiam em conjuntos de relatórios certificados?
    • Qual porcentagem de modelos semânticos dá suporte a mais de um relatório?
    • Quando um gateway ou uma fonte de dados é criado ou atualizado?

Para obter mais informações sobre maneiras de usar esses dados, consulte Entender os padrões de uso.

Importante

Se você ainda não estiver extraindo e armazenando dados de atividades do usuário, torne isso uma prioridade urgente. No mínimo, certifique-se de extrair os dados brutos e armazená-los em um local seguro. Dessa forma, os dados estarão disponíveis quando você estiver pronto para analisá-los. O histórico fica disponível por 30 dias ou 90 dias, dependendo da fonte usada.

Para obter mais informações, confira Acessar dados de atividade do usuário a seguir neste artigo.

Inventário de locatários

Geralmente, a segunda prioridade é recuperar os dados para criar um inventário de locatários. Às vezes, ele é chamado de inventário de workspace, metadados de workspace ou metadados de locatário.

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

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

  • Entender quanto conteúdo você tem e onde
    • Quais workspaces têm mais conteúdo?
    • Que tipo de conteúdo é publicado em cada workspace (especialmente quando você está separando workspaces de relatório e workspaces de dados)?
    • Quais dependências existem entre itens (como fluxos de dados que dão suporte a 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)?
    • Há relatórios órfãos (que são desconectados de seu modelo semântico)?
  • Entenda a proporção de modelos semânticos para relatórios
    • Quanta reutilização de modelos semânticos está ocorrendo?
    • Há modelos semânticos duplicados ou altamente semelhantes?
    • Há oportunidades para consolidar modelos semânticos?
  • Entender as tendências entre momentos
    • O número de relatórios está aumentando ao longo do tempo?
    • O número de modelos semânticos aumenta ao longo do tempo?
  • Localizar conteúdo não utilizado
    • Quais relatórios não são utilizados (ou subutilizados)?
    • Quais modelos semânticos são não utilizados (ou são subutilizados)?
    • Há oportunidades para desativar o 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 neste 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 neste momento registrará o nome do relatório antigo. Com um modelo de dados definido corretamente, você pode usar o inventário de locatários mais recente para localizar um item pelo nome atual (em vez de o nome anterior). Para saber mais, confira Criar um modelo de dados mais adiante neste artigo.

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

Dica

Geralmente você combinará os eventos de atividade do usuário (descritos na seção anterior) e o inventário de locatários para produzir uma imagem completa. Dessa forma, você aprimora o valor de todos os dados.

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

Há duas maneiras principais de criar um inventário de locatários. Para obter mais informações sobre as decisões e atividades envolvidas, consulte Acessar dados de atividade do usuário mais adiante neste artigo.

Dados de usuários e grupos

À medida que suas necessidades analíticas crescerem, 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 autoritativa para obter informações sobre usuários e grupos do Microsoft Entra ID (anteriormente conhecido como Azure Active 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 email), departamento ou local originado 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 de usuário
    • Quais licenças — Power BI Pro ou PPU (Power BI Premium por usuário)— são atribuídas aos usuários?
    • Quais usuários se conectam com mais frequência?
    • Quais usuários não se conectaram ao serviço do Power BI recentemente?

Aviso

Alguns métodos mais antigos (que estão amplamente documentados online) para acessar dados de usuários e grupos foram preteridos e não devem ser usados. Sempre que possível, use o Microsoft Graph como a fonte autoritativa de dados de usuários e grupos.

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

Talvez você tenha um requisito para executar auditorias de segurança regulares.

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

Importante

Às vezes, este artigo se refere ao Power BI Premium ou às suas assinaturas de capacidade (P SKUs). Lembre-se de que a Microsoft está consolidando atualmente as opções de compra e desativando os SKUs do Power BI Premium por capacidade. Em vez disso, os clientes novos e existentes devem considerar a compra de SKUs (assinaturas de capacidade do Fabric).

Para obter mais informações, consulte Atualização importante chegando ao de licenciamento do Power BI Premium e Perguntas frequentes do Power BI Premium.

Dica

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

Essas perguntas comuns não são uma lista completa; há uma ampla variedade de APIs REST do Power BI disponível. 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 ela afeta as permissões necessárias para o usuário que está extraindo os dados), consulte Escolher uma API de usuário ou API de administrador posteriormente neste artigo.

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

  • Identificar necessidades de dados específicas para dados de atividade do usuário: valide os requisitos coletados. Identifique quais dados de auditoria são necessários para atender a cada requisito de dados de atividade do usuário.
  • Identificar necessidades de dados específicas para dados de inventário do locatário: valide os requisitos coletados. Identifique quais dados de auditoria são necessários para compilar um inventário de locatários.
  • Identificar necessidades de dados específicas para dados de usuários e grupos: valide os requisitos coletados. Identifique quais dados de auditoria são necessários para atender a cada requisito de dados de usuários e grupos.
  • Identificar necessidades de dados específicas para dados de segurança: valide os requisitos coletados. Identifique quais dados de auditoria são necessários para atender a cada requisito de dados de segurança.
  • Verificar prioridades: verifique a ordem das prioridades para que você saiba o que desenvolver primeiro.
  • Decidir com que frequência capturar atividades: decida com que frequência capturar eventos de atividade (como uma vez por dia).
  • Decidir com que frequência capturar instantâneos: decida o intervalo para capturar dados de instantâneo, como um inventário de locatários ou os dados de usuários e grupos.

Tipo de solução de auditoria

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

A maioria dos novos processos de auditoria começa como um processo manual, especialmente durante o desenvolvimento e os testes. 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 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 de auditoria pontual.
  • Necessidades exploratórias de auditoria.
  • Processos de auditoria não essenciais que não exigem suporte total.

Processos de auditoria automatizados

A auditoria recorrente de dados que são necessários deve ser automatizada. Ele é extraído e processado em um agendamento regular e é conhecido como um processo automatizado. Às vezes, ele é chamado de processo autônomo.

As metas 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:

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

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 de 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 a seguir neste artigo.

Dica

Se houver uma necessidade regular e recorrente de obter dados de auditoria que atualmente são tratados manualmente, considere investir tempo para automatizá-los. Por exemplo, se um administrador do Power BI executar um script todos os dias manualmente para recuperar dados do log de atividades do Power BI, haverá o risco de perda de dados se esse administrador estiver doente ou de férias.

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

  • Determinar a finalidade primária para cada novo requisito de auditoria: decida se deseja usar um processo manual ou automatizado para cada novo requisito. Considere se essa decisão é temporária ou permanente.
  • Criar um plano de como automatizar: quando for apropriado para um requisito de auditoria específico, crie um plano de como automatizá-lo, quando e por quem.

Permissões e responsabilidades

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

Permissões de usuário

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

Aqui estão algumas das considerações que devem ser feitas.

Acesso direto aos dados de auditoria

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

  • Quem deve ser um administrador do Power BI? Um administrador do Power BI tem acesso a todos os metadados de locatário, incluindo as APIs de administrador. 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 muito controlado.
  • O acesso precisa ser fortemente controlado? Determinados setores com requisitos regulatórios e de conformidade devem controlar o acesso mais fortemente do que outros setores.
  • Há grandes volumes de dados de atividade? Para evitar atingir o topo da 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 exibir os dados brutos extraídos e gravados em um local de armazenamento. Geralmente, o acesso a dados brutos é restrito a administradores e auditores. O COE (Centro de Excelência) também pode exigir acesso. Para obter mais informações, consulte Determinar onde armazenar dados de auditoria mais adiante neste artigo.

Acesso a dados analíticos coletados

Você deve decidir quem pode exibir os dados coletados e transformados que estão prontos para análise. Esses dados sempre devem ser disponibilizados para 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 coletados mais adiante neste artigo.

Funções e responsabilidades

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

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

Função Tipos de responsabilidades Função normalmente executada por
Comunicar-se com stakeholders Atividades de comunicação e coleta de requisitos. COE em parceria com TI. Também pode incluir pessoas selecionadas nas principais unidades de negócios.
Decidir prioridades e fornecer direçã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 escalonar questões.
Extrair e armazenar os dados brutos Criação de scripts e processos para acessar e extrair os 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 coletados Limpeza de dados, transformação e criação dos dados coletados 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 coletados. Criadores de conteúdo do Power BI, geralmente em TI ou no COE.
Criar relatórios de análise Criação de relatórios para analisar os dados coletados. Alterações contínuas em relatórios com base em novos requisitos e quando novos dados de auditoria são disponibilizados. Criadores de relatório do Power BI, geralmente em TI ou no COE.
Analisar os dados e agir sobre os resultados Análise dos dados e tomada de ação em resposta aos dados de 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, legal, gerenciamento de riscos ou gerenciamento de alterações.
Testar e validar Teste para garantir que os requisitos de auditoria sejam atendidos e que os dados apresentados sejam precisos. Criadores 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 coletados. Gerenciar o acesso a modelos semânticos criados para analisar os dados. Administrador do sistema que armazena os dados, em parceria com a equipe que supervisiona o Power BI na organização.
Agendamento e automação Operacionalize uma solução e agende o processo com a ferramenta de escolha. Equipe de engenharia de dados, geralmente em TI e em parceria com o COE.
Fornecer suporte à solução Monitore a solução de auditoria, incluindo execuções de trabalho, erros e suporte para problemas técnicos. A equipe que manipula o suporte ao sistema do Power BI, que geralmente é a TI ou o COE.

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

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

Considere vários exemplos.

  • Exemplo 1: os dados de auditoria mostram que alguns usuários exportam dados com frequência para o Excel. Ação executada: o COE entra em contato com os usuários específicos para entender suas necessidades e ensiná-los alternativas melhores.
  • Exemplo 2: os dados de auditoria mostram que o acesso de usuário externo ocorre de maneira inesperada. Ações executadas: um administrador do 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 de 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 executada: o comitê de governança de dados inicia um projeto para estabelecer 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.

Observação

A configuração de processos de extração de dados geralmente é um esforço único com aprimoramentos ocasionais e solução de problemas. A análise e tomada de ação com base nos dados são esforços contínuos que ocorrem de forma recorrente.

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

  • Identificar quais equipes estão envolvidas: determine quais equipes estarão envolvidas na criação de ponta a ponta e no suporte da solução de auditoria.
  • Decidir permissões de usuário: determine como as permissões de usuário serão configuradas para acessar dados de auditoria. Crie a documentação das principais decisões para referência posterior.
  • Decidir funções e responsabilidades: verifique se as expectativas são claras para quem faz o que, especialmente quando várias equipes estão envolvidas. Crie uma documentação para funções e responsabilidades que inclua ações esperadas.
  • Atribuir funções e responsabilidades: atribua funções e responsabilidades específicas a pessoas ou equipes específicas. Atualize descrições de trabalho individuais com recursos humanos, quando apropriado.
  • Criar um plano de treinamento: estabeleça um plano para treinar a equipe quando ela precisar de novas habilidades.
  • Criar um plano de treinamento cruzado: verifique se o treinamento cruzado e os backups estão em vigor para as principais funções.

Decisões técnicas

Ao planejar uma solução de auditoria em nível de 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 planejamento envolve tomar as decisões a seguir.

Selecionar uma tecnologia para acessar 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 workspace de monitoramento do administrador.

Quando precisar acessar os dados diretamente e criar sua própria solução, você usará uma API (interface de programa aplicativo). As APIs foram projetadas para trocar dados por meio da 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 for capaz de enviar uma solicitação HTTP e receber uma resposta JSON.

Dica

Os cmdlets do PowerShell usam as APIs REST do Power BI para acessar os dados de auditoria. Para obter mais informações, confira Escolher APIs ou cmdlets do PowerShell a seguir neste artigo.

Esta seção se concentra na escolha de sua tecnologia. Para obter considerações sobre a fonte para acessar tipos específicos de dados de auditoria, consulte Decisões da fonte de dados mais adiante neste artigo.

Opções de plataforma

Há várias maneiras diferentes de acessar dados de auditoria. Dependendo da tecnologia escolhida, você pode pender para uma linguagem preferencial. Talvez você também precise tomar uma decisão específica sobre como agendar a execução de seus scripts. As tecnologias diferem amplamente em sua curva de aprendizado e facilidade de introdução.

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

Tecnologia Boa opção para processos manuais de auditoria Boa opção para processos automatizados de auditoria
Workspace de monitoramento do administrador O espaço de trabalho de monitoramento de administrador é uma boa opção para processos de auditoria manuais.
Tryit A Tryit é uma boa opção para processos manuais de auditoria.
PowerShell O PowerShell é uma boa opção para processos manuais de auditoria. O PowerShell é uma boa opção para processos automatizados de auditoria.
Power BI Desktop O Power BI Desktop é uma boa opção para processos manuais de auditoria.
Power Automate O Power Automate é uma boa opção para processos automatizados de auditoria.
Serviço preferencial do Azure O serviço preferencial do Azure é uma boa opção para processos automatizados de auditoria.
Ferramenta/linguagem preferencial A ferramenta/linguagem preferencial é uma boa opção para processos manuais de auditoria. A ferramenta/linguagem preferencial é uma boa opção para processos automatizados de auditoria.
Pesquisa de log de auditoria do Microsoft Purview A pesquisa de log de auditoria do Microsoft Purview é uma boa opção para processos automatizados de auditoria.
Defender for Cloud Apps Os Aplicativos Defender para Nuvem são uma boa opção para processos manuais de auditoria.
Microsoft Sentinel O Microsoft Sentinel é uma boa opção para processos automatizados de auditoria.

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

Workspace de monitoramento do administrador

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

Documentação da API da Tryit

A Tryit é 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 elas não exigem outras ferramentas ou qualquer configuração em seu computador.

Você pode usar a Tryit para:

  • Enviar manualmente uma solicitação para uma API para determinar se ela retorna as informações desejadas.
  • Saber como a URL é construída antes de gravar um script.
  • Verificar os dados de maneira informal.

Observação

Você deve ser um usuário licenciado e autenticado do Power BI para usar a Tryit. Ela segue o modelo de permissões padrão, o que significa que as APIs de usuário dependem de permissões de usuário e as APIs de administrador exigem permissões de administrador do Power BI. Você não pode se autenticar com a Tryit usando uma entidade de serviço.

Por ser interativa, a Tryit é mais adequada para aprendizado, 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.

Há várias opções comuns.

  • Visual Studio Code: um editor de código-fonte leve e moderno. É uma ferramenta de código aberto disponível gratuitamente com suporte em várias plataformas, incluindo Windows, macOS e Linux. Você pode usar o Visual Studio Code com várias linguagens, incluindo o PowerShell (usando a extensão do PowerShell).
  • Azure Data Studio: uma ferramenta para criar scripts e notebooks. É construído sobre o Visual Studio Code. O Azure Data Studio está disponível de forma independente ou com SSMS (SQL Server Management Studio). 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 em um navegador.
  • Azure Functions: uma alternativa para trabalhar com o PowerShell localmente. Azure Functions é um serviço do Azure que permite gravar e executar código em um ambiente sem servidor. O PowerShell é uma das várias linguagens compatíveis com ele.

Importante

Recomendamos que você use a versão mais recente do PowerShell (PowerShell Core) para todo novo trabalho de desenvolvimento. Você deve descontinuar o uso do Windows PowerShell (que não pode executar o PowerShell Core) e, em vez disso, usar um dos editores de código modernos que dão suporte ao PowerShell Core. Tome cuidado ao fazer referência a muitos exemplos online que usam Windows PowerShell (versão 5.1) porque eles podem não usar as abordagens de código mais recentes (e melhores).

Você pode usar o PowerShell de várias maneiras diferentes. Para obter mais informações sobre essa decisão técnica, consulte Escolher APIs ou cmdlets do PowerShell 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, talvez você queira usá-lo para criar sua solução de auditoria. No entanto, há algumas desvantagens e complexidades significativas.

  • Acumular histórico: como o log de atividades do Power BI fornece até 30 dias de dados, criar toda a solução de auditoria envolve acumular um conjunto de arquivos ao longo do tempo que armazenam todos os eventos históricos. Acumular arquivos históricos é mais simples de fazer com outras ferramentas.
  • Manipular credenciais e chaves com segurança: muitas soluções que você encontra online de blogueiros de comunidade não são seguras porque codificam credenciais e chaves em texto não criptografado em consultas do Power Query. Embora seja fácil, essa abordagem não é recomendável, pois qualquer pessoa que obtiver seu arquivo Power BI Desktop pode ler os valores. Não é possível 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 você:
    • Use um conector personalizado que foi desenvolvido com o SDK do Power Query. Por exemplo, um conector personalizado pode ler valores confidenciais do Azure Key Vault ou de outro serviço que armazena com segurança o valor criptografado. Também há 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 quanto ao que pode ser executado no Power BI Desktop. Por exemplo, Power Query não dá suporte a todos os tipos de solicitação de API. Por exemplo, somente solicitações GET e POST têm suporte ao usar a função Web.Contents. Para auditoria, normalmente você envia solicitações GET.
  • Capacidade de atualizar: você precisa seguir padrões de desenvolvimento Power Query específicos para atualizar com êxito um modelo semântico no serviço do Power BI. Por exemplo, a opção RelativePath deve estar presente quando você usar Web.Contents para que o 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:

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

Você pode usar o Power Automate com o Power BI de várias maneiras. 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.

Dica

Para enviar solicitações para as APIs REST do Power BI, você pode usar um conector personalizado para o Power Automate para autenticar e extrair com segurança os dados de auditoria. Como alternativa, você pode usar o Azure Key Vault para fazer referência a uma senha ou segredo. Ambas as opções são melhores do que armazenar senhas e segredos em texto não criptografado no fluxo do Power Automate.

Para ter outras ideias sobre como usar o Power Automate, pesquise 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 preferencial do Azure, como:

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

Ferramenta e/ou linguagem preferencial

Você pode usar sua ferramenta e sua linguagem preferenciais para enviar solicitações para as APIs REST do Power BI. Essa é 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 .NET do Power BI, que atua como um wrapper sobre as APIs REST do Power BI para simplificar alguns processos e aumentar a produtividade.
  • JavaScript

O Portal de conformidade do Microsoft Purview (antigo centro de conformidade do Microsoft 365) inclui uma interface do usuário que permite exibir e pesquisar os logs de auditoria. Os logs de auditoria unificada incluem o Power BI e todos os outros serviços que dão suporte a logs de auditoria unificada do Microsoft 365.

Os dados capturados no log de auditoria unificada 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. Você 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, como:
    • Relatório do Power BI excluído
    • Acesso de administrador adicionado a um workspace 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 Portal de conformidade do Microsoft Purview mais adiante neste artigo.

Interface do usuário de Aplicativos Defender para Nuvem

O Defender para Aplicativos de Nuvem está disponível para administradores no Microsoft Defender XDR (portal do Microsoft 365). Eles incluem uma interface do usuário para exibir e pesquisar logs de atividades para vários serviços de nuvem, incluindo o Power BI. Ele exibe os mesmos eventos de log originados no portal de conformidade do Microsoft Purview, além de outros eventos, como a atividade de entrada do usuário do Microsoft Entra ID.

A interface do log de auditoria nos Aplicativos Defender para Nuvem é uma boa opção para processos manuais de auditoria. Para obter mais informações, consulte Aplicativos Defender para Nuvem mais adiante neste artigo.

Microsoft Sentinel e KQL

O Microsoft Sentinel é um serviço do Azure que permite coletar, detectar, 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 do Azure Monitor ). Você pode usar a KQL (Linguagem de Consulta Kusto) para analisar os eventos do log de atividades armazenados no Azure Log Analytics.

Usar a 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, confira Microsoft Sentinel mais adiante neste artigo.

Considerações sobre a plataforma

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

  • Você está implementando um processo de auditoria manual ou automatizado? Determinadas ferramentas se alinham fortemente ao processamento manual ou ao processamento automatizado. Por exemplo, um usuário sempre executa a funcionalidade Tryit interativamente, portanto, ela é adequada apenas para processos manuais de auditoria.
  • Como você se autenticará? Nem todas as opções dão suporte a todas as opções de autenticação. Por exemplo, a funcionalidade Tryit dá suporte apenas à autenticação do usuário.
  • Como você armazenará as credenciais com segurança? Diferentes tecnologias têm opções diferentes para armazenar credenciais. Para obter mais informações, consulte Determinar o método de autenticação a seguir neste artigo.
  • Com qual tecnologia sua equipe já é proficiente? Se houver uma ferramenta que sua equipe prefira e se sinta confortável em usar, comece por aí.
  • Qual é a capacidade de suporte da sua equipe? Se uma equipe diferente oferecer suporte à solução implantada, considere se essa equipe é capaz de dar suporte adequado a ela. Considere também que suas equipes internas podem dar suporte ao desenvolvimento feito por consultores.
  • Qual ferramenta você tem aprovação para usar? Determinadas ferramentas e tecnologias podem exigir aprovação. Isso pode ser devido ao custo. E também pode ser devido a políticas de segurança de TI.
  • Qual é a sua preferência para agendamento? Algumas tecnologias decidem por você. Outras vezes, você terá que tomar uma decisão. Por exemplo, se você optar por gravar scripts do PowerShell, haverá várias maneiras de agendar a execução deles. Por outro lado, se você usar um serviço de nuvem como Azure Data Factory, o agendamento será integrado.

Recomendamos que você examine 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:

  • Discutir com sua equipe de TI: converse com suas equipes de TI para descobrir se há determinadas ferramentas aprovadas ou preferenciais.
  • Explorar opções com uma pequena POC (prova de conceito): faça alguma experimentação com uma POC técnica. Inicialmente, o foco é no aprendizado. Depois, o foco é na sua decisão sobre o que usar daqui para frente.

Determinar o método de autenticação

A forma como você planeja configurar a autenticação é uma decisão crítica. Geralmente, um dos aspectos mais difíceis é quando você começa a fazer auditoria e monitoramento. Você deve considerar cuidadosamente as opções disponíveis para tomar uma decisão informada.

Importante

Consulte suas equipes de TI e segurança sobre esse assunto. Reserve um tempo para aprender as noções básicas de como funciona a segurança no Microsoft Entra ID.

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

Dica

O glossário de termos da plataforma de identidade da Microsoft é um recurso que ajuda você a se familiarizar com os conceitos básicos.

Antes de recuperar dados de auditoria, primeiro você deve se 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 é autenticado, 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, o token de acesso expira após uma hora. Um token de atualização pode ser solicitado, se necessário.

Há 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 do Microsoft Entra (entidade de serviço).

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

Observação

Um aplicativo do Microsoft Entra é uma configuração de identidade que permite que um processo automatizado se integre ao Microsoft Entra ID. Neste artigo, ele é conhecido como um registro de aplicativo. O termo entidade de serviço também é bastante usado neste artigo. Esses termos são descritos em mais detalhes posteriormente neste artigo.

Dica

A maneira mais fácil de se autenticar é usar o cmdlet Connect-PowerBIServiceAccount do módulo Gerenciamento do Power BI. Você pode ver outros cmdlets relacionados à autenticação em artigos e postagens de blog online. Por exemplo, há os cmdlets Login-PowerBI e Login-PowerBIServiceAccount, que são aliases para o cmdlet Connect-PowerBIServiceAccount. Há também o cmdlet Disconnect-PowerBIServiceAccount que você pode usar para sair explicitamente no final de um processo.

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

Tipo de autenticação Descrição Destinado a Boa opção para processos manuais de auditoria Boa opção para processos automatizados de auditoria
Autenticação de usuário Entre como usuário utilizando o nome principal do usuário (endereço de email) e uma senha. Uso ocasional e interativo A autenticação de usuário é uma boa opção para processos manuais de auditoria
Autenticação de entidade 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, agendadas e autônomas A autenticação de entidade de serviço é uma boa opção para processos automatizados de auditoria

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

Autenticação de usuário

A autenticação de usuário é útil nas situações a seguir.

  • Processos manuais de auditoria: você deseja executar um script usando suas permissões de usuário. As permissões podem estar em um dos 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 a 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 a uma API de usuário. Para obter mais informações, consulte Escolher uma API de usuário ou API de administrador.
  • Entrada interativa: você deseja entrar interativamente, o que exige que você insira seu endereço de email e senha. Por exemplo, você deve entrar interativamente para usar a experiência Tryit, que é encontrada na documentação da API da Microsoft.
  • Acompanhar quem acessou os metadados do locatário: quando usuários e administradores individuais 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), a ID de usuário capturada pelo log de atividades é a ID do Aplicativo. Se vários administradores se autenticam 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 ele é implementado e controlado, essa pode não ser uma prática recomendada. Em vez de uma conta compartilhada, você deve considerar o uso do Privileged Identity Management (PIM) do Microsoft Entra, que pode conceder direitos ocasionais e temporários de administrador do Power BI para um usuário.
  • APIs que dão suporte apenas à autenticação de usuário: ocasionalmente, talvez seja necessário usar uma API que não dá suporte à autenticação por uma entidade de serviço. Na documentação, cada API observa se uma entidade de serviço pode chamá-la.

Importante

Sempre que possível, recomendamos o uso de autenticação de entidade de serviço para processos automatizados.

Autenticação de entidade 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 do Microsoft Entra, há dois componentes.

  • Registro de aplicativo: um registro de aplicativo é globalmente exclusivo. É a definição global de um aplicativo registrado do Microsoft Entra 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 em um computador de usuário. No entanto, essa não é a situação para registros de aplicativo. No portal do Azure, os aplicativos do Microsoft Entra são encontrados na página Registros de aplicativo no Microsoft Entra ID.
  • Entidade de serviço: uma entidade de serviço é a representação local do registro de aplicativo para uso em seu locatário específico. A entidade de serviço é derivada do aplicativo do 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 de entidade de serviço é a maneira mais comum de se referir a entradas.

Dica

O administrador do Microsoft Entra pode informar quem tem permissão para criar e consentir com um registro de aplicativo em sua organização.

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

  • Processos de auditoria automatizados: você deseja executar um processo autônomo em um agendamento.
  • 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 aos 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 em nível de locatário (ou outras permissões específicas).
  • Uso por vários administradores: você deseja permitir que vários administradores ou usuários utilizem a mesma entidade de serviço.
  • Bloqueadores técnicos: há um bloqueador técnico que impede o uso da autenticação de usuário. Os bloqueadores técnicos comuns incluem:
    • MFA (autenticação multifator): 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 que uma conta de usuário seja autenticada. Às vezes, a TI ou uma equipe de segurança cibernética pode desabilitar essa funcionalidade.
Finalidade do registro de 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 de aplicativo).

Considere implementar 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: normalmente 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 de privilégios mínimos ao criar registros de aplicativo separados que só podem ler dados.
  • Público-alvo: opcional. Dependendo da carga de trabalho e finalidade, o público-alvo permite que você determine os usuários pretendidos do registro de 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 aplicativo que podem ser usados para extrair dados de auditoria em nível de locatário:

Nome do registro de aplicativo Finalidade Público-alvo
PowerBIData-Read-AdminAPIs-EntraApp Extraia metadados em 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 Gerenciar 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

O gerenciamento de vários registros de aplicativo para diferentes finalidades envolve mais esforço. No entanto, você pode se beneficiar de várias vantagens.

  • Ver para que o registro de aplicativo deve ser usado e por que: quando vir a ID do cliente do registro de aplicativo aparecer nos dados de auditoria, você terá uma ideia do que foi usado e por que. Essa é uma vantagem significativa da criação de registros de aplicativo separados (em vez de usar apenas um para todas as finalidades).
  • Ver por quem o registro de aplicativo deve ser usado: quando vir a ID do cliente do registro de aplicativo aparecer nos dados de auditoria, você terá uma ideia de quem o estava usando.
  • Evitar superprovisionamento de permissões: você pode seguir o princípio de privilégios mínimos fornecendo registros de aplicativo separados para diferentes conjuntos de pessoas que têm necessidades diferentes. Você pode evitar o superprovisionamento de permissões usando um registro de aplicativo somente leitura quando as permissões de gravação não são necessárias. Por exemplo, você pode ter alguns usuários de autoatendimento altamente capazes que desejam coletar dados sobre seus conjuntos de dados; eles precisam de 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 conjuntos de dados; eles precisam de acesso a uma entidade de serviço com permissão de gravação.
  • Saber quem deve estar em 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 posteriormente nesta seção), o impacto é menor quando você usa registros de aplicativo separados para diferentes necessidades. Isso é útil quando você precisa girar o segredo porque um usuário deixa a organização ou altera as funções.
Permissões de registro de aplicativo

Há duas maneiras principais pelas quais um registro de aplicativo pode acessar dados e recursos. Isso envolve permissões e consentimento.

  • Permissões somente de aplicativo: o acesso e a autorização são tratados 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 de aplicativo, é essencial entender que as permissões não são atribuídas no Microsoft Entra ID. Em vez disso, as permissões são atribuídas de uma das 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 administrador (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: as permissões de item e workspace do Power BI se aplicam. As permissões Standard 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. Lembre-se de que esse é um conceito diferente da autenticação somente do 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 aplicativo que são superprovisionados com permissões.

Importante

Neste artigo, o foco está apenas na autenticação do usuário ou na autenticação somente de aplicativo. As permissões delegadas (com um usuário interativo e a entidade de serviço) podem desempenhar uma função importante ao inserir programaticamente o conteúdo do Power BI. No entanto, nós não recomendamos a configuração de permissões delegadas para extrair dados de auditoria. Cada API limita a frequência com que ela pode ser executada (com limitação em vigor), portanto, não é prático ter usuários diferentes acessando diretamente os dados brutos de auditoria. Em vez disso, recomendamos que você extraia os dados brutos de auditoria uma vez (com um processo centralizado) e disponibilize os dados de auditoria coletados para downstream de usuários autorizados.

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

Segredos de registro de aplicativo

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 expiração. 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 organizacionais, como o Azure Key Vault, é uma excelente opção.

Dica

Como uma abordagem alternativa para o uso de um segredo, você pode usar uma identidade gerenciada. Uma identidade gerenciada elimina a necessidade de gerenciar credenciais. Se você pretende usar serviços como Azure Functions ou Azure Data Factory para extrair os dados, uma identidade gerenciada será uma boa opção para investigar.

Gerenciar credenciais com segurança

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

Cuidado

A primeira regra é aquela que muitas pessoas violam: senhas e chaves nunca devem aparecer em texto sem formatação em um script. Muitos artigos, blogs e exemplos online fazem isso para simplificar. No entanto, é uma prática ruim que deve ser evitada. Qualquer pessoa que obtenha o script (ou o arquivo) pode potencialmente obter acesso aos mesmos dados aos quais o autor tem acesso.

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

  • Integre-se ao Azure Key Vault ou a outro sistema de cofre de senhas organizacionais 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, você não pode usar uma credencial quando a autenticação multifator está habilitada para uma conta de usuário.
  • Solicite uma senha no script do PowerShell ou use a autenticação interativa com um navegador.
  • Use o módulo Gerenciamento de Segredos para o PowerShell publicado pela Microsoft. Ele pode armazenar valores usando um cofre local. Ele também pode se integrar a um Azure Key Vault remoto, o que é útil quando há vários administradores em sua organização que trabalham com os mesmos scripts.
  • Crie um conector personalizado para Power BI Desktop para que ele possa lidar com as credenciais com segurança. Alguns conectores personalizados estão disponíveis através de membros da comunidade (geralmente no GitHub).

Dica

Recomendamos que você consulte suas equipes de TI e segurança para ajudar a escolher o melhor método ou valide se sua solução gerencia as credenciais de maneira segura.

Biblioteca de Autenticação da Microsoft

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

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

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

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

  • Decidir qual tipo de autenticação usar: determine se a autenticação de usuário ou autenticação de entidade de serviço são mais adequadas, dependendo do tipo de solução de auditoria que você planeja criar.
  • Planejar quais registros de aplicativo são necessários: considere seus requisitos, cargas de trabalho e público-alvo (usuários de cada registro de aplicativo). Planeje quantos registros de aplicativo você precisa criar para dar suporte a essas necessidades.
  • Criar uma convenção de nomenclatura para registros de aplicativo: configure uma convenção de nomenclatura que facilite a compreensão da finalidade pretendida e dos usuários pretendidos de cada registro de aplicativo.
  • Planejar como gerenciar credenciais com segurança: considere maneiras de gerenciar senhas, segredos e chaves com segurança. Considere qual documentação e treinamento podem ser necessários.
  • Confirmar o uso da MSAL: determine se há alguma solução de auditoria manual ou automatizada existente que dependa da ADAL. Se necessário, crie um plano para regenerar essas soluções para usar a biblioteca de autenticação MSAL mais recente.

Escolher uma API de usuário ou API de administrador

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

Há dois tipos de APIs que devem ser considerados.

  • APIs de usuário: conte com as 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 workspace é com uma API de usuário. A permissão para ler conjuntos de dados pode ser concedida por função de workspace ou permissões por item. Há duas formas de executar APIs de usuário:
    • Autenticação de usuário: o usuário conectado deve ter permissão para acessar o workspace ou item.
    • Autenticação de entidade de serviço: a entidade de serviço deve ter permissão para acessar o workspace ou item.
  • APIs de administrador: recuperam metadados do locatário. Às vezes são chamadas de escopo organizacional. Por exemplo, para retornar uma lista de todos os modelos semânticos no locatário, use uma API de administrador. Há duas formas de executar APIs de administrador:
    • Autenticação de usuário: o usuário conectado deve ser um administrador do Power BI para executar APIs de administrador.
    • Autenticação de 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 a API de usuário).

Dica

Todas as APIs de administrador pertencem ao grupo de operações de administrador. Qualquer API que tenha o sufixo As Admin é uma API de administrador; todas as APIs restantes são APIs de usuário.

Considere um exemplo no qual você precisa obter uma lista de conjuntos de dados. 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 Escopo Número de modelos semânticos
Obter Conjunto de Dados Usuário Workspace pessoal Um
Obter conjuntos de dados Usuário Workspace pessoal Tudo
Obter conjunto de dados no grupo Usuário Um workspace Um, contanto que o usuário conectado tenha permissão para ler o modelo semântico
Obter conjuntos de dados no grupo Usuário Um workspace Todos, contanto que o usuário conectado tenha permissão para ler cada modelo semântico
Obter conjuntos de dados em grupo como administrador Admin Um workspace Tudo
Obter conjuntos de dados como administrador Admin Locatário inteiro Tudo

Observação

Alguns dos nomes de API incluem o termo Grupo como uma referência a um workspace. Esse termo se originou do modelo de segurança original do Power BI, que dependia de grupos do Microsoft 365. Embora o modelo de segurança do Power BI tenha evoluído significativamente ao longo dos anos, os nomes de API existentes permanecem inalterados para evitar a interrupção de soluções existentes.

Para obter informações sobre as 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 API de administrador, as principais decisões e ações incluem:

  • Consultar os requisitos de dados: colete e documente os principais requisitos de negócios para uma solução de auditoria. Com base no tipo de dados necessários, determine se um escopo de usuário ou escopo organizacional é apropriado.
  • Testar os resultados: faça alguma experimentação. Teste a precisão dos resultados retornados pelas diferentes APIs.
  • Examinar permissões: para quaisquer soluções de auditoria existentes, confirme se as permissões são atribuídas corretamente para administradores e entidades de serviço do Power BI. Para novas soluções de auditoria, confirme qual método de autenticação será usado.

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 será importante se você tiver decidido que o PowerShell é uma das tecnologias serão usadas para acessar dados de auditoria.

PowerShell é uma solução de automação de tarefas. O termo PowerShell é um termo coletivo que se refere à linguagem de script, a um aplicativo de shell de linha de comando e a uma estrutura de gerenciamento de configuração. O PowerShell Core é a versão mais recente do PowerShell, que é executada no 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. Baixe e instale 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. Esse cmdlet do PowerShell recupera seus dados da API REST Obter Eventos de Atividade. Geralmente, é mais simples começar usando os cmdlets porque isso 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 você 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 subjacentes do Power BI. O uso desses módulos do PowerShell pode facilitar a gravação de scripts.

Dica

Além dos módulos publicados pela Microsoft, há módulos e scripts do PowerShell disponíveis gratuitamente publicados (geralmente no GitHub) por membros da comunidade do Power BI, parceiros e MVPs (Profissionais Mais Valiosos da Microsoft).

Começar com uma solução de comunidade pode desempenhar um papel importante na criação de sua solução de auditoria de ponta a ponta. Se você optar por usar uma solução disponível gratuitamente, certifique-se de testá-la totalmente. Familiarize-se com o funcionamento dela para que você possa gerenciar sua solução com eficiência ao longo do tempo. Seu departamento de TI pode ter critérios para usar soluções de comunidade disponíveis publicamente.

Módulo Gerenciamento do Power BI

O módulo Gerenciamento do Power BI é um módulo cumulativo que contém módulos específicos do Power BI para administração, capacidades, workspaces 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 Gerenciamento do Power BI têm suporte no Windows PowerShell e no PowerShell Core.

Importante

Recomendamos que você descontinue o uso de Windows PowerShell (que não pode executar o PowerShell Core). Em vez disso, use um dos editores de código modernos que dão suporte ao PowerShell Core. O ISE (ambiente de script integrado) do Windows PowerShell só é capaz de executar o PowerShell versão 5.1, que não é mais atualizado. Agora o Windows PowerShell está preterido, portanto, recomendamos que você use o PowerShell Core para todo o novo trabalho de desenvolvimento.

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

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

Dica

Há outros cmdlets disponíveis para gerenciar e publicar conteúdo. No entanto, o foco deste artigo é recuperar dados de auditoria.

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

Recomendamos que você instale o módulo cumulativo Gerenciamento do Power BI. Dessa forma, todos os cmdlets necessários estão disponíveis. No mínimo, você precisa do módulo Perfil (para autenticação) e de todos os módulos específicos que contenham os cmdlets que você deseja usar.

Cuidado

Certifique-se de manter os módulos atualizados em cada servidor, computador de usuário e serviço de nuvem (como Automação do Azure) em que você usa o PowerShell. Se os módulos não forem atualizados regularmente, erros ou problemas imprevisíveis poderão surgir. Algumas ferramentas (como Visual Studio Code) ajudam você a manter os módulos atualizados. Além disso, lembre-se de que o PowerShellGet não desinstala automaticamente versões mais antigas de um módulo quando você instala ou atualiza uma versão mais recente. Ele instala versões mais recentes junto com as versões mais antigas. Recomendamos que você verifique as versões instaladas e desinstale periodicamente versões mais antigas.

Módulo 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 tem suporte apenas no PowerShell Core. Não há suporte para Windows PowerShell.

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

Aviso

Não é possível atribuir uma entidade de serviço como administrador de gateway (mesmo quando a entidade de serviço é membro de um grupo de segurança). Portanto, planeje usar credenciais de usuário ao recuperar informações sobre gateways de dados.

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

Cmdlet Finalidade
Connect-DataGatewayServiceAccount Autentique um usuário do Power BI (geralmente exige 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ê tomar é 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 essa técnica, há um equilíbrio de simplicidade e flexibilidade. O cmdlet Invoke-PowerBIRestMethod está disponível no módulo Perfil de gerenciamento do Power BI. Geralmente esse cmdlet é 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 chamar qualquer uma das APIs REST do Power BI. É altamente recomendável usar essa técnica. Depois de se autenticar com o cmdlet Connect-PowerBIServiceAccount, use o cmdlet Invoke-PowerBIRestMethod para recuperar dados de sua API preferida (por exemplo, Obter usuários de pipeline como administrador).
Use cmdlets do PowerShell o máximo possível, tanto para autenticação quanto para recuperar 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 no PowerShell de vários aspectos. Depois de se 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 no PowerShell como uma ferramenta, pois seu uso principal é orquestrar a invocação de chamadas à API. Apenas um módulo genérico do PowerShell é usado para acessar APIs (nenhum dos módulos dentre os módulos Gerenciamento do Power BI é usado). Depois de se autenticar usando a MSAL (Biblioteca de Autenticação da Microsoft), chame sua API preferida (por exemplo, Obter usuários de pipeline como administrador) usando o cmdlet Invoke-RestMethod genérico para recuperar dados.

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

Dica

Você pode usar o cmdlet Invoke-ASCmd do PowerShell para criar e executar scripts DAX, XMLA e TMSL . No entanto, esses casos de uso estão fora do escopo deste artigo. Para obter mais informações sobre como consultar DMVs (Exibições de Gerenciamento Dinâmico), consulte Auditoria em nível de dados.

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

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

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

A tabela a seguir descreve como os parâmetros usados no cmdlet do PowerShell são traduzidos para as chamadas do PowerShell à API.

Parâmetros de cmdlets API que o cmdlet usa Tipo de API Escopo Itens recuperados
-DatasetID {DatasetID}
-Scope Individual		 Obter Conjunto de Dados Usuário Workspace pessoal Um modelo semântico
-Scope Individual Obter conjuntos de dados Usuário Workspace pessoal Todos os modelos semânticos
-DatasetID {DatasetID}
-GroupID {WorkspaceID}		 Obter conjunto de dados no grupo Usuário Um workspace 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 Usuário Um workspace Todos os modelos semânticos, desde que o usuário conectado tenha permissão para acessar o workspace e ler o modelo semântico
-GroupID {WorkspaceID}
-Scope Organization		 Obter conjuntos de dados em grupo como administrador Admin Um workspace Todos os modelos semânticos
-Scope Organization Obter conjuntos de dados como administrador Admin Locatário 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 à 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 cmdlet Connect-PowerBIServiceAccount.
  • 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, ao chamar diretamente a API REST Obter Eventos de Atividade, você recupera uma hora de dados de auditoria. Portanto, ao usar 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 com eficiência por 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 como usar um token de continuação, confira API REST de Eventos de Atividade.
  • Expirações de 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 por você. Dessa forma, você não precisa gravar 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 amigável. Para processos de auditoria automatizados, isso provavelmente não será um problema. No entanto, para processos manuais de auditoria, a formatação mais agradável pode ser útil.
Considerações sobre o uso de APIs REST diretamente

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

  • Muitas outras APIs disponíveis: há mais APIs REST disponíveis do que cmdlets do PowerShell. No entanto, não ignore a flexibilidade do cmdlet Invoke-PowerBIRestMethod, que você pode usar para chamar qualquer uma das APIs REST do Power BI.
  • Frequência de 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 Obter Conjunto de Dados, poderá levar algum tempo até que ele fique disponível nos resultados do cmdlet Get-PowerBIDataset .
  • Menos dependência de linguagem/ferramenta: ao usar as APIs REST diretamente (em vez de um cmdlet), você não precisa usar o PowerShell. Ou você pode optar por usar o PowerShell apenas para orquestrar a chamada de várias APIs em um script. Removendo (ou evitando) qualquer dependência do PowerShell, em algum momento no futuro você pode regenerar sua lógica em uma linguagem diferente. Quando sua equipe de TI ou de desenvolvedores tem grandes preferências por ferramentas e linguagens, menos dependência pode ser uma consideração importante a ser feita.

Independentemente do método que você optar por usar, as APIs REST podem ser alteradas ao longo do tempo. Quando uma tecnologia evolui, as APIs (e os módulos do PowerShell) podem ser preteridas e substituídas. Portanto, recomendamos que você crie scripts que sejam simples de manter e resilientes a alterações.

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:

  • Consultar a TI sobre o uso do PowerShell: entre em contato com as equipes de TI relevantes para determinar se há requisitos internos ou preferências existentes sobre como o PowerShell pode ser usado.
  • Decidir como você deseja usar o PowerShell: determine quais técnicas do PowerShell usar e se você deseja aumentar ou reduzir intencionalmente sua dependência no PowerShell. Considere se a comunicação interna ou o treinamento é necessário.
  • Atualizar para o PowerShell Core: pesquise usando o PowerShell Core. Determine se os computadores administradores precisam ser atualizados. Considere quais scripts existentes precisam ser testados. Determine se os administradores ou desenvolvedores precisam de treinamento adicional para atualizar suas habilidades.
  • Determinar quais módulos do PowerShell usar: considere se os módulos Gerenciamento do Power BI e/ou Gateway de dados serão usados.
  • Decidir se os projetos da comunidade são permitidos: determine se você tem permissão (ou é incentivado) para usar módulos do PowerShell disponíveis online (versus módulos publicados pela Microsoft). Consulte a TI para determinar se há critérios para projetos de comunidade obtidos online.
  • Esclareça como dar suporte a projetos da comunidade: se os projetos da comunidade do PowerShell forem permitidos, considere quem será responsável por dar suporte a eles quando usados internamente.
  • Concluir uma pequena prova de conceito (POC): experimente uma POC técnica. Confirme suas ferramentas preferenciais de cliente e o método de acesso aos dados.
  • Determinar como dar suporte a usuários avançados: considere como você oferecerá suporte a usuários técnicos que criam automação por conta própria usando as APIs do usuário.

Determinar onde armazenar dados de auditoria

Quando planeja criar uma solução de auditoria de ponta a ponta, você precisa decidir onde armazenar os dados brutos (e os dados coletados, que são abordados na próxima seção). Suas decisões sobre o armazenamento de dados estão relacionadas às suas preferências de 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 inicialmente os dados. Em vez disso, extraia todos os atributos disponíveis e armazene os dados em seu estado original.

Aqui estão vários motivos pelos quais o armazenamento dos 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 todos os dados disponíveis no momento em que os extraiu. Mesmo quando você leva tempo — 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 à alteração: se o formato de dados brutos for alterado, o processo que extrai os dados não será afetado. Como alguns dados de auditoria diferenciam o tempo, é importante você ter certeza de projetar um processo de extração de dados que não falhará quando ocorrer uma alteração na origem.
  • Funções e responsabilidades: diferentes membros da equipe (como engenheiros de dados ou administradores globais) podem ser responsáveis por criar os processos para acessar, extrair e armazenar os dados brutos de auditoria. Simplificar o processo de extração de dados facilita o trabalho em conjunto de várias equipes.

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

  • Data lake ou armazenamento de objetos: um serviço de nuvem como o OneLake especializado em armazenar arquivos de qualquer estrutura. É uma opção ideal para armazenar os dados brutos de auditoria. Em uma estrutura de data lake, os dados brutos devem ser armazenados na camada bronze.
  • Sistema de arquivos: um sistema de arquivos (como Windows ou Linux) é uma opção comum para armazenar os dados brutos de auditoria.
  • Banco de dados:é possível armazenar dados JSON em um banco de dados relacional, como Banco de Dados SQL do Azure. No entanto, é menos comum do que armazenar os dados em um data lake ou sistema de arquivos. Isso ocorre porque a consulta e a manutenção de dados JSON podem se tornar desafiadoras e caras, especialmente à medida que os volumes de dados aumentam.

Dica

Ao usar um data lake, armazenamento de objetos ou sistema de arquivos, recomendamos que você armazene os dados de uma maneira fácil de organizar e proteger. Também é importante esclarecer se os dados abrangem eventos (que normalmente são acrescentados) ou se eles são um instantâneo pontual (que requer a seleção de uma data para analisar).

Considere um exemplo que envolve uma zona de dados brutos de um data lake. A zona tem uma hierarquia de pastas para armazenar dados de log de atividades: Raw > ActivityLog > YYYYY > 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. YYYYMMDD representa os dados reais e YYYYYMMDDTTTT 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) em 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 no armazenamento imutável. O armazenamento imutável garante que, depois que os dados forem gravados, eles não poderão ser substituídos ou excluídos. Essa distinção é importante para os auditores e permite que você acredite que os dados brutos são confiáveis.

Você também precisa considerar como armazenar com segurança os dados brutos. Normalmente, pouquíssimos usuários exigem acesso aos dados brutos. O acesso a dados brutos normalmente é fornecido de acordo com as necessidades, normalmente para engenheiros de dados e administradores do sistema. Seus auditores internos também podem precisar de acesso. Os membros da equipe responsáveis por criar os dados coletados (descritos a seguir) também exigem 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 rigorosos de como e onde os dados são armazenados.
  • A área de assunto é particularmente confidencial? Dependendo do tipo de dados e da confidencialidade, sua organização pode ter um requisito de como e onde eles são armazenados. Os dados de auditoria do Power BI contêm a identificação de informações do usuário e endereços IP, portanto, devem ser armazenados em uma área segura.
  • Há uma tecnologia de armazenamento preferencial? Pode haver uma tecnologia de armazenamento existente que está em uso dentro da 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, pouquíssimos usuários recebem acesso a dados brutos. O acesso aos dados coletados normalmente é disponibilizado para criadores de conteúdo do Power BI responsáveis por criar o modelo de dados centralizado (o modelo semântico que serve como camada semântica para relatórios).
  • Você tem requisitos de residência de dados? Algumas organizações têm requisitos de residência de dados legais ou regulatórios para armazenar dados em uma região de dados específica.
  • Como os dados serão organizados? O uso da arquitetura medalhão é uma prática comum, especialmente em implementações de data lake e lakehouse. A meta é armazenar seus dados em camadas de dados bronze, silver e gold. A camada bronze contém os dados brutos originais. A camada silver contém dados validados e com eliminação de duplicação usados para transformações. A camada gold contém os dados coletados 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:

  • Consultar a TI: entre em contato com as equipes de TI relevantes para determinar se há processos existentes em execução para extrair os dados brutos de auditoria. Nesse caso, descubra se você pode acessar os dados existentes. Se um novo processo de extração de dados for necessário, determine se há preferências ou requisitos quanto ao local onde os dados devem ser armazenados.
  • Decidir onde armazenar dados brutos: determine a melhor localização e estrutura de armazenamento para armazenar os dados brutos.
  • Determinar os requisitos de residência de dados: descubra se há requisitos legais ou regulatórios quanto ao local onde os dados podem ser armazenados.
  • Criar uma estrutura de pastas e uma convenção de nomenclatura: determine qual convenção de nomenclatura usar para arquivos de dados brutos, incluindo a estrutura de pastas. Inclua esses detalhes em sua documentação técnica.
  • Considerar como a segurança dos dados brutos funcionará: ao projetar o local de armazenamento de dados brutos, considere quem precisará acessar os dados e como o acesso será concedido.

Planejar a criação de dados coletados

Os dados coletados dão suporte à análise e foram projetados para serem amigáveis. Você precisa tomar algumas decisões sobre como e onde os dados coletados serão criados. A tecnologia escolhida para armazenar os dados coletados pode ser qualquer uma das tecnologias listadas na seção anterior.

O objetivo dos dados coletados é transformar os dados em um formato mais amigável otimizado para análise e relatórios. Ele forma a fonte de dados de um modelo de dados do Power BI, o que significa que você usa um modelo de dados do Power BI para analisar o uso do Power BI em sua organização. Diretrizes fundamentais do modelo de dados se aplicam: você deve adotar um design de esquema em estrela, que é otimizado para desempenho e usabilidade.

Você pode escolher criar dados coletados de diferentes maneiras. Você precisa decidir como fazer a integração de dados e até que ponto fazer upstream para aplicar as transformações que preparam os dados para carregamento em um esquema em estrela.

Data Lake

Você pode aplicar transformações e criar arquivos de dados coletados em um data lake. Você deve usar uma camada gold para dados coletados, 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 coletar os dados quando:

  • Você espera que haja vários modelos de dados Power BI que atendam a relatórios (o que justifica a criação de uma camada intermediária silver).
  • Você precisa dar suporte a vários criadores de conteúdo de autoatendimento que precisam de acesso aos dados de auditoria em nível de 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

Você pode concluir todo o trabalho de transformação no Power BI. Use o Power Query para acessar e transformar os dados de seu estado bruto para o formato coletado.

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 as durações da atualização.)
  • Sua preferência é fazer todo o trabalho de transformação ao carregar o modelo de dados.
  • Você espera ter um modelo de dados centralizado para os dados de auditoria em nível de locatário. Todos os relatórios (ou outros modelos de dados) podem usar o modelo semântico centralizado do Power BI como sua fonte.
  • Você deseja fornecer acesso de usuário somente ao modelo semântico centralizado do Power BI (e não a qualquer um dos dados da fonte).

Dica

Ao criar os dados coletados, configure-os de uma maneira para que você possa executar facilmente o processo para intervalos de datas anteriores. Por exemplo, se você descobrir que um novo atributo apareceu nos logs de auditoria de três meses atrás, convém analisá-lo desde que ele apareceu pela primeira vez. A capacidade de recarregar o histórico de dados coletados é uma das várias razões pelas quais é importante armazenar os dados brutos em seu estado original (descrito anteriormente neste artigo).

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 as permissões da fonte de dados, estas são algumas ações e decisões importantes:

  • Decidir onde as transformações devem ser feitas: considere até que ponto o upstream do trabalho de transformação deve ser feito e onde isso se encaixa em seu plano para toda a arquitetura.
  • Decida qual ferramenta usar para transformar os dados em um esquema em estrela: confirme quais ferramentas e serviços serão usados para transformar os dados brutos em dados coletados.
  • Decidir onde os dados coletados devem ser armazenados: determine a melhor opção para armazenar os dados brutos que foram transformados em um formato de esquema em estrela. Decida se uma camada intermediária silver é útil na arquitetura de ponta a ponta.
  • Criar uma convenção de nomenclatura: determine qual convenção de nomenclatura usar para arquivos e pastas de dados coletados (se aplicável). Inclua os detalhes em sua documentação técnica.
  • Considere como a segurança dos dados coletados funcionará: ao projetar o local de armazenamento de dados coletados, considere quem precisará acessar os dados e como a segurança será atribuída.

Decisões de fonte de dados

Neste ponto, você deve ser claro sobre requisitos, necessidades de dados e permissões. Decisões técnicas importantes foram tomadas. Agora você precisa tomar algumas decisões sobre a abordagem de como obterá determinados 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 quantidade 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 ao log de auditoria unificada do Microsoft Purview (anteriormente conhecido como log de auditoria unificada 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 registrar em log. Ele é habilitado por padrão.

Importante

Se você ainda não estiver extraindo e armazenando dados de atividade do usuário, torne isso uma prioridade urgente. Os dados de atividade do usuário estão disponíveis para os 30 ou 90 dias mais recentes (dependendo da fonte). Mesmo quando você não estiver pronto para fazer análises detalhadas, é importante começar a extrair e armazenar os dados o mais rápido possível. Dessa forma, o histórico valioso estará disponível para análise.

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

Técnica Descrição Dias padrão de histórico disponível Boa opção para processos manuais de auditoria Boa opção para processos automatizados de auditoria Boa opção para configurar alertas Boa opção para começar rapidamente
Manual (interface do usuário) Portal de conformidade do Microsoft Purview 90 O Portal de conformidade do Microsoft Purview é uma boa opção para processos manuais de auditoria. O Portal de conformidade do Microsoft Purview é uma boa opção para começar rapidamente.
Manual (interface do usuário) Defender for Cloud Apps 30 Os Aplicativos Defender para Nuvem são uma boa opção para processos manuais de auditoria. Aplicativos Defender para Nuvem são uma boa opção para configurar alertas.
Programático Log de atividades do Power BI (API ou cmdlet do PowerShell) 30 Log de atividades do Power BI (API ou cmdlet do PowerShell) é uma boa opção para processos automatizados de auditoria. Log de atividades do Power BI (API ou cmdlet do PowerShell) é uma boa opção para começar rapidamente.
Programático API de Atividade de Gerenciamento de Office 365 7 API de Atividade de Gerenciamento de Office 365 é uma boa opção para processos automatizados de auditoria.
Programático Microsoft Sentinel (Azure Monitor) 30 O Microsoft Sentinel (Azure Monitor) é uma boa opção para processos automatizados de auditoria. Microsoft Sentinel (Azure Monitor) é uma boa opção para configurar alertas.

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 Centro de conformidade do Microsoft 365) é um local conveniente para exibir atividades e alertas. Essa ferramenta não exige 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 solicita que você descubra quem excluiu um workspace mais cedo naquele dia para que ele possa contatar rapidamente a pessoa para discutir a situação.

Os 90 dias mais recentes do histórico estão disponíveis com Auditoria (Standard). Com a Auditoria (Premium), a retenção de longo prazo permite que você (opcionalmente) mantenha logs de auditoria por mais tempo. Como a retenção de longo prazo só se aplica a usuários licenciados do E5, ela exclui registros de auditoria para usuários não E5 e usuários convidados. Portanto, recomendamos que você dependa apenas do 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. As permissões elevadas do Exchange Online também são necessárias para acessar os logs de auditoria.

Dica

Por padrão, os administradores do Power BI não têm permissão para acessar a pesquisa de log de auditoria unificada no Portal de conformidade do Microsoft Purview. Como contém dados para muitos serviços do Microsoft 365, ela é uma função de alto privilégio. Na maioria das organizações, essas permissões são reservadas para um pequeno número de administradores de TI. Há outras opções disponíveis para administradores do Power BI, que são descritas posteriormente nesta seção.

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

Defender for Cloud Apps

O portal em Aplicativos Defender para Nuvem é um local conveniente para exibir 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 e das entradas de usuário do Power BI.

Os Aplicativos Defender para Nuvem incluem uma interface do usuário para exibir e pesquisar logs de atividades para vários serviços de nuvem, incluindo o Power BI. Ele exibe os mesmos eventos de log originados no log de auditoria unificada do Microsoft Purview e inclui outros eventos, como a atividade de entrada do usuário do Microsoft Entra ID.

Assim como o Portal de conformidade do Microsoft Purview (descrito na seção anterior), o Defender for Cloud Apps tem uma interface do 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 os Aplicativos Defender para Nuvem para exibir até seis meses de histórico de log de atividades (em incrementos de sete dias).

Há requisitos de licenciamento para acessar os Aplicativos Defender para Nuvem. Permissões separadas também são necessárias.

Dica

Por padrão, os administradores do Power BI não têm permissão para acessar Aplicativos Defender para Nuvem. Há uma função do Power BI nos Aplicativos Defender para Nuvem. Adicionar administradores do Power BI a essa função é uma boa maneira de conceder a eles acesso a um conjunto limitado de dados.

A interface do usuário nos Aplicativos Defender para Nuvem é útil para processos manuais de auditoria e investigações pontuais de atividades do usuário.

Log de atividades Power BI

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

Dica

Para organizações que estão planejando extrair atividades do usuário, recomendamos que elas comecem com o log de atividades do Power BI. É a fonte mais simples para acessar programaticamente.

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

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

Dica

Para obter exemplos de como acessar o log de atividades do Power BI com o PowerShell, consulte Acessar o log de atividades do Power BI.

Os dados do log de atividades do Power BI estão disponíveis para todos os administradores do Power BI, administradores do Power Platform e administradores globais. Os dados podem ser acessados no log de auditoria unificada, disponível para determinadas funções do Exchange Online. Para obter mais informações, confira Acompanhar as atividades do usuário no Power BI.

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

Observação

Nos dados do log de auditoria, os workspaces são chamados de pastas. Na API REST do Power BI, os workspaces são chamados de grupos.

API de Atividade de Gerenciamento de Office 365

Você pode extrair dados do log de auditoria unificada para outros serviços, como SharePoint Online, Teams, Exchange Online, Dynamics 365 e Power BI. Quando sua meta é implementar uma solução de auditoria e monitoramento para vários serviços, recomendamos o uso da API de Atividade de Gerenciamento de Office 365. Como essa API retorna dados de muitos serviços, ela é conhecida como a API de Auditoria Unificada (ou log de auditoria unificada). Ela é 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ê precise ter permissão para acessar esses dados em vez de criar uma nova solução.

Você pode acessar os dados de duas maneiras.

Importante

O cmdlet Search-UnifiedAuditLog não é bem dimensionado e exige que você implemente uma estratégia de looping para superar seu limite de 5.000 linhas. Por esses motivos, ele é adequado para consultas ocasionais ou para pequenas organizações que experimentam baixa atividade. Quando você precisar apenas de dados do Power BI, recomendamos o uso do cmdlet Get-PowerBIActivityEvent .

Em geral, começar a usar a API de Atividade de Gerenciamento de 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 de vizinho barulhento). Portanto, recuperar grandes volumes de histórico pode ser um desafio em organizações maiores. Para obter mais informações, confira o artigo de solução de problemas.

Para usar essa API, você deve se autenticar com uma entidade de serviço que recebeu permissão para recuperar dados da API de Atividade de Gerenciamento de Office 365.

Dica

Por padrão, os administradores do Power BI não têm permissão para acessar a API de Atividade de Gerenciamento de Office 365. Como ela contém dados para muitos serviços do Microsoft 365, o acesso requer as funções de administrador de alto privilégio ou de auditoria. Na maioria das organizações, essas funções são reservadas para um pequeno número de administradores de TI. O log de atividades do Power BI destina-se ao uso por administradores do Power BI.

Recuperar os dados de auditoria programaticamente da API de Atividade de Gerenciamento de 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 permite coletar, detectar, 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 é uma funcionalidade do Azure Monitor.

Dica

O Azure Log Analytics baseia-se na mesma arquitetura usada pelos logs de eventos do modelo semântico no nível do workspace. Para obter mais informações sobre logs de eventos do modelo semântico, consulte Auditoria em nível de dados.

Como esse é um serviço separado do Azure, qualquer administrador ou usuário que você quer que execute consultas KQL (Linguagem de Consulta Kusto) deve receber permissões no Azure Log Analytics (Azure Monitor). Quando têm permissão, eles podem consultar os dados de auditoria armazenados na tabela PowerBIActivity. No entanto, tenha em mente que, na maioria dos casos, você concederá aos usuários acesso aos dados coletados na camada gold em vez dos dados brutos na camada bronze.

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

Há várias maneiras de acessar os eventos armazenados no Azure Log Analytics. Você pode usar:

  • O aplicativo de modelo do Log Analytics para Modelos Semânticos do Power BI predefinido.
  • O conector do Power BI Desktop para Azure Data Explorer (Kusto).
  • A experiência de consulta baseada na Web no Azure Data Explorer.
  • Qualquer ferramenta de consulta que possa executar consultas KQL.

Cuidado

Lembre-se de que apenas um subconjunto dos dados do log de atividades do Power BI é armazenado no Azure Monitor. Quando você planejar fazer uma análise abrangente do uso e da adoção do Power BI na organização, recomendamos que você use outras opções (descritas anteriormente nesta seção) para recuperar dados de atividade.

O período de histórico que você pode recuperar depende da política de retenção de dados para o workspace do Log Analytics do Azure. Considere o custo e acesso a dados brutos ao decidir quantos dados 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 detalhes capturado atende às suas necessidades e atividades como detecçã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 dá suporte à execução de uma análise abrangente do uso e da 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 dados de atividade do usuário.

  • Ele será um processo de auditoria manual ou automatizado? As opções de interface do usuário funcionam bem para processos de auditoria manuais 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 agendamento 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 sejam pelo menos de um dia antes da data atual usando o UTC (Tempo Universal Coordenado) em vez de a hora local. Por exemplo, se o processo for executado na manhã de sexta-feira (horário UTC), você deverá extrair dados de quarta-feira. Há vários motivos pelos 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 por vez, o que evita resultados parciais do dia.
    • Você minimizará o risco de perder alguns eventos de auditoria. Normalmente, os eventos de auditoria chegam dentro de 30 minutos. Ocasionalmente, alguns eventos podem levar até 24 horas para chegar ao log de auditoria unificada.
  • Você precisa de mais do que dados do Power BI? Considere a maneira mais eficiente de acessar o que você precisa.
  • Quem desenvolverá a solução? Planeje investir algum tempo para criar 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 dados de atividade do usuário, as principais ações e decisões incluem:

  • Esclarecer o escopo das necessidades: determine se você precisa acessar apenas registros de auditoria do Power BI ou auditar dados para vários serviços.
  • Consultar a TI: descubra se a TI extrai atualmente os logs de auditoria e se é possível obter acesso aos dados brutos para que você não precise criar uma nova solução.
  • Decidir sobre uma fonte de dados: determine a melhor fonte a ser usada para acessar dados de atividade do usuário.
  • Concluir uma prova de conceito: planeje concluir uma pequena prova de conceito (POC) técnica. Use-a para validar suas decisões sobre como a solução final será criada.
  • Acompanhar as necessidades de dados adicionais: você pode correlacionar dados do log de atividades com outras fontes para aprimorar o valor dos dados. Acompanhe essas oportunidades à medida que elas surgirem para que elas possam ser adicionadas ao escopo do seu projeto.

Acessar dados de inventário de locatário

Um inventário de locatários é uma parte inestimável e necessária de uma solução madura de auditoria e monitoramento. Ele ajuda você a entender quais workspaces 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ário 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 de locatários é diferente. Um inventário de locatários é 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ê os extraiu.

Observação

A documentação da API REST do Power BI refere-se a itens publicados como artefatos.

Dica

Muitas organizações acham útil extrair o inventário de locatários no mesmo horário do dia toda semana.

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 de locatários. Combiná-los permite que você entenda quanto conteúdo você tem e onde ele está localizado. Isso também permite que você encontre conteúdo não utilizado ou subutilizado (porque não haverá eventos para ele no log de atividades). O inventário de locatários também ajuda você 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 a importância do inventário de locatários, confira a seção anterior Inventário de locatários neste artigo.

Dica

Você pode usar a API Obter Artefatos Não Utilizados como Administrador para pesquisar itens que não têm nenhuma atividade de usuário nos últimos 30 dias. No entanto, você não pode personalizar esse período de tempo. Por exemplo, você pode ter conteúdo crítico usado apenas trimestralmente. Combinando o inventário de locatários com os dados de atividade do usuário, você pode encontrar itens não utilizados de maneiras que você pode personalizar.

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

Técnica Descrição Mais adequado para Boa opção para processos manuais de auditoria Boa opção para processos automatizados de auditoria
Programático A API Get Groups as Admin ou o cmdlet Get-PowerBIWorkspace do PowerShell podem fornecer uma lista de workspaces para todo o locatário. Opcionalmente, itens individuais (como modelos semânticos e relatórios) por workspace podem ser incluídos. Organizações menores ou baixo volume de dados A API Obter Grupos como Administrador ou o cmdlet Get-PowerBIWorkspace do PowerShell é uma boa opção para processos manuais de auditoria. A API Obter Grupos como Administrador ou o cmdlet Get-PowerBIWorkspace do PowerShell é uma boa opção para processos automatizados de auditoria.
Programático Um conjunto de APIs de administrador assíncronas, coletivamente conhecidas como APIs de verificação de metadados ou APIs de scanner, pode retornar uma lista de workspaces 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 As APIs de verificação de metadados são uma boa opção para processos automatizados de auditoria.

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

APIs de Grupos ou cmdlet de workspaces

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

Observação

Alguns dos nomes de API incluem o termo grupo como uma referência a um workspace. Esse termo se originou do modelo de segurança original do Power BI, que dependia de grupos do Microsoft 365. Embora o modelo de segurança do Power BI tenha evoluído significativamente ao longo dos anos, os nomes de API existentes permanecem inalterados para evitar a interrupção de soluções existentes.

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

Também é possível usar o cmdlet Get-PowerBIWorkspace do PowerShell. Ele é do módulo Workspaces de gerenciamento do Power BI. Quando você define o parâmetro -Scope como organization, ele funciona como a API Get Groups as Admin. O cmdlet também aceita o parâmetro -Include (que é equivalente ao parâmetro $expand na API REST) para incluir itens publicados no workspace (como modelos semânticos e relatórios).

Dica

Ao passar parâmetros, você pode usar o cmdlet de maneiras diferentes. Esta seção se concentra na recuperação de um inventário em todo o locatário. Para obter mais informações sobre como usar o parâmetro -Scope, consulte Escolher uma API de usuário ou API de administrador anteriormente neste artigo.

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

A API REST Get Groups as Admin ou o cmdlet Get-PowerBIWorkspace do 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 desafiadoras de usar. A API REST e o cmdlet sempre extraem um conjunto completo de dados para que possam levar mais tempo para serem executados. Portanto, também é provável que organizações maiores tenham limitações no número de solicitações permitidas por hora (conhecidas como limitação, o que é feito para proteger a integridade do serviço). As APIs de verificação de metadados (descritas a seguir) fornecem uma alternativa mais confiável e escalonável.

APIs de verificação de metadados

As APIs de verificação de metadados, normalmente chamadas de APIs de scanner, são um conjunto de APIs que retornam uma lista de workspaces e seus itens do Power BI (conjuntos de dados, relatórios e outros itens). Conceitualmente, elas fornecem os mesmos dados (e muito mais) que as APIs de Grupos ou o cmdlet do workspace, 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 de locatários.

Observação

Observe como algumas pessoas usam o termo APIs de scanner ou a frase verificação de locatário. Geralmente elas usam esses termos para dizer compilação de um inventário de locatários, distinguindo isso dos eventos de atividade do usuário. Elas podem, ou não, estar literalmente se referindo ao uso das APIs de verificação de metadados.

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

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

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

Esta é a sequência de etapas que seu processo deve seguir ao usar as APIs de 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 do workspace: envie uma solicitação para recuperar uma lista de IDs do workspace. Na primeira vez que ela for executada, você não terá uma data modificada, portanto, ela retornará uma lista completa de workspaces. Normalmente, você passará a data modificada para recuperar apenas workspaces que foram alterados desde esse momento. A data modificada deve estar dentro dos últimos 30 dias.
  3. Iniciar uma verificação de metadados: inicie uma chamada para solicitar uma verificação das informações do workspace passando as IDs do workspace recuperadas na Etapa 2. Observe que essa é 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. Essa consulta especifica o nível de detalhes que serão extraídos, 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. Ela também retorna a data e a hora da verificação, que você deve registrar como a data do instantâneo.
  4. Verificar o status da verificação: use a ID de verificação obtida na Etapa 3 para obter o status da verificação. Talvez seja necessário chamar essa API mais de uma vez. Quando o status retornado for Bem-sucedido, você poderá prosseguir para a próxima etapa. O tempo necessário para verificação depende da quantidade de dados que você solicita.
  5. Obter os resultados: use a ID de verificação obtida na Etapa 3 para obter o resultado da verificação e extrair os dados. Você deve executar essa etapa dentro de 24 horas após concluir a Etapa 4. Tenha em mente que o carimbo de data/hora do instantâneo deve ser correlacionado com a Etapa 3 em vez de com a Etapa 5 (quando houver um atraso significativo). Dessa forma, você terá um carimbo de data/hora de instantâneo preciso. Salve os resultados em seu local de armazenamento de dados preferido. Conforme já 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 da Etapa 3 para que você possa usá-lo na Etapa 2 da próxima vez que executar o processo. Dessa forma, você extrairá apenas os dados que foram alterados desde esse momento. Seguindo em frente, 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 de locatários, as principais decisões e ações incluem:

  • Confirmar requisitos: esclareça as necessidades para compilar um inventário de locatários e os requisitos analíticos para os dados.
  • Decidir a frequência para extrair o inventário de locatários: confirme com que frequência você precisará de um novo inventário de locatários (por exemplo, toda semana).
  • Decidir como extrair o inventário de locatários: confirme qual método você usará para obter os dados de inventário de locatário (APIs de verificação de API, cmdlet ou metadados).
  • Concluir uma prova de conceito: planeje concluir uma pequena prova de conceito (POC) técnica. Use-a para validar suas decisões sobre como a solução final será criada.

Acessar dados de usuário e grupo

Além das informações de identificação (como um endereço de email) incluídas nos dados de atividade do usuário, é importante 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 é composto por 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 corporativa ou de estudante ou conta Microsoft. O termo usuário de domínio geralmente é usado para descrever usuários organizacionais, enquanto o termo formal é UPN (nome principal de usuário). Um UPN geralmente tem o mesmo valor que o endereço de email do usuário (no entanto, se um endereço de email for alterado, o UPN não será alterado porque ele é imutável). Há também uma ID exclusiva do Microsoft Graph para cada usuário. Geralmente, uma conta de usuário é 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.

Observação

Quando este artigo se refere a usuários e grupos, esse termo também inclui entidades de serviço. Esse termo mais curto é usado para fins de brevidade.

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

Dica

Para obter mais informações sobre usuários, entidades de serviço e grupos, confira Integração com o Microsoft Entra ID.

Atributos analíticos

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

  • Nome completo de usuários: muitas fontes de dados incluem apenas o endereço de email do usuário que realizou uma atividade ou que foi atribuído a uma função. Use esse atributo quando quiser exibir o nome completo (nome de exibição) em relatórios analíticos. Usar o nome completo torna os relatórios mais amigáveis.
  • 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 workspace). Recuperar a associação de grupo melhora sua capacidade de analisar totalmente o que um usuário individual está fazendo ou a que ele tem acesso.
  • Licenças de usuário: é útil analisar quais licenças de usuário — gratuitas, Power BI Pro ou PPU (Power BI Premium por usuário) — são atribuídas aos usuários. Esses dados podem ajudá-lo a identificar quem não está usando as licenças deles. Eles também ajudam você a analisar todos os usuários (usuários distintos com uma licença) versus usuários ativos (com atividades recentes). Se você estiver considerando adicionar ou expandir suas licenças de Power BI Premium, recomendamos que você analise os dados de licença do usuário junto com os dados de atividade do usuário para executar uma análise de custo.
  • Membros das funções de administrador: você pode compilar uma lista dos administradores do Power BI (que inclui administradores do Power Platform e administradores globais).

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

Dica

A recuperação de membros de grupos pode ser um dos aspectos mais desafiadores da obtenção de dados de auditoria. Você precisará fazer uma pesquisa transitiva para nivelar todos os membros aninhados e grupos aninhados. Você pode fazer uma pesquisa transitiva por membros do grupo. Esse tipo de pesquisa é especialmente desafiador quando há milhares de grupos em sua organização. Nesse caso, pode haver alternativas melhores para recuperar os dados. Uma opção é extrair todos os grupos e membros do grupo do Microsoft Graph. No entanto, isso pode não ser prático quando apenas um pequeno número de grupos é usado para segurança do Power BI. Outra opção é criar previamente uma lista de referência de grupos que são usados por qualquer tipo de segurança do Power BI (funções de workspace, permissões de aplicativo, compartilhamento por item, segurança em nível de linha e outros). Então você pode executar um loop na lista de referência para recuperar membros do grupo do Microsoft Graph.

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

  • Tipo de usuário: os usuários são membros ou convidados. Normalmente, 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 alterou as funções na organização (por exemplo, quando ele é transferido para um departamento diferente). Dessa forma, você pode verificar se as configurações de segurança do Power BI foram ou devem ser atualizadas.
  • Usuários desabilitados: quando um usuário sai da organização, geralmente um administrador desabilita a conta dele. Você pode criar um processo para verificar se os usuários desabilitados são administradores de workspace ou proprietários de conjuntos de dados.

Dica

O log de atividades do Power BI inclui um evento que registra quando um usuário se inscreve para uma licença de avaliação. Você pode combinar esse evento com os dados de licença do usuário (provenientes do Microsoft Entra ID) para produzir uma imagem completa.

Recuperar dados de usuários e grupos

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

Técnica Descrição Boa opção para processos manuais de auditoria Boa opção para processos automatizados de auditoria
Manual Explorador do Graph O Explorer do Graph é uma boa opção para processos manuais de auditoria.
Programático APIs e SDKs do Microsoft Graph APIs e SDKs do Microsoft Graph são boas opções para processos automatizados de auditoria.
Programático Módulo do PowerShell Az O módulo Az PowerShell é uma boa opção para processos automatizados de auditoria.

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

Observação

Tenha cuidado ao ler informações online porque muitos nomes de ferramentas são semelhantes. Algumas ferramentas no ecossistema da Microsoft incluem o termo Graph no nome, como Azure Resource Graph, GraphQL e API do Graph de Segurança da Microsoft. Essas ferramentas não estão relacionadas ao Microsoft Graph e estão fora do escopo deste artigo.

Microsoft Graph Explorer

O Explorer do Microsoft Graph é uma ferramenta de desenvolvedor que permite que você saiba mais sobre as APIs do Microsoft Graph. Essa é uma maneira simples de começar, pois não requer nenhuma outra ferramenta ou configuração em seu computador. Você pode entrar para recuperar dados de seu locatário ou recuperar dados de exemplo de um locatário padrão.

Você pode usar Explorer do Graph 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 gravar um script.
  • Verificar os dados de maneira informal.
  • Determine quais permissões são necessárias para cada API. Você também pode dar seu consentimento para novas permissões.
  • Obtenha snippets de código a serem usados ao criar scripts.

Use este link para abrir o Explorer do Graph.

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 agrupa 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 sua linguagem preferida e um dos SDKs. Para obter mais informações, confira Escolher APIs ou cmdlets do PowerShell a seguir neste artigo.

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

Importante

O módulo do PowerShell do Microsoft Graph substitui os módulos do PowerShell do Azure AD e MSOL (MSOnline), que foram preteridos. Você não deve criar novas soluções com módulos preteridos. O módulo PowerShell do Microsoft Graph tem muitos recursos e benefícios. Para obter mais informações, consulte Atualizar do PowerShell do Azure AD para o PowerShell do Microsoft Graph.

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

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

Dica

A Microsoft atualiza os módulos PowerShell do Microsoft Graph regularmente. Às vezes, os módulos de versão prévia são disponibilizados por pré-lançamento ou ponto de extremidade beta. Talvez você queira especificar a versão em que está interessado ao instalar e atualizar os módulos. Além disso, ao examinar a documentação online, observe que o número de versão atual é acrescentado automaticamente ao final da URL (portanto, tenha cuidado ao salvar ou compartilhar URLs).

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.

Importante

O módulo Az PowerShell substitui os módulos PowerShell do AzureRM, que foram preteridos. Você não deve criar novas soluções com módulos preteridos.

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 do Az versão 7, 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 que está contido nas APIs do Microsoft Graph e nos módulos PowerShell. Para novas soluções, recomendamos que você use o SDK do PowerShell do Microsoft Graph.

APIs e módulos preteridos

Você pode encontrar artigos e postagens de blog online 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 APIs ou módulos a seguir.

  • Módulos PowerShell do AzureRM: preteridos e serão desativados. Eles foram substituídos pelo módulo Az PowerShell.
  • Módulo API do Graph do Azure AD e PowerShell do Azure AD: 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 PowerShell do Microsoft Graph. (O Microsoft Entra ID agora é conhecido como Microsoft Entra ID.)
  • Módulo PowerShell do MSOL (MSOnline): preterido e será desativado. Todos os investimentos futuros do PowerShell serão feitos no SDK do PowerShell do Microsoft Graph.

Cuidado

Confirme o status de qualquer API ou módulo preterido que você esteja usando no momento. Para obter mais informações sobre a desativação do AzureRM, consulte este comunicado.

Para obter mais informações sobre o Microsoft Entra ID e o MSOL, confira esta postagem de anúncio de desativação.

Se você tiver dúvidas ou precisar esclarecer a direção futura do acesso a dados programáticos, entre em contato com sua equipe da conta da Microsoft.

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

  • Confirmar requisitos: esclareça as necessidades de compilação de dados relacionados a usuários, grupos e licenças.
  • Priorizar requisitos: confirme quais são as principais prioridades para que você saiba no que despender seu tempo primeiro.
  • Decidir a frequência para extrair dados: determine com que frequência você precisará de um novo instantâneo dos dados de usuários e grupos (por exemplo, toda semana ou todos os meses).
  • Decidir como extrair dados com o Microsoft Graph: determine qual método você usará para recuperar os dados.
  • Concluir uma prova de conceito: planeje concluir uma pequena POC (prova de conceito) técnica para extrair dados de usuários e grupos. Use-a para validar suas decisões sobre como a solução final será criada.

Acessar dados de APIs REST do Power BI

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

Por exemplo, você pode recuperar dados sobre:

Durante uma auditoria de segurança, talvez você queira identificar:

Para obter mais informações sobre os outros tipos de APIs, consulte Escolher uma API de usuário ou 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:

  • Obter requisitos: compile os requisitos analíticos conforme eles surgem. Acompanhe-os em sua lista de pendências.
  • Priorizar requisitos: defina prioridades para os novos requisitos que surgem.

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

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

Diagrama de fluxo descrevendo a Fase 2, que se concentra nos pré-requisitos e na configuração para construir uma solução de auditoria em nível de locatário.

Criar Conta de Armazenamento

Neste ponto, você decidiu um local para armazenar dados brutos e como criar dados coletados. Com base nessas decisões, agora 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 usar uma tecnologia que permita gravar os dados brutos no armazenamento imutável. Depois que os dados são gravados, eles não podem ser alterados ou excluídos. Então você pode confiar nos dados brutos porque sabe que um administrador com acesso não pode alterá-los de forma alguma. No entanto, os dados coletados (geralmente) não precisam ser armazenados no armazenamento imutável. Os dados coletados podem ser alterados ou regenerados.

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

  • Criar uma conta de armazenamento: crie ou envie uma solicitação para criar uma conta de armazenamento. Use configurações de armazenamento imutáveis para os dados brutos, sempre que possível.
  • Definir permissões: determine quais permissões devem ser definidas para a conta de armazenamento.
  • Testar o acesso: faça um pequeno teste para garantir que você possa ler e gravar na conta de armazenamento.
  • Confirmar responsabilidades: verifique se está claro quem gerenciará a conta de armazenamento continuamente.

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, agora você está pronto para instalar software e configurar serviços.

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

Se tiver tomado a decisão (descrita anteriormente) de usar o PowerShell, você deverá instalar o PowerShell Core e os módulos PowerShell necessários em:

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

Se tiver optado por usar qualquer serviço do Azure (como Azure Functions, Automação do Azure, Azure Data Factory ou Azure Synapse Analytics), você também deverá provisioná-los e configurá-los.

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

  • Configurar computadores de administrador/desenvolvedor: se aplicável, instale as ferramentas necessárias que serão usadas para desenvolvimento.
  • Configurar servidores:se aplicável, instale as ferramentas necessárias em todos os servidores ou máquinas virtuais presentes em sua arquitetura.
  • Configurar serviços do Azure: se aplicável, provisione e configure cada serviço do Azure. Atribua permissões para cada administrador/desenvolvedor que fará o trabalho de desenvolvimento.

Registrar um aplicativo do Microsoft Entra

Neste ponto, você decidiu como autenticar. Recomendamos que você registre um aplicativo do Microsoft Entra (entidade de serviço). Normalmente 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 em nível de locatário, consulte Habilitar a autenticação da entidade de serviço para APIs de administrador somente leitura.

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

  • Verifique se há um registro de aplicativo existente: verifique com a TI se um registro de aplicativo existente está disponível para fins de execução de APIs de administrador. Nesse caso, determine se o existente deve ser usado ou se um novo deve ser criado.
  • Criar um novo registro de aplicativo: crie um registro de aplicativo quando apropriado. Considere usar um nome de aplicativo como PowerBI-AdminAPIs-EntraApp, que descreve claramente sua finalidade.
  • Criar um segredo para o registro de aplicativo: quando o registro de aplicativo existir, crie um segredo para ele. Defina a data de expiração com base na frequência com que você pretende girar o segredo.
  • Salvar os valores com segurança: armazene o segredo, a ID do aplicativo (ID do cliente) e a ID do locatário porque você precisará deles para se autenticar com a entidade de serviço. Use um local seguro, como um cofre de senhas organizacional. (Se você precisar solicitar a criação de um registro de aplicativo de TI, especifique que precisa desses valores retornados para você.)
  • Criar um grupo de segurança: crie (ou solicite) um grupo de segurança que será usado para o Power BI. Considere usar o nome do grupo, como entidades de serviço de administrador do Power BI, o que significa que o grupo será usado para acessar metadados em todo o locatário.
  • Adicionar a entidade de serviço como membro do grupo de segurança: use a ID do aplicativo (ID do cliente) para adicionar a entidade de serviço nova (ou existente) como membro do novo grupo de segurança.
  • Atualizar a configuração do locatário da API de administrador no Power BI: no portal de administração do Power BI, adicione o grupo de segurança à configuração Permitir que as entidades de serviço usem APIs de administrador somente leitura do Power BI.
  • Ignorar a atribuição de permissões no Azure: não delegue nenhuma permissão ao registro de aplicativo (ele obterá acesso aos dados de auditoria em nível de locatário do Power BI por meio da configuração de locatário Permitir que entidades de serviço usem APIs de administrador somente leitura do Power BI).
  • Decidir se o registro de aplicativo deve acessar metadados detalhados: determine se deseja extrair informações detalhadas sobre tabelas, colunas e expressões de medida de modelo semântico ao criar seu inventário de locatários.
  • Atualizar as configurações detalhadas do locatário de metadados no Power BI: opcionalmente, no portal de administração do Power BI, adicione o grupo de segurança à configuração de locatário Aprimorar respostas da API de administrador com metadados detalhados e também a configuração de locatário Aprimorar respostas da API de administrador com DAX e expressões de mashup.
  • Testar a entidade de serviço: crie um script simples para entrar usando a entidade de serviço e teste se ele pode recuperar dados de uma API de administrador.
  • Criar um processo para gerenciar segredos de registro de aplicativo: crie uma documentação e um processo para girar regularmente os segredos. Determine como você comunicará com segurança um novo segredo a todos os administradores e desenvolvedores que precisam dele.

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 em nível de locatário.

APIs de administrador

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

Importante

Como essas configurações concedem acesso a metadados para todo o locatário (sem atribuir permissões diretas do Power BI), você deve controlá-las rigorosamente.

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

Observação

Você não precisa atribuir explicitamente outros administradores do Power BI à configuração Permitir que entidades de serviço usem APIs de administrador somente leitura do Power BI porque eles já têm acesso a metadados de todo o locatário.

A configuração de locatário Aprimorar respostas da API de administrador com metadados detalhados 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 em nível de esquema sobre modelos semânticos do Power BI para que ele possa armazená-los no catálogo de dados.

A configuração de locatário Aprimorar respostas da API de administrador 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.

Observação

A configuração Permitir que entidades de serviço usem APIs de administrador somente leitura do Power BI é especificamente sobre como acessar APIs de administrador. Seu nome é muito semelhante à configuração de locatário destinada a acessar APIs de usuário (descritas a seguir). Para obter mais informações sobre a diferença entre APIs de administrador e APIs de usuário, consulte Escolher uma API de usuário ou API de administrador anteriormente neste artigo.

APIs de 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 workspace).

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 acesso às APIs de inserção, APIs de streaming, APIs de exportação e a 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 em nível de relatório.

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

  • Verificar se cada entidade de serviço está no grupo correto: confirme se o grupo Entidades de serviço de administrador do Power BI inclui as entidades de serviço corretas.
  • Atualizar a configuração de locatário da API de administrador no Power BI: adicione o grupo de segurança à configuração de locatário Permitir que entidades de serviço usem APIs de administrador somente leitura do Power BI, o que permite usar as APIs de administrador para recuperar metadados de todo o locatário.
  • Atualizar as configurações detalhadas do locatário de metadados no Power BI: se necessário, adicione o grupo de segurança à configuração de locatário Aprimorar respostas da API de administrador com metadados detalhados e a configuração de locatário Aprimorar respostas da API de administrador com DAX e expressões de mashup.
  • Confirmar quais APIs de usuário serão acessadas: verifique se uma ou mais APIs de usuário serão necessárias (além de usar as APIs de administrador).
  • Atualizar a configuração de locatário da API de usuário no Power BI: adicione o grupo de segurança à configuração de locatário Permitir que entidades de serviço usem APIs do Power BI, que se destina a APIs de usuário.

Fase 3: desenvolvimento e análise de solução

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

Diagrama de fluxo descrevendo a Fase 3, que se concentra no desenvolvimento e na análise de soluções de uma solução de auditoria em nível de locatário.

Extrair e armazenar os dados brutos

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

Assim como 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 de atributo-valor e matrizes. Por exemplo, "state": "Active" é um exemplo em que o valor do atributo de estado é Ativo. 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 que você se familiariza 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 workspace.

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

  • Qual convenção de nomenclatura será usada? Para um sistema baseado em arquivo, uma convenção de nomenclatura é necessária para arquivos, pastas e zonas do data lake. Para um banco de dados, uma convenção de nomenclatura é necessária para tabelas e colunas.
  • Qual formato será usado para armazenar os dados brutos? À medida que o Power BI continua a introduzir novos recursos, aparecerão novas atividades 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 coletados.
  • Qual local de armazenamento será usado? Um armazenamento de blobs ou data lake é comumente usado para armazenar dados brutos. Para obter mais informações, consulte Determinar onde armazenar dados de auditoria anteriormente neste artigo.
  • Quanto histórico você 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 decidir por um período mais curto, dependendo das políticas de retenção de dados para sua organização.
  • Como você acompanhará a última execução do processo? Defina um arquivo de configuração, ou o equivalente, para registrar os carimbos de data/hora quando um processo é iniciado e concluído. Na 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ê lidará com a limitação? Algumas APIs REST do Power BI e a API do Microsoft Graph implementam 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. A maneira como você evita tentativas com falha devido à limitação depende da tecnologia usada para acessar e extrair os dados. Uma opção é desenvolver lógica em seus scripts que responda a um erro 429 "Muitas solicitações" repetindo após um período de espera.
  • Os dados de auditoria são necessários para 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 no armazenamento imutável. Dessa forma, depois 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 aos seus requisitos? Os melhores lugares para armazenar dados brutos são um data lake (como Azure Data Lake Storage Gen2) ou um armazenamento de objetos (como Armazenamento de Blobs do Azure). Um sistema de arquivos também poderá 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:

  • Confirmar requisitos e prioridades: esclareça os requisitos e as prioridades dos dados que você extrairá primeiro.
  • Confirmar a fonte de dados a ser extraída: verifique a fonte de cada tipo de dados necessário.
  • Configurar um processo para extrair os dados e carregá-los na zona de dados brutos: crie o processo inicial para extrair e carregar os dados brutos em seu estado original, sem nenhuma transformação. Teste se o processo funciona como esperado.
  • Criar um agendamento para executar os processos: configure um agendamento recorrente para executar os processos de extração, carregamento e transformação.
  • Verificar se as credenciais são gerenciadas com segurança: confirme se senhas, segredos e chaves são armazenados e comunicados de maneiras seguras.
  • Confirmar se a segurança está configurada corretamente:verifique se as permissões de acesso estão configuradas corretamente para os dados brutos. Verifique se os administradores e auditores podem acessar os dados brutos.

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 coletados

Neste ponto, os dados brutos são extraídos e armazenados. A próxima etapa é criar uma camada de dados gold separada para os dados coletados. Sua meta é 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 é otimizado intencionalmente para análise e relatório. Os arquivos na camada de dados coletados tornam-se a fonte de um modelo de dados do Power BI (descrito no próximo tópico).

Dica

Quando você esperar que haja mais de um modelo de dados, é mais útil investir em uma camada centralizada de dados coletados.

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

  • Confirme os requisitos e as prioridades: se você pretende usar uma camada intermediária silver para os dados transformados, esclareça os requisitos e os objetivos para o que você precisa realizar.
  • Configurar um processo para transformar os dados brutos e carregá-los na zona de dados coletados: crie um processo para transformar e carregar os dados em um esquema em estrela. Teste se o processo funciona como esperado.
  • Criar um agendamento para executar os processos: configure um agendamento recorrente para preencher a camada de dados coletados.
  • Confirmar se a segurança está configurada corretamente:verifique se as permissões de acesso estão configuradas corretamente para os dados coletados. Verifique se os desenvolvedores do modelo de dados podem acessar os dados coletados.

Criar um modelo de dados

O tópico é sobre como configurar um modelo de dados analítico. Um modelo de dados é um recurso de dados que pode ser consultado e é otimizado para análise. Às vezes, ele é conhecido 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 coletada (gold). Se você optar por não criar uma camada de dados coletados, o modelo de dados originará 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 coletados, o esquema em estrela do modelo de dados do Power BI deve espelhar o esquema em estrela da camada de dados coletados.

Dica

Para obter uma visão geral do design do esquema em estrela, confira Entender o esquema em estrela e sua importância para o Power BI.

Assim como acontece com 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 se tornam disponíveis. Com o tempo, você pode até mesmo integrar novas fontes de dados.

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

  • Data: um conjunto de atributos de data para habilitar a análise (destrinchamento) de dados por dia, semana, mês, trimestre, ano e outros períodos de tempo relevantes.
  • Hora: se você precisar analisar por hora do dia e tiver um volume muito grande de dados de auditoria, considere armazenar a parte de hora separadamente da data. Essa abordagem pode ajudar a aprimorar o desempenho do aplicativo.
  • 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 nesta 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 agrupa e classifica eventos de atividade semelhantes. Por exemplo, você pode agrupar todos os eventos de criação de item, excluir eventos e assim por diante.
  • Workspaces: uma lista de workspaces nas propriedades de locatário e workspace, como tipo (pessoal ou padrão) e descrição. Algumas organizações registram mais detalhes sobre workspaces (possivelmente usando uma lista do SharePoint). Você pode integrar esses detalhes a essa tabela de dimensões. Você precisa decidir se essa tabela de dimensões armazena apenas o estado atual do workspace ou se ela armazena dados com controle de versão que refletem alterações significativas no workspace ao longo do tempo. Por exemplo, quando um nome de workspace é alterado, os relatórios históricos mostram o nome do workspace atual ou o nome do workspace que era atual naquele momento? Para obter mais informações sobre controle de versão, consulte Dimensões de alteração lenta.
  • 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 locatário.
  • Gateways: uma lista de gateways de dados no locatário.
  • Fontes de dados: uma lista de fontes de dados que são 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 originários dos dados JSON originais. Todos os atributos que não têm nenhum valor analítico são removidos. Todos os atributos que pertencem às tabelas de dimensões (acima) também são removidos.
  • Inventário de locatários: um instantâneo pontual de todos os itens publicados no locatário. Para obter mais informações, confira Inventário de locatários anteriormente neste artigo.
  • Modelos semânticos: inclui atividade do usuário envolvendo modelos semânticos (como alterações semânticas de modelo) ou fontes de dados relacionadas.
  • Atualizações do 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 de workspace: um instantâneo pontual de atribuições de função de workspace.
  • Licenças de usuário: um instantâneo pontual de licenças de usuário. Embora você queira armazenar a licença de usuário na tabela de dimensões Usuários, essa abordagem não oferecerá suporte à análise de alterações de licença e tendências ao longo do tempo.
  • Associações de grupo de usuários: um instantâneo pontual de usuários (e entidades de serviço) atribuído a um grupo de segurança.
  • Atividades da comunidade: inclui fatos relacionados à comunidade, como eventos de treinamento. Por exemplo, você pode analisar as atividades do usuário do Power BI em comparação com a participação no treinamento. Esses dados podem ajudar o Centro de Excelência a identificar possíveis novos campeões.

As tabelas de fatos não devem incluir colunas que os criadores de relatório 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 detalhamento). Esse último ponto é importante para produzir um modelo de dados útil e amigável que seja extensível quando você adicionar novas tabelas de fatos (assuntos).

Por exemplo, a tabela de dimensões Usuários estará relacionada a todas as tabelas de fatos. Ela deve estar relacionada à tabela de fatos Atividades do usuário (que realizou a atividade), tabela de fatos Inventário de locatários (que criou o item publicado) e todas as outras tabelas de fatos. Quando um relatório é filtrado por um usuário na tabela de dimensões Usuários, os visuais desse relatório podem mostrar fatos para esse usuário de qualquer tabela de fatos relacionada.

Ao projetar seu modelo, verifique se um atributo está visível uma vez, e apenas uma vez, no modelo. Por exemplo, o endereço de email 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 dar suporte a um relacionamento de modelo). No entanto, você deve ocultá-lo em cada tabela de fatos.

Recomendamos que você crie seu modelo de dados separado dos relatórios. A desassociação de um modelo semântico e seus relatórios resulta em um modelo semântico centralizado que pode atender a muitos relatórios. Para saber mais sobre a reutilização de modelos semânticos compartilhados, consulte o cenário de uso de BI de autoatendimento gerenciado.

Considere configurar a RLS (segurança em nível de linha) 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:

  • Planejar e criar o modelo de dados: projete o modelo de dados como um esquema em estrela. Valide se os relacionamentos funcionam conforme esperado. À medida que você desenvolve o modelo, crie medidas iterativamente e adicione dados adicionais com base nos requisitos analíticos. Inclua melhorias futuras em uma lista de pendências, quando necessário.
  • Configurar a RLS: se você pretende disponibilizar o modelo de dados para outros usuários gerais, configure a segurança em nível de linha para restringir o acesso a dados. Valide se as funções RLS retornam os dados corretos.

Aprimorar o modelo de dados

Para analisar efetivamente o uso de 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 de seus dados é adicionar classificações ao modelo de dados. Verifique se essas classificações são usadas consistentemente por seus relatórios.

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

Classificação de uso do usuário

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

  • Usuário frequente: atividade registrada na última semana e em nove dos últimos 12 meses.
  • Usuário ativo: atividade registrada no mês passado.
  • 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.

Dica

É útil saber quem são seus usuários ocasionais ou inativos, especialmente quando eles têm licenças Pro ou PPU (que envolvem custo). Também é útil saber quem são seus usuários mais frequentes e ativos. Considere convidá-los para ingressar no horário comercial ou participar do treinamento. Seus criadores de conteúdo mais ativos podem ser candidatos a ingressar em sua rede de campeões.

Classificação de uso do conteúdo

Considere as classificações a seguir para uso do 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 de uso ocasional: atividade registrada nos últimos nove meses, mas sem atividade no último mês.
  • Conteúdo não usado: nenhuma atividade registrada nos últimos nove meses.
Classificação de tipo de usuário

Considere as classificações a seguir para tipo do 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 exibiu o conteúdo, mas sem nenhuma atividade de criação de conteúdo.

Você deve decidir se as classificações de uso para usuários ou conteúdo devem ser baseadas apenas em quão recentemente ocorreu uma atividade. Talvez você também queira considerar a fatoração no uso médio ou de 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, antes dessa semana, o gerente 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ório publica um novo relatório toda semana. Quando você analisa o uso por usuários frequentes, a atividade regular do criador de relatório parece ser positiva. No entanto, após uma investigação mais aprofundada, você descobre que esse usuário vem republicando um novo relatório (com um novo nome de relatório) sempre que edita o relatório. Seria útil para o criador do relatório ter mais treinamento.
  • Um executivo exibe um relatório esporadicamente e, portanto, sua classificação de uso muda com frequência. Talvez seja necessário analisar determinados tipos de usuários, como executivos, de forma diferente.
  • Um auditor interno vê relatórios críticos uma vez por ano. O auditor interno pode parecer 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 desativado, já que é usado com pouca frequência.

Dica

Você pode calcular médias e tendências usando as funções de inteligência de tempo do DAX. Para saber como usar essas funções, trabalhe no módulo de aprendizagem Usar funções de inteligência de tempo do DAX em modelos do Power BI Desktop.

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

  • Obter consenso sobre definições de classificação: discuta definições de classificação com os stakeholders relevantes. Verifique se há acordo ao tomar as decisões.
  • Criar documentação: verifique se as definições de classificação estão incluídas na documentação para criadores e consumidores de conteúdo.
  • Criar um loop de comentários: verifique se há uma maneira de os usuários fazerem perguntas ou proporem alterações nas definições de classificação.

Criar relatórios analíticos

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

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

  • Patrocinador executivo
  • Centro de excelência
  • Administradores do Power BI
  • Administradores de workspace
  • 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 exibições de conteúdo: seus patrocinadores executivos e suas 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 workspace 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. Os administradores de capacidade Premium estarão interessados em quem está usando a capacidade para garantir sua integridade e estabilidade.
  • Inventário de locatários: seus administradores, administradores de workspace e auditores do Power BI estarão interessados em entender qual conteúdo existe, onde, linhagem e suas configurações de segurança.

Essa lista não é absoluta. O objetivo é fornecer ideias sobre como criar relatórios analíticos direcionados a 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 de como você pode usar dados de auditoria e os tipos de informações que você pode optar por apresentar em seus relatórios.

Dica

Embora seja tentador apresentar muitos dados, inclua apenas informações sobre as quais você está preparado para tomar uma ação. Verifique se cada página de relatório é clara sobre sua finalidade, qual ação deve ser tomada e por quem.

Para saber como criar relatórios analítico, confira o roteiro de aprendizagem Projetar relatórios efetivos no Power BI.

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

  • Revisar requisitos: priorize a criação de relatórios com base em necessidades conhecidas e perguntas específicas que devem ser respondidas.
  • Confirmar seu público-alvo: esclareça quem usará os relatórios de auditoria e qual será a finalidade pretendida.
  • Criar e implantar relatórios: desenvolva o primeiro conjunto de relatórios principais. Estenda-os e aprimore-os gradualmente ao longo do tempo.
  • Distribuir relatórios em um aplicativo: considere criar um aplicativo que inclua todos os seus relatórios de auditoria e monitoramento.
  • Verificar quem tem acesso aos relatórios: verifique se os relatórios (ou o aplicativo) são disponibilizados para o conjunto correto de usuários.
  • Criar um loop de comentários: verifique se há uma maneira de os consumidores de relatório fornecerem feedback ou sugestões ou relatarem problemas.

Tomar uma ação com base nos dados

A auditoria de dados é valiosa porque ajuda você a entender o que está acontecendo em seu locatário do Power BI. Embora possa parecer óbvio, agir explicitamente sobre o que você aprende com os dados de auditoria pode ser facilmente negligenciado. Por esse motivo, recomendamos que você atribua alguém que seja 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 no nível de maturidade com o Power BI.

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

Uso de conteúdo

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 (diária ou semanal): verifique se qualquer conteúdo crítico é certificado. Confirme se a propriedade está clara e se a solução tem suporte adequado.
  • Alto número de exibições de workspace: quando ocorrer um grande número de exibições de workspace, 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 de destino para determinar se a solução atende às suas necessidades ou se seus requisitos foram alterados.
  • A atividade de atualização ocorre com mais frequência do que as exibiçõ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 usuário

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

  • Primeira ação de publicação por um novo usuário: identifique quando um tipo de usuário muda de consumidor para criador, que você pode identificar quando eles publicam conteúdo pela primeira vez. É uma ótima oportunidade para enviar um email padrão que fornece diretrizes e links para recursos úteis.
  • Participação dos criadores de conteúdo mais frequentes: convide seus criadores mais ativos para ingressar em sua rede de campeões ou para se envolver com sua comunidade de práticas.
  • 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 a atribuição de uma licença permanente ao usuário antes do término da avaliação.

Oportunidades de treinamento do usuário

Aqui estão algumas oportunidades de treinamento do usuário que você pode identificar com base nos 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 quê é importante evitar a criação de modelos semânticos duplicados.
  • Compartilhamento excessivo de um workspace pessoal: contate um usuário que está fazendo muito compartilhamento de seu workspace pessoal. Ensine-o sobre workspaces padrão.
  • Exibições de relatório significativas de um workspace pessoal: contate um usuário que possui conteúdo que tenha um alto número de exibições de relatório. Ensine-o como os workspaces padrão são melhores do que os workspaces pessoais.

Dica

Você também pode melhorar seu conteúdo ou documentação de treinamento examinando as perguntas respondidas pela comunidade interna do Power BI e os problemas enviados ao suporte técnico.

Segurança

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

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

Governança e mitigação de risco

Aqui estão alguns 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 exibições para relatórios (e modelos semânticos subjacentes) que não são endossados.
  • Uso significativo de fontes de dados desconhecidas ou não sancionadas.
  • Locais de arquivo que não se alinham com as diretrizes de governança de onde os arquivos de origem devem estar localizados.
  • Nomes de workspace não se alinham com os requisitos de governança.
  • Rótulos de confidencialidade são usados para proteção de informações.
  • Falhas consistentes de atualização de dados.
  • Uso significativo e recorrente de impressão.
  • Uso inesperado ou excessivo de assinaturas.
  • Uso inesperado de gateways pessoais.

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

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

  • Esclarecer expectativas: crie relatórios de auditoria com um conjunto claro de expectativas para quais ações são esperadas.
  • Esclarecer quem será responsável pelas ações: certifique-se de que funções e responsabilidades sejam atribuídas.
  • Criar automação: quando possível, automatize as ações conhecidas que são repetíveis.
  • Usar um sistema de acompanhamento: use um sistema para acompanhar uma situação observada, incluindo contato feito, próxima ação planejada, quem é responsável, resolução e status.

Fase 4: manter, aprimorar e monitorar

A quarta fase de planejamento e implementação de uma solução de auditoria em nível de locatário se concentra na manutenção, nos aprimoramentos e no 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.

Diagrama de fluxo descrevendo a Fase 4, que se concentra em manter, aprimorar e monitorar uma solução de auditoria em nível de locatário.

Operacionalizar e melhorar

Normalmente, os processos de auditoria são considerados em execução em produção quando o desenvolvimento e os testes iniciais são concluídos e você automatiza o processo. Os processos de auditoria automatizados em execução em produção têm expectativas maiores (do que processos manuais) para qualidade, confiabilidade, estabilidade e suporte.

Um processo de auditoria em nível de produção foi operacionalizado. Uma solução operacionalizada geralmente inclui muitas das seguintes características.

  • Segura: as credenciais são armazenadas e gerenciadas com segurança. Os scripts não contêm senhas ou chaves em texto não criptografado.
  • 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 adotados para garantir que o ambiente de produção seja protegido. Você também pode trabalhar com ambientes de desenvolvimento e teste ou apenas com um ambiente de desenvolvimento.
  • Suporte: a equipe que dá suporte à 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 ocorre quando apropriado.
  • Alertas: quando algo der errado, os alertas notificarão a equipe de suporte automaticamente. Preferencialmente, o alerta inclui logs e emails (em vez de somente email). Um log é útil para analisar erros e avisos registrados.
  • Registrar em 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 normalmente (como sair imediatamente, continuar ou aguardar e tentar novamente). As notificações de alerta são enviadas à equipe de suporte quando ocorre um erro.
  • Padrões de codificação: boas técnicas de codificação com bom desempenho são usadas. Por exemplo, os loops são evitados propositalmente, exceto quando necessário. Padrões de codificação consistentes, comentários, formatação e sintaxe são usados para que a solução seja mais fácil de manter e dar suporte.
  • Reutilização e modularização: para minimizar valores de duplicação, código e configuração (como cadeias de conexão ou endereços de email para notificações) são modularizados para que outros scripts e processos possam reutilizá-los.

Dica

Você não precisa fazer tudo listado acima de uma só vez. À medida que adquire experiência, você pode aprimorar incrementalmente a solução para que ela se torne completa e robusta. Lembre-se de que a maioria dos exemplos que você encontra online são snippets de script simples e pontuais que podem não ter qualidade de produção.

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:

  • Avaliar o nível de soluções existentes: determine se há oportunidades para melhorar e estabilizar as soluções de auditoria existentes que são automatizadas.
  • Estabelecer padrões de nível de produção: decida quais padrões você deseja ter para seus processos de auditoria automatizados. Fatore as melhorias que você pode adicionar realisticamente ao longo do tempo.
  • Criar um plano de melhoria: planeje melhorar a qualidade e estabilidade das soluções de auditoria de produção.
  • Determinar se um ambiente de desenvolvimento separado é necessário: avalie o nível de risco e a dependência dos dados de produção. Decida quando criar ambientes separados de desenvolvimento e produção (e teste).
  • Considerar uma estratégia de retenção de dados: determine se você precisa implementar um processo de retenção de dados que limpe os dados após um determinado período de tempo ou mediante solicitação.

Documentação e suporte

A documentação e o suporte são essenciais para qualquer solução em 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 é direcionada à equipe técnica que criou a solução e que 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 de componentes de arquitetura e pré-requisitos.
  • Quem detém e gerencia o conteúdo.
  • Quem dá suporte à solução.
  • Um diagrama da arquitetura.
  • Decisões de design, incluindo metas, motivos pelos quais determinadas 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 diretrizes e padrões técnicos.
  • Requisitos de gerenciamento 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 isso).

Documentação de suporte

Dependendo do nível de criticidade da 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.

Às vezes, a documentação de suporte é conhecida como uma base de dados de conhecimento ou um runbook. Essa documentação é direcionada ao seu suporte técnico ou à sua equipe de suporte e deve incluir:

  • Diretrizes de solução de problemas para quando algo der errado. Por exemplo, quando há uma falha de atualização de dados.
  • Ações a serem tomadas continuamente. Por exemplo, pode haver algumas etapas manuais que alguém precisa executar regularmente até que um problema seja resolvido.

Documentação do criador de conteúdo

Você deriva mais valor de sua solução de auditoria fornecendo análise 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 aos criadores de conteúdo de autoatendimento que criam relatórios e modelos de dados que geram os dados de auditoria coletados. Ela 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:

  • Confirmar quem deve dar suporte à solução: determine quem oferecerá suporte a soluções de auditoria consideradas de nível de produção (ou com dependências de relatório downstream).
  • Verificar a preparação da equipe de suporte: verifique se a equipe de suporte está preparada para dar suporte à solução de auditoria. Identifique se há lacunas na preparação que precisam ser resolvidas.
  • Organizar treinamento cruzado: realize sessões de transferência de conhecimento ou sessões de treinamento cruzado para a equipe de suporte.
  • Esclarecer as expectativas da equipe de suporte: verifique se as expectativas de resposta e resolução estão claramente documentadas e comunicadas. Decida se alguém precisa estar de plantão para resolve rapidamente problemas relacionados à solução de auditoria.
  • Criar documentação técnica: crie documentação sobre as decisões de design e arquitetura técnica.
  • Criar documentação de suporte: atualize a base de dados de conhecimento do suporte técnico para incluir informações sobre como dar suporte à solução.
  • Criar documentação para criadores de conteúdo: crie documentação para ajudar os criadores de autoatendimento a usar o modelo de dados. Descreva definições de dados comuns para melhorar a consistência de seu uso.

Habilitar 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 em nível de locatário.

Gerenciamento contínuo

Você precisa executar 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 que você extrai 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.

Importante

Alterações interruptivas são raras, mas podem ocorrer. É importante que você tenha alguém disponível que possa solucionar problemas rapidamente ou atualizar a solução de auditoria quando necessário.

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

  • Atribuir um proprietário técnico: verifique se há propriedade e responsabilidade claras para toda a solução de auditoria.
  • Verificar se existe um backup: verifique se há um proprietário técnico de backup que pode se envolver caso surja um problema urgente que o suporte não possa resolver.
  • Manter um sistema de acompanhamento: verifique se há alguma maneira de capturar novas solicitações e definir prioridades imediatas e também de curto, médio e longo prazos (lista de pendências).

Conteúdo relacionado

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