Polítiques de prevenció de pèrdua de dades (DLP)

La prevenció de la pèrdua de dades (DLP) és un aspecte crític per mantenir la seguretat i el compliment de les dades dins de l'ecosistema Microsoft Power Platform .

Podeu crear polítiques de dades que puguin actuar com a barreres de seguretat per ajudar a reduir el risc que els usuaris exposin dades de l'organització sense voler. Un component bàsic de Power Apps i Power Automate Microsoft Copilot Studio és l'ús de connectors per enumerar, omplir, empènyer i treure dades. Les polítiques de dades del Power Platform centre d'administració permeten als administradors controlar l'accés a aquests connectors de diverses maneres per ajudar a reduir el risc a l'organització.

Aquesta visió general descriu alguns conceptes d'alt nivell relacionats amb els connectors i diverses consideracions importants a tenir en compte a l'hora de configurar les normes o fer canvis de política.

Connectors

Els connectors, en el seu nivell més bàsic, són representacions fortament tipificades d'interfícies de programació d'aplicacions, també conegudes com a API. Per exemple, l'API Power Platform proporciona diverses operacions relacionades amb la funcionalitat del Power Platform centre d'administració.

Quan s'embolica l'API Power Platform en un connector, és més fàcil per als creadors i desenvolupadors ciutadans utilitzar l'API a les seves aplicacions, fluxos de treball i chatbots de codi baix. Per exemple, el Power Platform for Admins connector V2 és la representació de l'API Power Platform i veiem que l'acció "Obtén recomanacions" simplement arrossega i deixa anar al flux:

Hi ha diversos tipus de connectors esmentats en aquest article, i cadascun té capacitats dins de les polítiques de dades.

Connectors certificats

Els connectors certificats es refereixen a connectors que s'han sotmès a rigorosos processos de prova i certificació per garantir que compleixen els estàndards de seguretat, fiabilitat i compliment de Microsoft. Aquests connectors proporcionen als usuaris un mitjà fiable per integrar-se amb altres serveis de Microsoft i serveis externs, tot mantenint la integritat i la seguretat de les dades.

Per obtenir més informació sobre els connectors certificats, vegeu Directrius d'enviament de certificació.

Connectors personalitzats

Els connectors personalitzats permeten als fabricants crear els seus propis connectors per integrar-los amb sistemes o serveis externs no coberts pel conjunt estàndard de connectors certificats. Tot i que ofereixen flexibilitat i opcions de personalització, els connectors personalitzats requereixen una consideració acurada per garantir que compleixen les polítiques de dades i no comprometen la seguretat de les dades.

Obteniu més informació sobre com podeu crear i administrar connectors personalitzats.

Connectors virtuals

Els connectors virtuals són connectors que es mostren a les polítiques de dades perquè els administradors els controlin, però no es basen en una API restful. La proliferació de connectors virtuals s'ha derivat del fet que les polítiques de dades són un dels controls Power Platform de governança més populars. S'espera que més d'aquests tipus de capacitats "on/off" apareguin com a regles dins dels grups d'entorn.

Es proporcionen diversos connectors virtuals per governar Microsoft Copilot Studio. Aquests connectors faciliten la possibilitat de desactivar diverses funcions de Copilots i chatbots.

Exploreu els connectors virtuals i el seu paper en la prevenció de la pèrdua de dades a Microsoft Copilot Studio.

Connexions

Quan un creador està creant una aplicació o un flux i necessita connectar-se a les dades, pot utilitzar un dels tipus de connector anteriors. Quan s'afegeix un connector a una aplicació per primera vegada, s'estableix una connexió mitjançant els protocols d'autenticació admesos per aquest connector en particular. Aquestes connexions representen una credencial desada i s'emmagatzemen a l'entorn que allotja l'aplicació o el flux. Per obtenir més informació sobre l'autenticació als connectors, vegeu Connexió i autenticació a fonts de dades.

Temps de disseny en comparació amb temps d'execució

Quan un administrador decideix limitar l'accés a un connector sencer o a accions específiques d'un connector, hi ha impactes tant en l'experiència del creador com en l'execució d'aplicacions, fluxos i chatbots creats anteriorment.

Les experiències de fabricació, sovint anomenades experiències en temps de disseny, limiten els connectors amb els quals els creadors poden interactuar. Si una política de dades ha bloquejat l'ús del connector de l'MSN Weather, un fabricant no pot desar el flux o l'aplicació que l'utilitza i, en canvi, rep un missatge d'error que indica que el connector ha estat bloquejat per la política.

Les experiències en què s'executa una aplicació o s'executa un flux segons una planificació predefinida, com ara cada dia a les 3:00 AM, sovint s'anomenen experiències en temps d'execució . Continuant amb l'exemple anterior, si la connexió s'ha desactivat pel procés en segon pla que es descriu a continuació, el resultat és que l'aplicació o el flux proporciona un missatge d'error que indica que la connexió de l'MSN Weather està trencada i necessita resolució. Quan el fabricant intenta actualitzar la seva connexió per solucionar-ho, rep un error a l'experiència en temps de disseny que el connector està bloquejat per la política.

Procés de canvis de política

A mesura que es creen noves polítiques de dades o quan s'actualitzen les polítiques existents, s'activa un procés específic dins de l'ecosistema Power Platform de serveis que ajuda a aplicar aquestes polítiques a tot el conjunt de recursos que un client té al seu inquilí. Aquest procés implica els passos següents.

1. La configuració de la política de dades es desa a nivell de gestió de clients.
2. Les configuracions es retransmeten en cascada a cada entorn de l'inquilí del client.
3. Els recursos de cada entorn (com ara aplicacions, fluxos i chatbots) comproven periòdicament si hi ha configuracions de polítiques actualitzades.
4. Quan es detecta un canvi de configuració, s'avalua cada aplicació, flux i chatbot per veure si infringeix la política.
5. Si es produeix una infracció, l'aplicació, el flux o el chatbot es posa en un estat suspès o de quarantena perquè no pugui funcionar.
6. Les connexions s'escanegen. Si la política bloqueja tot el connector, la connexió s'estableix en un estat inhabilitat perquè no pugui funcionar.
7. Tots els recursos que s'estan executant i intenten utilitzar una connexió inactiva fallen en temps d'execució.

Consideracions sobre la latència

El temps que es necessita per implementar polítiques de dades de manera efectiva varia d'un client a un altre en funció del seu volum d'entorns i recursos dins d'aquests entorns. Com més aplicacions, fluxos i chatbots tingui un client, més temps trigarà a fer efecte els canvis de la política. Per als casos més extrems, la latència per a l'aplicació completa és de 24 hores. En la majoria dels casos és en una hora.

Consulteu també

• Gestionar les polítiques de prevenció de pèrdua de dades (DLP)
• Polítiques DLP per a Power Automate