Compartilhar via

White paper de segurança do Power BI

Resumo: O Power BI é uma oferta de SaaS (serviço de software online ou Software como serviço) da Microsoft que permite criar facilmente e rapidamente painéis de business intelligence de autoatendimento, relatórios, modelos semânticos e visualizações. Com o Power BI, você pode se conectar a muitas fontes de dados diferentes, combinar e moldar dados dessas conexões e, em seguida, criar relatórios e dashboards que possam ser compartilhados com outras pessoas.

Escritores: Yitzhak Kesselman, Paddy Osborne, Matt Neely, Tony Bencic, Srinivasan Turuvekere, Cristian Petculescu, Adi Regev, Naveen Sivaraj, Ben Glastein, Evgeny Tshiorny, Arthi Ramasubramanian Iyer, Sid Jayadevan, Ronald Chang, Ori Eduar, Anton Fritz, Idan Sheinberg, Ron Gilad, Sagiv Hadaya, Paul Inbar, Igor Uzhviev, Michael Roth, Jaime Tarquino, Gennady Pats, Orion Lee, Yury Berezansky, Maya Shenhav, Romit Chattopadhyay, Yariv Maimon, Bogdan Crivat

Revisores técnicos: Cristian Petculescu, Amir Netz, Sergei Gundorov

Aplica-se a: Power BI SaaS, Power BI Desktop, Power BI Premium, Power BI Embedded Analytics, Power BI Mobile.

Observação

Você pode salvar ou imprimir este white paper selecionando Imprimir no navegador e, em seguida, selecionando Salvar como PDF.

Introdução

O Power BI é uma oferta de SaaS (serviço de software online ou Software como serviço) da Microsoft que permite criar facilmente e rapidamente painéis de business intelligence de autoatendimento, relatórios, modelos semânticos e visualizações. Com o Power BI, você pode se conectar a muitas fontes de dados diferentes, combinar e moldar dados dessas conexões e, em seguida, criar relatórios e dashboards que possam ser compartilhados com outras pessoas.

O mundo está mudando rapidamente; as organizações estão passando por uma transformação digital acelerada, e estamos vendo um aumento maciço no trabalho remoto, aumento da demanda do cliente por serviços online e aumento do uso de tecnologias avançadas em operações e tomada de decisões de negócios. E tudo isso é alimentado pela nuvem.

À medida que a transição para a nuvem mudou de uma gota para uma inundação, e com a nova área de superfície exposta que vem com ela, mais empresas estão perguntando quão seguros são meus dados na nuvem? E qual proteção de ponta a ponta está disponível para impedir que meus dados confidenciais vazem? E para as plataformas de BI que geralmente lidam com algumas das informações mais estratégicas da empresa, essas perguntas são duplamente importantes.

Os fundamentos de décadas do modelo de segurança de BI — segurança em nível de objeto e nível de linha — embora ainda importantes, claramente não são mais suficientes para fornecer o tipo de segurança necessário na era da nuvem. Em vez disso, as organizações devem procurar uma solução de segurança de defesa em profundidade, nativa de nuvem, de várias camadas, para seus dados de business intelligence.

O Power BI foi criado para fornecer proteção completa e hermética de ponta na indústria para dados. O produto obteve as classificações de segurança mais altas disponíveis no setor, e hoje muitas agências de segurança nacional, instituições financeiras e prestadores de cuidados de saúde lhe confiam suas informações mais confidenciais.

Tudo começa com a fundação. Após um período difícil no início dos anos 2000, a Microsoft fez investimentos maciços para resolver suas vulnerabilidades de segurança e, nas décadas seguintes, construiu uma pilha de segurança forte que vai tão fundo quanto o kernel de bios do computador no chip e se estende até as experiências do usuário final. Esses investimentos profundos continuam e, hoje, mais de 3.500 engenheiros da Microsoft estão envolvidos na criação e aprimoramento da pilha de segurança da Microsoft e na abordagem proativa do cenário de ameaças em constante mudança. Com bilhões de computadores, trilhões de logons e inúmeros zettabytes de informações confiadas à proteção da Microsoft, a empresa agora possui a pilha de segurança mais avançada do setor de tecnologia e é amplamente vista como líder global na luta contra atores mal-intencionados.

O Power BI baseia-se nessa base forte. Ele usa a mesma pilha de segurança que rendeu ao Azure o direito de servir e proteger os dados mais confidenciais do mundo e integra-se às ferramentas mais avançadas de proteção de informações e conformidade do Microsoft 365. Além disso, fornece segurança por meio de medidas de segurança de várias camadas, resultando em proteção de ponta a ponta projetada para lidar com os desafios exclusivos da era da nuvem.

Para fornecer uma solução de ponta a ponta para proteger ativos confidenciais, a equipe de produtos precisava lidar com preocupações desafiadoras do cliente em várias frentes simultâneas:

  • Como controlar quem pode se conectar, de onde eles se conectam e como eles se conectam?Como podemos controlar as conexões?
  • Como os dados são armazenados?Como ele é criptografado?Quais controles eu tenho em meus dados?
  • Como posso controlar e proteger meus dados confidenciais?Como fazer para garantir que esses dados não possam vazar fora da organização?
  • Como fazer para auditar quem conduz quais operações?Como reagir rapidamente se há atividade suspeita no serviço?

Este artigo fornece uma resposta abrangente para todas essas perguntas. Ele começa com uma visão geral da arquitetura de serviço e explica como os principais fluxos no sistema funcionam. Em seguida, ele passa a descrever como os usuários se autenticam no Power BI, como as conexões de dados são estabelecidas e como o Power BI armazena e move dados por meio do serviço. A última seção discute os recursos de segurança que permitem que você, como administrador do serviço, proteja seus ativos mais valiosos.

O serviço do Power BI é regido pelos Termos dos Serviços Do Microsoft Online e pela Política de Privacidade da Microsoft Enterprise. Para o local do processamento de dados, consulte o local dos termos de processamento de dados nos Termos dos Serviços Do Microsoft Online e para o Adendo de Proteção de Dados. Para obter informações de conformidade, a Central de Confiabilidade da Microsoft é o principal recurso para o Power BI. A equipe do Power BI está trabalhando duro para trazer aos seus clientes as inovações e a produtividade mais recentes. Saiba mais sobre a conformidade nas ofertas de conformidade da Microsoft.

O serviço do Power BI segue o SDL (Ciclo de Vida de Desenvolvimento de Segurança), práticas de segurança rigorosas que dão suporte a requisitos de conformidade e garantia de segurança. O SDL ajuda os desenvolvedores a criar um software mais seguro, reduzindo o número e a gravidade das vulnerabilidades do software e, ao mesmo tempo, reduzindo o custo de desenvolvimento. Saiba mais em Práticas de Ciclo de Vida de Desenvolvimento de Segurança da Microsoft.

Arquitetura do Power BI

O serviço do Power BI é criado no Azure, plataforma de computação em nuvem da Microsoft. O Power BI está atualmente implantado em muitos datacenters em todo o mundo; há muitas implantações ativas disponibilizadas aos clientes nas regiões atendidas por esses datacenters e um número igual de implantações passivas que servem como backups para cada implantação ativa.

O WFE e o Back-End

WFE (cluster front-end da Web)

O cluster de front-end web (cluster WFE) fornece ao navegador do usuário o conteúdo inicial da página HTML durante o carregamento do site e ponteiros para o conteúdo da CDN (Rede de Distribuição de Conteúdo) do Azure, utilizado para a renderização do site no navegador.

O grupo WEF

Um cluster WFE consiste em um site ASP.NET em execução no Ambiente do Serviço de Aplicativo do Azure. Quando os usuários tentam se conectar ao serviço do Power BI, o serviço DNS do cliente pode se comunicar com o Gerenciador de Tráfego do Azure para encontrar o datacenter mais apropriado (geralmente mais próximo) com uma implantação do Power BI. Para obter mais informações sobre esse processo, consulte o método de roteamento de tráfego de desempenho para o Gerenciador de Tráfego do Azure.

Recursos estáticos como *.js, *.css e arquivos de imagem são armazenados principalmente em uma CDN do Azure e recuperados diretamente pelo navegador. Observe que as implantações de cluster do Governo Soberano são uma exceção a essa regra e, por motivos de conformidade, omitirão a CDN e, em vez disso, usarão um cluster WFE de uma região compatível para hospedar conteúdo estático.

