Conceptes de seguretat al Microsoft Dataverse

Una de les característiques clau del Dataverse és el seu ric model de seguretat que es pot adaptar a molts escenaris d'ús de negoci. Aquest model de seguretat només està actiu quan hi ha una base de dades del Dataverse en l'entorn. Com a administrador, és probable que no creeu tot el model de seguretat, sinó que sovint estareu implicat en el procés d'administrar els usuaris i assegurar-vos que tenen la configuració correcta i solucionar els problemes relacionats amb l'accés de seguretat.

Propina

Mireu el següent vídeo: Microsoft Dataverse – Conceptes de seguretat que es mostren a les demostracions.

Seguretat basada en funcions

El Dataverse utilitza la seguretat basada en funcions per agrupar una col·lecció de privilegis. Aquestes funcions de seguretat es poden associar directament amb els usuaris o poden associar-se amb els equips i les unitats de negoci del Dataverse. Aleshores, els usuaris poden associar-se amb l'equip i, per tant, tots els usuaris associats amb l'equip es beneficiaran de la funció. Un concepte clau de la seguretat del Dataverse per entendre és que totes les concessions de privilegis són acumulatives amb la quantitat més gran d'accés vigent. Si concedíssiu un ampli nivell de lectura de l'organització a tots els registres de contacte, no podríeu tornar enrere i amagar un sol registre.

Unitats de negoci

Propina

Mireu el següent vídeo: Modernitzar les unitats de negoci.

Les unitats de negoci funcionen amb funcions de seguretat per determinar la seguretat eficaç que té un usuari. Les unitats de negoci són un fonament de modelatge de seguretat que ajuda en la gestió d'usuaris i de les dades a les que poden accedir. Les unitats de negoci defineixen un límit de seguretat. Cada base de dades del Dataverse té una unitat de negoci arrel única.

Podeu crear unitats de negoci secundàries com a ajuda per segmentar els usuaris i les dades. Tots els usuaris assignats a un entorn pertanyen a una unitat de negoci. Com que les unitats de negoci es podien utilitzar per modelar 1:1 una autèntica jerarquia d'organització, sovint s'inclinen més cap als límits de seguretat definits per ajudar a aconseguir les necessitats del model de seguretat.

Per comprendre millor, vegem el següent exemple. Tenim tres unitats de negoci. Woodgrove és la unitat de negoci arrel i sempre estarà a la part superior, que no es pot canviar. S'han creat dues unitats de negoci secundàries, A i B. Els usuaris d'aquestes unitats de negoci tenen necessitats d'accés molt diferents. Quan associem un usuari amb aquest entorn, podem definir que l'usuari estigui en una d'aquestes tres unitats de negoci. El lloc on l'usuari està associat determinarà quina unitat de negoci posseeix els registres dels quals l'usuari és el propietari. Amb aquesta associació, podem adaptar una funció de seguretat per permetre a l'usuari veure tots els registres d'aquesta unitat de negoci.

Estructura d'accés a les dades jeràrquiques

Els clients poden utilitzar una estructura d'organització en què les dades i els usuaris estan compartimentats en una jerarquia d'arbre.

Quan associem un usuari amb aquest entorn, podem definir que l'usuari estigui en una d'aquestes tres unitats de negoci i assignar una funció de seguretat de la unitat de negoci a l'usuari. La unitat de negoci amb la qual està associat l'usuari determina la unitat de negoci que és propietària dels registres quan l'usuari crea un registre. Disposar d'aquesta associació ens permet adaptar una funció de seguretat que permeti a l'usuari veure els registres d'aquesta unitat de negoci.

L'usuari A està associat amb la divisió A i té assignada un funció de seguretat Y de la divisió A. Això permet a l'usuari A accedir als registres del Contacte núm. 1 i el Contacte núm. 2. Tot i que l'usuari B de la divisió B no pot accedir als registres de contacte de la divisió A, sí que pot accedir al registre del Contacte núm. 3.

Estructura d'accés a les dades de matriu (Unitats de negoci modernitzades)

