Sikkerhedsbegreber i Microsoft Dataverse

En af de vigtigste funktioner i Dataverse er en omfattende sikkerhedsmodel, der kan tilpasses i mange scenarier for forretningsbrug. Sikkerhedsmodellen kan kun bruges, når der er en Dataverse-database i miljøet. Som en administrator vil du sandsynligvis ikke selv opbygge hele sikkerhedsmodellen, men du bliver ofte involveret i processen til administration af brugere og sikring af, at de har den rette konfiguration og problemer med fejlfinding af sikkerhedsadgang.

Tip

Se følgende video: Microsoft Dataverse - Sikkerhedsbegreber, der vises i demoer.

Rollebaseret sikkerhed

Dataverse bruger rollebaseret sikkerhed til at gruppere en samling af rettigheder. Disse sikkerhedsroller kan knyttes direkte til brugere, eller de kan knyttes til Dataverse-teams og -afdelinger. Brugere kan derefter knyttes til teamet, og derfor vil alle de brugere, der er knyttet til teamet, drage nytte af rollen. Et vigtigt koncept for Dataverse-sikkerhed er at forstå, at alle rettighedstildelinger akkumuleres med det største antal gældende adgangstilladelser. Hvis du har givet bred læseadgang på organisationsniveau til alle kontaktposter, kan du ikke gå tilbage og skjule en enkelt post.

Afdelinger

Tip

Tjek følgende video: Modernisere afdelinger.

Afdelinger arbejder med sikkerhedsroller for at afgøre, hvilken effektiv sikkerhed en bruger har. Afdelinger er en byggeblok for sikkerhedsmodellering, som hjælper med at administrere brugere og de data, de har adgang til. Afdelinger definerer en sikkerhedsgrænse. Alle Dataverse-databaser har en enkelt rodafdeling.

Du kan oprette underafdelinger for yderligere at segmentere brugerne og dataene. Alle brugere, der er tildelt til et miljø, tilhører en afdeling. Mens afdelinger kan bruges til 1:1-modellering af et ægte organisationshierarki, bliver de ofte defineret med bestemte sikkerhedsgrænser, der er nødvendige for at indfri sikkerhedsmodellens behov.

Lad os se på følgende eksempel for at lette forståelsen. Vi har tre afdelinger. Woodgrove er rodafdelingen og vil altid være øverst, men den kan ikke ændres. Vi har oprettet to andre underordnede afdelinger, A og B. Brugere i disse afdelinger har meget forskellige adgangsbehov. Når vi knytter en bruger til dette miljø, kan vi angive, at brugeren skal være medlem af en af disse tre afdelinger. Hvor brugeren er tilknyttet, afgør, hvilken afdeling der ejer de poster, som brugeren er ejer af. Ved hjælp af denne tilknytning kan vi tilpasse en sikkerhedsrolle, som giver brugeren mulighed for at se alle poster i den pågældende afdeling.

Hierarkisk dataadgangsstruktur

Kunder kan bruge en organisationsstruktur, hvor data og brugere bliver opdelt i et trælignende hierarki.

Når vi knytter en bruger til dette miljø, kan vi angive, at brugeren skal være i en af disse tre afdelinger, og tildele en sikkerhedsrolle fra afdelingen til brugeren. Den afdeling, som brugeren er tilknyttet, bestemmer, hvilken afdeling der ejer posterne, når brugeren opretter en post. Ved hjælp af denne tilknytning kan vi tilpasse en sikkerhedsrolle, som giver brugeren mulighed for at se poster i den pågældende afdeling.

Bruger A er knyttet til division A og har fået tildelt sikkerhedsrolle Y fra division A. Det giver bruger A adgang til posterne for kontakt nr. 1 og kontakt nr. 2. Derimod har bruger B i division B ikke adgang til division A's kontaktpersonposter, men har adgang til posten for kontakt nr. 3.

Adgangsstruktur for matrixdata (Moderniser afdelinger)

Kunder kan bruge en organisationsstruktur, hvor data opdeles i et trælignende hierarki, og hvor brugere kan arbejde med og få adgang til alle afdelingsdata, uanset hvilken afdeling brugeren er tildelt til.

