Beveiligingsconcepten in Microsoft Dataverse

Een van de belangrijkste kenmerken van Dataverse is het uitgebreide beveiligingsmodel, dat zich kan aanpassen aan veel zakelijke gebruiksscenario's. Dit beveiligingsmodel is alleen van toepassing als er een Dataverse database in de omgeving aanwezig is. Als beheerder bouw je waarschijnlijk niet het hele beveiligingsmodel zelf, maar ben je vaak betrokken bij het proces van het beheren van gebruikers, het zorgen voor de juiste configuratie en het oplossen van problemen met beveiligingstoegang.

Fooi

Bekijk de volgende Video: Microsoft Dataverse – Beveiligingsconcepten getoond in demo's.

Op rollen gebaseerde beveiliging

Dataverse maakt gebruik van op rollen gebaseerde beveiliging om een verzameling rechten te groeperen. Deze beveiligingsrollen kunnen rechtstreeks aan gebruikers worden gekoppeld of kunnen worden gekoppeld aan teams en business units van Dataverse. Gebruikers kunnen vervolgens aan het team worden gekoppeld, zodat alle gebruikers die aan het team zijn gekoppeld, van de rol profiteren. Een sleutelbegrip in de Dataverse-beveiliging dat u moet kennen, is dat alle privileges worden opgebouwd met de grootste hoeveelheid toegang die bestaat. Als u leestoegang op breed organisatieniveau hebt gegeven aan alle contactpersoonsrecords, kunt u niet teruggaan en één record verbergen.

Business units

Fooi

Bekijk de volgende Video: Moderniseer bedrijfseenheden.

Business units werken met beveiligingsrollen om de effectieve beveiliging van een gebruiker te bepalen. Business units zijn een bouwsteen voor beveiligingsmodellering, die helpt bij het beheer van gebruikers en de gegevens waartoe ze toegang hebben. Business units definiëren een beveiligingsgrens. Elke Dataverse-database heeft een business unit op het hoogste niveau.

U kunt onderliggende business units maken om uw gebruikers en gegevens verder te segmenteren. Elke gebruiker die aan een omgeving is toegewezen, behoort tot een bedrijfseenheid. Hoewel business units kunnen worden gebruikt om een echte organisatiehiërarchie 1:1 te modelleren, neigen ze vaker naar eerder gedefinieerde beveiligingsgrenzen om de behoeften van het beveiligingsmodel te helpen realiseren.

Laten we het volgende voorbeeld bekijken om dit beter te begrijpen: We hebben drie business units. Woodgrove is de hoofd-business unit en zal altijd aan de top staan, dat kan niet worden gewijzigd. We hebben twee andere onderliggend-bedrijfseenheden gecreëerd: A en B. Gebruikers in deze bedrijfseenheden hebben verschillende toegangsbehoeften. Wanneer we een gebruiker koppelen aan deze omgeving, kunnen we de gebruiker in een van deze drie business units plaatsen. Waar de gebruiker aan is gekoppeld, bepaalt welke bedrijfseenheid eigenaar is van de records waarvan de gebruiker de eigenaar is. Door die koppeling kunnen we een beveiligingsrol op maat maken waarmee de gebruiker alle records in die business unit kan zien.

Hiërarchische gegevenstoegangsstructuur

Klanten kunnen een organisatiestructuur gebruiken waarin gegevens en gebruiker zijn opgedeeld in een boomachtige hiërarchie.

Wanneer we een gebruiker koppelen aan deze omgeving, kunnen we de gebruiker in een van deze drie business units plaatsen en een beveiligingsrol van de business unit aan de gebruiker toewijzen. De business unit waaraan de gebruiker is gekoppeld, bepaalt welke business unit eigenaar is van de records wanneer de gebruiker een record maakt. Dankzij deze koppeling kunnen we een beveiligingsrol op maat maken, waarmee de gebruiker gegevens in die bedrijfseenheid kan bekijken.

Gebruiker A is gekoppeld aan Divisie A en heeft een beveiligingsrol Y van Divisie A toegewezen gekregen. Hierdoor heeft gebruiker A toegang tot de records van contactpersoon 1 en contactpersoon 2. Terwijl gebruiker B in Divisie B geen toegang heeft tot de contactgegevens van Divisie A, maar wel tot contactpersoon #3.

Matrix-gegevenstoegangsstructuur (gemoderniseerde business units)

Klanten kunnen een organisatiestructuur gebruiken waarbij gegevens in een boomstructuur zijn ondergebracht, en gebruikers kunnen werken met en toegang krijgen tot de gegevens van alle business units, ongeacht de business unit waaraan de gebruiker is toegewezen.

