Policyer for hindring av tap av data (DLP)
Hindring av datatap er avgjørende for å sørge for datasikkerhet og forskriftssamsvar i Microsoft Power Platform-økosystemet.
Du kan opprette datapolicyer som kan fungere som beskyttelsessperrer for å redusere risikoen for at brukere utilsiktet eksponerer organisasjonsdata. En kjernekomponent i Power Apps, Power Automate og Microsoft Copilot Studio er bruken av koblinger til å regne opp, fylle inn, sende og hente data. Datapolicyer i Power Platform administrasjonssenteret gjør det mulig for administratorer å kontrollere tilgangen til disse koblingene på ulike måter for å redusere risikoen i organisasjonen.
Denne oversikten beskriver enkelte høynivåkonsepter som er relatert til koblinger, og flere viktige ting du må ta hensyn til når du konfigurerer policyen eller gjør policyendringer.
Koblinger
Koblinger er typesikre representasjoner av RESTful programmeringsgrensesnitt, også kalt API-er, på det mest grunnleggende nivået. API-en for Power Platform har for eksempel flere operasjoner relatert til funksjonalitet i administrasjonssenteret for Power Platform.
Når API-en for Power Platform pakkes inn i en kobling, blir det enklere for utviklere og selvlærte utviklere å bruke API-en i lavkodebaserte apper, arbeidsflyter og chatroboter. Koblingen Power Platform for Admins V2 er for eksempel representasjonen av API-en for Power Platform, og vi ser at handlingen Få anbefalinger ganske enkelt flyttes og slippes på flyten:
Flere typer koblinger nevnes i denne artikkelen, og hver av dem har funksjoner i datapolicyer.
Sertifiserte koblinger
Sertifiserte koblinger refererer til kontakter som har gjennomgått strenge test- og sertifiseringsprosesser for å sikre at de oppfyller Microsoft standardene for sikkerhet, pålitelighet og samsvar. Disse koblingene gir brukerne en pålitelig måte å integrere med andre Microsoft tjenester og eksterne tjenester på, samtidig som dataintegriteten og sikkerheten opprettholdes.
Hvis du vil ha mer informasjon om sertifiserte koblinger, kan du se Retningslinjer for innsending til sertifisering.
Egendefinerte koblinger
Egendefinerte koblinger gjør at utviklere kan lage egne koblinger de kan integrere med eksterne systemer eller tjenester som ikke dekkes av standardsettet med sertifiserte koblinger. Egendefinerte koblinger byr på fleksibilitet og tilpassingsalternativer, men krever nøye vurdering for å sikre at de fungerer i tråd med datapolicyer og ikke går utover datasikkerheten.
Finn ut mer om oppretting og administrasjon av egendefinerte koblinger.
Virtuelle koblinger
Virtuelle koblinger er koblinger som vises i datapolicyer som administratorer kan styre, men de er ikke basert på en RESTful API. Utbredelsen av virtuelle koblinger skyldes at datapolicyer er en av de mest populære styringskontrollene i Power Platform. Flere av disse typene av på/av-funksjoner forventes å vises som regler i Miljøgrupper.
Flere virtuelle koblinger er tilgjengelige for styring av Microsoft Copilot Studio. Disse koblingene gjør at ulike funksjoner i kopiloter og chatroboter kan deaktiveres.
Utforsk virtuelle koblinger og rollen deres i hindring av datatap i Microsoft Copilot Studio.
Tilkoblinger
Når en utvikler bygger en app eller en flyt og må koble til data, kan vedkommende bruke en av koblingstypene ovenfor. Når en kobling legges til i en app første gang, opprettes en tilkobling ved hjelp av godkjenningsprotokollene som støttes av den bestemte koblingen. Disse tilkoblingene representerer en lagret legitimasjon og lagres i miljøet som er vert for appen eller flyten. Hvis du vil ha mer informasjon om godkjenning til koblinger, kan du se Koble til og godkjenne datakilder.
Utformingstid kontra kjøretid
Når en administrator velger å begrense tilgang til en hel kobling eller bestemte handlinger i en kobling, påvirkes både utvikleropplevelsen og kjøringen av tidligere opprettede apper, flyter og chatroboter.
Utvikleropplevelser, som kan kalles utformingstidsopplevelser, begrenser hvilke koblinger utviklere kan samhandle med. Hvis en datapolicy blokkerte bruken av MSN Vær-koblingen, kan ikke en utvikler lagre flyten eller appen som bruker denne, og får i stedet en feilmelding om at koblingen blokkeres av policyen.
Apper eller flyter som kjøres etter en forhåndsdefinert tidsplan, for eksempel hver natt klokken 03:00, kan gjerne kalles kjøretidsopplevelser. Hvis vi fortsetter med det tidligere eksemplet og tilkoblingen ble deaktivert av bakgrunnsprosessen skissert nedenfor, blir resultatet at appen og flyten kommer med en feilmelding om at MSN Vær-tilkoblingen er brutt og må rettes. Når utvikleren prøver å oppdatere tilkoblingen for å rette den, får vedkommende en feilmelding i utformingstidsopplevelsen om at koblingen blokkeres av en policy.
Prosess for policyendringer
Etter hvert som nye datapolicyer opprettes eller eksisterende policyer oppdateres, utløses en bestemt prosess i Power Platform-økosystemet av tjenester som bidrar til at disse policyene håndheves på tvers av hele settet med ressurser en kunde har i leieren. Denne prosessen omfatter følgende trinn.
- Datapolicykonfigurasjon lagres på kundeadministrasjonsnivå.
- Konfigurasjoner distribueres ned til hvert miljø i kundeleieren.
- Ressurser i hvert miljø (for eksempel apper, flyter og chatroboter) ser regelmessig etter oppdaterte policykonfigurasjoner.
- Når en konfigurasjonsendring registreres, blir hver app, flyt og chatrobot evaluert for å se om den bryter policyen.
- Hvis det oppstår et brudd, blir appen, flyten eller chatroboten satt i en deaktivert tilstand eller i karantene, slik at den ikke kan fungere.
- Tilkoblinger skannes. Hvis policyen blokkerer hele koblingen, settes tilkoblingen i en deaktivert tilstand, slik at den ikke kan fungere.
- Eventuelle ressurser som kjører og prøver å bruke en inaktiv tilkobling, mislykkes ved kjøretid.
Viktig!
Håndhevelse av kjøretid er avhengig av tilstanden til tilkoblingen. Hvis den ikke er deaktivert eller skannet ennå, kan tilkoblingen likevel kjøres ved kjøretid uten feil.
Ventetid
Tiden det tar å implementere datapolicyer effektivt, varierer fra kunde til kunde basert på mengden miljøer og ressurser i disse miljøene. Jo flere apper, flyter og chatroboter en kunde bruker, desto lengre tid tar det før policyendringene trer i kraft. I de mest alvorlige tilfellene er ventetiden 24 timer for full håndhevelse. I de fleste tilfeller er den under en time.