Как безопасность OneLake контролирует доступ к данным

Безопасность OneLake — это система, основанная на ролях, которая определяет, кто может получать доступ к данным в OneLake и какие действия он может предпринимать с этими данными. Понимание модели контроля доступа к данным помогает предоставлять пользователям только тот доступ, который им необходим, чтобы защитить конфиденциальные данные, при этом позволяя нужным людям работать с ними.

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

Роли безопасности OneLake

Безопасность OneLake использует модель управления доступом на основе ролей (RBAC) для управления доступом к данным в OneLake. В опыте безопасности OneLake каждая роль включает следующие компоненты:

  • Разрешения: Разрешения, которые роль предоставляет для данных, такие как чтение или чтение и запись.
  • Тип: Тип роли. Средства безопасности OneLake поддерживают только роли Grant, которые предоставляют участникам доступ к данным, связанным с этой ролью. Не поддерживаются роли Deny, которые запрещают доступ.
  • Данные в роли: Таблицы, папки или схемы, к которым роль предоставляет доступ. Вы также можете задать доступ к данным с помощью безопасности на уровне строк и столбцов в таблицах.
  • Участники в ролях: Идентификаторы Microsoft Entra, назначенные роли, такие как пользователи, группы или непользовательские личности. Если вы назначаете группу Microsoft Entra, система безопасности OneLake назначает эту роль всем участникам этой группы.

Безопасность OneLake использует модель отказа по умолчанию, поэтому пользователи начинают без доступа к данным, если только роль безопасности OneLake явно не предоставляет доступ. Некоторые элементы Fabric начинаются с ролей по умолчанию, которые дают пользователям базовый доступ на основе прав на рабочее пространство.

Разрешения и поддерживаемые элементы

Роли безопасности OneLake поддерживают следующие разрешения:

  • Читать: Предоставляет пользователю возможность считывать данные из таблицы и просматривать связанные с ней метаданные таблицы и столбца. С точки зрения SQL, это разрешение эквивалентно обоим VIEW_DEFINITION и SELECT. Для получения дополнительной информации см. раздел «Безопасность метаданных».
  • ReadWrite: Предоставляет пользователю возможность читать и записывать данные в таблице или папке, а также просматривать соответствующие метаданные таблицы и столбцов. В терминах SQL это разрешение эквивалентно ALTER, DROP, UPDATE, и INSERT. Дополнительные сведения см. в разделе Разрешение ReadWrite.

Вы можете создавать роли безопасности OneLake для следующих элементов Fabric:

Предмет из ткани Поддерживаемые разрешения
Объединенное хранилище данных Чтение, Чтение и Запись
зеркальный каталог Azure Databricks Читать
Зеркальные базы данных Читать
Зеркальные каталоги Читать

Разрешение на чтение и запись

Используйте разрешение ReadWrite, чтобы предоставить пользователям с правами только на чтение право записи для определённых данных в элементе.

ReadWrite применяется только к пользователям, имеющим разрешение Read для элемента, например к пользователям с ролью Viewer в рабочей области. Назначение разрешения ReadWrite ролям рабочего пространства — администратор, участник или участник с правом внесения изменений — не имеет эффекта, поскольку эти роли уже имеют права на запись.

ReadWrite включает все привилегии, предоставленные разрешением чтения, а также предоставляет доступ к выбранному объекту и его содержимому. Например, разрешение ReadWrite в папке даёт доступ к записи как в папку, так и на данные внутри неё.

Пользователи с разрешением ReadWrite могут выполнять следующие действия:

  • Создайте, удалите или переименуйте папку или таблицу.
  • Загрузите или отредактируйте файл.
  • Создайте, удалите или переименуйте ярлык.

Пользователи могут выполнять операции записи через ноутбуки Spark, файловый проводник OneLake или API OneLake. Поскольку Fabric поддерживает запись данных только одним механизмом, пользователи с разрешением ReadWrite могут записывать в эти данные только через OneLake. Все механизмы обработки запросов по-прежнему последовательно обеспечивают выполнение операций чтения.