Wanneer we een gebruiker koppelen aan deze omgeving, kunnen we de gebruiker in een van deze drie business units plaatsen. Voor elke business unit waarvoor een gebruiker toegang tot gegevens nodig heeft, wordt een beveiligingsrol van die business unit aan de gebruiker toegewezen. Wanneer de gebruiker een record maakt, kan hij de business unit instellen die eigenaar is van de record.

Gebruiker A kan gekoppeld zijn aan een van de business units, met inbegrip van de hoofd-business unit. Een beveiligingsrol Y van Divisie A is toegewezen aan gebruiker A die de gebruiker toegang geeft tot records van contactpersoon 1 en contactpersoon 2. Een beveiligingsrol Y van Divisie B is toegewezen aan gebruiker A die de gebruiker toegang geeft tot de record van contactpersoon 3.

De matrixgegevenstoegangsstructuur inschakelen

Notitie

Voordat u deze functie inschakelt, moet u al uw aanpassingen publiceren om al uw nieuwe niet-gepubliceerde tabellen voor de functie in te schakelen. Als u merkt dat u niet-gepubliceerde tabellen hebt die niet werken met deze functie nadat u deze hebt ingeschakeld, kunt u de instelling RecomputeOwnershipAcrossBusinessUnits opgeven met behulp van het OrgDBOrgSettings-hulpmiddel voor Microsoft Dynamics CRM. Als RecomputeOwnershipAcrossBusinessUnits ingesteld wordt op true, kan het veld Bedrijfseenheid die eigenaar is worden ingesteld en bijgewerkt.

1. Meld u aan bij Power Platform Beheercentrum als beheerder (Dynamics 365-beheerder of Microsoft Power Platform beheerder).
2. Selecteer Omgevingen en kies de omgeving waarvoor u deze functie wilt inschakelen.
3. Selecteer Instellingen>Product>Functies.
4. Zet de schakelaar Eigendom van records in business units op Aan.

Zodra deze functieschakelaar is ingeschakeld, kunt u Business unit selecteren wanneer u een beveiligingsrol toewijst aan een gebruiker. Hiermee kunt u beveiligingsrollen van verschillende business units toewijzen aan een gebruiker. De gebruiker heeft ook een beveiligingsrol nodig van de business unit waaraan de gebruiker is toegewezen met gebruikersinstellingen bevoegdheden om modelgestuurde apps uit te voeren. Bij de beveiligingsrol Basisgebruiker kunt u vinden hoe deze gebruikersinstellingen-bevoegdheden worden ingeschakeld.

U kunt een gebruiker toewijzen als recordeigenaar in elke willekeurige business unit zonder dat u een beveiligingsrol hoeft toe te wijzen in de business unit die de record bezit, zolang de gebruiker een beveiligingsrol heeft met leesrechten voor de recordtabel. Zie Eigendom van entiteiten in gemoderniseerde business units.

Notitie

Deze functieschakelaar is opgeslagen in de instelling EnableOwnershipAcrossBusinessUnits en kan ook worden ingesteld met het OrgDBOrgSettings-hulpmiddel voor Microsoft Dynamics CRM.

Een Business Unit koppelen aan een Microsoft Entra-beveiligingsgroep

U kunt een Microsoft Entra-beveiligingsgroep gebruiken om uw Business Unit toe te wijzen voor het stroomlijnen van uw gebruikersbeheer en roltoewijzing.

Maak een Microsoft Entra beveiligingsgroep voor elke bedrijfseenheid en wijs de betreffende bedrijfseenheid beveiligingsrol toe aan elk groepsteam.

Maak een Microsoft Entra-beveiligingsgroep voor elke Business Unit. Maak een Dataverse-groepsteam voor elke Microsoft Entra-beveiligingsgroep. Wijs de desbetreffende beveiligingsrol van de Business Unit toe aan elk Dataverse-groepsteam. De gebruiker in het bovenstaande diagram wordt gemaakt in de Business Unit van het hoogste niveau wanneer de gebruiker toegang krijgt tot de omgeving. Het is prima als de gebruiker en de Dataverse-groepsteams in de Business Unit van het hoogste niveau zitten. Ze hebben alleen toegang tot gegevens in de Business Unit waar de beveiligingsrol is toegewezen.

Voeg gebruikers toe aan de desbetreffende Microsoft Entra-beveiligingsgroep om hen toegang te verlenen tot de Business Unit. De gebruikers kunnen de app onmiddellijk uitvoeren en toegang krijgen tot de resources/gegevens.

