Etablere en DLP-strategi

Policyer for hindring av tap av data (DLP) fungerer som beskyttelsessperrer for å forhindre brukere fra å utilsiktet eksponere organisasjonsdata og for å beskytte informasjonssikkerheten i leieren. DLP-policyer håndhever regler for hvilke koblinger som er aktivert for hvert miljø, og hvilke koblinger som kan brukes sammen. Koblinger klassifiseres bare som enten bare forretningsdata, ingen forretningsdata tillatt eller blokkert. En kobling i gruppen bare forretningsdata kan bare brukes med andre tilkoblinger fra den gruppen i samme app eller flyt. Mer informasjon: Administrere Microsoft Power Platform: Policyer for å hindre datatap

Oppretting av DLP-policyer går hånd i hånd med miljøstrategien din.

Hurtigfakta

• Policyer for hindring av tap av data (DLP) fungerer som beskyttelsessperrer for å bidra til å forhindre at brukere viser data ved en feiltakelse.
• DLP-policyer kan knyttes til miljønivået og leiernivået, noe som gir fleksibilitet til å lage policyer som er fornuftige og ikke blokkerer høy produktivitet.
• DLP-policyer for miljøet kan ikke kan overstyre policyene for hindring av datatap for hele leieren.
• Hvis flere policyer er konfigurert for ett miljø, gjelder den mest restriktive policyen for kombinasjonen av koblinger.
• Som standard er ingen DLP-policyer implementert i leieren.
• Policyer kan ikke brukes på brukernivå, bare på miljø- eller leiernivå.
• DLP-policyer er koblingsspesifikke, men styrer ikke tilkoblingene som blir utført ved hjelp av koblingen – med andre ord er ikke DLP-policyer klar over om du bruker koblingen til å koble til et utviklings-, test- eller produksjonsmiljø.
• PowerShell- og administratorkoblinger kan behandle policyer.
• Brukere av ressurser i miljøer kan vise policyer som gjelder.

Klassifisering av koblinger

Forretningsmessige og ikke-forretningsmessige klassifiseringer tegner grenser rundt hvilke koblinger som kan brukes sammen i en gitt app eller strøm. Koblinger kan blokkeres på tvers av følgende grupper ved hjelp av DLP-policyer:

• Forretning: En gitt Power App- eller Power Automate-ressurs kan bruke én eller flere koblinger fra en forretningsgruppe. Hvis en Power App- eller Power Automate-ressurs bruker en bedriftskobling, kan den ikke bruke en ikke-bedriftskobling.
• Ikke-forretning: En gitt Power App- eller Power Automate-ressurs kan bruke én eller flere koblinger fra en ikke-forretningsgruppe. Hvis en Power App- eller Power Automate-ressurs bruker en ikke-forretningskobling, kan den ikke bruke noen forretningskoblinger.
• Blokkert: Ingen Power App- eller Power Automate-ressurs kan bruke en kobling fra en blokkert gruppe. Alle Microsoft-eide Premium-koblinger og tredjepartskoblinger (standard og Premium) kan blokkeres. Alle Microsoft-eide standardkoblinger og Common Data Service-koblinger kan ikke blokkeres.

Navnene "forretning" og "ikke-forretning" har ingen spesiell betydning, de er bare etiketter. Grupperingen av selve koblingene er av betydning, ikke navnet på gruppen de er plassert i.

Mer informasjon: Administrere Microsoft Power Platform: Koblingsklassifisering

Strategier for oppretting av policyer for hindring av datatap

Som administrator som overtar et miljø eller begynner å støtte bruk av Power Apps og Power Automate, bør DLP-policyer være en av de første tingene du konfigurerer. Dette sikrer at et grunnleggende sett med policyer er på plass, og deretter kan du fokusere på å behandle unntak og opprette målrettede DLP-policyer som implementerer disse unntakene når de er godkjent.

Vi anbefaler følgende utgangspunkt for DLP-policyer for delte bruker- og teamproduktivitetsmiljøer:

• Opprett en policy som dekker alle miljøene unntatt utvalgte (for eksempel produksjonsmiljøer). Hold de tilgjengelige koblingene i denne policyen begrenset til Office 365 og andre standard mikrotjenester, og blokker tilgang til alt annet. Denne policyen gjelder standardmiljøet, og opplæringsmiljøer du har for å kjøre interne opplæringsarrangementer. I tillegg gjelder denne policyen også for alle nye miljøer som blir opprettet.
• Opprett riktige og DLP-policyer som tillater mer, for dine delte bruker- og teamproduktivitetsmiljøer. Disse policyene kan gi utviklere mulighet til å bruke koblinger som Azure-tjenester i tillegg til Office 365-tjenestene. Hvilke koblinger som er tilgjengelige i disse miljøene, avhenger av organisasjonen din, og hvor organisasjonen lagrer forretningsdata.

Vi anbefaler følgende utgangspunkt for DLP-policyer for produksjonsmiljøer (forretningsenhet og prosjekt):

• Utelat disse miljøene fra delte bruker- og teamproduktivitetspolicyer.
• Arbeid med forretningsenheten og prosjektet for å fastsette hvilke koblinger og koblingskombinasjoner de skal bruke, og opprett en leierpolicy som bare inkluderer de valgte miljøene.
• Miljøadministratorer for disse miljøene kan bruke miljøpolicyer til å kategorisere egendefinerte koblinger bare som forretningsdata, hvis nødvendig.

I tillegg anbefaler vi også følgende:

