Gegevensbeleid

Voorkoming van gegevensverlies (DLP) is een cruciaal aspect van het handhaven van gegevensbeveiliging en -compliance binnen het Microsoft Power Platform-ecosysteem.

U kunt gegevensbeleid opstellen dat het risico helpt verlagen om te voorkomen dat gebruikers onbedoeld organisatiegegevens vrijgeven. Een kernbestanddeel van Power Apps, Power Automate, En Microsoft Copilot Studio is het gebruik van connectors om gegevens op te sommen, in te vullen, te pushen en op te halen. Met Gegevensbeleid in het Power Platform-beheercentrum kunnen beheerders de toegang tot deze connectors op verschillende manieren beheren om de risico's in uw organisatie te helpen verminderen.

In dit overzicht worden enkele concepten op hoog niveau beschreven, die betrekking hebben op connectors en een aantal belangrijke overwegingen waarmee u rekening moet houden bij het opzetten van uw beleid of het aanbrengen van beleidswijzigingen.

Connectors

Connectors zijn op hun meest basale niveau sterk getypeerde representaties van restful Application Programming Interfaces, ook wel bekend als API's. De Power Platform-API biedt bijvoorbeeld verschillende bewerkingen met betrekking tot functionaliteit in het Power Platform-beheercentrum.

Door de Power Platform-API in een connector te verpakken, wordt het voor makers en citizen developers eenvoudiger om de API in hun low-code apps, workflows en chatbots te gebruiken. De V2-connector van Power Platform for Admins is bijvoorbeeld de weergave van de Power Platform-API en we zien dat de actie Aanbevelingen ophalen eenvoudigweg naar de stroom wordt gesleept:

In dit artikel worden verschillende soorten connectors genoemd en elk heeft mogelijkheden binnen het gegevensbeleid.

Gecertificeerde connectors

Gecertificeerde connectors verwijzen naar connectors die strenge test- en certificeringsprocessen hebben ondergaan om ervoor te zorgen dat ze voldoen aan de Microsoft-normen voor beveiliging, betrouwbaarheid en compliance. Deze connectors bieden gebruikers een betrouwbare manier om met andere Microsoft-services en externe services te integreren, terwijl de gegevensintegriteit en -beveiliging behouden blijven.

Voor meer informatie over gecertificeerde connectors gaat u naar Richtlijnen voor het indienen van certificaten.

Aangepaste connectoren

Met aangepaste connectors kunnen makers hun eigen connectors maken om met externe systemen of services die niet onder de standaardset gecertificeerde connectors vallen, te integreren. Hoewel ze flexibiliteit en aanpassingsopties bieden, moeten aangepaste connectors zorgvuldig worden overwogen om ervoor te zorgen dat ze voldoen aan het gegevensbeleid en de gegevensbeveiliging niet in gevaar brengen.

Meer informatie over het maken en beheren van aangepaste connectors.

Virtuele connectors

Virtuele connectors zijn connectors die in het gegevensbeleid worden weergegeven en door beheerders kunnen worden beheerd, maar ze zijn niet gebaseerd op een restful API. De proliferatie van virtuele connectors komt voort uit het feit dat gegevensbeleid een van de meest populaire governance-controles is in Power Platform. Er wordt verwacht dat meer van dit soort 'aan/uit'-mogelijkheden als regels naar boven zullen komen binnen Omgevingsgroepen.

Er zijn verschillende virtuele connectors beschikbaar voor het beheer van Microsoft Copilot Studio. Deze connectors vergemakkelijken de mogelijkheid om verschillende functies van Copilots en chatbots uit te schakelen.

Ontdek virtuele connectors en hun rol bij preventie van gegevensverlies in Microsoft Copilot Studio.

Connecties

