White paper de segurança do Power BI

Resumo: O Power BI é um serviço de software online (SaaS ou Software como Serviço) oferecido pela Microsoft que permite criar painéis de Business Intelligence de autoatendimento de forma fácil e rápida, relatórios, modelos semânticos (anteriormente conhecidos como conjuntos de dados) 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 painéis 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, Sergei Gundorov

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

Nota

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 serviço de software online (SaaS ou Software como Serviço) da Microsoft que lhe 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 muitas fontes de dados diferentes, combinar e moldar dados dessas conexões e, em seguida, criar relatórios e painéis que podem ser compartilhados com outras pessoas.

O mundo está a mudar 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 on-line 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 um gotejamento para uma inundação, e com a nova área de superfície exposta que vem com ela, mais empresas estão se perguntando quão seguros são meus dados na nuvem? e Qual proteção de ponta a ponta está disponível para evitar que meus dados confidenciais vazem? E para as plataformas de BI que muitas vezes lidam com algumas das informações mais estratégicas da empresa, essas questões são duplamente importantes.

Os fundamentos de décadas do modelo de segurança de BI - segurança em nível de objeto e em nível de linha - embora ainda sejam 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 da nuvem, multicamadas e de defesa profunda para seus dados de business intelligence.

O Power BI foi criado para fornecer proteção de dados, completa e hermética líder do setor. O produto ganhou as mais altas classificações de segurança disponíveis no setor, e hoje muitas agências de segurança nacional, instituições financeiras e provedores de cuidados de saúde confiam a ele suas informações mais confidenciais.

Tudo começa com a fundação. Depois de 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 forte pilha de segurança que vai tão fundo quanto o kernel bios on-chip da máquina 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 abordam proativamente o cenário de ameaças em constante mudança. Com bilhões de computadores, trilhões de logins e incontáveis zettabytes de informações confiadas à proteção da Microsoft, a empresa agora possui a pilha de segurança mais avançada da indústria de tecnologia e é amplamente vista como líder global na luta contra agentes mal-intencionados.

O Power BI baseia-se nesta base sólida. Ele usa a mesma pilha de segurança que deu ao Azure o direito de servir e proteger os dados mais confidenciais do mundo e integra-se com as ferramentas de conformidade e proteção de informações mais avançadas do Microsoft 365. Além disso, oferece segurança por meio de medidas de segurança em 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 completa para proteger ativos confidenciais, a equipe de produto precisava lidar com as preocupações desafiadoras dos clientes em várias frentes simultâneas:

• Como controlamos quem pode se conectar, de onde eles se conectam e como eles se conectam?Como podemos controlar as conexões?
• Como são armazenados os dados?Como é encriptado?Que controlos tenho sobre os meus dados?
• Como posso controlar e proteger os meus dados sensíveis?Como faço para garantir que esses dados não vazem para fora da organização?
• Como faço para auditar quem conduz quais operações?Como reajo 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ços e explica como funcionam os principais fluxos no sistema. 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 do serviço, proteja seus ativos mais valiosos.

O serviço Power BI é regido pelos Termos do Microsoft Online Services e pela Declaração de Privacidade da Microsoft Enterprise. Para obter o local do processamento de dados, consulte os termos de Localização do Processamento de Dados nos Termos do Microsoft Online Services e no Adendo de Proteção de Dados. Para obter informações de conformidade, a Central de Confiabilidade da Microsoft é o principal recurso do Power BI. A equipa do Power BI está a trabalhar arduamente para trazer aos seus clientes as mais recentes inovações e produtividade. Saiba mais sobre conformidade nas ofertas de conformidade da Microsoft.

O serviço Power BI segue o Security Development Lifecycle (SDL), práticas de segurança rigorosas que dão suporte aos requisitos de conformidade e garantia de segurança. O SDL ajuda os desenvolvedores a construir software mais seguro, reduzindo o número e a gravidade das vulnerabilidades no software, enquanto reduz o custo de desenvolvimento. Saiba mais nas Práticas de Ciclo de Vida de Programação de Segurança da Microsoft.

