Considerações sobre exfiltração de dados e práticas recomendadas para fluxos de dados

Dica

O Power BI Dataflow Gen1 agora está em um estado herdado e não receberá novos investimentos em recursos. Para clientes Premium com acesso ao Fabric, o Dataflow Gen2 é o caminho recomendado, oferecendo melhorias no desempenho, escala, confiabilidade, funcionalidade e IA interna. Os clientes Pro/PPU podem continuar a usar o Gen1, já que a orientação para Gen2 nesses cenários ainda está evoluindo. Consulte a atualização do Dataflow Gen1 para o Dataflow Gen2 para obter diretrizes de atualização.

Fluxos de dados do Fabric e fluxos de dados do Power Platform são serviços do Microsoft 365 que permitem que os usuários se conectem, extraam, movam e transformem dados facilmente em centenas de fontes de dados com suporte. Os fluxos de dados se baseiam em um serviço subjacente chamado Power Query Online, que hospeda o mecanismo de movimentação de dados (Mashup Engine) como um serviço de nuvem. Por padrão, a conectividade se origina desse local de nuvem e tem acesso irrestrito à Internet. Portanto, ao usar fluxos de dados para acessar e mover dados confidenciais, as organizações devem considerar estratégias para impedir que insiders realizem a exfiltração acidental ou maliciosa de dados. Este artigo descreve fatores de risco conhecidos e práticas recomendadas para proteções.

Considerações

Execução arbitrária de código

Os trabalhos de ETL de fluxo de dados são definidos por meio de programas escritos em uma linguagem chamada Power Query M. Em sua configuração padrão, o Mecanismo de Mashup executa esses programas na nuvem, fora do limite de rede do locatário e com acesso irrestrito à Internet. Os usuários podem criar programas que se conectam a várias fontes de dados e, mediante consentimento, permitir que os dados fluam entre essas fontes.

Um usuário confiável que tem acesso a dados confidenciais pode criar um programa para enviar os dados por push para um armazenamento de dados não confiável. Como o Mecanismo de Mashup é executado inteiramente na nuvem, ele não passa por firewalls corporativos e servidores proxy. Portanto, ela não está sujeita a nenhuma política de DLP (prevenção contra perda de dados) que possa ser imposta por essas redes. Como o ponto de acesso está na Internet pública, os dados podem viajar para qualquer destino ao qual o usuário tenha acesso, seja por meio de autenticação ou acesso anônimo. Aqui estão alguns exemplos de maneiras pelas quais esses programas podem exfiltrar dados confidenciais:

• Solicitações da Web anônimas: usando Web.Contents, os usuários podem fazer solicitações da Web com dados confidenciais no corpo da solicitação.
• Filtragem e junções entre diferentes fontes de dados: dados confidenciais podem ser usados como condições de filtragem ou de junção em outra fonte de dados não confiável. Especificamente, os dados podem viajar para a fonte de dados não confiável na forma de cadeias de caracteres ou parâmetros de consulta.
• Destinos de saída: usando fluxos de dados do Fabric, os usuários podem especificar destinos de saída para suas consultas, transferindo dados para uma lista de coletores de dados com suporte, que inclui bancos de dados SQL do Azure e data warehouses, Fabric Lakehouses, Warehouses e bancos de dados KQL.

Movimentação de dados entre locatários

O Mecanismo de Mashup exige que as fontes de dados sejam definidas explicitamente antes de fazer conexões. As fontes de dados são associadas a programas com um tipo e uma chave de caminho (por exemplo, SQL;contoso.database.windows.net). Essa associação oferece uma oportunidade para que as organizações governem quais fontes de dados são permitidas, filtrando com base nos caminhos da fonte de dados. No entanto, há algumas fontes de dados em que o caminho é comum em todas as conexões e os dados são segmentados apenas pelo locatário das credenciais OAuth do usuário conectado. Esse cenário cria um fator de risco para a exfiltração de dados, em que um usuário faz login em uma instância de maior segurança e em uma instância de menor segurança e move dados entre elas. Normalmente, essa exfiltração pode ser feita de duas maneiras:

• Saída: Um usuário confiável em um locatário de segurança mais alta define um fluxo de dados nesse ambiente e cria um destino de saída para um receptáculo de dados permitido, mas autentica com o receptáculo de dados usando uma conta de um locatário com segurança inferior.
• Entrada: um usuário em um locatário de segurança inferior define um fluxo de dados que lê dados de uma fonte de dados confidencial no locatário de segurança mais alta. Essa definição pode ser obtida autenticando-se na fonte de dados confidenciais usando uma conta confiável no locatário de segurança superior.

Práticas recomendadas

As políticas DLP podem operar em várias camadas de OSI. Em geral, quanto mais confidenciais forem os dados, menor será a camada em que as políticas devem ser aplicadas. Normalmente, protocolos de camada inferior são mais caros de implementar, mais difíceis de dimensionar e mais difíceis de operar. Por exemplo, as organizações com requisitos de governança mais baixos podem precisar aplicar apenas políticas de camada de aplicativo. No entanto, algumas organizações e entidades que processam dados altamente confidenciais podem exigir medidas extremas, como isolamento físico. Recomendamos que as organizações que lidam com dados confidenciais utilizem uma combinação de políticas de aplicativo e de nível de rede para proteger contra ameaças internas.

Isolamento da rede

