White paper de segurança do Power BI

Resumo: O Power BI é uma oferta de serviço de software online (SaaS ou Software como Serviço) da Microsoft que permite criar painéis, relatórios, modelos semânticos e visualizações de Business Intelligence de autoatendimento de maneira fácil e rápida. Com o Power BI, você pode se conectar a várias fontes de dados diferentes, combinar e moldar os dados usando essas conexões e criar relatórios e dashboards que podem 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 e Sergei Gundorov

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

Introdução

O Power BI é uma oferta de serviço de software online (SaaS, ou Software como Serviço) da Microsoft que permite criar dashboards, relatórios, modelos semânticos e visualizações de Business Intelligence de autoatendimento de forma fácil e rápida. Com o Power BI, você pode se conectar a várias fontes de dados diferentes, combinar e moldar os dados usando essas conexões e criar relatórios e dashboards que podem 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 dos clientes 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.

As bases 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ária na era da nuvem. Em vez disso, as organizações devem procurar uma solução de segurança nativa de nuvem, de várias camadas e de defesa em profundidade para seus dados de business intelligence.

O Power BI foi criado para fornecer proteção completa e hermética líder do setor 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 serviços de saúde confiam a ele 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 grandes investimentos para resolver suas vulnerabilidades de segurança e, nas décadas seguintes, criou uma pilha de segurança forte que vai tão fundo quanto o kernel de bios do computador on-chip e estende todo o caminho 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 no enfrentamento proativo 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 se baseia 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 se integra às ferramentas mais avançadas de proteção de informações e conformidade do Microsoft 365. Além disso, ele 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 do produto 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 eles são criptografados? Quais controles tenho em meus dados?
• Como fazer controlar e proteger meus dados confidenciais? Como fazer garantir que esses dados não possam vazar fora da organização?
• Como fazer auditar quem realiza quais operações? Como fazer reagir rapidamente se houver 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 fluxos de main 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 pelo serviço. A última seção discute os recursos de segurança que permitem que você, como administrador de serviços, proteja seus ativos mais valiosos.

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

O serviço do Power BI segue o SDL (Security Development Lifecycle), práticas de segurança estritas 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 Power BI foi desenvolvido no Azure, a plataforma de computação em nuvem da Microsoft. O Power BI atualmente está implantado em muitos datacenters em todo o mundo – há muitas implantações ativas disponibilizadas para clientes nessas regiões atendidas por esses datacenters, e um número igual de implantações passivas que servem como backups para cada implantação ativa.

Cluster de front-end da Web (WFE)

O cluster WFE fornece ao navegador do usuário o conteúdo inicial da página HTML no carregamento do site e ponteiros para o conteúdo da CDN usado para renderizar o site no navegador.

Um cluster WFE consiste em um site de ASP.NET em execução no ambiente de 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 o mais próximo) com uma implantação do Power BI. Para obter mais informações sobre esse processo, veja 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 (Rede de Distribuição de Conteúdo) 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 em conformidade para hospedar conteúdo estático.

Cluster de back-end do Power BI (BE)

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 de Front-End e API da Web, 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 à medida que 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 é chamado de cluster inicial do locatário. As informações de cluster inicial de um usuário autenticado são fornecidas pelo Serviço Global e usadas pelo Front-End da Web 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 conjuntos de dimensionamento redimensionáveis ajustados para executar tarefas específicas, recursos com estado, como bancos de dados SQL, contas de armazenamento, barramentos de serviço, caches e outros componentes de nuvem necessários.

Os metadados e os dados do locatário são armazenados dentro dos limites de cluster, exceto para replicação de dados para um cluster de back-end secundário em uma região emparelhada do Azure na mesma geografia do Azure. O cluster de back-end secundário serve como um cluster de failover em caso de interrupção regional e é passivo em qualquer outro momento.

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

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

Infraestrutura de Power BI Premium

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

