Hierarchiabiztonság

 

Közzétéve: 2016. november

Hatókör: Dynamics CRM 2015

A hierarchikus biztonsági modell a már létező Microsoft Dynamics 365 biztonsági modelljeinek kiterjesztése, amely részlegek, biztonsági szerepkörök, megosztások és a csoportok alapján működik. Az összes többi létező biztonsági modellel együtt is használható. A hierarchikus biztonság finomabban hangolható hozzáférést biztosít a bejegyzésekhez, és segít lenyomni a karbantartási költségeket. Bonyolult esetekben például létrehozhat először néhány részleget, majd hozzáadhatja a hierarchikus biztonságot. Ezzel finomhangolt hozzáférést biztosíthat az adatokhoz, jóval alacsonyabb karbantartási költséggel, mint arra nagyszámú részlegnél szükség lenne.

Jelen témakörben

Vezetői hierarchia és pozícióhierarchia alapú biztonsági modellek

A hierarchikus biztonság beállítása

Vezetői és pozícióhierarchiák beállítása

Teljesítménnyel kapcsolatos szempontok

Vezetői hierarchia és pozícióhierarchia alapú biztonsági modellek

Két biztonsági modell használható a hierarchiákra: a vezetői hierarchia és a pozícióhierarchia. A vezetői hierarchiában a vezetőnek ugyanabban a részlegben kell lennie, ahol a jelentés, vagy annak egy fölérendelt részlegében, csak így férhet hozzá a jelentés adataihoz. A pozícióhierarchia több részlegre kiterjedően is lehetővé teszi az adatokhoz való hozzáférést. Ha pénzügyi szervezetnél dolgozik, valószínűleg a vezetői hierarchia modellt találja előnyösebbnek, amelyben a vezetők csak saját részlegeik adataihoz férhetnek hozzá. Ha azonban ügyfélszolgálati szervezetet képvisel, és fontos, hogy a vezetők más részlegekben is rálássanak a különböző esetekre, akkor a pozícióhierarchia modell lesz a hatékonyabb.

Megjegyzés

A hierarchikus biztonsági modell egy adott szintű hozzáférést biztosít az adatokhoz, ami mellett másfajta biztonsági megoldásokkal (például biztonsági szerepkörökkel) további hozzáférés is adható.

Vezetői hierarchia

A vezetői hierarchikus biztonsági modell a felettesi láncra vagy a közvetlen alárendeltségi struktúrára épül, ahol a vezető és a jelentés kapcsolata rendszerfelhasználói entitás Vezető mezőjében hozható létre. Ezzel a biztonsági modellel a vezetők is hozzáférhetnek azokhoz az adatokhoz, amelyekhez jelentéseik hozzáférnek. Ezzel elvégezhetik a közvetlen jelentéseikhez tartozó munkát, vagy hozzáférhetnek a jóváhagyásra váró adatokhoz.

Megjegyzés

A vezetői hierarchikus biztonsági modellel egy vezető hozzáférhet a felhasználók bejegyzéseihez, a felhasználó csoportjainak bejegyzéseihez, valamint a felhasználóval vagy a felhasználó csoportjával közvetlenül megosztott bejegyzésekhez.

A vezetői hierarchikus bizonsági modell mellett a vezetőnek minimum felhasználói szintű olvasási jogosultsággal kell rendelkeznie egy entitásban ahhoz, hogy a jelentés adatait megtekinthesse. Ha például egy vezető nem rendelkezik olvasási hozzáféréssel az Eset entitáshoz, akkor nem láthatja azokat az eseteket, amelyekhez annak jelentései hozzáférnek.

Nem közvetlen jelentéseknél a vezető csak olvasási hozzáféréssel rendelkezik a jelentés adataihoz. Közvetlen jelentéseknél a vezető olvasási, írási, frissítési, hozzáadási és „hozzáadás ehhez” hozzáféréssel rendelkezik a jelentés adataihoz. A vezetői hierarchikus biztonsági modell szemléltetéséhez tekintse át az alábbi ábrát. A vezérigazgatói megtekintheti és frissítheti is az értékesítési igazgató és a szolgáltatási igazgató adatait. Az értékesítési vezető és a szolgáltatási vezető adatait azonban csak olvasni tudja, ugyanúgy, mint az értékesítési és a támogatási adatokat. A „Mélység” opcióval tovább korlátozható a vezetők hozzáférése az adatokhoz. A mélység beállítással állítható be, maximum hány szint mélyen rendelkezik egy vezető olvasási jogosultságokkal jelentéseinek adataihoz. Ha például a mélység értéke 2, a vezérigazgató csak az értékesítési igazgató, a szolgáltatási igazgató, valamint az értékesítési és szolgáltatási vezetők adatait láthatja. Nincs azonban betekintése az értékesítési adatokba és a támogatási adatokba.