Når vi knytter en bruger til dette miljø, kan vi angive, at brugeren skal være medlem af en af disse tre afdelinger. For hver afdeling, som kræves for en bruger for at få adgang til data i en afdeling, tildeles der en sikkerhedsrolle fra den pågældende afdeling til brugeren. Når brugeren opretter en post, kan brugeren angive, at afdelingen skal eje posten.

Bruger A kan knyttes til en hvilken som helst af afdelingerne, herunder rodafdelingen. Sikkerhedsrolle Y fra division A tildeles til bruger A, hvilket giver brugeren adgang til poster for kontakt nr. 1 og kontakt nr. 2. Sikkerhedsrolle Y fra division B tildeles til bruger A, hvilket giver brugeren adgang til posten for kontakt nr. 3.

Aktivere adgangsstruktur for matrixdata

Bemærk

Før du aktiverer denne funktion, skal du publicere alle dine tilpasninger for at aktivere alle dine nye ikke-publicerede tabeller for funktionen. Hvis du opdager, at du har ikke-publicerede tabeller, der ikke virker sammen med denne funktion, efter at du har slået den til, kan du angive indstillingen RecomputeOwnershipAcrossBusinessUnits ved hjælp af værktøjet OrgDBOrgSettings til Microsoft Dynamics CRM. Hvis du angiver RecomputeOwnershipAcrossBusinessUnits til sand, kan feltet Ejende afdeling angives og opdateres.

1. Log på Power Platform Administration som administrator (Dynamics 365-administrator, Global administrator eller Microsoft Power Platform-administrator).
2. Vælg Miljøer, og vælg derefter det miljø, du vil aktivere denne funktion for.
3. Vælg Indstillinger>Produkt>Funktioner.
4. Slå parameteren Postejerskab på tværs af afdelingertil.

Når denne funktionsparameter er slået til, kan du vælge Afdeling, når du tildeler en sikkerhedsrolle til en bruger. Det giver dig mulighed for at tildele en sikkerhedsrolle fra forskellige afdelinger til en bruger. Brugeren skal også have en sikkerhedsrolle fra den afdeling, som brugeren er tildelt til, med rettigheder til brugerindstillinger til at køre modelbaserede apps. Du kan gå til sikkerhedsrollen Basic-bruger for at finde ud af, hvordan disse rettigheder til brugerindstillinger er aktiveret.

Du kan tildele en bruger som postejer i en hvilken som helst afdeling uden at skulle tildele en sikkerhedsrolle i postens ejende afdeling, så længe brugeren har en sikkerhedsrolle, der har rettigheden Læs til posttabellen. Se Ejerskab af poster i moderne afdelinger.

Bemærk

Dette funktionsskift lagres i indstillingen EnableOwnershipAcrossBusinessUnits og kan også angives ved hjælp af værktøjet OrgDBOrgSettings til Microsoft Dynamics CRM.

Tilknytte en afdeling til en Microsoft Entra-sikkerhedsgruppe

Du kan bruge en Microsoft Entra-sikkerhedsgruppe til at tilknytte afdelingen for at strømline brugeradministrationen og rolletildelingen.

Opret en Microsoft Entra-sikkerhedsgruppe for hver afdeling, og tildel de respektive afdelingssikkerhedsroller til de enkelte gruppeteams.

Opret en Microsoft Entra-sikkerhedsgruppe for hver enkelt afdeling. Opret et Dataverse-gruppeteam for de enkelte Microsoft Entra-sikkerhedsgrupper. Tildel de respektive sikkerhedsroller fra afdelingen til de enkelte Dataverse-gruppeteams. Brugeren i ovenstående diagram oprettes i rodafdelingen, når brugeren får adgang til miljøet. Det er ok at have brugeren og Dataverse-gruppeteamet i rodafdelingen. De har kun adgang til data i den afdeling, hvor sikkerhedsrollen er tildelt.

Føj brugere til den pågældende Microsoft Entra-sikkerhedsgruppe for at give dem adgang til afdelingen. Brugerne kan straks køre appen og få adgang til dens ressourcer/data.