Роли безопасности OneLake, предоставляющие разрешение на ReadWrite, не могут содержать ограничения безопасности на уровне строк (RLS) или на уровне столбцов (CLS).

Разрешения на безопасность и доступ к рабочей области OneLake

Роли рабочих пространств — это первая граница безопасности данных в OneLake. Они управляют плоскостью управления — то есть создают элементы Fabric и управляют ими, а также настраивают разрешения, — и распространяются на все элементы рабочей области. Для получения сведений о конкретных разрешениях OneLake, предоставляемых каждой ролью рабочей области, см. Предоставление доступа с помощью ролей рабочей области. Чтобы узнать больше о ролях в рабочих пространствах, смотрите раздел «Роли в рабочих пространствах» в Fabric.

Помимо доступа к плоскости управления, роли рабочей области также могут предоставлять доступ к элементам данных через роли безопасности OneLake, назначаемые по умолчанию. (Роли по умолчанию применяются только к наблюдателям, поскольку роли администратора, участника и автора имеют расширенный доступ благодаря разрешению Write.) Роль по умолчанию — это обычная роль безопасности OneLake, которую Fabric автоматически создаёт для каждого нового элемента. Он предоставляет пользователям разрешения определенной рабочей области или элемента по умолчанию для доступа к данным в этом элементе. Например, у элементов Lakehouse есть роль DefaultReader, которая позволяет пользователям с разрешением ReadAll получать доступ к данным в Lakehouse. Этот стандартный доступ гарантирует, что пользователи, работающие с новым элементом, имеют базовый уровень доступа. Все стандартные роли используют функцию виртуализации участников, так что участники роли — это любые пользователи в этом рабочем пространстве с необходимым разрешением. Например, все пользователи с разрешением ReadAll для lakehouse.

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

Предмет из ткани Имя роли Разрешение предоставлено Назначенные члены
Объединенное хранилище данных DefaultReader Читать Все пользователи с разрешением "Чтение всех данных"
зеркальный каталог Azure Databricks DefaultReader Читать Все пользователи с разрешением на чтение
Зеркальный каталог DefaultReader Читать Все пользователи с разрешением на чтение
зеркальная база данных DefaultReader Читать Все пользователи с разрешением "Чтение всех данных"

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

Доступ пользователя и двигателя к данным

Безопасность OneLake по умолчанию установлена на наименее привилегированный доступ. Некоторые операции на уровне хранилища не могут применять RLS или CLS, поэтому когда запрос нельзя безопасно отфильтровать, OneLake полностью блокирует его, чтобы не рисковать раскрытием данных, которые пользователю запрещено видеть. Будет ли запрос отфильтрован или заблокирован — зависит от пути доступа — поддерживаемого движка запросов или прямого пользовательского доступа.

Для движков, поддерживающих фильтрацию RLS и CLS, а также требований к каждой из них, см. раздел Read data secured with OneLake security.

Сфера применения и обеспечение соблюдения

В этом разделе содержатся сведения о том, как роли безопасности OneLake предоставляют доступ к определенным областям, как работает этот доступ, а также способы разрешения доступа между несколькими ролями и типами доступа.

Безопасность на уровне таблицы

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

  • Папка находится в Tables/ каталоге предмета. Для элементов с поддержкой схемы папка также должна находиться в допустимой папке схемы.
  • Папка содержит _delta_log папку с соответствующими JSON-файлами для метаданных таблицы.
  • В папке нет дочерних ярлыков.

Если вы настроите RLS или CLS в таблице, OneLake отказывает в доступе, если папка таблицы не соответствует этим критериям. Без RLS или CLS OneLake рассматривает папку, не соответствующую этим критериям, как папку и применяет безопасность на уровне папки.

Безопасность на уровне строк и на уровне столбцов

