Varnostni koncepti v storitvi Microsoft Dataverse

Ena ključnih značilnosti storitve Dataverse je njen zmogljiv varnostni model, ki se lahko prilagodi glede na številne poslovne scenarije. Ta varnostni model je v igri le, ko je v okolju Dataverse baza podatkov. Kot skrbnik verjetno ne boste sami izdelali celotnega varnostnega modela, temveč boste pogosto vključeni v postopek upravljanja uporabnikov in zagotavljanja pravilne konfiguracije ter odpravljanja težav, povezanih z varnostnim dostopom.

Napitnina

Oglejte si ta videoposnetek: Microsoft Dataverse – Varnostni koncepti, prikazani v predstavitvah.

Varnost, ki temelji na vlogah

Storitev Dataverse varnost na podlagi vlog uporablja skupaj z več pravicami. Te varnostne vloge so lahko neposredno povezane z uporabniki ali pa so povezane z ekipami in poslovnimi enotami v storitvi Dataverse. Uporabnike je nato mogoče povezati z ekipo, zato imajo vsi uporabniki, povezani z ekipo, korist od vloge. Glede varnosti v storitvi Dataverse je ključnega pomena, da se zavedate, da so vse dodelitve pravic akumulativne in dostopa ni mogoče onemogočiti. Če ste podelili dostop za branje na splošni ravni organizacije do vseh zapisov stikov, se ne morete vrniti nazaj in skriti kakšnega zapisa.

Poslovne enote

Nasvet

Oglejte si naslednji video: Posodobite poslovne enote.

Poslovne enote sodelujejo z varnostnimi vlogami, da ugotovijo dejansko varnost uporabnika. Poslovne enote so gradnik modeliranja varnosti, ki pomaga pri upravljanju uporabnikov in podatkov, do katerih lahko dostopajo. Poslovne enote določijo varnostno mejo. Vsaka zbirka podatkov storitve Dataverse ima eno samo korensko poslovno enoto.

Ustvarite lahko podrejene poslovne enote, s katerimi boste lažje segmentirali svoje uporabnike in podatke. Vsak uporabnik, dodeljen okolju, pripada poslovni enoti. Medtem ko bi lahko poslovne enote uporabili za modeliranje resnične hierarhije organizacije v razmerju 1 : 1, se te bolj pogosto nagibajo k opredeljenim varnostnim mejam, s katerimi lažje zadovoljimo potrebe varnostnega modela.

Za boljše razumevanje si bomo ogledali naslednji primer. Imamo tri poslovne enote. Woodgrove je korenska poslovna enota in bo vedno na vrhu, česar ni mogoče spremeniti. Ustvarili smo dve drugi podrejeni poslovni enoti A in B. Uporabniki v teh poslovnih enotah imajo različne potrebe po dostopu. Ko povežemo uporabnika s tem okoljem, lahko uporabnika nastavimo v eni od teh treh poslovnih enot. Kjer je uporabnik povezan, določa, katera poslovna enota ima v lasti zapise, katerih lastnik je ta uporabnik. S to povezavo lahko prilagodimo varnostno vlogo, da uporabniku omogočimo ogled vseh zapisov v tej poslovni enoti.

Hierarhična struktura dostopa do podatkov

Stranke lahko uporabljajo organizacijsko strukturo, kjer so podatki in uporabniki razdeljeni v drevesno hierarhijo.

Ko uporabnika povežemo s tem okoljem, ga lahko nastavimo v eno od teh treh poslovnih enot in mu dodelimo varnostno vlogo iz poslovne enote. Poslovna enota, s katero je uporabnik povezan, določa, katera poslovna enota je lastnica zapisov, ko uporabnik ustvari zapis. S to povezavo nam omogoča, da prilagodimo varnostna vloga, ki uporabniku omogoča ogled zapisov v tej poslovni enoti.

Uporabnik A je povezan z oddelkom A in mu je dodeljena varnostna vloga Y iz oddelka A. To uporabniku A omogoča dostop do zapisov Stik #1 in Stik #2. Medtem ko uporabnik B v oddelku B ne more dostopati do zapisov stikov oddelka A, lahko pa dostopa do zapisa kontakta #3.

Struktura dostopa do podatkov matrike (Posodobljene poslovne enote)

Stranke lahko uporabljajo organizacijsko strukturo, kjer so podatki razdeljeni v drevesno hierarhijo, uporabniki pa lahko delajo in dostopajo do podatkov katere koli poslovne enote, ne glede na to, kateri poslovni enoti je uporabnik dodeljen.

