Концепции за сигурност в Microsoft Dataverse

Една от основните характеристики на Dataverse е неговият богат модел на сигурност, който може да се адаптира към много сценарии за използване на бизнеса. Този модел на сигурност е в действие само когато има Dataverse база данни в средата. Като администратор най-вероятно няма да изграждате сами целия модел на защита, но често ще участвате в процеса на управление на потребителите и гарантиране, че те имат правилната конфигурация и отстраняване на проблеми, свързани със сигурността.

Бакшиш

Вижте следното видео: Microsoft Dataverse – Концепции за сигурност, показани в демонстрации.

Защита, базирана на права за достъп

Dataverse използва защитата на базата на роли, за да групира заедно колекция от привилегии. Тези роли на защита могат да бъдат свързани директно с потребителите или могат да бъдат свързани с тях екипи и бизнес звена на Dataverse. След това потребителите могат да бъдат свързани с екипа и следователно всички потребители, свързани с екипа, се възползват от ролята. Ключова концепция за разбиране на защитата на Dataverse е, че всички предоставяния на привилегии са натрупващи се с най-голямо количество преобладаващ достъп. Ако сте дали достъп за четене на широко ниво на организация до всички записи на контакти, не можете да се върнете и да скриете нито един запис.

Бизнес единици

Съвет

Вижте следното видео: Модернизиране на бизнес единиците.

Бизнес единиците работят с роли за сигурност, за да определят ефективната защита, която има потребителят. Бизнес единиците са изграждащ блок за моделиране на сигурността, който помага при управлението на потребителите и данните, до които те имат достъп. Бизнес единиците определят границата на сигурността. Всяка база данни на Dataverse има една коренова бизнес единица.

Можете да създадете дъщерни стопански единици, за да помогнете за по-нататъшното сегментиране на вашите потребители и данни. Всеки потребител, присвоен на среда, принадлежи към бизнес единица. Докато бизнес единиците могат да бъдат използвани за моделиране 1:1 на истинска организационна йерархия, по-често те се навеждат повече към точно определени граници на сигурност, за да помогнат за постигане на нуждите на модела за сигурност.

За да разберете по-добре, нека разгледаме следващия пример. Имаме три бизнес звена. Woodgrove е основната бизнес единица и винаги ще бъде на върха, което е непроменимо. Създадохме две други дъщерни бизнес единици А и Б. Потребителите в тези бизнес единици имат различни нужди от достъп. Когато свързваме потребител с тази среда, можем да настроим потребителя да бъде в едно от тези три бизнес звена. Къде е свързан потребителят определя коя бизнес единица притежава записите, на които потребителят е собственик. Наличието на тази асоциация ни позволява да приспособим роля на защита, за да позволи на потребителя да вижда всички записи в тази бизнес единица.

Йерархична структура за достъп до данни

Клиентите могат да използват организационна структура, където данните и потребителят са разделени в дървовидна йерархия.

Когато свързваме потребител с тази среда, можем да настроим потребителя да бъде в една от тези три бизнес единици и да присвоим на потребителя права за достъп от бизнес единицата. Бизнес единицата, с която е свързан потребителят, определя коя бизнес единица притежава записите, когато потребителят създава запис. Чрез тази асоциация ни позволява да приспособим права за достъп, която позволява на потребителя да вижда записи в тази бизнес единица.

Потребител А е свързан с Отдел А и му е присвоен права за достъп Y от Отдел А. Това позволява на потребител А да получи достъп до записите Контакт #1 и Контакт #2. Докато потребител Б в Дивизия Б няма достъп до записите на контактите на Отдел А, но има достъп до запис на Контакт #3.

Матрична структура за достъп до данни (Модернизирани бизнес единици)

Клиентите могат да използват организационна структура, където данните са разделени в дървовидна йерархия, а потребителите могат да работят и да имат достъп до данните на всяка бизнес единица, независимо от това към коя бизнес единица е назначен потребителят.

