Концепції безпеки в Microsoft Dataverse

Одна з ключових особливостей Dataverse, це багатофункціональна модель системи безпеки, здатна пристосовуватись до широкого спектру ділових сценаріїв. Ця модель безпеки діє лише тоді, коли в середовищі є Dataverse база даних. Адміністратору, найімовірніше, не доведеться будувати модель повністю. Проте, йому потрібно буде приймати участь в керуванні користувачами, забезпеченні правильної конфігурації користувачів, та розв'язанні проблем з доступом.

Порада

Перегляньте наступне відео: Microsoft Dataverse – Концепції безпеки показані в демонстраціях.

Система безпеки на основі ролей.

Dataverse використовує безпеку на основі ролей для створення набору прав. Ці ролі безпеки можна призначити безпосередньо користувачам, або робочим групам та організаційним підрозділам Dataverse. Після цього користувачі можуть бути пов’язані з командою, і тому всі користувачі, пов’язані з командою, отримують вигоду від цієї ролі. Важливо розуміти, що в Dataverse надані права доступу накопичуються, і користувачу надається найширший можливий доступ. Якщо ви надали право на читання на рівні доступу всієї організації до всіх записів контактних осіб, ви не зможете повернутися та приховати один запис.

Організаційні одиниці

Порада

Ознайомтеся з наступним відео: Модернізація бізнес-одиниць.

Організаційні одиниці працюють з ролями безпеки для визначення ефективної безпеки користувача. Організаційні підрозділи — це стандартні блоки моделювання системи безпеки, що полегшують керування користувачами та тим, до яких даних у них є доступ. Організаційні підрозділи визначають периметр системи безпеки. Кожна база даних Dataverse має один кореневий організаційний підрозділ.

Ви можете створювати дочірні підрозділи для подальшого розподілення користувачів та даних. Кожен користувач, призначений оточенню, належить до певної бізнес-одиниці. Підрозділи можуть точно повторювати структуру ієрархії установи, але частіше вони просто задають периметри системи безпеки для виконання вимог моделі.

Щоб краще зрозуміти, розгляньмо приклад. Дано: три організаційні підрозділи. Woodgrove — кореневий підрозділ. Завжди знаходиться на верху ієрархії, перемістити його не можна. Ми створили ще два дочірніх бізнес-підрозділи A та B. Користувачі цих бізнес-підрозділів мають різні потреби в доступі. Під час пов’язання користувача з цим середовищем ми можемо додати його до одного з цих трьох підрозділів. Якщо користувач пов’язаний, визначає, якій бізнес-одиниці належать записи, власником яких є цей користувач. Подібна асоціація дає змогу налаштувати роль безпеки користувача, щоб він бачив усі записи підрозділу.

Ієрархічна структура доступу до даних

Клієнти можуть використовувати організаційну структуру, в якій дані та користувачі розташовуються в деревоподібній ієрархії.

Коли ми пов’язуємо користувача з цим середовищем, ми можемо вказати для користувача приналежність до однієї з цих трьох підрозділів і призначити йому роль безпеки з підрозділу. Організаційна одиниця, із якою зв'язаний користувач, визначає, яка організаційна одиниця відповідає за записи, які створюватиме користувач. Маючи такий зв’язок, ми можемо налаштувати роль безпеки, яка дозволяє користувачеві бачити записи в цій бізнес-одиниці.

Користувач А пов'язаний із Відділенням А й отримує роль безпеки Y з Відділення А. Це дозволяє користувачу А отримати доступ до записів Контактна особа №1 та Контактна особа №2. У той час як користувач B у дивізіоні B не може отримати доступ до записів контактів дивізіону A, але може отримати доступ до запису контакту #3.

Матрична структура доступу до даних (модернізовані підрозділи)

Клієнти можуть використовувати організаційну структуру, в якій дані розподіляються в подібної до дерева ієрархії, а користувачі можуть отримувати доступ й працювати із даними з будь-якої організаційної одиниці, незалежно від того, до якої організаційної одиниці призначено певного користувача.

