Power Platform Data Loss Prevention (DLP)

Wat is een Data Loss Prevention-beleid in Power Platform?

Een Data Loss Prevention-beleid, vaak DLP-beleid genoemd, is een governancecontrole voor connectoren in Power Platform. Beheerders bepalen welke connectoren gebruikt mogen worden en welke connectoren binnen dezelfde app, flow of agent gegevens met elkaar mogen uitwisselen.

Het doel is te voorkomen dat iemand onbedoeld bedrijfsdata van een goedgekeurde dienst naar een persoonlijke of niet-goedgekeurde dienst stuurt. Een flow die SharePoint-documenten naar een consumentenaccount kopieert, kan zo al tijdens het ontwerpen worden tegengehouden.

DLP is een misleidend brede naam als je ze los van het product leest. Het beleid controleert Power Platform-connectorgebruik. Het vervangt geen toegangsrechten, informatielabels, endpointbeveiliging of controles in de bron- en doelsystemen.

Connectorgroepen en blokkering

In klassieke data policies worden connectoren ingedeeld als business, non-business of blocked. Connectoren uit de businessgroep mogen binnen dezelfde resource niet samen met connectoren uit de non-businessgroep worden gebruikt. Geblokkeerde connectoren zijn niet beschikbaar waar het beleid geldt, voor zover het connectortype blokkering ondersteunt.

De indeling zegt niet dat een connector op zichzelf veilig of onveilig is. Ze beschrijft welke gegevensgrens de organisatie wil bewaken. Outlook en SharePoint kunnen bijvoorbeeld als business worden beschouwd, terwijl een persoonlijke opslagdienst in non-business staat.

Custom connectors vragen aparte aandacht. Hun host en acties kunnen toegang geven tot eigen API's. Beheerders moeten weten welke dienst erachter zit en hoe authenticatie en gegevensgebruik werken.

Power Platform ontwikkelt ook fijnere connectorcontroles. Beschrijf in intern beleid welke beleidsmodus wordt gebruikt en controleer actuele Microsoft-documentatie voordat je nieuwe functies breed toepast.

Scope van een beleid

Een data policy kan op tenantniveau of voor geselecteerde omgevingen gelden. Een tenantbreed basisbeleid legt een minimale grens vast. Aanvullende omgevingsregels kunnen strengere eisen toepassen op productie of gevoelige data.

Te brede uitzonderingen maken het beleid moeilijk te begrijpen. Te strenge regels kunnen makers naar onbeheerde oplossingen duwen. Test beleidswijzigingen in een gecontroleerde omgeving en bekijk welke bestaande apps, flows en agents geraakt worden.

Een beleidswijziging kan ontwerp en runtime beïnvloeden. Een resource die een verboden combinatie gebruikt, kan niet meer worden opgeslagen of uitgevoerd. Houd rekening met verwerkingstijd voordat een wijziging overal is afgedwongen.

Een uitgewerkt voorbeeld

Een HR-team bouwt een flow die personeelsdocumenten uit SharePoint leest en meldingen via Teams verstuurt. Beide connectoren staan in de businessgroep. Een maker voegt later een persoonlijke cloudopslagconnector toe om bestanden makkelijk te delen.

Omdat die connector in non-business staat, blokkeert het beleid de combinatie met SharePoint in dezelfde flow. De maker kiest daarna een goedgekeurde zakelijke opslaglocatie of vraagt een inhoudelijk beoordeelde uitzondering.

Het beleid verhindert niet dat iemand met brede SharePoint-rechten verkeerde documenten leest. Dat blijft een kwestie van bronrechten, dataminimalisatie en procesontwerp.

DLP versus andere beveiligingslagen

Least privilege bepaalt welke data een gebruiker of technische identiteit in een bronsysteem mag benaderen. DLP bepaalt welke connectoren binnen Power Platform samen gebruikt kunnen worden. Beide zijn nodig.

Data classification en sensitivity labels beschrijven de gevoeligheid en behandeling van informatie. Endpoint- en netwerkbeleid beperken andere kanalen buiten Power Platform. Auditlogs helpen achteraf onderzoeken wat gebeurde.

Een HTTP- of custom connector kan zeer verschillende eindpunten aanspreken. Gebruik waar ondersteund endpointregels en beperk de achterliggende identiteit. Vertrouw niet alleen op de zichtbare connectornaam.

Een DLP-beleid invoeren en beheren

Inventariseer eerst omgevingen, connectoren en kritieke gegevensstromen. Definieer daarna een basisindeling met vertegenwoordigers van security, platformbeheer en proceseigenaars.

Voer wijzigingen gefaseerd in. Analyseer getroffen resources, verwittig eigenaars en test herstel. Documenteer uitzonderingen met doel, eigenaar, einddatum en compenserende controles.

Monitor overtredingen en runtimefouten na iedere wijziging. Herbekijk het beleid wanneer nieuwe connectoren, agents of bedrijfsdiensten verschijnen. Een werkbaar DLP-beleid is concreet genoeg om gegevensgrenzen af te dwingen en duidelijk genoeg dat makers vooraf weten welke integraties toegestaan zijn.