Konfigurowanie zabezpieczeń hierarchii w celu uzyskania ziarnistego dostępu do danych

Uwaga

Jeśli włączono tryb Tylko ujednolicony interfejs, przed użyciem procedur opisanych w tym artykule wykonaj następujące czynności:

1. Wybierz pozycję Settings () na pasku nawigacyjnym.
2. Wybierz pozycję Ustawienia zaawansowane.

   

Model zabezpieczeń hierarchii jest rozszerzeniem istniejących modeli zabezpieczeń programu Dynamics 365 Customer Engagement (on-premises), które korzystają z jednostek biznesowych, ról zabezpieczeń, udostępniania i zespołów. Może być używany w połączeniu ze wszystkimi innymi istniejącymi modelami zabezpieczeń. Zabezpieczenia hierarchii oferują bardziej szczegółowy dostęp do rekordów dla organizacji i pomagają obniżyć koszty konserwacji. Na przykład w złożonych scenariuszach można rozpocząć od utworzenia kilku jednostek biznesowych, a następnie dodać zabezpieczenia hierarchii. W ten sposób zostanie osiągnięty bardziej szczegółowy dostęp do danych przy znacznie niższych kosztach konserwacji, niż może wymagać duża liczba jednostek biznesowych.

Modele zabezpieczeń hierarchii kierowników i hierarchii stanowisk

Dwa modele zabezpieczeń mogą być używane do hierarchii: hierarchia kierowników i hierarchia stanowisk. W hierarchii kierowników kierownik musi być w tej samej jednostki biznesowej co podległy pracownik albo w nadrzędnej jednostce biznesowej jednostki biznesowej pracownika, aby mieć dostęp do danych pracownika. Hierarchia stanowisk umożliwia dostęp do danych we wszystkich jednostkach biznesowych. Jeśli organizacja ma związek z finansami, może być preferowany model hierarchii kierowników, aby uniemożliwić kierownikom dostęp do danych spoza ich jednostek biznesowych. Jednakże jeśli jesteś częścią działu obsługi klienta i chcesz zapewnić kierownikom dostęp do zgłoszeń serwisowych obsługiwanych w różnych jednostkach biznesowych, lepiej może działać hierarchia stanowisk.

Uwaga

Model zabezpieczeń hierarchii zapewnia pewien poziom dostępu do danych, natomiast dodatkowy dostęp można uzyskać przy użyciu innych form zabezpieczeń, takich jak role zabezpieczeń.

Hierarchia kierowników

Model zabezpieczeń hierarchii kierowników opiera się na łańcuchu zarządzania lub strukturze bezpośredniej podległości w relacjach służbowych, gdzie jest ustanawiana relacja przełożonego i podwładnego za pomocą pola Kierownik w encji użytkownika systemowego. W tym modelu zabezpieczeń kierownicy mają dostęp do danych, do których dostęp mają ich podwładni. Są w stanie wykonywać pracę w imieniu swoich bezpośrednich podwładnych oraz mają dostęp do informacji, która wymagają zatwierdzenia.

Uwaga

W modelu zabezpieczeń hierarchii kierowników kierownik ma dostęp do rekordów, których właścicielem jest użytkownik lub zespół, którego użytkownik jest członkiem, i do rekordów, które są bezpośrednio udostępniane użytkownikowi lub zespołowi, którego użytkownik jest członkiem. Gdy rekord jest udostępniany przez użytkownika, który jest poza łańcuchem zarządzania, dla bezpośredniego przełożonego z dostępem tylko do odczytu, menedżer bezpośredniego przełożonego ma tylko dostęp tylko do odczytu do rekordu udostępnianego.

Oprócz modelu zabezpieczeń hierarchii kierowników kierownik musi mieć co najmniej uprawnienie odczytu na poziomie użytkownika wobec encji, aby wyświetlać dane podwładnego. Na przykład jeżeli kierownik nie ma prawa odczytu wobec encji Sprawa, nie będzie widział spraw, do których mają dostęp jego podwładni.

Dla innych niż bezpośredni przełożony w tym samym łańcuchu zarządzania menedżera, menedżer ma dostęp tylko do odczytu do danych raportu innych niż bezpośredni. Dla podwładnych bezpośrednich kierownik może odczytywać, zapisywać, aktualizować, dołączać i dołączać do dla danych podwładnych. Aby zilustrować model zabezpieczeń hierarchii kierowników, spójrzmy na poniższy diagram. Dyrektor generalny może odczytywać i aktualizować dane wiceprezesów ds. sprzedaży i serwisu. Dyrektor generalny może jednak tylko odczytywać dane kierowników sprzedaży i serwisu, a także dane o sprzedaży i wsparciu technicznym. Można dodatkowo zawęzić ilość danych, które są dostępne dla kierownika, za pomocą ustawienia „Głębokość”. Głębokość jest używana do ograniczania liczby poziomów w głąb, na jaką kierownik ma dostęp tylko do odczytu do danych swoich podwładnych. Na przykład jeśli głębokość jest ustawiona na 2, dyrektor generalny może zobaczyć dane wiceprezesów ds. sprzedaży i serwisu oraz kierowników sprzedaży i serwisu. Jednakże nie widzi danych o sprzedaży i wsparciu technicznym.

