Поділитися через


Налаштування безпеки за допомогою дозволів таблиць

Примітка

З 12 жовтня 2022 року портали Power Apps перейменовано на Power Pages. Додаткова інформація: Microsoft Power Pages тепер у загальному доступі (блоґ)
Незабаром документацію порталів Power Apps буде перенесено та об’єднано з документацією Power Pages.

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

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

Щоб захистити ці функції, дозволи таблиці дозволяють надавати деталізовані права та вмикати для безпеки на рівні запису взаємопов'язані визначення.

Додавання дозволів таблиці до веб-ролі

  1. Відкрийте Програма керування порталом.

  2. Перейдіть до пункту Портали > Веб-ролі і відкрийте веб-роль, для якої потрібно додати дозвіл.

  3. В області Пов'язане виберіть Дозволи таблиць.

  4. Виберіть Додати наявний дозвіл таблиці, щоб додати існуючий дозвіл таблиці до веб-ролі.

  5. Знайдіть дозвіл таблиці або виберіть Створити дозвіл таблиці, щоб створити новий запис «Дозвіл таблиці».

    Додавання дозволів таблиці до веб-ролі.

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

Примітка

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

Глобальний тип доступу

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

Тип доступу «Контактна особа»

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

У списку цей тип доступу означає, що фільтр буде додано до будь-якого подання Microsoft Dataverse, що видає цей список, у якому відтворено тільки ті записи, які безпосередньо пов'язані з поточним користувачем. (Залежно від сценарію, такий зв'язок може бути об'ємом власності або права керування.) Наприклад, див. цей приклад сценарію для демонстрування, оновлення та видалення списків автомобілів, за які відповідає авто у автосалоні.

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

Тип доступу «Бізнес-партнер»

Якщо використовується тип доступу «Бізнес-партнер», користувач, який виконав вхід, у ролі, для якої визначено запис дозволу, матиме права, які надаються за цим дозволом тільки для записів, які мають відношення до цього запису первинного партнера користувача через визначені зв’язки.

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

Тип доступу «Власний»

Власний тип доступу дозволяє визначити права, які користувач має для свого власного запису контактної особи (посвідчення). Користувачі можуть використовувати базові або багатоетапні форми, щоб вносити зміни до власних записів контактних осіб, що пов'язані з їхнім профілями. За замовчуванням сторінка «Профіль» має спеціальну вбудовану форму, яка дозволяє будь-якому користувачеві змінювати його основну контактну інформацію і включати її або виключати з маркетингових списків. Якщо ця форма входить у ваш портал (це за замовчуванням), користувачам не потрібен такий дозвіл, щоб використовувати її. Однак, їм буде потрібен цей дозвіл на використання будь-яких базових або багатоетапні форм, що націлені на їхній запис контакту користувача. Наприклад, див. цей приклад сценарію, який дає змогу персоналу автосалону оновлювати контактні дані на сторінці профілю.

Батьківський тип доступу

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

Запис батьківського дозволу визначає дозвіл та область тип доступу для таблиці (ймовірно, тип доступу Глобальний або Контактна особа, хоча можливо також і Батьківський). Ця таблиця може бути пов'язана з контактною особою (якщо є тип доступу «Контактна особа») або визначатися глобально. Якщо є цей дозвіл, створюється дочірній дозвіл, який визначає зв’язок з іншої таблиці до таблиці, визначеної у батьківському зв’язку.

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

Атрибути та зв’язки

Наведена нижче таблиця пояснює атрибути дозволів таблиць.

Унікальне ім'я Опис
Унікальне ім'я Описове ім’я запису. Це обов’язкове поле.
Назва таблиці Логічне ім'я таблиці, яка має бути захищена або яка визначатиме зв’язок контактів або батьківський зв'язок для того, щоб убезпечити пов'язану таблицю у дочірньому дозволі. Це обов’язкове поле.
Тип доступу (обов’язково)
  • Глобальний: надає права до запису таблиці без будь-яких вимог до відповідального (контактної особи).
  • Контактна особа: надає права для запису таблиці, що має прямий зв’язок із відповідальним (контактною особою).
  • Бізнес-партнер: надає права до запису таблиці, який має зв’язок із бізнес-партнером, що виступає як відповідальний, припускаючи, що бізнес-партнер є первинним клієнтом контактної особи.
  • Батьківський: надає права до запису таблиці через ланцюжок зв’язків її батьківських дозволів.
