Модель разрешения

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

Рабочая область — это логическая сущность для группировки элементов в Fabric. Роли рабочей области определяют разрешения доступа для рабочих областей. Хотя элементы хранятся в одной рабочей области, ими можно делиться с другими пользователями через Fabric. Когда вы предоставляете общий доступ к элементам Fabric, вы можете решить, с какими разрешениями предоставить пользователю общий доступ к элементу. Некоторые элементы, такие как отчеты Power BI, позволяют более детально контролировать данные. Можно настроить отчеты так, чтобы в зависимости от разрешений пользователи видели только часть данных, доступных им.

Роли рабочей области

Роли рабочей области используются для управления доступом к рабочим областям и содержимому в них. Администратор Структуры может назначать роли рабочей области отдельным пользователям или группам. Роли рабочей области ограничены определенной рабочей областью и не применяются к другим рабочим областям, емкости рабочей области или клиенту.

Существует четыре роли рабочей области, и они применяются ко всем элементам в рабочей области. Пользователи, у которых нет этих ролей, не могут получить доступ к рабочей области. Вот эти роли:

  • Средство просмотра — может просматривать все содержимое в рабочей области, но не может изменить его.

  • Участник — может просматривать и изменять все содержимое в рабочей области.

  • Член — может просматривать, изменять и предоставлять общий доступ ко всему содержимому в рабочей области.

  • Администратор — может просматривать, изменять, предоставлять общий доступ и управлять всем содержимым в рабочей области, включая управление разрешениями.

В этой таблице показан небольшой набор возможностей каждой роли. Полный и подробный список см. в статье "Роли рабочей области Microsoft Fabric".

Возможность Администратор Участник Контрибьютор Просмотрщик
Удалить рабочую область ✅ ❌ ❌ ❌
Добавить администраторов ✅ ❌ ❌ ❌
Добавить участников ✅ ✅ ❌ ❌
Запись данных ✅ ✅ ✅ ❌
Создание элементов ✅ ✅ ✅ ❌
Чтение данных ✅ ✅ ✅ ✅

Разрешения элемента

Разрешения элементов используются для управления доступом к отдельным элементам Fabric в рабочей области. Разрешения элемента ограничены определенным элементом и не применяются к другим элементам. Используйте разрешения элемента для управления тем, кто может просматривать, изменять и управлять отдельными элементами в рабочей области. Вы можете использовать разрешения элемента для предоставления пользователю доступа к одному элементу в рабочей области, к которому у них нет доступа.

При совместном использовании элемента с пользователем или группой можно настроить разрешения элемента. Общий доступ к элементу предоставляет пользователю разрешение на чтение для этого элемента по умолчанию. Разрешения на чтение позволяют пользователям просматривать метаданные этого элемента и просматривать все отчеты, связанные с ним. Однако разрешения на чтение не позволяют пользователям получать доступ к базовым данным в SQL или OneLake. Например, если вы предоставляете общий доступ к отчету Power BI, использующий режим DirectLake, получатель может просматривать отчет, но также должен иметь разрешения на данные OneLake для запроса базовых таблиц Delta напрямую. Для сценариев, требующих более глубокого доступа к данным, предоставьте дополнительные разрешения на уровне вычислений через конечную точку аналитики SQL или безопасность семантической модели.

Разные элементы Fabric имеют разные разрешения. Дополнительные сведения о разрешениях для каждого элемента см. в следующих статье:

Разрешения вычислений

Разрешения также можно задать в определенном вычислительном ядре в Fabric, в частности через конечную точку аналитики SQL или в семантической модели. Разрешения подсистемы вычислений обеспечивают более детализированный контроль доступа к данным, например безопасность на уровне таблицы и строк.

  • Конечная точка аналитики SQL. Конечная точка аналитики SQL предоставляет прямой доступ к таблицам в OneLake и может иметь безопасность, настроенную в собственном коде с помощью команд SQL. Эти разрешения применяются только к запросам, сделанным через SQL.

  • Семантическая модель — семантические модели позволяют определять безопасность с помощью DAX. Ограничения, определенные с помощью DAX, применяются к пользователям, запрашивающим семантическую модель или отчеты Power BI, созданные на основе семантической модели.

Дополнительные сведения см. в следующих статьях:

Безопасность OneLake

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

Узнайте больше о модели контроля доступа к данным OneLake и ознакомьтесь с инструкциями.

Совместное использование данных между клиентами и сочетания клавиш OneLake

Ярлыки OneLake не копируют данные; доступ осуществляется на уровне источника. При совместном использовании данных между клиентами Microsoft Entra с помощью данных OneLake, внешним пользователям должны быть предоставлены соответствующие разрешения на доступ к общим данным в таблице или папке OneLake. Ссылки, ссылающиеся на перекрестные общие данные, следуют той же модели разрешений: доступ контролируется исходным клиентом, а пользователи потребляющего клиента должны иметь явные разрешения OneLake, предоставленные владельцем данных.

Порядок операций

Структура имеет три разных уровня безопасности. Чтобы получить доступ к данным, пользователь должен иметь доступ на каждом уровне. Каждый уровень оценивается последовательно, чтобы определить, имеет ли пользователь доступ. Такие правила безопасности, как политики Microsoft Information Protection, оцениваются на определенном уровне, чтобы разрешить или запретить доступ. Порядок операции при оценке безопасности Fabric:

  1. Проверка подлинности Entra: Проверяет, может ли пользователь пройти аутентификацию в узле Microsoft Entra.
  2. Доступ к Microsoft Fabric: Проверяет, может ли пользователь получить доступ к Microsoft Fabric.
  3. Безопасность данных. Проверяет, может ли пользователь выполнить запрошенное действие в таблице или файле.