Arquitetura do Power BI

O serviço Power BI é criado no Azure, a plataforma de computação em nuvem da Microsoft. Atualmente, o Power BI está implantado em muitos datacenters ao redor do mundo – há muitas implantações ativas disponibilizadas para 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.

Cluster 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 CDN usado para renderizar o site no navegador.

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 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 compatível para hospedar conteúdo estático.

Cluster back-end (BE) do Power BI

O cluster back-end é a espinha dorsal de todas as funcionalidades disponíveis no Power BI. Ele consiste em vários pontos de extremidade de serviço consumidos por clientes Web Front End 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 à medida que ficam disponíveis. Uma única região do Azure hospeda um ou mais clusters 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 se esgotam.

Cada cluster back-end tem monitoração de 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 doméstico do locatário. As informações do cluster base 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 base do locatário.

Cada cluster back-end consiste em várias máquinas virtuais combinadas em vários conjuntos de escala redimensionável ajustados para executar tarefas específicas, recursos com monitoração de 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 do cluster, exceto para a replicação de dados para um cluster back-end secundário em uma região emparelhada do Azure na mesma geografia do Azure. O cluster 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 é servida por microsserviços executados em máquinas diferentes dentro da rede virtual do cluster que não são acessíveis do lado de fora, exceto para dois componentes que podem ser acessados pela Internet pública:

• Serviço de Gateway
• Gestão de API do Azure

Infraestrutura do 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 Gerenciador de Recursos do Azure.

As capacidades do Power BI Premium são hospedadas em clusters de back-end que são independentes do back-end normal do Power BI – veja acima). Isso proporciona 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 do 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 o navegador de um usuário, um back-end normal do Power BI, conexões diretas por meio de clientes XMLA, APIs ARM, etc.

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 são encapsulados dentro de um cluster (por exemplo, computação) e existem alguns recursos regionais comuns (por exemplo, armazenamento de metadados). A infraestrutura premium permite duas maneiras de alcançar escalabilidade horizontal em uma região: aumentar os recursos dentro dos 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 por Conjuntos de Escala de Máquina Virtual e Azure Service Fabric. Os Conjuntos de Dimensionamento de Máquina Virtual e o Service Fabric permitem um aumento rápido e indolor dos 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 do Power BI Premium.

Existem muitos recursos circundantes 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. Quaisquer segredos, chaves e certificados necessários para o Power BI Premium são geridos exclusivamente pelo Azure Key Vault . Qualquer autenticação é feita exclusivamente por meio da integração com o Microsoft Entra ID (anteriormente conhecido como Azure Ative Directory).

Qualquer solicitação que chega à infraestrutura do Power BI Premium vai primeiro para os nós front-end – eles são os únicos nós disponíveis para conexões externas. O resto dos recursos estão escondidos 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 back-end).

Os nós 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 do Power BI Mobile se enquadram em duas categorias:

• Comunicação do dispositivo
• A aplicação e os dados no dispositivo

Para comunicação de dispositivo, todos os aplicativos do Power BI Mobile se comunicam com o serviço Power BI e usam as mesmas sequências de conexão e autenticação usadas pelos navegadores, descritas em detalhes anteriormente neste white paper. Os aplicativos móveis do Power BI para iOS e Android exibem uma sessão do navegador dentro do próprio aplicativo, enquanto o aplicativo móvel do Windows traz 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 à autenticação baseada em certificado (CBA) para o Power BI Mobile, com base na plataforma de dispositivo móvel:

Suporte CBA	iOS	Android	Janelas
Power BI (entrar no serviço)	Suportado	Suportado	Não suportado
SSRS ADFS local (conecte-se ao servidor SSRS)	Não suportado	Suportado	Não suportado
Proxy de Aplicações SSRS	Suportado	Suportado	Não suportado

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 que são 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:

