Sikkerhetskonsepter i Microsoft Dataverse

En viktig funksjon i Dataverse er en omfattende sikkerhetsmodell som kan tilpasses mange scenarier for forretningsbruk. Denne sikkerhetsmodellen er bare gjeldende når det er en Dataverse-database i miljøet. Som administrator vil du trolig ikke bygge hele sikkerhetsmodellen selv, men vil ofte være involvert i prosessen med å lede brukere og sørge for at de har riktig konfigurasjon og feilsøke sikkerhetstilgangsrelaterte problemer.

Tips

Videosymbol Se følgende video: – Microsoft Dataverse - Sikkerhetskonsepter vist i demonstrasjoner.

Rollebasert sikkerhet

Dataverse-bruker rollebasert sikkerhet til å gruppere sammen en samling rettigheter. Disse sikkerhetsrollene kan knyttes direkte til brukere, eller de kan knyttes til Dataverse-team og forretningsenheter. Brukere kan deretter knyttes til teamet, og derfor vil alle brukere som er tilknyttet teamet, dra nytte av rollen. Et viktig konsept for Dataverse-sikkerhet som bør forstås, er at alle tilgangstyper akkumuleres med største gjeldende tilgang. Hvis du ga lesetilgang til alle kontaktoppføringer på organisasjonsnivå, kan du ikke gå tilbake og skjule en enkelt oppføring.

Forretningsenheter

Tips

Sjekk ut følgende video: Modernisere forretningsenheter.

Forretningsenheter arbeider med sikkerhetsroller for å avgjøre hvilken effektiv sikkerhet en bruker har. Forretningsenheter er en byggeblokk for sikkerhetsmodellering som bidrar til å administrere brukere og dataene de har tilgang til. Forretningsenheter definerer en sikkerhetsrgrense. Hver Dataverse-database har én enkelt rotforretningsenhet.

Du kan opprette underordnede forretningsenheter for å segmentere brukere og data ytterligere. Hver bruker som er tilordnet til et miljø, hører til i en forretningsenhet. Når du kan bruke forretningsenheter til å modellere 1:1 i et virkelig organisasjonshierarki, er det ofte brukt bare definerte sikkerhetsgrenser som bidrar til å oppnå behovene for sikkerhetsmodellen.

La oss se på eksemplet nedenfor for å forstå dette bedre. Vi har tre forretningsenheter. Woodgrove er rotforretningsenheten og vil alltid være øverst. Det kan ikke endres. Vi har opprettet to andre underordnede forretningsenheter A og B. Brukere i disse forretningsenhetene har svært ulike tilgangsbehov. Når vi knytter en bruker til dette miljøet, kan vi angi at brukeren skal være i én av disse tre forretningsenhetene. Hvor brukeren er tilordnet, avgjør hvilken forretningsenhet som eier oppføringene som brukeren er eieren av. Når vi har denne tilknytningen, kan vi skreddersy en sikkerhetsrolle for å la brukeren å se alle oppføringene i den forretningsenheten.

Hierarkisk datatilgangsstruktur

Kunder kan bruke en organisasjonsstruktur der data og bruker er innrettet i et trelignende hierarki.

Når vi knytter en bruker til dette miljøet, kan vi angi at brukeren skal være i en av disse tre forretningsenhetene og tilordne en sikkerhetsrolle fra forretningsenheten til brukeren. Forretningsenheten brukeren er knyttet til, avgjør hvilken forretningsenhet som eier oppføringene når brukeren oppretter en oppføring. Ved å ha denne tilknytningen kan vi skreddersy en sikkerhetsrolle som gjør det mulig for brukeren å se oppføringer i den forretningsenheten.

Bruker A er knyttet til divisjon A og tilordnet en sikkerhetsrolle Y fra divisjon A. Dette gir bruker A tilgang til oppføringene for kontakt 1 og kontakt 2. Selv om bruker B i divisjon B ikke har tilgang til kontaktoppføringene i divisjon A, har han tilgang til oppføringen for kontakt 3.

Matrisedatatilgangsstruktur (Moderniserte forretningsenheter)

Kunder kan bruke en organisasjonsstruktur der dataene er innrettet i et trelignende hierarki, og brukere kan arbeide med og få tilgang til alle forretningsenhetsdata uavhengig av hvilken forretningsenhet brukeren er tilordnet.

