Implementering af DLP i Microsoft 365: regler, undtagelser og bedste praksis

For korrekt at implementere Forebyggelse af datatab (DLP) i Microsoft 365 Det handler ikke bare om at aktivere et par politikker og krydse fingre. Det kræver en dyb forståelse af, hvilke data du håndterer, hvem der bruger dem, hvor de bevæger sig hen, og virkningen af ​​at blokere eller tillade bestemte handlinger. Hvis en DLP-politik ikke er designet med omtanke, kan den stoppe vigtige forretningsprocesser, generere tonsvis af falske positiver og ende med at blive deaktiveret, "så folk kan arbejde".

I denne artikel vil jeg på en meget udførlig måde forklare, hvordan man griber det an DLP-implementering i Microsoft 365 (Exchange, SharePoint, OneDrive, Teams, enheder, cloud-applikationer og webtrafik), hvordan regler, betingelser, handlinger og undtagelserOg hvilken strategi man skal følge for at implementere den uden at forstyrre den daglige drift. Den er rettet mod virkelige miljøer med regler, brugere der har travlt, og IT-teams der ikke har tid at spilde.

Grundlæggende DLP-koncepter i Microsoft 365 og Microsoft Purview

I Microsoft 365-økosystemet er DLP-funktionalitet integreret i Microsoft Purviewsom er paraplyen for compliance, informationsbeskyttelse og datastyring. Fra Purview-portalen kan du oprette politikker, der opdage, overvåge og beskytte fortrolige data på flere steder og i flere scenarier:

• Virksomhedsapplikationer og -enhederExchange Online-e-mail, SharePoint-websteder, OneDrive-konti, Teams-chats og -kanaler, Office-applikationer (Word, Excel, PowerPoint), Windows 10/11- og macOS-enheder, lokale fillagre og lokale SharePoint-, Fabric- og Power BI-arbejdsområder, Microsoft 365 Copilot, integrerede SaaS-applikationer via Defender til cloud-apps.
• Webtrafik inspiceretdata, der sendes ud over netværket og via Microsoft Edge til virksomheder ikke-administrerede cloud-applikationer, såsom lagringstjenester, samarbejdsværktøjer eller generative AI-platforme (ChatGPT, Google Gemini, DeepSeek osv.).

Disse direktiver bruger avanceret indholdsanalyse, der går langt ud over blot at søge efter tekststrenge. De kombinerer typer af fortrolige oplysninger (såsom kreditkort, personlige sundhedsdata, nationale identifikatorer, klassifikatorer, der kan trænes, præcis datamatchning, navngivne enheder, legitimationsoplysninger...) med brugskontekst (hvem deler, med hvem, fra hvilken applikation eller enhed, til hvilket domæne osv.). Derfra udløses automatiserede handlinger: blokere, revidere, kryptere, underrette, kræve begrundelseflyttes i karantæne osv.

Før du starter: Licenser, tilladelser og nøglekomponenter

For at implementere DLP seriøst, skal du først gennemgå det. licenser og tilladelserMange af de avancerede funktioner (f.eks. endpoint DLP, avanceret klassificering, EDM, træningsbare klassifikatorer eller inspiceret webtrafik) er knyttet til Microsoft 365- og Microsoft Purview-abonnementer mellem- til højpris (E5, compliance-tilføjelser osv.). Det anbefales at gennemgå Microsoft 365-sikkerheds- og compliance-licensvejledningen, da mulighederne, selv inden for den samme funktion, varierer afhængigt af planen.

Med hensyn til tilladelser skal den konto, der opretter og administrerer politikker, tilhøre rollegrupper som f.eks. Compliance-administrator, Compliance-dataadministrator, Informationsbeskyttelsesadministrator eller SikkerhedsadministratorDerudover er der specifikke, detaljerede DLP- og informationsbeskyttelsesroller (administrator, analytiker, efterforsker, læser), der tillader fordeling af ansvar og begrænsning af adgang i henhold til princippet om mindst mulige privilegier. Denne adskillelse er afgørende, når disse faktorer kommer i spil. meget følsomme data og revisioner.