Els clients poden utilitzar una estructura d'organització en què les dades estan compartimentades en una jerarquia d'arbre, i els usuaris poden treballar i accedir a les dades de qualsevol unitat de negoci independentment de la unitat de negoci a la qual s'assigni l'usuari.

Quan associem un usuari amb aquest entorn, podem definir que l'usuari estigui en una d'aquestes tres unitats de negoci. Per a cada unitat de negoci que un usuari necessita per accedir a les dades, s'assigna a l'usuari una funció de seguretat d'aquesta unitat de negoci. Quan l'usuari crea un registre, l'usuari pot definir la unitat de negoci propietària del registre.

L'usuari A es pot associar amb qualsevol de les unitats de negoci, inclosa la unitat de negoci arrel. Un funció de seguretat Y de la divisió A s'assigna a l'usuari A, que proporciona a l'usuari accés als registres del contacte núm. 1 i el contacte núm. 2. Un funció de seguretat Y de la divisió B s'assigna a l'usuari A, que proporciona a l'usuari accés al registre del contacte núm. 3.

Habilitar l'estructura d'accés a les dades de matriu

Nota

Abans d'habilitar aquesta característica, heu de publicar totes les personalitzacions per habilitar totes les taules no publicades noves de la característica. Si trobeu que teniu taules que no s'han publicat i que no funcionen amb aquesta característica després d'haver-la activat, podeu configurar l'opció RecomputeOwnershipAcrossBusinessUnits amb l'eina OrgDBOrgSettings per al Microsoft Dynamics CRM. Establir RecomputeOwnershipAcrossBusinessUnits a true permet definir i actualitzar el camp Unitat de negoci propietària.

1. Inicieu la sessió al centre d'administració del Power Platform com a administrador (administrador del Dynamics 365, administrador global o administrador del Microsoft Power Platform).
2. Seleccioneu Entorns i, a continuació, trieu l'entorn per al qual voleu habilitar aquesta característica.
3. Seleccioneu Configuració>Producte>Característiques.
4. Activeu el commutador Propietat del registre entre unitats de negoci.

Quan aquest commutador de característica està activat, podeu seleccionar Unitat de negoci quan assigneu una funció de seguretat a un usuari. Això us permet assignar la funció de seguretat des de diferents unitats de negoci a un usuari. L'usuari també necessita una funció de seguretat de la unitat de negoci a la qual s'assigna l'usuari amb els privilegis de configuració de l'usuari per executar aplicacions basades en model. Podeu fer referència a la funció de seguretat Usuari bàsic per trobar com estan habilitats aquests privilegis de configuració d'usuari.

Podeu assignar un usuari com a propietari de registre en qualsevol unitat de negoci sense necessitat d'assignar un funció de seguretat a la unitat de negoci propietària del registre sempre que l'usuari tingui una funció de seguretat amb el privilegi de lectura a la taula de registres. Vegeu Propietat dels registres en unitats de negoci modernitzades.

Nota

Aquest commutador de característica s'emmagatzema a la configuració EnableOwnershipAcrossBusinessUnits i es pot configurar amb l'eina OrgDBOrgSettings per al Microsoft Dynamics CRM.

Associar una unitat de negoci a un Microsoft Entra grup de seguretat

Podeu utilitzar un Microsoft Entra grup de seguretat per assignar la unitat de negoci per racionalitzar l'administració d'usuaris i l'assignació de funcions.

Creeu un grup de Microsoft Entra seguretat per a cada unitat de negoci i assigneu la unitat de negoci funció de seguretat respectiva a cada equip del grup.

Per a cada unitat de negoci, creeu un Microsoft Entra grup de seguretat. Creeu un equip Dataverse de grup per a cada Microsoft Entra grup de seguretat. Assigneu la funció de seguretat respectiva de la unitat de negoci a cada equip de grup del Dataverse. L'usuari del diagrama anterior es crearà a la unitat de negoci arrel quan l'usuari accedeixi a l'entorn. No cal que l'usuari i els equips de grup del Dataverse estiguin a la unitat de negoci arrel. Només tenen accés a les dades de la unitat de negoci on està assignada la funció de seguretat.