I matrixdataadgangen, hvor brugere kan arbejde med og få adgang til data fra flere afdelinger, skal du føje brugerne til de Microsoft Entra-sikkerhedsgrupper, der er knyttet til de pågældende afdelinger.

Ejende afdeling

Hver post indeholder kolonnen Ejende afdeling, som bestemmer, hvilken afdeling der ejer posten. Denne kolonne bruges som standard til brugerens afdeling, når posten oprettes, og kan ikke ændres, undtagen når funktionsparameteren er slået TIL.

Bemærk

Når du ændrer, hvilken afdeling der ejer en post, skal du kontrollere følgende for at få overlappende effekt: Brug af SDK for .NET til at konfigurere overlappende funktionsmåde.

Du kan styre, om du vil give brugeren tilladelse til at angive kolonnen Ejende afdeling, når funktionsparameteren er slået TIL. Hvis du vil angive kolonnen Ejende afdeling, skal du tildele brugerens sikkerhedsrolle rettigheden Føj til i tabellen Afdeling med tilladelse på lokalt niveau.

Du kan give brugeren mulighed for at angive kolonnen ved at aktivere den i det følgende:

1. Formular – både brødteksten og overskriften.
2. Visning.
3. Kolonnetilknytninger. Hvis du bruger AutoMapEntity, kan du angive kolonnen i kolonnetilknytningen.

Bemærk

Hvis du har et job/en proces til synkronisering af data mellem miljøer, og Ejende afdeling er inkluderet som en del af skemaet, mislykkes dit job med en begrænsningsovertrædelse af en Fremmed nøgle, hvis destinationsmiljøet ikke har samme værdi for Ejende afdeling.

Du kan enten fjerne kolonnen Ejende afdeling fra kildeskemaet eller opdatere værdien i kolonnen Ejende afdeling i kilden til en af afdelingerne i målet.

Hvis du har et job/en proces, der kopierer data fra et miljø til en ekstern ressource, f.eks. PowerBI, skal du vælge eller fravælge kolonnen Ejende afdeling fra kilden. Vælg den, hvis ressourcen kan modtage den, ellers skal du fravælge den.

Ejerskab af tabel/post

Der understøttes to typer postejerskab i Dataverse. Organisationsejet og bruger- eller temejet. Det er et valg, der sker på det tidspunkt, hvor tabellen oprettes, og kan ikke ændres. Af sikkerhedsmæssige årsager er det eneste valg på adgangsniveau enten, at brugeren kan udføre handlingen eller ikke for poster, som organisationen ejer. For bruger- og teamejede poster er valgmulighederne på adgangsniveau for de fleste rettigheder niveauinddelt: Organisation, Afdeling, Afdeling og underordnet afdeling eller kun brugerens egne poster. Det betyder, at for læserettigheder på kontaktperson kunne jeg angive brugerejet, så brugeren kan kun se egne poster.

Lad os antage, at bruger A er knyttet til afdeling A, og vi giver dem læseadgang på kontaktperson som afdelingsniveau. De kan se Kontaktperson 1 og Kontaktperson 2, men ikke Kontaktperson 3.

Når du konfigurerer eller redigerer rettigheder til sikkerhedsroller, angiver du adgangsniveauet for de enkelte indstillinger. Det følgende er et eksempel på editoren til sikkerhedsrollens rettigheder.

I ovenstående kan du se standardrettighedstyperne for hver tabel: Opret, Læs, Skriv, Slet, Tilføj, Føj til, Tildel og Del. Du kan redigere de enkelte af disse individuelt. Den visuelle visning af hver af dem stemmer overens med nedenstående nøgle i forhold til, hvilket adgangsniveau du har tildelt.

I eksemplet herover har vi givet adgang til kontakt på organisationsniveau, hvilket betyder, at brugeren i Division A kan se og opdatere de kontakter, der ejes af alle. Det er faktisk en af de mest almindelige administrative fejl at blive frustreret over tilladelser og bare give for omfattende adgang. Meget hurtigt vil en veludformet sikkerhedsmodel begynde at se ud som schweiziske oste (fuld af huller!).