En anden vigtig komponent er administrative enheder Microsoft Purview giver dig mulighed for at segmentere administrationsomfanget efter regioner, datterselskaber, afdelinger eller brugergrupper, så en regional administrator kun administrerer politikker for sin del af virksomheden. DLP-politikker kan begrænses til disse enheder for at sikre overholdelse af regler. organisatoriske og regulatoriske grænser.

Planlægning af implementeringen af ​​DLP: interessenter, data og strategi

En solid DLP-implementering starter altid med en fase af struktureret planlægningDet er her, tingene ofte går galt, hvis man går for hurtigt frem. Der er fire elementer, du skal afstemme fra starten: nøglepersoner, datakategorier, beskyttelsesmål og implementeringsplan.

Identifikation af interessenter

Det er ikke nok for IT at bestemme, hvad der blokeres, og hvad der ikke gør. DLP-politikker påvirker tværfaglige forretningsprocesser, så alle skal være involveret. compliance, juridisk, risici, sikkerhed, dataejere og forretningDet er dem, der kan:

• Liste over regler, love og standarder der gælder (GDPR, HIPAA, CCPA, finansielle bestemmelser, sektorbestemmelser osv.).
• Definer kategorier af følsomme oplysninger prioriterede områder (finanser, sundhed, privatliv, intellektuel ejendomsret, personoplysninger).
• Beskriv forretningsprocesser hvor disse data bruges (fakturering, revision, kundeservice, HR, forskning og udvikling, support osv.).
• Bestem qué risikoadfærd De skal begrænses (ekstern afsendelse, brug af uautoriserede clouds, kopiering til USB, udskrivning, indsættelse på AI-websteder osv.).
• Indstil beskyttelsesprioritetHvilke typer data og processer bør dækkes først.
• Design gennemgangs- og svarproces Som svar på DLP-advarsler: hvem undersøger, hvem træffer beslutninger, svartider og eskaleringsflow.

I praksis konkluderer mange organisationer, at efterspørgslen primært er efter overholdelse af lovgivningen (beskyttelse af personlige, økonomiske, kliniske data…) og i mindre grad beskyttelse af intellektuel ejendomsret. Begge dimensioner bør være til stede i din strategi, men med forskellig vægtning afhængigt af din sektor.

Beskriv kategorierne af fortrolige oplysninger

Det næste trin er at definere, ved hjælp af forretningsterminologi, hvilke data der falder ind under hver kategori. Microsoft Purview skelner blandt andet mellem data økonomisk, sundhedsmæssig, privatlivsmæssig og personligMen du er nødt til at oversætte det til din egen virkelighed. Typiske eksempler:

• "Vi opførte os som dataansvarligeDerfor skal vi indføre kontrol over alle interessentdata og finansielle data, som vores kunder giver os.”
• "Vores prioritet er at beskytte tegninger, kildekode, teknisk dokumentation og forsknings- og udviklingsstudier, samt at forhindre nøgler og adgangskoder i at forlade systemet.”

Denne definition stemmer derefter overens med typer af fortrolige oplysninger native data (kreditkortnumre, IBAN, CPR-nummer, amerikanske, EU-personoplysninger osv.), træningsbare klassifikatorer (f.eks. "ansættelseskontrakter", "netværksdokumentation"), nøjagtig datamatchning for stamdata eller kundedata og fortrolighedsetiketter.

Beskyttelsesmål og lækagetolerance

Når kategorierne er klare, og processerne er identificeret, skal interessenterne definere specifikke mål og risikotoleranceNogle centrale spørgsmål:

• Hvilke regler skal jeg påvise overholdelse af, og med hvilken detaljeringsgrad af dokumentation?
• Hvad Denne type lækage er uacceptabel. (for eksempel aldrig sende kreditkort ud, aldrig poste lægejournaler i skyen osv.)?
• I hvilken grad er jeg villig til at acceptere falske positive Eller indflydelse på produktiviteten til gengæld for mere beskyttelse?
• I hvilke tilfælde skal brugerne kunne ugyldiggøre en blok Hvilke er berettigede, og hvilke er ikke?