In de toegang tot matrixgegevens, waar gebruikers kunnen werken en toegang hebben tot gegevens van meerdere Business Units, voegt u de gebruikers toe aan de Microsoft Entra-beveiligingsgroepen die zijn toegewezen aan die Business Units.

Bedrijfseenheid die eigenaar is

Elk record heeft een kolom Bedrijfseenheid die eigenaar is , die bepaalt welke bedrijfseenheid eigenaar is van het record. Deze kolom is standaard ingesteld op de bedrijfseenheid van de gebruiker wanneer de record wordt gemaakt. Deze kan alleen worden gewijzigd wanneer de functieschakelaar op AAN staat.

Notitie

Wanneer u wijzigt welke business unit eigenaar is van een record, moet u het volgende controleren voor trapsgewijze effecten: SDK voor .NET gebruiken om trapsgewijze kenmerken te configureren.

U kunt beheren of u uw gebruiker wilt toestaan om de kolom Business unit die eigenaar is in te stellen wanneer de functieschakelaar op AAN staat. Om de kolom voor Business unit die eigenaar is in te stellen, moet u de beveiligingsrol van de gebruiker de bevoegdheid Toevoegen aan van de tabel van de business unit toewijzen met lokale machtigingen.

Om uw gebruiker toe te staan deze kolom in te stellen, kunt u deze kolom als volgt inschakelen:

1. Formulier: zowel de hoofdtekst als de koptekst.
2. Weergave.
3. Kolomtoewijzingen. Als u AutoMapEntity gebruikt, kunt u de kolom in uw kolom toewijzing opgeven.

Notitie

Als u een taak/proces hebt om gegevens te synchroniseren tussen omgevingen en de Business unit die eigenaar is is opgenomen als onderdeel van het schema, zal uw taak mislukken met een beperkingsschending Refererende sleutel als de doelomgeving niet dezelfde Business unit die eigenaar is-waarde heeft.

U kunt ofwel de kolom Business unit die eigenaar is uit het bronschema halen of de kolomwaarde van Business unit die eigenaar is van de Bron bijwerken naar een van de business units van het doel.

Als u een taak/proces hebt om gegevens van een omgeving naar een externe bron te kopiëren, bijvoorbeeld PowerBI, moet u de kolom Business unit die eigenaar is van uw bron selecteren of te deselecteren. Selecteer het als uw resource het kan ontvangen, anders deselecteert u het.

Eigendom van tabel/record

Dataverse ondersteunt twee typen eigenaarschap van records: eigendom van de organisatie en eigendom van de gebruiker of het team. Dit is een keuze die wordt gemaakt bij het maken van de tabel en kan niet worden gewijzigd. Om veiligheidsredenen zijn records die eigendom zijn van de organisatie, de enige keuze voor het toegangsniveau of de gebruiker de bewerking kan uitvoeren of niet. Voor records die eigendom zijn van gebruikers en teams, zijn de toegangsniveaus voor de meeste privileges gelaagde organisatie, business unit, onderliggende business unit of alleen de eigen records van de gebruiker. Dat betekent dat voor leesrechten op Contactpersonen, ik het eigendom van de gebruiker kan instellen en de gebruiker alleen zijn eigen records zou zien.

Om een ander voorbeeld te geven: laten we zeggen dat gebruiker A is gekoppeld aan Divisie A en we geven ze Leestoegang op niveau van de business unit voor Contactpersonen. Ze kunnen contact nummer 1 en 2 zien, maar niet contact nummer 3.

Wanneer u beveiligingsrolprivileges configureert of bewerkt, stelt u het toegangsniveau voor elke optie in. Het volgende is een voorbeeld van de editor voor beveiligingsrolrechten.

In het bovenstaande ziet u de typen standaardbevoegdheden voor elke tabel Maken, Lezen, Schrijven, Verwijderen, Toevoegen, Toevoegen aan, Toewijzen en Delen. U kunt elk van deze afzonderlijk bewerken. De visuele weergave van elke entiteit komt overeen met de onderstaande sleutel met betrekking tot het toegangsniveau dat u hebt verleend.

In het bovenstaande voorbeeld hebben we op organisatieniveau toegang tot Contactpersoon gegeven, wat betekent dat de gebruiker in Divisie A contactpersonen van iedereen kan zien en bijwerken. Een van de meest voorkomende beheersfouten is dat men gefrustreerd raakt door machtigingen en teveel toegang gaat verlenen. Al heel snel begint een goed opgezet beveiligingsmodel op Zwitserse kaas te lijken (vol gaten).