Należy pamiętać, że jeśli bezpośredni podwładny ma głębszy dostęp do encji niż menedżer, menedżer może nie być w stanie wyświetlić wszystkich rekordów, do których ma dostęp bezpośredni podwładny. Poniższy przykład ilustruje to zagadnienie.

• Pojedyncza jednostka biznesowa ma trzech użytkowników: Użytkownik 1, Użytkownik 2 i Użytkownik 3.

• Użytkownik 2 jest bezpośrednim podwładnym Użytkownika 1.

• Użytkownik 1 i Użytkownik 3 mają dostęp odczytu na poziomie użytkownika dla encji Konto. Ten poziom dostępu zapewnia użytkownikom dostęp do posiadanych rekordów, rekordów udostępnionych użytkownikowi, oraz rekordów udostępnionych zespołowi, którego użytkownik jest członkiem.

• Użytkownik 2 ma dostęp do odczytu na poziomie Jednostki biznesowej dla encji Konto. Dzięki temu użytkownik 2 może wyświetlać wszystkie konta dla jednostki biznesowej, w tym wszystkie konta będące własnością Użytkownika 1 i Użytkownika 3.

• Użytkownik 1, jako bezpośredni przełożony Użytkownika 2 ma dostęp do kont będących własnością lub współdzielonych z Użytkownikiem 2, i wszelkich kont, które są udostępniane zespołowi lub należą do zespołu, którego członkiem jest użytkownik 2. Jednak Użytkownik 1 nie ma dostępu do kont należących do Użytkownika 3, mimo że jego lub jej bezpośredni podwładny może mieć dostęp do kont Użytkownika 3.

Hierarchia stanowisk

Hierarchia stanowisk nie opiera się na strukturze bezpośredniej podległości, w odróżnieniu od hierarchii kierowników. Użytkownik nie musi być rzeczywistym kierownikiem innego użytkownika, aby uzyskać dostęp do jego danych. Jako administrator możesz zdefiniować różne stanowiska w organizacji i ułożyć je w hierarchię stanowisk. Następnie możesz dodać użytkowników do poszczególnych stanowisk, lub innymi słowy „oznakować” użytkowników określonymi stanowiskami. Użytkownika może oznakować tylko jednym stanowiskiem w danej hierarchii, jednak jedno stanowisko może służyć wielu użytkownikom. Użytkownicy na wyższych stanowiskach w hierarchii mają dostęp do danych użytkowników na niższych stanowiskach, w ścieżce bezpośrednich elementów nadrzędnych. Bezpośrednie wyższe stanowiska mają uprawnienia Odczyt, Zapis, Aktualizacja, Dołączanie i Dołączanie do wobec danych na niższych stanowiskach w ścieżce bezpośrednich elementów nadrzędnych. Niebezpośrednie wyższe stanowiska mają uprawnienie Tylko odczyt wobec danych na niższych stanowiskach w ścieżce bezpośrednich elementów nadrzędnych.

Aby zilustrować pojęcie ścieżki bezpośrednich elementów nadrzędnych, spójrzmy na poniższy diagram. Stanowisko Kierownik sprzedaży ma dostęp do danych o sprzedaży, jednak nie ma dostępu do danych o wsparciu technicznym, które znajdują się w innej ścieżce elementów nadrzędnych. To samo dotyczy stanowiska Kierownik serwisu. Nie ma ono dostępu do danych o sprzedaży, które znajdują się w ścieżce Sprzedaż. Podobnie jak w hierarchii kierowników, można ograniczyć ilość danych, które są dostępne na wyższych stanowiskach, za pomocą ustawienia „Głębokość”. Głębokość ograniczy liczbę poziomów, na jakich wyższe stanowisko ma dostęp tylko odczytu wobec danych na niższych stanowiskach w ścieżce bezpośrednich elementów nadrzędnych. Na przykład jeśli głębokość jest ustawiona na 3, stanowisko dyrektora generalnego widzi dane na całej ścieżce od stanowisk wiceprezesów ds. sprzedaży i serwisu aż do szeregowych stanowisk w działach sprzedaży i wsparcia technicznego.

Uwaga

W modelu zabezpieczeń hierarchii stanowisk użytkownik na wyższym stanowisku ma dostęp do rekordów, których właścicielem jest użytkownik na niższym stanowisku lub zespół, którego użytkownik jest członkiem, i do rekordów, które są bezpośrednio udostępniane użytkownikowi lub zespołowi, którego użytkownik jest członkiem.

Oprócz modelu zabezpieczeń hierarchii stanowisk użytkownicy na wyższym poziomie muszą mieć co najmniej uprawnienie odczytu na poziomie użytkownika wobec encji, aby widzieć rekordy, do których mają dostęp użytkownicy na niższych stanowiskach. Na przykład jeżeli użytkownik na wyższym poziomie nie ma prawa odczytu wobec encji Sprawa, nie będzie widział spraw, do których mają dostęp użytkownicy na niższych stanowiskach.