Fontos megjegyezni, hogy abban az esetben, ha egy közvetlen beosztott mélyebb biztonsági hozzáféréssel rendelkezik egy entitáshoz mint a felettese, előfordulhat, hogy a felettes nem lát minden rekordot, amelyhez a beosztottnak hozzáférése van. A következő példa szemlélteti ezt az esetet.

• Egy részlegnek három felhasználója van: Felhasználó 1, Felhasználó 2 és Felhasználó 3.

• Felhasználó 2 Felhasználó 1 közvetlen beosztottja.

• Felhasználó 1 és Felhasználó 3 felhasználói szintű olvasási hozzáféréssel rendelkeznek a Partner entitáshoz. Ez a hozzáférési szint elérhetővé teszi a felhasználók számára a saját tulajdonukban lévő rekordokat, a felhasználókkal megosztott rekordokat, illetve az olyan csoporttal megosztott rekordokat, amelynek a felhasználók tagjai.

• Felhasználó 2 részleg szintű olvasási hozzáféréssel rendelkezik a Partner entitáshoz. Ez lehetővé teszi Felhasználó 2 számára, hogy megtekintse a részleg összes partnerét, beleértve az összes Felhasználó 1 és Felhasználó 3 tulajdonában álló partnert.

• Felhasználó 1 – Felhasználó 2 közvetlen feletteseként – hozzáfér a Felhasználó 2 tulajdonában lévő, vagy vele megosztott partnerekhez és minden partnerhez, amelynek olyan csoport a tulajdonosa, vagy olyan csoporttal van megosztva, amelynek Felhasználó 2 tagja. Azonban Felhasználó 1 nem fér hozzá Felhasználó 3 partnereihez, noha közvetlen beosztottja hozzáférhet Felhasználó 3 partnereihez.

Pozícióhierarchia

A pozícióhierarchia nem szorosan a beosztotti hierarchiára épül, mint a vezetői hierarchia. A felhasználónak nem kell feltétlenül vezetőnek lennie ahhoz, hogy más felhasználók adatait láthassa. Rendszergazdaként az egyik feladata, hogy definiálja a szervezet különböző beosztásait, és elrendezze őket a pozícióhierarchiában. Ezután adhat hozzá felhasználókat egy adott pozícióhoz, vagy ahogy mi mondjuk, „felcímkézheti” őket egy adott beosztással. Egy felhasználó egy adott hierarchiában csak egy pozícióval lehet felcímkézve, azonban egy pozíciót több felhasználóhoz is hozzárendelhet. A hierarchia magasabb pozícióiban levő használók az alacsonyabb pozícióban levő felhasználók adataihoz férhetnek hozzá, a közvetlen elődi útvonalon. A közvetlen magasabb pozíció olvasási, írási, frissítési, hozzáfűzési és „hozzáfűzés ehhez” jogosultsággal rendelkeznek az alacsonyabb beosztások adataihoz a közvetlen elődi úton. A nem közvetlen magasabb pozíció csak olvasási jogosultsággal rendelkezik az alacsonyabb beosztások adataihoz a közvetlen elődi úton.

Közvetlen elődi útvonal fogalmának illusztrálásához vizsgáljuk meg az alábbi ábrát. Az értékesítési igazgatói pozíció hozzáfér az értékesítési adatokhoz, azonban a támogatási adatokhoz nem, ez ugyanis eltérő elődi útvonalon található. Ugyanez igaz a szolgáltatási vezető pozíciójára. Ez nem éri el az értékesítési adatokat, amelyek az értékesítési útvonalon helyezkednek el. A vezetői hierarchiához hasonlóan itt is korlátozhatja a magasabb pozíciók által elért adatokat a „Mélyésg” opcióval. A mélység határozza meg, hogy egy adott felső pozíció hány szintre rendelkezik olvasási jogosultsággal a közvetlen elődi úton elérhető alsóbb pozíciókból. Ha például a mélység értéke 3, akkor a vezérigazgatói pozíció minden adatot láthat, amely az értékesítési igazgató és a szolgáltatási igazgató pozíciója alá esik, egészen az értékesítési és támogatási pozíciókig.

Megjegyzés

A pozícióhierarchikus biztonsági modellel egy magasabb szintű pozícióban dolgozó felhasználó hozzáférhet az alsóbb szintű pozícióban dolgozó felhasználó bejegyzéseihez, a felhasználó csoportjainak bejegyzéseihez, valamint a felhasználóval vagy a felhasználó csoportjával közvetlenül megosztott bejegyzésekhez.

A pozícióhierarchiai biztonsági modell mellett a magasabb szinten álló felhasználóknak legalább felhasználói szintű olvasási jogosultsággal kell rendelkezniük egy entitásban, hogy láthassák az alacsonyabban álló pozícióban levő felhasználók által hozzáférhető bejegyzéseket. Ha például egy magasabb szintű felhasználó nem rendelkezik olvasási hozzáféréssel az Eset entitáshoz, akkor nem láthatja azokat az eseteket, amelyekhez az alacsonyabb pozíciójú felhasználók hozzáférnek.