• 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 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 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 configuração do usuário) são armazenados em cache no dispositivo em uma área restrita e armazenamento interno acessível apenas ao aplicativo. Para o aplicativo do Windows, os dados só são acessíveis pelo usuário (e pelo administrador do sistema).
• A geolocalização é ativada ou desativada explicitamente pelo utilizador. Se ativada, os dados de geolocalização não são guardados no dispositivo e não são partilhados com a Microsoft.
• As notificações são ativadas ou desativadas explicitamente pelo utilizador. Se ativados, o Android e o iOS não suportam requisitos de residência de dados geográficos para notificações.

A encriptação de dados pode ser melhorada através da aplicação de encriptação ao nível de ficheiro através do Microsoft Intune, um serviço de software que fornece gestão de dispositivos móveis e aplicações. Todas as três plataformas para as quais o Power BI Mobile está disponível suportam o Intune. Com o Intune habilitado 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.

A aplicação Windows também suporta a Proteção de Informações do Windows (WIP).

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

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 não consegue entrar (como após um evento de expiração de token ou alteração de senha). O cache de dados inclui painéis e relatórios acessados anteriormente a partir do aplicativo Power BI Mobile.

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

As aplicações Power BI para iOS e Android permitem-lhe proteger os seus dados configurando identificação adicional, como fornecer Face ID, Touch ID ou um código de acesso para iOS e dados biométricos (ID de impressão digital) para Android. Saiba mais sobre identificação adicional.

Autenticação para o 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 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 a seguir.

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) 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 de 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 tiver sido 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. 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 back-end do Power BI. O Serviço Global do Power BI determina qual cluster de serviço back-end do Power BI contém o locatário do usuário e retorna a URL do cluster back-end do Power BI de volta para o cliente.

8. O cliente agora pode se comunicar com a API de URL de cluster back-end do Power BI, usando o token de acesso no cabeçalho Authorization 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 Power BI no navegador do usuário fará solicitações periódicas para renovar o token de acesso antes que ele expire.

Nos raros casos 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

Salvo indicação em contrário na documentação, o Power BI armazena dados do cliente numa geografia do Azure que é atribuída quando um inquilino do Microsoft Entra se inscreve nos serviços do Power BI pela primeira vez. Um locatário do Microsoft Entra abriga as identidades de usuário e aplicativo, grupos e outras informações relevantes que pertencem 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 selecionada como parte da configuração do locatário do Microsoft Entra para a geografia do Azure mais adequada onde 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 nesta geografia selecionada do Azure (também conhecida como geografia inicial), exceto nos casos em que as organizações utilizam implantações multigeográficas.

Várias geografias (multi-geo)

Algumas organizações têm uma presença global e podem exigir serviços do Power BI em várias geografias 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 artefactos atribuídos a uma área de trabalho multigeográfica são alojados e permanecem na geografia do Azure de capacidade remota. No entanto, alguns metadados de artefatos, como a estrutura do relatório, podem permanecer armazenados em repouso na área geográfica da casa do locatário. Além disso, algum trânsito e processamento de dados ainda pode acontecer na área geográfica de origem do locatário, mesmo para espaços de trabalho hospedados em uma capacidade Premium multigeográfica.

Consulte Configurar suporte Multi-Geo para o 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 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. Os compromissos relativos à localização dos dados de clientes inativos encontram-se especificados nos Termos do Processamento de Dados dos Termos dos Serviços Online da Microsoft.

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

Processamento de dados

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

Dados inativos

O Power BI usa dois tipos principais de recursos de armazenamento de dados:

• Armazenamento do Azure
• Bases 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 os Bancos de Dados SQL do Azure são usados para persistir metadados de artefatos.