Os recursos do Power BI Premium são hospedados em clusters de back-end que são independentes do back-end regular do Power BI (veja acima). Isso fornece melhor isolamento, alocação de recursos, capacidade de suporte, isolamento de segurança e escalabilidade da oferta Premium.

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

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

A infraestrutura Power BI Premium em uma região do Azure consiste em vários clusters 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 de cluster estiverem se aproximando de seus limites).

O backbone de cada cluster são recursos de computação gerenciados pelo Conjuntos de Dimensionamento de Máquinas Virtuais e pelo Azure Service Fabric. 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 cresce e orquestra a implantação, o gerenciamento e o monitoramento de serviços e aplicativos de 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 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 a Power BI Premium infraestrutura 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 de front-end autenticam a solicitação, lidam com ela ou a encaminham para os recursos apropriados (por exemplo, nós de back-end).

Os nós de back-end fornecem a maioria dos recursos e funcionalidades 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 móveis do Power BI se enquadram em duas categorias:

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

Para a comunicação do 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 abrem uma sessão de navegador dentro do próprio aplicativo, enquanto o aplicativo móvel do Windows abre um corretor para estabelecer o canal de comunicação com o Power BI (para o processo de login).

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

Suporte a CBA	iOS	Android	Windows
Power BI (entre no serviço)	Com suporte	Compatível	Sem suporte
SSRS ADFS no local (conecte-se ao servidor SSRS)	Sem suporte	Com suporte	Sem suporte
Proxy de Aplicativo SSRS	Com suporte	Compatível	Sem suporte

Aplicativos do Power BI Mobile ativamente comunicam-se 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 a serviços usados para monitorar o uso e a atividade; nenhum dado do cliente é enviado com a telemetria.

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

• O Microsoft Entra ID e os tokens de atualização são armazenados em um mecanismo seguro no dispositivo, usando medidas de segurança padrão do setor.
• Os dados e as configurações (pares chave-valor para a configuração do usuário) são armazenados em cache 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 definido 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 área restrita e armazenamento interno acessível apenas para o aplicativo. Para o aplicativo do Windows, os dados só podem ser acessados pelo usuário (e pelo administrador do sistema).
• A geolocalização é habilitada ou desabilitada explicitamente pelo usuário. Se habilitados, os dados de geolocalização não serão salvos no dispositivo e não serão compartilhados com a Microsoft.
• As notificações são habilitadas ou desabilitadas explicitamente pelo usuário. Se habilitados, Android e iOS não dão suporte a requisitos de residência de dados geográficos para notificações.

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

O aplicativo windows também dá suporte ao WINDOWS Proteção de Informações (WIP).

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 Biblioteca de Autenticação da Microsoft (MSAL).

Os dados 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 não consegue fazer login (como após um evento de expiração de token ou alteração de senha). O cache de dados inclui dashboards e relatórios acessados anteriormente por meio do aplicativo Power BI Mobile.

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

Os aplicativos do Power BI para iOS e Android permitem que você proteja seus dados configurando identificação adicional, como fornecer id facial, ID de toque ou senha para iOS e dados biométricos (ID de 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 para o 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 do 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 os 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 as 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 o mais próximo) onde o Power BI está 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 é autenticado, a página de entrada redireciona 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. A ID de locatário do usuário é usada pelo cliente do navegador para consultar o Serviço Global do Power BI, que mantém uma lista de locatários e seus locais 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. O cliente agora é capaz de se comunicar com a API de URL do cluster de back-end do Power BI, usando o token de acesso no cabeçalho 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 que ele expire.

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

Residência de dadosResidência de dados

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

A atribuição de uma área geográfica do Azure para armazenamento de dados de locatário é feita mapeando o país/região selecionado como parte da configuração do locatário do Microsoft Entra para a área geográfica 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 área geográfica inicial), exceto nos casos em que as organizações utilizam implantações multigeográficos.

