Políticas de DLP no Power Platform: como proteger os dados

O maior risco do Power Platform não é o app mal feito, é o dado saindo pela porta dos fundos#

Quando uma empresa adota Power Apps e Power Automate em escala, o medo natural é técnico: app lento, fluxo que quebra, automação que dá erro. O risco real é outro e é silencioso. Um colaborador bem-intencionado cria um fluxo que lê a base de clientes no SharePoint e, para "facilitar", manda uma cópia para o Gmail pessoal, para um Google Sheets particular ou para um conector de mídia social. Ninguém teve má intenção, ninguém percebeu nada de errado, e a empresa acabou de transferir dados pessoais para fora do ambiente corporativo sem base legal, sem registro e sem controle. É esse cenário que as Políticas de DLP no Power Platform existem para impedir.

DLP significa Data Loss Prevention, ou prevenção de perda de dados. No Power Platform, essas políticas não olham para o conteúdo do dado, e sim para os conectores: os "canos" por onde a informação entra e sai de apps e fluxos. A ideia central é classificar cada conector em um de três grupos e impedir que canos de grupos diferentes sejam plugados no mesmo app ou fluxo. Este artigo explica como esses grupos funcionam, a diferença entre política de tenant e política de ambiente, como isso bloqueia exfiltração combinando conectores e por que, no Brasil, esse controle virou peça de conformidade com a LGPD.

As Políticas de DLP no Power Platform controlam conectores, não o conteúdo do dado#

Vale desfazer um mal-entendido comum. DLP em ferramentas de e-mail ou em soluções como o Microsoft Purview costuma inspecionar o conteúdo: procura um CPF, um número de cartão, uma palavra sensível na mensagem. O DLP do Power Platform trabalha em outra camada. Ele não lê o dado, ele governa os conectores, que são as integrações prontas com serviços como SharePoint, SQL Server, Dataverse, Outlook, Gmail, Twitter, Dropbox, o conector HTTP e os conectores personalizados que a própria empresa cria.

A lógica é direta: se você impedir que um app ou fluxo combine um conector que acessa dado corporativo com um conector que joga esse dado para fora, fecha a rota de vazamento na origem, sem inspecionar cada registro que trafega. É abordagem de arquitetura, não de varredura. Por isso o DLP é a primeira camada de governança que estruturamos em qualquer projeto de Power Platform: sem ela, todo o resto vira remendo.

Todo conector cai em um de três grupos: corporativo, não corporativo ou bloqueado#

O coração de uma política de DLP é a classificação de conectores. Cada conector disponível no tenant precisa estar em um destes três grupos:

Grupo	O que significa	Exemplos típicos
Corporativos (Business)	Conectores confiáveis que lidam com dado da empresa e podem conversar entre si	SharePoint, Dataverse, SQL Server, Outlook 365, Teams, OneDrive for Business
Não corporativos (Non-business)	Conectores tolerados para uso pessoal ou não crítico, isolados dos corporativos	Twitter, Facebook, serviços de e-mail pessoal, armazenamento de nuvem de consumo
Bloqueados (Blocked)	Conectores proibidos de serem usados em qualquer app ou fluxo no escopo da política	Conectores de risco alto, integrações não homologadas, o que a empresa decidir vetar

A regra que dá poder a essa classificação é simples e rígida: conectores de grupos diferentes não podem ser usados juntos no mesmo app ou fluxo. Um fluxo pode combinar SharePoint com Dataverse à vontade, porque ambos são corporativos, e pode usar dois conectores não corporativos entre si. O que ele não consegue é misturar corporativo com não corporativo na mesma automação. E um conector bloqueado simplesmente não fica disponível, o maker nem consegue selecioná-lo.

Um detalhe que costuma pegar as equipes de surpresa: existe um grupo padrão. Todo conector novo que a Microsoft lança, ou que a empresa cria, cai automaticamente no grupo definido como padrão. Se esse padrão for "não corporativo", cada novidade já entra isolada do dado sensível, que é a postura mais defensiva. Se for "corporativo", cada conector novo nasce com acesso liberado ao dado da empresa, conveniente e perigoso ao mesmo tempo. Definir esse padrão é decisão de segurança, não detalhe de configuração.

O bloqueio de combinação é o que realmente impede a exfiltração#

Para entender por que os grupos importam, siga o caminho do dado. Imagine um fluxo do Power Automate que pega a lista de leads no Dataverse. Sozinho, é inofensivo. O risco aparece quando esse mesmo fluxo tenta escrever a lista em um armazenamento pessoal ou disparar por um e-mail de consumo. Esse é o padrão clássico de exfiltração: um conector que lê dado corporativo, mais um que o exporta para fora do perímetro.