Typisk eksempel: Sikkerhed og juridiske bestemmelser kræver "nul lækage" af kreditkortnumre uden for organisationen, men det interne revisionsområde Du skal sende dem til eksterne revisorer periodisk. Hvis du anvender en hård blokering uden undtagelser, afbryder du processen og genererer ekstra omkostninger. Løsningen involverer at kombinere generel blokade med kontrollerede undtagelser (visse brugere eller grupper, kun-revisionstilstande, tagging og kryptering, tilladte domæner osv.). Hændelser som f.eks. lækage, der afslørede brugerdata De illustrerer den reelle risiko, og hvorfor det er vigtigt at planlægge for undtagelser.

Definer implementeringsplanen

Med fundamentet klart, er det tid til at udforme en plan med starttilstand, måltilstand og mellemliggende trin. En komplet plan omfatter typisk:

• Kort over Nuværende situation: hvilke data er tilgængelige, hvor de er placeret (M365, lokale systemer, tredjepartsclouds), hvilke beskyttelser der findes, hvad der deles.
• Tilgang til opdage og klassificere Data: Purview-dataklassificering, indholds- og aktivitetsudforsker, informationsanalysator til lokale lagre, integration med Defender til cloud-apps osv.
• Strategi direktivdesignImplementeringsrækkefølge (efter platform, efter brugergruppe, efter datatype), skabeloner der skal bruges, prioriterede scenarier.
• Plan of tekniske forudsætningerWindows- og macOS-versioner, installation af endpoint-agent, analysatorkonfiguration til lokale lagre, browserudvidelse til Chrome/Firefox, nødvendige KB'er osv.
• Sekvens af simuleringstilstand → simulering med hints → fuld applikationmed klare kriterier for at gå videre til næste fase.
• Plan of træning og kommunikation til slutbrugeren: beskeder, ofte stillede spørgsmål, eksempler, forklaring af forslag til politikker og årsagerne til ændringerne.
• cyklus af løbende gennemgang og justering: gennemgangsfrekvens, rapportbrug, aktivitetsexplorer, advarsler og telemetri til finjustering.

Afsløring af fortrolige data og klassificering

Før du beslutter dig for, hvad du skal blokere, bør du vide Hvilke følsomme data har du, og hvor er de gemt?Det er her, at flere funktioner i Microsoft Purview kommer i spil:

• dataklassificering med grafiske og statistiske repræsentationer af typer af fortrolige oplysninger, der er registreret i M365 og, udvidet, i tredjepartsclouds og on-premises.
• Indholdsudforsker for at se, hvor de elementer, der indeholder bestemte typer oplysninger eller fortrolighedsmærkater, er placeret.
• Aktivitetsudforsker at gennemgå, hvad der gøres med disse elementer: hvem åbner dem, deler dem, flytter dem, tagger dem osv.
• Informationsbeskyttelsesanalysator at undersøge lokale lagre (fildelinger, lokalt SharePoint osv.) og anvende klassificering og beskyttelse.
• Integration med Defender til cloud-apps at finde, klassificere og mærke data i cloud-lagring som f.eks. Box eller Google Drive.

Mens du definerer din strategi, kan du begynde gradvist at beskytte med manuel, automatisk og standardmærkningFor eksempel kan du konfigurere fortrolighedsetiketter med krypteringshandlinger, indholdsmarkeringer, adgangsbegrænsninger og obligatorisk begrundelse ved nedgradering. Derefter forbinder du disse etiketter med DLP-politikker, der bruger dem som en betingelse ("hvis dokumentet er mærket 'Ekstremt fortroligt', må ekstern deling, udskrivning eller kopiering til USB ikke tillades").

Arkitektur af en DLP-politik: placeringer, betingelser, handlinger og undtagelser

Microsoft Purviews DLP-politikker deler en fælles struktur Dette gælder for e-mail, SharePoint, OneDrive og Teams, samt enheder, cloud-applikationer og webtrafik. Hver politik definerer:

