Compartir por


Políticas de prevención de perda de datos (DLP).

A prevención da perda de datos (DLP) é un aspecto fundamental para manter a seguridade e o cumprimento dos datos dentro do Microsoft Power Platform ecosistema.

Podes crear políticas de datos que poidan actuar como barandillas para axudar a reducir o risco de que os usuarios expoñan datos da organización sen querer. Un compoñente principal de Power Apps, Power Automate e Microsoft Copilot Studio é o uso de conectores para enumerar, encher, enviar e extraer datos. As políticas de datos no Power Platform centro de administración permiten aos administradores controlar o acceso a estes conectores de varias maneiras para axudar a reducir o risco na súa organización.

Esta visión xeral describe algúns conceptos de alto nivel relacionados cos conectores e varias consideracións importantes que hai que ter en conta ao configurar as túas políticas ou facer cambios de políticas.

Conectores

Os conectores, no seu nivel máis básico, son representacións fortemente tipificadas de interfaces de programación de aplicacións tranquilas, tamén coñecidas como API. Por exemplo, a Power Platform API ofrece varias operacións relacionadas coa funcionalidade do Power Platform centro de administración.

Mostra unha páxina de referencia da API tranquila con parámetros de cadea de consulta opcionais.

Ao envolver a Power Platform API nun conector, faise máis doado para os creadores e os desenvolvedores cidadáns utilizar a API nas súas aplicacións, fluxos de traballo e chatbots con pouco código. Por exemplo, o conector Power Platform for Admins V2 é a representación da Power Platform API e vemos que a acción "Obter recomendacións" é simplemente arrastrar e soltar no fluxo:

Mostra o conector nun Power Automate fluxo de traballo.

Hai varios tipos de conectores mencionados neste artigo e cada un ten capacidades dentro das políticas de datos.

Conectores certificados

Os conectores certificados fan referencia a conectores que pasaron por rigorosos procesos de proba e certificación para garantir que cumpren os estándares de seguridade, fiabilidade e cumprimento de Microsoft. Estes conectores proporcionan aos usuarios un medio fiable de integración con outros Microsoft servizos e servizos externos, mantendo a integridade e seguridade dos datos.

Para obter máis información sobre conectores certificados, consulta as Directrices de envío de certificacións.

Conectores personalizados

Os conectores personalizados permiten aos fabricantes crear os seus propios conectores para integrarse con sistemas ou servizos externos non contemplados polo conxunto estándar de conectores certificados. Aínda que ofrecen flexibilidade e opcións de personalización, os conectores personalizados requiren unha consideración coidadosa para garantir que cumpran coas políticas de datos e non comprometan a seguridade dos datos.

Obtén máis información sobre a creación e a xestión de conectores personalizados.

Conectores virtuais

Os conectores virtuais son conectores que se mostran nas políticas de datos para que os administradores poidan controlar, pero non se basean nunha API tranquila. A proliferación de conectores virtuais derivou de que as políticas de datos son un dos controis de goberno máis populares en Power Platform. Espérase que máis destes tipos de capacidades de "activación/desactivación" aparezan como regras dentro de grupos ambientais.

Disponse de varios conectores virtuais para gobernar Microsoft Copilot Studio. Estes conectores facilitan a posibilidade de desactivar varias funcións de Copilots e chatbots.

Explora os conectores virtuais e o seu papel na prevención da perda de datos en Microsoft Copilot Studio.

Conexións

Cando un fabricante está a construír unha aplicación ou un fluxo e necesita conectarse aos datos, pode usar un dos tipos de conectores anteriores. Cando se engade por primeira vez un conector a unha aplicación, establécese unha conexión mediante os protocolos de autenticación admitidos por ese conector en particular. Estas conexións representan unha credencial gardada e gárdanse no entorno que aloxa a aplicación ou o fluxo. Para obter máis información acerca da autenticación en conectores, consulte Conexión e autenticación en fontes de datos.

Tempo de deseño fronte a tempo de execución

Cando un administrador decide limitar o acceso a un conector completo ou a accións específicas dun conector, hai impactos tanto na experiencia do creador como na execución de aplicacións, fluxos e chatbots creados previamente.

As experiencias de creadores, denominadas a miúdo experiencias en tempo de deseño , limitan cos que poden interactuar os creadores de conectores. Se unha política de datos bloqueou o uso do conector MSN Weather, o fabricante non pode gardar o seu fluxo ou aplicación que o utiliza e recibe unha mensaxe de erro que indica que o conector foi bloqueado pola política.

As experiencias nas que se está a executar unha aplicación ou se está a executar un fluxo nunha programación predefinida, como todos os días ás 3:00 a. m., adoitan denominarse experiencias en tempo de execución . Continuando co exemplo anterior, se a conexión foi desactivada polo proceso en segundo plano descrito a continuación, o resultado é que a aplicación ou o fluxo proporciona unha mensaxe de erro que indica que a conexión MSN Weather está rota e necesita resolución. Cando o fabricante tenta actualizar a súa conexión para solucionala, recibe un erro na experiencia de deseño de que o conector está bloqueado pola política.

Proceso de cambio de políticas

A medida que se crean novas políticas de datos ou cando se actualizan políticas existentes, hai un proceso específico que se activa dentro do Power Platform ecosistema de servizos que axuda a que esas políticas se apliquen en todo o conxunto de recursos que un cliente ten no seu inquilino. Este proceso implica os seguintes pasos.

  1. A configuración da política de datos gárdase no nivel de xestión de clientes.
  2. As configuracións están en cascada a cada ambiente do inquilino do cliente.
  3. Os recursos de cada ambiente (como aplicacións, fluxos e chatbots) comproban periodicamente se hai configuracións de políticas actualizadas.
  4. Cando se detecta un cambio de configuración, avalíase cada aplicación, fluxo e chatbot para ver se infrinxe a política.
  5. Se se produce unha infracción, a aplicación, o fluxo ou o chatbot ponse en suspendido ou corentena que non pode funcionar.
  6. As conexións son escaneadas. Se a política bloquea todo o conector, a conexión establécese nun estado desactivado para que non poida funcionar.
  7. Calquera recurso que se estea executando e intentando utilizar unha conexión inactiva falla durante a execución.

Importante

A aplicación do tempo de execución depende do estado da conexión. Se aínda non está desactivado ou aínda non foi dixitalizado, a conexión aínda se pode executar en tempo de execución sen erros.

Consideracións de latencia

O tempo que leva implementar de forma eficaz as políticas de datos varía dun cliente a outro en función do seu volume de ambientes e recursos dentro deses ambientes. Cantas máis aplicacións, fluxos e chatbots teña un cliente, máis tempo tarda en que os cambios de políticas teñan pleno efecto. Para os casos máis extremos, a latencia para a execución total é de 24 horas. Na maioría dos casos é dentro dunha hora.

Consulte tamén