Hiërarchiebeveiliging voor toegangsbeheer
Het hiërarchiebeveiligingsmodel is een uitbreiding van de bestaande beveiligingsmodellen waarin gebruik wordt gemaakt van business units, beveiligingsrollen, delen en teams. Het kan met alle andere bestaande beveiligingsmodellen worden gebruikt. 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. Deze extra beveiliging biedt een meer gedetailleerde toegang tot gegevens met veel lagere onderhoudskosten dan een groot aantal business units mogelijk vereist.
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, wilt u mogelijk 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.
Opmerking
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 beheerketen of de directe rapportagestructuur, waarbij de relatie tussen de manager en het rapport wordt gevormd door gebruik van het veld Manager in de systeemgebruikerstabel. Met dit beveiligingsmodel kunnen 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.
Opmerking
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 buiten de managementketen wordt gedeeld met een direct ondergeschikte met alleen-lezen toegang, heeft de manager van de direct ondergeschikte alleen-lezen toegang tot de gedeelde record.
Nadat u de optie Eigendom van records in business units hebt ingeschakeld, kunnen managers directe ondergeschikten hebben van verschillende business units. U kunt de volgende omgevingsdatabase-instellingen gebruiken om de beperking van de business unit op te heffen.
ManagersMoetenInDezelfdeOfBovenliggendeBedrijfseenheidZijnAlsRapporten
Standaardwaarde = waar
U kunt dit instellen op onwaar, en een business unit van de manager hoeft niet dezelfde te zijn als de business unit van de direct ondergeschikte.
Naast het beveiligingsmodel van de managerhiërarchie moet een manager ten minste de leesbevoegdheid op gebruikersniveau voor een tabel hebben om de gegevens van de ondergeschikte te zien. Als een manager bijvoorbeeld geen leestoegang tot de aanvraagtabel 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 de toegangsbevoegdheden voor lezen, schrijven, toevoegen en toevoegen aan voor de gegevens van de ondergeschikte. Kijk om het beveiligingsmodel van de managerhiërarchie te illustreren naar het onderstaande diagram. Een CEO kan gegevens van de VP Sales en de VP Service lezen of bijwerken. De CEO kan de gegevens van de verkoopdirecteur en de servicemanager echter alleen lezen, evenals de verkoop- en ondersteuningsgegevens. 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-lezen toegang 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 verkoopdirecteurs en verkoopmanagers zien. De CEO ziet echter niet de verkoop- of ondersteuningsgegevens.
Het is belangrijk op te merken dat als een directe ondergeschikte diepere beveiligingstoegang tot een tabel 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.
Gebruikers 1 en 3 beschikken over leestoegang op gebruikersniveau tot de accounttabel. 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 accounttabel. Door deze toegang 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, met inbegrip van accounts die worden gedeeld met of die het eigendom zijn van andere teams waarvan gebruiker 2 lid is. Gebruiker 1 heeft echter geen toegang tot de accounts van gebruiker 3, hoewel de directe ondergeschikte van gebruiker 1 mogelijk 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 toegangsbevoegdheid tot lezen, schrijven, toevoegen en toevoegen aan voor 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 volgende diagram. De verkoopdirecteur heeft toegang tot de verkoopgegevens, maar geen toegang tot de supportgegevens, die zich in een ander bovenliggend pad bevinden. Hetzelfde geldt voor de positie van servicemanager. Deze heeft geen toegang tot de verkoopgegevens die zich in het verkooppad 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. Als het niveau is ingesteld op 3, kan de CEO bijvoorbeeld de gegevens zien van de posities VP Sales en VP Support tot aan de verkoop- en omdersteuningsposities.
Opmerking
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, 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 tabel 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 aanvraagtabel heeft, kan die gebruiker de aanvragen niet zien waartoe de gebruikers op een lagere positie toegang hebben.
Hiërarchiebeveiliging instellen
Controleer of u over de machtiging Systeembeheerder voor het bijwerken van de instelling beschikt om een hiërarchiebeveiliging in te stellen.
- Volg de handelingen in Uw gebruikersprofiel weergeven.
- Hebt u niet de juiste machtigingen? Neem contact op met uw systeembeheerder.
De hiërarchiebeveiliging is standaard uitgeschakeld. Voer de volgende stappen uit om hiërarchiebeveiliging in te schakelen.
Selecteer een omgeving en ga naar Instellingen>Gebruikers en machtigingen>Hiërarchiebeveiliging.
Onder Hiërarchiemodel selecteert u Managerhiërarchiemodel inschakelen of Positiehiërarchiemodel inschakelen, afhankelijk van uw vereisten.
Belangrijk
Als u wijzigingen in Hiërarchiebeveiliging wilt aanbrengen, moet u beschikken over de bevoegdheid Instellingen hiërarchiebeveiliging wijzigen.
In het gebied Hierarchietabelbeheer zijn alle systeemtabellen standaard ingeschakeld voor hiërarchiebeveiliging, maar u kunt selectieve tabellen uitsluiten van de hiërarchie. Als u specifieke tabellen wilt uitsluiten van het hiërarchiemodel, schakelt u de selectievakjes uit voor de tabellen die u wilt uitsluiten en slaat u uw wijzigingen op.
Stel het niveau in op de gewenste waarde om te beperken hoeveel niveaus diep een manager alleen-lezen toegang 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 ons voorbeeld als niet-beheerder VP Sales aanmeldt bij apps voor klantbetrokkenheid, ziet u alleen de actieve accounts van de gebruikers, zoals weergegeven:
Opmerking
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.
In de sectie Hierarchietabelbeheer zijn alle systeemtabellen standaard ingeschakeld voor hiërarchiebeveiliging. Als u een specifieke tabel wilt uitsluiten van het hiërarchiemodel, schakelt u het vinkje naast de tabelnaam uit en slaat u uw wijzigingen op.
Belangrijk
- Dit is een preview-functie.
- Preview-functies zijn niet bedoeld voor productiegebruik en bieden mogelijk beperkte functionaliteit. Voor deze functies gelden aanvullende gebruiksvoorwaarden. Bovendien zijn ze beschikbaar vóór een officiële release zodat klanten vroeg toegang kunnen krijgen en feedback kunnen geven.
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 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 verkoopdirecteur in de managerhiërarchie en heeft deze ook de verkooppositie 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.
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.
Een positiehiërarchie maken:
Selecteer een omgeving en ga naar Instellingen>Gebruikers en machtigingen>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. De volgende afbeelding is een voorbeeld van een positiehiërarchie met de actieve posities.
In de volgende afbeelding ziet u het voorbeeld van de ingeschakelde gebruikers met hun corresponderende posities.
Records opnemen of uitsluiten die eigendom zijn van directe ondergeschikten met de status van uitgeschakelde gebruiker
Managers kunnen de records van hun directe ondergeschikten met uitgeschakelde status zien voor omgevingen waarin hiërarchiebeveiliging is ingeschakeld na 31 januari 2024. Voor andere omgevingen worden de records van de uitgeschakelde status van direct ondergeschikten niet opgenomen in de managerweergave.
U kunt als volgt de records van directe ondergeschikten met de uitgeschakelde status opnemen:
- Installeer de OrganizationSettingsEditor-tool.
- Update de instelling AuthorizationEnableHSMForDisabledUsers naar true.
- Schakel de hiërarchiemodellering uit.
- Schakel deze opnieuw in.
U kunt als volgt de records van directe ondergeschikten met de uitgeschakelde status uitsluiten:
- Installeer de OrganizationSettingsEditor-tool.
- Update de instelling AuthorizationEnableHSMForDisabledUsers naar false.
- Schakel de hiërarchiemodellering uit.
- Schakel deze opnieuw in.
Opmerking
- Wanneer u de hiërarchiemodellering uit- en opnieuw inschakelt, kan de update enige tijd duren, omdat het systeem de toegang tot managerrecords opnieuw moet berekenen.
- Als u een time-out ziet, verminder dan het aantal tabellen onder de lijst Hiërarchietabelbeheer, zodat alleen tabellen worden weergegeven die door de manager moeten worden bekeken. Als de time-out aanhoudt, dient u een ondersteuningsticket in om hulp te vragen.
- Records met een uitgeschakelde status van directe ondergeschikten worden opgenomen als deze records worden gedeeld met een andere directe ondergeschikte die actief is. U kunt deze records uitsluiten door de share te verwijderen.
Prestatieoverwegingen
Voor een optimaal functioneren raden we het volgende aan:
Beperk de effectieve hiërarchiebeveiliging tot 50 gebruikers of minder onder een manager of positie. Uw hiërarchie kan meer dan 50 gebruikers onder een manager of positie bevatten, maar u kunt de instelling Diepte gebruiken om het aantal niveaus voor alleen-lezen toegang te verkleinen en zo het effectieve aantal gebruikers onder een manager of positie beperken tot 50 gebruikers of minder.
Gebruik hiërarchiebeveiligingsmodellen 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
Veiligheid in Microsoft Dataverse
Hiërarchische gegevens opvragen en visualiseren