Konfigurowanie zabezpieczeń hierarchii

Aby skonfigurować hierarchię zabezpieczeń, musisz mieć rolę zabezpieczeń Administrator.

Zabezpieczenia hierarchii są domyślnie wyłączone. Aby ją włączyć:

1. Wybierz kolejno pozycje Ustawienia>Zabezpieczenia.

2. Wybierz Zabezpieczenia hierarchii i wybierz Włącz modelowanie hierarchii.

Ważne

Aby wprowadzać jakiekolwiek zmiany w oknie Zabezpieczenia hierarchii, musisz mieć uprawnienie Zmiana ustawień zabezpieczeń hierarchii.

Po włączeniu modelowania hierarchii wybierz określony model, zaznaczając opcję Hierarchia kierowników lub Niestandardowa hierarchia stanowisk. Wszystkich encje systemowe są fabrycznie włączone dla zabezpieczeń hierarchii, ale można wykluczyć encje selektywnie z hierarchii. Okno Zabezpieczenia hierarchii przedstawiono poniżej:

Ustaw opcję Głębokość na żądaną wartość, aby ograniczyć liczbę poziomów w głąb, na jaką kierownik ma dostęp tylko do odczytu do danych swoich podwładnych. Na przykład, jeśli głębokość jest równa 2, kierownik ma dostęp tylko do swoich klientów oraz klientów swoich podwładnych na dwa poziomy w głąb. W naszym przykładzie jeśli zalogujesz się w aplikacjach Customer Engagement nie jako Administrator, kto może widzieć wszystkich klientów, ale jako wiceprezes ds. sprzedaży, będziesz widzieć tylko aktywnych klientów użytkowników wyświetlanych w czerwonym prostokącie, jak zostało to przedstawione poniżej:

Uwaga

Choć zabezpieczenia hierarchii przyznają wiceprezesowi ds. sprzedaży dostęp do rekordów w czerwonym prostokącie, dodatkowy dostęp może być dostępny w oparciu o rolę zabezpieczeń, którą ma wiceprezes ds. sprzedaży.

Konfigurowanie hierarchii kierowników i stanowisk

Hierarchia kierowników jest łatwo tworzona za pomocą relacji kierowników na rekordzie użytkownika systemowego. Użyj pola odnośnika Kierownik (ParentsystemuserID), aby określić kierownika użytkownika. Jeśli już utworzono hierarchię stanowisk, można również oznakować użytkownika określonym stanowiskiem w hierarchii stanowisk. W poniższym przykładzie sprzedawca podlega kierownikowi sprzedaży w hierarchii kierowników i ma również stanowisko sprzedaży w hierarchii stanowisk:

Aby dodać użytkownika do określonego stanowiska w hierarchii stanowisk, użyj pola odnośnika o nazwie Stanowiska wobec formularza rekordu użytkownika, jak poniżej:

Ważne

Aby dodać użytkownika do stanowiska lub zmienić stanowisko użytkownika, musisz mieć uprawnienie Przypisywanie stanowiska do użytkownika.

Aby zmienić stanowisko w formularzu rekordu użytkownika, na pasku nawigacji wybierz opcję Więcej (...) i wybierz inne stanowisko, jak pokazano poniżej:

Aby utworzyć hierarchię Stanowiska:

1. Wybierz kolejno pozycje Ustawienia>Zabezpieczenia.

2. Wybierz Stanowiska.

   Dla każdego stanowiska podaj nazwę, obiekt nadrzędny i opis. Dodaj użytkowników do tego stanowiska, korzystając z pola odnośnika o nazwie Użytkownicy na tym stanowisku. Poniżej znajduje się przykład hierarchii stanowisk z aktywnymi stanowiskami.

   

   Poniżej przedstawiono przykład włączonych użytkowników z ich odpowiednimi stanowiskami:

   

Zagadnienia dotyczące wydajności

Aby zwiększyć wydajność, zalecamy:

• Aby zachować skuteczne zabezpieczenie hierarchii, utrzymuj maksymalnie 50 użytkowników dla jednego kierownika/stanowiska. Hierarchia może mieć więcej niż 50 użytkowników pod jednym kierownikiem/stanowiskiem, ale można użyć ustawienia Głębokość, aby zmniejszyć liczbę poziomów dostępu tylko do odczytu, a w ten sposób efektywną liczbę użytkowników dla kierownika/stanowiska do maksymalnie 50.

• Używaj modeli zabezpieczeń hierarchii w połączeniu z innymi istniejącymi modelami zabezpieczeń dla bardziej złożonych scenariuszy. Należy unikać tworzenia dużej liczby jednostek biznesowych, a zamiast tego tworzyć mniej jednostek biznesowych i dodawać zabezpieczenia hierarchii.

Zobacz także

Koncepcje zabezpieczeń dla Microsoft Dynamics 365 for Customer Engagement
Zapytaj i wizualizuj dane hierarchiczne