Нотатка
Доступ до цієї сторінки потребує авторизації. Можна спробувати ввійти або змінити каталоги.
Доступ до цієї сторінки потребує авторизації. Можна спробувати змінити каталоги.
Dataverse надає гнучку модель безпеки для багатьох бізнес-сценаріїв. Модель застосовується лише до середовищ, у яких є база даних Dataverse. Адміністратор керує користувачами, перевіряє їх конфігурацію безпеки та усуває проблеми з доступом.
Чайові
Дивитися Microsoft Dataverse – поняття безпеки, показані в демонстраціях.
Система безпеки на основі ролей.
Dataverse Використовує ролі безпеки для групування привілеїв. Призначте ролі безпеки безпосередньо користувачам або командам Dataverse. Учасники групи отримують права, призначені команді.
Права безпеки сукупні. Користувач отримує найширший доступ, наданий для всіх своїх ролей і членства в команді. Наприклад, якщо одна роль надає доступ організації на рівні читання до всіх записів контактів, інша роль не може приховати певний контакт від користувача.
Організаційні одиниці
Перегляньте це відео, щоб зрозуміти підрозділи в Dataverse:
Підрозділи працюють із ролями безпеки, щоб визначити доступ користувача. Вони визначають межі безпеки, які допомагають керувати користувачами та даними. Кожна база даних містить одну кореневу робочу одиницю.
Створіть дочірні підрозділи , щоб розділити користувачів і дані на менші межі безпеки. Кожен користувач у середовищі належить до підрозділу. Структура підрозділів може відповідати ієрархії організації, але не обов'язково.
У наведених нижче прикладах використовуються три бізнес-одиниці. Woodgrove є кореневою бізнес-одиницею і залишається у верхній частині ієрархії. Підрозділи A та B – це дочірні підрозділи. Користувачі кожного підрозділу мають різні потреби в доступі.
Ієрархічна структура доступу до даних
Використовуйте ієрархічну структуру, щоб розділяти користувачів і дані в ієрархії, подібній до дерева.
Призначте кожному користувачу одну робочу одиницю та призначте користувачу роль безпеки з цього підрозділу. За замовчуванням підрозділ користувача володіє записами, які створює користувач. Роль безпеки визначає, до яких записів користувач може отримати доступ у цій робочій одиниці.
У цьому прикладі користувач A належить до підрозділу A та має роль безпеки Y від підрозділу A. Користувач A може отримати доступ до контактів #1 і контакту #2. Користувач Б належить до підрозділу B, тому користувач Б не може отримати доступ до контактів підрозділу А, але може отримати доступ до контакту #3.
Структура доступу до даних матриці (модернізовані бізнес-одиниці)
Використовуйте структуру матриці, щоб упорядковувати дані в ієрархії, подібній до дерева, надаючи користувачам доступ до даних у кількох підрозділах незалежно від підрозділу, до якого вони належать.
Призначте користувачу роль безпеки з кожного підрозділу, до даних якого потрібно отримати доступ. Коли користувач створює запис, він може вибрати робочу одиницю, яка його володіє.
У цьому прикладі користувач A може належати до будь-якої робочої одиниці, включно з кореневою робочою одиницею. Роль безпеки Y відділу A надає користувачу доступ до контактів #1 і контакту #2. Роль безпеки Y відділу B надає користувачу доступ до контакту #3.
Увімкнення структури доступу до даних матриці
Нотатка
Перш ніж активувати цю функцію, опублікуйте всі настроювання, щоб ця функція застосовується до нових таблиць. Якщо неопублікована таблиця не працює після ввімкнення цієї функції, скористайтеся інструментом OrgDBOrgSettings для Microsoft Dynamics CRM, щоб установити для параметра RecomputeOwnershipAcrossBusinessUnits значення true. Цей параметр дає змогу встановити та оновити стовпець "Власна одиниця бізнесу ".
- Увійдіть у Центр адміністрування Power Platform як адміністратор Dynamics 365 або адміністратор Microsoft Power Platform.
- В області переходів виберіть Керування .
- В області Керування виберіть пункт Середовища, а потім виберіть середовище.
- Виберіть елементи Настройки>Продукт>Функції.
- Увімкніть параметр "Записувати право власності на будь-які підрозділи".
- Виберіть Зберегти.
Після ввімкнення функції виберіть підрозділ, коли призначається роль безпеки користувачу. Цей параметр дає змогу призначити користувачам ролі з різних підрозділів. Щоб запускати програми на основі моделі, користувачу також потрібна роль із власного підрозділу, який містить необхідні права на настройки користувача. У ролі "Основний користувач " відображаються права на параметри користувача, які потрібно ввімкнути.
Ви можете зробити користувача власником запису в будь-якій робочій одиниці, якщо одна з їхніх ролей безпеки надає право читання для таблиці запису. Користувачу не потрібна роль безпеки з підрозділу, що належить запису. Докладні відомості див . в статті Записування права власності на модернізовані підрозділи.
Нотатка
Параметр EnableOwnershipAcrossBusinessUnits зберігає стан цієї функції. Ви також можете змінити цей параметр за допомогою інструмента OrgDBOrgSettings для Microsoft Dynamics CRM.
Пов’язування бізнес-одиниці з групою Microsoft Entra безпеки
Зіставте підрозділи, щоб Microsoft Entra групи безпеки, щоб спростити керування користувачами та призначення ролей.
Для кожної одиниці:
- Створення групи безпеки Microsoft Entra.
- Створіть групу Dataverse для групи безпеки.
- Призначте роль безпеки підрозділу групі Dataverse.
- Додавання користувачів до групи безпеки Microsoft Entra.
Коли користувач вперше має доступ до середовища, Dataverse створює користувача в кореневій робочій одиниці. Групи користувачів і груп Dataverse можуть залишатися в кореневій робочій одиниці. Призначені їм ролі безпеки надають доступ до даних у відповідних підрозділах.
Щоб отримати доступ до даних матриці, додайте користувачів до групи безпеки Microsoft Entra для кожного підрозділу, до якого їм потрібно отримати доступ.
Володіння підрозділом
Кожен запис має стовпець "Власна бізнес-одиниця ", який визначає підрозділ, який володіє записом. Коли користувач створює запис, стовпець за замовчуванням використовується для підрозділу користувача. Значення можна змінити, лише якщо ввімкнуто параметр Записувати право власності на підрозділи .
Нотатка
Змінення організаційної одиниці може призвести до каскадних змін. Докладні відомості див. в статті Налаштування каскадної поведінки за допомогою SDK для .NET.
Щоб користувач установив стовпець "Власний підрозділ ", надайте користувачу роль безпеки "Додавання до " локального рівня для таблиці "Підрозділ".
Додайте стовпець до:
- Основний або верхній колонтитул форми.
- Подання.
- Зіставлення стовпців. Якщо використовується функція AutoMapEntity, додайте стовпець до зіставлення.
Нотатка
Якщо завдання синхронізації даних містить у схемі " Володіння підрозділом ", завдання не працює з порушенням обмеження зовнішнього ключа, якщо цільове середовище не містить однакове значення. Видаліть стовпець із вихідної схеми або змініть його вихідне значення на робочу одиницю, яка існує в цільовому середовищі.
Коли ви копіюєте дані до зовнішнього ресурсу, наприклад Power BI, додайте "Володіння підрозділом", лише якщо місце призначення підтримує стовпець.
Володіння таблицями та записами
Dataverse підтримує два типи володіння записами:
- Організація, що належить: Право застосовується до всіх записів або не застосовується.
- Користувач або група, що належать: Більшість прав підтримують користувачів, підрозділ, батьківсько-дочірній підрозділ і рівні доступу до організації.
Під час створення таблиці ви вибираєте тип власності та не зможете змінити її пізніше. Наприклад, доступ користувача для читання до таблиці контактів дає змогу користувачам читати лише записи контактів, якими вони володіють.
Якщо користувач A належить до підрозділу A та має доступ до таблиці контактів на рівні підрозділів, користувач A може прочитати контакт #1 і Контакт #2, але не контакт #3.
Коли ви налаштовуєте роль безпеки, виберіть рівень доступу для кожного з них.
Налаштуйте стандартні права таблиці окремо: "Створити", "Прочитати", "Записати", "Видалити", "Додати", "Додати до", "Призначити" та "Спільний доступ". Піктограма прав відображає наданий рівень доступу.
Відфільтровано право власності на запис таблиці (підготовча версія)
Підготовчі функції призначені для невиробничого використання й можуть бути обмежені. Ці функції доступні до офіційного випуску, щоб клієнти могли ознайомитися з ними заздалегідь і залишити відгуки.
Відфільтровані права власності на записи дають змогу адміністраторам керувати доступом до записів Dataverse за допомогою фільтрів значень стовпців. Наприклад, надати доступ лише до записів, у яких City стовпець дорівнює Redmond. Користувачі можуть створювати, читати, оновлювати та видаляти лише записи, які відповідають фільтрам у своїх ролях безпеки.
На відміну від традиційних таблиць Dataverse, таблиці з відфільтрованими правами власності на записи не підтримують право власності на записи, спільний доступ або призначення. Права на основі фільтрів керують доступом до записів і надають деталізований доступ на рівні рядків без обмеження таблиць, стовпців або інших об'єктів моделі.
Нотатка
Використовуйте відфільтровані права власності на записи на рівні рядків, які відповідають умовам фільтра. Застосування прав на основі фільтра до відфільтрованих таблиць володіння записами та наявних таблиць, що належать користувачу або організації. Для наявних таблиць цей підхід зберігає базову модель володіння.
Запис прав власності на модернізовані бізнес-одиниці
За допомогою модернізованих підрозділів користувачі можуть володіти записами в будь-якій робочій одиниці. Користувачу потрібна роль безпеки з будь-якого підрозділу, який надає права читання для таблиці запису. Користувачу не потрібна роль від кожної робочої одиниці, яка містить запис, яким він володіє.
Якщо ви ввімкнули параметр Записувати право власності на підрозділи у виробничому середовищі протягом підготовчого періоду, виконайте наведені нижче дії.
- Інсталюйте редактор настройок організації.
- Установіть для параметра RecomputeOwnershipAcrossBusinessUnits значення
true. Система блокується під час переобчислення, що може зайняти до п'яти хвилин. Після переобчислення користувачі можуть володіти записами в різних підрозділах без окремої ролі безпеки від кожного підрозділу. Власники записів також можуть призначати записи користувачам, які не належать до підрозділу запису. - Установіть для параметра AlwaysMoveRecordToOwnerBusinessUnit значення
false. Після цього записи залишаються у вихідному підрозділі, що належить компанії, коли змінюється право власності.
Для непродуктивних середовищ установіть для параметра AlwaysMoveRecordToOwnerBusinessUnit значення false.
Нотатка
Якщо вимкнути параметр "Записувати право власності на підрозділи " або встановити для параметра RecomputeOwnershipAcrossBusinessUnits значення false, не можна встановити або оновити стовпець "Одиниця власності ". Dataverse також змінює одиницю власності кожного запису, на який впливає проблема, відповідно до підрозділу власника запису.
Робочі групи (включно з груповими робочими групами)
Кожна команда належить до підрозділу. Dataverse автоматично створює стандартну команду для кожного підрозділу та керує її членством. Команда за замовчуванням завжди включає всіх користувачів у підрозділ. Додавати або видаляти його учасників вручну не можна. Dataverse update membership when you associate or disassociate users with the business unit.
Dataverse надає два типи команд:
- Команди власників можуть володіти записами. Кожен учасник команди отримує прямий доступ до записів команди. Користувач може належати до кількох команд власників.
- Команди Access надають доступ до спільних записів, але не володіють записами або не мають ролей безпеки.
Надання спільного доступу до записів
Надавайте спільний доступ до окремих записів користувачу або групі, щоб обробляти винятки, які не охоплюють модель вашого власника та підрозділу. Використовуйте спільний доступ лише для винятків, оскільки він працює менш ефективно і може бути важче виправити неполадки, ніж доступ на основі ролей. Надавати спільний доступ групі ефективніше, ніж надавати спільний доступ окремо кожному користувачу.
Використовуйте шаблон групи доступу, щоб автоматично створити команду доступу та визначити її дозволи для запису. Ви також можете створювати команди доступу без шаблону та керувати їхніми учасниками вручну. Команди Access не володіють записами та не можуть мати ролі безпеки. Учасники групи отримують доступ, оскільки до запису надано спільний доступ команді.
Безпека на рівні запису в Dataverse
Доступ до записів користувача поєднує всі їхні ролі безпеки, членство в підрозділах, членство в групах і спільні записи. Access є сукупним у базі даних Dataverse. Dataverse відстежує доступ окремо для кожної бази даних, і користувач повинен мати відповідну ліцензію Dataverse.
Безпека на рівні стовпців у Dataverse
Використовуйте захист на рівні стовпця, якщо безпека на рівні записів не забезпечує достатнього контролю. Увімкніть цей параметр для всіх настроюваних стовпців і більшості системних стовпців. Більшість системних стовпців, які містять особисті дані (PII), підтримують захист на рівні стовпця. Метадані системного стовпця вказують на те, чи можна його захистити.
Увімкніть захист на рівні стовпця окремо для кожного стовпця. Потім створіть профіль безпеки стовпця, який надає доступ до захищених стовпців: "Створення", "Оновлення" та "Читання". Призначте профіль користувачам або командам.
Безпека на рівні стовпця не надає доступ до запису. Щоб профіль безпеки стовпця міг надати доступ до захищених стовпців, користувач повинен мати доступ до записів. Використовуйте захист на рівні стовпця лише за потреби, оскільки надмірне використання може знизити продуктивність.
Керування безпекою в кількох середовищах
Використовуйте рішення Dataverse для переміщення ролей безпеки та профілів безпеки стовпців між середовищами. Створюйте бізнес-підрозділи та команди та керуйте ними окремо в кожному середовищі. Також потрібно призначити користувачів відповідним компонентам безпеки в кожному середовищі.
Налаштування безпеки користувачів
Створивши ролі, команди та підрозділи, налаштуйте доступ кожного користувача:
- Пов'яжіть користувача з підрозділом. Dataverse за замовчуванням використовує кореневу робочу одиницю та додає користувача до стандартної команди цього підрозділу.
- Призначте ролі безпеки, які потрібні користувачу.
- Додайте користувача до відповідних команд.
- Якщо використовується безпека на рівні стовпця, призначте профіль безпеки стовпця користувачу або одній із їхніх команд.
Ефективний доступ користувача поєднує безпосередньо призначені ролі безпеки з ролями, призначеними в командах. Dataverse завжди надає найширший дозвіл від цих ролей. Докладні покрокові вказівки див. в статті Настроювання безпеки середовища.
Координуйте основні зміни системи безпеки з розробниками програм і адміністраторами, які керують дозволами користувачів, перш ніж розгортати зміни.