Eigendom van entiteiten in gemoderniseerde business units

In Gemoderniseerde business units kunt u ervoor zorgen dat gebruikers eigenaar zijn van records in alle business units. Het enige dat gebruikers nodig hebben, is een beveiligingsrol (willekeurige business unit) met leesrechten voor de recordtabel. De gebruikers hoeven geen beveiligingsrol te hebben toegewezen in elke business unit waar het record zich bevindt.

Als Eigendom van records in business units was ingeschakeld in uw productieomgeving tijdens de preview-periode, moet u het volgende doen om dit recordeigendom in te schakelen voor alle business units:

1. De Organisatie-instellingeneditor installeren
2. Stel de organisatie-instellingen RecomputeOwnershipAcrossBusinessUnits in op waar. Wanneer deze instelling is ingesteld op ´true´, is het systeem vergrendeld en kan het tot 5 minuten duren om de herberekening uit te voeren om de mogelijkheid in te schakelen waarbij gebruikers nu eigenaar kunnen zijn van records in verschillende bedrijfseenheden zonder dat afzonderlijke beveiligingsrollen aan elke Business Unit moeten worden toegewezen. Hierdoor kan een eigenaar van een record zijn record toewijzen aan iemand buiten de Business Unit die eigenaar is van het record.
3. Stel AlwaysMoveRecordToOwnerBusinessUnit in op onwaar. Dit zorgt ervoor dat het record in de oorspronkelijke business unit blijft wanneer het eigendom van het record wordt gewijzigd.

Voor alle niet-productieomgevingen hoeft u alleen maar AlwaysMoveRecordToOwnerBusinessUnit in te stellen op onwaar om deze mogelijkheid te gebruiken.

Notitie

Als u de functie Eigendom van records in business unit uitschakelt of de instelling RecomputeOwnershipAcrossBusinessUnits op ´false´ instelt met behulp van de OrgDBOrgSettings-tool voor Microsoft Dynamics CRM, kunt u het veld Bedrijfseenheid die eigenaar is niet instellen of bijwerken, en alle records waarvoor het veld Bedrijfseenheid die eigenaar is verschilt van de business unit van de eigenaar, worden bijgewerkt naar de business unit van de eigenaar.

Teams (inclusief groepsteams)

Teams zijn een andere belangrijke bouwsteen voor beveiliging. Teams zijn eigendom van een business unit. Elke business unit heeft één standaardteam, dat automatisch wordt gemaakt wanneer de business unit wordt gemaakt. De standaardteamleden worden beheerd door Dataverse en bevatten altijd alle gebruikers die aan die business unit zijn gekoppeld. U kunt leden niet handmatig toevoegen aan of verwijderen uit het standaardteam. Ze worden dynamisch aangepast door het systeem wanneer nieuwe gebruikers worden gekoppeld aan of losgekoppeld van business units.. Er zijn twee soorten teams: teams die eigenaar zijn en toegangsteams.

• Teams die eigenaar zijn kunnen records bezitten, waardoor elk teamlid directe toegang tot dat record heeft. Gebruikers kunnen lid zijn van meerdere teams. Hierdoor kan dit een krachtige manier zijn om gebruikers op een brede manier machtigingen te verlenen zonder al te gedetailleerd bezig te zijn met toegang op niveau van de individuele gebruikers.
• Toegangsteams worden in de volgende sectie besproken als onderdeel van het delen van records.

Records delen

Individuele records kunnen op individuele basis worden gedeeld met een andere gebruiker. Dit is een krachtige manier om uitzonderingen af te handelen die niet vallen onder het toegangsmodel voor eigendom van de records of lid zijn van een business unit. Het zou echter een uitzondering moeten zijn, omdat het een minder handige manier is om de toegang te controleren. Het is moeilijker om problemen met delen op te lossen, omdat het geen consistent geïmplementeerd toegangsbeheer is. Delen kan zowel op gebruikers- als op teamniveau. Delen met een team is een efficiëntere manier van delen. Een meer geavanceerd concept van delen is met toegangsteams, dat zorgt voor het automatisch aanmaken van een team en het delen van recordtoegang met het team op basis van een toegangsteamsjabloon (sjabloon met rechten) dat wordt toegepast. Toegangsteams kunnen ook zonder de sjablonen worden gebruikt, door de leden handmatig toe te voegen of te verwijderen. Toegangsteams presteren beter omdat ze niet toestaan dat teams eigenaar zijn van records of dat beveiligingsrollen aan het team worden toegewezen. Gebruikers krijgen toegang omdat de record met het team wordt gedeeld en de gebruiker lid is.