Múltiplas Áreas Geográficas (multi-geo)

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 área geográfica do Azure de capacidade remota. No entanto, alguns metadados de artefato, como a estrutura de relatório, podem permanecer armazenados em repouso na área geográfica inicial do locatário. Além disso, alguns tráfegos de dados e processamento ainda podem ocorrer na área geográfica inicial do locatário, mesmo para workspaces hospedados em uma capacidade multigeográfico Premium.

Consulte Configurar suporte multigeográfico para Power BI Premium para obter mais informações sobre como criar e gerenciar implantações do Power BI que abrangem várias regiões geográficas do Azure.

Regiões e datacenters

Os serviços do Power BI estão disponíveis em regiões geográficas 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 são usados, consulte o Microsoft Trust Center. Os compromissos relativos à localização dos dados do cliente em repouso estão especificados nos Termos de Processamento de Dados dos Termos do Microsoft Online Services.

A Microsoft também fornece centros de dados 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 de artefatos do Power BI, enquanto SQL do Azure Bancos de Dados são usados para persistir metadados de artefato.

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 Transparent Data Encryption (TDE) do Azure SQL. Os dados do cliente armazenados no Armazenamento de Blobs do Azure são criptografados usando a Criptografia de Armazenamento do Azure.

Opcionalmente, as organizações podem utilizar o Power BI Premium para usar suas próprias chaves para criptografar dados inativos que são importados para um modelo semântico. Essa abordagem geralmente é descrita como BYOK (Bring Your Own Key). A utilização do BYOK ajuda a garantir que, mesmo no caso de um erro de operador de serviço, os dados do cliente não sejam expostos – algo que não pode ser facilmente alcançado usando a criptografia transparente do lado do serviço. Consulte Traga suas próprias chaves de criptografia para o Power BI para obter 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 dessa fonte são persistentes no serviço ou não.

Modo de Modelo Semântico (Variante)	Dados persistentes no Power BI
Importaçãoação	Sim
DirectQuery	Não
Live Connect	Não
Composto	Se contiver uma fonte de dados De importação
Streaming	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 consulta e relatório.

Dados no 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 ativamente dados processados 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 exige que todo o tráfego HTTP de entrada seja criptografado usando o TLS 1.2 ou superior. Todas as solicitações que tentarem usar o serviço com TLS 1.1 ou inferior serão rejeitadas.

Autenticação para 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 painéis 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 o logon único, as credenciais do usuário atual serão usadas para se conectar à fonte de dados quando um usuário exibir os dados. Quando usado com logon único, a RLS (Segurança em Nível de Linha) e/ou a OLS (segurança em nível de objeto) podem ser implementadas na fonte de dados. Isso permite que os usuários exibam apenas os dados que têm privilégios de acesso. Quando a conexão é feita com fontes de dados na nuvem, a autenticação do Microsoft Entra é usada para logon único; quanto às fontes de dados locais, há suporte para Kerberos, SAML (Security Assertion Markup Language) e Microsoft Entra ID.

Se a fonte de dados for Azure Analysis Services ou o Analysis Services local e o RLS e/ou o OLS estiver configurado, o serviço do Power BI aplicará essa segurança em nível de linha e os usuários que não têm credenciais suficientes para acessar os dados subjacentes (que podem ser uma consulta usada em um dashboard, relatório ou outro artefato de dados) não verá dados para os quais eles 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 nos 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 um membro, contribuidor ou uma função de administrador em um workspace pode criar um fluxo de dados. Os usuários na função de 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, contribuidor ou administrador do workspace poderá agendar atualizações, bem como exibir e editar o fluxo de dados tomando 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 por serviços Power Query enquanto os dados estão em andamento. Para fluxos de dados premium, Power Query serviços 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 localmente. Quando extraído diretamente de uma fonte de nuvem para o serviço ou para o gateway, o transporte usa a 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 as fontes de dados especificadas pelo cliente exigem credenciais para acesso, o proprietário/criador do fluxo de dados as fornecerá durante a criação. Eles são armazenados usando o armazenamento de credenciais padrão em todo o produto. Consulte a seção 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 Armazenamento de Blobs para proteger os dados enquanto eles estão em repouso. Consulte a seção 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, uma entidade de segurança de serviço do Power BI recebe acesso a essa conta de armazenamento para que ela possa gravar os dados durante a atualização. Nesse caso, o proprietário do recurso de armazenamento é responsável por configurar a criptografia na conta de armazenamento do ADLS configurada. 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 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 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 estã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 o Microsoft Entra ID 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 protocolo de transporte criptografado HTTPS.

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