Ko povežemo uporabnika s tem okoljem, lahko uporabnika nastavimo v eni od teh treh poslovnih enot. Za vsako poslovno enoto, ki jo uporabnik potrebuje za dostop do podatkov, je uporabniku dodeljena varnostna vloga iz te poslovne enote. Ko uporabnik ustvari zapis, lahko poslovno enoto določi kot lastnico zapisa.

Uporabnik A je lahko povezan s katero koli poslovno enoto, vključno s korensko poslovno enoto. Uporabniku A je dodeljena varnostna vloga Y iz oddelka A, ki uporabniku omogoča dostop do zapisov Stik #1 in Stik #2. Uporabniku A je dodeljena varnostna vloga Y iz oddelka B, ki uporabniku omogoča dostop do zapisa Stik #3.

Omogočanje strukture dostopa do podatkov matrike

opomba,

Preden omogočite to funkcijo, morate objaviti vse svoje prilagoditve, da omogočite vse nove neobjavljene tabele za to funkcijo. Če ugotovite, da imate neobjavljene tabele, ki ne delujejo s to funkcijo po tem, ko ste jo vklopili, lahko nastavite nastavitev RecomputeOwnershipAcrossBusinessUnits z orodjem OrgDBOrgSettings za Microsoft Dynamics CRM. Nastavitev RecomputeOwnershipAcrossBusinessUnits na true omogoča nastavitev in posodobitev polja Owning Business Unit .

1. Prijavite se v Power Platform skrbniško središče kot skrbnik (skrbnik Dynamics 365 ali Microsoft Power Platform admin).
2. Izberite Okolja, nato izberite okolje, za katerega želite omogočiti to funkcijo.
3. Izberite Nastavitve>Izdelek>Funkcije.
4. Vklopite stikalo Lastništva zapisov v poslovni enoti.

Ko je stikalo za te funkcije vklopljeno, lahko izberete »Poslovna enota«, ko uporabniku dodelite varnostno vlogo. To omogoča, da uporabniku dodelite varnostno vlogo iz različnih poslovnih enot. Uporabnik prav tako zahteva varnostno vlogo od poslovne enote, ki ji je uporabnik dodeljen s pravicami uporabniških nastavitev za izvajanje aplikacij, ki temeljijo na modelu. Oglejte si varnostno vlogo Osnovni uporabnik, če želite izvedeti, kako so omogočene te pravice uporabniških nastavitev.

Uporabnika lahko dodelite kot lastnika zapisa v kateri koli poslovni enoti, ne da bi morali dodeliti varnostno vlogo v poslovni enoti, ki je lastnik zapisa, če ima uporabnik varnostno vlogo, ki ima pravico za branje tabele z zapisi. Glejte Lastništvo zapisov v posodobljenih poslovnih enotah.

opomba,

Stikalo te funkcije je shranjeno v nastavitvi EnableOwnershipAcrossBusinessUnits in ga je mogoče nastaviti tudi z orodjem OrgDBOrgSettings za Microsoft Dynamics CRM.

Povežite poslovno enoto z Microsoft Entra varnostno skupino

Uporabite lahko Microsoft Entra varnostno skupino za preslikavo vaše poslovne enote za racionalizacijo uporabniškega upravljanja in dodelitve vlog.

Ustvarite Microsoft Entra varnostno skupino za vsako poslovno enoto in dodelite ustrezno poslovno enoto varnostna vloga vsaki ekipi skupine.

Za vsako poslovno enoto ustvarite Microsoft Entra varnostno skupino. Ustvarite Dataverse ekipo skupine za vsako Microsoft Entra varnostno skupino. Dodelite ustrezno varnostno vlogo iz poslovne enote vsaki ekipi skupine Dataverse. Uporabnik v zgornjem diagramu bo ustvarjen v korenski poslovni enoti, ko bo uporabnik dostopal do okolja. V redu je, da so uporabniki in ekipe skupin Dataverse v korenski poslovni enoti. Dostop imajo samo do podatkov v poslovni enoti, kjer je dodeljena varnostna vloga.

Dodajte uporabnike v ustrezno Microsoft Entra varnostno skupino, da jim omogočite dostop do poslovne enote. Uporabniki lahko takoj zaženejo aplikacijo in dostopajo do njenih virov/podatkov.