Когато свързваме потребител с тази среда, можем да настроим потребителя да бъде в едно от тези три бизнес звена. За всяка бизнес единица, която потребителят се нуждае за достъп до данни, права за достъп от тази бизнес единица се присвоява на потребителя. Когато потребителят създава запис, той може да настрои бизнес единицата да притежава записа.

Потребител А може да бъде свързан с някоя от бизнес единиците, включително основната бизнес единица. A права за достъп Y от Отдел А е присвоено на потребител А, което дава на потребителя достъп до записите Контакт #1 и Контакт #2. A права за достъп Y от Отдел B е присвоено на потребител А, което дава на потребителя достъп до записа на Контакт #3.

Активиране на структурата за достъп до данни на матрицата

Бележка

Преди да активирате тази функция, трябва да публикувате всички ваши персонализации, за да активирате всичките си нови непубликувани таблици за функцията. Ако установите, че имате непубликувани таблици, които не работят с тази функция, след като сте я включили, можете да зададете настройката RecomputeOwnershipAcrossBusinessUnits с помощта на Инструмент OrgDBOrgSettings за Microsoft Dynamics CRM. Задаването на RecomputeOwnershipAcrossBusinessUnits на true позволява полето Owning Business Unit да бъде зададено и актуализирано.

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 за конфигуриране на каскадно поведение.

Можете да управлявате дали искате да разрешите на потребителя да зададе колоната „Притежаване на бизнес единица“, когато превключвателят на функциите е ВКЛЮЧЕН. За да зададете колоната Собственик на бизнес единица, трябва да предоставите на ролята за сигурност на потребителя привилегията Присъединяване към на таблицата Business Unit (Бизнес единица) с разрешение на локално ниво.

За да позволите на потребителя да задава тази колона, можете да я активирате по следния начин:

1. Форма - както тялото, така и заглавката.
2. Преглеждане.
3. Съпоставяне на колони. Ако използвате AutoMapEntity, можете да зададете колоната в съпоставянето на колони.

Бележка

Ако имате работа/процес за синхронизиране на данни между среди и Притежаване на бизнес единица е включен като част от схемата, вашата работа ще се провали с Чужд КЛЮЧ нарушение на ограничението, ако целевата среда няма същото Притежаване на бизнес единица стойност.

Можете или да премахнете колоната Притежаване на бизнес единица от изходната схема или актуализирайте Притежаване на бизнес единица стойност на колоната на източника към която и да е от бизнес единиците на целта.

Ако имате задача/процес за копиране на данни от среда към външен ресурс, например PowerBI, ще трябва да изберете или премахнете избора от колоната Притежаване на бизнес единица от вашия източник. Изберете го, ако вашият ресурс може да го получи, в противен случай премахнете избора му.

Собственост на таблица/запис

Dataverse поддържа два вида собственост на записи. Притежавани от организация и притежавани от потребител или екип. Това е избор, който се случва в момента на създаване на таблицата и не може да бъде променен. От съображения за сигурност, записите, които са собственост на организацията, единственият избор на ниво достъп е или потребителят може да извърши операцията, или не. За записите, притежавани от потребители и екип, изборът на ниво достъп за повечето привилегии е многостепенна организация, бизнес единица, бизнес единица и дъщерна бизнес единица или само собствените записи на потребителя. Това означава, че привилегията за четене при контакт можех да определя собственост на потребителя и потребителят да вижда само собствените си записи.

За да дадем друг пример, нека да кажем, че Потребител A е свързан с отдел A, и ние им даваме ниво на бизнес единица за достъп за четене при контакт. Те биха могли да видят Контакт №1 и №2, но не и Контакт №3.

Когато конфигурирате или редактирате привилегии права за достъп, вие задавате нивото на достъп за всяка опция. Следва пример за редактора на привилегии на роля на защита.

В горното можете да видите стандартните типове привилегии за всяка таблица Създаване, четене, писане, изтриване, добавяне, добавяне към, присвояване и споделяне. Можете да редактирате всеки от тях поотделно. Визуалното показване на всеки ще съответства на клавиша по-долу за нивото на достъп, което сте предоставили.