Cluster de back-end do Power BI

O cluster de back-end é o backbone de todas as funcionalidades disponíveis no Power BI. Ele consiste em vários pontos de extremidade de serviço consumidos por clientes WFE e API, bem como serviços de trabalho em segundo plano, bancos de dados, caches e vários outros componentes.

O back-end está disponível na maioria das regiões do Azure e está sendo implantado em novas regiões conforme eles ficam disponíveis. Uma única região do Azure hospeda um ou mais clusters de back-end que permitem o dimensionamento horizontal ilimitado do serviço do Power BI quando os limites de dimensionamento vertical e horizontal de um único cluster são esgotados.

Cada cluster de back-end tem estado e hospeda todos os dados de todos os locatários atribuídos a esse cluster. Um cluster que contém os dados de um locatário específico é conhecido como o cluster inicial do locatário. As informações do cluster inicial de um usuário autenticado são fornecidas pelo Serviço Global e usadas pelo WFE para rotear solicitações para o cluster inicial do locatário.

Cada cluster de back-end consiste em várias máquinas virtuais combinadas em vários grupos de escala ajustáveis, ajustados para executar tarefas específicas, recursos com estado persistente, como bancos de dados SQL, contas de armazenamento, barramentos de serviço, caches e outros componentes de nuvem necessários.

Os metadados de locatário e os dados são armazenados dentro dos limites de cluster, exceto quando há replicação de dados para um cluster de back-end secundário em uma região do Azure emparelhada na mesma geografia do Azure. O cluster secundário de back-end funciona como um cluster de contingência em caso de interrupção regional e permanece inativo em qualquer outro momento.

A funcionalidade de back-end é atendida por microsserviços em execução em máquinas diferentes dentro da rede virtual do cluster que não são acessíveis de fora, exceto por dois componentes que podem ser acessados da Internet pública:

  • Serviço de Gateway
  • Gerenciamento de API do Azure

O cluster de back-end

Infraestrutura do Power BI Premium

O Power BI Premium oferece um serviço para assinantes que exigem recursos premium do Power BI, como IA avançada, distribuição para usuários sem licença etc. Quando um cliente se inscreve em uma assinatura do Power BI Premium, a capacidade Premium é criada por meio do Azure Resource Manager.

As capacidades do Power BI Premium são hospedadas em clusters de back-end independentes do back-end normal do Power BI, conforme descrito acima. Isso fornece melhor isolamento, alocação de recursos, suporte, isolamento de segurança e escalabilidade da oferta Premium.

O diagrama a seguir ilustra a arquitetura da infraestrutura do Power BI Premium:

Power BI Premium

A conexão com a infraestrutura do Power BI Premium pode ser feita de várias maneiras, dependendo do cenário do usuário. Os clientes do Power BI Premium podem ser um navegador do usuário, um back-end regular do Power BI, conexões diretas por meio de clientes XMLA, APIs do ARM, entre outros.

A infraestrutura do Power BI Premium em uma região do Azure consiste em vários clusters Do Power BI Premium (o mínimo é um). A maioria dos recursos Premium é encapsulada dentro de um cluster (por exemplo, computação) e há alguns recursos regionais comuns (por exemplo, armazenamento de metadados). A infraestrutura Premium permite duas maneiras de alcançar a escalabilidade horizontal em uma região: aumentar os recursos dentro de clusters e/ou adicionar mais clusters sob demanda conforme necessário (se os recursos do cluster estiverem se aproximando de seus limites).

O backbone de cada cluster são recursos de computação gerenciados pelos Conjuntos de Dimensionamento de Máquinas Virtuais e pelo Azure Service Fabric. Os Conjuntos de Dimensionamento de Máquinas Virtuais e o Service Fabric permitem um aumento rápido e indolor de nós de computação à medida que o uso aumenta e orquestra a implantação, o gerenciamento e o monitoramento dos serviços e aplicativos do Power BI Premium.

Há muitos recursos ao redor que garantem uma infraestrutura segura e confiável: balanceadores de carga, redes virtuais, grupos de segurança de rede, barramento de serviço, armazenamento etc. Todos os segredos, chaves e certificados necessários para o Power BI Premium são gerenciados exclusivamente pelo Azure Key Vault . Qualquer autenticação é feita exclusivamente por meio da integração com o Microsoft Entra ID.

Qualquer solicitação que chega à infraestrutura do Power BI Premium vai primeiro para nós de front-end – eles são os únicos nós disponíveis para conexões externas. O restante dos recursos está oculto atrás de redes virtuais. Os nós front-end autenticam a solicitação, manipulam-na ou encaminham-na para os recursos apropriados (por exemplo, nós de back-end).

Os nós de back-end fornecem a maioria das capacidades e recursos do Power BI Premium.

Power BI Mobile

O Power BI Mobile é uma coleção de aplicativos projetados para as três principais plataformas móveis: Android, iOS e Windows (UWP). As considerações de segurança para os aplicativos do Power BI Mobile se enquadram em duas categorias:

  • Comunicação do dispositivo
  • O aplicativo e os dados no dispositivo

Para comunicação de dispositivo, todos os aplicativos do Power BI Mobile se comunicam com o serviço do Power BI e usam as mesmas sequências de conexão e autenticação usadas pelos navegadores, que são descritas em detalhes anteriormente neste white paper. Os aplicativos móveis do Power BI para iOS e Android trazem uma sessão de navegador dentro do próprio aplicativo, enquanto o aplicativo móvel do Windows cria um agente para estabelecer o canal de comunicação com o Power BI (para o processo de entrada).

A tabela a seguir mostra o suporte à CBA (autenticação baseada em certificado) para o Power BI Mobile, com base na plataforma de dispositivo móvel:

Suporte a CBA Ios Andróide Windows
Power BI (entrar no serviço) Suportado Suportado Sem suporte
SSRS ADFS local (conecte-se ao servidor SSRS) Sem suporte Suportado Sem suporte
Proxy de Aplicativo SSRS Suportado Suportado Sem suporte

Os aplicativos do Power BI Mobile se comunicam ativamente com o serviço do Power BI. A telemetria é usada para coletar estatísticas de uso de aplicativos móveis e dados semelhantes, que são transmitidos para serviços usados para monitorar o uso e a atividade; nenhum dado do cliente é enviado com telemetria.

O aplicativo Power BI armazena dados no dispositivo que facilita o uso do aplicativo:

  • A ID do Microsoft Entra e os tokens de atualização são armazenados em um mecanismo seguro no dispositivo, usando medidas de segurança padrão do setor.
  • Dados e configurações (pares chave-valor para configuração do usuário) são armazenados em cache no armazenamento no dispositivo e podem ser criptografados pelo sistema operacional. No iOS, isso é feito automaticamente quando o usuário define uma senha. No Android, isso pode ser configurado nas configurações. No Windows, isso é feito usando o BitLocker.
  • Para os aplicativos Android e iOS, os dados e as configurações (pares chave-valor para a configuração do usuário) são armazenados em cache no dispositivo em uma sandbox e armazenamento interno acessível somente ao aplicativo.
  • A geolocalização é habilitada ou desabilitada explicitamente pelo usuário. Se habilitado, os dados de geolocalização não são salvos no dispositivo e não são compartilhados com a Microsoft.
  • As notificações são habilitadas ou desabilitadas explicitamente pelo usuário. Se habilitado, o Android e o iOS não dão suporte aos requisitos de residência de dados geográficos para notificações.

A criptografia de dados pode ser aprimorada aplicando criptografia em nível de arquivo por meio do Microsoft Intune, um serviço de software que fornece gerenciamento de aplicativos e dispositivos móveis. Todas as três plataformas para as quais o Power BI Mobile está disponível dão suporte ao Intune. Com o Intune habilitado e configurado, os dados no dispositivo móvel são criptografados e o próprio aplicativo do Power BI não pode ser instalado em um cartão SD. Saiba mais sobre o Microsoft Intune.

O aplicativo do Windows também dá suporte à WIP (Proteção de Informações do Windows).

Para implementar o SSO, alguns valores de armazenamento protegidos relacionados à autenticação baseada em token estão disponíveis para outros aplicativos de primeira parte da Microsoft (como o Microsoft Authenticator) e são gerenciados pela MSAL ( Biblioteca de Autenticação da Microsoft ).