Pri matričnem dostopu do podatkov, kjer lahko uporabniki delajo in dostopajo do podatkov iz več poslovnih enot, dodajte uporabnike v Microsoft Entra varnostne skupine, ki so preslikane v tiste poslovne enote.

Lastniška poslovna enota

Vsak zapis ima stolpec Lastništvo poslovne enote , ki določa, katera poslovna enota je lastnik zapisa. Ta stolpec je privzeto nastavljen na uporabnikovo poslovno enoto, ko je zapis ustvarjen, in ga ni mogoče spremeniti, razen če je stikalo za funkcije vklopljeno.

opomba,

Ko spremenite, katera poslovna enota ima v lasti zapis, preverite naslednje za kaskadne učinke: Uporaba SDK za .NET za konfiguracijo kaskadnega vedenja.

Določite lahko, ali boste uporabniku dovolili, da nastavi stolpec »Lastniška poslovna enota«, ko je stikalo za funkcije vklopljeno. Če želite nastaviti stolpec »Lastniška poslovna enota«, morate uporabniku dodeliti varnostno vlogo v pravici tabele poslovne enote Priloži k z dovoljenjem na lokalni ravni.

Če želite, da vaš uporabnik nastavi ta stolpec, lahko ta stolpec omogočite na naslednji način:

1. Oblika – tako telo kot glava.
2. Ogled.
3. Preslikave stolpca. Če uporabljate AutoMapEntity, lahko podate stolpec v svojem stolpcu preslikava.

opomba,

Če imate posel/proces za sinhronizacijo podatkov med okolji in je Lastniška poslovna enota vključena kot del sheme, vaš posel ne bo uspel s kršitvijo omejitve Tuji ključ, če ciljno okolje nima enake vrednosti Lastniške poslovne enote.

Lahko odstranite stolpec Lastniška poslovna enota iz izvorne sheme ali posodobite vrednost stolpca Lastniška poslovna enota vira na katero koli poslovno enoto cilja.

Če imate posel/proces za kopiranje podatkov iz okolja v zunanji vir, na primer storitev PowerBI, boste morali iz svojega vira izbrati ali preklicati izbiro stolpca Lastniška poslovna enota. Izberite ga, če ga vaš vir lahko prejme, sicer prekličite izbiro.

Lastništvo tabel/zapisov

Storitev Dataverse podpira dve vrsti lastništva zapisov. Zapisi v lasti organizacije ter zapisi v lasti uporabnika ali ekipe. Do te izbire pride v času ustvarjanja tabele in je ni mogoče spremeniti. Iz varnostnih razlogov je za zapise, ki so v lasti organizacije, edina možnost izbire na ravni dostopa ta, ali lahko uporabnik izvede operacijo ali ne. Za zapise, ki so v lasti uporabnikov in ekip, so možnosti na ravni dostopa za večino dovoljenj sestavljene iz plasti Organizacija, Poslovna enota, Poslovna enota in Podrejena poslovna enota ali samo lastnih zapisov uporabnika. To pomeni, da za pravico do branja za stik lahko nastavimo, da je v lasti uporabnika, in bo uporabnik videl le lastne zapise.

Če dodamo še en primer, recimo, da je uporabnik A povezan z oddelkom A in mu dodelimo dostop za branje za stik na ravni poslovne enote. Videli bi lahko Stik 1 in 2, ne pa tudi Stik 3.

Ko končate s konfiguracijo ali urejanjem dovoljenj za varnostne vloge, nastavite raven dostopa za vsako možnost. V nadaljevanju je primer urejevalnika pravic varnostne vloge.

Zgoraj lahko vidite standardne vrste pravic za vsako tabelo Ustvari, Preberi, Piši, Izbriši, Priloži, Dodaj, Dodeli in Daj v skupno rabo. Vsako izmed njih lahko uredite posebej. Vizualni prikaz vsake možnosti se bo ujemal s spodnjim ključem glede na stopnjo dostopa, ki ste jo odobrili.

V zgornjem primeru smo stiku dodelili dostop na ravni organizacije, kar pomeni, da bo uporabnik v oddelku A lahko videl in posodabljal stike, ki jih ima v lasti kdor koli. Dejansko je ena najpogostejših skrbniških napak, da nas vrste dovoljenj zmedejo in dodelimo previsoko raven dostopa. Zelo hitro lahko videz dobro izdelanega varnostnega modela postane podoben švicarskemu siru (polno lukenj!).

Lastništvo zapisov v posodobljenih poslovnih enotah

