Políticas de dados prevenção contra perdas (DLP)

A Prevenção Contra Perda de Dados (DLP) é um aspecto crítico para manter a segurança e a conformidade dos dados no ecossistema do Microsoft Power Platform.

É possível criar políticas de dados que podem atuar como grades de proteção para ajudar a reduzir os riscos de os usuários exporem dados organizacionais acidentalmente. Um componente central do Power Apps, Power Automate e Microsoft Copilot Studio é o uso de conectores para enumerar, preencher, enviar por push e extrair dados. As políticas de dados no centro de administração do Power Platform permitem que os administradores controlem o acesso a esses conectores de várias maneiras para ajudar a reduzir o risco em sua organização.

Esta visão geral descreve alguns conceitos de alto nível relacionados a conectores e várias considerações importantes a serem levadas em conta ao configurar suas políticas ou fazer alterações nelas.

Conectores

Os conectores, em seu nível mais básico, são representações fortemente tipadas de interfaces de programação de aplicativos RESTFUL, também conhecidas como APIs. Por exemplo, a API do Power Platform fornece várias operações relacionadas à funcionalidade no centro de administração do Power Platform.

Ao envolver a API do Power Platform em um conector, fica mais fácil para criadores e desenvolvedores cidadãos utilizarem a API em seus aplicativos, fluxos de trabalho e chatbots de low-code. Por exemplo, o conector V2 do Power Platform for Admins é a representação da API do Power Platform e vemos que a ação "Obter recomendações" é simplesmente arrastar e soltar no fluxo:

Há vários tipos de conectores mencionados neste artigo e cada um tem recursos dentro das políticas de dados.

Conectores certificados

Os conectores certificados referem-se a conectores que passaram por rigorosos processos de teste e certificação para garantir que atendam aos padrões da Microsoft de segurança, confiabilidade e conformidade. Esses conectores fornecem aos usuários um meio confiável de integração com outros serviços da Microsoft e serviços externos, mantendo a integridade e a segurança dos dados.

Para obter mais informações sobre conectores certificados, consulte Diretrizes de Envio de Certificação.

Conectores personalizados

Os conectores personalizados permitem que os criadores criem seus próprios conectores para integração com sistemas ou serviços externos não cobertos pelo conjunto padrão de conectores certificados. Embora ofereçam opções de flexibilidade e personalização, os conectores personalizados exigem uma consideração cuidadosa para garantir que estejam em conformidade com as políticas de dados e não comprometam a segurança dos dados.

Saiba mais sobre como criar e gerenciar conectores personalizados.

Conectores virtuais

Os conectores virtuais são conectores mostrados em políticas de dados para os administradores controlarem, mas não se baseiam em uma API restful. A proliferação de conectores virtuais decorreu do fato de as políticas de dados serem um dos controles de governança mais populares no Power Platform. Espera-se que mais desses tipos de recursos "ativar/desativar" apareçam como regras nos grupos de ambiente.

Vários conectores virtuais são fornecidos para governar o Microsoft Copilot Studio. Esses conectores facilitam a capacidade de desativar vários recursos de copilotos e chatbots.

Explore os conectores virtuais e sua função na prevenção contra perda de dados no Microsoft Copilot Studio.

Conexões

Quando um criador está criando um aplicativo ou um fluxo e precisa se conectar aos dados, ele pode usar um dos tipos de conector acima. Quando um conector é adicionado pela primeira vez a um aplicativo, uma conexão é estabelecida usando os protocolos de autenticação suportados por esse conector específico. Essas conexões representam uma credencial salva e são armazenadas no ambiente que hospeda o aplicativo ou fluxo. Para obter mais informações sobre autenticação de conectores, consulte Como conectar e autenticar em fontes de dados.

Tempo de design versus tempo de execução

Quando um administrador opta por limitar o acesso a um conector inteiro ou a ações específicas de um conector, há impactos tanto na experiência do criador quanto na execução de aplicativos, fluxos e chatbots criados anteriormente.

As experiências do criador, geralmente chamadas de experiências de tempo de design, limitam os conectores com os quais os criadores podem interagir. Se uma política de dados bloqueou o uso do conector MSN Weather, um criador não poderá salvar seu fluxo ou aplicativo que utilize isso e, em vez disso, receberá uma mensagem de erro informando que o conector foi bloqueado pela política.

As experiências em que um aplicativo está sendo executado ou um fluxo está sendo executado em um cronograma predefinido, como todos os dias às 3h, costumam ser chamadas de experiências de tempo de execução. Continuando com o exemplo anterior, se a conexão foi desativada pelo processo em segundo plano descrito abaixo, o resultado é que o aplicativo ou fluxo fornece uma mensagem de erro informando que a conexão do MSN Clima está interrompida e precisa de resolução. Quando o criador tenta atualizar sua conexão para corrigi-lo, ele recebe um erro na experiência de tempo de design de que o conector está bloqueado pela política.

Processo para alterações de política

À medida que novas políticas de dados são criadas ou quando as políticas existentes são atualizadas, há um processo específico que é acionado no ecossistema de serviços do Power Platform que ajuda a fazer com que essas políticas sejam aplicadas em todo o conjunto de recursos que um cliente tem em seu locatário. Esse processo envolve as seguintes etapas.

1. A configuração da política de dados é salva no nível de gerenciamento do cliente.
2. As configurações são em cascata para cada ambiente no locatário do cliente.
3. Os recursos em cada ambiente (como aplicativos, fluxos e chatbots) verificam periodicamente as configurações de política atualizadas.
4. Quando uma alteração de configuração é detectada, cada aplicativo, fluxo e chatbot é avaliado para verificar se viola a política.
5. Se ocorrer uma violação, o aplicativo, fluxo ou chatbot será colocado em estado suspenso ou em quarentena para que não possa operar.
6. As conexões são verificadas. Se a política bloquear o conector inteiro, a conexão será definida como um estado desabilitado para que não possa operar.
7. Todos os recursos que estão sendo executados e tentando usar uma conexão inativa, falham no tempo de execução.

Importante

A aplicação do tempo de execução depende do estado da conexão. Se ainda não estiver inativada ou ainda não tiver sido verificada, a conexão ainda poderá ser executada em tempo de execução sem erros.

Considerações de latência

O tempo necessário para implementar efetivamente as políticas de dados varia de cliente para cliente com base no volume de ambientes e recursos dentro desses ambientes. Quanto mais aplicativos, fluxos e chatbots um cliente tiver, mais tempo levará para que as alterações de política entrem em vigor. Para os casos mais extremos, a latência para aplicação total é de 24 horas. Na maioria dos casos, é dentro de uma hora.

Ver também

• Gerenciar políticas de prevenção de perda de dados
• Políticas DLP para Power Automate