Під час пов’язання користувача з цим середовищем ми можемо додати його до одного з цих трьох підрозділів. Для кожної організаційної одиниці, до даних з якої потрібно отримати доступ, користувачеві призначається роль безпеки. Під час створення запису користувачем він може передати відповідальність за цей запис організаційній одиниці.

Користувач А може бути пов'язаний із будь-якими організаційними одиницями, включно із кореневою організаційною одиницею. Роль безпеки Y з Відділення А призначається користувачеві А, і надає цьому користувачеві доступ до записів Контактна особа №1 та Контактна особа №2. Роль безпеки Y з Відділення Б призначається користувачеві А, і надає цьому користувачеві доступ до запису Контактна особа №3.

Увімкнення матричної структури доступу до даних

Примітка

Перш ніж увімкнути цю функцію, ви маєте опублікувати всі настроювання, щоб усі нові неопубліковані таблиці підтримували цю функцію. Якщо ви виявите в себе неопубліковані таблиці, які не працюють з цією функцією після її ввімкнення, задайте параметр RecomputeOwnershipAcrossBusinessUnits за допомогою засобу OrgDBOrgSettings для Microsoft Dynamics CRM. Встановлення для параметра RecomputeOwnershipAcrossBusinessUnits значення true дозволяє встановити та оновити поле «Володіння бізнес-одиницею ».

1. увійдіть у Power Platform Центр адміністрування як адміністратор (адміністратор або Microsoft Power Platform адміністратор Dynamics 365).
2. Перейдіть на вкладку Середовища та виберіть середовище, для якого потрібно ввімкнути цю функцію.
3. Виберіть елементи Настройки>Продукт>Функції.
4. Увімкніть перемикач Відповідальність за запис в організаційних одиницях.

Після увімкнення цього перемикача можна вибрати організаційну одиницю при призначенні ролі безпеки користувачеві. Це дасть змогу призначати користувачу роль безпеки з різних підрозділів. Користувачу також потрібна роль безпеки від підрозділу, якому призначено користувача з правами на налаштування користувачів для запуску модельних програм. Ви можете звернутися до ролі безпеки Базовий користувач, щоб дізнатися, як активуються ці права на налаштування користувачів.

Ви можете призначити користувача відповідальним за запис у будь-якому підрозділі, не призначаючи роль безпеки в підрозділі, що володіє записом, якщо у користувача є роль безпеки з правом читання таблиці записів. Див. розділ Призначення відповідального за запис у модернізованих підрозділах.

Примітка

Цей перемикач функції зберігається в параметрі EnableOwnershipAcrossBusinessUnits і може бути встановлений за допомогою засобу OrgDBOrgSettings для Microsoft Dynamics CRM.

Пов’язування бізнес-одиниці з групою Microsoft Entra безпеки

Групу Microsoft Entra безпеки можна використовувати для складання карти бізнес-одиниці для оптимізації адміністрування користувачів і призначення ролей.

Створіть групу Microsoft Entra безпеки для кожного бізнес-підрозділу та призначте відповідну роль безпеки бізнес-одиниці кожній команді групи.

Для кожної бізнес-одиниці створіть групу Microsoft Entra безпеки. Створіть групову команду Dataverse для кожної Microsoft Entra групи безпеки. Призначте відповідні роль безпеки з підрозділу кожній груповій робочій групі Dataverse . Користувача на наведеній вище схемі буде створено в кореневому підрозділі, коли користувач отримає доступ до середовища. Це нормально, коли користувач і групова робоча група Dataverse перебувають у кореневому підрозділі. У них є доступ лише до даних у підрозділі, якому призначено роль безпеки.

Додайте користувачів до відповідної Microsoft Entra групи безпеки, щоб надати їм доступ до бізнес-одиниці. Користувачі можуть одразу запустити програму та отримати доступ до його ресурсів і даних.