V posodobljenih poslovnih enotah lahko uporabniki postanejo lastniki zapisov v kateri koli poslovni enoti. Vse, kar uporabniki potrebujejo, je varnostna vloga (katera koli poslovna enota), ki ima pravico do branja tabele z zapisi. Uporabnikom ni treba imeti dodeljene varnostne vloge v vsaki poslovni enoti, kjer je zapis.

Če je bilo Lastništva zapisov v poslovni enoti omogočeno v vašem produkcijskem okolju med obdobjem predogleda, morate izvesti naslednje, da omogočite to lastništvo zapisov v poslovni enoti:

1. Namestitev urejevalnika nastavitev organizacije
2. Nastavite nastavitve organizacije RecomputeOwnershipAcrossBusinessUnits na »true«. Ko je ta nastavitev nastavljena na »true«, je sistem zaklenjen in lahko traja do 5 minut, da izvede ponovni izračun, da omogoči zmožnost, pri kateri si lahko uporabniki zdaj lastijo zapise v poslovnih enotah, ne da bi morali imeti ločeno varnostna vloga dodeljeno iz vsake poslovne enote. To omogoča lastniku zapisa, da svoj zapis dodeli nekomu zunaj poslovne enote, ki je lastnik zapisa.
3. Nastavite AlwaysMoveRecordToOwnerBusinessUnit na »false«. Zaradi tega zapis ostane v prvotni lastniški poslovni enoti, ko se spremeni lastništvo zapisa.

Za vsa neprodukcijska okolja morate za uporabo te zmožnosti le nastaviti AlwaysMoveRecordToOwnerBusinessUnit na »false«.

opomba,

Če izklopite bodisi funkcijo Evidentiranje lastništva med poslovnimi enotami ali nastavite RecomputeOwnershipAcrossBusinessUnits nastavitev na false z uporabo OrgDBOrgSettings orodje za Microsoft Dynamics CRM, ne boste mogli nastaviti ali posodobiti Lastniške poslovne enote in vsi zapisi, kjer je polje Lastništvo poslovne enote različno od poslovne enote lastnika, bodo posodobljeni na poslovno enoto lastnika.

Ekipe (vključno z ekipami skupine)

Ekipe so prav tako pomemben gradnik varnosti. Ekipe so v lasti poslovne enote. Vsaka poslovna enota ima eno privzeto ekipo, ki se samodejno ustvari, ko ustvarite poslovno enoto. Privzete člane ekipe se upravlja v storitvi Dataverse in vedno zajemajo vse uporabnike, povezane s to poslovno enoto. Članov ne morete ročno dodati ali odstraniti iz privzete ekipe – sistem jih dinamično prilagodi glede na to, ali nove uporabnike povežete s poslovnimi enotami oz. to povezavo prekinete. Na voljo sta dve vrsti ekip: lastniške ekipe in ekipe za dostop.

• Lastniške ekipe so lahko lastniki zapisov, ki vsakemu članu ekipe omogočajo neposreden dostop do tega zapisa. Uporabniki so lahko člani več ekip. S tem to postane močno orodje za širše dodeljevanje dovoljenj uporabnikom, pri čemer vam ni treba izvesti mikroupravljanja na ravni posameznih uporabnikov.
• Ekipe za dostop so obravnavane v naslednjem razdelku kot del skupne rabe zapisov.

Skupna raba zapisov

Posamezne zapise je mogoče deliti enega za drugim z drugim uporabnikom. To je zmogljiv način obravnavanja izjem, ki ne spadajo v lastništvo zapisa ali so član modela dostopa poslovne enote. Vendar bi morala biti izjema, ker je manj zmogljiv način nadzora dostopa. Skupno rabo je težje odpraviti, ker ni dosledno implementiran nadzor dostopa. Skupno rabo lahko izvedete tako na ravni uporabnikov kot ekipe. Skupna raba z ekipo je učinkovitejši način skupne rabe. Naprednejši koncept deljenja je z Access Teams, ki omogoča samodejno ustvarjanje ekipe in deljenje dostopa do zapisa z ekipo temelji na Access Team Template (predlogi dovoljenj), ki se uporablja. Ekipe za dostop je mogoče uporabljati tudi brez predlog, le z ročnim dodajanjem ali odstranjevanjem članov. Ekipe za dostop so učinkovitejše, ker ne dovoljujejo, da so zapisi v lasti ekipe ali so ekipi dodeljene varnostne vloge. Uporabniki prejmejo dostop, ker se zapis deli z ekipo, uporabnik pa je član te ekipe.

