Del via


Politikker til forebyggelse af tab af data (DLP)

DLP (Data Loss Prevention) er et vigtigt element i forbindelse med vedligeholdelse af datasikkerhed og -overholdelse inden for Microsoft Power Platform-økosystem.

Du kan oprette datapolitikker, der kan fungere som retningslinjer for at reducere risikoen for, at brugere utilsigtet eksponerer organisationsdata. En kernekomponent i Power Apps, Power Automate og Microsoft Copilot Studio er brugen af connectorer til at optælle, udfylde, flytte og trække data. Datapolitikker i Power Platform Administration giver administratorer mulighed for at styre adgangen til disse forbindelser på forskellige måder for at reducere risikoen i organisationen.

I denne oversigt beskrives nogle grundlæggende koncepter, der vedrører forbindelser, og en række vigtige overvejelser, der skal tages i betragtning, når du konfigurerer politikker eller foretager ændringer af politikker.

Connectors

Connectorer på deres mest grundlæggende niveau er stærkt indtastede repræsentationer af restful, programprogrammeringsgrænseflader, også kendt som API'er. API'en indeholder f.eks. Power Platform flere handlinger, der vedrører funktionalitet i Power Platform Administration.

Viser en restful API-referenceside med valgfrie forespørgselsparametre.

Når API'en anvendes på en Power Platform connector, bliver det nemmere for udviklere af udviklere af lave kode at bruge API'en i deres apps, arbejdsprocesser og chatproducenter. V2-connector er f.eks. Power Platform for Admins repræsentationen af Power Platform API, og vi kan se handlingen 'Hent anbefalinger' er simpelthen at trække og slippe på flowet:

Viser connectoren i en Power Automate arbejdsproces.

Der er flere typer connectors, der er nævnt i denne artikel, og de har alle funktioner inden for datapolitikker.

Certificerede connectorer

Certificerede connectorer refererer til connectorer, der har forskellige test- og certificeringsprocesser for at sikre, at de overholder Microsofts standarder for sikkerhed, pålidelighed og overholdelse af standarder. Disse forbindelser giver brugerne en pålidelig måde at integrere sig på med andre Microsoft-tjenester og eksterne tjenester, samtidig med at dataintegritet og sikkerhed bevares.

Du kan finde flere oplysninger om certificerede connectors i Certificering af indsendelsesretningslinjer.

Brugerdefinerede connectorer

Brugerdefinerede connectorer gør det muligt for beslutningstagere at oprette deres egne connectorer, så de kan integreres med eksterne systemer eller tjenester, der ikke er omfattet af standardsættet af certificerede connectorer. Brugerdefinerede tilslutninger tilbyder fleksibilitet og tilpasningsmuligheder, men de kræver nøje overvejelser for at sikre, at de overholder datapolitikkerne og ikke svækker datasikkerheden.

Lær mere om oprette og administrere brugerdefinerede connectorer.

Virtuelle connectorer

Virtuelle connectorer er connectorer, der vises i datapolitikker, som administratorer kan styre, men de er ikke baseret på en restful API. Den måde, virtuelle forbindelser er adskilt fra, er datapolitikker, der er en af de mest populære kontrolelementer i Power Platform. Flere af disse typer "on/off"-funktioner forventes at dukke op som regler i miljøgrupper.

Der findes adskillige virtuelle connectorer, som kan styre Microsoft Copilot Studio. Disse forbindelser gør det nemmere at slå forskellige funktioner i Copilots og chatrobotter fra.

Undersøg de virtuelle forbindelser og deres rolle i forbindelse med forhindring af datatab i Microsoft Copilot Studio.

Forbindelser

Når en udvikler er i gang med at bygge en app eller et flow og har brug for at oprette forbindelse til data, kan de bruge en af ovenstående tilslutningstyper. Når en connector første gang føjes til en app, oprettes der forbindelse ved hjælp af de godkendelsesprotokoller, der understøttes af den pågældende connector. Disse forbindelser repræsenterer en gemt legitimationsoplysning og gemmes i det miljø, der er vært for appen eller flowet. Du kan få flere oplysninger i godkendelse til connectorer i Oprette forbindelse til og godkende datakilder.

Designtid versus runtime

Når en administrator vælger at begrænse adgangen til enten en hel tilslutning eller bestemte handlinger for en connector, påvirkes både maker-oplevelsen og udførelsen af tidligere oprettede apps, flow og chatbeskeder.

Oplevelse med udviklere, der ofte omtales som design-tid-erfaringer, begrænser, hvad connectorer kan arbejde med. Hvis en datapolitik har blokeret brugen af MSN Connector med hjælp fra en bruger, kan vedkommende ikke gemme det flow eller den app, der anvender denne, og i stedet modtager vedkommende en fejlmeddelelse om, at forbindelsen er blokeret af en politik.

Oplevelser, hvor en app køres, eller et flow køres efter en foruddefineret tidsplan, f.eks. hver dag kl. 3:00, omtales ofte som kørselsoplevelser. Hvis du fortsætter med eksemplet tidligere, og forbindelsen blev inaktiveret af den baggrundsproces, der er skitseret nedenfor, er resultatet, at appen eller flowet indeholder en fejlmeddelelse om, at forbindelsen MSN Vejrforbindelser er afbrudt, og at der skal findes en løsning. Når udvikleren forsøger at opdatere sin forbindelse for at rette den, får han eller hun en fejl i den designtidsoplevelse, at connectoren er blokeret af en politik.

Proces for ændringer af politikker

Efterhånden som der oprettes nye datapolitikker, eller når eksisterende politikker opdateres, er der en bestemt proces, der udløses inden for Power Platform-økosysten med tjenester, der er med til at håndhæve disse politikker på tværs af alle de ressourcer, kunden har i sin lejer. Denne proces involverer følgende trin.

  1. Konfiguration af datapolitik gemmes på kundestyringsniveau.
  2. Konfigurationer overlappes nedad til de enkelte miljøer i kunde lejen.
  3. Ressourcer i de enkelte miljøer (f.eks. apps, flows og chatdatabasen) kontrollerer jævnligt, om der er opdaterede politikkonfigurationer.
  4. Når der registreres en konfigurationsændring, evalueres hver app, et flow og en chatsession for at se, om politikken understøttes.
  5. Hvis der indtræffer et brud, sættes appen, flowet eller chatrobot i en afbrudt eller karantæne-tilstand, hvor programmet ikke kan fungere.
  6. Forbindelser er forskellige. Hvis politikken blokerer hele forbindelsen, angives forbindelsen til en deaktiveret tilstand, så den ikke kan fungere.
  7. Alle ressourcer, der kører og forsøger at bruge en inaktiv forbindelse, lykkes ikke under kørsel.

Vigtigt!

Håndhævelse af kørsel afhænger af forbindelsens tilstand. Hvis den endnu ikke er deaktiveret eller endnu ikke er aktiveret, kan forbindelsen stadig køres under kørsel uden fejl.

Ventetidsovervejelser

Den tid, det tager at implementere datapolitikker på en effektiv måde, varierer fra kunde til kunde, afhængigt af mængden af miljøer og ressourcer i de pågældende miljøer. Jo flere apps, flows og chatrobotter en kunde har, jo længere tid tager det, før politikændringer træder i kraft fuldt ud. I de mest yderligste tilfælde er ventetiden for fuld håndhævelse 24 timer. I de fleste tilfælde er det inden for en time.

Se også