Når vi knytter en bruker til dette miljøet, kan vi angi at brukeren skal være i én av disse tre forretningsenhetene. For hver forretningsenhet der en bruker trenger tilgang til data, tilordnes en sikkerhetsrolle forretningsenhet til brukeren. Når brukeren oppretter en oppføring, kan brukeren angi at forretningsenheten skal eie oppføringen.

Bruker A kan tilknyttes en hvilken som helst forretningsenhet, inkludert rotforretningsenheten. En sikkerhetsrolle Y fra divisjon A tilordnes til bruker A, som gir brukeren tilgang til oppføringer for 1 kontakt og 2. En sikkerhetsrolle Y fra divisjon B tilordnes til bruker A, som gir brukeren tilgang til oppføring for kontakt 3.

Aktiver matrisedatatilgangsstrukturen

Obs!

Før du aktiverer denne funksjonen, må du publisere alle tilpassingene for å aktivere alle de nye upubliserte tabellene for funksjonen. Hvis du ser at du har upubliserte tabeller som ikke fungerer med denne funksjonen etter at du har aktivert den, kan du angi innstillingen RecomputeOwnershipAcrossBusinessUnits ved hjelp av verktøyet OrgDBOrgSettings for Microsoft Dynamics CRM. Angivelse av RecomputeOwnershipAcrossBusinessUnits til sann gjør at feltet Eiende forretningsenhet kan angis og oppdateres.

1. Logg på Power Platform-administrasjonssenteret som en administrator (Dynamics 365-administrator, global administrator eller Microsoft Power Platform-administrator).
2. Velg Miljøer og deretter miljøet du vil aktivere denne funksjonen for.
3. Velg Innstillinger>Produkt>Funksjoner.
4. Slå På bryteren Oppføringseierskap på tvers av forretningsenheter.

Når denne funksjonsbryteren er aktivert, kan du velge Forretningsenhet når du tilordner en sikkerhetsrolle til en bruker. Dermed kan du tilordne en sikkerhetsrolle fra ulike forretningsenheter til en bruker. Brukeren må også ha en sikkerhetsrolle fra forretningsenheten som brukeren er tilordnet til, med brukerinnstillingstillatelser til å kjøre modelldrevne apper. Du kan se sikkerhetsrollen Basic-bruker for å finne ut hvordan disse brukerinnstillingstillatelsene aktiveres.

Du kan tilordne en bruker som oppføringseier i en hvilken som helst forretningsenhet uten å måtte tilordne en sikkerhetsrolle i oppføringens egen forretningsenhet så lenge brukeren har en sikkerhetsrolle som har leserettigheter til oppføringstabellen. Se Registrere eierskap i moderniserte forretningsenheter.

Obs!

Denne funksjonsbryteren lagres i innstillingen EnableOwnershipAcrossBusinessUnits og kan også angis ved hjelp av verktøyet OrgDBOrgSettings for Microsoft Dynamics CRM.

Knytte en forretningsenhet til en Microsoft Entra-sikkerhetsgruppe

Du kan bruke en Microsoft Entra-sikkerhetsgruppe til å tildele forretningsenheten for å effektivisere brukeradministrasjon og rolletilordningen.

Opprett en Microsoft Entra-sikkerhetsgruppe for hver forretningsenhet, og tildel den respektive sikkerhetsrollen for forretningsenhet til hvert gruppeteam.

Opprett en Microsoft Entra-sikkerhetsgruppe for hver forretningsenhet. Opprett et Dataverse-gruppeteam for hver Microsoft Entra-sikkerhetsgruppe. Tilordne den respektive sikkerhetsrollen fra forretningsenheten til hvert Dataverse-gruppeteam. Brukeren i diagrammet ovenfor blir opprettet i rotforretningsenheten når brukeren går til miljøet. Det går greit å ha brukeren og Dataverse-gruppeteamene i rotforretningsenheten. De har bare tilgang til data i forretningsenheten der sikkerhetsrollen er tilordnet.

Legg til brukere i den respektive Microsoft Entra-sikkerhetsgruppen for å gi dem tilgang til forretningsenheten. Brukerne kan umiddelbart kjøre appen og få tilgang til ressursene/dataene.