• Hvad vil du overvåge? (foruddefineret skabelon eller brugerdefineret direktiv).
• Administrativt omfang (fuldstændig administrativ enhed eller delmængde).
• steder som det gælder for (Exchange, SharePoint, OneDrive, Teams, Enheder, lokale lagre, Fabric/Power BI, Copilot, Defender til cloud-apps, webtrafik).
• Betingelser der skal være opfyldt (typer af fortrolige oplysninger, etiketter, hvem der sender og modtager, domæner, størrelse, adgangskodebeskyttelse osv.).
• undtagelser (de samme betingelser, men omvendt: afsendere, modtagere, placering osv., som skal udelukkes fra reglen).
• Acciones der udføres, når betingelsen er opfyldt (blokering, blokering med tilsidesættelse, kun revision, kryptering, omdirigering, karantæne, vis politikhints, ændring af overskrifter, indsættelse af tekst foran emnet osv.).

Accepterede placeringer og omfang

I guiden til oprettelse af politikker vælger du, hvor Purview skal placeres. Overvåg og anvend kontrollerHver lokation har sine egne muligheder for inkludering/ekskludering:

Beliggenhed	Omfangsfiltrering
Exchange Online Mail	Efter brugere, grupper og distributionsgrupper.
SharePoint-websteder	Via specifikke websteder eller dem alle.
OneDrive-konti	Efter individuelle konti eller distributionsgrupper.
Teams-beskeder (chats og kanaler)	Af brugere eller grupper.
Windows 10/11 og macOS-enheder	Efter brugere og grupper, og efter enheder og grupper af enheder.
Defender til cloud-apps	Pr. instans af cloud-applikation.
Lokale lagre	Efter filstier eller mapper.
Fabric og Power BI	Efter arbejdsområder.
Microsoft 365 Copilot	Af brugere eller grupper.

Dette detaljeringsniveau giver dig mulighed for at oprette, for eksempel, en politik, der kun påvirker interne revisorer deres arbejdssteder eller en endpoint-politik for callcenterteams og for eksempel forhindre dem i at vedhæfte bestemte typer filer eller data til e-mails eller chats.

Betingelser og undtagelser: hvordan scenarier detekteres

den condiciones Betingelserne i en DLP-regel definerer det datamønster og den kontekst, der skal være opfyldt for at udløse en handling. I Exchange, SharePoint, OneDrive og Teams er der et stort antal tilgængelige betingelser; nogle fokuserer på afsendere/modtagere, andre på indhold, emne, vedhæftede filer eller meddelelsesegenskaber. For hver betingelse er der normalt en tilsvarende, såsom en betingelse. undtagelse, som du kan bruge til at forfine og undgå falske positiver.

Nogle vigtige grupper af betingelser i Exchange (også gyldige som undtagelser):

• Remitentes"Afsender er", "Afsender er medlem af", "Afsenderens domæne er", "Afsenderens omfang (internt/eksternt)", egenskaber. Indtast afsender-ID, der indeholder ord eller matcher mønstre, afsenderadresse, der indeholder ord eller matcher regulære udtryk. Derudover kan du vælge, om evalueringen skal udføres på headeradresse, SMTP-konvolutten eller begge dele.
• modtagere"Modtageren er", "Modtagerens domæne er", "Sendt til medlemmet af", egenskaber såsom modtager-ID, unikke modtagerantal, modtagerdomæneantal og modtageromfang (internt/eksternt). Nogle udløsere gaffel af beskeden (den leveres kun til nogle af modtagerne).
• Indhold, emne og brødtekstemne eller brødtekst, der indeholder ord eller mønstre; indhold, der indeholder typer af fortrolige oplysninger; indhold uden en fortrolighedsetiket; kombination af emne eller brødtekst med regulære udtryk.
• Vedhæftede filerAdgangskodebeskyttede vedhæftede filer, specifikke filtypenavne, ukendte vedhæftede filer eller vedhæftede filer, hvis analyse overskrider grænserne, dokumentnavn, der indeholder ord eller mønstre, brugerdefinerede egenskaber, størrelse på vedhæftede filer, indhold af vedhæftede filer, der indeholder ord eller mønstre.
• Meddelelsesegenskaber: vigtighed, tegnsæt, beskeder med ugyldiggørelse fra tidligere afsender, beskedtype (automatisk svar, videresendelse, kryptering, kalender, telefonsvarer, IRM osv.), beskedstørrelse.

