Del via


Hierarkisk sikkerhed med henblik på at styre adgang

Hierarkisikkerhedsmodellen er en udvidelse af de eksisterende sikkerhedsmodeller, der bruger afdelinger, sikkerhedsroller, deling og teams. Den kan bruges sammen med alle andre eksisterende sikkerhedsmodeller. Hierarkisikkerheden giver en mere detaljeret adgang til poster for en organisation og hjælper med at nedbringe vedligeholdelsesomkostningerne.

For eksempel kan du i komplekse scenarier starte med at oprette flere afdelinger og derefter tilføje hierarkisikkerheden. Dette tilføjede sikkerhed leverer en mere detaljeret adgang til data med langt færre vedligeholdelsesomkostninger, som et stort antal afdelinger kan kræve.

Sikkerhedsmodeller til lederhierarki og stillingshierarki

To sikkerhedsmodeller kan bruges til hierarkier, lederhierarki og stillingshierarki. Med lederhierarki skal en leder være i samme afdeling som den underordnede eller i den overordnede afdeling for den underordnedes afdeling for at kunne få adgang til den underordnedes data. Stillingshierarkiet tillader dataadgang på tværs af afdelinger. Hvis du er en økonomisk organisation, foretrækker du måske, at administratormodellen af hierarki skal forhindre chefens adgang til data uden for deres afdelinger. Men hvis du er en del af en kundeserviceorganisationen og vil have lederne til at have adgang til servicesager, der håndteres i forskellige afdelinger, vil stillingshierarkiet fungere bedre for dig.

Bemærk

Hvor den hierarkiske sikkerhedsmodel giver et bestemt niveau for adgang til data, kan yderligere adgang opnås ved hjælp af andre former for sikkerhed, som f.eks. sikkerhedsroller.

Lederhierarki

Sikkerhedsmodellen med lederhierarkier er baseret på en administrationskæde eller en direkte rapporteringsstruktur, hvor lederens navn og den underordnedes relation er etableret ved hjælp af feltet Leder på systembrugertabellen. Med denne sikkerhedsmodel kan lederne få adgang til de data, som deres underordnede har adgang til. De er i stand til at udføre arbejde på vegne af deres direkte rapporter eller få adgang til oplysninger, der kræver godkendelse.

Bemærk

Med sikkerhedsmodellen til lederhierarki har en leder adgang til de poster, der ejes af en bruger eller af teamet, som en bruger er medlem af, og til de poster, der deles direkte med brugeren eller teamet. Når en post deles af en bruger, der er uden for administrationskæden, til en direkte underordnet med skrivebeskyttet adgang, har den direkte underordnedes leder kun skrivebeskyttet adgang til den delte post.

Når du har aktiveret Postejerskab på tværs af afdelinger, kan lederen have direkte underordnede fra forskellige afdelinger. Du kan bruge følgende indstillinger i miljødatabasen til at fjerne begrænsningen for afdelingen.

ManagersMustBeInSameOrParentBusinessUnitAsReports

standard = sand

Du kan angive den til falsk, og chefens afdeling behøver ikke at være den samme som for den direkte underordnede.

Ud over lederhierarki-sikkerhedsmodellen skal en leder have mindst læserettigheder på brugerniveau til en tabel for at se den underordnedes data. Hvis en leder f.eks. ikke har læseadgang til tabellen Sag, kan lederen ikke se de sager, som deres underordnede har adgang til.

For en ikke-direkte rapport i den samme administrationskæde for lederen har en leder skrivebeskyttet adgang til den ikke-direkte rapports data. For en direkte underordnet har en leder læse-, skrive-, tilføje-, og AppendTo-adgang til den underordnedes data. For at illustrere lederhierarki-sikkerhedsmodellen kan vi se på nedenstående diagram. Den administrerende direktør kan læse eller opdatere salgsdirektørens og underdirektørens data. Men den administrerende direktør kan kun læse salgsdirektørens data og underdirektørens data samt data til salg og support. Du kan yderligere begrænse mængden data, der er tilgængelige for en leder med Dybde. Dybde bruges til at begrænse, hvor mange niveauer en leder har skrivebeskyttet adgang til deres underordnedes data. Hvis dybden f.eks. er indstillet til 2, kan den administrerende direktør se dataene for salgsdirektøren, underdirektøren og salgs- og serviceledere. Den administrerende direktør kan dog ikke se dataene for salg eller support.

Skærmbillede, der viser lederhierarkiet. Dette hierarki omfatter CEO, VP of Sales, VP for Service, Sales Managers, Service Managers, Salg og Support.