Ejerskab af poster i moderne afdelinger

I moderne afdelinger kan brugerne være ejere af poster på tværs af alle afdelinger. Det eneste, brugerne skal have, er en sikkerhedsrolle (en hvilken som helst afdeling), som har rettigheden Læs til posttabellen. Brugerne behøver ikke at have fået tildelt en sikkerhedsrolle i hver enkelt afdeling, hvor posten findes.

Hvis Postejerskab på tværs af afdelinger blev aktiveret i produktionsmiljøet i forhåndsversionsperioden, skal du udføre følgende for at aktivere dette postejerskab på tværs af afdelinger:

1. Installere Indstillinger for organisation-editor
2. Angiv organisationsindstillingerne RecomputeOwnershipAcrossBusinessUnits til sand. Når denne indstilling angives til true, er systemet låst, og det kan tage op til 5 minutter at udføre genberegning for at aktivere den funktion, hvor brugere nu kan eje poster på tværs af afdelinger uden at skulle tildeles separate sikkerhedsrolle fra de enkelte afdelinger. Det giver en ejer af en post mulighed for at tildele posten til en person uden for postens ejende afdeling.
3. Angiv AlwaysMoveRecordToOwnerBusinessUnit som falsk. Det får posten til at forblive i den oprindelige ejende afdeling, når ejerskabet af posten ændres.

I alle miljøer, der ikke er produktionsmiljøer, skal du blot angive AlwaysMoveRecordToOwnerBusinessUnit til falsk for at bruge denne funktion.

Bemærk

Hvis du deaktiverer ejerskabet for posten på tværs af afdelinger eller angiver indstillingen RecomputeOwnershipAcrossBusinessUnits til false ved hjælp af OrgDBOrgSettings-værktøjet til Microsoft Dynamics CRM kan du ikke angive eller opdatere feltet Ejende afdeling, og alle poster, hvor feltet Ejende afdeling er forskelligt fra ejerens afdeling, opdateres med ejerens afdeling.

Teams (herunder gruppeteams)

Teams er en anden vigtig byggeblok for sikkerhed. Teams ejes af en afdeling. Alle afdelinger har ét standardteam, der automatisk oprettes, når afdelingen oprettes. Standardteammedlemmerne administreres af Dataverse og indeholder altid alle de brugere, der er knyttet til den pågældende afdeling. Du kan ikke manuelt tilføje eller fjerne medlemmer fra standardteamet, men de justeres dynamisk af systemet, når nye brugere knyttes til/fjernes fra afdelinger. Der findes to typer teams: ejende teams og adgangsteams.

• Ejende teams kan eje poster, hvilket giver et teammedlem direkte adgang til den pågældende post. Brugere kan være medlem af flere teams. Det betyder, at det kan være en effektiv måde at give tilladelser til brugerne på i bred forstand, uden at skulle administrere adgangen på de enkelte brugerniveauer.
• Adgangsteams gennemgås i næste afsnit som en del af postdeling.

Deling af poster

Individuelle poster kan deles enkeltvist med en anden bruger. Det er en effektiv måde at håndtere undtagelser på, som ikke falder inden for postejerskabet eller medlemskabet af en afdelings adgangsmodel. Det skal dog være en undtagelse, da det er en mindre effektiv måde at styre adgangen på. Det er sværere at foretage fejlfinding af deling, da det ikke er en konsekvent implementeret adgangskontrol. Deling kan udføres på både bruger- og teamniveau. Deling med et team er en mere effektiv måde at dele på. Det er mere avanceret at dele med adgangsteam, der giver automatisk oprettelse af et team og deling af postadgang med teamet er baseret på en Adgangsteamskabelon (en skabelon med tilladelser), som anvendes. Adgangsteams kan også bruges uden skabelonerne, med blot manuel tilføjelse eller fjernelse af medlemmer. Adgangsteams er mere effektive, da de ikke tillader, at poster ejes af teamet, eller det har fået tildelt sikkerhedsroller. Brugerne får adgang, fordi posten deles med teamet, og brugeren er medlem.