Todos os dados persistidos 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 Azure SQL. Os dados do cliente armazenados no armazenamento de Blob 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 em repouso que são importados para um modelo semântico. Esta abordagem é frequentemente descrita como traga a sua própria chave (BYOK). A utilização do BYOK ajuda a garantir que, mesmo em caso de erro do operador de serviço, os dados do cliente não serão expostos – algo que não pode ser facilmente alcançado usando criptografia transparente do lado do serviço. Consulte Trazer 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 da fonte de dados são persistentes no serviço ou não.

Modo de Modelo Semântico (Tipo)	Dados persistentes no Power BI
Importar	Sim
DirectQuery	Não
Conexão ao vivo	Não
Composto	Se contiver uma fonte de dados Importar
Transmissão	Se configurado para persistir

Independentemente do modo de modelo semântico utilizado, o Power BI pode armazenar temporariamente em cache quaisquer dados recuperados para otimizar o desempenho de carregamento 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 nesses 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 exige que todo o tráfego HTTP de entrada seja criptografado usando TLS 1.2 ou superior. Quaisquer solicitações que tentem usar o serviço com TLS 1.1 ou inferior serão rejeitadas.

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 conectar-se diretamente à fonte de dados.

No caso de importação, um usuário estabelece uma conexão com base no login 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 visualizaçã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 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 Segurança no Nível do Objeto (OLS) podem ser implementadas na fonte de dados. Isso permite que os usuários visualizem 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; para fontes de dados locais, há suporte para Kerberos, SAML (Security Assertion Markup Language) e ID do Microsoft Entra.

Se a fonte de dados for o Azure Analysis Services ou o Analysis Services local e a RLS e/ou OLS estiver configurada, o serviço do Power BI aplicará essa segurança em nível de linha 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 os dados para os quais não têm privilégios suficientes.

Funcionalidades premium

Arquitetura de fluxos de dados

Os fluxos de dados fornecem aos usuários a capacidade de configurar operações de processamento de dados 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, 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 espaço de trabalho pode criar um fluxo de dados. Os usuários na função de visualizador podem exibir dados processados pelo fluxo de dados, mas não podem fazer alterações em sua composição. Depois que um fluxo de dados for criado, qualquer membro, colaborador ou administrador do espaço de trabalho poderá agendar atualizações, bem como exibir e editar o fluxo de dados assumindo a propriedade dele.

Cada fonte de dados configurada está vinculada a uma tecnologia cliente para acessar essa fonte de dados. A estrutura de credenciais necessária para acessá-los é 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 voo. Para fluxos de dados premium, os serviços do Power Query são executados em nós 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 fonte de nuvem para o serviço ou para o gateway, o transporte usa 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 em 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 Blob para proteger os dados enquanto eles estão em repouso. Consulte a secçã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 serviço do Power BI recebe acesso a essa conta de armazenamento para que possa 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 de armazenamento ADLS configurada. Os dados são sempre transmitidos para o armazenamento de Blob usando criptografia.

Como o desempenho ao acessar contas de armazenamento pode estar abaixo do ideal para 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 de forma redundante em um banco de dados SQL que está disponível para DirectQuery por meio do acesso pelo sistema back-end do Power BI. Os dados são sempre encriptados no sistema de ficheiros. Se o usuário fornecer uma chave para criptografar os dados armazenados no banco de dados SQL, essa chave será usada para criptografá-los 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 vinculados a um espaço de trabalho, o acesso aos dados é sempre limitado pela função do usuário nesse espaço de trabalho. 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. Em caso afirmativo, 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 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 encaixarem bem em uma página. Eles exibem todos os dados em uma tabela, mesmo que a tabela se estenda por várias páginas. Você pode controlar exatamente o layout da página do relatório.

Os relatórios paginados suportam expressões ricas e poderosas escritas no Microsoft Visual Basic .NET. 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 são realizados 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 descrita na seção Autenticação para o Serviço do Power BI acima.

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

No Power BI Premium, o tempo de execução do serviço do Power BI fornece um ambiente de execução adequadamente isolado para cada renderização de relatório. Isso inclui casos em que os relatórios que estão sendo renderizados pertencem a espaços de trabalho 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, o sandbox nunca tem acesso a nenhuma credencial ou segredo.

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

