Защита портала 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. Действительно ли клиенту нужно удалять счет, или ему достаточно доступа на чтение и добавление? После того как вы определили действия, нужно задать область строк для каждой таблицы:

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

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

Разница между областями «Контакт» и «Учетная запись»

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

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

С другой стороны, область Account предназначена для архитектуры B2B-порталов. В B2B-сценарии менеджеру по работе с клиентами или главному специалисту отдела закупок нужно видеть все обращения, заказы и счета, связанные с их родительской учетной записью организации. Когда вы назначаете область Account для разрешения таблицы, портал определяет родительскую учетную запись, связанную с записью контакта вошедшего пользователя, и затем показывает все связанные дочерние записи этой организации. Правильное сопоставление этих связей в 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 и попробуйте просмотреть данные другого контакта или учетной записи. Попробуйте манипулировать URL-адресом и подменять GUID, меняя идентификаторы записей в адресной строке браузера, чтобы проверить, блокирует ли сервер несанкционированные запросы. Кроме того, проверьте журналы диагностики и аудита портала, чтобы убедиться, что попытки получения повышенных привилегий приводят к соответствующим ответам 403 Forbidden.

Заключение и лучшие практики

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

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