В горния пример ние предоставихме на ниво организация достъп до контакт, което означава, че потребителят в отдел A може да вижда и актуализира контакти, притежавани от всеки. Всъщност една от най-често срещаните административни грешки е разочарованието от разрешения и малко над предоставяне на достъп. Много бързо един добре изработен модел за сигурност започва да изглежда като швейцарско сирене (пълно с дупки!).

Регистриране на собствеността в модернизирани бизнес единици

В Модернизирани бизнес единици можете да имате потребители да бъдат собственици на записи във всички бизнес единици. Всичко, от което се нуждаят потребителите, е права за достъп (всяка бизнес единица), която има привилегия за четене на таблицата със записи. Не е необходимо потребителите да имат присвоен права за достъп във всяка бизнес единица, където се намира записът.

Ако Собствеността на записи между бизнес единици е била активирана във вашата производствена среда по време на периода на визуализация, трябва да изпълните следното, за да активирате тази собственост на записи в бизнес единица:

1. Инсталиране на редактора на настройките на организацията
2. Задайте настройките на организацията RecomputeOwnershipAcrossBusinessUnits на true. Когато тази настройка е зададена на true, системата е заключена и може да отнеме до 5 минути, за да извърши преизчислението, за да активира възможността, при която потребителите вече могат да притежават записи в бизнес единици, без да е необходимо да имат отделна права за достъп, присвоена от всяка бизнес единица. Това позволява на собственика на записа да присвои своя запис на някой извън бизнес единицата собственик на записа.
3. Задайте AlwaysMoveRecordToOwnerBusinessUnit на false. Това кара записа да остане в първоначалната притежаваща бизнес единица, когато собствеността на записа бъде променена.

За всички непроизводствени среди просто трябва да зададете AlwaysMoveRecordToOwnerBusinessUnit на false, за да използвате тази възможност.

Бележка

Ако изключите или функцията за собственост на запис в бизнес единици, или зададете настройката RecomputeOwnershipAcrossBusinessUnits на false с помощта на инструмента OrgDBOrgSettings за Microsoft Dynamics CRM, няма да можете да зададете или актуализирате полето Притежаване на бизнес единица и всички записи, където полето Притежаваща бизнес единица е различно от бизнес единицата на собственика, ще бъдат актуализирани до бизнес единицата на собственика.

Екипи (включително групови отбори)

Екипите са друг важен блок за сигурност. Екипите са собственост на бизнес звено. Всяко бизнес звено има един екип по подразбиране, който се създава автоматично, когато е създаден бизнес единицата. Членовете на екипа по подразбиране се управляват от Dataverse и винаги съдържа всички потребители, свързани с този бизнес единица. Не можете ръчно да добавяте или премахвате членове от екипа по подразбиране, те се настройват динамично от системата, тъй като новите потребители се асоциират/дисасоциират с бизнес единици. Има два типа екипи, притежаващи екипи и екипи за достъп.

• Притежаването на екипи може да притежава записи, които дават на всеки член на екипа директен достъп до този запис. Потребителите могат да бъдат членове на множество екипи. Това ще позволи да бъде мощен начин за предоставяне на разрешения на потребителите по широк начин, без да управлявате микроуправление достъпа на индивидуално потребителско ниво.
• Екипите за достъп са обсъдени в следващия раздел като част от споделянето на записи.

Споделяне на записи

Отделните записи могат да се споделят един по един с друг потребител. Това е мощен начин за обработка на изключения, които не попадат в собствеността на записа или са член на модел за достъп до бизнес единици. Това обаче трябва да бъде изключение, защото това е по-малко ефективен начин за контролиране на достъпа. Споделянето е по-трудно за отстраняване, тъй като не е последователно внедрен контрол на достъпа. Споделянето може да се извърши както на ниво потребител, така и на екип. Споделянето с екип е по-ефективен начин за споделяне. По-усъвършенствана концепция за споделяне е с Access Teams, която осигурява автоматично създаване на екип и споделянето на достъп до записи с екипа се основава на шаблон на Access Team (шаблон на разрешения), който се прилага. Екипите за достъп могат да се използват и без шаблоните, като само ръчно се добавят или премахват членовете му. Екипите за достъп са по-ефективни, защото не позволяват да притежават записи от екипа или да имат зададени роли за сигурност на екипа. Потребителите получават достъп, защото записът се споделя с екипа, а потребителят е член.