Análise incorporada do Power BI

Os fornecedores independentes de software (ISVs) e os fornecedores de soluções têm dois modos principais de incorporar artefactos do Power BI nas suas aplicações Web e portais: incorporar para a sua organização e incorporar para os seus clientes. O artefato é incorporado 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 incorporação para 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 TIs. Todas as políticas e recursos do Power BI descritos neste documento, como RLS (Segurança em Nível de Linha) e OLS (Segurança em Nível de Objeto), são aplicados automaticamente a todos os usuários, independentemente de acessarem o Power BI por meio do portal do Power BI ou de portais personalizados.

Em um cenário de incorporação para seus clientes , os ISVs normalmente possuem locatários do Power BI e itens do Power BI (painéis, relatórios, modelos semânticos e outros). É responsabilidade de um serviço 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 de ISV são criptografadas em um token de incorporação gerado pelo Power BI e passadas para o back-end de ISV para posterior distribuição 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 são capazes de descriptografar ou modificar tokens de incorporaçã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 aplicará todas as políticas (como acesso ou RLS) exatamente como foi especificado pelo ISV durante a geração.

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

A análise incorporada do Power BI e suas APIs REST oferecem suporte a todos os recursos de isolamento de rede do Power BI descritos neste artigo: Por exemplo, Tags de Serviço e Links Privados.

Recursos de IA

Atualmente, o Power BI oferece suporte a duas grandes categorias de recursos de IA no produto: visuais de IA e enriquecimentos de IA. Os recursos de IA de nível visual incluem recursos como Key-Influencers, Decomposition-Tree, Smart-Narrative, Anomaly Detection, R-visual, Python-visual, Clustering, Forecasting, Q&A, Quick-Insights, etc. Os recursos de enriquecimento de IA incluem recursos como AutoML, Azure Machine Learning, CognitiveServices, transformações R/Python etc.

A maioria dos recursos mencionados acima são suportados em espaços de trabalho compartilhados e Premium atualmente. No entanto, AutoML e CognitiveServices são suportados apenas em espaços de trabalho 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 enquanto carrega dados em um fluxo de dados definido em um espaço de trabalho Premium. Além disso, os usuários do Power BI podem aplicar várias APIs do CognitiveServices, como TextAnalytics e ImageTagging, para transformar dados antes de carregá-los em um modelo semântico/fluxo de dados definido em um espaço de trabalho 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 por 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 a partir dos 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 espaço de trabalho/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 AI. Essas fontes de dados de IA são especiais porque não apresentam nenhum de seus próprios dados e apenas fornecem 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 olhar para os cenários Premium individualmente para entender os padrões de comunicação e detalhes relevantes relacionados à segurança referentes 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 hiperparâmetros adequados para a iteração atual. Nesta chamada de saída, apenas metadados de experimento relevantes (por exemplo, precisão, algoritmo ml, parâmetros de algoritmo, etc.) da iteração anterior são enviados. O treinamento AutoML produz um modelo ONNX e dados de relatório de treinamento que são salvos no fluxo de dados. Mais tarde, 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 de serviço CognitiveServices, mas usa um SDK interno para executar as APIs na capacidade do Power BI Premium. Atualmente, essas APIs são suportadas 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ó podem acessar essa funcionalidade se tiverem acesso a um espaço de trabalho Premium do Power BI. Assim, 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. Consulte 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. Ajuda a minimizar a complexidade das atualizações frequentes das regras de segurança de rede. Os clientes podem usar tags 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 tags de serviço no lugar de endereços IP específicos ao criar regras de segurança. Ao especificar o nome da etiqueta 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 incluídos pela etiqueta de serviço e atualiza automaticamente a etiqueta de serviço à medida que os endereços mudam.

Integração de Link Privado