Внутри роли вы можете ограничить доступ к определённым строкам и столбцам таблицы, используя безопасность на уровне строк и столбцов. Для получения дополнительной информации о том, что делает каждый элемент управления и как OneLake его обеспечивает, см. раздел «Безопасность на уровне таблицы, столбцов и строк» в OneLake. Дополнительные сведения о том, как применяются RLS и CLS, если пользователь входит в несколько ролей, см. в статье Оценка нескольких ролей безопасности OneLake.

Безопасность метаданных

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

Наследование разрешений папки и сквозной доступ

Разрешения папок влияют на иерархию в двух направлениях:

  • Наследование: Разрешения, предоставленные папке, применяются вниз к её файлам и подпапкам.
  • Просмотр и обход: Если у пользователей есть разрешение на дочерний элемент, средства безопасности OneLake позволяют им просматривать и обходить его родительские папки, чтобы они могли находить данные, к которым у них есть доступ, и переходить к ним. Обход не предоставляет доступ к соседним файлам или папкам.

Рассмотрим следующую иерархию домика на озере в OneLake:

Tables/
──── (empty folder)
Files/
────folder1
│   │   file11.txt
│   │
│   └───subfolder11
│       │   file111.txt
│       │
│       └───subfolder111
│            │   file1111.txt
│   
└───folder2
    │   file21.txt

Вы создаёте роль, Role1, которая предоставляет разрешение на чтение на subfolder11. Благодаря наследованию участники этой роли могут читать file111.txt и всё, что находится в subfolder111. Участники могут видеть folder1 и переходить через него, чтобы достичь subfolder11, но они не видят file11.txt, потому что он находится на одном уровне с subfolder11, и не видят Tables, потому что он находится на одном уровне с Files.

Files/
│
└───folder1
│   │
│   └───subfolder11 <-- READ
│       │   file111.txt
│       │
│       └───subfolder111
│            │   file1111.txt

Вы создаёте ещё одну роль, Role2, которая предоставляет разрешение чтения для folder2. Благодаря наследованию члены могут читать file21.txt. Участники могут пройти через folder2 и Files, чтобы добраться до него, но они не могут видеть folder1 или какие-либо его дочерние элементы.

Files/
│
└───folder2 <-- READ
    │   file21.txt

Для сочетаний клавиш поведение немного отличается. Ярлыки на внешние источники данных работают так же, как папки. Однако короткие пути к другим локациям OneLake имеют специализированное поведение. Целевые разрешения ярлыка определяют доступ к ярлыку OneLake. При выводе списка ярлыков OneLake не выполняет запрос для проверки наличия доступа к целевому объекту. В результате, когда вы просматриваете содержимое каталога, OneLake возвращает все внутренние ярлыки независимо от наличия у вас доступа к целевому объекту. Проверка прав доступа выполняется при попытке открыть ярлык, после чего вы видите только те данные, на просмотр которых у вас есть необходимые права.

Ярлыки

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

  • Passthrough: Ярлык использует личность пользователя, отправляющего запрос, чтобы получить доступ к цели. Passthrough — это стандартный вариант для ярлыков OneLake-to-OneLake.
  • Делегированный доступ: Ярлык использует настроенную учетную запись подключения или учетные данные для доступа к целевому объекту. Ярлыки OneLake-to-OneLake могут использовать делегированную аутентификацию, а ярлыки для внешних систем всегда используют делегированную аутентификацию.

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

Безопасность OneLake в сквозном доступе через ярлыки

Когда пользователь получает доступ к данным через сквозной ярлык OneLake-to-OneLake, OneLake использует удостоверение личности пользователя, инициировавшего запрос, для авторизации доступа к целевому пути. Эффективный доступ пользователя ограничен его правами как на коротком пути, так и на целевом пути.

Примечание.

Идентификация движка запросов и аутентификация ярлыков — это отдельные настройки. Ярлык сквозного доступа обычно использует учётные данные вызывающего пользователя для доступа к целевому объекту. Однако семантические модели Power BI, использующие Direct Lake над конечными точками аналитики SQL и SQL в режиме делегированной идентичности, используют идентичность владельца потребительского товара или источника данных. Это поведение не меняет настроенный режим аутентификации ярлыка. Для передачи идентификации пользователя от конца до конца используйте Direct Lake вместо OneLake или настройте конечную точку аналитики SQL для использования режима доступа к идентификации пользователя.