Relatórios paginados

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

Os relatórios paginados dão suporte a expressões avançadas e avançadas escritas no Microsoft Visual Basic .NET. As expressões são amplamente usadas nos relatórios paginados do Power BI Report Builder 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 são executados dentro de uma área restrita.

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 maneira descrita na seção Autenticação no Serviço do Power BI acima.

O token do Microsoft Entra obtido durante a autenticação é usado para se comunicar diretamente do navegador com o cluster do Power BI Premium.

Em 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 área restrita 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, a área restrita nunca tem acesso a nenhuma credencial ou segredo.

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

Análise integrada do Power BI

IsVs (Fornecedores Independentes de Software) e provedores de soluções têm dois modos main de inserir 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 portal ou aplicativo Web externo e a comunicação com o IFrame é feita usando o SDK do Cliente do Power BI usando mensagens POST.

Em um cenário de inserção para a sua 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 ITs. Todas as políticas e funcionalidades do Power BI descritas neste artigo, como RLS (Segurança em Nível de Linha) e OLS (segurança em nível de objeto), 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 inserção para seus clientes, os ISVs normalmente possuem locatários 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 do 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 inserçã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 aos métodos de autenticação e autorização do Microsoft Entra delegados e de 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: Por exemplo, 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 recursos como Influenciadores-chave, Árvore de decomposição, Narrative inteligente, Detecção de anomalias, Visual R, Visual Python, Clustering, Previsão, P e R, 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 nos workspaces Compartilhado e Premium atualmente. No entanto, o AutoML e o CognitiveServices têm suporte apenas 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 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 CognitiveServices, como TextAnalytics e ImageTagging, para transformar dados antes de carregá-los em um fluxo de dados/modelo semântico definido em um workspace Premium.

Os recursos de enriquecimento de IA Premium podem ser melhor exibidos 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 fluxo de dados/modelo semântico no Serviço do Power BI e 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 exibem dados próprios e fornecem apenas essas funções/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 relacionados a eles.

Para treinar e aplicar um modelo de AutoML, o Power BI usa o SDK do AutoML do Azure 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 hiperparâmetros adequados para a iteração atual. Nessa 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 podem 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 usa um SDK interno para executar as APIs na capacidade do Power BI Premium. Atualmente, essas APIs têm suporte em fluxos de dados e modelos semânticos do Power BI. 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 do Power BI Premium. Portanto, os clientes são solicitados a fornecer suas credenciais do Microsoft Entra.

Isolamento de 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. Consulte as seções abaixo para obter detalhes.

Marcas 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 das regras de segurança da rede. Os clientes podem usar tags de serviço para definir controles de acesso à rede em Grupos de Segurança de Rede ou no Azure Firewall. Os clientes podem usar tags de serviço no lugar de endereços IP específicos ao criar regras de segurança. Ao especificar o nome da tag de serviço (como PowerBI) no campo apropriado de origem ou destino (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 englobados pela marca de serviço e atualiza automaticamente a marca de serviço em caso de alteração de endereços.

Integração de Link Privado

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 os pontos de extremidade privados, o tráfego de dados é enviado de maneira privada por meio da infraestrutura de rede de backbone da Microsoft e, portanto, os dados não passam pela Internet.

O Private Link garante que os usuários do Power BI usem o backbone da 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 fluirá pelo backbone do Azure para um ponto de extremidade privado para recursos baseados na nuvem do Azure.
• O isolamento de tráfego de rede de uma infraestrutura não baseada no Azure, como o acesso local, exige que os clientes tenham o ExpressRoute ou uma VPN (rede virtual privada) configurada.

Confira Links privados para acessar o Power BI para obter informações adicionais.

Conectividade de VNet

Embora o recurso de integração Link Privado forneça conexões de entrada seguras com o 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 instalação e monitoramento de gateways de dados locais para se conectar a fontes de dados associadas a uma VNet. No entanto, eles ainda seguirão 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 compatíveis) inicia uma consulta e envia a consulta, os detalhes da fonte de dados e as credenciais para o serviço Power Platform VNet (PP VNet).