A rede do Azure fornece o recurso Azure Private Link que permite que o Power BI forneça acesso seguro por meio de pontos de extremidade privados da Rede do Azure. Com o Azure Private Link e pontos de extremidade privados, o tráfego de dados é enviado de forma privada 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.

Usar o Private Link com o Power BI oferece os seguintes benefícios:

• O Private Link garante que o tráfego fluirá através do backbone do Azure para um ponto de extremidade privado para recursos baseados na nuvem do Azure.
• O isolamento do tráfego de rede da infraestrutura não baseada no Azure, como o acesso local, exigiria que os clientes tivessem a Rota Expressa ou uma VPN (Rede Privada Virtual) configurada.

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

Conectividade VNet (pré-visualização - em breve)

Enquanto o recurso de integração de Link Privado fornece conexões de entrada seguras para o Power BI, o recurso de conectividade VNet habilita a conectividade de saída segura do Power BI para fontes de dados dentro de uma VNet.

Os gateways de VNet (gerenciados pela Microsoft) eliminarão a sobrecarga de instalação e monitoramento de gateways de dados locais para conexão com fontes de dados associadas a uma VNet. No entanto, eles ainda seguirão o processo familiar de gerenciamento de segurança e fontes de dados, como acontece com um gateway de dados local.

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

1. O serviço de nuvem do Power BI (ou um dos outros serviços de nuvem suportados) 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 VNet PP injeta com segurança um contêiner executando 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 VNet PP envia a consulta, os detalhes da fonte de dados e as credenciais para o gateway VNet.

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

5. A consulta é então enviada para a fonte de dados para execução.

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

Esta funcionalidade estará disponível em pré-visualização pública em breve.

Principais de serviço

O Power BI dá suporte ao uso de entidades de serviço. Armazene todas as credenciais da entidade de serviço usadas para criptografar ou acessar o Power BI em um Cofre de Chaves, atribua políticas de acesso adequadas ao cofre e revise regularmente as permissões de acesso.

Consulte Automatizar tarefas de modelo semântico e espaço de trabalho 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 com a Proteção de Informações do Microsoft Purview. O Microsoft Purview Information Protection permite que as organizações tenham uma solução única e integrada para classificação, rotulagem, auditoria e conformidade no Azure, Power BI e Office.

Quando a proteção de informações está 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 sensibilidade 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 ficheiros .pbix no Power BI Desktop, tal como acontece nas aplicações Excel, Word e PowerPoint. Os arquivos podem ser facilmente marcados de acordo com seu nível de sensibilidade. Além disso, podem ser encriptados se contiverem dados comerciais confidenciais, garantindo que apenas utilizadores autorizados podem editar esses ficheiros.
• As pastas de trabalho do Excel herdam automaticamente rótulos de sensibilidade quando se conectam ao Power BI (visualização), tornando possível manter a classificação de ponta a ponta e aplicar proteção quando os modelos semânticos do Power BI são analisados no Excel.
• Os rótulos de sensibilidade aplicados a relatórios e painéis do Power BI são visíveis nos aplicativos móveis do Power BI para iOS e Android.
• Os rótulos de sensibilidade persistem quando um relatório do Power BI é incorporado no Teams, no SharePoint ou em um site seguro. Isso ajuda as organizações a manter a classificação e a proteção após a exportação ao incorporar conteúdo do Power BI.
• A herança de rótulos após a criação de 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 sensibilidade 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 administração do Power BI permitem que as equipes centrais apliquem programaticamente rótulos de sensibilidade ao conteúdo no serviço do Power BI.
• As equipes centrais podem criar políticas de rótulos obrigatórios 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 downstream conectado ao modelo semântico ou datamart.

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

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

As políticas de DLP do Microsoft Purview podem ajudar as organizações a reduzir o risco de vazamento de dados corporativos confidenciais do Power BI. As políticas de DLP podem ajudá-los a atender aos requisitos de conformidade de regulamentações governamentais ou do setor, como GDPR (Regulamento Geral de Proteção de Dados da União Europeia) ou CCPA (Lei de Privacidade do Consumidor da Califórnia) e garantir que seus dados no Power BI sejam gerenciados.

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

