Концепції безпеки в Microsoft Dataverse
Одна з ключових особливостей Dataverse, це багатофункціональна модель системи безпеки, здатна пристосовуватись до широкого спектру ділових сценаріїв. Ця модель системи безпеки використовується лише при наявності в середовищі бази даних Dataverse. Адміністратору, найімовірніше, не доведеться будувати модель повністю. Проте, йому потрібно буде приймати участь в керуванні користувачами, забезпеченні правильної конфігурації користувачів, та розв'язанні проблем з доступом.
Чайові
Перегляньте наступне відео: Microsoft Dataverse – Концепції безпеки, показані в демонстраціях.
Система безпеки на основі ролей.
Dataverse використовує безпеку на основі ролей для створення набору прав. Ці ролі безпеки можна призначити безпосередньо користувачам, або робочим групам та організаційним підрозділам Dataverse. Користувачів можна додати до команди. Таким чином, всі користувачі в команді будуть користуватись певною роллю. Важливо розуміти, що в Dataverse надані права доступу накопичуються, і користувачу надається найширший можливий доступ. Якщо ви надали право на читання на рівні доступу всієї організації до всіх записів контактних осіб, ви не зможете повернутися та приховати один запис.
Організаційні одиниці
Порада
Перегляньте наступне відео: Модернізація бізнес-одиниць.
Організаційні одиниці працюють з ролями безпеки для визначення ефективної безпеки користувача. Організаційні підрозділи — це стандартні блоки моделювання системи безпеки, що полегшують керування користувачами та тим, до яких даних у них є доступ. Організаційні підрозділи визначають периметр системи безпеки. Кожна база даних Dataverse має один кореневий організаційний підрозділ.
Ви можете створювати дочірні підрозділи для подальшого розподілення користувачів та даних. Кожен користувач, призначений середовищу, належатиме до певного підрозділу. Підрозділи можуть точно повторювати структуру ієрархії установи, але частіше вони просто задають периметри системи безпеки для виконання вимог моделі.
Щоб краще зрозуміти, розгляньмо приклад. Дано: три організаційні підрозділи. Woodgrove — кореневий підрозділ. Завжди знаходиться на верху ієрархії, перемістити його не можна. Ми створили два інші дочірні підрозділи A та B. У користувачів у цих організаційних одиницях дуже різні потреби доступу. Під час пов’язання користувача з цим середовищем ми можемо додати його до одного з цих трьох підрозділів. Підрозділ, до якого додано користувача стає відповідальним за записи, за які відповідає сам користувач. Подібна асоціація дає змогу налаштувати роль безпеки користувача, щоб він бачив усі записи підрозділу.
Ієрархічна структура доступу до даних
Клієнти можуть використовувати організаційну структуру, в якій дані та користувачі розташовуються в деревоподібній ієрархії.
Коли ми пов’язуємо користувача з цим середовищем, ми можемо вказати для користувача приналежність до однієї з цих трьох підрозділів і призначити йому роль безпеки з підрозділу. Організаційна одиниця, із якою зв'язаний користувач, визначає, яка організаційна одиниця відповідає за записи, які створюватиме користувач. Завдяки такому зв'язку ми можемо пристосувати роль безпеки, яка дозволить користувачеві бачити записи в цій організаційної одиниці.
Користувач А пов'язаний із Відділенням А й отримує роль безпеки Y з Відділення А. Це дозволяє користувачу А отримати доступ до записів Контактна особа №1 та Контактна особа №2. Хоча користувач Б у Відділенні Б не має доступу до записів контактних осіб відділення А, він має доступ до запису Контактної особи №3.
Матрична структура доступу до даних (модернізовані підрозділи)
Клієнти можуть використовувати організаційну структуру, в якій дані розподіляються в подібної до дерева ієрархії, а користувачі можуть отримувати доступ й працювати із даними з будь-якої організаційної одиниці, незалежно від того, до якої організаційної одиниці призначено певного користувача.
Під час пов’язання користувача з цим середовищем ми можемо додати його до одного з цих трьох підрозділів. Для кожної організаційної одиниці, до даних з якої потрібно отримати доступ, користувачеві призначається роль безпеки. Під час створення запису користувачем він може передати відповідальність за цей запис організаційній одиниці.
Користувач А може бути пов'язаний із будь-якими організаційними одиницями, включно із кореневою організаційною одиницею. Роль безпеки Y з Відділення А призначається користувачеві А, і надає цьому користувачеві доступ до записів Контактна особа №1 та Контактна особа №2. Роль безпеки Y з Відділення Б призначається користувачеві А, і надає цьому користувачеві доступ до запису Контактна особа №3.
Увімкнення матричної структури доступу до даних
Нотатка
Перш ніж увімкнути цю функцію, ви маєте опублікувати всі настроювання, щоб усі нові неопубліковані таблиці підтримували цю функцію. Якщо ви виявите в себе неопубліковані таблиці, які не працюють з цією функцією після її ввімкнення, задайте параметр RecomputeOwnershipAcrossBusinessUnits за допомогою засобу OrgDBOrgSettings для Microsoft Dynamics CRM. Встановлення для параметра RecomputeOwnershipAcrossBusinessUnits значення true дозволяє встановити та оновити поле Owning Business Unit . ...
- Виконайте вхід до центру адміністрування Power Platform як адміністратор (адміністратор Dynamics 365, глобальний адміністратор або адміністратор Microsoft Power Platform).
- Перейдіть на вкладку Середовища та виберіть середовище, для якого потрібно ввімкнути цю функцію.
- Виберіть елементи Настройки>Продукт>Функції.
- Увімкніть перемикач Відповідальність за запис в організаційних одиницях.
Після увімкнення цього перемикача можна вибрати організаційну одиницю при призначенні ролі безпеки користувачеві. Це дасть змогу призначати користувачу роль безпеки з різних підрозділів. Користувачу також потрібна роль безпеки від підрозділу, якому призначено користувача з правами на налаштування користувачів для запуску модельних програм. Ви можете звернутися до ролі безпеки Базовий користувач, щоб дізнатися, як активуються ці права на налаштування користувачів.
Ви можете призначити користувача відповідальним за запис у будь-якому підрозділі, не призначаючи роль безпеки в підрозділі, що володіє записом, якщо у користувача є роль безпеки з правом читання таблиці записів. Див. розділ Призначення відповідального за запис у модернізованих підрозділах.
Нотатка
Цей перемикач функції зберігається в параметрі EnableOwnershipAcrossBusinessUnits і може бути встановлений за допомогою засобу OrgDBOrgSettings для Microsoft Dynamics CRM.
Пов’язування бізнес-підрозділу з групою Microsoft Entra безпеки
Ви можете використовувати групу безпеки, щоб скласти карту свого бізнес-підрозділу Microsoft Entra для оптимізації адміністрування користувачів і призначення ролей.
Створіть групу безпеки для кожного бізнес-підрозділу Microsoft Entra та призначте відповідну бізнес-одиницю роль безпеки кожній команді групи.
Для кожної структурної одиниці створіть групу Microsoft Entra безпеки. Створіть групову команду Dataverse для кожної Microsoft Entra групи безпеки. Призначте відповідні роль безпеки з підрозділу кожній груповій робочій групі Dataverse . Користувача на наведеній вище схемі буде створено в кореневому підрозділі, коли користувач отримає доступ до середовища. Це нормально, коли користувач і групова робоча група Dataverse перебувають у кореневому підрозділі. У них є доступ лише до даних у підрозділі, якому призначено роль безпеки.
Додайте користувачів до відповідної Microsoft Entra групи безпеки, щоб надати їм доступ до бізнес-одиниці. Користувачі можуть одразу запустити програму та отримати доступ до його ресурсів і даних.
У матричному доступі до даних, де користувачі можуть працювати та отримувати доступ до даних із кількох бізнес-одиниць, додайте користувачів до Microsoft Entra груп безпеки, які зіставлені з цими бізнес-одиницями.
Відповідальний підрозділ
Кожен запис має стовпець «Бізнес-одиниця-власник», який визначає, якій структурній одиниці належить запис. Під час створення запису в цьому стовпці за замовчуванням використовується підрозділ користувача, і це значення не можна змінити, крім випадків, коли перемикач цієї функції ввімкнуто.
Нотатка
Коли ви змінюєте, якій структурній одиниці належить запис, обов’язково ознайомтеся з наведеною нижче інформацією про каскадні ефекти: Використання пакета SDK для .NET для настроювання каскадної поведінки.
Ви можете зазначити, чи хочете дозволити користувачу задавати значення стовпця «Відповідальний підрозділ», якщо цю функцію ввімкнуто. Щоб налаштувати стовпець «Відповідальний підрозділ», вам необхідно надати ролі безпеки користувача право Додавання до з дозволом локального рівня.
Щоб дозволити користувачу встановлювати цей стовпець, можна ввімкнути його таким чином:
- Форма — і в основному тексті, і у верхньому колонтитулі.
- Подання.
- Зіставлення стовпців. Якщо використовується AutoMapEntity, стовпець можна вказати в зіставленні стовпців.
Нотатка
Якщо у вас є завдання або процес для синхронізації даних між середовищами, а Відповідальний підрозділ додається до складу схеми, це завдання не вдасться виконати, і відобразиться повідомлення про порушення обмеження Зовнішнього ключа, якщо значення Відповідальний підрозділ у цільовому середовищі відрізняється.
Ви можете видалити стовпець Відповідальний підрозділ зі схеми джерела або змінити значення поля Відповідальний підрозділ у джерелі на будь-який підрозділ у цільовому середовищі.
Якщо у вас є завдання або процес для копіювання даних із середовища до зовнішнього ресурсу, наприклад PowerBI, потрібно буде вибрати або скасувати вибір стовпця Відповідальний підрозділ у джерелі. Виберіть це поле, якщо ресурс здатен його прийняти та обробити, в іншому випадку скасуйте вибір.
Відповідальний за таблицю або запис
Dataverse підтримує два типи відповідальності за запис. Відповідальність організації та відповідальність користувача або команди. Це вибір, який виконується під час створення таблиці, і його не можна змінити. З міркувань безпеки для записів, за які відповідає організація, можна вибрати тільки один варіант рівня доступу: може користувач виконувати операцію, чи ні. Для записів, за які відповідає робоча група або користувач, варіантами рівня доступу для більшості прав є: організація, організаційна одиниця, організаційна одиниця та дочірня організаційна одиниця або лише власні записи користувача. Тобто, якщо поставити право перегляду контактних осіб на рівень «Користувач», то користувач зможе переглядати лише власні записи.
Ще один приклад. Скажімо, користувач пов'язаний з відділом а, і ми призначаємо рівень доступу «підрозділ» для перегляду контактних осіб. Тоді можна переглядати Контакт №1 і Контакт №2, але не Контакт №3.
У разі настроювання права ролі безпеки доступу настроюється рівень доступу для кожного параметра. Нижче наведено приклад редактора прав Ролей безпеки.
У вищенаведених розділах можна переглянути стандартні типи прав для кожної таблиці: створення, читання, записування, видалення, додавання, додавання до, призначення та спільний доступ. Кожний тип можна редагувати окремо. Візуальне відображення для кожного з них збігатимуться з ключовим елементом нижче, до якого надано доступ.
У наведеному вище прикладі ми надали доступ на рівні організації до Контактних осіб, тобто користувач у відділі А зможе переглядати та оновлювати контактні особи будь-кого в системі. Власне, одна з найпоширеніших помилок адміністратора, це надання надмірного доступу через роздратування від системи дозволів. І дуже швидко елегантна модель системи безпеки стає схожою на решето.
Призначення відповідального за запис у модернізованих підрозділах
У модернізованих підрозділах користувачі можуть бути відповідальними за записи будь-яких підрозділів. Усе, що потрібно користувачам, – це роль безпеки (будь-який підрозділ) з правом на читання таблиці записів. Користувачам не потрібно призначати роль безпеки в кожному підрозділі, де є запис.
Якщо параметр Призначення відповідального за запис у підрозділах було ввімкнуто у вашому робочому середовищі протягом періоду підготовчої версії, вам необхідно ввімкнути призначення відповідального за запис у підрозділі. Щоб зробити це, виконайте такі дії:
- Інсталюйте Редактор параметрів організації
- Установіть для параметрів організації RecomputeOwnershipAcrossBusinessUnits значення true. Якщо для цього параметра встановлено значення true, система блокується, і повторне обчислення може зайняти до 5 хвилин, щоб увімкнути можливість, за допомогою якої користувачі тепер можуть володіти записами між бізнес-одиницями без необхідності призначати окремі роль безпеки від кожного бізнес-підрозділу. Це дає змогу власнику запису призначити свій запис будь-якій особі, яка не є власником запису.
- Установіть для параметра AlwaysMoveRecordToOwnerBusinessUnit значення false. У результаті якщо власника запису буде змінено, запис залишиться у вихідному відповідальному підрозділі.
Для всіх невиробничих середовищ потрібно просто встановити для параметра AlwaysMoveRecordToOwnerBusinessUnit значення false, щоб використовувати цю можливість.
Нотатка
Якщо за допомогою інструмента OrgDBOrgSettings для CRM вимкнути функцію Записувати право власності між бізнес-одиницями або встановити значення false для параметра RecomputeOwnershipAcrossBusinessUnits , ви не зможете встановити Microsoft Dynamics або оновитиполе Власник бізнес-одиниці, а всі записи, у яких поле Ownering Business Unit відрізняється від поля власника, буде оновлено до бізнес-одиниці власника.
Робочі групи (включно з груповими робочими групами)
Робочі групи, це ще один важливий елемент безпеки. За робочі групи відповідає підрозділ. Кожен підрозділ має одну робочу групу за замочуванням, створено автоматично при створенні самого підрозділу. Учасники цієї групи (за замовчуванням, всі користувачі приписані до підрозділу) керуються Dataverse. До робочої групи за замовчуванням не можна вручну додавати учасників, чи видаляти їх. Система автоматично регулює список учасників, коли користувачі зв’язуються із підрозділами або виходять з їх складу. Існує два типи робочих груп: відповідальні групи та групи доступу.
- Відповідальні робочі групи можуть мати власні записи, прямий доступ до яких надається будь-якому учаснику робочої групи. Користувачі можуть входити в кілька робочих груп. Це дозволяє надавати користувачам широкий доступ, при цьому не налаштовуючи доступ для кожного користувача окремо.
- Робочі групи доступу розглядаються в наступному розділі у контексті спільного доступу до записів.
Надання спільного доступу до записів
Окремими записами можна ділитися по черзі з іншим користувачем. Це потужний спосіб обробки винятків, які не належать до запису або є частиною моделі доступу до бізнес-одиниці. Однак це має бути винятком, оскільки це менш ефективний спосіб контролю доступу. Спільний доступ важче виправити, оскільки він не є послідовно реалізованим контролем доступу. Спільний доступ можна виконати на рівні користувача або робочої групи. Надання спільного доступу робочій групі ефективніше. Більш просунута концепція спільного доступу полягає в Access Teams, яка забезпечує автоматичне створення команди, а спільне використання доступу до записів з командою базується на шаблоні команди Access (шаблоні дозволів), який застосовується. Команди Access також можна використовувати без шаблонів, просто вручну додаючи або видаляючи їх учасників. Команди доступу більш продуктивні, оскільки самі команди не можуть відповідати за записи чи мати ролі системи безпеки. Користувачі отримують спільний доступ до запису за посередництвом групи.
Безпека на рівні запису в Dataverse
Можливо ви спитаєте – що визначає доступ до запису? На перший погляд просте запитання, але доступ кожного користувача це поєднання всіх його ролей безпеки, підрозділів та робочих груп до яких він належить, та записів до яких він має спільний доступ. Головне пам'ятати, що доступ, це сума всіх цих понять в рамках середовища бази даних Dataverse. Ці умови обслуговування надаються тільки в одній базі даних і окремо відстежуються в кожній базі даних Dataverse. Для цього потрібно мати належну ліцензію для доступу до Dataverse.
Безпека на рівні стовпців у Dataverse
В деяких бізнес-сценаріях керування доступом на рівні запису недостатньо. Dataverse має функцію безпеки на рівні стовпців, що дає змогу точніше керувати системою безпеки. Безпеку на рівні стовпців можна ввімкнути для всіх настроюваних і більшості системних стовпців. Більшість системних стовпців, які містять персональні дані, можна захистити індивідуально. Метадані кожного стовпця визначають, чи є це доступним параметром для системного стовпця.
Безпека на рівні стовпців вмикається для кожного стовпця окремо. Потім для керування доступом створюється профіль безпеки стовпців. Профіль містить усі стовпці, для яких увімкнуто безпеку на рівні стовпців, а також доступ, наданий цим конкретним профілем. Кожен стовпець можна контролювати в профілі для доступу до створення, оновлення та перегляду. Профілі захисту стовпців прив’язуються до користувачів чи робочих груп і надають користувачам відповідні права в доступних для них записах. Важливо зазначити, що безпека на рівні стовпців не має нічого спільного з безпекою на рівні записів. У користувача вже має бути доступ до запису, щоб профіль безпеки стовпців міг надати йому будь-який доступ до стовпців. Безпеку на рівні стовпців слід використовувати за потреби, оскільки надмірне використання може додати накладні витрати, які завдають шкоди.
Керування безпекою в декількох середовищах
Рішення Dataverse дають змогу упаковувати ролі безпеки та профілі захисту стовпців, а також переміщати їх між середовищами. Підрозділи та робочі групи потрібно створювати та адмініструвати окремо в кожному середовищі (включно з призначенням користувачів на необхідні компоненти безпеки).
Налаштування безпеки середовища користувачів
Коли в середовищі створюються ролі, робочі групи та організаційні одиниці, саме час призначити користувачам відповідні конфігурації безпеки. Спочатку під час створення користувача його слід зв'язати з організаційною одиницею. За замовчуванням обирається кореневий підрозділ установи. Вони також додаються до робочої групи цієї організаційної одиниці за замовчуванням.
Клієнту призначаються необхідні ролі безпеки. А також участь у необхідних робочих групах. Пам'ятайте, що у робочих груп також можуть бути ролі безпеки, тому ефективні права користувача — це поєднання безпосередньо призначених ролей безпеки з ролями групи, учасником якої є цей користувач. Система безпеки завжди надає користувачам найбільший обсяг обслуговування згідно їх прав доступу. Нижче наводиться гарна покрокова інструкція з налаштування системи безпеки середовища.
Якщо в системі використовувалася безпека на рівні стовпців, слід зв’язати користувача або робочу групу користувача з одним із створених профілів безпеки стовпців.
Безпека — це складне завдання, яке найефективніше виконується у взаємодії розробників програм і робочої групи, яка керує дозволами користувачів. Будь-які суттєві зміни слід погоджувати задовго до їх розгортання в середовищі.