Модель разрешения
Microsoft Fabric имеет гибкую модель разрешений, которая позволяет управлять доступом к данным в организации. В этой статье описаны различные типы разрешений в Fabric и их совместная работа для управления доступом к данным в организации.
Рабочая область — это логическая сущность для группировки элементов в Fabric. Роли рабочей области определяют разрешения доступа для рабочих областей. Хотя элементы хранятся в одной рабочей области, их можно совместно использовать другим пользователям в Fabric. Когда вы предоставляете общий доступ к элементам Fabric, вы можете решить, с какими разрешениями предоставить пользователю общий доступ к элементу. Некоторые элементы, такие как отчеты Power BI, позволяют более детально контролировать данные. Отчеты можно настроить таким образом, чтобы в зависимости от разрешений пользователи, которые просматривали их только часть удерживаемых данных.
Роли рабочей области
Роли рабочей области используются для управления доступом к рабочим областям и содержимому в них. Администратор Структуры может назначать роли рабочей области отдельным пользователям или группам. Роли рабочей области ограничены определенной рабочей областью и не применяются к другим рабочим областям, емкости рабочей области или клиенту.
Существует четыре роли рабочей области, и они применяются ко всем элементам в рабочей области. Пользователи, у которых нет этих ролей, не могут получить доступ к рабочей области. Вот эти роли:
Средство просмотра — может просматривать все содержимое в рабочей области, но не может изменить его.
Участник — может просматривать и изменять все содержимое в рабочей области.
Член — может просматривать, изменять и предоставлять общий доступ ко всему содержимому в рабочей области.
Администратор — может просматривать, изменять, предоставлять общий доступ и управлять всем содержимым в рабочей области, включая управление разрешениями.
В этой таблице показан небольшой набор возможностей каждой роли. Полный и подробный список см. в статье "Роли рабочей области Microsoft Fabric".
| Возможность | Административный | Элемент | Участник | Наблюдатель |
|---|---|---|---|---|
| удаления рабочей области. | ✅ | ❌ | ❌ | ❌ |
| Добавить администраторов | ✅ | ❌ | ❌ | ❌ |
| Добавить участников | ✅ | ✅ | ❌ | ❌ |
| Запись данных | ✅ | ✅ | ✅ | ❌ |
| Создание элементов | ✅ | ✅ | ✅ | ❌ |
| Чтение данных | ✅ | ✅ | ✅ | ✅ |
Разрешения элемента
Разрешения элементов используются для управления доступом к отдельным элементам Fabric в рабочей области. Разрешения элемента ограничены определенным элементом и не применяются к другим элементам. Используйте разрешения элемента для управления тем, кто может просматривать, изменять и управлять отдельными элементами в рабочей области. Вы можете использовать разрешения элемента для предоставления пользователю доступа к одному элементу в рабочей области, к которому у них нет доступа.
При совместном использовании элемента с пользователем или группой можно настроить разрешения элемента. Общий доступ к элементу предоставляет пользователю разрешение на чтение для этого элемента по умолчанию. Разрешения на чтение позволяют пользователям просматривать метаданные этого элемента и просматривать все отчеты, связанные с ним. Однако разрешения на чтение не позволяют пользователям получать доступ к базовым данным в SQL или OneLake.
Разные элементы Fabric имеют разные разрешения. Дополнительные сведения о разрешениях для каждого элемента см. в следующих статье:
Разрешения вычислений
Разрешения также можно задать в определенном вычислительном ядре в Fabric, в частности через конечную точку аналитики SQL или в семантической модели. Разрешения подсистемы вычислений обеспечивают более детализированный контроль доступа к данным, например безопасность на уровне таблицы и строк.
Конечная точка аналитики SQL. Конечная точка аналитики SQL предоставляет прямой доступ к таблицам в OneLake и может иметь безопасность, настроенную в собственном коде с помощью команд SQL. Эти разрешения применяются только к запросам, сделанным через SQL.
Семантическая модель — семантические модели позволяют определять безопасность с помощью DAX. Ограничения, определенные с помощью DAX, применяются к пользователям, запрашивающим семантическую модель или отчеты Power BI, созданные на основе семантической модели.
Дополнительные сведения см. в следующих статьях:
Row-level security (RLS) with Power BI (Безопасность на уровне строк (RLS) в Power BI)
Разрешения OneLake (роли доступа к данным)
OneLake имеет собственные разрешения для управления доступом к файлам и папкам в OneLake с помощью ролей доступа к данным OneLake. Роли доступа к данным OneLake позволяют пользователям создавать пользовательские роли в lakehouse и предоставлять разрешения на чтение только указанным папкам при доступе к OneLake. Для каждой роли OneLake пользователи могут назначать пользователей, группы безопасности или предоставлять автоматическое назначение на основе роли рабочей области.
Узнайте больше о модели oneLake Data контроль доступа и ознакомьтесь с руководствами.
Порядок операций
Структура имеет три разных уровня безопасности. Чтобы получить доступ к данным, пользователь должен иметь доступ на каждом уровне. Каждый уровень оценивается последовательно, чтобы определить, имеет ли пользователь доступ. Такие правила безопасности, как политики Microsoft Information Protection, оцениваются на определенном уровне, чтобы разрешить или запретить доступ. Порядок операции при оценке безопасности Fabric:
- Проверка подлинности записи. Проверяет, может ли пользователь пройти проверку подлинности в клиенте Microsoft Entra.
- Доступ к структуре. Проверяет, может ли пользователь получить доступ к Microsoft Fabric.
- Безопасность данных. Проверяет, может ли пользователь выполнить запрошенное действие в таблице или файле.
Примеры
В этом разделе приведены два примера настройки разрешений в Fabric.
Пример 1. Настройка разрешений группы
Wingtip Toys настраивается с одним клиентом для всей организации и тремя емкостями. Каждая емкость представляет собой другой регион. Wingtip Toys работает в США, Европе и Азии. Каждая емкость имеет рабочую область для каждого отдела в организации, включая отдел продаж.
Отдел продаж имеет руководителя, руководителя отдела продаж и участников группы продаж. Wingtip Toys также использует одного аналитика всей организации.
В следующей таблице показаны требования к каждой роли в отделе продаж и настройке разрешений для их включения.
| Роль | Требование | Настройка |
|---|---|---|
| Manager | Просмотр и изменение всего содержимого отдела продаж в всей организации | Роль участника для всех рабочих областей продаж в организации |
| Руководитель команды | Просмотр и изменение всего содержимого отдела продаж в определенном регионе | Роль участника для рабочей области продаж в регионе |
| Участник группы продаж | ||
| Аналитик | Просмотр всего содержимого отдела продаж в всей организации | Роль просмотра для всех рабочих областей продаж в организации |
Wingtip также имеет квартальный отчет, который перечисляет свой доход от продаж на члена продаж. Этот отчет хранится в рабочей области финансов. С помощью безопасности на уровне строк отчет настраивается таким образом, чтобы каждый участник продаж видел только свои собственные цифры продаж. Руководители группы могут видеть данные о продажах всех участников продаж в их регионе, а менеджер по продажам может видеть данные о продажах всех участников продаж в организации.
Пример 2. Разрешения рабочей области и элемента
При совместном использовании элемента или изменении его разрешений роли рабочей области не изменяются. В этом разделе показано, как взаимодействуют разрешения рабочей области и элемента.
Вероника и Марта работают вместе. Вероника является владельцем отчета, который она хочет поделиться с Мартой. Если Veronica делится отчетом с Marta, Марта сможет получить доступ к нему независимо от роли рабочей области, которая у нее есть.
Предположим, что Marta имеет роль средства просмотра в рабочей области, в которой хранится отчет. Если Veronica решит удалить разрешения на элемент Marta из отчета, Марта по-прежнему сможет просматривать отчет в рабочей области. Marta также сможет открыть отчет из рабочей области и просмотреть его содержимое. Это связано с тем, что Marta имеет разрешения на просмотр рабочей области.
Если Veronica не хочет, чтобы Marta просматривал отчет, удаление разрешений на элемент Marta из отчета недостаточно. Veronica также необходимо удалить разрешения средства просмотра Marta из рабочей области. Без разрешений средства просмотра рабочей области Марта не сможет увидеть, что отчет существует, так как он не сможет получить доступ к рабочей области. Марта также не сможет использовать ссылку на отчет, так как у нее нет доступа к отчету.
Теперь, когда Марта не имеет роли просмотра рабочей области, если Вероника решает поделиться отчетом с ней снова, Марта сможет просмотреть его с помощью ссылки Veronica общих папок с ней, не имея доступа к рабочей области.
Пример 3. Разрешения приложения Power BI
При совместном использовании отчетов Power BI часто требуется, чтобы получатели имели доступ только к отчетам, а не к элементам в рабочей области. Для этого можно использовать приложения Power BI или предоставлять доступ к отчетам непосредственно пользователям.
Кроме того, можно ограничить доступ средства просмотра к данным с помощью безопасности на уровне строк (RLS) с помощью RLS, с помощью RLS можно создавать роли, имеющие доступ к определенным частям данных, и ограничить результаты, возвращая только доступ к удостоверениям пользователя.
Это работает хорошо при использовании моделей импорта, так как данные импортируются в семантической модели, и получатели имеют доступ к этому в рамках приложения. При использовании DirectLake отчет считывает данные непосредственно из Lakehouse, а получатель отчета должен иметь доступ к этим файлам в озере. Это можно сделать несколькими способами:
- Предоставьте
ReadDataразрешение непосредственно на Lakehouse. - Переключите учетные данные источника данных из Единый вход (SSO) на фиксированное удостоверение, которое имеет доступ к файлам в озере.
Так как RLS определен в семантической модели, данные будут считываться сначала, а затем строки будут отфильтрованы.
Если в конечной точке аналитики SQL определена какая-либо безопасность, созданная отчетом, запросы автоматически возвращаются в режим DirectQuery. Если вы не хотите использовать это резервное поведение по умолчанию, вы можете создать новый Lakehouse с помощью сочетаний клавиш для таблиц в исходном Lakehouse и не определить RLS или OLS в SQL в новом Lakehouse.