Нельзя напрямую настроить разрешения безопасности OneLake на ярлыке OneLake-to-OneLake. Разрешения в папке, содержащей ярлык, объединяются с разрешениями на целевом пути. Если целевой элемент поддерживает безопасность OneLake, пользователю нужен доступ через роль безопасности OneLake. Если целевой элемент не поддерживает безопасность OneLake, пользователю потребуется разрешение Fabric ReadAll на целевом элементе. Пользователю не требуется разрешение на чтение Fabric для целевого элемента только для доступа к его данным через ярлык.

Безопасность OneLake в делегированных сочетаниях клавиш

Делегированные ярлыки используют настроенную идентификацию соединения или учетные данные вместо идентификации вызывающего пользователя для доступа к целевой цели. Безопасность OneLake ограничивает доступ вызывающего пользователя через это соединение.

Делегированные сочетания клавиш OneLake

Для делегированного ярлыка OneLake-to-OneLake вызывающий пользователь видит пересечение своего доступа на пути ярлыка и доступ настроенного идентификатора соединения на целевом пути. Защита на уровне столбцов (CLS) поддерживается в обоих случаях. Безопасность на уровне строк (RLS) поддерживается для целевого пути, но для пути ярлыка нельзя определить RLS.

Делегированные внешние упрощения

Ярлыки к внешним системам, таким как ADLS, Amazon S3 и Dataverse, используют настроенные учетные данные соединения для доступа к внешнему источнику. Безопасность OneLake применяется поверх доступа, предоставленного этим учетным данным.

Например, предположим, что user1 создаёт ярлык lakehouse для папки в bucket Amazon S3, и user2 получает доступ к ярлыку из lakehouse. User2 может получить доступ к данным S3 только в том случае, если настроенные учётные данные для подключения к S3 имеют доступ к источнику, а параметры безопасности OneLake разрешают User2 доступ к пути ярлыка.

Вы можете предоставить OneLake Security доступ ко всему внешнему ярлыку доступа или к выбранным подпутям. Права доступа к папке рекурсивно наследуются всеми её подпапками, включая папки, доступные по ярлыку. Пользователь, который попадёт на внешний ярлык через другой ярлык OneLake, всё равно должен быть авторизован системой безопасности OneLake, применённой к исходному внешнему ярлыку.

Доступ к внешнему ярлыку через Spark или прямой вызов API OneLake также требует разрешения Fabric Read на элементе, содержащем внешний ярлык. Это разрешение необходимо для надёжного разрешения подключения к внешней системе.

Оцените несколько ролей безопасности OneLake

Пользователь может принадлежать к нескольким ролям безопасности OneLake. OneLake объединяет доступ, предоставленный этими ролями, в эффективную роль, которая определяет, к какому доступу может получить доступ пользователь. OneLake оценивает эффективную роль поэтапно.

Определите доступ для каждой роли

OneLake сначала решает каждую роль независимо. Внутри роли пользователь может получить доступ только к данным, разрешённым всеми тремя компонентами безопасности:

  • Безопасность на уровне объектов (OLS) определяет, к каким таблицам или папкам может обращаться роль.
  • Безопасность на уровне строк (RLS) ограничивает, к каким строкам данной таблицы может получить доступ роль.
  • Безопасность на уровне столбцов (CLS) ограничивает, к каким столбцам данной таблицы роль может получать доступ.

Поскольку применяются все три компонента, OneLake использует только их пересечение. Например, если Роль1 предоставляет доступ к Таблице 1 и ограничивает её строки и столбцы, разрешённый доступ для Роли 1 выглядит следующим образом:

Role1 = R1_OLS ∩ R1_RLS ∩ R1_CLS

Символ пересечения (∩) означает, что пользователь получает только тот доступ, который разрешён правилами OLS, RLS и CLS в этой роли.

Объединение доступа между ролями

