Säkerhetsbegrepp i Microsoft Dataverse
En av nyckelfunktionerna i Dataverse är dess omfattande säkerhetsmodell som kan anpassas till många affärsanvändningsscenarier. Den här säkerhetsmodellen är bara i spel när Dit finns en Dataverse databas i miljön. Som administratör kommer du antagligen inte att bygga hela säkerhetsmodellen själv, men kommer ofta att vara involverad i processen för att hantera användare och se till att de har rätt konfiguration och felsökning av säkerhetsåtkomstrelaterade problem.
Dricks
Se följande videoklipp: Microsoft Dataverse – Säkerhetskoncept som visas i demonstrationer.
Rollbaserad säkerhet
Dataverse använder rollbaserad säkerhet för att gruppera en samling med privilegier. De här säkerhetsrollerna kan associeras direkt till användare, eller till Dataverse-team och affärsenheter. Användare kan sedan associeras med teamet, och därför kan alla användare som är associerade med teamet dra nytta av rollen. Ett nyckelkoncept för Dataverse säkerhet för att förstå är att alla privilegier är ackumulativ som ger störst åtkomst. Om du får läsbehörighet på hög organisationsnivå till alla kontaktposter går det inte att gå tillbaka och dölja en enskild post.
Affärsenheter
Dricks
Kolla in följande video: Modernisera affärsenheter.
Affärsenheter arbetar med säkerhetsroller för att avgöra vilken effektiv säkerhet en användare har. Affärsenheter är ett byggblock för säkerhetsmodellering som hjälper dig att hantera användare och de data de har tillgång till. Affärsenheter definierar en säkerhetsgräns. Varje Dataverse databas har en enda rotaffärsenhet.
Du kan skapa underordnade affärsenheter för att ytterligare segmentera dina användare och data. Varje användare som tilldelats en miljö tillhör en affärsenhet. Även om affärsenheter kan användas för att modellera 1:1 en sann organisationshierarki, desto mer lutar de just nu en bättre säkerhetsgräns för att kunna uppnå behov i säkerhetsmodellen.
Vi ska titta på exemplet för att få mer information: Det finns tre affärsenheter. Woodgrove är huvudaffärsenheten och alltid visas överst, men det är inte ändrat. Vi har skapat två andra underordnade affärsenheter A och B. Användare i dessa affärsenheter har olika åtkomstbehov. När vi associerar en användare med miljön kan vi ange att användaren ska vara i en av dessa tre affärsenheter. Var användaren är associerad avgör vilken affärsenhet som äger de poster som användaren är ägare till. Genom att ha den kopplingen kan vi skräddarsy en säkerhetsroll som gör att användaren kan se poster i affärsenheten.
Hierarkisk dataåtkomststruktur
Kunderna kan använda en organisationsstruktur där data och användare förs in i en trädstruktur.
När vi associerar en användare med den här miljön kan vi ange att användaren ska vara i någon av dessa tre affärsenheter och tilldela en säkerhetsroll från affärsenheten till användaren. Affärsenheten användaren är associerad med avgör vilken affärsenhet som äger posterna när användaren skapar en post. Genom att ha den kopplingen kan vi skräddarsy en säkerhetsroll, vilket gör det möjligt för användaren att se poster i den affärsenheten.
Användare A associeras med avdelning A och tilldelas en säkerhetsroll Y från avdelning A. Detta gör att användaren A kan komma åt #1 och #2 poster. Användare B i avdelning B kan inte komma åt avdelning A:s kontaktposter, men kan komma åt kontakt #3-posten.
Åtkomststruktur för matrisdata (Modernisera affärsenheter)
Kunderna kan använda en organisationsstruktur där data finns i en trädstruktur och användare kan arbeta och komma åt affärsenhetens data oavsett vilken affärsenhet användaren är tilldelad.
När vi associerar en användare med miljön kan vi ange att användaren ska vara i en av dessa tre affärsenheter. För varje affärsenhet som en användare behöver komma åt data tilldelas användaren en säkerhetsroll affärsenheten från den affärsenheten. När användaren skapar en post kan användaren ange att affärsenheten ska äga posten.
Användare A kan associeras med alla affärsenheter, inklusive affärsenheten som är roten. En säkerhetsroll Y från avdelning A tilldelas användare A som ger användaren åtkomst till #1 och #2 poster. En säkerhetsroll Y från avdelning B tilldelas användare A som ger användaren åtkomst till #3 post.
Aktivera matrisdataåtkomststrukturen
Kommentar
Innan du aktiverar den här funktionen måste du publicera alla anpassningar så att alla dina nya opublicerade tabeller för funktionen aktiveras. Om du upptäcker att du har opublicerade tabeller som inte fungerar med den här funktionen efter att du har aktiverat den kan du ställa in RecomputeOwnershipAcrossBusinessUnits med OrgDBOrgSettings verktyget för Microsoft Dynamics CRM. Inställning RecomputeOwnershipAcrossBusinessUnits till sant tillåter att fältet Ägande affärsenhet anges och uppdateras.
- Logga in på Power Platform administrationscentret som administratör (Dynamics 365-administratör eller Microsoft Power Platform administratör).
- Välj Miljöer och välj sedan den miljö som du vill aktivera den här funktionen för.
- Välj Inställningar>Produkt>Funktioner.
- Slå På knappen Registrera ägarskap över affärsenheterna.
När funktionsknappen är aktiverad kan du välja Affärsenhet när du tilldelar en säkerhetsroll till en användare. På så sätt kan du tilldela en användare säkerhetsroll från olika affärsenheter. Användaren behöver också en säkerhetsroll från affärsenheten som användaren har tilldelats med användarinställningar privilegier för att köra modellstyrda program. I den säkerhetsroll grundläggande användarens hur de här användarinställningarna har aktiverats.
Du kan tilldela en användare som postägare i en affärsenhet utan att du behöver tilldela en säkerhetsroll i postens affärsenhet så länge användaren har en säkerhetsroll med läsprivilegium till posttabellen. Se Postägarskap i moderniserade affärsenheter.
Kommentar
Denna funktionsomkopplare är lagrad i inställningen EnableOwnershipAcrossBusinessUnits och kan ställas in med OrgDBOrgSettings verktyget för Microsoft Dynamics CRM.
Koppla en affärsenhet med en Microsoft Entra säkerhetsroll
Med hjälp av en Microsoft Entra säkerhetsgrupp kan du mappa affärsenheten för att rationalisera användaradministrationen och rolltilldelningen.
Skapa en Microsoft Entra säkerhetsgrupp för varje affärsenhet och tilldela respektive affärsenhet säkerhetsroll till varje gruppteam.
För varje affärsenhet, skapa en Microsoft Entra säkerhetsgrupp. Skapa ett Dataverse gruppteam för varje Microsoft Entra säkerhetsgrupp. Tilldela respektive säkerhetsroll från affärsenheten till varje Dataverse gruppteam. Användaren i diagrammet ovan skapas i rot affärsenheten när användaren öppnar miljön. Det går bra att ha användaren och gruppteamen Dataverse i rot affärsenheten. De har bara åtkomst till data i den affärsenhet där säkerhetsroll tilldelas.
Lägg till användare i respektive Microsoft Entra säkerhetsgrupp så att de får åtkomst till affärsenheten. Användarna kan direkt köra programmet och få åtkomst till sina resurser/data.
I matrisdataåtkomsten, där användare kan arbeta och komma åt data från flera affärsenheter, lägg till användarna i Microsoft Entra säkerhetsgrupper som mappas till dessa affärsenheter.
Ägande affärsenhet
Varje post har kolumnen Ägande affärsenhet som avgör vilken affärsenhet som äger posten. Den här kolumnen är som standard användarens affärsenhet när posten skapas och kan inte ändras förutom när funktionsomkopplaren är PÅ.
Obs
När du ändrar vilken affärsenhet som äger en post bör du kontrollera följande för sammanhängande effekter: Använda SDK för .NET organisationsservice för att konfigurera sammanhängande funktioner.
Du kan bestämma om du vill tillåta användaren att ange kolumnen Äga affärsenhet när funktionsknappen är PÅ. För att ställa in kolumnen Äga affärsenhet måste du ge användarens säkerhetsroll tabellen affärsenhet privilegier Tillägg till privilegium med tillstånd på lokal nivå.
Om du vill tillåta användaren att ange det här kolumn kan du aktivera det här kolumn enligt följande:
- Formulär – både brödtext och rubrik.
- Visa.
- Kolumnmappningar. Om du använder AutoMapEntity kan du ange kolumnen i mappningen av kolumnen.
Kommentar
Om du har ett jobb/process för att synkronisera data mellan miljöer och Ägande affärsenhet ingår som en del av schemat, kommer ditt jobb att misslyckas med en Extern NYCKEL begränsningsöverträdelse om målmiljön inte har samma värde för Ägande affärsenhet.
Du kan antingen ta bort kolumn Ägande affärsenhet från källschemat, eller uppdatera kolumnvärdet Ägande affärsenhet för källan till någon av affärsenheterna i målet.
Om du har ett jobb/process för att kopiera data från en miljö till en extern resurs, till exempel PowerBI, måste du välja eller avmarkera kolumn Ägande affärsenhet från källan. Markera den om resursen kan ta emot den på annat sätt.
Tabell/postens ägarskap
Dataverse stöder två typer av ägarskap för post. Organisationsägda och användar- eller teamägda poster Det här är ett val som sker när tabellen skapas och som inte kan ändras. Av säkerhetsskäl är poster som är organisationsägda, de enda alternativen på åtkomstnivån att göra detta, antingen kan användaren göra åtgärden eller inte. För användar- och teamägda poster är de åtkomstnivåalternativ som har de flesta privilegierna nivåindelade organisationer, affärsenheter, affärsenhet och underordnade affärsenheter, eller endast användarens egna poster. Det innebär att läsprivilegiet för kontaktperson kan konfigureras av användaren och användaren kan då endast se sina egna poster.
Anta att du vill skapa ett annat exempel, t. ex är användare A associerad med avdelning A, och vi ger dem läsbehörighet för affärsenhet till kontakt. De kan se Kontakt #1 och #2 men inte Kontakt #3.
När du konfigurerar eller redigerar säkerhetsroll privilegier anger du åtkomstnivån för varje alternativ. Nedan visas ett exempel på redigerare för privilegier för säkerhetsroller.
I ovanstående kan du se standardprivilegier för varje tabell skapa, läsa, skriva, ta bort, lägga till, lägga till i, tilldela och dela. Du kan redigera varje enskild. Den visuella visningen av varje objekt matchar nyckeln nedan om vilken åtkomstnivå du har beviljat.
I exemplet ovan har vi gett åtkomst på organisationsnivå till kontakt vilket innebär att användaren i avdelning A kan se och uppdatera kontakter som ägs av vem som helst. Ett av de vanligaste administrativa misstagen är att bli frustrerad med behörigheter och bara att bevilja åtkomst. En väl utformad säkerhetsmodell börjar på samma sätt som schweiziska ostar (fullt av hål!).
Postägarskap i moderniserade affärsenheter
I Modernare affärsenheter kan du ha användare som ägare av poster i alla affärsenheter. Alla användare behöver en säkerhetsroll (alla affärsenheter) som har läsprivilegier till posttabellen. Användarna behöver inte ha en säkerhetsroll tilldelas i varje affärsenhet där posten finns.
Om postägarskap för flera affärsenheter aktiverades i produktionsmiljön under förhandsgranskningsperioden måste du göra följande för att aktivera postägarskapet i hela affärsenheten:
- Installera redigerare för organisationsinställningar
- Ange organisationsinställningar RecomputeOwnershipAcrossBusinessUnits till sant. När den här inställningen är inställd på sant är systemet låst och det kan ta upp till 5 minuter att göra omberäkningen för att möjliggöra möjligheten där användare nu kan äga poster över affärsenheter utan att behöva ha en separat säkerhetsroll tilldelad från varje affärsenhet. Detta gör att en ägare till en post kan tilldela posten till någon utanför postens affärsenhet.
- Ange AlwaysMoveRecordToOwnerBusinessUnit till falskt. Då blir posten kvar i den ursprungliga ägande affärsenheten när postägarskapet ändras.
För alla miljöer som inte är i produktionsmiljön behöver du bara ange false för AlwaysMoveRecordToOwnerBusinessUnit för att kunna använda den här funktionen.
Kommentar
Om du stänger av antingen inställningen Rekordägande över affärsenheter eller ange inställningen RecomputeOwnershipAcrossBusinessUnits till falsk med OrgDBOrgSettings verktyget för Microsoft Dynamics CRM, kommer du inte att kunna ställa in eller uppdatera fältet Ägande affärsenhet och alla poster där fältet Ägande affärsenhet skiljer sig från ägarens affärsenhet uppdateras till ägarens affärsenhet.
Team (inklusive gruppteam)
Team är ett annat viktigt säkerhetsblock. Team ägs av affärsenheter. Alla affärsenheter har ett standardteam som skapas automatiskt när affärsenheten skapas. Standardteammedlemmarna hanteras av Dataverse och innehåller alltid alla användare som är kopplade till den affärsenheten. Du kan inte lägga till eller ta bort medlemmar manuellt från standardteamet, de justeras dynamiskt av systemet som nya användare associeras/avskiljs från affärsenheter. Det finns två typer av team: ägarteam och åtkomstteam.
- Att äga Teams kan äga poster, vilket ger teammedlemmarna direkt åtkomst till den posten. Användare kan vara medlemmar i flera team. På så sätt kan det vara ett kraftfullt sätt att bevilja behörigheter för användare på ett omfattande sätt utan att mikricke-hantera åtkomst på den enskilda användarnivån.
- Åtkomstteam diskuteras i nästa avsnitt som en del av postdelning.
Dela poster
Enskilda poster kan delas en i taget med en annan användare. Det här är ett kraftfullt sätt att hantera undantag som inte faller inom postens ägarskap eller medlem i en affärsenhets åtkomstmodell. Det bör dock vara ett undantag eftersom det är ett mindre bra sätt att styra åtkomsten. Det går inte att dela tufft för att felsöka eftersom det inte är en konsekvent implementerad åtkomstkontroll. Delning kan göras på både användar- och teamnivå. Delning med ett team är ett effektivare sätt att dela. Ett mer avancerat sätt att dela med är att använda åtkomstteam som tillhandahåller automatisk skapande av ett team och delning av poståtkomst med teamet baserat på en mall för åtkomstteam (behörighetsmall) som används. Åtkomstteam kan också användas utan mallar, med bara manuella tillägg eller borttagning av medlemmar. Det är effektivare med åtkomstteamen eftersom de inte tillåter att äga poster av teamet eller har säkerhetsroller tilldelade teamet. Användarna får åtkomst eftersom posten är gemensam för teamet och användaren är medlem.
Säkerhet på postnivå i Dataverse
Du kanske undrar – vad avgör åtkomst till en post? Det låter som en enkel fråga, men för alla användare är det en kombination av alla deras säkerhetsroller, den affärsenhet de är associerade med, de team de är medlemmar i och de poster som delas med dem. De du behöver komma ihåg är att all åtkomst ackumuleras för alla dessa begrepp i en Dataverse databasmiljö. Dessa berättiganden beviljas endast inom en och samma databas och spåras enskilt i varje Dataverse-databas. Den här kursen kräver att de har en lämplig licens för att få tillgång till Dataverse.
Kolumnsäkerhet i Dataverse
Ibland är kontroll på postnivå av åtkomst inte tillräcklig för vissa affärsscenarier. Dataverse har en säkerhetsfunktion på kolumnnivå som tillåter mer detaljerad kontroll av säkerheten på kolumnnivån. Säkerhet på kolumnnivå kan aktiveras på alla anpassade kolumner och i de flesta systemkolumner. De flesta system kolumn som innehåller personligt identifierbar information (PII) kan skyddas individuellt. Metadata för varje kolumn anger om det är ett tillgängligt alternativ för systemkolumn.
Säkerhet på kolumnnivå har aktiverats för en kolumn i taget. Åtkomsten hanteras sedan genom att skapa en kolumnsäkerhetsprofil. Profilen innehåller alla kolumn med säkerhet på kolumnnivå som är aktiverat och den åtkomst som beviljats av den specifika profilen. Varje kolumn kan styras i profilen för skapa, uppdatera och läsbehörighet. Kolumnsäkerhetsprofiler associeras sedan med en användare eller ett team för att ge användarna behörighet till de poster de redan har tillgång till. Det är viktigt att notera att säkerhet på kolumnnivå inte har något med säkerhet på postnivå att göra. En användare måste redan ha tillgång till posten för kolumnsäkerhetsprofilen för att ge användaren åtkomst till kolumner. Säkerhet på kolumnnivå bör användas vid behov och inte i hög grad eftersom den kan lägga till ett skyddsutrymme som är skadligt om det används.
Hantera säkerhet i flera miljöer
Säkerhetsroller och kolumnsäkerhetsprofiler kan paketeras och flyttas från en miljö till nästa med hjälp av Dataverse-lösningar. Affärsenheter och team måste skapas och hanteras i varje miljö tillsammans med användarnas tilldelningar till de säkerhetskomponenter som behövs.
Konfigurera användares miljösäkerhet
När roller, team och affärsenheter har skapats i en miljö är det dags att tilldela användarna deras säkerhetskonfigurationer. När du skapar en användare associerar du först användaren med en affärsenhet. Som standard är detta huvudaffärsenhet i organisationen. De läggs också till i standardteamet för affärsenheten.
Dessutom ska du tilldela alla säkerhetsroller som behövs för användarna. Du kan också lägga till dem som medlemmar i ett team. Kom ihåg att team också kan ha säkerhetsroller, så användarens faktiska rättigheter är kombinationen av direkt tilldelade säkerhetsroller i kombination med de i alla team de är medlemmar i. Säkerhet är alltid tillsats med den minst begränsade behörigheten för någon av deras berättiganden. Här följer en bra beskrivning av hur du konfigurerar miljösäkerheten.
Om du har använt säkerhet på kolumnnivå måste du associera användaren eller ett team av användaren med en av de kolumnsäkerhetsprofiler du skapade.
Säkerhet är en komplex artikel och utförs bäst som en gemensam insats mellan programtillverkarna och teamet som administrerar användarnas behörigheter. Alla större ändringar bör koordineras på ett bra sätt innan de distribueras i miljön.