A hierarchikus biztonság beállítása

A biztonsági hierarchia beállításához rendszergazdai szerepkörrel kell rendelkeznie.

A hierarchikus biztonsági alapértelmezés szerint le van tiltva. Az engedélyezéshez:

1. Válassza a Beállítások > Biztonság lehetőséget.

2. Válassza a Hierarchiabiztonság, majd a Hierarchia modellezés engedélyezése lehetőséget.

Fontos

A Hierarchikus biztonság módosításához rendelkeznie kell a Hierarchikus biztonsági beállítások módosítása jogosultsággal.

A hierarchiamodellezés engedélyezését követően a konkrét modell megadásához kattintson a Vezetői hierarchia vagy az Egyéni pozícióhierarchia opcióra. A rendszerentitások mindegyike eleve engedélyezett a hierarchikus biztonságban való használathoz, de szükség szerint bármelyiket kizárhatja közülük a hierarchiából. A Hierarchikus biztonság ablakot lent tekintheti meg:

Ha a Mélység opciót egy adott értékre állítja, megadhatja, maximum hány szint mélyen rendelkezhet egy vezető olvasási jogosultságokkal jelentéseinek adataihoz. Például ha mélység 2, egy vezető csak saját partnereinek és a két szinttel lejjebb levő jelentések partnereinek adataihoz férhet hozzá. Ebben a példában, ha nem az összes partnert látó rendszergazdaként jelentkezik be a Dynamics 365 rendszerbe, hanem értékesítési igazgatóként, akkor csak a vörös négyszögben látható felhasználókhoz tartozó aktív partnereket láthatja, mint azt az alábbi ábra is mutatja:

Megjegyzés

Bár a hierarchikus biztonság az értékesítési igazgatónak csak a vörös négyszögben található bejegyzésekhez ad hozzáférést, emellett további hozzáférést biztosíthat az igazgató biztonsági szerepköre alapján.

Vezetői és pozícióhierarchiák beállítása

A vezetői hierarchiát könnyen létrehozhatja a rendszerfelhasználói bejegyzés vezetői kapcsolat opciójával. A vezetői (ParentsystemuserID) keresőmezőben határozhatja meg a felhasználó vezetőjét. Ha már létrehozta a pozícióhierarchiát, akkor a felhasználót itt felcímkézheti annak egy adott pozíciójával. Az alábbi példában az értékesítő az értékesítési vezető alá tartozik a vezetői hierarchiában, és emellett értékesítési pozícióval rendelkezik a pozícióhierarchiában:

Ha szeretne egy felhasználót hozzáadni a pozícióhierarchia egy adott pozíciójával, a felhasználó bejegyzésűrlapjának Pozíció nevű keresőmezővel teheti ezt meg, a következő módon:

Fontos

Egy felhasználó adott pozícióhoz való hozzáadásához vagy a felhasználó pozíciójának módosításához a Felhasználó pozíciójának beállítása jogosultságra van szüksége.

A felhasználói rekord helyzetének változtatásához a navisávon válassza a Továbbiak (...) lehetőséget és válasszon egy másik helyet az alábbiak szerint:

Egy pozíciós hierarchia létrehozása:

1. Válassza a Beállítások > Biztonság lehetőséget.

2. Válassza a Pozíciók lehetőséget.

Minden egyes pozíciónál adja meg a pozíció nevét, szülőjét és leírását. Ehhez a pozícióhoz A pozíciót betöltő felhasználók keresőmezővel adhat hozzá felhasználókat. Az alábbiakban egy pozícióhierarchia-példát láthat az aktív pozíciókkal.

Az engedélyezett felhasználók és a hozzájuk rendelt pozíciók példáját az alábbiakban láthatja:

Teljesítménnyel kapcsolatos szempontok

A teljesítmény növelése érdekében ajánlott betartani az alábbi javaslatokat:

• A hierarchikus biztonság hatékonysága érdekében ne soroljon 50 felhasználónál többet egy vezető/pozíció alá. Megengedhető 50 főnél több is egy vezető/pozíció alatt, de ebben az esetben a Mélység beállítással korlátozhatja az olvasási hozzáférések szintjét, amely egy vezető/pozíció alatt valóban megtekinthető felhasználók számát 50 alá csökkenti.

• Bonyolultabb esetekben a hierarchikus biztonsági modelleket a többi, már létező biztonsági modellel együtt használja. Ne hozzon létre túl sok részleget, inkább viszonylag kisebb számú részleghez adjon hozzá hierarchikus biztonságot.

Lásd még

A Microsoft Dynamics CRM biztonsági elvei
Hierarchikus adatok lekérdezése és képi megjelenítése
Videó: Hierarchikus biztonsági modell a Microsoft Dynamics CRM 2015 rendszerben
Videó: Hierarchikus képi megjelenítés a Microsoft Dynamics CRM 2015 rendszerben

© 2016 Microsoft Corporation. Minden jog fenntartva. Szerzői jogi tájékoztató