Sikkerhed på postniveau i Dataverse

Du tænker måske over, hvad der bestemmer din adgang til en post? Det lyder som et simpelt spørgsmål, men for en hvilken som helst bruger er det kombinationen af alle deres sikkerhedsroller, den afdeling, de er knyttet til, de teams, de er medlem af, og de poster, der deles med dem. Det vigtigste at huske er, at al adgang er akkumuleret over alle disse koncepter i omfanget af et Dataverse-databasemiljø. Disse berettigelser tildeles kun i en enkelt database og spores enkeltvis i hver Dataverse-database. Alt dette kræver den relevante licens for at få adgang til Dataverse.

Sikkerhed på kolonneniveau i Dataverse

Nogle gange er adgangskontrol på postniveau ikke tilstrækkelig til visse forretningsscenarier. Dataverse har en sikkerhedsfunktion på kolonneniveau, der giver mulighed for mere detaljeret kontrol af sikkerhed på kolonneniveau. Sikkerhed på kolonneniveau kan aktiveres på alle brugerdefinerede kolonner og de fleste systemkolonner. De fleste systemkolonner, der indeholder personligt identificerbare oplysninger (PII), kan sikres individuelt. De enkelte kolonners metadata definerer, hvis dette er en tilgængelig indstilling for systemkolonnen.

Sikkerhed på kolonneniveau er aktiveret på kolonnebasis. Adgang administreres derefter ved at oprette en kolonnesikkerhedsprofil. Profilen indeholder alle kolonner, hvor sikkerhed på kolonneniveau er aktiveret, og den adgang, der er tildelt af den pågældende profil. De enkelte kolonner kan styres i profilen for Opret-, Opdater- og Læs-adgang. Kolonnesikkerhedsprofiler knyttes derefter til en bruger eller teams for at give dem rettigheder til de poster, de allerede har adgang til. Det er vigtigt at være opmærksom på, at sikkerhed på kolonneniveau ikke har noget at gøre med sikkerhed på postniveau. En bruger skal allerede have adgang til posten for kolonnesikkerhedsprofilen for at give vedkommende adgang til kolonnerne. Sikkerhed på kolonneniveau skal bruges efter behov og ikke i stort omfang, da det kan give spild af ressourcer.

Administration af sikkerhed på tværs af flere miljøer

Sikkerhedsroller og kolonnesikkerhedsprofiler kan pakkes og flyttes fra ét miljø til det næste ved hjælp af Dataverse-løsninger. Afdelinger og teams skal oprettes og administreres i hvert miljø sammen med brugernes tildelinger af de nødvendige sikkerhedskomponenter.

Konfiguration af sikkerhed for brugermiljø

Når roller, teams og afdelinger er oprettet i et miljø, er tiden inde til at tildele brugerne deres sikkerhedskonfigurationer. Når du opretter en bruger, skal du først knytte brugeren til en afdeling. Det er som standard rodafdelingen i organisationen. De føjes også til standardgruppen for den pågældende afdeling.

Derudover skal du tildele eventuelle sikkerhedsroller, som brugeren skal have. Du kan også tilføje dem som medlemmer af ethvert team. Husk på, at teams også kan have sikkerhedsroller, så brugerens effektive rettigheder er en kombination af direkte tildelte sikkerhedsroller og rettighederne for de teams, de er medlem af. Sikkerhed er altid akkumuleret og giver den mindst restriktive tilladelse blandt deres berettigelser. Følgende er en god gennemgang af , hvordan du konfigurerer miljøsikkerhed.

Hvis du har brugt sikkerhed på kolonneniveau, skal du knytte brugeren eller et af brugerens teams til en af de kolonnesikkerhedsprofiler, du har oprettet.

Sikkerhed er en kompleks sag, der bedst udføres som en fælles indsats mellem programudviklerne og det team, der administrerer brugertilladelserne. Større ændringer bør ske samordnet i god tid under før installationen af ændringerne i miljøet.

Se også

Konfigurere sikkerhed for miljø
Sikkerhedsroller og rettigheder