For eksempel kan du oprette en regel, der matcher, når en intern e-mail En brugers e-mail med emnelinjen "regnskab" og en vedhæftet Excel-fil større end X MB sendes til et ikke-godkendt eksternt domæne, og regnearket indeholder visse typer fortrolige oplysninger. Omvendt kan en undtagelse udelukke en gruppe af eksterne revisorer allerede et specifikt socialt domæne, der tillader den kommunikation.

Tilgængelige handlinger: blokering, kryptering, omdirigering og mere

Når betingelserne er opfyldt (og der ikke gælder undtagelser), udfører reglen en eller flere aktionerNogle er udelukkende relateret til e-mailtransport, mens andre påvirker, hvordan indhold kan tilgås i Microsoft 365-tjenester.

• Bloker adgang eller krypter indhold på M365-lokationer ved hjælp af RMS-skabeloner (BlockAccess og tilhørende omfang).
• Omdiriger Beskeder til bestemte brugere uden at levere til de oprindelige modtagere eller underrette afsenderen (nyttigt til karantæne efter regler).
• Send igen til godkendelse til afsenderens leder eller til bestemte godkendere (moderering).
• tilføje modtagere i Til/Cc/Bcc eller tilføj direkte til afsenderens administrator.
• Rediger overskriftertilføj (SetHeader) eller fjern (RemoveHeader) specifikke headerfelter.
• Rediger emnetTilføj tekst for at markere følsomme e-mails eller endda erstatte/omskrive mønstre i emnelinjen.
• Anvend HTML-ansvarsfraskrivelser i beskedens brødtekst, med placeringsmuligheder (start/slut) og alternativ adfærd, hvis klienten ikke understøtter den pågældende indsættelse.
• Fjern kryptering anvendt af Purview når det er relevant (RemoveRMSTemplate) eller omvendt, anvende brandskabeloner i krypterede beskeder.
• Påbud om brug af en krypteret beskedportal for eksterne modtagere.
• Send beskeden til karantæne hostet på Microsoft 365.

I den specifikke kontekst af "at tillade krypteret indhold og blokere ukrypteret indhold" kan du bruge kombinationen af indholdsbetingelser (typer af fortrolige oplysninger), kontrollerer om "indholdet er tagget/krypteret", og omdirigerings- eller blokeringshandlinger. Hvis du kun ønsker, at en e-mail skal blokeres, når CPR-nummeret sendes i almindelig tekst, skal du sikre dig, at betingelsen eller undtagelsen tager højde for tilstedeværelsen af ​​et tag eller en anvendt kryptering, og at krypteringstransportflowet (f.eks. automatisk tagbaseret kryptering) finder sted, før blokeringsreglen evalueres.

Endpoint DLP: Enheder, ekskluderede ruter og avanceret klassificering

Den mest kraftfulde (og samtidig følsomme) del af DLP i Microsoft 365 er komponenten af Forbindelsespunkt, som fører tilsyn med arkiveringsaktiviteter i Windows 10/11 og macOSHer ser du ikke kun e-mails eller websteder, men alle handlinger på filer på enheden: kopiering til USB, kopiering til netværksdelinger, udskrivning, kopiering til udklipsholder, upload til cloud-tjenester, brug af Bluetooth, RDP osv.

Fra de centrale indstillinger Fra DLP-forbindelsespunktet i Purview-portalen kan du justere:

• Avanceret klassificering (cloud-implementering af teknologier som EDM, træningsbare klassifikatorer, OCR, navngivne enheder), med mulighed for at begrænse den daglige båndbredde pr. enhed.
• Avanceret etiketbaseret beskyttelsehvilket giver dig mulighed for at arbejde med taggede filer (selv ikke-Office- og PDF-filer) i en ukrypteret tilstand lokalt, men sikrer, at de krypteres lige før de forlader enheden.
• Udelukkelse af filsti For at reducere støj og belastning: specifikke mønstre og miljøvariabler i Windows, anbefalede stier i macOS. Nogle stier er som standard udeladt (midlertidige mapper, browsercacher osv.).
• Dækning af delte netværksressourcer og udelukkelser, samt interaktion med lokale DLP-lagre og Just-In-Time-beskyttelse.
• Begrænsede applikationer og applikationsgrupper: samlinger af applikationer, hvis handlinger på beskyttede filer du kan revidere eller blokere (inklusive webvarianter, der tilgås fra Edge).
• Bluetooth er ikke tilladt, ikke-understøttede filudvidelserUSB-enhedsgrupper, printergrupper og netværksdelingsgrupper for finjusteret kontrol.
• VPN-konfiguration: Anvend forskellige handlinger, når trafik passerer gennem et specifikt virksomhedsnetværk.