• Todos os modelos semânticos dentro dos espaços de trabalho especificados na política são avaliados pela política.
• Você pode detetar quando dados confidenciais são carregados em suas capacidades Premium. As políticas de DLP podem detetar:
  • Rótulos de sensibilidade.
  • Tipos de informações confidenciais. Mais de 260 tipos são suportados. A deteção de tipos de informações confidenciais depende da verificação de conteúdo do Microsoft Purview.
• Quando você encontra um modelo semântico identificado como confidencial, pode ver uma dica de política personalizada que o 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 tiver um motivo válido para fazê-lo.
• 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 falsamente identificado.
• Reduçõ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 de perda de dados para o Power BI.

Microsoft Defender para aplicativos de nuvem para Power BI

O Microsoft Defender for Cloud Apps é um dos principais corretores de segurança de acesso à nuvem do mundo, nomeado como líder no Quadrante Mágico do Gartner para o mercado de agente de segurança de acesso à nuvem (CASB). O Defender for Cloud Apps é usado para proteger o uso de aplicativos na 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 a partir 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 for Cloud Apps, 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 for Cloud Apps e ações arriscadas, como baixar dados marcados com um rótulo de sensibilidade "Altamente Confidencial", poderão ser bloqueadas imediatamente.
• Investigue a atividade do usuário do Power BI com o log de atividades do Defender for Cloud Apps. O log de atividades do Defender for Cloud Apps 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 e ações rápidas do Defender for Cloud Apps para uma investigação eficaz de problemas.
• Crie políticas personalizadas para alertar sobre atividades suspeitas do usuário no Power BI. O recurso de política de atividade do Defender for Cloud Apps pode ser aproveitado para definir suas próprias regras personalizadas, para ajudá-lo a detetar o comportamento do usuário que se desvia da norma e até mesmo possivelmente agir sobre ele automaticamente, se parecer muito perigoso.
• Trabalhe com a deteção de anomalias integrada do Defender for Cloud Apps. As políticas de deteção de anomalias do Defender for Cloud Apps fornecem análises comportamentais do usuário e aprendizado de máquina prontos para uso para que você esteja pronto desde o início para executar a deteção avançada de ameaças em seu ambiente de nuvem. Quando uma política de deteçã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 for Cloud Apps. O Defender for Cloud Apps 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 do Microsoft Defender for Cloud Apps no Power BI para obter detalhes adicionais.

Pré-visualizar funcionalidades de segurança

Esta seção lista os recursos que estão planejados para serem lançados até março de 2021. Como este tópico lista recursos que podem não ter sido lançados ainda, os prazos de entrega podem ser alterados e a funcionalidade projetada pode ser lançada depois de março de 2021 ou pode não ser lançada. Para obter mais informações sobre visualizações, consulte os Termos dos Serviços Online.

Traga seu próprio Log Analytics (BYOLA)

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, linguagem de consulta interativa e construções de aprendizado de máquina integradas.

Perguntas e respostas de segurança do Power BI

As perguntas a seguir são perguntas e respostas de segurança comuns 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 documento for atualizado. As perguntas mais recentes são adicionadas ao final desta lista.

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