Wanneer een maker een app of een stroom bouwt en verbinding moet maken met gegevens, kan hij een van de bovenstaande connectortypen gebruiken. Wanneer een connector voor het eerst aan een app wordt toegevoegd, wordt er een verbinding tot stand gebracht met behulp van de verificatieprotocollen die door die specifieke connector worden ondersteund. Deze verbindingen vertegenwoordigen een opgeslagen referentie en worden opgeslagen in de omgeving waarin de app of stroom wordt gehost. Zie Verbinding maken met en verifiëren bij gegevensbronnen voor meer informatie over verificatie voor connectors.

Ontwerptijd versus uitvoeringstijd

Wanneer een beheerder ervoor kiest de toegang tot een hele connector of tot specifieke acties van een connector te beperken, heeft dit voor zowel de makerervaring als voor de uitvoering van eerder gemaakte apps, stromen en chatbots gevolgen.

Makerervaringen, ook wel ontwerptijd-ervaringen genoemd, beperken met welke connectors makers kunnen communiceren. Als een gegevensbeleid het gebruik van de MSN Weer-connector blokkeert, kan een maker de stroom of app die hiervan gebruikmaakt niet opslaan en ontvangt hij in plaats daarvan een foutmelding dat de connector door beleid is geblokkeerd.

Ervaringen waarbij een app of een stroom wordt uitgevoerd volgens een vooraf gedefinieerd schema, bijvoorbeeld elke dag om 3:00 uur, worden vaak runtime-ervaringen genoemd. Als we doorgaan met het eerder gegeven voorbeeld: als de verbinding is geïnactiveerd door het hieronder beschreven achtergrondproces, is het resultaat dat de app of stroom een foutmelding geeft dat de MSN weer-verbinding is verbroken en moet worden opgelost. Wanneer de maker probeert de verbinding bij te werken om deze te repareren, krijgen ze tijdens het ontwerp een foutmelding dat de connector door beleid wordt geblokkeerd.

Proces voor beleidswijzigingen

Wanneer er nieuw gegevensbeleid wordt gemaakt of wanneer bestaand beleid wordt bijgewerkt, wordt er binnen het Power Platform-ecosysteem van diensten een specifiek proces in gang gezet dat ertoe bijdraagt dat dit beleid over de gehele set resources die een klant in diens tenant heeft, wordt afgedwongen. Het proces omvat de volgende stappen.

1. De configuratie van het gegevensbeleid wordt op klantbeheerniveau opgeslagen.
2. Configuraties worden trapsgewijs naar elke omgeving in de klanttenant doorgevoerd.
3. Resources in elke omgeving (zoals apps, stromen en chatbots) controleren periodiek op bijgewerkte beleidsconfiguraties.
4. Wanneer een configuratiewijziging wordt gedetecteerd, wordt elke app, stroom en chatbot geëvalueerd om te zien of deze het beleid schendt.
5. Als er een overtreding plaatsvindt, krijgt de app, flow of chatbot een status opgeschort of quarantaine status gezet, zodat deze niet kan functioneren.
6. Verbindingen worden gescand. Als het beleid de hele connector blokkeert, wordt de verbinding uitgeschakeld , zodat deze niet kan werken.
7. Alle resources die actief zijn en een inactieve verbinding proberen te gebruiken, mislukken tijdens runtime.

Belangrijk

Afdwingen via runtime is afhankelijk van de status van de verbinding. Als deze nog niet is geïnactiveerd of nog niet is gescand, kan de verbinding tijdens runtime nog steeds zonder fouten worden uitgevoerd.

Overwegingen op het gebied van latentie

De tijd die nodig is om het gegevensbeleid effectief te implementeren, varieert van klant tot klant, op basis van het volume aan omgevingen en resources binnen die omgevingen. Hoe meer apps, stromen en chatbots een klant heeft, hoe langer het duurt voordat beleidswijzigingen volledig effect hebben. Voor de meest extreme gevallen bedraagt de latentie voor volledige handhaving 24 uur. In de meeste gevallen is dit binnen een uur.

Zie ook

Beleid ter voorkoming van gegevensverlies (DLP) beheren