Konfigurera hierarkisäkerhet för granular åtkomst till data
Kommentar
Om du har aktiverat läget för enbart enhetligt gränssnitt gör du så här innan du använder procedurerna i den här artikeln:
- VäljInställningar (
) i navigeringsfältet. - Välj Avancerade inställningar.
Säkerhetsmodellen i hierarkin är ett tillägg till de befintliga Dynamics 365 Customer Engagement (on-premises)-säkerhetsmodeller som använder affärsenheter, säkerhetsroller, delning och team. Den kan användas tillsammans med andra befintliga säkerhetsmodeller. Hierarkisäkerhet ger en bättre åtkomst till poster för en organisation och hjälper dig att hålla ned underhållskostnaderna. I komplexa scenarier kan du till exempel börjar med att skapa flera affärsenheter och sedan lägga till hierarkisäkerhet. Detta kommer att uppnå en bättre åtkomst till data med mycket mindre underhållskostnader än ett stort antal affärsenheter kan kräva.
Säkerhetsmodeller för chefshierarki och befattningshierarki
Två säkerhetsmodeller kan användas för hierarkier, chefshierarkin och befattningshierarkin. Med chefshierarkin måste en chef måste vara inom samma affärsenhet som rapporten, eller i den överordnade affärsenheten för rapportens affärsenhet, för att ha tillgång till informationen i rapporten. Befattningshierarkin ger tillgång till data över affärsenheter. Om du är ett finansiellt företag kanske du föredrar chefshierarkimodellen för att hindra att chefen får åtkomst till data utanför sin affärsenheter. Dock om du är en del av en kundtjänstorganisation och vill att chefer att komma åt serviceärenden som hanterats i olika affärsenheter kan befattningshierarkin fungera bättre för dig.
Kommentar
Även om hierarkisäkerhetsmodellen innehåller en viss nivå av åtkomst till data, kan ytterligare åtkomst erhållas med hjälp av andra former av säkerhet, till exempel säkerhetsroller.
Chefshierarki
Säkerhetsmodellen Chefshierarki baseras på chefskedjan eller en direkt rapporteringsstruktur, där chefens och rapportens relation upprättas med hjälp av fältet Chef på systemets användarentitet. Med den här säkerhetsmodellen kan chefer komma åt data som deras rapporter har tillgång till. De kan utföra arbete för sina underställda eller komma åt information som kräver godkännande.
Kommentar
Med säkerhetsmodellen Chefshierarki har en chef tillgång till poster som ägs av användaren eller teamet som användaren är medlem i, och till de poster som delas direkt med användaren eller det team som användaren är medlem i. När en post delas av en användare som är utanför hanteringskedja till en direktrapportanvändare med skrivskyddad åtkomst har den direkt överordnade chefen bara har skrivskyddad åtkomst till den delade posten.
Förutom säkerhetsmodellen Chefshierarki måste en chef ha minst läsprivilegium på användarnivå för en entitet för att visa data i rapporter. Till exempel om en chef inte har läsprivilegium för entiteten ärende, kommer chefen inte att kunna se de ärenden som deras rapporter har tillgång till.
För en icke-direkt rapport i samma hanteringskedja för chefen har chefen skrivskyddad åtkomst till icke-direkt rapportens data. För en direktrapport har en chef åtkomsterna Läsa, Skriva, Uppdatera, Lägga till och Tillägg till för data i rapporten. För att illustrera säkerhetsmodellen Chefshierarki ska vi ta en titt på diagrammet nedan. VD kan läsa eller uppdatera data för VP Sales och VP Service. VD kan emellertid endast läsa försäljningsansvarigs data och serviceansvarigs data, samt data för Försäljning och support. Du kan ytterligare begränsa mängden data som kan nås av en chef med "Djup". Djup används för att begränsa för hur många nivåer en chef har skrivskyddad åtkomst till data i sina rapporter. Om djupet är 2 kan VD se data för VP Sales, VP Service och sälj- och serviceansvariga. VD kan emellertid inte visa försäljnings- eller supportdata.
Det är viktigt att observera att om en direktrapport har djupare säkerhetsåtkomst till en entitet än deras chef så kan kanske inte chefen se alla poster som direktrapporten har åtkomst till. Följande exempel visar detta.
En enskild affärsenhet har tre användare: Användare 1, Användare 2 och Användare 3.
Användare 2 är en direktrapport till Användare 1.
Användare 1 och Användare 3 har läsbehörighet till entiteten Konto. Den här åtkomstnivån ger användaren åtkomst till poster som de äger, poster som delas med användaren och poster som delas med teamet som användaren tillhör.
Användare 2 har läsbehörighet för affärsenhet på entiteten Konto. Detta tillåter Användare 2 att visa alla konton för affärsenheten, inklusive alla konton som ägs av Användare 1 och Användare 3.
Användare 1, som närmaste chef till Användare 2, har åtkomst till konton som ägs av eller delas med Användare 2 och alla konton som delas med eller ägs av ett team där Användare 2 är medlem i. Men Användare 1 har inte åtkomst till konton för Användare 3, även om deras direktrapport har åtkomst till Användaren 3:s konton.
Befattningshierarki
Befattningshierarkin baseras inte på direkt rapporteringsstruktur som chefshierarkin. En användare behöver inte vara en faktisk chef för en annan användare för att komma åt användarens data. Som administratör kan du definiera olika befattningar i organisationen och ordna dem i befattningshierarkin. Sedan du lägga till användare till en viss befattning eller, som vi också säger "märka" en användare med en viss befattning. En användare kan bara vara märkt med en befattning i en viss hierarki, men en befattning kan användas för flera användare. Användare på högre befattningar i hierarkin har tillgång till data för användarna på de lägre befattningarna, i direkt överordnad sökväg. Direkt högre befattningar har åtkomsterna Läsa, Skriva, Uppdatera, Lägga till och Tillägg till för de lägre befattningarnas data i den direkt överordnade sökvägen. Icke-direkt högre befattningar har skrivskyddad åtkomst till de lägre befattningarnas data i den direkt överordnade sökvägen.
För att illustrera begreppet direkt överordnad sökväg ska vi titta på diagrammet nedan. Försäljningschefbefattningen har åtkomst till data för Försäljning, men har inte tillgång till supportdata som finns i en annan överordnad sökväg. Detsamma gäller för befattningen serviceansvarig. Den har inte tillgång till data för Försäljning, som finns i sökvägen för Försäljning. I chefshierarkin kan du begränsa mängden data som är tillgänglig för högre befattningar med "Djup". Djup begränsar för hur många nivåer en högre befattning har en skrivskyddad åtkomst till lägre befattningars data i den direkt överordnade sökvägen. Om djupet är 3 kan VD-befattningen till exempel se data ända ned från befattningarna VP Sales och VP Service till befattningarna Försäljning och Support.
Kommentar
Med säkerhetsmodellen Befattningshierarki har en användare på en högre befattning tillgång till poster som ägs av en användaren med lägre befattning eller teamet som användaren är medlem i, och till de poster som delas direkt med användaren eller det team som användaren är medlem i.
Förutom säkerhetsmodellen Befattningshierarki måste användare på en högre nivå ha minst läsprivilegium på användarnivå för en entitet för att visa de poster som användarna på lägre befattningar har tillgång till. Till exempel om en användare på en högre nivå inte har läsprivilegium för entiteten Ärende, kommer den användaren inte att kunna se de ärenden som användarna på lägre befattningar har tillgång till.
Konfigurera hierarkisäkerhet
Du måste ha säkerhetsrollen Administratör för att konfigurera säkerhetshierarkin.
Hierarkisäkerhet är inaktiverad som standard. För att aktivera:
Gå till Inställningar>Säkerhet.
Välj Hierarkisäkerhet och välj Aktivera hierarkimodell.
Viktigt!
För att göra ändringar i Hierarkisäkerhet måste du ha privilegiet Ändra säkerhetsinställningar för hierarkin.
När du har aktiverat hierarkimodellering, väljer du den specifika modellen genom att välja Chefshierarki eller Anpassad befattningshierarki. Alla systementiteter är aktiverade för säkerhetshierarkin från början, men du kan utesluta selektiva enheter från hierarkin. Fönstret Hierarkisäkerhet visas nedan:
Ange ett önskat värde för Djup för att begränsa i hur många nivåer en chef har skrivskyddad åtkomst till data i sina rapporter. Exempelvis om djupet är lika med 2 kan en chef kan bara komma åt sin egen bokföring och rapporternas bokföring två nivåer djupt. I vårt exempel, om du loggar in i Customer Engagement-appar inte som administratör, som kan se alla konton, men som VP Sales, kommer du bara att kunna se aktiva konton för de användare som visas i den röda rektangeln, som visas nedan:
Kommentar
När hierarkisäkerheten ger VP Sales åtkomst till posterna i den röda rektangeln, kan ytterligare åtkomst finnas utifrån den säkerhetsroll som VP Sales har.
Konfigurera chefs- och befattningshierarkier
Chefshierarkin skapas enkelt med hjälp av chefsrelationen i systemets användarpost. Du kan använda chefens (ParentsystemuserID) uppslagsfält för att ange chefen för användaren. Om du redan har skapat befattningshierarkin kan du också märka användare med en viss befattning i befattningshierarkin. I följande exempel rapporterar försäljaren till försäljningschefen i chefshierarkin, och har även befattningen Försäljning i befattningshierarkin:
Om du vill lägga till en användare till en viss befattning i befattningshierarkin använder du uppslagsfältet Befattning i användarpostens formulär enligt nedan:
Viktigt!
Om du vill lägga till en användare till en befattning eller ändra användarens befattning, måste du ha privilegiet Tilldela befattning för en användare.
Om du vill ändra befattningen på användarpostens formulär, väljer de Mer (...) i navigeringsfältet och väljer en annan befattning enligt nedan:
Att skapa en befattningshierarki:
Gå till Inställningar>Säkerhet.
Välj Befattningar.
Ange namnet på befattningen, överordnad befattning och beskrivning för varje befattning. Lägg till användare i den här befattningen genom att använda uppslagsfältet Användare i den här befattningen. Nedan finns exempel på Befattningshierarki med aktiva befattningar.
Exempel på aktiverade användare med deras motsvarande befattningar visas nedan:
Prestandaöverväganden
Om du vill öka prestanda rekommenderar vi:
Hålla den effektiva hierarkisäkerheten till 50 användare eller färre under en chef/befattning. Hierarkin kan ha mer än 50 användare under en chef/befattning, men du kan använda Djup-inställningen för att minska antalet nivåer för skrivskyddad åtkomst och på så sätt begränsa det effektiva antalet användare under en chef/befattning till 50 användare eller mindre.
Använd hierarkisäkerhetsmodeller tillsammans med andra befintliga säkerhetsmodeller för mer komplexa scenarier. Undvika att skapa ett stort antal affärsenheter, skapa i stället färre affärsenheter och lägg till hierarkisäkerhet.
Se även
Säkerhetkoncept för Microsoft Dynamics 365 for Customer Engagement
Fråga och visualisera hierarkiska data