Зв'язок для типу доступу Залежить від вибраного типу доступу.
  • Зв'язок контактної особи: потрібен лише якщо тип доступу = контактна особа.
    Ім'я схеми зв’язків між контактною особою та таблицею, вказаною в полі «Ім'я таблиці».
  • Зв'язок бізнес-партнера: потрібен лише якщо тип доступу = бізнес-партнер.
    Ім'я схеми зв’язків між бізнес-партнером та таблицею, вказаною в полі «Ім'я таблиці».
  • Батьківський зв’язок: потрібен тільки якщо призначено батьківський дозвіл таблиці.
    Ім'я схеми зв’язків між таблицею, вказаною в полі «Ім'я таблиці», і таблицею, вказаною в полі «Ім'я сутності» у її записі Батьківського дозволу таблиці.
    • Батьківський дозвіл таблиці: потрібен лише якщо тип доступу = батьківський.

Примітка: доступні зв'язки будуть пустими, якщо контактна особа або бізнес-партнер не мають наявних зв'язків із вибраною таблицею. Щоб створити зв'язки таблиць, див. Огляд зв'язків таблиць.
Прочитане Право, яке визначає, чи користувач може створювати запис.
Записування Право, що керує, чи користувач може оновити запис.
Створення Право, що керує, чи користувач може створити новий запис. Право на створення запису для типу таблиці застосовується не до окремого запису, а до класу таблиць.
Delete Право, що керує, чи користувач може видалити запис.
Додати Право, яка контролює, чи користувач може прикріпляти інший запис до вказаного запису. Дозволи «Додати» і «Додати до» діють у парі. Кожного разу, коли користувач прикріпляє один запис до іншого, користувач повинен мати обидва права. Наприклад, коли ви додаєте примітку до інциденту, потрібно мати право доступу «Додати» примітку і право доступу «Додати до» інциденту для операційної роботи.
Додавання до Право, яка контролює, чи користувач може додавати потрібний запис до іншого запису. Дозволи «Додати» і «Додати до» діють у парі, як описано нижче.

Глобальні дозволи для завдань, що пов'язані з потенційними клієнтами

В одному сценарії ми, можливо, спробуємо використовувати список і базові форми, щоб вивести всіх потенційних клієнтів на порталі для будь-кого в настроюваній веб-ролі менеджера потенційних клієнтів. У формі "Редагувати потенційних клієнтів", що запускається щоразу, коли вибрано рядок потенційних клієнтів у списку, вкладена сітка відображатиме пов'язані записи завдань. Ці записи мають бути доступними для тих, хто має роль менеджера потенційних клієнтів. Як перший етап ми даємо глобальні дозволи до потенційних клієнтів будь-якому в нашій ролі менеджера потенційних клієнтів.

Ця роль має пов’язані дозволи таблиць для таблиці «Потенційний клієнт» із типом доступу «Глобальний».

Користувачі у цій ролі матимуть доступ до всіх потенційних клієнтів через списки або форми на порталі.

Надання повноцінних дозволів для потенційного клієнта.

Тепер ми додамо дочірній дозвіл до глобального дозволу для потенційних клієнтів. Коли відкрито запис «Дозвіл на батьківський дозвіл», перейдіть до вкладеної таблиці «Дозволи дочірньої таблиці» та виберіть «Новий дозвіл для таблиці», щоб додати новий запис.

Додайте дочірній дозвіл до глобального дозволу для потенційних клієнтів.

Виберіть таблицю «Завдання» і тип доступу «Батьківський». Можна тоді вибрати первинний зв’язок (Lead_Tasks). Цей дозвіл передбачає, що контакт, який має веб-роль з первинним дозволом, буде мати глобальний дозвіл для всіх завдань, які стосуються потенційних клієнтів.

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

  • Для списку необхідно увімкнути дозволи таблиць.

    Увімкніть дозволи таблиць для списку.

  • Необхідно, щоб відбулися дії, які фактично дозволять користувачам виконати дії, на які їм надано дозволи.

    Дії, для яких було надано дозволи.

  • Дозволи також потрібно увімкнути для запису базової форми.

    Увімкнуто дозволи для запису базової форми.

  • Форма має бути на сторінці із вкладеною сіткою для таблиці, яку необхідно ввімкнути з дозволами «Дочірня». У цьому разі таблицею буде «Завдання».

    Вкладена сітка з таблицею — «Завдання».

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

Ця дія потім надає дозволи для всіх завдань, які пов’язані з потенційними клієнтами. Якщо завдання з'являється у списку сутностей, фільтр по суті додається до списку так, що тільки завдання, які пов'язані з потенційним клієнтом, будуть відображатися в списку. У нашому прикладі вони виводяться із вкладеною сіткою на базовій формі.

Приклад завдання.

Дозволи типу доступу «Контактна особа» завдань

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

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

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

Створення веб-ролі для порталів
Керування доступом до веб-сторінки для порталів

Примітка

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

Проходження опитування займе близько семи хвилин. Персональні дані не збиратимуться (декларація про конфіденційність).