Recomendamos que todos os armazenamentos de dados que contêm dados confidenciais sejam isolados de rede para permitir o acesso somente de redes selecionadas. Essa restrição de isolamento deve ser definida e operada na camada de rede ou inferior. Por exemplo, firewalls de camada 3, NSGs (Grupos de Segurança de Rede) e Links Privados do Azure são bons exemplos de mecanismos que podem ser usados. No entanto, as políticas de acesso condicional baseadas em localização na ID do Microsoft Entra operam na camada do aplicativo e são consideradas insuficientes para essa finalidade.

Essas políticas de isolamento de rede devem obstruir a linha de visão do mecanismo de execução de nuvem dos fluxos de dados para armazenamentos de dados confidenciais (uma vez que o mecanismo de nuvem é executado na Internet pública). A conectividade dos fluxos de dados com esses armazenamentos de dados é forçada a se originar de dentro de uma das redes permitidas associando conexões a um gateway de dados local ou gateway de dados VNet. Uma característica de execução importante dos fluxos de dados é que a avaliação baseada em nuvem e a avaliação baseada em gateway nunca são misturadas. Se um fluxo de dados precisar acessar um armazenamento de dados isolado de rede (e, portanto, estiver associado a um gateway), todo o acesso a dados será necessário para fluir pelo gateway. Além disso, como os gateways residem fisicamente em redes controladas pelo inquilino do usuário, eles cumprem as restrições de nível de rede, como firewalls e soluções de proteção DLP (Prevenção contra Perda de Dados). Essas restrições tornam os ambientes de gateway tão seguros e seguros quanto qualquer dispositivo gerenciado corporativo e reduzem os riscos associados à execução arbitrária de código em um ambiente de nuvem.

Vale a pena observar que o isolamento de rede deve ser aplicado a todos os armazenamentos de dados que possam conter dados confidenciais. Considere um exemplo em que um usuário cria um fluxo de dados para ler dados do OneDrive for Business no Power BI. Em seguida, o usuário cria um fluxo de dados vinculado para transformar os dados no Power BI em entidades downstream. Nesse cenário, não é suficiente apenas isolar o OneDrive for Business para redes confiáveis. Como os dados confidenciais também podem residir no Power BI, é importante isolar esses dados habilitando links privados e desabilitando o acesso público à Internet para o Power BI. Saiba mais sobre o acesso seguro ao Power BI usando pontos de extremidade privados.

Forçar a execução do gateway

A meta de isolar o armazenamento de dados confidenciais em redes selecionadas é forçar a origem do acesso de volta a redes confiáveis, para que as políticas existentes que regem dispositivos gerenciados possam ser usadas para controlar a movimentação de dados de fluxos de dados. Em determinados casos, uma solução de isolamento de rede completa pode levar tempo para desenvolver, testar e implantar. Como alternativa, você pode abrir um tíquete de suporte de fluxos de dados para aplicar uma política para toda a organização que desative o Mashup Engine. Essa política afeta todas as avaliações de consulta que usam o Mecanismo de Mashup do Power Query Online. Os recursos afetados incluem:

• Fluxos de dados de malha
• Fluxos de dados do Power Platform
• Fluxos de dados de estruturação do Azure Data Factory
• Fluxos de dados no Dynamics 365 (Customer Insights, Gerenciamento inteligente de pedidos e assim por diante)
• Importação rápida do Power BI do SharePoint

Após a aplicação da política, toda a execução baseada em nuvem falha com o seguinte erro: Cloud evaluation request denied based on tenant policies. Please use a data gateway and try again. esse erro força efetivamente todas as avaliações de consulta no locatário a ocorrer em gateways, sem primeiro implementar uma solução completa de isolamento de rede. Observe que a política é aplicada a todo o locatário e não a um subconjunto de cargas de trabalho. Essa política significa que as cargas de trabalho existentes falham imediatamente e exigem intervenção manual para converter para execução em gateways. As organizações que aplicam essa política também devem garantir que tenham capacidade suficiente em seus clusters de gateway para acomodar todas as suas cargas de trabalho.

Isolamento de locatário

Para a maioria dos armazenamentos de dados na camada de SaaS (software como serviço), como o Fabric Lakehouse e o Power Platform Dataverse, geralmente há um ponto de extremidade multilocatário com o qual você se comunica para obter acesso aos dados. Esses pontos de extremidade são comuns a todos os usuários do serviço, portanto, podem ser difíceis de isolar e proteger apenas usando técnicas de isolamento de rede (Camada 3). A abordagem recomendada para esse tipo de armazenamento de dados é usar políticas de Camada 7, normalmente fornecidas pela ID do Microsoft Entra:

• Permitir somente a autenticação da ID do Microsoft Entra. Remova esquemas anônimos e de autenticação de nome de usuário/senha do armazenamento de dados.
• Use políticas de localização para permitir a entrada no locatário protegido somente de dispositivos gerenciados. Saiba mais.
• Não permita logons de locatários desconhecidos de dispositivos gerenciados, usando restrições de locatário do Microsoft Entra ID. Use restrições de locatário para gerenciar o acesso a aplicativos SaaS. Saiba mais.

Essa abordagem restringe o acesso aos armazenamentos de dados confidenciais do locatário a um conjunto de dispositivos gerenciados em que a entrada em outro locatário não é permitida, isolando efetivamente a movimentação de dados no locatário.

Roteiro

A lista a seguir contém alguns dos recursos que estão atualmente planejados para ajudar as organizações a gerenciar melhor os riscos de exfiltração de dados no Fabric:

• Lista de permissões de conexão da fonte de dados: permite que os administradores de locatário do Fabric controlem os tipos de conectores que podem ser usados dentro do locatário e os pontos de extremidade aos quais os conectores podem se conectar.
• Auditoria de uso de conexão: suporte para auditoria de logs que acompanham a criação, atualização, exclusão e uso da conexão.