Afegiu usuaris al grup de seguretat corresponent Microsoft Entra per concedir-los accés a la unitat de negoci. Els usuaris poden executar immediatament l'aplicació i accedir als seus recursos/dades.

A l'accés a dades de la matriu, on els usuaris poden treballar i accedir a dades de diverses unitats de negoci, afegiu els usuaris als grups de seguretat que s'han Microsoft Entra assignat a aquestes unitats de negoci.

Unitat de negoci propietària

Cada registre té una columna Unitat de negoci propietària que determina quina unitat de negoci és propietària del registre. Aquesta columna per defecte és la unitat de negoci de l'usuari quan es crea el registre i no es pot canviar llevat que el commutador de característica estigui activat.

Nota

Quan canvieu quina unitat de negoci és propietària d'un registre, assegureu-vos de comprovar el següent per als efectes en cascada:Ús de l'SDK per a .NET per configurar el comportament en cascada.

Podeu administrar si voleu permetre a l'usuari definir la columna Unitat de negoci propietària quan el commutador de característica està activat. Per definir la columna Unitat de negoci propietària, heu de concedir a la funció de seguretat de l'usuari el privilegi Annexa a de la taula de la Unitat de negoci amb el permís de nivell local.

Per permetre a l'usuari definir aquesta columna, podeu habilitar la columna en el següent:

1. Formulari: el cos i la capçalera.
2. Mostra.
3. Assignacions de columnes. Si utilitzeu AutoMapEntity, podeu especificar la columna a l'assignació de columnes.

Nota

Si teniu un treball o procés per sincronitzar dades entre entorns i la Unitat de negoci propietària s'inclou com a part de l'esquema, la vostra feina fallarà amb una violació de la restricció de Clau externa si l'entorn de destinació no té el mateix valor d'Unitat de negoci propietària.

Podeu suprimir la columna Unitat de negoci propietària de l'esquema d'origen o actualitzar el valor de la columna Unitat de negoci propietària del valor de l'origen a qualsevol de les unitats de negoci de la destinació.

Si teniu una feina o un procés per copiar dades d'un entorn a un recurs extern com, per exemple, el PowerBI, haureu de seleccionar o deseleccionar la columna Unitat de negoci propietària del vostre origen. Seleccioneu-ho si el recurs pot rebre-la; en cas contrari, deseleccioneu-ho.

Propietat de la taula o el registre

El Dataverse admet dos tipus de propietat del registre. Propietat de l'organització i propietat de l'usuari o l'equip. Aquesta és una opció que es defineix en el moment de crear la taula i no es pot canviar. Per motius de seguretat, per als registres que són propietat de l'organització l'única opció de nivell d'accés és que l'usuari pot o no fer l'operació. Per als registres propietat d'usuaris i equips, les opcions de nivell d'accés de la majoria de privilegis són: Organització multinivell, Unitat de negoci, Unitat de negoci i unitat de negoci secundària, o només els registres propis de l'usuari. Això vol dir que per al privilegi de lectura del contacte, podria definir l'usuari propietari i l'usuari només veurà els seus registres.

Per donar un altre exemple: suposem que l'usuari A està associat amb la divisió A i el donem accés de lectura al nivell d'unitat de negoci al contacte. Podran veure el Contacte #1 i #2, però no el Contacte #3.

Quan configureu o editeu els privilegis de la funció de seguretat, esteu definint el nivell d'accés de cada opció. El següent és un exemple de l'editor de privilegis de funció de seguretat.

A l'anterior podeu veure els tipus de privilegis estàndard de cada taula: Creació, Lectura, Escriptura, Supressió, Annexa, Annexa a, Assigna i Comparteix. Podeu editar cada un d'aquests tipus individualment. La visualització visual de cadascun coincidirà amb la clau següent pel que fa al nivell d'accés que heu atorgat.

A l'exemple anterior, hem donat l'accés de nivell d'organització al contacte el que significa que l'usuari de la divisió A podria veure i actualitzar els contactes que són propietat de qualsevol persona. De fet, un dels errors administratius més habituals és estar frustrat amb els permisos i només concedir accés. Molt ràpidament, un model de seguretat ben dissenyat comença a tenir l'aspecte de formatge suís (ple de forats).

