Захист вашого порталу Power Pages: поглиблений огляд дозволів і областей дії для таблиць

By Mirko Peters · 2026-08-11

Ласкаво просимо назад до подкаст-блогу! Коли ви створюєте веб-застосунки для клієнтів на Microsoft Power Platform, безпека не може бути запізнілою думкою. Power Pages — неймовірний інструмент для швидкого розгортання надійних зовнішніх порталів, безпосередньо пов’язаних із Dataverse. Але з великою силою приходить велика відповідальність — зокрема відповідальність за те, щоб конфіденційні дані вашо

Automatically translated with AI from the original post. Read the English original

Titelbild: Securing Your Power Pages Portal: A Deep Dive into Table Permissions and Scopes

У цьому дописі ми детально розглянемо основні архітектурні концепції безпеки, які обговорювали в нашому нещодавньому випуску. Якщо ви ще його не слухали, обов’язково ознайомтеся з випуском Build Customer Portals with Power Pages and Dataverse, де розказано про повне налаштування середовища, роботу із зовнішніми ідентичностями та розгортання першого рішення порталу.

Заглибимось у механіку безпеки Power Pages, почавши з того, як спланувати межі даних і опанувати дозволи для таблиць.

Вступ до безпеки Power Pages

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

Безпека в Power Pages спирається на багаторівневу стратегію захисту. На зовнішньому рівні є механізми автентифікації — наприклад, Azure AD B2C, локальні облікові записи або зовнішні постачальники ідентичності, які підтверджують, хто є користувачем. На внутрішньому рівні діють веб-ролі та дозволи для таблиць Dataverse. Ці дозволи точно визначають, що автентифіковані ідентичності можуть переглядати, створювати, оновлювати або видаляти. Правильна настройка — це різниця між безпечним корпоративним порталом і величезним витоком даних, який чекає на свою чергу.

Планування меж даних і дозволів для таблиць

Перш ніж торкнутися хоча б однієї кнопки в Power Pages Studio, візьміть дошку й ретельно накресліть межі своїх даних. Це, мабуть, найважливіші 15 хвилин усього життєвого циклу вашого проєкту порталу.

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

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

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

Розуміння різниці між областями «Контакт» і «Обліковий запис»

Одна з найпоширеніших плутанин для початківців у Power Pages — розуміння відмінностей між областями «Контакт» і «Обліковий запис». Неправильний вибір області може або повністю зіпсувати досвід користувача, приховавши релевантні дані компанії, або ненавмисно відкрити конфіденційні дані неавторизованим особам.

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

З іншого боку, Account Scope призначений для архітектур порталів B2B. У сценарії B2B вам потрібно, щоб менеджер за обліковим записом або головний відповідальний за закупівлі бачив усі звернення, замовлення та рахунки, пов'язані з батьківським обліковим записом їхньої компанії. Коли ви призначаєте область Account для дозволу таблиці, портал визначає батьківський обліковий запис, пов'язаний із записом Contact поточного користувача, і після цього показує всі пов'язані дочірні записи цієї організації. Правильне зіставлення цих зв'язків у Dataverse є критично важливим для успіху B2B.

Визначення веб-ролей і уникнення пастки «Authenticated Users»

Веб-ролі є ланкою між автентифікованими користувачами та дозволами таблиць Dataverse. За замовчуванням Power Pages містить роль «Authenticated Users». Саме тут багато адміністраторів потрапляють у небезпечну пастку безпеки.

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

Натомість створюйте власні веб-ролі з детальними дозволами, адаптовані до конкретних типів користувачів. Наприклад:

CustomerUser: зіставлена з областю Contact для операційних таблиць, таких як Cases і Orders, що дозволяє користувачам відстежувати власні взаємодії.
AccountManager: зіставлена з областю Account, що надає призначеним керівникам організації доступ до активів на рівні всієї компанії.
KnowledgeBaseViewer: зіставлена глобально, але суворо обмежена дією лише для читання з публічними статтями служби підтримки.

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

Посилення видимості на рівні полів і захист PII

Контроль доступу до рядків через області таблиць — лише половина справи. Потрібно також уважно стежити за тим, які дані видимі в окремих рядках і списках. Розкриття персональних даних (PII), таких як номери телефонів, домашні адреси, фінансові відомості чи внутрішні нотатки про співробітників, може призвести до серйозних порушень вимог відповідності (наприклад, GDPR або CCPA).

Під час створення списків і базових форм у Power Pages переконайтеся, що ваші представлення не містять чутливих стовпців. Те, що поле приховано в інтерфейсі форми, не означає, що його не можна переглянути чи отримати через базові веб-API, якщо дозволи надто широкі. Використовуйте окремі, посилені представлення (наприклад, спеціальне «PublicView»), які містять лише безпечні, очищені стовпці. Якщо певні стовпці мають залишатися в таблиці бази даних, розгляньте можливість впровадження безпеки на рівні стовпців у Dataverse, щоб повністю обмежити доступ на рівні ядра бази даних.

Тестування на проникнення дозволів вашого порталу

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

Створіть тестові облікові записи для кожної з визначених веб-ролей. Увійдіть як звичайний CustomerUser і спробуйте переглянути дані, що належать іншому Contact або Account. Спробуйте прямо змінювати URL і підміняти GUID, замінюючи ідентифікатори записів у рядку адреси браузера, щоб перевірити, чи сервер правильно блокує несанкціоновані запити. Крім того, перегляньте діагностичні журнали та журнали аудиту порталу, щоб переконатися, що спроби неавторизованого доступу викликають відповідь 403 Forbidden.

Висновки та найкращі практики

Захист порталу Power Pages вимагає продуманого планування, суворого дотримання принципу найменших привілеїв і глибокого розуміння дозволів та областей таблиць Dataverse. Відмовившись від небезпечних типових налаштувань, таких як роль Authenticated Users, ретельно обмежуючи доступ до таблиць на рівні Contact або Account і посилюючи видимість полів, ви зможете створити клієнтський портал, який є водночас високофункціональним і надзвичайно безпечним.

Щоб зануритися в цю тему ще глибше та побачити повний покроковий посібник із впровадження, включно з налаштуванням зовнішніх ідентичностей, проєктуванням архітектури рішення та підготовкою до запуску, обов’язково послухайте наш супутній епізод подкасту: Build Customer Portals with Power Pages and Dataverse. Дякуємо, що читаєте, і стежте за новими експертними порадами щодо опанування Microsoft Power Platform!