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