Propietat dels registres en unitats de negoci modernitzades

A les unitats de negoci modernitzades, podeu tenir usuaris propietaris de registres a totes les unitats de negoci. Tots els usuaris necessiten una funció de seguretat (qualsevol unitat de negoci) que tingui el privilegi de lectura a la taula de registres. Els usuaris no han de tenir assignada una funció de seguretat a cada unitat de negoci on resideix el registre.

Si Propietat del registre en diverses unitats de negoci s'ha habilitat a l'entorn de producció durant el període de versió preliminar, heu de dur a terme el següent per habilitar aquesta propietat del registre en tota la unitat de negoci:

1. Instal·lar l'editor Configuració de l'organització
2. Definiu la configuració de l'organització RecomputeOwnershipAcrossBusinessUnits en cert. Quan aquesta configuració està definida com a certa, el sistema està bloquejat i pot trigar fins a 5 minuts a fer el càlcul per habilitar la capacitat on els usuaris ara poden posseir registres a través d'unitats de negoci sense necessitat de tenir funció de seguretat separats assignats de cada unitat de negoci. Això permet que el propietari d'un registre assigni el seu registre a algú de fora de la unitat de negoci propietària del registre.
3. Definiu AlwaysMoveRecordToOwnerBusinessUnit com a fals. D'aquesta manera, el registre es queda a la unitat de negoci propietària original quan es canvia la propietat del registre.

Per a tots els entorns que no són de producció, només heu d'establir AlwaysMoveRecordToOwnerBusinessUnit en fals per utilitzar aquesta capacitat.

Nota

Si desactiveu la característica Propietat del registre entre unitats de negoci o definiu la configuració RecomputeOwnerAcrossBusinessUnits com a falsa mitjançant l'eina OrgDBOrgSettings per al CRM , no podreu definir ni actualitzar el camp Unitat de negoci propietària i tots els registres en què el Microsoft Dynamics camp Unitat de negoci propietària sigui diferent de la unitat de negoci del propietari s'actualitzaran a la unitat de negoci del propietari.

Equips (incloent-hi els equips del grup)

Els equips són altres fonaments de seguretat importants. Els equips són propietat d'una unitat de negoci. Cada unitat de negoci té un equip per defecte que es crea automàticament quan es crea la unitat de negoci. Els membres de l'equip per defecte estan gestionats per el Dataverse i sempre contenen tots els usuaris associats amb aquesta unitat de negoci. No podeu afegir ni suprimir manualment els membres de l'equip per defecte, els quals s'ajusten dinàmicament pel sistema, ja que els usuaris nous estan associats/desassociats amb unitats de negoci. Hi ha dos tipus d'equips, equips propietaris i equips d'accés.

• Els equips propietaris poden tenir els seus propis registres, els quals ofereixen a qualsevol membre de l'equip accés directe al registre. Els usuaris poden ser membres de diversos equips. Això permetrà que sigui una manera potent de concedir permisos als usuaris d'una manera àmplia sense la microgestió de l'accés al nivell d'usuari individual.
• Els equips d'accés es tracten a la següent secció com a part de l'intercanvi de registres.

Compartir registres

Els registres individuals es poden compartir un per un amb un altre usuari. Aquesta és una manera poderosa de gestionar les excepcions que no pertanyen a la propietat del registre o són membres d'un model d'accés a la unitat de negoci. Hauria de ser una excepció, però, perquè és una manera menys executant de controlar l'accés. L'ús compartit és més difícil de resoldre perquè no és un control d'accés implementat de manera coherent. L'ús compartit es pot fer tant al nivell de l'usuari com d'equip. L'ús compartit amb un equip és una manera més eficient de compartir. Un concepte més avançat d'ús compartit és amb Access Teams, que proporciona la creació automàtica d'un equip i l'ús compartit de l'accés al registre amb l'equip es basa en una plantilla d'equip d'accés (plantilla de permisos) que s'aplica. Els equips d'accés també es poden utilitzar sense les plantilles, amb només afegir o eliminar manualment els seus membres. Els equips d'accés són més eficients, ja que no permeten registres propietaris de l'equip ni tenen les funcions de seguretat assignades a l'equip. Els usuaris obtenen accés perquè el registre es comparteix amb l'equip i l'usuari és un membre.