После определения каждой роли OneLake объединяет роли, используя модель объединения, или модель с наименьшими ограничениями. Символ профсоюза (∪) означает, что доступ, предоставленный любой ролью, становится частью эффективной роли. Если Role1 предоставляет доступ к TableA, а Role2 — к TableB, пользователь, принадлежащий обеим ролям, может получить доступ к обеим таблицам.

Для двух ролей эффективной ролью является:

Effective role = Role1 ∪ Role2

Когда несколько ролей предоставляют доступ к одной и той же таблице, правила безопасности на уровне строки объединяются с оператором OR . Например, предикаты, допускающие city = 'Redmond' и city = 'New York', объединяются как city = 'Redmond' OR city = 'New York'.

Правила безопасности на уровне столбцов также объединяются в объединение, за исключением конечной точки SQL аналитики. В конечной точке аналитики SQL CLS использует более строгую семантику «отрицать». Если какая-либо роль скрывает столбец, эндпоинт блокирует доступ к этому столбцу. В результате конечная точка пересекает CLS разрешённые списки по всем ролям пользователя, вместо того чтобы объединять их в объединение.

Внимание

Сохраняйте правила RLS и CLS, которые должны применяться вместе в рамках одной роли. OneLake не поддерживает комбинацию ролей, при которой две роли позволяют использовать разные столбцы для таблицы, и каждая из ролей также применяет RLS к этой таблице. Например, пользователь не может принадлежать к Role1, который допускает столбцы c1 и c2 и подмножество строк, и Role2, который допускает столбцы c2 и c3.

Объедините доступ к ярлыку и целевому объекту

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

Для двух коротких и двух предполагаемых целевых ролей эффективный доступ таков:

Effective shortcut access = (ShortcutRole1 ∪ ShortcutRole2) ∩ (InferredRole1 ∪ InferredRole2)

В этом выражении ShortcutRole1 и ShortcutRole2 — роли в расположении ярлыка. InferredRole1 и InferredRole2 — это соответствующие предполагаемые роли, выведенные из целевого объекта ярлыка. Каждая роль формируется на основе своих компонентов OLS, RLS и CLS, прежде чем OneLake объединит роли.

Ограничения безопасности OneLake

  • При назначении роли безопасности OneLake гостевому пользователю B2B необходимо настроить параметры внешней совместной работы для B2B в Внешняя идентификация Microsoft Entra. Установите настройку доступа гостевого пользователя так: Гостевые пользователи имеют такой же доступ, как и участники (наиболее инклюзивные).

  • Если добавить список рассылки в роль в системе безопасности OneLake, конечная точка аналитики SQL не сможет определить участников этого списка для применения контроля доступа. В результате пользователи, по-видимому, не являются членами этой роли, когда обращаются к SQL-аналитике. Direct Lake на SQL семантических моделях тоже подвержен этому ограничению.

  • Блокноты Spark требуют, чтобы среда была 3.5 или выше и использовала Fabric runtime 1.3.

  • Lakehouse без схемы не поддерживают предварительный просмотр данных для таблиц, защищённых с помощью RLS и CLS. Используйте lakehouses с поддержкой схем и безопасностью OneLake.

  • Безопасность OneLake не работает с Azure Data Share или Purview Data Share. Дополнительные сведения см. в статье Azure Data Share.

  • В следующей таблице приведены ограничения ролей безопасности OneLake.

    Сценарий Лимит
    Максимальное количество ролей безопасности OneLake для элемента системы Fabric 250 ролей на элемент (см. примечание)
    Максимальное число членов для каждой роли безопасности OneLake 500 пользователей или групп пользователей для каждой роли
    Максимальное количество разрешений за одну роль безопасности в OneLake 500 разрешений на роль

    Примечание.

    Вы можете запросить увеличение количества ролей для каждого элемента до 1 000. Чтобы запросить увеличение, свяжитесь с Службой поддержки Azure.

Задержки

Чтобы применить изменения определений ролей, потребуется около 5 минут.

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

Связанные материалы

  • Last updated on