I matrisedatatilgangen, der brukere kan arbeide og få tilgang til data fra flere forretningsenheter, legger du til brukerne i Microsoft Entra-sikkerhetsgruppene som er tilordnet til disse forretningsenhetene.

Eiende forretningsenhet

Hver oppføring har kolonnen Eiende forretningsenhet, som avgjør hvilken forretningsenhet som eier oppføringen. Denne kolonnen er standard for brukerens forretningsenhet når oppføringen opprettes, og kan ikke endres med unntak av når funksjonsbryteren er aktivert.

Obs!

Når du endrer hvilken forretningsenhet som eier en oppføring, må du kontrollere følgende for å få overlappende virkninger: Bruk SDK for .NET til å konfigurere overlappende funksjonalitet.

Du kan bestemme om du vil at brukeren skal kunne angi kolonnen Eiende forretningsenhet når funksjonsbryteren er PÅ. Hvis du vil angi kolonnen Eiende forretningsenhet, må du gi brukerens sikkerhetsrolle forretningenhetstabellens rettighet Tilføy i med tillatalse på lokalt nivå.

Hvis du vil tillate at brukeren angir denne kolonnen, kan du aktivere denne kolonnen i følgende:

1. Skjema – både brødtekst og overskrift.
2. Vis.
3. Kolonnetilordninger. Hvis du bruker AutoMapEntity, kan du angi kolonnen i kolonnetilordningen.

Obs!

Hvis du har en jobb/prosess for å synkronisere data mellom miljøer, og Eiende forretningsenhet er inkludert som en del av skjemaet, vil jobben mislykkes med et sekundærnøkkel-begrensningsbrudd hvis målmiljøet ikke har samme Eiende forretningsenhetverdi-verdi.

Du kan fjerne kolonnen Eiende forretningsenhet fra kildeskjemaet eller oppdatere kolonnen Eiende forretningsenhet i kilden til en hvilken som helst av forretningsenhetene for målet.

Hvis du har en jobb/prosess for å kopiere data fra et miljø til en ekstern ressurs, for eksempel PowerBI, må du velge eller oppheve valget av kolonnen Eiende forretningsenhet fra kilden. Velg den hvis ressursen kan motta den, ellers ikke.

Eierskap av tabell/oppføring

Dataverse støtter to typer eierskap til oppføring. Organisasjonseid og bruker- eller teameid. Dette er et valg som foretas når tabellen opprettes, og det kan ikke endres. Av sikkerhetsgrunner, for oppføringer som eies av organisasjonen, er de eneste tilgangsnivåvalgene om brukeren kan utføre operasjonen eller ikke. For bruker- og teameide oppføringer er tilgangsnivåvalgene for de fleste rettigheter lagvis Organisasjon, Forretningsenhet, Forretningsenhet og Underordnet forretningsenhet, eller bare brukerens egne oppføringer. Det betyr at jeg har leserettigheter til kontakten, at jeg kan angi brukereide og at brukeren vil bare se sine egne oppføringer.

La oss si at bruker A er tilknyttet Divisjon A, for å nevne et annet eksempel, og vi gir dem lesetilgang til Kontakt på forretningsenhetsnivå. De vil kunne se kontakt nr. 1 og nr 2, men ikke nr 3.

Når du konfigurerer eller redigerer sikkerhetsrollerettigheter, angir du tilgangsnivået for hvert alternativ. Nedenfor er et eksempel på redigeringsprogrammet for sikkerhetsrollerettigheter.

Ovenfor kan du se standard rettighetstyper for hver tabell: opprette, lese, skrive, slette, tilføye, tilføye i, tilordne og dele. Du kan redigere hvert av disse enkeltvis. Den visuelle visningen av hver av dem tilsvarer nøkkelen nedenfor for hvilket tilgangsnivå du har gitt.

I eksemplet ovenfor har vi gitt organisasjonsnivåtilgang til Kontakte, noe som betyr at brukeren i Divisjon A kan se og oppdatere kontakter som eies av alle. En av de vanligste administrative feilene er faktisk å bli frustrert over tillatelser og gi for stor tilgang. En vellaget sikkerhetsmodell begynner svært raskt å se ut som en sveitserost (full av hull).