У матриці доступу до даних, де користувачі можуть працювати та отримувати доступ до даних із кількох бізнес-одиниць, додайте користувачів до Microsoft Entra груп безпеки, які зіставлені з цими бізнес-одиницями.

Відповідальний підрозділ

Кожен запис має стовпець «Власник бізнес-одиниці », який визначає, якій бізнес-одиниці належить запис. Цей стовпець за замовчуванням використовується для бізнес-одиниці користувача під час створення запису та не може бути змінений, за винятком випадків, коли перемикач функцій увімкнено.

Примітка

Коли ви змінюєте, якій бізнес-одиниці належить запис, обов’язково ознайомтеся з наведеними нижче параметрами для каскадних ефектів: Використання SDK для .NET для налаштування каскадної поведінки.

Ви можете зазначити, чи хочете дозволити користувачу задавати значення стовпця «Відповідальний підрозділ», якщо цю функцію ввімкнуто. Щоб налаштувати стовпець «Відповідальний підрозділ», вам необхідно надати ролі безпеки користувача право Додавання до з дозволом локального рівня.

Щоб дозволити користувачу встановлювати цей стовпець, можна ввімкнути його таким чином:

1. Форма — і в основному тексті, і у верхньому колонтитулі.
2. Подання.
3. Відображення стовпців. Якщо ви використовуєте AutoMapEntity, ви можете вказати стовпець у зіставленні стовпців.

Примітка

Якщо у вас є завдання або процес для синхронізації даних між середовищами, а Відповідальний підрозділ додається до складу схеми, це завдання не вдасться виконати, і відобразиться повідомлення про порушення обмеження Зовнішнього ключа, якщо значення Відповідальний підрозділ у цільовому середовищі відрізняється.

Ви можете видалити стовпець Відповідальний підрозділ зі схеми джерела або змінити значення поля Відповідальний підрозділ у джерелі на будь-який підрозділ у цільовому середовищі.

Якщо у вас є завдання або процес для копіювання даних із середовища до зовнішнього ресурсу, наприклад PowerBI, потрібно буде вибрати або скасувати вибір стовпця Відповідальний підрозділ у джерелі. Виберіть це поле, якщо ресурс здатен його прийняти та обробити, в іншому випадку скасуйте вибір.

Відповідальний за таблицю або запис

Dataverse підтримує два типи відповідальності за запис. Відповідальність організації та відповідальність користувача або команди. Це вибір, який виконується під час створення таблиці, і його не можна змінити. З міркувань безпеки для записів, за які відповідає організація, можна вибрати тільки один варіант рівня доступу: може користувач виконувати операцію, чи ні. Для записів, за які відповідає робоча група або користувач, варіантами рівня доступу для більшості прав є: організація, організаційна одиниця, організаційна одиниця та дочірня організаційна одиниця або лише власні записи користувача. Тобто, якщо поставити право перегляду контактних осіб на рівень «Користувач», то користувач зможе переглядати лише власні записи.

Ще один приклад. Скажімо, користувач пов'язаний з відділом а, і ми призначаємо рівень доступу «підрозділ» для перегляду контактних осіб. Тоді можна переглядати Контакт №1 і Контакт №2, але не Контакт №3.

У разі настроювання права ролі безпеки доступу настроюється рівень доступу для кожного параметра. Нижче наведено приклад редактора прав Ролей безпеки.

У вищенаведених розділах можна переглянути стандартні типи прав для кожної таблиці: створення, читання, записування, видалення, додавання, додавання до, призначення та спільний доступ. Кожний тип можна редагувати окремо. Візуальне відображення для кожного з них збігатимуться з ключовим елементом нижче, до якого надано доступ.

У наведеному вище прикладі ми надали доступ на рівні організації до Контактних осіб, тобто користувач у відділі А зможе переглядати та оновлювати контактні особи будь-кого в системі. Власне, одна з найпоширеніших помилок адміністратора, це надання надмірного доступу через роздратування від системи дозволів. І дуже швидко елегантна модель системи безпеки стає схожою на решето.