• O Power BI gerencia credenciais para fontes de dados de 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 de seu armazenamento 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 no login 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 visualizaçã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 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, a RLS (Segurança em Nível de Linha) e/ou a Segurança no Nível do Objeto (OLS) podem ser implementadas na fonte de dados, e isso permite que os usuários visualizem 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; para fontes de dados locais, há suporte para Kerberos, SAML e ID do Microsoft Entra.

  Ao se conectar com Kerberos, o UPN do usuário é passado para o gateway e, usando a delegação restrita de Kerberos, o usuário é representado e conectado às respetivas fontes de dados. O SAML também é suportado na fonte de dados do Gateway for SAP HANA. Mais informações estão disponíveis em Visão geral do logon único para gateways.

  Se a fonte de dados for o Azure Analysis Services ou o Analysis Services local e a Segurança em Nível de Linha (RLS) e/ou a segurança no nível do objeto (OLS) estiver configurada, o serviço do Power BI aplicará essa segurança em nível de linha 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á 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 a dados para determinados usuários. Os filtros restringem o acesso aos dados no nível da linha e você pode definir filtros dentro da função.

  A segurança em nível de objeto (OLS) 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 em nível de objeto também protege nomes de objetos e metadados. Isso ajuda a evitar que usuários mal-intencionados descubram até mesmo a existência de tais objetos. Tabelas e colunas seguras 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 de usuários sem permissões de acesso adequadas, tabelas e colunas seguras simplesmente não existem.

  A segurança em nível de objeto, juntamente com a segurança em nível de linha, permite uma segurança aprimorada de nível empresarial em relatórios e modelos semânticos, garantindo que apenas usuários com as permissões necessárias tenham acesso para visualizar 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 oferece 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 atravessarão a rede.

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

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

Os clientes armazenam em cache os dados das páginas da Web localmente?

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

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

• 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 ficarão disponíveis para os usuários com quem são compartilhados para exibir e interagir. O Power BI não reautentica os usuários na fonte original dos dados, uma vez 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 as conexões de dados são feitas com 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 existirem permissões suficientes, os dados sã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 em 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 de suas credenciais de domínio. Como eles podem evitar ter que inserir essas credenciais cada vez que fazem uma conexão de dados?

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

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

• A resposta detalhada a esta pergunta está disponível no seguinte link: Portas de gateway

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

• Durante a instalação e configuração do gateway, o administrador digita 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 na máquina local. Esse ficheiro também foi encriptado. O conteúdo do ficheiro só pode ser desencriptado por essa máquina Windows específica 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 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 suporta os dois protocolos de comunicação a seguir:

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

  • HTTPS – WebSockets sobre HTTPS + TLS: Este protocolo usa apenas a porta 443. O WebSocket é iniciado por uma única mensagem HTTP CONNECT. Uma vez 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?

• Como mencionado anteriormente, o Power BI usa a CDN (Rede de Entrega de Conteúdo) 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 mais 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 provedores de serviços independentes), arquivos de configuração do navegador usados para iniciar e estabelecer 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 contata a CDN do Azure especificada (ou, para alguns arquivos, a 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 Microsoft Entra, informações de sessão, o local do cluster back-end associado e a coleção de arquivos baixados do cluster CDN e WFE do Azure, durante a sessão do navegador do serviço Power BI.

Para 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.º É responsabilidade do cliente analisar e determinar se o código visual personalizado deve ser confiável. Todo o código visual personalizado é operado em um ambiente de área restrita, para que qualquer código errante em um visual personalizado não afete negativamente o restante do serviço do Power BI.

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

• Sim. Os visuais do Bing Maps e ESRI transmitem dados do serviço do Power BI para elementos visuais que usam esses serviços.

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

• N.º O editor do aplicativo é responsável pelo conteúdo, enquanto é responsabilidade do cliente analisar e determinar se deve confiar no editor do aplicativo modelo.

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

• Sim. É da responsabilidade do cliente rever a política de privacidade do editor e determinar se deve instalar a aplicação modelo no inquilino. 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 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, onde 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, uma vez que um administrador de dados separado opera o serviço Power BI na 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 administrador de dados separado da Microsoft. O preço das 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 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 daquelas 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 B2B (business-to-business) do Microsoft Entra, 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 como faria com 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 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 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) 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 entrada do Microsoft Online Services.

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

5. O cluster WFE verifica com a ID do Microsoft Entra 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 back-end do Power BI e determina qual cluster de serviço 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 back-end com o token de acesso Microsoft Entra no cabeçalho Autorização. O cluster 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 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, consulte os seguintes recursos.

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