Ієрархія безпеки для керування доступом
Ієрархічна модель безпеки є розширенням наявних моделей безпеки, в яких використовуються підрозділи, ролі безпеки, спільний доступ і робочі групи. Його можна використовувати з усіма іншими існуючими моделями безпеки. Ієрархічна безпека пропонує більш детальний доступ до записів для організації та допомагає знизити витрати на обслуговування.
Наприклад, у складних сценаріях можна почати зі створення кількох бізнес-підрозділів, а потім додати ієрархічну організацію безпеки. Ця додаткова безпека забезпечує більш детальний доступ до даних із набагато меншими витратами на обслуговування, які можуть знадобитися великій кількості бізнес-підрозділів.
Ієрархія менеджерів та ієрархія посад моделі безпеки
Для ієрархій можна використовувати дві моделі безпеки: ієрархію менеджерів та ієрархію посад. Для доступу до даних звіту керівник має бути в межах тієї самої структурної одиниці, що й звіт, або в материнській структурній одиниці бізнес-одиниці звіту. Ієрархія посад дозволяє доступ до даних між різними підрозділами. Якщо ви фінансова організація, ви можете віддати перевагу моделі ієрархії менеджерів, щоб запобігти доступу менеджерів до даних за межами своїх бізнес-підрозділів. Однак, якщо ви є частиною служба підтримки клієнтів організації і хочете, щоб менеджери мали доступ до службових випадків, які обробляються в різних бізнес-підрозділах, ієрархія посад може підійти вам краще.
Нотатка
У той час як ієрархічна модель безпеки надає певний рівень доступу до даних, можна отримати додатковий доступ за допомогою інших форм безпеки, таких як ролі безпеки.
Ієрархія керівників
Модель безпеки ієрархії менеджерів базується на ланцюжку управління або структурі прямого підпорядкування, де взаємозв’язок керівника та звіту встановлюється за допомогою поля «Керівник» у таблиці користувача системи. За допомогою цієї моделі безпеки менеджери можуть отримати доступ до даних, до яких мають доступ їхні звіти. Вони можуть виконувати роботу від імені своїх безпосередніх підлеглих або отримувати доступ до інформації, яка потребує узгодження.
Нотатка
У моделі безпеки ієрархії менеджерів керівник має доступ до записів, що належать користувачеві або команді, членом якої є користувач, а також до записів, які безпосередньо передаються користувачеві або команді, членом якої є користувач. Якщо користувач, який перебуває поза ланцюжком керування, надає спільний доступ до запису користувачеві прямого підлеглого з доступом лише для читання, керівник прямого підлеглого має доступ до спільного запису лише для читання.
Якщо ввімкнути параметр Записувати право власності між бізнес-одиницями , керівники можуть мати прямих підлеглих із різних бізнес-підрозділів. Для усунення обмеження щодо підрозділів можна скористатися цими параметрами бази даних середовища.
ManagersMustBeInSameOrParentBusinessUnitAsReports
Default = true
Ви можете встановити значення false, і бізнес-одиниця керівника не обов’язково має збігатися з бізнес-одиницею безпосереднього підлеглого.
На додаток до ієрархічної моделі безпеки менеджерів, адміністратор повинен мати принаймні привілеї на читання на рівні користувача в таблиці, щоб бачити дані звітів. Наприклад, якщо менеджер не має доступу на читання до таблиці Інцидент, він не зможе переглядати інциденти, до яких мають доступ його звіти.
Для непрямого підлеглого в тому ж ланцюжку управління менеджер має доступ лише для читання до даних непрямого підлеглого. Для прямого підлеглого керівник має доступ до даних звіту Read, Write, AppendTo. Щоб проілюструвати модель безпеки ієрархії менеджерів, розглянемо наступну діаграму. Генеральний директор може читати або оновлювати дані віце-президента зі збуту та віце-президента з обслуговування. Однак генеральний директор може зчитувати лише дані менеджера з продажу та дані менеджера з обслуговування, а також дані про продажі та підтримку. Ви можете додатково обмежити обсяг даних, доступних менеджеру, за допомогою глибини. Глибина використовується для обмеження глибини, на скільки рівнів менеджер має доступ лише для читання до даних своїх звітів. Наприклад, якщо встановлено глибину 2, генеральний директор може бачити дані віце-президента з продажу, віце-президента з обслуговування, а також менеджерів з продажу та обслуговування. Однак генеральний директор не бачить ні даних про продажі, ні даних підтримки.
Важливо зауважити, що якщо безпосередній підлеглий має глибший доступ до таблиці, ніж його керівник, він може не бачити всі записи, до яких має доступ безпосередній підлеглий. Цю ситуацію розглянуто в прикладі нижче.
Одна бізнес-одиниця складається з трьох користувачів: Користувач 1, Користувач 2 і Користувач 3.
Користувач 2 є прямим підлеглим Користувача 1.
Користувачі 1 і 3 мають доступ на читання на рівні користувача в таблиці «Обліковий запис». Цей рівень доступу надає користувачу доступ до записів, за які він відповідає, записів, до яких йому надано спільний доступ, і записів, до яких має спільний доступ робоча група, до якої користувач належить.
Користувач 2 має доступ до читання бізнес-одиниці в таблиці «Обліковий запис». Цей доступ дозволяє Користувачеві 2 переглядати всі облікові записи бізнес-одиниці, включаючи всі облікові записи, що належать Користувачеві 1 і Користувачеві 3.
Користувач 1, як безпосередній керівник Користувача 2, має доступ до облікових записів, що належать Користувачеві 2 або спільно з ним, включаючи облікові записи, спільні з іншими командами Користувача 2 або належать їм. Однак Користувач 1 не має доступу до облікових записів Користувача 3, хоча його прямий підлеглий може мати доступ до облікових записів Користувача 3.
Ієрархія посад
Ієрархія посад не ґрунтується на структурі прямого підпорядкування, як ієрархія менеджерів. Користувач не повинен бути фактичним керівником іншого користувача, щоб отримати доступ до його даних. Як адміністратор, ви визначаєте різні посади в організації та впорядковуєте їх в ієрархію посад. Потім ви додаєте користувачів на будь-яку задану позицію, або, як ми ще говоримо, позначаєте користувача певною позицією. Користувачу можна призначити лише одну посаду в заданій ієрархії, проте одну посаду можна використовувати для кількох керівників. Користувачі на вищих посадах в ієрархії мають доступ до даних користувачів на нижчих посадах, за шляхом прямих предків. Прямі вищі посади мають доступ із правами «Читання», «Записування», «Додавання», «Додавання до» до даних нижчих посад за шляхом прямих предків. Непрямі вищі позиції мають доступ лише для читання до даних нижчих позицій на шляху прямого предка.
Щоб проілюструвати концепцію прямого шляху предків, розглянемо наступну схему. Посада менеджера з продажу має доступ до даних про продажі, однак вона не має доступу до даних підтримки, які знаходяться на іншому шляху предків. Те ж саме стосується і посади сервіс-менеджера. Він не має доступу до даних про продажі, які знаходяться на шляху продажів. Як і в ієрархії менеджерів, ви можете обмежити обсяг даних, доступних вищими посадами, за допомогою глибини. Глибина обмежує, на скільки рівнів глибини вища позиція має доступ лише для читання, до даних нижчих позицій на шляху прямого предка. Наприклад, якщо для глибини встановлено значення 3, посада генерального директора може бачити дані від посад віце-президента з продажів і віце-президента з обслуговування до посад відділу продажів і підтримки.
Нотатка
Завдяки безпеці ієрархії посад користувач на вищій посаді має доступ до записів, що належать користувачеві нижчої позиції або команді, членом якої є користувач, а також до записів, які безпосередньо надаються користувачеві або команді, членом якої є користувач.
На додаток до моделі безпеки ієрархії позицій, користувачі на вищому рівні повинні мати принаймні привілеї на читання на рівні користувача в таблиці, щоб бачити записи, до яких мають доступ користувачі, що знаходяться на нижчих позиціях. Наприклад, якщо користувач вищого рівня не має доступу на читання до таблиці «Інцидент», він не зможе бачити інциденти, до яких мають доступ користувачі, що займають нижчі позиції.
Настроювання ієрархічної системи безпеки
Щоб настроїти захист ієрархії, переконайтеся, що у вас є дозвіл системного адміністратора на оновлення параметра.
- Виконайте дії, зазначені в статті Перегляд профілю користувача.
- Немає відповідних дозволів? Зверніться до системного адміністратора.
Ієрархічну модель безпеки за промовчанням вимкнуто. Щоб увімкнути захист ієрархії, виконайте наведені нижче дії.
Виберіть середовище та перейдіть у розділ Настройки>Користувачі та дозволи>Ієрархічна система безпеки.
У розділі Модель ієрархії виберіть Увімкнути модель ієрархії менеджера або Увімкнути модель ієрархії посад залежно від ваших вимог.
Важливо
Щоб внести будь-які зміни до ієрархічної системи безпеки, потрібно мати права Змінення настройок ієрархічної системи безпеки.
В області керування таблицями ієрархії всі системні таблиці ввімкнуто для захисту ієрархії за промовчанням, але можна виключити вибіркові таблиці з ієрархії. Щоб виключити певні таблиці з моделі ієрархії, зніміть прапорці для таблиць, які потрібно виключити, і збережіть зміни.
Встановіть потрібне значення глибини , щоб обмежити глибину на скількох рівнях, на які менеджер має доступ лише для читання до даних своїх звітів.
Наприклад, якщо глибина дорівнює 2, менеджер може отримати доступ лише до власних облікових записів, а рахунки звітів глибиною у два рівні. У нашому прикладі, якщо ви входите до програм customer engagement як віце-президент зі збуту, який не є адміністратором, ви бачите лише активні облікові записи користувачів, як показано на рисунку:
Нотатка
Хоча ієрархічна система безпеки надає віце-президенту зі збуту доступ до записів у червоному прямокутнику, можна отримати додатковий доступ залежно від ролі безпеки, яку має ВП зі збуту.
У розділі «Керування таблицями ієрархії» всі системні таблиці за замовчуванням увімкнено для захисту ієрархії. Щоб виключити певну таблицю з ієрархічної моделі, зніміть прапорець поруч із назвою таблиці та збережіть зміни.
Важливо
- Це функція попереднього перегляду.
- Підготовчі функції призначені для невиробничого використання і можуть бути обмежені. Ці функції доступні до офіційного випуску, щоб клієнти могли ознайомитися з ними заздалегідь і залишити відгуки.
Налаштування ієрархії керівника та посади
Ієрархію менеджерів легко створити за допомогою зв’язку менеджера в записі користувача системи. Слід скористатися полем підстановки «Керівник» (ParentsystemuserID), щоб зазначити керівника певного користувача. Якщо ви створили ієрархію посад, ви також можете позначити користувача певною позицією в ієрархії посад. У наведеному нижче прикладі продавець підпорядковується менеджеру з продажу в ієрархії менеджерів, а також має посаду продавця в ієрархії посад:
Щоб додати користувача на певну посаду в ієрархії посад, використовуйте поле підстановки під назвою Посада у формі запису користувача.
Важливо
Щоб додати користувача на посаду або змінити посаду користувача, потрібно мати право Призначення посади для користувача.
Щоб змінити положення у формі запису користувача, на панелі переходів виберіть пункт Більше (...) і виберіть інше положення.
Щоб створити ієрархію посад:
Виберіть середовище та перейдіть у розділ Настройки>Користувачі та дозволи>Розташування.
Для кожної посади вкажіть назву, материнську посаду та опис. Додайте користувачів на цю посаду за допомогою поля підстановки Користувачі на цій посаді. Наступне зображення є прикладом ієрархії позицій з активними позиціями.
Приклад увімкнених користувачів з відповідними позиціями показаний на наступному зображенні.
Включення або виключення записів, що належать прямому підлеглому зі статусом вимкненого користувача
Після 31 січня 2024 року керівники можуть переглядати записи прямого підлеглого про вимкнений статус для середовищ, де ввімкнено захист ієрархії. Для інших середовищ записи вимкнутого статусу прямого підлеглого не включаються в подання керівника.
Щоб включити записи прямого підлеглого вимкненого статусу:
- Інсталюйте інструмент OrganizationSettingsEditor.
- Оновіть параметр AuthorizationEnableHSMForDisabledUsers на true.
- Вимкніть моделювання ієрархії.
- Увімкніть його знову.
Щоб виключити записи прямого підлеглого з вимкненим статусом:
- Інсталюйте інструмент OrganizationSettingsEditor.
- Оновіть параметр AuthorizationEnableHSMForDisabledUsers на false.
- Вимкніть моделювання ієрархії.
- Увімкніть його знову.
Нотатка
- Якщо вимкнути та знову ввімкнути моделювання ієрархії, оновлення може зайняти деякий час, оскільки системі потрібно повторно обчислити доступ до записів менеджера.
- Якщо відображається час очікування, зменште кількість таблиць у списку Керування таблицями ієрархії, щоб включити лише ті таблиці, які має переглядати керівник. Якщо тайм-аут не зникає, надішліть запит до служби підтримки, щоб попросити про допомогу.
- Записи прямого підлеглого з вимкненим статусом включаються, якщо ці записи передаються іншому активному безпосередньому підлеглому. Ці записи можна виключити, видаливши спільний ресурс.
Рекомендації щодо продуктивності
Для збільшення продуктивності рекомендовано:
Забезпечте ефективну безпеку ієрархії до 50 користувачів або менше під керівництвом керівника або посади. Ваша ієрархія може налічувати понад 50 користувачів під керівництвом керівника або посади, але ви можете скористатися настройкою глибини , щоб зменшити кількість рівнів доступу лише для читання та обмежити ефективну кількість користувачів під керівництвом керівника або посади до 50 користувачів або менше.
Використовуйте ієрархічні моделі безпеки з іншими існуючими моделями безпеки для більш складних сценаріїв. Уникати створення великої кількості підрозділів, натомість створити менше підрозділів і додати ієрархічну систему безпеки.
Див. також
Безпека в Microsoft Dataverse
Здійснення запитів до ієрархічних даних та їх візуалізація