Beveiliging op recordniveau in Dataverse

U vraagt zich misschien af: wat bepaalt de toegang tot een record? Dat lijkt een simpele vraag, maar voor een willekeurige gebruiker is het de combinatie van al zijn/haar beveiligingsrollen, de bedrijfseenheid waaraan hij/zij is gekoppeld, de teams waarvan hij/zij lid is en de gegevens die met hem/haar worden gedeeld. Het belangrijkste om te onthouden is dat alle toegang cumulatief is voor al die concepten in het kader van een Dataverse-databaseomgeving. Deze rechten worden alleen toegekend binnen één database en worden individueel bijgehouden in elke Dataverse-database. Dit alles vereist dat ze een geschikte licentie hebben om toegang te krijgen tot Dataverse.

Beveiliging op kolomniveau in Dataverse

Soms is toegangscontrole op recordniveau niet toereikend voor bepaalde bedrijfsscenario's. Dataverse kent ook beveiliging op kolomniveau, om een gedetailleerdere controle over de beveiliging op kolomniveau mogelijk te maken. Beveiliging op kolomniveau kan worden ingeschakeld op alle aangepaste kolommen en de meeste systeemkolommen. De meeste systeemkolommen die persoonlijke identificeerbare informatie (PII) bevatten, kunnen individueel worden beveiligd. De metagegevens van elke kolom bepalen of dat een beschikbare optie is voor de systeemkolom.

Beveiliging op kolomniveau wordt per kolom ingeschakeld. Toegang wordt vervolgens beheerd door een kolombeveiligingsprofiel te maken. Het profiel bevat alle kolommen waarvoor beveiliging op kolomniveau is ingeschakeld en de toegang die door dat specifieke profiel wordt verleend. Elke kolom kan binnen het profiel worden beheerd voor Maken, Bijwerken en Lezen. Kolombeveiligingsprofielen worden vervolgens gekoppeld aan een gebruiker of teams om die gebruikers de rechten te verlenen voor de records waartoe ze al toegang hebben. Het is belangrijk op te merken dat beveiliging op kolomniveau niets te maken heeft met beveiliging op recordniveau. Een gebruiker moet al toegang hebben tot de record voor het kolombeveiligingsprofiel om toegang te kunnen geven tot de kolommen. Beveiliging op kolomniveau moet worden gebruikt als dat nodig is en niet overdreven omdat het overhead kan toevoegen die schadelijk is als het te veel wordt gebruikt.

Beveiliging beheren in meerdere omgevingen

Beveiligingsrollen en kolombeveiligingsprofielen kunnen worden ingepakt en met behulp van Dataverse-oplossingen van de ene omgeving naar een andere worden verplaatst. Business units en Teams moeten in elke omgeving worden gemaakt en beheerd samen met de toewijzing van gebruikers aan de benodigde beveiligingsonderdelen.

Omgevingsbeveiliging voor gebruikers configureren

Zodra rollen, teams en business units in een omgeving zijn gemaakt, is het tijd om de gebruikers hun beveiligingsconfiguraties toe te wijzen. Ten eerste, wanneer u een gebruiker aanmaakt, koppelt u de gebruiker aan een business unit. Standaard wordt hiervoor de business unit op het hoogste niveau in de organisatie gekozen. Ze worden ook toegevoegd aan het standaardteam van die business unit.

Bovendien wijst u ook beveiligingsrollen toe die de gebruiker nodig heeft. U voegt de gebruiker ook toe als lid van een of meerdere teams. Onthoud dat teams ook beveiligingsrollen kunnen hebben, dus de effectieve rechten van de gebruiker bestaan uit de combinatie van direct toegewezen beveiligingsrollen en die van elk team waarvan ze lid zijn. Beveiliging is altijd additief en biedt de minst beperkende toestemming voor hun rechten. Het volgende is een goede doorloop van het configureren van omgevingsbeveiliging.

Als u beveiliging op kolomniveau hebt gebruikt, moet u de gebruiker of een team van de gebruiker koppelen aan een van de door u gemaakte kolombeveiligingsprofielen.

Beveiliging is een complex onderwerp en kan het beste worden gerealiseerd door een gezamenlijke inspanning van de applicatiemakers en het team dat de gebruikersrechten beheert. Alle belangrijke veranderingen moeten ruim van tevoren worden gecoördineerd voordat de veranderingen in de omgeving worden geïmplementeerd.

Zie ook

Configureer omgeving-beveiliging
Beveiligingsrollen en privileges