Políticas de dados

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

Pode criar políticas de dados que podem agir como proteções para ajudar a reduzir o risco de os utilizadores exporem involuntariamente dados organizacionais. Um componente central do Power Apps, do Power Automate e do Microsoft Copilot Studio é a utilização de conectores para enumerar, preencher, emitir e solicitar dados. As políticas de dados no centro de administração do Power Platform permitem que os administradores controlem o acesso a estes conectores de várias formas para ajudar a reduzir o risco na sua organização.

Esta descrição geral descreve alguns conceitos de alto nível relacionados com conectores e várias considerações importantes a ter em conta ao configurar as suas políticas ou fazer alterações às políticas.

Conectores

Os conectores, no seu nível mais básico, são representações com tipos de dados inflexíveis de interfaces de programação de aplicações restful, também conhecidas como APIs. Por exemplo, a API do Power Platform fornece várias operações relacionadas com a funcionalidade no centro de administração do Power Platform.

Ao encapsular a API do Power Platform num conector, torna-se mais fácil para os criadores e programadores cidadãos utilizarem a API nas suas aplicações de low-code, fluxos de trabalho e chatbots. Por exemplo, o conector Power Platform for Admins V2 é a representação da API do Power Platform e vemos que a ação "Obter Recomendações" é simplesmente arrastada e largada no fluxo:

Existem vários tipos de conectores mencionados neste artigo e cada um tem capacidades dentro de políticas de dados.

Conectores certificados

Os conectores certificados referem-se a conectores que foram submetidos a testes e processos de certificação rigorosos para garantir que cumprem as normas da Microsoft em termos de segurança, fiabilidade e conformidade. Estes conectores fornecem aos utilizadores um meio fiável de integração com outros serviços da Microsoft e serviços externos, mantendo simultaneamente a integridade e a segurança dos dados.

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

Conectores personalizados

Os conectores personalizados permitem que os criadores criem os seus próprios conectores para integração com sistemas ou serviços externos não abrangidos pelo conjunto padrão de conectores certificados. Apesar de oferecerem opções de flexibilidade e personalização, os conectores personalizados requerem consideração cuidadosa para garantir que estão em conformidade com as políticas de dados e não comprometem a segurança dos dados.

Mais informações sobre a criação e gestão de conectores personalizados.

Conectores virtuais

Os conectores virtuais são conectores que são mostrados em políticas de dados para os administradores controlarem, no entanto, não se baseiam numa API restful. A proliferação de conectores virtuais resultou de as políticas de dados serem um dos controlos de governação mais populares no Power Platform. Espera-se que mais destes tipos de capacidades "ativadas/desativadas" apareçam como regras dentro de Grupos de ambientes.

Vários conectores virtuais são fornecidos para governar o Microsoft Copilot Studio. Estes conectores facilitam a capacidade de desativar várias caraterísticas de Copilots e chatbots.

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

Ligações

Quando um criador está a criar uma aplicação ou um fluxo e precisa de se ligar a dados, pode utilizar um dos tipos de conector acima. Quando um conector é adicionado pela primeira vez a uma aplicação, é estabelecida uma ligação utilizando os protocolos de autenticação suportados por esse conector específico. Estas ligações representam uma credencial guardada e são armazenadas no ambiente que está a alojar a aplicação ou o fluxo. Para mais informações sobre a autenticação para conectores, consulte Ligar e autenticar a origens de dados.

Tempo de conceção versus runtime

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

As experiências de criador, muitas vezes referidas como experiências de tempo de conceção, limitam os conectores com os quais os criadores podem interagir. Se uma política de dados bloqueou a utilização do conector MSN Meteorologia, um criador não poderá guardar o respetivo fluxo ou aplicação que o utiliza e, em vez disso, recebe uma mensagem de erro a informar que o conector foi bloqueado pela política.

As experiências em que uma aplicação está a ser executada ou um fluxo está a ser executado numa agenda predefinida, como, por exemplo, todos os dias às 3h00, são muitas vezes referidas como experiências de runtime. Continuando com o exemplo anterior, se a ligação foi desativada pelo processo de fundo descrito abaixo, o resultado é que a aplicação ou o fluxo fornece uma mensagem de erro a indicar que a ligação MSN Meteorologia está quebrada e precisa de resolução. Quando o criador tenta atualizar a ligação para a corrigir, obtém um erro na experiência de tempo de conceção a indicar que o conector está bloqueado pela política.

Processo para alterações a políticas

À medida que são criadas novas políticas de dados, ou quando as políticas existentes são atualizadas, existe um processo específico que é acionado dentro do ecossistema de serviços do Power Platform que ajuda a impor essas políticas a todo o conjunto de recursos que um cliente tem no respetivo inquilino. Este processo envolve os passos a seguir.

1. A configuração da política de dados é guardada ao nível da gestão de clientes.
2. As configurações são propagadas em cascata para cada ambiente no inquilino do cliente.
3. Os recursos em cada ambiente (tais como aplicações, fluxos e chatbots) verificam periodicamente se existem configurações de política atualizadas.
4. Quando é detetada uma alteração à configuração, cada aplicação, fluxo e chatbot é avaliado para verificar se viola a política.
5. Se ocorrer uma violação, a aplicação, o fluxo ou o chatbot é colocado num estado suspenso ou em quarentena para que não possa operar.
6. As ligações são verificadas. Se a política bloquear o conector inteiro, a ligação é definida para um estado desativado para que não possa operar.
7. Todos os recursos que estão em execução e tentarem utilizar uma ligação inativa, falham em runtime.

Importante

A imposição do runtime depende do estado da ligação. Se ainda não estiver desativada ou ainda não tiver sido verificada, a ligação ainda pode ser executada em runtime sem erros.

Considerações sobre latência

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

Consulte também

Gerir políticas de prevenção de perda de dados (DLP)