2. Em seguida, o serviço PP VNet injeta com segurança um contêiner que executa um gateway VNet na sub-rede. Esse contêiner agora pode se conectar a serviços de dados acessíveis a partir dessa sub-rede.

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

4. O gateway da VNet recebe a consulta e se conecta às fontes de dados com essas credenciais.

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

6. Após a execução, os resultados são enviados para o gateway VNet, e o serviço PP VNet 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 as credenciais da Entidade de Serviço usada para criptografar ou acessar o Power BI em um Key Vault, atribua as políticas de acesso adequadas ao cofre e examine regularmente as permissões de acesso.

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

Microsoft Purview para Power BI

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

O Power BI está profundamente integrado ao Proteção de Informações do Microsoft Purview. 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 entre o Azure, o Power BI e o Office.

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

• Os 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 em 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 de negócios, garantindo que somente usuários autorizados possam editar esses arquivos.
• As pastas de trabalho do Excel herdam automaticamente rótulos de confidencialidade quando se conectam ao Power BI (versão prévia), possibilitando manter a classificação de ponta a ponta e aplicar proteção quando os modelos semânticos do Power BI forem analisados no Excel.
• Os rótulos de confidencialidade aplicados a relatórios e dashboards do Power BI estã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 de rótulos 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 ao novo conteúdo criado 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 confidencialidade downstream no serviço do Power BI garante que, quando um rótulo em um modelo semântico ou datamart é aplicado ou alterado, o rótulo seja aplicado ou alterado automaticamente em todo o conteúdo downstream conectado ao modelo semântico ou datamart.

Confira mais informações em 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 do Microsoft Purview ajudam as organizações a reduzir o risco de vazamento de dados comerciais confidenciais do Power BI. As políticas DLP as 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 o CCPA (a Lei de Privacidade do Consumidor da Califórnia) 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 dentro dos workspaces especificados na política são avaliados por ela.
• 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.
• Ao encontrar 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 "confidencial" 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 erroneamente.
• Mitigações automáticas de risco, como alertas para o administrador de segurança, podem ser invocadas.

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

Microsoft Defender para aplicativos em nuvem para o Power BI

Microsoft Defender para Aplicativos de Nuvem é um dos principais agentes de segurança de acesso à nuvem do mundo, nomeado como líder no Magic Quadrant da Gartner para o mercado CASB (agente de segurança de acesso à nuvem). O Microsoft 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 ações do usuário, como baixar relatórios com informações confidenciais.

Com os Aplicativos Microsoft Defender para 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 dos Aplicativos Microsoft Defender para 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 dos Aplicativos Microsoft Defender para Nuvem. O log de atividades dos Aplicativos Microsoft Defender para Nuvem inclui atividades do Power BI capturadas no log de auditoria 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 e as ações rápidas dos Aplicativos Microsoft Defender para Nuvem para uma investigação eficaz do problema.
• Crie políticas personalizadas para alertar sobre atividades suspeitas de usuários no Power BI. O recurso de política de atividade dos Aplicativos Microsoft Defender para 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 agir automaticamente, se parecer muito perigoso.
• Trabalhe com a detecção de anomalias interna dos Aplicativos Microsoft Defender para Nuvem. As políticas de detecção de anomalias dos Aplicativos Microsoft Defender para Nuvem fornecem análise comportamental do usuário e aprendizado de máquina prontos desde o início 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 dos Aplicativos Microsoft Defender para Nuvem. Os Aplicativos Microsoft Defender para 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.