Det er vigtigt at bemærke, at hvis en direkte rapport har dybere sikkerhedsadgang til en tabel end deres leder, kan lederen måske ikke se alle de poster, som den direkte rapport har adgang til. Følgende eksempel illustrerer dette.

  • En enkelt afdeling har tre brugere: bruger 1, bruger 2 og bruger 3.

  • Bruger 2 er en direkte rapport til bruger 1.

  • Bruger 1 og bruger 3 har læseadgang på brugerniveau til tabellen Firma. Dette adgangsniveau giver brugere adgang til poster, de ejer, poster, som deles med brugeren, og poster, der deles med det team, som brugeren er medlem af.

  • Bruger 2 har læseadgang på afdelingsniveau til tabellen Firma. Denne adgang tillader bruger 2 at se alle firmaerne for afdelingen, herunder alle de firmaer, der ejes af bruger 1 og bruger 3.

  • Bruger 1 har som direkte leder af bruger 2 adgang til de firmaer, der ejes af eller deles med bruger 2, og alle de firmaer der er delt med, eller som ejes af et team, som bruger 2 er medlem af. Men bruger 1 har dog ikke adgang til firmaerne for bruger 3, selvom deres direkte rapport har adgang til firmaerne for bruger 3.

Stillingshierarki

Stillingshierarkiet ikke er baseret på direkte rapporteringsstrukturen som Manager-hierarki. En bruger behøver ikke være en faktisk leder af en anden bruger adgang til brugerens data. Som administratorer kan du definere forskellige stillinger i organisationen og arrangere dem i stillingshierarkiet. Du kan derefter føje brugere til en bestemt stilling eller såkaldt mærke en bruger med en bestemt stilling. En bruger kan kun være mærket med ét stilling i et bestemt hierarki - en stilling kan dog bruges til flere brugere. Brugere i de højeste stillinger i hierarkiet har adgang til data om brugerne i de nederste stillinger i stien med direkte overordnede. De direkte højeste stillinger har adgang til at læse, skrive, tilføje og AppendTo-adgang til de lavere stillinger i stien med direkte overordnede. De ikke-direkte højeste stillinger har skrivebeskyttet adgang til de lavere stillinger i stien med direkte overordnede.

For at illustrere begrebet direkte overordnet-stien kan vi se på nedenstående diagram. Salgschef-stillingen har adgang til salgsdata, men den har ikke adgang til supportdata, som er i anden overordnet sti. Det samme gælder for stillingen som servicechef. Den har ikke adgang til salgsdata, som er i salgsstien. Som i lederhierarkiet kan du begrænse mængden af data, der er tilgængelige for højere stillinger, med Dybde. Dybden begrænser, hvor mange niveauer ned en højere stilling har skrivebeskyttet adgang til data i de lavere stillinger i stien direkte overordnet. Hvis dybden f.eks. er indstillet til 3, vil den administrerende direktør kunne se dataene helt ned fra salgsdirektøren og underdirektøren, til salg og support.

Skærmbillede, der viser stillingshierarkiet. Dette hierarki omfatter CEO, VP of Sales, VP for Service, Sales Managers, Service Managers, Salg og Support.

Bemærk

Med stillingshierarkisikkerheden har en bruger i en højere stilling adgang til de poster, der ejes af en bruger i en lavere stilling eller af teamet, som en bruger er medlem af, og til de poster, der deles direkte med brugeren eller teamet.

Ud over sikkerhedsmodellen for stillingshierarkiet skal brugere på et højere niveau have mindst læserettigheder på brugerniveau på en tabel for at få vist de poster, som brugere i lavere stillinger har adgang til. For eksempel, hvis en bruger på et højere niveau ikke har læseadgang til tabellen Sag, vil brugeren ikke kunne se de sager, som brugerne i lavere stillinger har adgang til.

Konfigurere hierarkisk sikkerhed

Kontrollér, at du har de relevante tilladelser som Systemadministrator til at opdatere indstillingen, hvis du skal oprette hierarkisikkerhed.

Hierarkisikkerheden er som standard deaktiveret. Fuldfør følgende trin for at aktivere hierarkisikkerhed.

  1. Vælg et miljø, og gå til Indstillinger>Brugere og tilladelser>Hierarkisk sikkerhed.

  2. Vælg enten Aktivér lederhierarkimodel eller Aktivér stillingshierarkimodel under Hierarkimodel, afhængigt af dine behov.

    Vigtigt

    For at kunne foretage ændringer i Hierarkisikkerhed skal du have rettigheden Ændre sikkerhedsindstillinger i hierarkiet.

    I området Hierarkitabelstyring er alle systemtabeller aktiverede for hierarkisikkerhed som standard, men du kan udelade udvalgte tabeller fra hierarkiet. Hvis du vil udelade specifikke tabeller fra hierarkimodellen, skal du fjerne markeringen ud for de tabeller, du vil udelukke og gemme ændringerne.

    Skærmbillede af siden Hierarkisikkerhed under Indstillinger for miljøer.

  3. Indstil Dybde til den ønskede værdi for at begrænse, hvor mange niveauer ned en leder har skrivebeskyttet adgang til sine underordnede.

    Hvis f.eks. dybden er lig med 2, har en leder kun adgang til deres egne konti og konti for rapporter i to niveauers dybde. Hvis du i eksemplet logger på apps til kundeengagement som salgsdirektør uden administrator, kan du kun se de aktive konti for brugerne som vist:

    Skærmbillede, der viser læseadgang for salgsdirektører og andre placeringer.

    Bemærk

    Mens hierarkisikkerheden giver salgsdirektøren adgang til poster i den røde firkant, kan han få yderligere adgang baseret på den sikkerhedsrolle, som salgsdirektøren har.

  4. I sektionen Hierarkitabelstyring er alle systemtabeller som standard aktiveret for hierarkisikkerhed. Hvis du vil udelade en bestemt tabel fra hierarkimodellen, skal du fjerne markeringen ud for tabelnavnet og gemme ændringerne.

    Skærmbillede, der viser, hvor du kan konfigurere hierarkisikkerhed under Indstillinger for den nye, moderne brugergrænseflade.

    Vigtigt!

    • Dette er en forhåndsversion af funktionen.
    • Forhåndsversionsfunktionerne er ikke beregnet til produktionsformål og kan have begrænset funktionalitet. Disse funktioner er tilgængelige før en officiel udgivelse, så kunderne kan få tidlig adgang og give feedback.

