Основные понятия безопасности в Microsoft Dataverse
Одна из ключевых особенностей Dataverseэто ее богатая модель безопасности, которая может адаптироваться ко многим сценариям использования в бизнесе. Эта модель безопасности работает только тогда, когда в среде есть Dataverse база данных. Как администратор, вы, скорее всего, не будете самостоятельно строить всю модель безопасности, но часто будете участвовать в процессе управления пользователями, обеспечения их правильной конфигурации и устранения проблем, связанных с безопасным доступом.
Совет
Посмотрите следующее видео: Microsoft Dataverse – Концепции безопасности, показанные в демонстрациях.
Ролевая безопасность
Dataverse использует безопасность на основе ролей для группировки коллекции привилегий. Эти роли безопасности могут быть связаны непосредственно с пользователями, или они могут быть связаны с рабочими группами и подразделениями Dataverse. Затем пользователи могут быть связаны с командой, и, следовательно, все пользователи, связанные с командой, получают выгоду от этой роли. Ключевая концепция безопасности Dataverse состоит в том, что все привилегии накапливаются с наибольшим объемом доступа. Если вы предоставили доступ для чтения ко всем записям контактов на широком уровне организации, вы не сможете вернуться и скрыть одну запись.
Бизнес-единицы
Совет
Посмотрите следующее видео: Модернизация бизнес-подразделений.
Бизнес-подразделения работают с ролями безопасности, чтобы определить эффективную безопасность пользователя. Подразделения — это строительный блок моделирования безопасности, который помогает управлять пользователями и данными, к которым они могут получить доступ. Подразделения определяют границы безопасности. Каждая база данных Dataverse имеет единственное корневое подразделение.
Вы можете создавать дочерние подразделения, чтобы помочь в дальнейшем сегментировать пользователей и данные. Каждый пользователь, назначенный в среду, принадлежит к определенному бизнес-подразделению. В то время как подразделения могут использоваться для моделирования истинной организационной иерархии 1:1, чаще они больше сводятся к определенным границам безопасности, чтобы помочь удовлетворить потребности модели безопасности.
Чтобы лучше понять, давайте посмотрим на следующий пример. У нас есть три подразделения. Woodgrove — это корневое подразделение, и оно всегда будет вверху, что неизменно. Мы создали еще два дочерний элемент бизнес-подразделения A и B. Пользователи в этих бизнес-подразделениях имеют разные потребности в доступе. Когда мы связываем пользователя с этой средой, мы можем задать пользователя в одном из этих трех подразделений. То, с каким подразделением связан пользователь, определяет, какие записи принадлежат этому пользователю. Наличие этой связи позволяет нам настроить роль безопасности, которая позволяет пользователю видеть все записи в этом бизнес-подразделении.
Иерархическая структура доступа к данным
Клиенты могут использовать организационную структуру, в которой данные и пользователь разделены в древовидной иерархии.
Когда мы связываем пользователя с этой средой, мы можем назначить пользователю одно из этих трех бизнес-подразделений и назначить пользователю роль безопасности из подразделения. Бизнес-подразделение, с которым связан пользователь, определяет, какое бизнес-подразделение владеет записями, когда пользователь создает запись. Наличие этой ассоциации позволяет нам адаптировать роль безопасности, что позволяет пользователю просматривать записи в этом бизнес-подразделении.
Пользователь A связан с подразделением A и ему присвоена роль безопасности Y из подразделения A. Это позволяет пользователю A получить доступ к записям контакта №1 и контакта №2. В то время как пользователь B в Подразделении B не может получить доступ к записям контактов Подразделения A, но может получить доступ к записи контакта № 3.
Матричная структура доступа к данным (модернизованные бизнес-подразделения)
Клиенты могут использовать организационную структуру, в которой данные разделены в виде древовидной иерархии, а пользователи могут работать и получать доступ к данным любого бизнес-подразделения независимо от того, какому бизнес-подразделению назначен пользователь.
Когда мы связываем пользователя с этой средой, мы можем задать пользователя в одном из этих трех подразделений. Для каждого бизнес-подразделения, которое требуется пользователю для доступа к данным, пользователю назначается роль безопасности из этого бизнес-подразделения. Когда пользователь создает запись, он может установить бизнес-подразделение, которое будет владеть этой записью.
Пользователь A может быть связан с любым бизнес-подразделением, включая корневое бизнес-подразделение. Роль безопасности Y из подразделения A назначается пользователю A, что дает ему доступ к записям контакта №1 и контакта №2. Роль безопасности Y из подразделения B назначается пользователю A, что дает ему доступ к записям контакта №3.
Включение матричной структуры доступа к данным
Заметка
Прежде чем включить эту функцию, вы должны опубликовать все свои настройки, чтобы все ваши новые неопубликованные таблицы поддерживали эту функцию. Если вы обнаружите, что у вас есть неопубликованные таблицы, которые не работают с этой функцией, после ее включения, вы можете задать параметр RecomputeOwnershipAcrossBusinessUnits с помощью инструмента OrgDBOrgSettings для Microsoft Dynamics CRM. Установка для параметра RecomputeOwnershipAcrossBusinessUnits значения true позволяет задавать и обновлять значение поля Ответственная бизнес-единица.
- войдите в Power Platform центр администрирования как администратор (администратор Dynamics 365 или Microsoft Power Platform администратор).
- Выберите Среды, затем выберите среду, для которой вы хотите включить эту функцию.
- Выберите Параметры>Продукт>Функции.
- Включите переключатель Ответственный за записи в различных бизнес-единицах.
Когда этот переключатель функции включен, вы можете выбрать бизнес-подразделение, когда вы назначаете пользователю роль безопасности. Это позволяет вам назначать пользователю роль безопасности из разных бизнес-подразделений. Пользователю также требуется роль безопасности от бизнес-подразделения, к которому назначен пользователь с привилегиями настроек пользователя для запуска приложений на основе модели. Вы можете обратиться к роли безопасности Базовый пользователь, чтобы узнать, как активируются эти привилегии настроек пользователей.
Вы можете назначить пользователя владельцем записи в любом бизнес-подразделении без необходимости назначать роль безопасности в бизнес-подразделении, владеющем записью, если у пользователя есть роль безопасности с правом чтения таблицы записей. См. раздел Владение записью в модернизированных бизнес-подразделениях.
Заметка
Этот переключатель функции хранится в параметре EnableOwnershipAcrossBusinessUnits и может быть установлен с помощью инструмента OrgDBOrgSettings для Microsoft Dynamics CRM.
Связывание бизнес-подразделения с группой безопасности Microsoft Entra
Вы можете использовать группу безопасности Microsoft Entra для сопоставления вашего бизнес-подразделения с целью упрощения администрирования пользователей и назначения ролей.
Создайте Microsoft Entra группу безопасности для каждого бизнес-подразделения и назначьте соответствующее бизнес-подразделение роль безопасности каждой групповой команде.
Для каждого бизнес-подразделения создайте группу безопасности Microsoft Entra. Создайте команду группы Dataverse для каждой группы безопасности Microsoft Entra. Назначьте соответствующую роль безопасности из бизнес-подразделения каждой команде группы Dataverse. Пользователь на приведенной выше диаграмме будет создан в корневом бизнес-подразделении, когда пользователь получит доступ к среде. Это нормально, когда пользователь и команда группы Dataverse находятся в корневом бизнес-подразделении. У них есть доступ только к данным в бизнес-подразделении, которому назначена роль безопасности.
Добавьте пользователей в соответствующую группу безопасности Microsoft Entra, чтобы предоставить им доступ к бизнес-подразделению. Пользователи могут немедленно запустить приложение и получить доступ к его ресурсам/данным.
В матричной структуре доступа к данным, где пользователи могут работать и получать доступ к данным из нескольких бизнес-подразделений, добавьте пользователей в группы безопасности Microsoft Entra, сопоставленные с этими бизнес-подразделениями.
Ответственное подразделение
Каждая запись имеет столбец Владеющее бизнес-подразделение , который определяет, какому бизнес-подразделению принадлежит запись. При создании записи в этом столбце по умолчанию указывается подразделение компании пользователя, и его нельзя изменить, за исключением случая, когда переключатель функции находится в положении ВКЛ.
Заметка
Когда вы меняете бизнес-единиц, владеющую записью, обязательно ознакомьтесь со следующими каскадными эффектами: Использование пакета SDK для .NET для настройки каскадного поведения.
Вы можете указать, хотите ли вы разрешить пользователю устанавливать столбец «Ответственное подразделение», когда переключатель функции находится в положении «ВКЛ.». Чтобы установить столбец "Ответственное подразделение", вам необходимо предоставить роли безопасности пользователя привилегию Добавить к с разрешением локального уровня.
Чтобы разрешить пользователю устанавливать этот столбец, вы можете включить этот столбец следующим образом:
- Форма — и текст, и заголовок.
- Представление.
- Сопоставление столбцов. Если вы используете AutoMapEntity, вы можете указать столбец в вашем столбце сопоставление.
Заметка
Если у вас есть задание/процесс для синхронизации данных между средами и Владелец бизнес-единицы включен как часть схемы, ваша работа завершится ошибкой с нарушением ограничения Внешний ключ, если в целевой среде нет того же значения Владелец бизнес-единицы.
Вы можете удалить столбец Владелец бизнес-единицы из исходной схемы или обновить значение столбца Владелец бизнес-единицы источника на любую из бизнес-единиц целевого объекта.
Если у вас есть задание/процесс для копирования данных из среды на внешний ресурс, например PowerBI, вам нужно будет выбрать или отменить выбор столбца Владелец бизнес-единицы из вашего источника. Выберите его, если ваш ресурс может его получить, в противном случае отмените выбор.
Владение таблицей/записью
Dataverse поддерживает два типа владения записями. Записи, принадлежащие организации, пользователю или рабочей группе. Этот выбор происходит во время создания таблицы, и его нельзя изменить. В целях безопасности для записей, принадлежащих организации, единственный выбор уровня доступа — это пользователь может выполнить операцию или не может. Для записей, принадлежащих пользователям и группам, выбор уровня доступа для большинства привилегий — это уровни организации, бизнес-единицы, бизнес-единицы и дочерних бизнес-единиц или только собственных записей пользователей. Это означает, что для привилегии чтения по контакту я мог установить владельца, и пользователь будет видеть только свои собственные записи.
В качестве еще одного примера, скажем, пользователь A связан с отделом A, и мы даем им доступ для чтения уровня подразделение по контакту. Они смогут видеть контакт №1 и №2, но не контакт №3.
Когда вы настраиваете или редактируете права роли безопасности, вы устанавливаете уровень доступа для каждого параметра. Ниже приведен пример редактора привилегий роли безопасности.
Выше вы можете увидеть стандартные типы привилегий для каждой таблицы: создать, прочитать, записать, удалить, добавить, добавить для, назначить, поделиться. Вы можете редактировать каждый из них в отдельности. Визуальное отображение каждого из них будет соответствовать приведенному ниже ключу в отношении того, какой уровень доступа вы предоставили.
В приведенном выше примере мы предоставили доступ на уровне организации к контакту, что означает, что пользователь в отделе А может видеть и обновлять контакты, принадлежащие кому-либо. На самом деле, одна из самых распространенных административных ошибок — разочарование в разрешениях и просто чрезмерное предоставление доступа. Очень быстро хорошо продуманная модель безопасности начинает выглядеть как швейцарский сыр (дырявый!).
Владение записью в модернизированных бизнес-подразделениях
В Модернизированных бизнес-подразделениях пользователи могут быть владельцами записей в любых бизнес-подразделениях. Все, что нужно пользователям, — это роль безопасности (любое бизнес-подразделение), у которого есть право на чтение таблицы записей. Пользователям не нужно назначать роль безопасности в каждом бизнес-подразделении, где находится запись.
Если параметр Ответственный за записи в различных бизнес-единицах был включена в вашей производственной среде в течение периода предварительной версии, вам необходимо выполнить следующие действия, чтобы включить владение этой записью в бизнес-подразделении:
- Установите Редактор настроек организации
- Установите для параметров организации RecomputeOwnershipAcrossBusinessUnits значение true. Если для этого параметра установлено значение true, система блокируется, и может потребоваться до 5 минут, чтобы выполнить перерасчет и включить возможность, при которой пользователи могут владеть записями в разных бизнес-единицах без назначения им отдельной роли безопасности для каждой бизнес-единицы. Это позволяет владельцу записи назначать свою запись пользователю за пределами бизнес-единицы, которой принадлежит запись.
- Установите для параметра AlwaysMoveRecordToOwnerBusinessUnit значение false. В результате запись остается во владеющем исходном бизнес-подразделении при смене владельца записи.
Для всех непроизводственных сред вам просто нужно установить для параметра AlwaysMoveRecordToOwnerBusinessUnit значение false, чтобы использовать эту возможность.
Заметка
Если отключить функцию Ответственный за записи в различных бизнес-единицах или установить для параметра RecomputeOwnershipAcrossBusinessUnits значение false с помощью средства OrgDBOrgSettings для Microsoft Dynamics CRM, вы не сможете задавать или обновлять значение поля Ответственная бизнес-единица, и все записи, где значение поля Ответственная бизнес-единица отличается от бизнес-единицы ответственного, будут обновляться в соответствии с бизнес-единицей ответственного.
Команды (включая команды группы)
Рабочие группы являются еще одним важным строительным блоком безопасности. Владельцами рабочих групп являются подразделения. Каждое подразделение имеет одну рабочую группу по умолчанию, которая создается автоматически при создании подразделения. Участники рабочей группы по умолчанию управляются в Dataverse и всегда содержат всех пользователей, связанных с этим подразделением. Вы не можете вручную добавлять или удалять участников из рабочей группы по умолчанию, они динамически корректируются системой, так как новые пользователи ассоциируются с/отделяются от подразделения. Существует два типа рабочих групп: ответственные рабочие группы и группы доступа.
- Ответственные рабочие группы могут владеть записями, что дает любому члену рабочей группы прямой доступ к этой записи. Пользователи могут быть участниками нескольких рабочих групп. Это позволит удобную возможность предоставления разрешений пользователям широким способом без микроуправления доступом на уровне отдельных пользователей.
- Группы доступа обсуждаются в следующем разделе как часть совместного использования записей.
Общий доступ к записям
Отдельные записи могут передаваться одна за другой другому пользователю. Это удобная возможность обработки исключений, которые не относятся к владению записью или является участником модели доступа подразделения. Однако это должно быть исключением, потому что это менее эффективный способ управления доступом. Совместное использование более сложно для устранения неполадок, потому что это не последовательно реализованный контроль доступа. Совместное использование может быть сделано как на уровне пользователя, так и на уровне рабочей группы. Совместное использование с рабочей группой является более эффективным способом совместного доступа. Более продвинутая концепция совместного использования — это группы доступа, которые обеспечивают автоматическое создание рабочей группы и совместное использование доступа к записям с рабочей группой на основе применяемого шаблона группы доступа (шаблон разрешений). Группы доступа также можно использовать без шаблонов, просто вручную добавляя или удаляя их участников. Группы доступа более эффективны, потому что они не позволяют владеть записями группы или назначать ей роли безопасности. Пользователи получают доступ, потому что запись передается группе, а пользователь является участником.
Безопасность уровня записи в Dataverse
Вам может быть интересно — что определяет доступ к записи? Это кажется простым вопросом, но для любого пользователя это совокупность всех его ролей безопасности, бизнес-подразделений, с которыми он связан, команд, в которые он входит, и записей, к которым ему предоставлен доступ. Главное, что нужно помнить, это то, что доступ является накопительным для всех этих концепций в рамках среда базы данных Dataverse. Эти объемы обслуживания предоставляются только в рамках одной базы данных и индивидуально отслеживаются в каждой базе данных Dataverse. Все это требует, чтобы у них была соответствующая лицензия для доступа к Dataverse.
Безопасность на уровне столбцов в Dataverse
Иногда контроль доступа на уровне записей недостаточен для некоторых бизнес-сценариев. Dataverse имеет функцию безопасности на уровне столбцов, чтобы обеспечить более детальный контроль безопасности на уровне столбцов. Безопасность на уровне столбцов может быть включена для всех настраиваемых столбцов и большинства системных столбцов. Большинство системных столбцов, которые включают в себя личную информацию (PII), могут быть защищены индивидуально. Метаданные каждого столбца определяют, является ли это доступным параметром для системного столбца.
Безопасность на уровне столбцов включена для каждого столбца. Затем управление доступом осуществляется путем создания профиля безопасности столбцов. Профиль содержит все столбцы, для которых включена безопасность на уровне столбцов, и доступ, предоставленный этим конкретным профилем. Каждый столбец можно контролировать в профиле для доступа «Создать», «Обновить» и «Чтение». Затем профили безопасности столбцов связываются с пользователем или рабочими группами, чтобы предоставить эти привилегии пользователям для записей, к которым у них уже есть доступ. Важно отметить, что безопасность на уровне столбцов не имеет ничего общего с безопасностью на уровне записей. Пользователь должен уже иметь доступ к записи, чтобы профиль безопасности столбцов мог предоставить ему какой-либо доступ к столбцам. Безопасность на уровне столбцов должна использоваться по мере необходимости, а не чрезмерно, поскольку она может добавить накладные расходы, которые наносят ущерб при чрезмерном использовании.
Управление безопасностью в нескольких средах
Роли безопасности и профили безопасности столбцов могут быть упакованы и перемещены из одной среды в другую, используя решения Dataverse. Подразделения и рабочие группы должны создаваться и управляться в каждой среде наряду с назначением пользователей на необходимые компоненты безопасности.
Настройка безопасности среды пользователей
После того, как в среде созданы роли, рабочие группы и бизнес-единицы, пора назначить пользователям их конфигурации безопасности. Во-первых, когда вы создаете пользователя, вы связываете его с бизнес-подразделением. По умолчанию это корневое подразделение в организации. Они также добавляются в рабочую группу по умолчанию этого бизнес-подразделения.
Кроме того, вы должны назначить любые роли безопасности, которые нужны пользователю. Вы также можете добавить их в качестве участников любых рабочих групп. Помните, что у рабочих групп также могут быть роли безопасности, поэтому эффективные права пользователя — это сочетание непосредственно назначенных ролей безопасности в сочетании с правами любых рабочих групп, в которые они входят. Безопасность всегда аддитивна, предлагая наименее ограничительное разрешение любого из их прав. Ниже приводится хорошее пошаговое руководство по настройке безопасности среды.
Если вы использовали безопасность на уровне , вам нужно будет связать пользователя или рабочую группу пользователя с одним из созданных вами профилей безопасности столбцов.
Безопасность — сложная задача, и ее лучше всего решать совместными усилиями разработчиков приложений и команды, администрирующей разрешения пользователей. Любые существенные изменения должны быть скоординированы заблаговременно до развертывания изменений в среде.