Com o Dataverse classificado como corporativo e os serviços de consumo como não corporativos, a plataforma barra a construção antes de o fluxo rodar. O maker recebe o aviso de que aquela combinação viola a política e não consegue salvar. Não é auditoria depois do fato, é trava no momento da criação. Essa é a diferença entre governança que documenta o vazamento e governança que o impede.

Dois conectores merecem atenção redobrada, porque são as portas mais largas de saída:

• O conector HTTP, que chama qualquer endereço na internet. Sem classificação adequada, é um cano aberto para qualquer destino externo. Muitas empresas o colocam direto nos bloqueados ou o restringem a ambientes específicos.
• Os conectores personalizados, criados internamente. Como a empresa mesma os define, é fácil esquecer de classificá-los, e um conector personalizado mal governado neutraliza toda a política ao seu redor.

Além da classificação em grupos, políticas mais maduras usam controles mais finos, como restringir ações específicas de um conector ou filtrar quais endpoints e URLs ele pode alcançar. Isso permite liberar o conector HTTP apenas para um domínio interno homologado, em vez de bloqueá-lo por inteiro. Esse refinamento separa uma política genérica de uma desenhada para a realidade da operação, e é parte do trabalho contínuo de governança de dados sobre a plataforma.

Uma política vale para o tenant inteiro ou para ambientes específicos#

Classificar conectores é metade da história. A outra metade é decidir onde a política se aplica. No Power Platform, o escopo de uma política de DLP pode ser definido em dois níveis, e entender a diferença evita tanto o excesso de controle quanto o buraco de segurança:

Escopo	Onde se aplica	Quando usar
Tenant	Todos os ambientes da organização, com opção de incluir ou excluir ambientes específicos	Regra de base que vale para todo mundo, como bloquear conectores de risco em qualquer lugar
Ambiente	Apenas um ou mais ambientes escolhidos	Regras específicas para um contexto, como um ambiente de produção com dado sensível que exige trava mais rígida

Na prática, o desenho recomendado combina os dois. A política de tenant estabelece o piso mínimo que ninguém pode violar, por exemplo mantendo conectores de consumo separados dos corporativos em toda a organização. Sobre esse piso, políticas de ambiente adicionam camadas mais restritivas onde o risco é maior, tipicamente na produção e em ambientes que tratam dado pessoal sensível.

Um ponto técnico costura tudo: quando mais de uma política incide sobre o mesmo ambiente, prevalece a regra mais restritiva. Se qualquer política em vigor classifica um conector como bloqueado, ele fica bloqueado, mesmo que outra o liberasse. Políticas se somam em direção a mais controle, nunca a menos, que é o comportamento desejado em segurança.

Vale um alerta sobre o ambiente padrão, o "Default Environment". Ele nasce em todo tenant e, por design, todo mundo da organização pode criar apps e fluxos ali. Sem política de DLP cobrindo esse ambiente, ele vira o ponto cego perfeito para exfiltração acidental. Governá-lo desde o primeiro dia é uma das recomendações mais repetidas de quem opera Power Platform em escala, tema que aprofundamos no guia de Power Platform com Power Apps e Automate.

DLP não é só higiene de TI, é infraestrutura de conformidade com a LGPD#

No Brasil, a conversa sobre DLP muda de tom quando entra a Lei nº 13.709/2018, a LGPD. A lei exige que a empresa adote medidas técnicas aptas a proteger dados pessoais de acessos não autorizados e de situações acidentais ou ilícitas de destruição, perda, alteração, comunicação ou difusão. Traduzindo para o Power Platform: se um colaborador consegue, com poucos cliques, mandar a base de clientes para um serviço externo não homologado, a empresa não adotou medida técnica de proteção nenhuma, e isso é exposição direta a autuação.

O DLP endereça obrigações específicas da lei de forma concreta:

Controle de DLP	O que faz	Obrigação da LGPD que apoia
Separação corporativo x não corporativo	Impede que dado pessoal saia por conectores de consumo	Segurança e prevenção de comunicação não autorizada
Bloqueio de conectores de risco	Veta integrações não homologadas em qualquer app ou fluxo	Medidas técnicas contra acesso e difusão indevidos
Escopo por ambiente	Aplica trava mais rígida onde há dado pessoal sensível	Proteção proporcional ao risco do tratamento
Filtragem de endpoints e ações	Restringe para onde o dado pode ser enviado	Controle de fluxo e responsabilização (accountability)