Consulte Usando controles dos Aplicativos Microsoft Defender para Nuvem no Power BI para obter detalhes adicionais.

Visualizar recursos de segurança

Esta seção lista os recursos que estão previstos para serem lançados até março de 2021. Como este tópico lista recursos que talvez ainda não tenham sido lançados, as linhas do tempo de entrega podem mudar e a funcionalidade projetada pode ser lançada até março de 2021 ou não ser lançada. Para obter mais informações sobre visualizações, examine os Termos dos Serviços Online.

ByOLA (Bring Your Own Log Analytics)

O Bring Your Own Log Analytics permite a integração entre o Power BI e o Azure Log Analytics. Essa integração inclui o mecanismo analítico avançado do Azure Log Analytics, a linguagem de consulta interativa e os constructos internos de machine learning.

Perguntas e respostas sobre segurança do Power BI

As perguntas a seguir são perguntas e respostas de segurança comuns para o Power BI. Elas estão organizadas com base na data em que foram adicionadas a este white paper, para facilitar sua capacidade de encontrar rapidamente novas perguntas e respostas quando este documento for 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 durante o uso do 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 utilizar 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 dashboard 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 (Segurança em Nível de Linha) e/ou a OLS (segurança no nível do objeto) 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 kerberos, o usuário é representado e conectado às respectivas fontes de dados. O SAML também tem suporte na fonte de dados Gateway para SAP HANA. Mais informações estão disponíveis em visão geral do logon único para gateways.

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

  A segurança de nível de linha com o Power BI pode ser usada para restringir o acesso aos dados para determinados usuários. Os filtros restringem o acesso a dados no nível da linha e você pode definir filtros nas funções.

  A OLS (segurança em nível de objeto) pode ser usada para proteger tabelas ou colunas confidenciais. No entanto, ao contrário da segurança em nível de linha, a segurança no nível do objeto também protege nomes de objetos e metadados. 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 por meio do DAX ou de 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.

  A segurança em nível de objeto, juntamente com a segurança em nível de linha, permite maior segurança 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 depois disso os dados cruzam a rede.

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

• Quando uma fonte de dados é acessada, o serviço do Power BI segue o processo descrito na seção Autenticação para fontes de dados, anteriormente neste documento.

Clientes armazenam em cache de dados da página da Web localmente?

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

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

• Para fontes de dados não habilitadas para RLS (Segurança em Nível de Função), se um painel, relatório ou modelo de dados for compartilhado com outros usuários por meio do Power BI, os dados estarão disponíveis para que os usuários com os quais foram compartilhados possam visualizar e interagir. O Power BI não autentica novamente os usuários com relação à 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 visualizar os dados.

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

  Para obter mais informações, consulte a seção Autenticação para fontes de dados, anteriormente neste documento.

Nossos usuários se conectam às mesmas fontes de dados o tempo todo, algumas das quais exigem credenciais diferentes das credenciais do seu domínio. Como ele pode evitar ter que inserir essas credenciais toda vez que fizer uma conexão de dados?

• O Power BI oferece o Power BI Personal Gateway, que é um recurso que permite aos usuários criar credenciais para várias fontes de dados diferentes e então automaticamente usá-las ao acessar depois cada uma dessas fontes de dados. Para obter mais informações, veja Power BI Personal Gateway.

Quais portas são utilizadas pelo gateway de dados local e pelo gateway pessoal? Existe algum nome de domínio que precisa ser permitido para fins de conectividade?

• A resposta detalhada a essa pergunta está disponível no link a seguir: Portas de gateway de rede

Ao trabalhar com o gateway de dados local, como são utilizadas as chaves de recuperação e em que local elas são armazenadas? E quanto ao gerenciamento seguro de credenciais?