Varnost na ravni zapisa v storitvi Dataverse

Morda se sprašujete – kaj opredeljuje dostop do zapisa? To se sliši kot preprosto vprašanje, toda za katerega koli uporabnika je to kombinacija vseh njegovih varnostnih vlog, poslovne enote, s katero je povezan, skupin, katerih člani so, in zapisov, ki so z njimi v skupni rabi. Ključno je, da si zapomnite, da je dostop akumulativen pri vseh konceptih v obsegu okolja za zbirko podatkov storitve Dataverse. Te upravičenosti so dodeljene samo znotraj ene zbirke podatkov in se jim ločeno sledi v vsaki zbirki podatkov Dataverse. Za vse to morajo imeti ustrezno licenco za dostop do Dataverse.

Varnost na ravni stolpca v storitvi Dataverse

Včasih nadzor dostopa na ravni zapisa ni primeren za nekatere poslovne scenarije. Storitev Dataverse ima funkcijo za varnost na ravni stolpca, ki omogoča natančnejši nadzor varnosti na ravni stolpca. Varnost na ravni stolpca je mogoče omogočiti pri vseh stolpcih po meri in pri večini sistemskih stolpcev. Večina sistemskih stolpcev s podatki, ki omogočajo identifikacijo posameznika (PII), je mogoče zavarovati posamezno. Metapodatki vsakega stolpca definirajo, če je to na voljo za sistemski stolpec.

Varnost na ravni stolpca je omogočena za vsak stolpec posebej. Dostop nato upravljate tako, da ustvarite varnostni profil stolpca. Profil vsebuje vse stolpce, ki imajo omogočeno varnost na ravni stolpca in jim je dostop dodelil točno ta profil. Vsak stolpec lahko upravljate znotraj profila, in sicer za dostop za ustvarjanje, posodabljanje in branje. Varnostni profili stolpca so nato povezani z uporabnikom ali ekipami, da se uporabnikom dodelijo pravice za zapise, do katerih imajo že dostop. Pomembno je omeniti, da varnost na ravni stolpca nima nič skupnega z varnostjo na ravni zapisa. Uporabnik mora že imeti dostop do zapisa za varnostni profil stolpca, da se mu lahko omogoči kakršen koli dostop do stolpcev. Varnost na ravni stolpca je treba uporabljati le po potrebi, saj lahko povzroči dodatne stroške, ki bodo ob pretirani uporabi škodljivi.

Upravljanje varnosti v več okoljih

Varnostne vloge in varnostne profile stolpca lahko vključite v paket in premaknete iz enega okolja v drugega z rešitvami Dataverse. Poslovne enote in skupine je treba ustvariti in upravljati v vsakem okolju, hkrati pa tudi dodeliti uporabnike potrebnim varnostnim komponentam.

Konfiguriranje varnosti okolja za uporabnike

Ko se v okolju ustvarijo vloge, skupine in poslovne enote, lahko uporabnikom dodelite tudi njihove varnostne konfiguracije. Ko ustvarite uporabnika, ga najprej povežite s poslovno enoto. Privzeto je to korenska poslovna enota v organizaciji. Dodani so tudi v privzeto ekipo te poslovne enote.

Poleg tega bi v tem primeru dodelili morebitne varnostne vloge, ki jih uporabnik potrebuje. Uporabnika bi dodali med člane ustreznih ekip. Ne pozabite, da imajo lahko tudi ekipe varnostne vloge, zato so dejanske pravice uporabnika kombinacija neposredno dodeljenih varnostnih vlog v kombinaciji s pravicami tiste ekipe, katere člani so. Varnost je vedno dodatek, ki ponuja najmanj omejujoče dovoljenje za katero koli od upravičenosti uporabnika. V nadaljevanju je predstavljeno konfiguriranje varnosti okolja.

Če ste uporabili varnost na ravni stolpca, boste morali uporabnika ali ekipo uporabnika povezati z enim od varnostnih profilov stolpca, ki ste jih ustvarili.

Varnost je zapleten člen in se najbolje doseže s skupnim prizadevanjem med izdelovalci aplikacij in ekipo, ki upravlja dovoljenja uporabnikov. Morebitne večje spremembe je treba uskladiti veliko časa pred uvedbo sprememb v okolje.

Glejte tudi

Konfiguriranje varnosti okolja
Varnostne vloge in pravice