• Opprett et minimalt antall policyer per miljø. Det finnes ikke noe strengt hierarki mellom leier- og miljøpolicyer, og ved utforming og kjøretid evalueres alle policyer som gjelder for miljøet der appen eller flyten befinner seg, sammen for å avgjøre om ressursen samsvarer med eller bryter med DLP-policyer. Flere DLP-policyer som brukes på ett miljø, fragmenterer koblingsområdet på en komplisert måte, og det kan være vanskelig å forstå problemer som dine produsenter møter.
• Administrasjon av DLP-policyer sentralt ved hjelp av policyer på klientnivå, og bruk av miljøpolicyer bare til å kategorisere egendefinerte koblinger eller i unntakstilfeller.

Med dette på plass planlegger du hvordan unntak skal håndteres. Du kan gjøre følgende:

• Avslå forespørselen.
• Legg til koblingen i standardpolicyen for hindring av datatap.
• Legg til miljøene i Alle unntatt-listen for globale standard DLP-er, og opprett en brukssaksspesifikk DLP-policy med unntaket inkludert.

Eksempel: Contosos DLP-strategi

La oss se på hvordan Contoso Corporation, vår eksempelorganisasjon for denne veiledningen, konfigurerer DLP-policyer. Oppsettet av DLP-policyene er nært knyttet til miljøstrategien deres.

Contoso-administratorer ønsker å støtte bruker- og teamproduktivitetsscenarioer og forretningsprogrammer, i tillegg til aktivitetsbehandling for Center of Excellence (CoE).

Miljøet og DLP-strategien som Contoso-administratorer har tatt i bruk, består av følgende:

1. En begrenset DLP-policy for hele leieren som gjelder for alle miljøer i leieren, unntatt bestemte miljøer de har utelukket fra policyområdet. Administratorer vil holde de tilgjengelige koblingene i denne policyen begrenset til Office 365 og andre standard mikrotjenester ved å blokkere tilgang til alt annet. Denne policyen skal også gjelde for standardmiljøet.

2. Contoso-administratorer har opprettet et annet delt miljø for brukere for å opprette apper for brukstilfeller av bruker- og teamproduktivitet. Dette miljøet har en tilknyttet DLP-policy på leiernivå som ikke er så risikoutsatt som en standardpolicy, og gir utviklere mulighet til å bruke koblinger som Azure-tjenester i tillegg til Office 365-tjenestene. Siden dette er et miljø som ikke er standard, kan administratorer aktivt kontrollere miljøprodusentlisten for den. Dette er en lagdelt tilnærmingsmåte til delte bruker- og teamproduktivitetsmiljøer og tilknyttede DLP-innstillinger.

3. For at forretningsenhetene skal opprette bransjeprogrammer har de i tillegg opprettet utviklings-, test- og produksjonsmiljøer for datterselskaper for skatt og revisjon i forskjellige land/områder. Miljøprodusentens tilgang til disse miljøene administreres nøye, og passende første- og tredjepartskoblinger gjøres tilgjengelige ved hjelp av DLP-policyer på leiernivå i konsultasjon med interessentene for forretningsenheten.

4. Utviklings-/test-/produksjonsmiljøer opprettes på samme måte for sentral bruk ved utvikling og utrulling av relevante eller riktige programmer. Disse scenarioene for forretningsprogrammer har vanligvis et godt definert sett med koblinger som må gjøres tilgjengelige for bransjer, testere og brukere i disse miljøene. Tilgang til disse koblingene administreres ved hjelp av en dedikert policy på leiernivå.

5. Contoso har også et miljø for spesielle formål som er dedikert til Center of Excellence-aktiviteter. I Contoso opprettholdes DLP-policyen for høy kontakt for miljøet for spesielle formål gitt den eksperimentelle typen teoriteambok. I dette tilfellet har leieradministratorer delegert DLP-administrasjon for dette miljøet direkte til en klarert miljøadministrator for CoE-teamet, og utelukket det fra policyer for leiernivå. Dette miljøet håndteres bare av DLP-policyen på miljønivå, som er et unntak i stedet for regelen hos Contoso.

Som forventet, blir alle nye miljøer som opprettes i Contoso, tilordnet til den opprinnelige policyen for alle miljøer.

Dette oppsettet av leierbaserte DLP-policyer forhindrer ikke at miljøadministratorer kan etablere egne DLP-policyer på miljønivå, hvis de vil introdusere flere begrensninger eller klassifisere egendefinerte koblinger.

Konfigurer datapolicyer

1. Opprett policyen i Power Platform-administrasjonssenteret. Mer informasjon: Administrer datapolicyer

2. Bruk DLP SDK til å legge til egendefinerte koblinger i en policy for hindring av datatap.

Kommuniser organisasjonens DLP-policyer klart til produsenter

Opprett et SharePoint-område eller en wiki som klart kommuniserer:

• Policyer for hindring av datatap på leier- og nøkkelmiljønivå (for eksempel standardmiljø, prøvemiljø) som håndheves i organisasjonen, inkludert lister over koblinger klassifisert som forretning, ikke-forretning og blokkert.
• Administratorgruppens e-post-ID, slik at produsenter kan ta kontakt for unntaktsscenarioer. Administratorer kan for eksempel hjelpe utviklere med overholdelse ved å redigere en eksisterende DLP-policy, flytte løsningen til et annet miljø, opprette et nytt miljø og en ny DLP-policy og flytte utvikleren og ressursen til det nye miljøet.

Kommuniser også klart organisasjonens miljøstrategi til utviklere.