Registrere eierskap i moderniserte forretningsenheter

I Moderniserte forretningsenheter kan du ha brukere som eiere av oppføringer på tvers av alle forretningsenheter. Alle brukerne trenger er en sikkerhetsrolle (enhver forretningsenhet) som har leserettigheter til oppføringstabellen. Brukerne trenger ikke å ha en sikkerhetsrolle i hver forretningsenhet der oppføringen finnes.

Hvis Oppføringseierskap på tvers av forretningsenheter ble aktivert i produksjonsmiljøet i løpet av forhåndsvisningsperioden, må du utføre følgende for å aktivere eierskapet av denne oppføringen på tvers av forretningsenheter:

1. Installere redigeringsprogram for løsningsorganisasjon
2. Sett organisasjoninnstillingene RecomputeOwnershipAcrossBusinessUnits til Sann. Når denne innstillingen er satt til Sann, er systemet låst og det kan ta opptil fem minutter å gjøre beregne prosessen på nytt for å aktivere funksjonen der brukere nå kan eie oppføringer på tvers av forretningsenheter uten at de trenger å ha atskilte sikkerhetsrolle tildelt fra hver forretningsenhet. Dette gjør at en eier av en oppføring kan tildele oppføringen sin til noen utenfor forretningsenheten som eier oppføringen.
3. Angi AlwaysMoveRecordToOwnerBusinessUnit som usann. Dette får oppføringen til å bli værende i den opprinnelige forretningsenheten når eierskapet til oppføringen endres.

For alle miljøer som ikke er i produksjonsmiljøer, må du bare sette AlwaysMoveRecordToOwnerBusinessUnit til usann for å bruke denne funksjonen.

Obs!

Hvis du deaktiverer funksjonen Oppføringseierskap på tvers av forretningsenheter eller angir innstillingen RecomputeOwnershipAcrossBusinessUnits til usann ved hjelp av orgDBOrgSettings-verktøyet for Microsoft Dynamics CRM, kan du ikke angi eller oppdatere feltet Eiende forretningsenhet, og alle oppføringer der feltet Eiende forretningsenhet er forskjellig fra eierens forretningsenhet, oppdateres til eierens forretningsenhet.

Team (inkludert gruppeteam)

Team er et annet viktig sikkerhetsbyggeblokk. Team eies av en forretningsenhet. Alle forretningsenheter har ett standardteam som opprettes automatisk når forretningsenheten opprettes. Medlemmene i standardteamet administreres av Dataverse og inneholder alltid alle brukere som er tilknyttet forretningsenheten. Du kan ikke legge til eller fjerne medlemmer manuelt fra standardteamet, de justeres dynamisk av systemet etter hvert som nye brukere knyttes til / fjernes fra forretningsenheter. Det finnes to typer team, eiende team og tilgangsteam.

• Eiende team kan eie oppføringer, noe som gir ethvert teammedlem direkte tilgang til den oppføringen. Brukere kan være medlemmer av flere team. Dette gjør at det er en effektiv måte å gi tillatelser til brukere på, på en omfattende måte, uten å måtte detaljstyre tilgang på det enkelte brukernivået.
• Tilgangsteam diskuteres i den neste delen som en del av deling av oppføringer.

Deling av oppføring

Enkeltoppføringer kan deles én om gangen med en annen bruker. Dette er en effektiv måte å behandle unntak på som ikke kommer inn under oppføringseierskapet eller er et medlem av en tilgangsmodell for forretningsenhet. Det bør imidlertid være et unntak fordi det er en mindre utførlig måte å kontrollere tilgang på. Deling er vanskeligere å feilsøke fordi det ikke er en konsekvent implementert tilgangskontroll. Deling kan utføres både på bruker- og teamnivået. Deling med et team er en mer effektiv måte å dele på. En mer avansert deling er med tilgangsteam, som automatisk oppretter et team og deling av oppføringstilgang med teamet, basert på en mal for tilgangsteam (en mal med tillatelser) som brukes. Tilgangsteam kan også brukes uten malene, med bare manuell tilføying eller fjerning av medlemmer. Tilgangsteam er mer effektivt fordi de ikke tillater eierskapsoppføringer av teamet eller sikkerhetsroller som er tilordnet teamet. Brukere får tilgang fordi oppføringen deles med teamet og brukeren er medlem.