Oprette leder- og stillingshierarkier

Lederhierarkiet oprettes let ved hjælp af lederrelationen på systembrugerposten. Du kan bruge Leder (ParentsystemuserID)-opslagsfelt til at angive brugerens leder. Hvis du allerede har oprettet stillingshierarkiet, kan du også mærke bruger med en bestemt placering i stillingshierarkiet. I følgende eksempel refererer sælgeren til salgschefen i lederhierarkiet og har også en salgsposition i stillingshierarkiet:

Skærmbillede, der viser en sælgerbrugerpost.

For at føje en bruger til en bestemt stilling i stillingshierarkiet kan du bruge opslagsfeltet Stilling i formularen til brugerposten.

Vigtigt

Hvis du vil føje en bruger til en stilling eller ændre brugerens stilling, skal du have rettigheden Tildele stilling for en bruger.

Skærmbillede, der viser, hvordan du føjer en bruger til en placering i Hierarkisikkerhed

Hvis du vil ændre stillingen i brugerpostformularen på navigationslinjen, kan du vælge Flere (...) og vælge en anden stilling.

Skift placering i hierarkisk sikkerhed

Sådan oprettes et stillingshierarki:

  1. Vælg et miljø, og gå til Indstillinger>Brugere og tilladelser>Placeringer.

    Angiv navnet på stillingen og den overordnede stilling samt beskrivelsen. Føj brugere til denne stilling ved hjælp af opslagsfeltet Brugere i denne stilling. Følgende billede er et eksempel på stillingshierarki med de aktive stillinger.

    Aktive placeringer i Hierarkisk sikkerhed

    Eksemplet med de aktiverede brugere med deres tilsvarende stillinger er vist i følgende billede.

    Skærmbillede, der viser aktiverede brugere med tildelte placeringer.

Medtage eller udelukke poster, der ejes af direkte rapporter med deaktiveret brugerstatus

Chefer kan se posterne for direkte rapporter for deaktiverede status for miljøer, hvor hierarkisikkerhed er aktiveret efter 31. januar 2024. I andre miljøer medtages de deaktiverede direkte statusrapporters poster ikke i chefens visning.

Sådan medtages poster for direkte rapporter med deaktiveret status:

  1. Installere værktøjet OrganizationSettingsEditor.
  2. Opdater indstillingen AuthorizationEnableHSMForDisabledUsers til sand.
  3. Deaktivér hierarkimodeller.
  4. Genaktiver den igen.

Sådan ekskluderes poster for direkte rapporter med deaktiveret status:

  1. Installere værktøjet OrganizationSettingsEditor.
  2. Opdater indstillingen AuthorizationEnableHSMForDisabledUsers til falsk.
  3. Deaktivér hierarkimodeller.
  4. Genaktiver den igen.

Bemærk

  • Når du deaktiverer og genaktiverer hierarkimodellerne, kan det tage tid at opdatere, da systemet skal have adgang til posten igen.
  • Hvis der er timeout, kan du reducere antallet af tabeller på listen Administration af hierarkitabel, så du kun medtager tabeller, der skal vises af lederen. Hvis timeouten varer ved, skal du sende en supportbillet for at anmode om hjælp.
  • De poster, der er poster for direkte deaktiverede statusrapporter, medtages, hvis disse poster deles med en anden direkte rapport, der er aktiv. Du kan udelukke disse poster ved at fjerne delingen.

Ydelsesovervejelser

For at øge ydeevnen anbefales det:

  • Hold den effektive hierarkisikkerhed til 50 brugere eller mindre under en leder eller stilling. Hierarkiet kan have mere end 50 brugere under en overordnet/stilling, men du kan bruge indstillingen Dybde til at reducere antallet af niveauer for skrivebeskyttet adgang, og med denne grænse, effektiv mindre eller antallet af brugere under en overordnet stilling til 50 brugere eller færre.

  • Brug hierarkisikkerhedsmodeller med andre eksisterende sikkerhedsmodeller til mere komplekse scenarier. Undgå at oprette et stort antal afdelinger. Opret i stedet færre afdelinger, og føj sikkerhed til hierarkiet.

Se også

Sikkerhed i Microsoft Dataverse
Forespørge på og visualisere hierarkiske data