Seguretat de nivell de registre al Dataverse

Potser us esteu preguntant: què determina l'accés a un registre? Això sona com una pregunta simple però per a qualsevol usuari concret és la combinació de totes les seves funcions de seguretat, la unitat de negoci amb la qual estan associats els equips membres i els registres que hi ha compartits. La clau que cal recordar és que tots els accessos són acumulatius de tots aquests conceptes en l'àmbit d'un entorn de base de dades del Dataverse. Aquests drets només s'atorguen en una única base de dades i se'n fa el seguiment individual a cada base de dades del Dataverse. Tot això requereix que tinguin una llicència adequada per accedir al Dataverse.

Seguretat de nivell de columna al Dataverse

De vegades, el control de nivell d'accés no és suficient per a alguns escenaris empresarials. El Dataverse té un element de seguretat de nivell de columna per permetre un control més granular de lla seguretat al nivell de columna. La seguretat de nivell de columna es pot habilitar a totes les columnes personalitzades i a la majoria de columnes del sistema. La majoria de les columnes del sistema que inclouen informació d'identificació personal (PII) es poden protegir-se individualment. Les metadades de cada columna defineixen si es tracta d'una opció disponible per a la columna del sistema.

La seguretat de nivell de columna està habilitada columna per columna. L'accés s'administra mitjançant la creació d'un perfil de seguretat de columna. El perfil conté totes les columnes que tenen activada la seguretat de nivell de columna i l'accés que atorga aquest perfil específic. Cada columna es pot controlar dins del perfil de l'accés de creació, actualització i lectura. Els perfils de seguretat de columna s'associen a un usuari o un equip per concedir aquests privilegis als usuaris per als registres als quals ja tenen accés. És important tenir en compte que la seguretat de nivell de columna no té res a veure amb la seguretat de nivell de registre. Un usuari ja ha de tenir accés al registre del Perfil de seguretat de columna per atorgar-li accés a les columnes. La seguretat de nivell de columna s'ha d'utilitzar segons calgui i no en excés, ja que pot afegir un cost elevat que és perjudicial si s'utilitza.

Administrar la seguretat en diversos entorns

Les funcions de seguretat i els perfils de seguretat de columna es poden agrupar i moure d'un entorn al següent mitjançant les solucions del Dataverse. Les unitats de negoci i els equips s'han de crear i administrar a cada entorn juntament amb l'assignació d'usuaris als components de seguretat necessaris.

Configurar la seguretat de l'entorn dels usuaris

Quan es creen funcions, equips i unitats de negoci en un entorn, és hora d'assignar als usuaris les seves configuracions de seguretat. En primer lloc, quan creeu un usuari, l'associareu amb una unitat de negoci. Per defecte, aquesta és la unitat de negoci arrel de l'organització. També s'afegeixen a l'equip per defecte d'aquesta unitat de negoci.

A més, heu d'assignar les funcions de seguretat que necessita l'usuari. També els afegireu com a membres d'un equip. Recordeu que els equips també poden tenir funcions de seguretat, de manera que els drets efectius de l'usuari són la combinació de les funcions de seguretat assignades directament, combinades amb les de qualsevol equip del qual sigui membre. La seguretat sempre és additiva oferint el permís menys restrictiu d'algun dels seus drets. El següent és un bon tutorial de configuració de la seguretat de l'entorn.

Si heu utilitzat la seguretat de nivell de columna, haureu d'associar l'usuari o un equip de l'usuari a un dels Perfils de tècnics de columna que heu creat.

La seguretat és un article complex i s'aconsegueix millor com un esforç conjunt entre els creadors de l'aplicació i l'equip que administra els permisos d'usuari. Tots els canvis importants han de coordinar-se amb l'antelació de la implementació dels canvis en l'entorn.

Consulteu també

Configurar la seguretat de l’entorn
Privilegis i funcions de seguretat