Hvis du aktiverer avanceret klassificeringBemærk størrelsesgrænserne (64 MB for tekst, 50 MB for billeder med OCR) og kompatibilitet med Windows-versioner. Når den konfigurerede båndbreddegrænse overskrides, stopper klienten med at sende indhold til skyen og vender tilbage til reduceret lokal klassificering, så nogle avancerede filtyper registreres muligvis ikke, før båndbreddegrænsen falder. Se [link til relevant dokumentation] for problemer med slutpunkter og privatliv. Sådan styrer du telemetri i Windows 11.

Applikationskontrol, cloudlagring og generativ AI

Et stadig mere kritisk scenarie er at forhindre følsomme data i at ende i uautoriserede applikationer (tredjeparts-clouds, synkroniseringsklienter, desktop-apps eller uautoriserede browsere) og frem for alt, som de holder sig til eller uploader til generative AI-webstederFor at opnå dette tilbyder Microsoft Purview flere kombinerede mekanismer:

• Begrænsede applikationerEn liste over eksekverbare filer (og, i forhåndsvisning, deres webgrænseflader i Edge), der, når de åbner en beskyttet fil, udløser handlinger som "kun revision", "bloker med tilsidesættelse" eller "bloker". Du kan f.eks. markere ikke-virksomhedsbaserede cloud-synkroniseringsapps som begrænsede.
• Begrænsede applikationsgrupper: sæt af apps med en ensartet begrænsningspolitik. Du kan endda oprette en "hvidliste"-model: tillad en bestemt gruppe med handlingen "Tillad", og indstil alle andre apps til at "blokere".
• Automatisk karantæneNår en begrænset app forsøger at få adgang til en følsom fil under en blokeringspolitik, kan DLP flytte filen til en lokal karantænemappe og efterlade en pladsholderbesked til brugeren, hvilket forhindrer notifikationsløkker (som det sker med nogle synkroniseringsapps, der prøver igen og igen).
• Browser- og domænebegrænsningerDefiner hvilke browsere der er tilladt (Edge som standard), og hvilke cloud-tjenestedomæner der er tillade eller blokereDette vil styre handlingerne "upload til begrænset cloud-tjenestedomæne", samt "indsæt i understøttede browsere", "udskriv websted", "kopiér webstedsdata" og "gem som".
• Domænegrupper for fortrolige tjenesterSamlinger af websteder, der modtager specifik DLP-behandling. For eksempel en forudkonfigureret gruppe til generative AI-websteder hvor du kan blokere eller kontrollere indsættelse af følsomt indhold og upload af filer.

Logikken i servicedomæner skelner mellem lister i tilstand tillade (kun disse domæner er undtaget fra restriktioner, alt andet er kontrolleret) og tilstand lås (Kun disse domæner kontrolleres eksplicit, og resten får lov til at komme igennem.) Der er en meget tydelig adfærdstabel, der kombinerer domænetilstanden (Tillad/Bloker) med den valgte DLP-handling ("Kun revision", "Bloker med tilsidesættelse", "Bloker") for at vise, om der genereres advarsler, om politikken anvendes, eller om der kun udføres revision.

Design og oprettelse af DLP-direktiver: fra intention til konfiguration

Microsoft anbefaler at starte hver politik med en instruktion om hensigtEn sætning, der i et naturligt sprog beskriver, hvad du ønsker at opnå. For eksempel: "Forhindr callcenterteamet i at sende følsomme filer til eksterne modtagere, undtagen autoriserede PDF-filer og billeder" eller "Forhindr medarbejdere i at kopiere kreditkortoplysninger til ikke-virksomhedsbaserede USB-enheder."

Derfra omsættes denne intention til politikkonfiguration:

1. Vælg skabelonen (økonomisk, medicinsk, privatliv, personlig…) eller en blank direktiv.
2. Indstil administrativt område (fuld lejer eller specifikke administrative enheder).
3. vælg placeringer destination (Exchange, SharePoint, OneDrive, Teams, enheder, webtrafik, lokale lagre osv.).
4. Definer condicionesTyper af fortrolige oplysninger, etiketter, delingskontekst (intern/ekstern), domæner, antal match, størrelse, ruter, applikationer, VPN osv.
5. konfigurering aktioner For hver regel: tillad/revider, bloker, bloker med tilsidesættelse, krypter, flyt til karantæne, begræns kun bestemte aktiviteter (kopier til USB, udskriv, indsæt osv.).
6. tilføje underretninger (e-mail til brugere, administratorer, SOC) og forslag til direktiver (pop op-meddelelser i Office, Edge og andre klienter).
7. Vælg implementeringsstatus: hold deaktiveret, simuleringstilstand, simulering med hints eller fuld aktivering.

I det praktiske tilfælde, du nævnte, hvor man kun blokerer følsomme data i ukrypterede e-mails, ville en robust tilgang være: 1) automatisk mærke og kryptere (eller kræve, at brugeren gør det), når en bestemt type data registreres, 2) anvende en DLP-regel, der blokerer afsendelsen af ​​disse data, hvis beskeden eller den vedhæftede fil ingen De har en specifik etiket eller kryptering, der kombinerer betingelser for fortrolig information med "ikke-mærket indhold" eller IRM-krypteringsattributter, og 3) bruger undtagelser for specifikke betroede domæner eller grupper.

Implementeringsstrategi: status, handlinger og omfang

En nøgle til at forhindre DLP i at blive en hovedpine er at styre de tre implementeringsakser godt: politikstatus, konfigurerede handlinger og omfang af lokationer/personerDen anbefalede tilgang er altid trinvis.

Direktivets stater

De tilgængelige stater De giver dig mulighed for at kontrollere effekten:

• Hold den slukketDen bruges, mens du udformer og gennemgår politikken. Intet evalueres eller registreres.
• Udfør direktivet i simuleringstilstandRegler evalueres, der genereres revisionshændelser og advarsler, men der anvendes ingen blokeringshandlinger eller brugernotifikationer. Ideel til at verificere den reelle indvirkning på alle systemer uden at forstyrre brugerne.
• Kør i simuleringstilstand og vis politikforslagDen samme vurdering udføres uden blokering, men nu får brugeren besked via pop op-vinduer eller kontekstuelle beskeder, og der kan sendes e-mails. Dette fungerer som en uddannelsesfase, der hjælper dem med at forstå, at deres adfærd er risikabel.
• Aktivér det med det samme: fuld compliance-tilstand, blokerings- eller begrænsningshandlinger udføres faktisk.

Du kan ændre din status, når du har brug for det, men det er bedst at holde sig til én. faseplan aftalt med virksomheden: hvor længe simuleringen skal forblive, hvilke metrikker der skal overvåges (antal matches, falske positiver, forventet effekt), hvilke tærskler berettiger skift til restriktiv tilstand.

Handlinger og alvorlighedsgrad

På enheds- og lagerplaceringer bruges handlinger som "hårdhedshåndtag"er:

• tilladeHandlingen er tilladt, men den revideres. Der er ingen automatiske notifikationer eller advarsler.
• Kun revisionLigner at tillade, men du kan tilføje notifikationer og advarsler. Dette er nyttigt til at øge bevidstheden og forberede organisationen på strengere politikker.
• Blokering med overstyringHandlingen er som standard blokeret, men brugeren kan tilsidesætte den med en begrundelse. Dette er nyttigt til at indsamle feedback på legitime sager og fejlfinde falske positiver.
• låsDer er ingen mulighed; handlingen er fuldstændig forbudt. Den skal reserveres til meget klare, aftalte og afprøvede scenarier.

I forslagene til politikker kan du bestemme, hvad begrundelsesmuligheder Visning: fritekst, en liste over foruddefinerede årsager eller en kombination af begge. Korrekt konfiguration af disse meddelelser (sprog, tone, en kort forklaring på, hvorfor systemet er blokeret, og hvad man skal gøre) forbedrer accepten betydeligt.

Omfangs- og autorisationsgrupper

