Hiërarchiebeveiliging instellen voor gedetailleerde toegang tot gegevens
Notitie
Als u Alleen Unified Interface gebruiken hebt ingeschakeld, doet u het volgende voordat u de procedures in dit artikel gebruikt:
- Selecteer op de navigatiebalk de optie Instellingen (
). - Selecteer Geavanceerde instellingen.
Het hiërarchiebeveiligingsmodel is een uitbreiding van de bestaande Dynamics 365 Customer Engagement (on-premises) beveiligingsmodellen met behulp van Business Units, beveiligingsrollen, delen en teams. Het kan samen met alle andere bestaande beveiligingsmodellen worden gebruikt. De hiërarchiebeveiliging biedt een meer gedetailleerde toegang tot records voor een organisatie en helpt de onderhoudskosten te verlagen. In complexe scenario's kunt u bijvoorbeeld beginnen met verschillende Business Units te maken en vervolgens de hiërarchiebeveiliging toevoegen. Dit is een meer gedetailleerde toegang tot gegevens met veel minder onderhoudskosten dan een groot aantal Business Units kan vereisen.
Beveiligingsmodellen voor managerhiërarchie en positiehiërarchie
Twee beveiligingsmodellen kunnen worden gebruikt voor hiërarchieën: de managerhiërarchie en de positiehiërarchie. Met de managerhiërarchie moet een manager zich binnen dezelfde Business Unit als de ondergeschikte bevinden of in de bovenliggende Business Unit van de Business Unit van de ondergeschikte, om toegang te hebben tot de gegevens van de ondergeschikte. De positiehiërarchie staat alleen gegevenstoegang over Business Units toe. Als u een financiële organisatie bent, kunt u het model van de Managerhiërarchie gebruiken om te voorkomen dat managers toegang hebben tot gegevens buiten hun Business Unit. Als u echter deel uitmaakt van een klantenserviceorganisatie en wilt dat de managers toegang hebben tot serviceaanvragen die in verschillende Business Units worden verwerkt, kan de positiehiërarchie beter voor u zijn.
Notitie
Het hiërarchiebeveiligingsmodel biedt een bepaald niveau van toegang tot gegevens, maar aanvullende toegang kan worden verkregen met behulp van andere soorten beveiliging, zoals beveiligingsrollen.
Managerhiërarchie
Het beveiligingsmodel van de managerhiërarchie is gebaseerd op de beheersketen of de directe rapportagestructuur, waarbij de relatie tussen de manager en het rapport wordt gevormd door gebruik van het veld Manager op de systeemgebruikersentiteit. Met dit beveiligingsmodel kunnen de managers toegang krijgen tot de gegevens waartoe hun ondergeschikten toegang hebben. Ze kunnen hun werk doen namens directe medewerkers of toegang krijgen tot informatie waarvoor goedkeuring nodig is.
Notitie
Met het beveiligingsmodel van de managerhiërarchie heeft een manager toegang tot de records die eigendom zijn van de gebruiker of van het team waarvan een gebruiker lid is, en tot de records die rechtstreeks worden gedeeld met de gebruiker of het team waarvan een gebruiker lid is. Wanneer een record door een gebruiker die zich buiten de managementketen bevindt, wordt gedeeld met een direct ondergeschikte met alleen-lezentoegang, heeft de manager van de direct ondergeschikte alleen-lezentoegang tot de gedeelde record.
Naast het beveiligingsmodel van de managerhiërarchie moet een manager ten minste de leesbevoegdheid op gebruikersniveau voor een entiteit hebben om de gegevens van de ondergeschikte te zien. Als een manager bijvoorbeeld geen leestoegang tot de aanvraagentiteit heeft, kan de manager de aanvragen niet zien waartoe zijn of haar ondergeschikten toegang hebben.
Voor een niet-direct ondergeschikte in dezelfde managementketen van de manager heeft een manager alleen-lezentoegang tot de gegevens van de niet-direct ondergeschikte. Voor een directe ondergeschikte heeft de manager lees-, schrijf-, bijwerk-, toevoegtoegang tot de gegevens van de ondergeschikte. Kijk om het beveiligingsmodel van de managerhiërarchie te demonstreren maar naar het onderstaande diagram. Een CEO kan gegevens van de VP Sales en de VP Service lezen of bijwerken. De CEO kan echter de gegevens van de Sales Manager en de Service Manager alleen lezen, evenals de Sales- en Support-gegevens. U kunt de hoeveelheid gegevens die toegankelijk is voor een manager, verder beperken met "Niveau". Het niveau wordt gebruikt om te beperken hoeveel niveaus diep een manager alleen leestoegang heeft tot de gegevens van zijn of haar ondergeschikten. Bijvoorbeeld, als het niveau is ingesteld op 2, kan de CEO de gegevens van de VP Sales of Service en de Sales en Service Managers zien. De CEO ziet echter niet de Sales-gegevens of de Support-gegevens.
Het is belangrijk op te merken dat als een directe ondergeschikte diepere beveiligingstoegang tot een entiteit heeft dan de manager van de ondergeschikte, de manager mogelijk niet alle records kan zien waartoe de directe ondergeschikte toegang heeft. Het volgende voorbeeld illustreert dit.
Eén business unit heeft drie gebruikers: gebruiker 1, gebruiker 2 en gebruiker 3.
Gebruiker 2 is een directe ondergeschikte van gebruiker 1.
Gebruiker 1 en 3 beschikken over leestoegang op gebruikersniveau tot de accountentiteit. Met dit toegangsniveau krijgen gebruikers toegang tot records waarvan ze eigenaar zijn, tot de records die met de gebruiker worden gedeeld en tot records die worden gedeeld met het team waarvan de gebruiker lid is.
Gebruiker 2 heeft Business Unit-leestoegang tot de accountentiteit. Hierdoor kan gebruiker 2 alle accounts voor de business unit zien, inclusief alle accounts die eigendom zijn van gebruiker 1 en gebruiker 3.
Gebruiker 1 heeft, als directe manager van gebruiker 2, toegang tot de accounts die eigendom zijn van of worden gedeeld met gebruiker 2 en tot accounts die worden gedeeld met of eigendom zijn van een team waarvan gebruiker 2 lid is. Gebruiker 1 heeft echter geen toegang tot de accounts van gebruiker 3, hoewel de directe ondergeschikte van gebruiker 1 wellicht wel toegang heeft tot de accounts van gebruiker 3.
Positiehiërarchie
De positiehiërarchie is niet gebaseerd op de directe rapportagestructuur, zoals de managerhiërarchie. Een gebruiker hoeft geen werkelijke manager van een andere gebruiker te zijn om toegang tot de gegevens van de gebruiker te hebben. Als beheerder definieert u verschillende taakposities in de organisatie en ordent u ze in de positiehiërarchie. Vervolgens voegt u gebruikers toe aan een eventuele positie, of anders gezegd, u 'markeert' een gebruiker met een bepaalde positie. Een gebruiker kan slechts met één positie in een bepaalde hiërarchie gemarkeerd zijn. Een positie kan echter voor meerdere gebruikers worden gebruikt. Gebruikers op de hogere posities in de hiërarchie hebben toegang tot de gegevens van de gebruikers op de lagere posities, in het directe bovenliggende pad. De directe hogere posities hebben lees-, schrijf-, bijwerk en toevoegtoegang tot de gegevens van de lagere posities in het directe bovenliggende pad. De niet-directe hogere posities hebben alleen-lezen toegang tot de gegevens van de lagere posities in het directe bovenliggende pad.
Het concept van het directe bovenliggende pad wordt geïllustreerd door het onderstaande diagram. De Sales Manager heeft toegang tot de Sales-gegevens, maar heeft geen toegang tot de Support-gegevens, die zich in een ander bovenliggend pad bevinden. Hetzelfde geldt voor de positie van Servicemanager. De positie heeft geen toegang tot de Sales-gegevens, die zich in het Sales-pad bevinden. Net als bij de managerhiërarchie kunt u het aantal gegevens dat voor hogere posities toegankelijk is, beperken met "Niveau". Het niveau beperkt hoeveel niveaus diep een hogere positie alleen-lezen toegang heeft tot de gegevens van de lagere posities in het directe onderliggende pad. Bijvoorbeeld, als het niveau is ingesteld op 3, kan de CEO de gegevens zien van de posities VP Sales en VP Support tot aan de posities Sales en Support.
Notitie
Met de positiehiërarchiebeveiliging heeft een gebruiker op een hogere positie toegang tot de records die eigendom zijn van een gebruiker op een lagere positie of van het team waarvan de gebruiker lid is, en tot de records die rechtstreeks worden gedeeld met de gebruiker of het team waarvan de gebruiker lid is.
In het beveiligingsmodel van de positiehiërarchie moeten de gebruikers op een hoger niveau ten minste leesbevoegdheid op gebruikersniveau hebben voor een entiteit om de records te zien waartoe de gebruikers op de lagere posities toegang hebben. Als een gebruiker op een hoger niveau bijvoorbeeld geen leestoegang tot de aanvraagentiteit heeft, kan die gebruiker de aanvragen niet zien waartoe de gebruikers op een lagere positie toegang hebben.
Hiërarchiebeveiliging instellen
Als u de beveiligingshiërarchie wilt instellen, moet u een beheerdersbeveiligingsrol hebben.
De hiërarchiebeveiliging is standaard uitgeschakeld. U kunt deze als volgt inschakelen:
Ga naar Instellingen>Beveiliging.
Kies Hiërarchie-beveiliging en selecteer Hiërarchische modellen inschakelen.
Belangrijk
Als u wijzigingen in Hiërarchiebeveiliging wilt aanbrengen, moet u beschikken over de bevoegdheid Instellingen hiërarchiebeveiliging wijzigen.
Nadat u de hiërarchiemodellering hebt ingeschakeld, kiest u het specifieke model door de Managerhiërarchie of de Aangepaste positiehiërarchie te selecteren. Alle systeementiteiten zijn standaard ingeschakeld voor hiërarchiebeveiliging, maar u kunt selectieve entiteiten van de hiërarchie uitsluiten. Hieronder ziet u het venster Hiërarchiebeveiliging:
Stel het niveau in op de gewenste waarde om te beperken hoeveel niveaus diep een manager alleen leestoegang heeft tot de gegevens van zijn of haar ondergeschikten. Bijvoorbeeld, als het niveau 2 is, kan een manager alleen toegang krijgen tot de eigen accounts en de accounts van de ondergeschikten twee niveaus diep. Als u zich in het voorbeeld bij Customer Engagement-apps aanmeldt, niet als systeembeheerder die alle accounts kan zien, maar als adjunct-directeur Sales, kunt u alleen de actieve accounts zien van de gebruikers die in de rode rechthoek worden weergegeven, zoals hieronder aangegeven:
Notitie
De hiërarchiebeveiliging verleent de adjunct-directeur van de afdeling Verkoop toegang tot de records in de rode rechthoek, maar er kan aanvullende toegang beschikbaar zijn op basis van de beveiligingsrol die de adjunct-directeur van de afdeling Verkoop heeft.
Setup Manager en positiehiërarchieën
De managerhiërarchie wordt gemakkelijk gemaakt door de managerrelatie te gebruiken met de systeemgebruikersrecord. U gebruikt het opzoekveld Manager (ParentsystemuserID) om de manager van de gebruiker op te geven. Als u de positiehiërarchie al hebt gemaakt, kunt u de gebruiker ook markeren met een bepaalde positie in de positiehiërarchie. In het volgende voorbeeld rapporteert de verkoper aan de Sales Manager in de managerhiërarchie en heeft deze ook de Sales-positie in de positiehiërarchie:
Als u een gebruiker aan een bepaalde positie in de positiehiërarchie wilt toevoegen, gebruikt u het opzoekveld positie in het formulier van de gebruikersrecord, zoals hieronder aangegeven:
Belangrijk
Als u een gebruiker wilt toevoegen aan een positie of de positie van een gebruiker wilt wijzigen, moet u beschikken over de bevoegdheid Positie voor een gebruiker toewijzen.
Als u de positie in het formulier van de gebruikersrecord wilt wijzigen, kiest u op de navigatiebalk Meer (...) en kiest u een andere positie, zoals hieronder weergegeven:
Een positiehiërarchie maken:
Ga naar Instellingen>Beveiliging.
Kies Posities.
Geef voor elke gewenste positie de naam van de positie, het bovenliggende element van de positie en de beschrijving op. Voeg gebruikers aan deze positie toe met behulp van het opzoekveld Gebruikers in deze positie. Onderaan ziet u het voorbeeld van een positiehiërarchie met de actieve posities.
Hieronder ziet u het voorbeeld van de ingeschakelde gebruikers met hun corresponderende posities:
Prestatieoverwegingen
Voor een optimaal functioneren raden we het volgende aan:
Beperk de effectieve hiërarchiebeveiliging tot 50 gebruikers of minder onder een manager/positie. De hiërarchie kan meer dan 50 gebruikers onder een manager/positie bevatten, maar u kunt de niveau-instelling gebruiken om het aantal niveaus voor alleen-lezen toegang te verkleinen en zo het effectieve aantal gebruikers onder een managerpositie beperken tot 50 gebruikers of minder.
Gebruik hiërarchiebeveiligingsmodellen in combinatie met andere bestaande beveiligingsmodellen voor complexere scenario's. Maak geen grote aantallen Business Units, maar maak minder Business Units en voeg hiërarchiebeveiliging toe.
Zie ook
Beveiligingsconcepten voor Microsoft Dynamics 365 for Customer Engagement
Hiërarchische gegevens opvragen en visualiseren