• Durante a configuração e a instalação do gateway, o administrador de digita Chave de Recuperação de um 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 aquele computador Windows em particular e somente por aquela conta de serviço de gateway específica.

  Quando um usuário insere credenciais da 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 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 seguintes protocolos de comunicação:

  • AMQP 1.0 - TCP + TLS: esse protocolo exige que as portas 443, 5671-5672 e 9350-9354 estejam abertas para comunicação de saída. Esse protocolo é preferível, já que tem menor sobrecarga de comunicação.

  • HTTPS – WebSockets sobre HTTPS + TLS: esse protocolo usa apenas a porta 443. O WebSocket é iniciado por uma única mensagem HTTP CONNECT. Quando 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 de Gateway Local.

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

• Como mencionado anteriormente, o Power BI usa a Rede de Entrega de Conteúdo (CDN) do Azure para distribuir com eficiência o conteúdo estático e os arquivos necessários aos usuários com base na localização geográfica. Para entrar em mais detalhes, o serviço do Power BI utiliza 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 provedores de serviços independentes), 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 inicial de login seguro 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, com o WFE) para fazer o download da 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 os recursos visuais do Power BI, a Microsoft realiza alguma 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 código visual personalizado deve ser usado. Todo o código visual personalizado é operado em um ambiente de área restrita, para que qualquer código errôneo 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. Bing Mapas e visuais ESRI transmitem dados fora do serviço do Power BI para visuais que usam esses serviços.

Para aplicativos modelo, a Microsoft realiza alguma avaliação de segurança ou privacidade do aplicativo modelo antes de publicar itens no Gallery?

• Não. O editor de aplicativos é responsável pelo conteúdo, enquanto é responsabilidade do cliente examinar e determinar se deve 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 de modelo deve ser instalado no locatário. O editor é responsável por informar o cliente sobre o comportamento e os recursos do aplicativo.

E quanto à soberania dos dados? Podemos fornecer locatários em data centers localizados em regiões geográficas específicas, para garantir que os dados não saiam das fronteiras do país ou da região?

• Alguns clientes em determinadas regiões geográficas têm a opção de criar um locatário em uma nuvem nacional/regional, onde o armazenamento e o processamento de dados são mantidos separados de todos os outros data centers. As nuvens nacionais/regionais têm um tipo de segurança ligeiramente diferente, pois um administrador de dados separado opera o serviço Power BI em nuvem nacional/regional em nome da Microsoft.

  Como alternativa, os clientes também podem configurar um locatário em uma região específica. No entanto, esses locatários não têm um objeto de confiança de dados separado da Microsoft. O preço para nuvens nacionais/regionais é diferente 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 de clientes que têm assinaturas do Power BI Premium? Essas conexões são diferentes daquelas estabelecidas para o serviço não Premium do Power BI?

• 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 o Microsoft Entra ID para habilitar o controle de acesso e a autorização. O Power BI lida com conexões de assinantes do Power BI Premium de 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 lado do serviço da sequência de autenticação do usuário 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 HTTPS e TLS 1.2, e todas as comunicações subsequentes entre o navegador e o serviço do Power BI usam HTTPS.

2. O Gerenciador de Tráfego do Azure verifica o registro DNS do usuário para determinar o datacenter mais apropriado (geralmente o mais próximo) onde o Power BI está 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 login do Microsoft Online Services.

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

5. O cluster WFE verifica com o Microsoft Entra ID para obter um token de segurança do Microsoft Entra usando o código de autenticação. Quando o Microsoft Entra ID retorna a autenticação bem-sucedida do usuário e retorna um token de segurança do Microsoft Entra, o cluster WFE consulta o Serviço Global do Power BI, que mantém uma lista de locatários e seus locais de cluster de back-end do Power BI e determina qual cluster de serviço de back-end do Power BI contém o locatário 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 exigir 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 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 que ele expire.

Recursos adicionais

Para obter mais informações sobre o Power BI, veja os seguintes recursos.

• Introdução ao Power BI Desktop
• API REST do Power BI – Visão Geral
• Referência da API do Power BI
• Gateway de dados local
• Nuvens nacionais/regionais do Power BI
• Power BI Premium
• Visão geral de SSO (logon único) para gateways no Power BI