El direktivets anvendelsesområde Den styres ikke kun af den generelle placering (Exchange, enheder osv.), men også af et sæt af specifikke grupper som giver dig ekstra granularitet:

• Printergrupperbegræns udskrivning af meget følsomme dokumenter til en liste over betroede printere (f.eks. kun dem i den juridiske afdeling eller det centrale arkiv).
• Flytbare USB-enhedsgrupperDefiner hvilke eksterne drev der er godkendte (f.eks. virksomhedsbackups), og hvilke der er blokeret.
• Netværksdelte ressourcegrupperDefiner hvilke netværksruter der er "sikre" lagre, og hvilke der ikke må lagre fortrolige dokumenter.
• Domænegrupper for fortrolige tjenesterGruppér websteder efter type (generativ AI, salgs-SaaS, lagring osv.) og anvend specifikke politikker.
• VPN-lister: skelne mellem adfærd, når brugeren er forbundet via virksomhedens VPN versus ved brug af et hjemmenetværk eller et offentligt netværk.

I starten er det tilrådeligt at starte med en pilotgruppe af brugere og specifikke lokationer, i stedet for at målrette hele virksomheden. Den pilotgruppe bliver en tidlig bruger og hjælper dig med at finpudse reglerne før skalering.

Overvågning, rapportering og løbende justering

Når dine politikker er på plads (selvom det kun er i simulering), vil du have en stabil strøm af telemetri som du bør vide, hvordan man læser. DLP giver adgang til adskillige dashboards og værktøjer i Microsoft Purview og Defender-portalen:

• Generel informationsside for DLPOversigt over status for politiksynkronisering, enhedsstatus, mest registrerede aktiviteter og tendenser.
• DLP-advarselspanel I Microsoft Purview og Defender-portalen: en liste over advarsler, der genereres, når en regel udløses, baseret på konfigurerede tærskler og tidsvinduer. Du kan se dem, vurdere deres alvorlighed, tildele en status (ny, under undersøgelse, løst) og spore dem.
• AktivitetsudforskerDetaljeret konsol, hvor du kan filtrere efter aktivitetstype (slutpunkt, output, DLP-aktiviteter, regler, politikker, brugertilsidesættelser osv.) og gennemgå hver hændelse med omfattende kontekst (bruger, enhed, app, domæne, matchende tekst i visse tilfælde).
• Microsoft 365 revisionslogge: centralt arkiv over begivenheder, der derefter udnyttes fra mange af disse visninger.
• Sikkerhed og overholdelse af PowerShell og Exchangespecifikke cmdlets til udtrækning af brugerdefinerede DLP-rapporter.

En særlig nyttig funktion er kontekstuel opsummering I DLPRuleMatch-hændelser kan du se teksten omkring det matchende indhold (f.eks. linjerne i nærheden af ​​et kreditkortnummer), når den relevante KB-opdatering er blevet installeret i Windows 10/11. Dette gør det nemmere at bekræfte, om matchet er legitimt eller falsk positivt. Det er også vigtigt at overvåge nye trusler, såsom... AI-drevne finansielle cybertruslerhvilket kan ændre risikomønstre og kræve justeringer.

Med disse data bør compliance- og IT-teamet etablere en løbende forbedringsløkkeJustering af placeringer, tilføjelse eller fjernelse af undtagelser, hærdning eller blødgøring af handlinger, ændring af domæne- eller applister, udvidelse af autorisationsgrupper osv. Brugeroplevelse, indsamlet gennem tilsidesættelsesbegrundelser og support, er uvurderlig for at forbedre politikker.

En velplanlagt DLP-implementering i Microsoft 365 er iterativDu starter med at lære om dine data, etiketter og politikker, teste dem med simuleringstilstande og pilotgrupper, uddanne brugerne med forslag til politikker, justere kontroller baseret på telemetri og gradvist styrke holdningen, hvor det tilføjer værdi, og virksomheden tolererer det, altid kombinere regler, velbegrundede undtagelser, fortrolighedsetiketter, kryptering og kontroller over applikationer, enheder og webtrafik for at holde data virkelig beskyttet uden at forsinke det daglige arbejde. Del denne guide, så flere brugere vil lære om emnet..