Vale ser honesto sobre o alcance do DLP, porque vender governança como bala de prata é desserviço. Ele não substitui base legal para o tratamento, não faz o registro das operações exigido pela lei, não responde sozinho a um pedido de eliminação de titular e não classifica o conteúdo do dado. Ele fecha uma rota de vazamento específica e importante, a da combinação de conectores, e faz isso muito bem. A conformidade completa é um conjunto maior, no qual o DLP é peça necessária, mas não suficiente. Essa articulação entre controle técnico e obrigação legal é a mesma que descrevemos para o Power BI no artigo sobre governança de dados e LGPD.

Boas práticas que separam a política que funciona da que só existe no papel#

Ter uma política de DLP criada não significa estar protegido. Muitas empresas colocam quase tudo como corporativo "para não travar ninguém" e criam uma política que não impede nada. Princípios que fazem diferença na prática:

• Comece pela postura defensiva no padrão. Deixe o grupo padrão como não corporativo, para que todo conector novo nasça isolado do dado sensível até que alguém decida promovê-lo.
• Governe o ambiente padrão desde o primeiro dia. É onde todo colaborador pode criar apps e fluxos, então é onde o risco acidental é maior.
• Trate o conector HTTP e os personalizados como itens críticos. São as portas de saída mais largas. Bloqueie ou restrinja por endpoint em vez de liberar por comodidade.
• Combine política de tenant com políticas de ambiente. Um piso mínimo para todos, camadas extras onde há dado pessoal sensível.
• Documente o porquê de cada classificação. Uma política que ninguém entende é abandonada no primeiro pedido de exceção. Registre a justificativa de cada conector movido de grupo.
• Revise periodicamente. A Microsoft lança conectores o tempo todo, e a operação muda. DLP não é projeto de uma vez, é rotina de manutenção, algo que tratamos dentro da sustentação de BI e da governança contínua da plataforma.

O erro mais comum não é técnico, é político. Times de negócio pressionam por liberação, e a TI cede conector por conector até a política virar decoração. Manter o rigor exige respaldo da liderança e um processo claro de exceção, no qual liberar um conector é decisão registrada, não favor de corredor.

Perguntas frequentes#

As Políticas de DLP no Power Platform leem o conteúdo dos dados, como um CPF? Não. O DLP do Power Platform atua sobre os conectores, não sobre o conteúdo. Ele impede combinações que abririam rota de vazamento, mas não inspeciona registro por registro. A inspeção de conteúdo é papel de outras ferramentas, como o Microsoft Purview, complementares ao DLP.

Um fluxo pode usar um conector corporativo e um não corporativo ao mesmo tempo? Não, essa é a trava central do DLP. Conectores de grupos diferentes não podem ser usados juntos no mesmo app ou fluxo. Dentro do mesmo grupo eles se combinam livremente, mas misturar corporativo com não corporativo é bloqueado na criação.

Qual é a diferença entre política de tenant e política de ambiente? A de tenant vale para toda a organização, com opção de incluir ou excluir ambientes. A de ambiente vale só para os ambientes escolhidos. O uso recomendado combina as duas, e quando várias políticas incidem sobre o mesmo ambiente prevalece a mais restritiva.

Ativar DLP já deixa minha empresa em conformidade com a LGPD? Não sozinho. O DLP é medida técnica de segurança que apoia a LGPD ao fechar a rota de exfiltração por conectores. Mas conformidade completa envolve base legal, registro das operações, atendimento a direitos do titular e classificação de dado, coisas que dependem de processo, não só de configuração.

O que acontece com o conector HTTP e com os conectores personalizados? São os pontos de maior atenção. O HTTP alcança qualquer endereço na internet, e os personalizados são fáceis de esquecer de classificar. A recomendação é bloqueá-los ou restringi-los por endpoint, porque qualquer um deles mal governado enfraquece toda a política ao redor.

Preciso configurar DLP no ambiente padrão do tenant? Sim, e com prioridade. O ambiente padrão nasce com permissão para todos os colaboradores criarem apps e fluxos, o que o torna o ponto mais provável de vazamento acidental. Deixá-lo sem política é manter aberto o maior ponto cego da plataforma.

Governança de conectores é barata perto do custo de um vazamento#

Configurar uma política de DLP no Power Platform não exige licença exótica nem projeto de meses. Exige decisão: quais conectores são confiáveis, quais são tolerados, quais são vetados e onde cada regra se aplica. É um dos controles de melhor relação entre esforço e proteção em toda a plataforma, porque fecha a rota de vazamento mais provável antes de o dado sair.

Se a sua empresa já usa Power Apps e Power Automate mas nunca definiu como os conectores são classificados, e ninguém sabe dizer se um fluxo pode mandar a base de clientes para fora, o momento de agir é antes do primeiro incidente, não depois da notificação. Fale com a gente para estruturar uma política de DLP alinhada à sua operação e às suas obrigações de LGPD.