Защита на ниво запис в Dataverse

Може би се чудите - какво определя достъпа до запис? Това звучи като прост въпрос, но за всеки даден потребител това е комбинацията от всичките му роли за защита, бизнес единицата, с която е свързан, екипите, в които членува, и записите, които се споделят с тях. Ключовото нещо, което трябва да запомните е, че целият достъп е натрупващ се във всички тези понятия в обхвата на среда на база данни на Dataverse. Тези права се предоставят само в рамките на една база данни и се проследяват индивидуално във всяка база данни на Dataverse. Всичко това изисква те да имат подходящ лиценз за достъп Dataverse.

Сигурност на ниво колона в Dataverse

Понякога контролът на достъпа на ниво запис не е подходящ за някои бизнес сценарии. Dataverse има функция за сигурност на ниво колона, която позволява по-подробен контрол на сигурността на ниво колона. Защитата на ниво колона може да бъде активирана за всички персонализирани колони и повечето системни колони. Повечето системни колони, които включват информация, позволяваща идентифициране на лица (PII), могат да бъдат индивидуално защитени. Метаданните на всяка колона определят дали това е налична опция за системната колона.

Сигурността на ниво колона се активира за всяка колона поотделно. След това достъпът се управлява чрез създаване на профил за сигурност на колоната. Профилът съдържа всички колони, които имат активирана защита на ниво колона, и достъпа, предоставен от този конкретен профил. Всяка колона може да се контролира в рамките на профила за достъп за създаване, актуализиране и четене. След това профилите за сигурност на колони се свързват с потребител или екипи, за да се предоставят тези привилегии на потребителите за записите, до които те вече имат достъп. Важно е да се отбележи, че сигурността на ниво колона няма нищо общо със сигурността на ниво запис. Потребителят вече трябва да има достъп до записа, за да може профилът за сигурност на колоните да му предостави достъп до колоните. Сигурността на ниво колона трябва да се използва според нуждите, а не прекомерно, тъй като може да добави допълнителни разходи, които са вредни, ако се използват прекомерно.

Управление на защитата в множество среди

Ролите за сигурност и профилите за сигурност на колони могат да бъдат пакетирани и премествани от една среда в друга с помощта на решения на Dataverse. Във всяка среда трябва да бъдат създадени и управлявани бизнес единици и екипи, както и да бъдат назначени потребители към необходимите компоненти за сигурност.

Конфигуриране на защитата на среда за потребители

След като роли, екипи и бизнес единици са създадени в среда, е време да зададете на потребителите техните конфигурации за сигурност. Първо, когато създавате потребител, ще го свържете с бизнес единица. По подразбиране това е основната бизнес единица в организацията. Те също се добавят към екипа по подразбиране на тази бизнес единица.

В допълнение, вие бихте назначили всички роли за сигурност, от които се нуждае потребителят. Вие също бихте ги добавили като членове на всички отбори. Не забравяйте, че екипите също могат да имат роли за сигурност, така че ефективните права на потребителя са комбинацията от пряко зададени роли за сигурност, комбинирани с тези на всички екипи, в които членуват. Сигурността винаги е добавка, предлагаща най-малкото ограничително разрешение на някое от техните права. По-долу е посочено добро описание на конфигуриране на сигурността на среда.

Ако сте използвали сигурност на ниво колона, ще трябва да свържете потребителя или екипа на потребителя с един от създадените профили за сигурност на колона.

Сигурността е сложна статия и се постига най-добре като съвместно усилие между създателите на приложения и екипа, администриращ разрешенията на потребителите. Всички големи промени трябва да бъдат координирани доста преди внедряването на промените в средата.

Вижте също

Конфигуриране на защитата на средата
Права за достъп и привилегии