Os dados armazenados em cache do Power BI Mobile são excluídos quando o aplicativo é removido, quando o usuário sai do Power BI Mobile ou quando o usuário falha ao entrar (como após uma alteração de senha ou evento de expiração de token). O cache de dados inclui dashboards e relatórios acessados anteriormente do aplicativo Power BI Mobile.

O Power BI Mobile não acessa outras pastas ou arquivos de aplicativo no dispositivo.

Os aplicativos do Power BI para iOS e Android permitem que você proteja seus dados configurando uma identificação adicional, como fornecer id facial, ID de toque ou uma senha para iOS e dados biométricos (ID da impressão digital) para Android. Saiba mais sobre identificação adicional.

Autenticação no serviço do Power BI

A autenticação do usuário no serviço do Power BI consiste em uma série de solicitações, respostas e redirecionamentos entre o navegador do usuário e o serviço do Power BI ou os serviços do Azure usados pelo Power BI. Essa sequência descreve o processo de autenticação de usuário no Power BI, que segue o fluxo de concessão de código de autenticação do Microsoft Entra. Para obter mais informações sobre as opções para modelos de autenticação de usuário de uma organização (modelos de entrada), consulte Escolhendo um modelo de entrada para o Microsoft 365.

Sequência de autenticação

A sequência de autenticação do usuário para o serviço do Power BI ocorre conforme descrito nas etapas a seguir, que são ilustradas na imagem que os segue.

  1. Um usuário inicia uma conexão com o serviço do Power BI a partir de um navegador, digitando o endereço do Power BI na barra de endereços ou selecionando Entrar na página de marketing do Power BI (https://powerbi.microsoft.com). A conexão é estabelecida usando TLS e HTTPS, e toda a comunicação subsequente entre o navegador e o serviço do Power BI usa HTTPS.

  2. O Gerenciador de Tráfego do Azure verifica o registro DNS do usuário para determinar o datacenter mais apropriado (geralmente mais próximo) em que o Power BI é implantado e responde ao DNS com o endereço IP do cluster WFE para o qual o usuário deve ser enviado.

  3. Em seguida, o WFE retorna uma página HTML para o cliente do navegador, que contém uma referência de biblioteca MSAL.js necessária para iniciar o fluxo de entrada.

  4. O cliente do navegador carrega a página HTML recebida do WFE e redireciona o usuário para a página de entrada do Microsoft Online Services.

  5. Depois que o usuário for autenticado, a página de entrada redirecionará o usuário de volta para a página WFE do Power BI com um código de autenticação.

  6. O cliente do navegador carrega a página HTML e usa o código de autenticação para solicitar tokens (acesso, ID, atualização) do Microsoft Entra ID.

  7. O ID do inquilino do usuário é usado pelo cliente do navegador para fazer consultas ao Serviço Global do Power BI, que mantém uma lista de inquilinos e suas localizações de cluster de back-end do Power BI. O Serviço Global do Power BI determina qual cluster de serviço de back-end do Power BI contém o locatário do usuário e retorna a URL do cluster de back-end do Power BI de volta para o cliente.

  8. Agora, o cliente pode se comunicar com a API de URL do cluster de back-end do Power BI, usando o token de acesso no cabeçalho de autorização para as solicitações HTTP. O token de acesso do Microsoft Entra terá uma data de expiração definida de acordo com as políticas do Microsoft Entra e, para manter a sessão atual, o Cliente do Power BI no navegador do usuário fará solicitações periódicas para renovar o token de acesso antes de expirar.

Diagrama ilustrando a sequência de Autenticação do Cliente.

Nos casos raros em que a autenticação do lado do cliente falha devido a um erro inesperado, o código tenta voltar a usar a autenticação do lado do servidor no WFE. Consulte a seção de perguntas e respostas no final deste documento para obter detalhes sobre o fluxo de autenticação do lado do servidor.

Residência de dados

A menos que indicado de outra forma na documentação, o Power BI armazena dados do cliente em uma geografia do Azure atribuída quando um locatário do Microsoft Entra se inscreve para serviços do Power BI pela primeira vez. Um tenant do Microsoft Entra abriga as identidades de usuário e aplicativo, grupos e outras informações relevantes que dizem respeito a uma organização e sua segurança.

A atribuição de uma geografia do Azure para armazenamento de dados de locatário é feita mapeando o país ou a região selecionado como parte da configuração do locatário do Microsoft Entra para a geografia mais adequada do Azure em que existe uma implantação do Power BI. Depois que essa determinação for feita, todos os dados do cliente do Power BI serão armazenados nessa geografia do Azure selecionada (também conhecida como a área geográfica inicial), exceto nos casos em que as organizações utilizam implantações de várias áreas geográficas.

Várias geografias (multi-geografia)

Algumas organizações têm uma presença global e podem exigir serviços do Power BI em várias regiões geográficas do Azure. Por exemplo, uma empresa pode ter sua sede nos Estados Unidos, mas também pode fazer negócios em outras áreas geográficas, como a Austrália. Nesses casos, a empresa pode exigir que determinados dados do Power BI permaneçam armazenados em repouso na região remota para cumprir as regulamentações locais. Esse recurso do serviço do Power BI é conhecido como multigeográfico.

A camada de execução de consulta, os caches de consulta e os dados de artefato atribuídos a um workspace multigeográfico são hospedados e permanecem na geografia Azure de capacidade remota. No entanto, alguns metadados de artefato, como a estrutura de relatório, podem permanecer armazenados na área geográfica inicial do locatário. Além disso, alguns processamentos e trânsito de dados ainda podem acontecer na localização geográfica inicial do locatário, mesmo para workspaces hospedados em uma capacidade Premium em várias regiões geográficas.

Para obter mais informações sobre como criar e gerenciar implantações que abrangem várias geografias do Azure, consulte Configurar o suporte multigeográfico para o Fabric.

Regiões e datacenters

Os serviços do Power BI estão disponíveis em geografias específicas do Azure, conforme descrito na Central de Confiabilidade da Microsoft. Para obter mais informações sobre onde seus dados são armazenados e como eles são usados, consulte a Central de Confiabilidade da Microsoft. Compromissos sobre o local dos dados em repouso do cliente são especificados nos Termos de Processamento de Dados dos Termos do Microsoft Online Services.

A Microsoft também fornece datacenters para entidades soberanas. Para obter mais informações sobre a disponibilidade do serviço do Power BI para nuvens nacionais/regionais, consulte nuvens nacionais/regionais do Power BI.

Manipulação de dados

Esta seção descreve as práticas de manipulação de dados do Power BI quando se trata de armazenar, processar e transferir dados do cliente.

Dados em repouso

O Power BI usa dois tipos de recursos de armazenamento de dados primários:

  • Armazenamento do Azure
  • Bancos de Dados SQL do Azure

Na maioria dos cenários, o Armazenamento do Azure é utilizado para persistir os dados dos artefatos do Power BI, enquanto os bancos de dados SQL do Azure são usados para persistir os metadados dos artefatos.

Todos os dados persistentes pelo Power BI são criptografados por padrão usando chaves gerenciadas pela Microsoft. Os dados do cliente armazenados nos bancos de dados SQL do Azure são totalmente criptografados usando a tecnologia TDE (transparent data encryption) do SQL do Azure . Os dados do cliente armazenados no Armazenamento de Blobs do Azure são criptografados usando a criptografia do Armazenamento do Azure.

Opcionalmente, as organizações podem utilizar o Power BI Premium para usar suas próprias chaves para criptografar dados em repouso importados para um modelo semântico. Essa abordagem geralmente é descrita como "traga sua própria chave" (BYOK). Usar BYOK ajuda a garantir que, mesmo em caso de erro do operador de serviço, os dados do cliente não sejam expostos – algo que não pode ser obtido facilmente usando criptografia transparente do lado do serviço. Consulte Traga suas próprias chaves de criptografia para o Power BI para ver mais informações.

Os modelos semânticos do Power BI permitem vários modos de conexão de fonte de dados que determinam se os dados da fonte de dados são persistentes no serviço ou não.

Modo de Modelo Semântico (Tipo) Dados persistentes no Power BI
Importação Sim
DirectQuery (Consulta Direta) Não
Live Connect Não
Composto Se houver uma fonte de dados de importação
Transmissão ao vivo Se configurado para persistir

Independentemente do modo de modelo semântico utilizado, o Power BI pode armazenar temporariamente em cache todos os dados recuperados para otimizar o desempenho de carga de consultas e relatórios.

Dados em processamento

Os dados estão em processamento quando estão sendo usados ativamente por um ou mais usuários como parte de um cenário interativo ou quando um processo em segundo plano, como a atualização, toca esses dados. O Power BI carrega dados processados ativamente no espaço de memória de uma ou mais cargas de trabalho de serviço. Para facilitar a funcionalidade exigida pela carga de trabalho, os dados processados na memória não são criptografados.

Dados em trânsito

O Power BI requer que todo o tráfego HTTP de entrada seja criptografado usando o TLS 1.2 ou superior. Quaisquer pedidos que tentem utilizar o serviço com o TLS 1.1 ou inferior serão rejeitados.

Autenticação em fontes de dados

Ao se conectar a uma fonte de dados, um usuário pode optar por importar uma cópia dos dados para o Power BI ou se conectar diretamente à fonte de dados.

No caso de importação, um usuário estabelece uma conexão com base na entrada do usuário e acessa os dados com a credencial. Depois que o modelo semântico é publicado no serviço do Power BI, o Power BI sempre usa a credencial desse usuário para importar dados. Depois que os dados são importados, a exibição dos dados em relatórios e dashboards não acessa a fonte de dados subjacente. O Power BI dá suporte à autenticação de logon único para fontes de dados selecionadas. Se a conexão estiver configurada para usar o logon único, as credenciais do proprietário do modelo semântico serão usadas para se conectar à fonte de dados.

Se uma fonte de dados estiver conectada diretamente usando credenciais pré-configuradas, as credenciais pré-configuradas serão usadas para se conectar à fonte de dados quando qualquer usuário exibir os dados. Se uma fonte de dados estiver conectada diretamente usando autenticação única, as credenciais do usuário atual serão utilizadas para conectar à fonte de dados quando ele visualizar os dados. Quando usado com autenticação única, a segurança em nível de linha (RLS) e/ou a segurança em nível de objeto (OLS) podem ser implementadas na fonte de dados. Isso permite que os usuários exibam apenas os dados que têm privilégios para acessar. Quando a conexão é com fontes de dados na nuvem, a autenticação do Microsoft Entra é usada para logon único; Há suporte para fontes de dados locais, Kerberos, SAML (Security Assertion Markup Language) e Microsoft Entra ID.

Se a fonte de dados for o Azure Analysis Services ou o Analysis Services local e o RLS e/ou OLS estiver configurado, o serviço do Power BI aplicará essa segurança de nível e os usuários que não tiverem credenciais suficientes para acessar os dados subjacentes (que podem ser uma consulta usada em um painel, relatório ou outro artefato de dados) não verão dados para os quais não têm privilégios suficientes.

Recursos premium

Arquitetura de fluxos de dados

Os fluxos de dados fornecem aos usuários a capacidade de configurar operações de processamento de dados de back-end que extrairão dados de fontes de dados polimórficas, executarão a lógica de transformação em relação aos dados e, em seguida, a colocarão em um modelo de destino para uso em várias tecnologias de apresentação de relatórios. Qualquer usuário que tenha uma função de Membro, Colaborador ou Administrador em um workspace criará um fluxo de dados. Os usuários na função Visualizador podem exibir dados processados pelo fluxo de dados, mas podem não fazer alterações em sua composição. Depois que um fluxo de dados tiver sido criado, qualquer membro, colaborador ou administrador do workspace poderá agendar atualizações, bem como exibir e editar o fluxo de dados assumindo a propriedade dele.

Cada fonte de dados configurada está associada a uma tecnologia de cliente para acessar essa fonte de dados. A estrutura de credenciais necessárias para acessá-las é formada para corresponder aos detalhes de implementação necessários da fonte de dados. A lógica de transformação é aplicada pelos serviços do Power Query enquanto os dados estão em trânsito. Para fluxos de dados premium, os serviços do Power Query são executados em nós de back-end. Os dados podem ser extraídos diretamente das fontes de nuvem ou por meio de um gateway instalado no local. Quando extraído diretamente de uma origem na nuvem para o serviço ou para o gateway, o transporte utiliza uma metodologia de proteção específica para a tecnologia do cliente, se aplicável. Quando os dados são transferidos do gateway para o serviço de nuvem, eles são criptografados. Consulte a seção Dados em trânsito acima.

Quando fontes de dados especificadas pelo cliente exigirem credenciais para acesso, o proprietário/criador do fluxo de dados fornecerá essas credenciais durante a criação. Eles são armazenados usando o armazenamento de credenciais padrão em todo o produto. Consulte Autenticação para fontes de dados acima. Há várias abordagens que os usuários podem configurar para otimizar a persistência e o acesso aos dados. Por padrão, os dados são colocados em uma conta de armazenamento protegida e de propriedade do Power BI. A criptografia de armazenamento está habilitada nos contêineres de Blob Storage para proteger os dados em repouso. Veja os dados em repouso abaixo. No entanto, os usuários podem configurar sua própria conta de armazenamento associada à sua própria assinatura do Azure. Ao fazer isso, um Service Principal do Power BI recebe acesso a essa conta de armazenamento para poder gravar os dados lá durante a atualização. Nesse caso, o proprietário do recurso de armazenamento é responsável por configurar a criptografia na conta configurada do Azure Data Lake Storage. Os dados são sempre transmitidos para o Armazenamento de Blobs usando criptografia.

Como o desempenho ao acessar contas de armazenamento pode ser inferior a alguns dados, os usuários também têm a opção de usar um mecanismo de computação hospedado pelo Power BI para aumentar o desempenho. Nesse caso, os dados são armazenados com redundância em um banco de dados SQL que está disponível para o DirectQuery por meio do acesso pelo sistema de back-end do Power BI. Os dados são sempre criptografados no sistema de arquivos. Se o usuário fornecer uma chave para criptografar os dados armazenados no banco de dados SQL, essa chave será usada para criptografá-la duplamente.

Ao consultar usando o DirectQuery, o protocolo de transporte criptografado HTTPS é usado para acessar a API. Todo o uso secundário ou indireto do DirectQuery é controlado pelos mesmos controles de acesso descritos anteriormente. Como os fluxos de dados são sempre associados a um workspace, o acesso aos dados é sempre fechado pela função do usuário nesse workspace. Um usuário deve ter pelo menos acesso de leitura para poder consultar os dados por qualquer meio.

Quando o Power BI Desktop é usado para acessar dados em um fluxo de dados, ele deve primeiro autenticar o usuário usando a ID do Microsoft Entra para determinar se o usuário tem direitos suficientes para exibir os dados. Nesse caso, uma chave SaS é adquirida e usada para acessar o armazenamento diretamente usando o HTTPS do protocolo de transporte criptografado.

O processamento de dados em todo o pipeline emite eventos de auditoria do Office 365. Alguns desses eventos capturarão operações relacionadas à segurança e privacidade.

Relatórios paginados

Os relatórios paginados são projetados para serem impressos ou compartilhados. Eles são chamados de paginados porque são formatados para se ajustarem bem em uma página. Eles exibem todos os dados em uma tabela, mesmo se a tabela abranger várias páginas. Você pode controlar exatamente o layout da página de relatório.

Relatórios paginados dão suporte a expressões avançadas e poderosas escritas no .NET do Microsoft Visual Basic. As expressões são amplamente usadas em todos os relatórios paginados do Construtor de Relatórios do Power BI para recuperar, calcular, exibir, agrupar, classificar, filtrar, parametrizar e formatar dados.

As expressões são criadas pelo autor do relatório com acesso à ampla gama de recursos do .NET Framework. O processamento e a execução de relatórios paginados ocorrem dentro de um sandbox.

As definições de relatório paginado (.rdl) são armazenadas no Power BI e, para publicar e/ou renderizar um relatório paginado, um usuário precisa autenticar e autorizar da mesma forma que descrito na Autenticação para o serviço do Power BI.

O token do Microsoft Entra obtido durante a autenticação é usado para comunicação direta do navegador para o cluster do Power BI Premium.

No Power BI Premium, o runtime do serviço do Power BI fornece um ambiente de execução isolado adequadamente para cada renderização de relatório. Isso inclui casos em que os relatórios que estão sendo renderizados pertencem a workspaces atribuídos à mesma capacidade.

Um relatório paginado pode acessar um amplo conjunto de fontes de dados como parte da renderização do relatório. A sandbox não se comunica diretamente com nenhuma das fontes de dados, mas se comunica com o processo confiável para solicitar dados e, em seguida, o processo confiável acrescenta as credenciais necessárias à conexão. Dessa forma, o sandbox nunca tem acesso a qualquer credencial ou segredo.

Para dar suporte a recursos como Bing Mapas ou chamadas para o Azure Functions, a área restrita tem acesso à Internet.

Análise integrada do Power BI

IsVs (fornecedores de software independentes) e provedores de solução têm dois modos principais de inserção de artefatos do Power BI em seus aplicativos Web e portais: inserir para sua organização e inserir para seus clientes. O artefato é inserido em um IFrame no aplicativo ou portal. Um IFrame não tem permissão para ler ou gravar dados do aplicativo Web externo ou portal, e a comunicação com o IFrame é feita usando o SDK do Cliente do Power BI usando mensagens POST.

Em um incorporação para a organização, os usuários do Microsoft Entra acessam seu próprio conteúdo do Power BI por meio de portais personalizados por suas empresas e seus setores de TI. Todas as políticas e funcionalidades do Power BI descritas neste artigo, como RLS e OLS, são aplicadas automaticamente a todos os usuários independentemente de acessarem o Power BI por meio do portal do Power BI ou por meio de portais personalizados.

Em um cenário de incorporar para seus clientes, os ISVs normalmente possuem instâncias do Power BI e itens do Power BI (dashboards, relatórios, modelos semânticos e outros). É responsabilidade de um serviço de back-end ISV autenticar seus usuários finais e decidir quais artefatos e qual nível de acesso é apropriado para esse usuário final. As decisões de política ISV são criptografadas em um token de inserção gerado pelo Power BI e passadas para o back-end ISV para distribuição adicional aos usuários finais de acordo com a lógica de negócios do ISV. Os usuários finais que usam um navegador ou outros aplicativos cliente não podem descriptografar ou modificar tokens de inserção. SDKs do lado do cliente, como APIs de cliente do Power BI, acrescentam automaticamente o token de incorporação criptografado às solicitações do Power BI como um cabeçalho Authorization: EmbedToken. Com base nesse cabeçalho, o Power BI imporá todas as políticas (como acesso ou RLS) exatamente como foi especificado pelo ISV durante a geração.

Para habilitar a inserção e a automação e gerar os tokens de inserção descritos acima, o Power BI expõe um conjunto avançado de APIs REST. Essas APIs REST do Power BI dão suporte a métodos de autenticação e autorização do Microsoft Entra delegados pelo usuário e à entidade de serviço .

A análise integrada do Power BI e suas APIs REST dão suporte a todos os recursos de isolamento de rede do Power BI descritos neste artigo, incluindo marcas de serviço eLinks Privados.

Recursos de IA

Atualmente, o Power BI dá suporte a duas categorias amplas de recursos de IA no produto atualmente: visuais de IA e enriquecimentos de IA. Os recursos de IA no nível visual incluem funcionalidades como Principais Influenciadores, Árvore de Decomposição, Narrativa Inteligente, Detecção de Anomalias, Visual R, Visual Python, Clustering, Previsão, Q&A, Insights Rápidos, etc. Os recursos de enriquecimento de IA incluem recursos como AutoML, Azure Machine Learning, CognitiveServices, transformações de R/Python etc.

A maioria dos recursos mencionados acima tem suporte em workspaces Compartilhados e Premium atualmente. No entanto, há suporte para AutoML e CognitiveServices somente em workspaces Premium devido a restrições de IP. Hoje, com a integração do AutoML no Power BI, um usuário pode criar e treinar um modelo de ML (machine learning personalizado) (por exemplo, Previsão, Classificação, Regressão etc.) e aplicá-lo para obter previsões ao carregar dados em um fluxo de dados definido em um workspace Premium. Além disso, os usuários do Power BI podem aplicar várias APIs de CognitiveServices, como TextAnalytics e ImageTagging, para transformar dados antes de carregá-los em um modelo semântico/fluxo de dados definido em um workspace Premium.

Os recursos de enriquecimento de IA Premium podem ser melhor vistos como uma coleção de funções/transformações de IA sem estado que podem ser usadas pelos usuários do Power BI em seus pipelines de integração de dados usados por um modelo semântico ou fluxo de dados do Power BI. Observe que essas funções também podem ser acessadas de ambientes atuais de criação de modelo semântico/fluxo de dados no serviço do Power BI e no Power BI Desktop. Essas funções/transformações de IA sempre são executadas em um workspace/capacidade Premium. Essas funções são exibidas no Power BI como uma fonte de dados que requer um token do Microsoft Entra para o usuário do Power BI que está usando a função de IA. Essas fontes de dados de IA são especiais porque não expõem seus próprios dados e fornecem apenas essas funções e transformações. Durante a execução, esses recursos não fazem chamadas de saída para outros serviços para transmitir os dados do cliente. Vamos examinar os cenários Premium individualmente para entender os padrões de comunicação e os detalhes relevantes relacionados à segurança relativos a eles.

Para treinar e aplicar um modelo AutoML, o Power BI usa o SDK do Azure AutoML e executa todo o treinamento na capacidade do Power BI do cliente. Durante as iterações de treinamento, o Power BI chama um serviço de experimentação do Azure Machine Learning para selecionar um modelo e hipermetrâmetros adequados para a iteração atual. Nesta chamada de saída, somente metadados de experimento relevantes (por exemplo, precisão, algoritmo ml, parâmetros de algoritmo etc.) da iteração anterior são enviados. O treinamento do AutoML produz um modelo ONNX e dados de relatório de treinamento que são salvos no fluxo de dados. Posteriormente, os usuários do Power BI poderão aplicar o modelo de ML treinado como uma transformação para operacionalizar o modelo de ML de forma agendada. Para APIs TextAnalytics e ImageTagging, o Power BI não chama diretamente as APIs do serviço CognitiveServices, mas sim utiliza um SDK interno para executar as APIs na capacidade premium do Power BI. Hoje, essas APIs têm suporte em fluxos de dados do Power BI e modelos semânticos. Ao criar um modelo de dados no Power BI Desktop, os usuários só poderão acessar essa funcionalidade se tiverem acesso a um workspace premium do Power BI. Portanto, os clientes são solicitados a fornecer suas credenciais do Microsoft Entra.

Isolamento da rede

Esta seção descreve os recursos avançados de segurança no Power BI. Alguns dos recursos têm requisitos de licenciamento específicos. Confira as seções abaixo para obter detalhes.

Etiquetas de serviço

Uma marca de serviço representa um grupo de prefixos de endereço IP de um determinado serviço do Azure. Ele ajuda a minimizar a complexidade das atualizações frequentes para as regras de segurança de rede. Os clientes podem usar marcas de serviço para definir controles de acesso à rede em grupos de segurança de rede ou no Firewall do Azure. Os clientes podem usar marcas de serviço no lugar de endereços IP específicos ao criar regras de segurança. Ao especificar o nome da marca de serviço (como PowerBI) no campo de origem ou destino apropriado (para APIs) de uma regra, os clientes podem permitir ou negar o tráfego para o serviço correspondente. A Microsoft gerencia os prefixos de endereço abrangidos pela marca de serviço e atualiza automaticamente a marca de serviço à medida que os endereços são alterados.

A rede do Azure fornece o recurso de Link Privado do Azure que permite ao Power BI fornecer acesso seguro por meio de pontos de extremidade privados da Rede do Azure. Com o Link Privado do Azure e pontos de extremidade privados, o tráfego de dados é enviado privadamente usando a infraestrutura de rede de backbone da Microsoft e, portanto, os dados não atravessam a Internet.

O Link Privado garante que os usuários do Power BI usem o backbone de rede privada da Microsoft ao acessar recursos no serviço do Power BI.

O uso do Link Privado com o Power BI oferece os seguintes benefícios:

  • O Link Privado garante que o tráfego flua pelo backbone do Azure para um ponto de extremidade privado para recursos baseados em nuvem do Azure.
  • O isolamento de tráfego de rede da infraestrutura não baseada no Azure, como o acesso local, exigiria que os clientes tivessem o ExpressRoute ou uma VPN configurada.

Consulte links privados para obter acesso seguro ao Fabric para obter informações adicionais.

Conectividade VNet

Embora o recurso de integração do Link Privado forneça conexões de entrada seguras ao Power BI, o recurso de conectividade VNet permite a conectividade de saída segura do Power BI para fontes de dados em uma VNet.

Os gateways de VNet (gerenciados pela Microsoft) eliminam a sobrecarga de instalar e monitorar gateways de dados locais para se conectar a fontes de dados associadas a uma VNet. No entanto, eles ainda seguem o processo familiar de gerenciamento de fontes de dados e segurança, como acontece com um gateway de dados local.

Veja a seguir uma visão geral do que acontece quando você interage com um relatório do Power BI conectado a uma fonte de dados em uma VNet usando gateways de VNet:

  1. O serviço de nuvem do Power BI (ou um dos outros serviços de nuvem com suporte) inicia uma consulta e envia a consulta, os detalhes da fonte de dados e as credenciais para o serviço VNet (VNet pp) do Power Platform.

  2. O serviço de VNet PP injeta com segurança um contêiner executando um gateway de VNet na sub-rede. Esse contêiner agora pode se conectar a serviços de dados acessíveis nessa sub-rede.

  3. Em seguida, o serviço de PP VNet envia a consulta, os detalhes da fonte de dados e as credenciais para o gateway de VNet.

  4. O gateway de VNet obtém a consulta e se conecta às fontes de dados com essas credenciais.

  5. Em seguida, a consulta é enviada à fonte de dados para execução.

  6. Após a execução, os resultados são enviados para o gateway de VNet e o serviço de VNet pp envia com segurança os dados do contêiner para o serviço de nuvem do Power BI.

Entidades de serviço

O Power BI dá suporte ao uso de entidades de serviço. Armazene quaisquer credenciais do principal de serviço usadas para criptografar ou acessar o Power BI em um Key Vault, atribua políticas de acesso adequadas ao cofre e revise regularmente as permissões de acesso.

Consulte Automatizar tarefas de modelo semântico e workspace Premium com entidades de serviço para obter detalhes adicionais.

Microsoft Purview para Power BI

Proteção de Informações do Microsoft Purview

O Power BI está profundamente integrado à Proteção de Informações do Microsoft Purview. A Proteção de Informações do Microsoft Purview permite que as organizações tenham uma única solução integrada para classificação, rotulagem, auditoria e conformidade no Azure, Power BI e Office.

Quando a proteção de informações estiver habilitada no Power BI:

  • Dados confidenciais, tanto no serviço do Power BI quanto no Power BI Desktop, podem ser classificados e rotulados usando os mesmos rótulos de confidencialidade usados no Office e no Azure.
  • As políticas de governança podem ser impostas quando o conteúdo do Power BI é exportado para arquivos excel, PowerPoint, PDF, Word ou .pbix , para ajudar a garantir que os dados sejam protegidos mesmo quando saem do Power BI.
  • É fácil classificar e proteger arquivos .pbix no Power BI Desktop, assim como é feito em aplicativos do Excel, Word e PowerPoint. Os arquivos podem ser facilmente marcados de acordo com seu nível de confidencialidade. Além disso, eles poderão ser criptografados se contiverem dados confidenciais comerciais, garantindo que somente usuários autorizados possam editar esses arquivos.
  • As pastas de trabalho do Excel herdam automaticamente rótulos de sensibilidade quando se conectam ao Power BI, permitindo manter a classificação de ponta a ponta e aplicar proteção na análise de modelos semânticos do Power BI no Excel.
  • Os rótulos de confidencialidade aplicados a relatórios e dashboards do Power BI são visíveis nos aplicativos móveis do Power BI para iOS e Android.
  • Os rótulos de confidencialidade persistem quando um relatório do Power BI é inserido no Teams, no SharePoint ou em um site seguro. Isso ajuda as organizações a manter a classificação e a proteção durante a exportação ao inserir conteúdo do Power BI.
  • A herança do rótulo após a criação de um novo conteúdo no serviço do Power BI garante que os rótulos aplicados a modelos semânticos ou datamarts no serviço do Power BI sejam aplicados a novos conteúdos criados sobre esses modelos semânticos e datamarts.
  • As APIs de verificação de administrador do Power BI podem extrair o rótulo de confidencialidade de um item do Power BI, permitindo que os administradores do Power BI e do InfoSec monitorem a rotulagem no serviço do Power BI e produzam relatórios executivos.
  • As APIs de administrador do Power BI permitem que as equipes centrais apliquem programaticamente rótulos de confidencialidade ao conteúdo no serviço do Power BI.
  • As equipes centrais podem criar políticas de rótulo obrigatórias para impor a aplicação de rótulos em conteúdo novo ou editado no Power BI.
  • As equipes centrais podem criar políticas de rótulo padrão para garantir que um rótulo de confidencialidade seja aplicado a todo o conteúdo novo ou alterado do Power BI.
  • A rotulagem automática de sensibilidade downstream no serviço do Power BI garante que, quando um rótulo em um modelo semântico ou datamart for aplicado ou alterado, o rótulo será automaticamente aplicado ou alterado em todo o conteúdo subsequente conectado ao modelo semântico ou datamart.

Para obter mais informações, consulte rótulos de confidencialidade no Power BI.

Políticas de Prevenção contra Perda de Dados do Microsoft Purview (DLP) para o Power BI

As políticas de DLP (Prevenção contra Perda de Dados) do Microsoft Purview ajudam as organizações a reduzir o risco de vazamento de dados comerciais confidenciais do Power BI. As políticas de DLP os ajudam a atender aos requisitos de conformidade das regulamentações governamentais ou do setor, como o GdpR (Regulamento Geral de Proteção de Dados) da União Europeia ou a Lei de Privacidade do Consumidor da Califórnia (CCPA) e garantir que seus dados no Power BI sejam gerenciados.

Quando as políticas DLP para o Power BI são configuradas:

  • Todos os modelos semânticos nos workspaces especificados na política são avaliados pela política.
  • Você pode detectar quando dados confidenciais são carregados em suas capacidades Premium. As políticas DLP podem detectar:
    • Rótulos de confidencialidade.
    • Tipos de informações confidenciais. Há suporte para mais de 260 tipos. A detecção de tipo de informações confidenciais depende da verificação de conteúdo do Microsoft Purview.
  • Quando você encontra um modelo semântico identificado como confidencial, você pode ver uma dica de política personalizada que ajuda a entender o que você deve fazer.
  • Se você for um proprietário de modelo semântico, poderá substituir uma política e impedir que seu modelo semântico seja identificado como "sensível" se você tiver um motivo válido para fazer isso.
  • Se você for um proprietário de modelo semântico, poderá relatar um problema com uma política se concluir que um tipo de informação confidencial foi identificado falsamente.
  • Mitigações automáticas de risco, como alertas para o administrador de segurança, podem ser invocadas.

Para obter mais informações, consulte políticas de prevenção contra perda de dados para o Fabric e o Power BI.

Microsoft Defender para Aplicativos de Nuvem para Power BI

O Microsoft Defender para Aplicativos de Nuvem é um dos principais agentes de segurança de acesso à nuvem do mundo, nomeado como líder no Quadrante Mágico do Gartner para o mercado casb (agente de segurança de acesso à nuvem). O Defender para Aplicativos de Nuvem é usado para proteger o uso de aplicativos de nuvem. Ele permite que as organizações monitorem e controlem, em tempo real, sessões arriscadas do Power BI, como o acesso do usuário de dispositivos não gerenciados. Os administradores de segurança podem definir políticas para controlar as ações do usuário, como baixar relatórios com informações confidenciais.

Com o Defender para Aplicativos de Nuvem, as organizações podem obter os seguintes recursos de DLP:

  • Defina controles em tempo real para impor sessões de usuário arriscadas no Power BI. Por exemplo, se um usuário se conectar ao Power BI de fora de seu país ou região, a sessão poderá ser monitorada pelos controles em tempo real do Defender para Aplicativos de Nuvem e ações arriscadas, como baixar dados marcados com um rótulo de confidencialidade "Altamente Confidencial", poderão ser bloqueadas imediatamente.
  • Investigue a atividade do usuário do Power BI com o log de atividades do Defender para Aplicativos de Nuvem. O log de atividades do Defender para Aplicativos de Nuvem inclui a atividade do Power BI capturada no log de auditoria do Office 365, que contém informações sobre todas as atividades de usuário e administrador, bem como informações de rótulo de confidencialidade para atividades relevantes, como aplicar, alterar e remover rótulo. Os administradores podem aproveitar os filtros avançados do Defender para Aplicativos de Nuvem e as ações rápidas para uma investigação de problemas eficaz.
  • Crie políticas personalizadas para alertar sobre atividades suspeitas do usuário no Power BI. O recurso de política de atividade do Defender para Aplicativos de Nuvem pode ser aproveitado para definir suas próprias regras personalizadas, para ajudá-lo a detectar o comportamento do usuário que se desvia da norma e até mesmo possivelmente agir sobre ela automaticamente, se parecer muito perigoso.
  • Trabalhe com a detecção de anomalias integrada do Defender para Aplicativos de Nuvem. As políticas de detecção de anomalias do Defender para Aplicativos de Nuvem fornecem análise de comportamento do usuário e aprendizado de máquina sem necessidade de configuração adicional, para que você esteja preparado desde o começo para executar a detecção avançada de ameaças em seu ambiente de nuvem. Quando uma política de detecção de anomalias identifica um comportamento suspeito, ela dispara um alerta de segurança.
  • Função de administrador do Power BI no portal do Defender para Aplicativos de Nuvem. O Defender para Aplicativos de Nuvem fornece uma função de administrador específica do aplicativo que pode ser usada para conceder aos administradores do Power BI apenas as permissões necessárias para acessar dados relevantes do Power BI no portal, como alertas, usuários em risco, logs de atividades e outras informações relacionadas ao Power BI.

Para obter mais detalhes, consulte Como usar controles do Microsoft Defender para Aplicativos de Nuvem no Power BI.

Perguntas e respostas de segurança do Power BI

As perguntas a seguir são perguntas e respostas comuns de segurança para o Power BI. Eles são organizados com base em quando foram adicionados a este white paper, para facilitar sua capacidade de encontrar rapidamente novas perguntas e respostas quando este artigo é atualizado. As perguntas mais recentes são adicionadas ao final dessa lista.

Como os usuários se conectam e obtêm acesso a fontes de dados ao usar o Power BI?

  • O Power BI gerencia credenciais para fontes de dados para cada usuário para credenciais de nuvem ou para conectividade por meio de um gateway pessoal. As fontes de dados gerenciadas por um gateway de dados local podem ser compartilhadas em toda a empresa e as permissões para essas fontes de dados podem ser gerenciadas pelo administrador do gateway. Ao configurar um modelo semântico, o usuário tem permissão para selecionar uma credencial em seu repositório pessoal ou usar um gateway de dados local para usar uma credencial compartilhada.

    No caso de importação, um usuário estabelece uma conexão com base na entrada do usuário e acessa os dados com a credencial. Depois que o modelo semântico é publicado no serviço do Power BI, o Power BI sempre usa a credencial desse usuário para importar dados. Depois que os dados são importados, a exibição dos dados em relatórios e dashboards não acessa a fonte de dados subjacente. O Power BI dá suporte à autenticação de logon único para fontes de dados selecionadas. Se a conexão estiver configurada para usar o logon único, a credencial do proprietário do modelo semântico será usada para se conectar à fonte de dados.

    Para relatórios conectados ao DirectQuery, a fonte de dados é conectada diretamente usando uma credencial pré-configurada. A credencial pré-configurada é usada para se conectar à fonte de dados quando qualquer usuário exibe os dados. Se uma fonte de dados estiver conectada diretamente usando o logon único, a credencial do usuário atual será usada para se conectar à fonte de dados quando o usuário exibir os dados. Ao usar com logon único, o RLS e/ou o OLS podem ser implementados na fonte de dados e isso permite que os usuários exibam dados que têm privilégios para acessar. Quando a conexão é com fontes de dados na nuvem, a autenticação do Microsoft Entra é usada para logon único; Há suporte para fontes de dados locais, Kerberos, SAML e Microsoft Entra ID.

    Ao se conectar ao Kerberos, o UPN do usuário é passado para o gateway e, usando a Delegação Restrita do Kerberos, o usuário é representado e conectado às respectivas fontes de dados. O SAML também tem suporte na fonte de dados do Gateway para SAP HANA. Mais informações estão disponíveis na visão geral da autenticação única para gateways.

    Se a fonte de dados for o Azure Analysis Services ou o Analysis Services local e o RLS e/ou OLS estiver configurado, o serviço do Power BI aplicará essa segurança de nível e os usuários que não tiverem credenciais suficientes para acessar os dados subjacentes (que podem ser uma consulta usada em um painel, relatório ou outro artefato de dados) não verão dados para os quais o usuário não tem privilégios suficientes.

    O RLS com o Power BI pode ser usado para restringir o acesso a dados para determinados usuários. Os filtros restringem o acesso a dados no nível da linha e você pode definir filtros dentro de uma função.

    O OLS pode ser usado para proteger tabelas ou colunas confidenciais. No entanto, ao contrário do RLS, o OLS também protege os nomes e metadados de objetos. Isso ajuda a impedir que usuários mal-intencionados descubram até mesmo a existência desses objetos. Tabelas e colunas protegidas são obscurecidas na lista de campos ao usar ferramentas de relatório como Excel ou Power BI e, além disso, os usuários sem permissões não podem acessar objetos de metadados protegidos via DAX ou qualquer outro método. Do ponto de vista dos usuários sem permissões de acesso adequadas, tabelas e colunas protegidas simplesmente não existem.

    O OLS, juntamente com o RLS, permite uma segurança avançada de nível empresarial em relatórios e modelos semânticos, garantindo que apenas os usuários com as permissões necessárias tenham acesso para exibir e interagir com dados confidenciais.

Como os dados são transferidos para o Power BI?

  • Todos os dados solicitados e transmitidos pelo Power BI são criptografados em trânsito usando HTTPS (exceto quando a fonte de dados escolhida pelo cliente não dá suporte a HTTPS) para se conectar da fonte de dados ao serviço do Power BI. Uma conexão segura é estabelecida com o provedor de dados e somente quando essa conexão for estabelecida os dados percorrerão a rede.

Como o Power BI armazena em cache dados de relatório, painel ou modelo e é seguro?

Os clientes armazenam dados da página da Web em cache localmente?

  • Quando os clientes do navegador acessam o Power BI, os servidores Web do Power BI definem a diretiva Cache-Controlcomo não armazenado. A diretiva no-store instrui os navegadores a não armazenar em cache a página da Web que está sendo exibida pelo usuário e não armazenar a página da Web na pasta de cache do cliente.

E quanto à segurança baseada em função, compartilhamento de relatórios ou dashboards e conexões de dados? Como isso funciona em termos de acesso a dados, exibição de dashboard, acesso a relatórios ou atualização?

  • Para fontes de dados não habilitadas para RLS , se um painel, um relatório ou um modelo de dados for compartilhado com outros usuários por meio do Power BI, os dados estarão disponíveis para usuários com os quais são compartilhados para exibir e interagir. O Power BI não autentica novamente os usuários na fonte original dos dados; depois que os dados são carregados no Power BI, o usuário que se autenticou nos dados de origem é responsável por gerenciar quais outros usuários e grupos podem exibir os dados.

    Quando conexões de dados são feitas a uma fonte de dados compatível com RLS , como uma fonte de dados do Analysis Services, somente os dados do painel são armazenados em cache no Power BI. Sempre que um relatório ou modelo semântico é exibido ou acessado no Power BI que usa dados da fonte de dados compatível com RLS, o serviço do Power BI acessa a fonte de dados para obter dados com base nas credenciais do usuário e, se houver permissões suficientes, os dados serão carregados no relatório ou no modelo de dados desse usuário. Se a autenticação falhar, o usuário verá um erro.

    Para obter mais informações, consulte Autenticação para fontes de dados.

Nossos usuários se conectam às mesmas fontes de dados o tempo todo, algumas das quais exigem credenciais que diferem de suas credenciais de domínio. Como eles podem evitar ter que inserir essas credenciais sempre que fazem uma conexão de dados?

  • O Power BI oferece o Gateway Pessoal do Power BI, que é um recurso que permite que os usuários criem credenciais para várias fontes de dados diferentes e, em seguida, usem automaticamente essas credenciais ao acessar cada uma dessas fontes de dados. Para obter mais informações, consulte Usar um gateway pessoal no Power BI.

Quais portas são usadas por um gateway de dados local e um gateway pessoal? Há nomes de domínio que precisam ser permitidos para fins de conectividade?

Ao trabalhar com o gateway de dados local, como as chaves de recuperação são usadas e onde elas são armazenadas? E o gerenciamento seguro de credenciais?

  • Durante a instalação e a configuração do gateway, o administrador insere uma chave de recuperação do gateway. Essa chave de recuperação é usada para gerar uma chave simétrica AES forte. Uma chave assimétrica RSA também é criada ao mesmo tempo.

    Essas chaves geradas (RSA e AES) são armazenadas em um arquivo localizado no computador local. Esse arquivo também é criptografado. O conteúdo do arquivo só pode ser descriptografado por esse computador Windows específico e apenas por essa conta de serviço de gateway específica.

    Quando um usuário insere credenciais de fonte de dados na interface do usuário do serviço do Power BI, as credenciais são criptografadas com a chave pública no navegador. O gateway descriptografa as credenciais usando a chave privada RSA e as criptografa novamente com uma chave simétrica do AES antes que os dados sejam armazenados no serviço do Power BI. Com esse processo, o serviço do Power BI nunca tem acesso aos dados não criptografados.

Quais protocolos de comunicação são usados pelo gateway de dados local e como eles são protegidos?

  • O gateway dá suporte aos dois protocolos de comunicação a seguir:

    • AMQP 1.0 – TCP + TLS: este protocolo requer que as portas 443, 5671-5672 e 9350-9354 sejam abertas para comunicação de saída. Esse protocolo é preferencial, pois tem uma sobrecarga de comunicação menor.

    • HTTPS – WebSockets via HTTPS + TLS: este protocolo usa apenas a porta 443. O WebSocket é iniciado por uma única mensagem HTTP CONNECT. Depois que o canal é estabelecido, a comunicação é essencialmente TCP+TLS. Você pode forçar o gateway a usar esse protocolo modificando uma configuração descrita no artigo do gateway local.

Qual é a função da CDN do Azure no Power BI?

  • Conforme mencionado anteriormente, o Power BI usa a CDN do Azure para distribuir com eficiência o conteúdo estático e os arquivos necessários aos usuários com base na localidade geográfica. Para entrar em detalhes, o serviço do Power BI usa várias CDNs para distribuir com eficiência o conteúdo estático e os arquivos necessários aos usuários por meio da Internet pública. Esses arquivos estáticos incluem downloads de produtos (como o Power BI Desktop, o gateway de dados local ou aplicativos do Power BI de vários ISVs), arquivos de configuração do navegador usados para iniciar e estabelecer quaisquer conexões subsequentes com o serviço do Power BI, bem como a página de entrada segura inicial do Power BI.

    Com base nas informações fornecidas durante uma conexão inicial com o serviço do Power BI, o navegador de um usuário entra em contato com a CDN do Azure especificada (ou para alguns arquivos, o WFE) para baixar a coleção de arquivos comuns especificados necessários para habilitar a interação do navegador com o serviço do Power BI. Em seguida, a página do navegador inclui o token do Microsoft Entra, as informações de sessão, o local do cluster de back-end associado e a coleção de arquivos baixados da CDN do Azure e do cluster WFE, durante a sessão do navegador do serviço do Power BI.

Para visuais do Power BI, a Microsoft executa qualquer avaliação de segurança ou privacidade do código visual personalizado antes de publicar itens na Galeria?

  • Não. É responsabilidade do cliente examinar e determinar se o código visual personalizado deve ser confiado. Todo o código visual personalizado é operado em um ambiente de área restrita, de modo que qualquer código errante em um visual personalizado não afete negativamente o restante do serviço do Power BI.

Há outros visuais do Power BI que enviam informações fora da rede do cliente?

  • Sim. Os visuais do Bing Mapas e ESRI transmitem dados do serviço do Power BI para aqueles que utilizam essas ferramentas.

Para aplicativos de modelo, a Microsoft executa qualquer avaliação de segurança ou privacidade do aplicativo de modelo antes de publicar itens na Galeria?

  • Não. O editor de aplicativos é responsável pelo conteúdo enquanto é responsabilidade do cliente examinar e determinar se deseja confiar no editor de aplicativos de modelo.

Há aplicativos de modelo que podem enviar informações fora da rede do cliente?

  • Sim. É responsabilidade do cliente examinar a política de privacidade do editor e determinar se o aplicativo modelo deve ser instalado no ambiente do usuário. O editor é responsável por informar o cliente sobre o comportamento e os recursos do aplicativo.

E a soberania de dados? Podemos provisionar locatários em datacenters localizados em geografias específicas para garantir que os dados não saiam das fronteiras do país ou da região?

  • Alguns clientes em determinadas geografias têm a opção de criar um locatário em uma nuvem nacional/regional, em que o armazenamento e o processamento de dados são mantidos separados de todos os outros datacenters. As nuvens nacionais/regionais têm um tipo de segurança ligeiramente diferente, já que um administrador de dados separado opera o serviço nacional/regional do Power BI em nome da Microsoft.

    Como alternativa, os clientes também podem configurar um inquilino em uma região específica. No entanto, esses locatários não têm um administrador de dados separado da Microsoft. Os preços das nuvens nacionais/regionais são diferentes dos do serviço comercial do Power BI geralmente disponível. Para obter mais informações sobre a disponibilidade do serviço do Power BI para nuvens nacionais/regionais, consulte nuvens nacionais/regionais do Power BI.

Como a Microsoft trata as conexões para clientes que têm assinaturas do Power BI Premium? Essas conexões são diferentes das estabelecidas para o serviço do Power BI não Premium?

  • As conexões estabelecidas para clientes com assinaturas do Power BI Premium implementam um processo de autorização do Microsoft Entra entre empresas (B2B), usando a ID do Microsoft Entra para habilitar o controle de acesso e a autorização. O Power BI lida com conexões de assinantes do Power BI Premium com recursos do Power BI Premium da mesma forma que qualquer outro usuário do Microsoft Entra.

Como funciona a autenticação do lado do servidor no WFE?

  • A autenticação do usuário pelo serviço, conforme descrito na sequência de etapas a seguir, é ilustrada na imagem que vem depois.

  1. Um usuário inicia uma conexão com o serviço do Power BI a partir de um navegador, digitando o endereço do Power BI na barra de endereços ou selecionando Entrar na página de marketing do Power BI (https://powerbi.microsoft.com). A conexão é estabelecida usando TLS 1.2 e HTTPS, e toda a comunicação subsequente entre o navegador e o serviço do Power BI usa HTTPS.

  2. O Gerenciador de Tráfego do Azure verifica o registro DNS do usuário para determinar o datacenter mais apropriado (geralmente mais próximo) em que o Power BI é implantado e responde ao DNS com o endereço IP do cluster WFE para o qual o usuário deve ser enviado.

  3. Em seguida, o WFE redireciona o usuário para a página de entrada dos Serviços Online da Microsoft.

  4. Depois que o usuário for autenticado, a página de entrada redirecionará o usuário para o cluster WFE do serviço do Power BI mais próximo previamente determinado com um código de autenticação.

  5. O cluster WFE verifica com a Microsoft Entra ID para obter um token de segurança do Microsoft Entra usando o código de autorização. Quando o Microsoft Entra ID autentica o usuário com sucesso e retorna um token de segurança do Microsoft Entra, o cluster WFE consulta o Power BI Global Service, que mantém uma lista de tenants e as localizações dos clusters de back-end do Power BI, e determina qual cluster de serviço de back-end do Power BI contém o tenant do usuário. Em seguida, o cluster WFE retorna uma página de aplicativo para o navegador do usuário com as informações de sessão, acesso e roteamento necessárias para sua operação.

  6. Agora, quando o navegador do cliente requerer dados do cliente, ele enviará solicitações para o endereço do cluster de back-end com o token de acesso do Microsoft Entra no cabeçalho de autorização. O cluster de back-end do Power BI lê o token de acesso do Microsoft Entra e valida a assinatura para garantir que a identidade da solicitação seja válida. O token de acesso do Microsoft Entra terá uma data de expiração definida de acordo com as políticas do Microsoft Entra e, para manter a sessão atual, o Cliente do Power BI no navegador do usuário fará solicitações periódicas para renovar o token de acesso antes de expirar.

Diagrama mostrando a sequência de Autenticação WFE.

Recursos adicionais

Para obter mais informações sobre o Power BI, consulte os recursos a seguir.