Призначення відповідального за запис у модернізованих підрозділах

У модернізованих підрозділах користувачі можуть бути відповідальними за записи будь-яких підрозділів. Усе, що потрібно користувачам, – це роль безпеки (будь-який підрозділ) з правом на читання таблиці записів. Користувачам не потрібно призначати роль безпеки в кожному підрозділі, де є запис.

Якщо параметр Призначення відповідального за запис у підрозділах було ввімкнуто у вашому робочому середовищі протягом періоду підготовчої версії, вам необхідно ввімкнути призначення відповідального за запис у підрозділі. Щоб зробити це, виконайте такі дії:

1. Інсталюйте Редактор параметрів організації
2. Установіть для параметрів організації RecomputeOwnershipAcrossBusinessUnits значення true. Якщо для цього параметра встановлено значення true, система блокується, і повторне обчислення може тривати до 5 хвилин, щоб увімкнути можливість, за якої користувачі тепер можуть володіти записами в різних бізнес-одиницях без необхідності призначати окрему роль безпеки від кожного бізнес-підрозділу. Це дає змогу власнику запису призначити свій запис користувачу, який не є власником запису.
3. Установіть для параметра AlwaysMoveRecordToOwnerBusinessUnit значення false. У результаті якщо власника запису буде змінено, запис залишиться у вихідному відповідальному підрозділі.

Для всіх невиробничих середовищ потрібно просто встановити для параметра AlwaysMoveRecordToOwnerBusinessUnit значення false, щоб використовувати цю можливість.

Примітка

Якщо за допомогою інструмента OrgDBOrgSettings для CRM вимкнути функцію Запис про право власності між бізнес-одиницями або встановити значення false для параметра RecomputeOwnershipAcrossBusinessUnits , ви не зможете встановити або оновити Microsoft Dynamics поле Ownering Businessunit, а всі записи, у яких поле Ownering Business Unit відрізняється від поля Business Unit власника, будуть оновлені до бізнес-одиниці власника.

Робочі групи (включно з груповими робочими групами)

Робочі групи, це ще один важливий елемент безпеки. За робочі групи відповідає підрозділ. Кожен підрозділ має одну робочу групу за замочуванням, створено автоматично при створенні самого підрозділу. Учасники цієї групи (за замовчуванням, всі користувачі приписані до підрозділу) керуються Dataverse. До робочої групи за замовчуванням не можна вручну додавати учасників, чи видаляти їх. Система автоматично регулює список учасників, коли користувачі зв’язуються із підрозділами або виходять з їх складу. Існує два типи робочих груп: відповідальні групи та групи доступу.

• Відповідальні робочі групи можуть мати власні записи, прямий доступ до яких надається будь-якому учаснику робочої групи. Користувачі можуть входити в кілька робочих груп. Це дозволяє надавати користувачам широкий доступ, при цьому не налаштовуючи доступ для кожного користувача окремо.
• Робочі групи доступу розглядаються в наступному розділі у контексті спільного доступу до записів.

Надання спільного доступу до записів

Окремими записами можна ділитися на індивідуальній основі з іншим користувачем. Це потужний спосіб обробки винятків, які не належать до запису або є частиною моделі доступу до бізнес-одиниці. Однак це має бути винятком, оскільки це менш ефективний спосіб контролю доступу. Спільний доступ складніше виправити неполадками, оскільки він не є послідовно впровадженим контролем доступу. Спільний доступ можна виконати на рівні користувача або робочої групи. Надання спільного доступу робочій групі ефективніше. Більш просунута концепція спільного доступу пов’язана з Access Teams, яка забезпечує автоматичне створення команди, а спільне використання доступу до записів з командою базується на шаблоні команди доступу (шаблон дозволів), який застосовується. Команди Access також можна використовувати без шаблонів, просто вручну додаючи або видаляючи її учасників. Команди доступу більш продуктивні, оскільки самі команди не можуть відповідати за записи чи мати ролі системи безпеки. Користувачі отримують спільний доступ до запису за посередництвом групи.