Для сценариев доступа между клиентами пользователи сначала проходят проверку подлинности через свой домашний клиент Microsoft Entra. Затем Fabric проверяет, предоставлен ли пользователю доступ к общим данным в исходном клиенте с помощью разрешений на общий доступ к данным OneLake.

Примеры

В этом разделе приведены два примера настройки разрешений в Fabric.

Пример 1. Настройка разрешений группы

Wingtip Toys настроен с одним арендатором для всей организации и тремя возможностями. Каждая емкость представляет собой другой регион. Wingtip Toys работает в США, Европе и Азии. Каждая емкость имеет рабочую область для каждого отдела в организации, включая отдел продаж.

Отдел продаж имеет руководителя, руководителя отдела продаж и участников группы продаж. Wingtip Toys также использует одного аналитика всей организации.

В следующей таблице показаны требования к каждой роли в отделе продаж и настройке разрешений для их включения.

Роль Требование Настройка
Менеджер Просмотр и изменение всего содержимого отдела продаж в всей организации Роль участника для всех рабочих областей продаж в организации
Руководитель команды Просмотр и изменение всего содержимого отдела продаж в определенном регионе Роль участника для рабочей области продаж в регионе
Участник группы продаж
  • Просмотр статистики других участников продажи в регионе
  • Просмотр и изменение собственного отчета о продажах
    		•
  • Нет ролей для любых рабочих областей продаж
  • Доступ к определенному отчету, который перечисляет данные о продажах участника
    		•
    Аналитик Просмотр всего содержимого отдела продаж в всей организации Роль просмотра для всех рабочих областей продаж в организации

    Wingtip также имеет квартальный отчет, который перечисляет доход от продаж на каждого сотрудника отдела продаж. Этот отчет хранится в рабочей области финансов. С помощью безопасности на уровне строк отчет настраивается таким образом, чтобы каждый участник продаж видел только свои собственные цифры продаж. Руководители группы могут видеть данные о продажах всех участников продаж в их регионе, а менеджер по продажам может видеть данные о продажах всех участников продаж в организации.

    Пример 2. Разрешения рабочей области и элемента

    При совместном использовании элемента или изменении его разрешений роли рабочей области не изменяются. Пример в этом разделе демонстрирует, как взаимодействуют разрешения рабочей области и элемента.

    Вероника и Марта работают вместе. Вероника является владельцем отчета, который она хочет поделиться с Мартой. Если Вероника поделится отчетом с Мартой, Марта сможет получить к нему доступ, независимо от ее роли в рабочей области.

    Предположим, что у Марты есть роль просмотра в рабочей области, где хранится отчет. Если Veronica решит удалить разрешения на элемент Marta из отчета, Марта по-прежнему сможет просматривать отчет в рабочей области. Marta также сможет открыть отчет из рабочей области и просмотреть его содержимое. Это связано с тем, что Marta имеет разрешения на просмотр рабочей области.

    Если Вероника не хочет, чтобы Марта просматривала отчет, удаление разрешений для Марты на просмотр отчета недостаточно. Veronica также необходимо удалить разрешения на просмотр для Марты из рабочей области. Без прав на просмотр пространства Марта не сможет видеть, что отчет существует, так как она не сможет иметь доступ к пространству. Марта также не сможет использовать ссылку на отчет, так как у нее нет доступа к отчету.

    Теперь, когда у Марты больше нет роли просмотрщика рабочей области, если Вероника решит поделиться отчетом с ней снова, Марта сможет просмотреть его по ссылке, которой Вероника поделится с ней, не имея доступа к рабочей области.

    Пример 3. Разрешения приложения Power BI

    При совместном использовании отчетов Power BI часто требуется, чтобы получатели имели доступ только к отчетам, а не к элементам в рабочей области. Для этого можно использовать приложения Power BI или предоставлять доступ к отчетам непосредственно пользователям.

    Кроме того, можно ограничить доступ средства просмотра к данным с помощью безопасности на уровне строк (RLS). С помощью RLS можно создавать роли, которые имеют доступ к определённым частям данных, и ограничивать результаты, возвращая только те данные, к которым имеет доступ учётная запись пользователя.

    Это работает хорошо при использовании моделей импорта, так как данные импортируются в семантической модели, и получатели имеют доступ к этому в рамках приложения. При использовании DirectLake отчет считывает данные непосредственно из Lakehouse, а получатель отчета должен иметь доступ к этим файлам в озере. Это можно сделать несколькими способами:

    Так как RLS определен в семантической модели, данные будут считываться сначала, а затем строки будут отфильтрованы.

    Если в конечной точке аналитики SQL определены какие-либо параметры безопасности, запросы автоматически переходят в режим DirectQuery. Если вы не хотите использовать это резервное поведение по умолчанию, вы можете создать новый Lakehouse с помощью сочетаний клавиш для таблиц в исходном Lakehouse и не определить RLS или OLS в SQL в новом Lakehouse.

    Замечание

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

    Связанный контент

    • Last updated on