Sikkerhet på oppføringsnivå i Dataverse

Kanskje lurer du på hva som avgjør tilgang til en oppføring? Dette høres ut som et enkelt spørsmål, men for alle brukere det er en kombinasjon av alle sikkerhetsrollene deres, forretningsenheten de er tilknyttet, teamene de er medlemmer av, og oppføringene som deles med dem. Det som er viktig å huske er at all tilgang akkumuleres på tvers av alle konseptene i omfanget av et Dataverse-databasemiljø. Disse rettighetene gis bare i én enkelt database, og de blir enkelt sporet i hver Dataverse-database. Dette kurset krever at de har riktig lisens for å få tilgang til Dataverse.

Kolonnenivåsikkerhet i Dataverse

I enkelte forretningsscenarier er det noen ganger ikke tilstrekkelig med kontroll av tilgang på oppføringsnivå. Dataverse har en funksjon for sikkerhet på kolonnenivå for å gi en mer detaljert kontroll av sikkerhet på kolonnenivået. Sikkerhet på kolonnenivå kan aktiveres for alle egendefinerte kolonner og de fleste systemkolonner. De fleste systemkolonner som inneholder personlig identifiserbar informasjon (PII), kan sikres enkeltvis. Metadataene i hver kolonne definerer om dette er et tilgjengelig alternativ for systemkolonne.

Sikkerhet på kolonnenivå aktivert for hver enkelt kolonne. Tilgang blir deretter administrert ved å opprette en kolonnesikkerhetsprofil. Profilen inneholder alle kolonner som har aktivert sikkerhet på kolonnenivå og tilgangen som gis av den bestemte profilen. Hver kolonne kan kontrolleres i profilen for tilgang til oppretting, oppdatering og lesing. Kolonnesikkerhetsprofiler knyttes deretter til en bruker eller team for å gi disse rettighetene til brukerne, til oppføringene de allerede har tilgang til. Det er viktig å merke seg at sikkerhet på kolonnenivå ikke har noe å gjøre med sikkerhet på oppføringsnivå. En bruker må allerede ha tilgang til oppføringen for profilen for kolonnesikkerhet for å gi dem tilgang til kolonnene. Sikkerhet på kolonnenivå bør brukes etter behov og ikke som standard, fordi dette kan føre til en ytelsesreduksjon som er skadelig hvis det bruker for mye.

Administrasjon av sikkerhet på tvers av flere miljøer

Sikkerhetsroller og kolonnesikkerhetsprofiler kan pakkes og flyttes fra ett miljø til det neste ved hjelp av Dataverse-løsninger. Forretningsenheter og team må opprettes og administreres i hvert miljø, sammen med tilordningen av brukere til de nødvendige sikkerhetskomponentene.

Konfigurasjon av miljøsikkerhet for brukere

Når roller, team og forretningsenheter er opprettet i et miljø, er det på tide å tilordne brukerne sikkerhetskonfigurasjonene. Når du oppretter en bruker, knytter du først brukeren til en forretningsenhet. Dette er som standard rotforretningsenheten i organisasjonen. De legges også til i standardteamet for den forretningsenheten.

I tillegg kan du tilordne alle sikkerhetsroller som brukeren trenger. Du kan også legge dem til som medlemmer i team. Husk at team også kan ha sikkerhetsroller, så effektive rettigheter for brukeren er kombinasjonen av direkte tilordnede sikkerhetsroller kombinert med teamene de er medlemmer av. Sikkerhet gir alltid den minst restriktive tillatelsen til hver av deres rettigheter. Nedenfor finner du en god gjennomgang av konfigurasjon av miljøsikkerhet.

Hvis du har brukt sikkerhet på kolonnenivå, må du knytte brukeren eller et team av brukeren til en av profilene for kolonnesikkerhet du opprettet.

Sikkerhet er en kompleks artikkel og oppnås best som en felles innsats mellom programutviklerne og teamet som administrerer brukertillatelsene. Alle viktige endringer bør koordineres godt før du distribuerer endringene til miljøet.

Se også

Konfigurer miljøsikkerhet
Sikkerhetsroller og tilgangsrettigheter