Безпека на рівні запису в Dataverse

Можливо ви спитаєте – що визначає доступ до запису? Це звучить як просте запитання, але для будь-якого користувача це комбінація всіх його ролей безпеки, бізнес-підрозділу, з яким вони пов’язані, команд, членами яких вони є, і записів, які з ними надсилаються. Головне пам'ятати, що доступ, це сума всіх цих понять в рамках середовища бази даних Dataverse. Ці умови обслуговування надаються тільки в одній базі даних і окремо відстежуються в кожній базі даних Dataverse. Для цього потрібно мати належну ліцензію для доступу до Dataverse.

Безпека на рівні стовпців у Dataverse

Іноді контроль доступу на рівні записів недостатній для деяких бізнес-сценаріїв. Dataverse має функцію безпеки на рівні стовпців, що дає змогу точніше керувати системою безпеки. Безпеку на рівні стовпців можна ввімкнути для всіх настроюваних і більшості системних стовпців. Більшість системних стовпців, які містять персональні дані, можна захистити індивідуально. Метадані кожного стовпця визначають, чи є це доступним параметром для системного стовпця.

Безпека на рівні стовпців вмикається для кожного стовпця окремо. Потім для керування доступом створюється профіль безпеки стовпців. Профіль містить усі стовпці, для яких увімкнуто безпеку на рівні стовпців, а також доступ, наданий цим конкретним профілем. Кожен стовпець можна контролювати в профілі для доступу до створення, оновлення та перегляду. Профілі захисту стовпців прив’язуються до користувачів чи робочих груп і надають користувачам відповідні права в доступних для них записах. Важливо зазначити, що безпека на рівні стовпців не має нічого спільного з безпекою на рівні записів. У користувача вже має бути доступ до запису, щоб профіль безпеки стовпців міг надати йому будь-який доступ до стовпців. Безпеку на рівні стовпців слід використовувати за потреби, оскільки надмірне використання може додати накладні витрати, які завдають шкоди.

Керування безпекою в декількох середовищах

Рішення Dataverse дають змогу упаковувати ролі безпеки та профілі захисту стовпців, а також переміщати їх між середовищами. Підрозділи та робочі групи потрібно створювати та адмініструвати окремо в кожному середовищі (включно з призначенням користувачів на необхідні компоненти безпеки).

Налаштування безпеки середовища користувачів

Коли в середовищі створюються ролі, робочі групи та організаційні одиниці, саме час призначити користувачам відповідні конфігурації безпеки. Спочатку під час створення користувача його слід зв'язати з організаційною одиницею. За замовчуванням обирається кореневий підрозділ установи. Вони також додаються до робочої групи цієї організаційної одиниці за замовчуванням.

Клієнту призначаються необхідні ролі безпеки. А також участь у необхідних робочих групах. Пам'ятайте, що у робочих груп також можуть бути ролі безпеки, тому ефективні права користувача — це поєднання безпосередньо призначених ролей безпеки з ролями групи, учасником якої є цей користувач. Система безпеки завжди надає користувачам найбільший обсяг обслуговування згідно їх прав доступу. Нижче наводиться гарна покрокова інструкція з налаштування системи безпеки середовища.

Якщо в системі використовувалася безпека на рівні стовпців, слід зв’язати користувача або робочу групу користувача з одним із створених профілів безпеки стовпців.

Безпека – це складна стаття, і найкраще її досягати спільними зусиллями розробників додатків і команди, яка адмініструє дозволи користувачів. Будь-які суттєві зміни слід погоджувати задовго до їх розгортання в середовищі.

Статті за темою

Налаштування безпеки середовища
Ролі та привілеї безпеки