Políticas de dados

As políticas de dados são um aspecto crítico da manutenção da segurança e da conformidade de dados no ecossistema de Microsoft Power Platform.

Crie políticas de dados que atuem como guardrails para ajudar a reduzir o risco de usuários exporem dados organizacionais sem querer. 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 do 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.

Quando você encapsula a API do Power Platform em um conector, fica mais fácil para os criadores e desenvolvedores cidadãos usarem a API em seus aplicativos de baixo código, fluxos de trabalho e chatbots. Por exemplo, o conector Power Platform for Admins V2 é a representação da API do Power Platform e você vê que a ação Obter recomendações é simplesmente arrastar e soltar no fluxo:

Este artigo menciona vários tipos de conectores. Cada tipo tem recursos diferentes dentro de políticas de dados.

Conectores certificados

Conectores certificados são conectores que Microsoft testes e certifica para garantir que eles atendam aos padrões de segurança, confiabilidade e conformidade da Microsoft. Esses conectores fornecem aos usuários um meio confiável de integração com outras serviços Microsoft e serviços externos, tudo isso 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 os conectores personalizados ofereçam opções de flexibilidade e personalização, eles exigem uma consideração cuidadosa para garantir que estejam em conformidade com as políticas de dados e não comprometam a segurança de dados.

Saiba mais sobre como criar e gerenciar conectores personalizados.

Conectores virtuais

Conectores virtuais são conectores que aparecem em políticas de dados para os administradores controlarem, mas não são baseados em uma API RESTful. A proliferação de conectores virtuais vem de políticas de dados sendo 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.

Microsoft fornece vários conectores virtuais para controlar Microsoft Copilot Studio. Esses conectores facilitam a capacidade de desativar vários recursos de copilotos e chatbots.

Saiba mais sobre conectores virtuais e sua função na prevenção de perda data no Microsoft Copilot Studio.

Conectores do PROTOCOLO MCP (Model Context Protocol)

Os conectores do "Protocolo de Contexto do Modelo" (MCP) são uma classe de conectores que fornecem mais metadados para revelar pontos de extremidade de APIs habilitados para MCP, conhecidos como ferramentas. Os conectores MCP estendem a funcionalidade típica do conector e permitem experiências mais avançadas para IA gerativa em Microsoft Copilot Studio.

Muitos dos conectores não desbloqueáveis no Microsoft Power Platform agora dão suporte ao MCP. Você pode gerenciar e restringir esses conectores e seus servidores MCP por meio de políticas avançadas de conector.

Conexões

Quando um criador cria um aplicativo ou um fluxo e precisa se conectar aos dados, ele pode usar um dos tipos de conector descritos anteriormente. Quando um criador adiciona pela primeira vez um conector a um aplicativo, ele estabelece uma conexão usando os protocolos de autenticação aos quais o conector dá suporte. Essas conexões representam uma credencial salva e são armazenadas dentro do ambiente que hospeda o aplicativo ou o fluxo. Para obter mais informações sobre como autenticar em conectores, consulte Conectar-se e autenticar-se a 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, ele afeta tanto a experiência do criador quanto a 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 bloquear o uso do conector do MSN Weather, um criador não poderá salvar seu fluxo ou aplicativo que usa esse conector. Em vez disso, eles recebem uma mensagem de erro informando que o conector está bloqueado pela política.

Experiências em que um aplicativo está em execução ou um fluxo está sendo executado em um agendamento predefinido, como todos os dias às 3h, geralmente são conhecidas como experiências de runtime . Continuando com o exemplo anterior, se o processo em segundo plano descrito na seção a seguir inativar a conexão, o aplicativo ou o fluxo fornecerá uma mensagem de erro informando que a conexão de clima msn 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

Quando você cria novas políticas de dados ou atualiza as políticas existentes, o ecossistema de serviços do Power Platform dispara um processo específico. Esse processo ajuda a impor essas políticas em todo o conjunto de recursos que um cliente tem em seu locatário. Esse processo envolve as seguintes etapas.

1. Salve a configuração da política de dados no nível de gerenciamento do cliente.
2. As configurações 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 for detectada, avalie cada aplicativo, fluxo e chatbot para ver se ele viola a política.
5. Se ocorrer uma violação, coloque o aplicativo, o fluxo ou o chatbot em um estado suspenso ou de quarentena para que ele não possa operar.
6. Verificar conexões. Se a política bloquear todo o conector, defina a conexão para um estado desabilitado para que a conexão não possa operar.
7. Todos os recursos que estiverem em execução e tentando usar uma conexão inativa, uma ação, um gatilho ou um servidor MCP bloqueado, falharão em runtime.

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 tenham efeito total. Para os casos mais extremos, a latência para aplicação total é de 24 horas. Na maioria dos casos, é dentro de uma hora.

Conteúdo relacionado

• Gerenciar políticas de dados
• Políticas de Dados para o Power Automate
• Políticas avançadas de conector