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

Благодаря безопасности OneLake Microsoft Fabric расширяет возможности управления и принудительного доступа к данным в разных рабочих нагрузках. Эта новая платформа безопасности обеспечивает администраторам большую гибкость для настройки разрешений. Администраторы могут выбирать между централизованным управлением с помощью OneLake или детализированного элемента управления на основе SQL в конечной точке аналитики SQL.

Режимы доступа в конечной точке аналитики SQL

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

Режим удостоверения пользователя: обеспечивает безопасность с помощью ролей и политик OneLake. В этом режиме конечная точка аналитики SQL передает удостоверение пользователя, выполнившего вход, в OneLake, и доступ на чтение полностью регулируется правилами безопасности, определенными в OneLake. Поддерживаются разрешения на уровне SQL для таблиц, обеспечивая согласованное управление такими инструментами, как Power BI, записные книжки и lakehouse.
Режим делегированного удостоверения: предоставляет полный контроль с помощью SQL. В этом режиме конечная точка аналитики SQL подключается к OneLake с помощью удостоверения владельца рабочей области или элемента , а безопасность регулируется исключительно разрешениями SQL , определенными внутри базы данных. Эта модель поддерживает традиционные подходы к безопасности, включая GRANT, REVOKE, пользовательские роли, Row-Level безопасность и динамическое маскирование данных.

Каждый режим поддерживает различные модели управления. Понимание их последствий важно для выбора правильного подхода в среде Fabric.

Сравнение режимов доступа

Ниже приведена четкая и краткая таблица сравнения, посвященная тому, как и где вы устанавливаете безопасность в режиме удостоверения пользователя и делегированном режиме идентификации, разделенные по типам объектов и политикам доступа к данным:

Целевой объект безопасности	Режим удостоверения пользователя	Режим делегированного удостоверения
Tables	Доступ управляется ролями безопасности OneLake. SQL `GRANT`/`REVOKE` не разрешен.	Полный контроль с помощью SQL `GRANT`/`REVOKE`.
Views	Используйте SQL GRANT/REVOKE для назначения разрешений.	Используйте SQL GRANT/REVOKE для назначения разрешений.
Хранимые процедуры	Используйте SQL GRANT EXECUTE для назначения разрешений.	Используйте SQL GRANT EXECUTE для назначения разрешений.
Функции	Используйте SQL GRANT EXECUTE для назначения разрешений.	Используйте SQL GRANT EXECUTE для назначения разрешений.
безопасностьRow-Level (RLS)	Определяется в пользовательском интерфейсе OneLake как часть ролей безопасности OneLake.	Определяется с помощью ПОЛИТИКИ БЕЗОПАСНОСТИ SQL CREATE.
безопасностьColumn-Level (CLS)	Определяется в пользовательском интерфейсе OneLake как часть ролей безопасности OneLake.	Определяется с помощью SQL GRANT SELECT со списком столбцов.
Динамическое маскирование данных (DDM)	Не поддерживается в безопасности OneLake.	Определяется с помощью sql `ALTER TABLE` с `MASKED` параметром.

Режим удостоверения пользователя в безопасности OneLake

В режиме идентификации пользователя конечная точка аналитики SQL использует механизм сквозной проверки подлинности для принудительного доступа к данным. Когда пользователь подключается к конечной точке аналитики SQL, его идентификатор записи передается в OneLake, который выполняет проверку разрешений. Все операции чтения в таблицах оцениваются с помощью правил безопасности, определенных в OneLake Lakehouse, а не с помощью инструкций GRANT или REVOKE на уровне SQL.

Этот режим позволяет централизованно управлять безопасностью, обеспечивая согласованное применение всех возможностей Fabric, включая Power BI, записные книжки, lakehouse и конечную точку аналитики SQL. Он предназначен для моделей управления, где доступ должен быть определен один раз в OneLake и автоматически уважается везде.

В режиме удостоверения пользователя:

Доступ к таблицам полностью регулируется безопасностью OneLake. Инструкции SQL GRANT/REVOKE в таблицах игнорируются.
RLS (Row-Level security), CLS (Column-Level Security) и Object-Level Security определены в интерфейсе OneLake.
Разрешения SQL допускаются для объектов, не являющихся данными, таких как представления, хранимые процедуры и функции, что обеспечивает гибкость для определения пользовательской логики или точек входа с пользователем.
Операции записи не поддерживаются в конечной точке аналитики SQL. Все записи должны выполняться через пользовательский интерфейс Lakehouse и управляются ролями рабочей области (администратор, член, участник).

Это важно

Для правильной синхронизации конечных точек Аналитики SQL требуется сопоставление между разрешениями элемента и членами роли безопасности OneLake. Если вы предоставляете удостоверению доступ к роли безопасности OneLake, то то же удостоверение должно иметь разрешение На чтение Fabric в lakehouse. Например, если пользователь назначает "user123@microsoft.com" роли безопасности OneLake, то "user123@microsoft.com" также должен быть назначен для этого lakehouse.

Поведение роли рабочей области

Пользователи с ролью администратора, участника или участника на уровне рабочей области не подлежат принудительному применению безопасности OneLake. Эти роли имеют повышенные привилегии и будут полностью обходить политики RLS, CLS и OLS. Следуйте этим требованиям, чтобы обеспечить соблюдение безопасности OneLake:

Назначение пользователям роли просмотра в рабочей области или
Поделитесь конечной точкой Lakehouse или аналитики SQL с пользователями, использующими разрешения только для чтения . Только пользователи с доступом только для чтения фильтруются в соответствии с ролями безопасности OneLake.

Приоритет ролей: большинство побед доступа в разрешительном доступе

Если пользователь принадлежит нескольким ролям OneLake, самая разрешительная роль определяет их эффективный доступ. Рассмотрим пример.

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

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

Синхронизация безопасности между конечной точкой Аналитики OneLake и SQL

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

Служба синхронизации безопасности отвечает за следующее:

Обнаружение изменений ролей OneLake, включая новые роли, обновления, назначения пользователей и изменения таблиц.
Преобразование политик OneLake (RLS, CLS, OLS) в эквивалентные структуры ролей базы данных, совместимые с SQL.
Обеспечение правильной проверки контекстных объектов (таблиц, полученных из других озерных домов), чтобы исходные параметры безопасности OneLake были учтены даже при удаленном доступе.

Эта синхронизация гарантирует, что определения безопасности OneLake остаются достоверными, устраняя необходимость ручного вмешательства на уровне SQL для репликации поведения безопасности. Так как безопасность применяется централизованно:

Вы не можете определить RLS, CLS или OLS напрямую с помощью T-SQL в этом режиме.
Вы по-прежнему можете применять разрешения SQL к представлениям, функциям и хранимым процедурам с помощью инструкций GRANT или EXECUTE.

Ошибки синхронизации безопасности и разрешение

Scenario	Поведение в режиме удостоверения пользователя	Поведение в делегированном режиме	Исправление действия	Примечания.
Политика RLS ссылается на удаленный или переименованный столбец	Ошибка: Политика безопасности на уровне строк ссылается на столбец, который больше не существует.База данных вводит состояние ошибки до тех пор, пока политика не будет исправлена.	Ошибка: недопустимое имя столбца имени <>столбца	Обновите или удалите одну или несколько затронутых ролей или восстановите отсутствующий столбец.	Обновление необходимо будет выполнить в лейкхаусе, где была создана роль.
Политика CLS ссылается на удаленный или переименованный столбец	Ошибка: Политика безопасности на уровне столбца ссылается на столбец, который больше не существует.База данных вводит состояние ошибки до тех пор, пока политика не будет исправлена.	Ошибка: недопустимое имя столбца имени <>столбца	Обновите или удалите одну или несколько затронутых ролей или восстановите отсутствующий столбец.	Обновление необходимо будет выполнить в лейкхаусе, где была создана роль.
Политика RLS/CLS ссылается на удаленную или переименованную таблицу	Ошибка. Политика безопасности ссылается на таблицу, которая больше не существует.	Ошибка не появилась; запрос завершается автоматически, если таблица отсутствует.	Обновите или удалите одну или несколько затронутых ролей или восстановите недостающую таблицу.	Обновление необходимо будет выполнить в лейкхаусе, где была создана роль.
Политика DDM (динамическое маскирование данных) ссылается на удаленный или переименованный столбец	DDM не поддерживается из OneLake Security, необходимо реализовать через SQL.	Ошибка: недопустимое имя столбца имени <>столбца	Обновите или удалите одно или несколько затронутых правил DDM или восстановите отсутствующий столбец.	Обновите политику DDM в конечной точке аналитики SQL.
Системная ошибка (непредвиденный сбой)	Ошибка: произошла непредвиденная системная ошибка. Повторите попытку или обратитесь в службу поддержки.	Ошибка: при применении изменений таблицы к SQL произошла внутренняя ошибка.	Повторная операция; Если проблема сохраняется, обратитесь в службу поддержки Майкрософт.	N/A
У пользователя нет разрешения на артефакт	Ошибка: у пользователя нет разрешения на артефакт	Ошибка: у пользователя нет разрешения на артефакт	Предоставьте пользователю разрешение objectID {objectID} на артефакт.	Идентификатор объекта должен точно соответствовать между членом роли безопасности OneLake и разрешениями элемента Fabric. Если группа добавляется в членство в роли, то этой же группе должно быть предоставлено разрешение на чтение Fabric. Добавление члена из этой группы в элемент не считается прямым совпадением.
Субъект-пользователь не поддерживается.	Ошибка: субъект-пользователь не поддерживается.	Ошибка: субъект-пользователь не поддерживается.	Удалите пользователя {username} из роли DefaultReader	Эта ошибка возникает, если пользователь больше не считается действительным идентификатором Entra, например, если он покинул организацию или был удалён. Удалите их из роли, чтобы устранить эту ошибку.

Поведение сочетаний клавиш с синхронизацией безопасности

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

В результате:

У пользователей должен быть допустимый доступ как к источнику ярлыка (текущей конечной точке Lakehouse или аналитики SQL), таки к месту хранения данных.
Если пользователь не имеет разрешения на любую сторону, запросы завершаются ошибкой доступа.
При разработке приложений или представлений, ссылающихся на сочетания клавиш, убедитесь, что назначения ролей правильно настроены в обоих концах контекстной связи.

Эта конструкция сохраняет целостность безопасности в границах Lakehouse, но в ней представлены сценарии, в которых могут возникнуть сбои доступа, если роли кросс-Lakehouse не согласованы.

Делегированный режим в безопасности OneLake

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

SQL проверяет доступ на основе разрешений SQL (GRANT, REVOKE, RLS, CLS, DDM, ролей и т. д.).
Если запрос авторизован, система переходит к данным, хранящимся в OneLake.
Этот доступ к данным выполняется с помощью удостоверения владельца конечной точки Lakehouse или конечной точки аналитики SQL, также известной как учетная запись элемента.

В этой модели:

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

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

SQL GRANT/REVOKE на всех уровнях объектов
Определяемые SQL Row-Level Security, Column-Level Security и Dynamic Data Masking
Существующие средства и методики T-SQL, используемые базами данных или приложениями

Изменение режима доступа OneLake

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

Перейдите в рабочую область Fabric и откройте lakehouse. В правом верхнем углу переключитесь из Lakehouse в конечную точку аналитики SQL.
В верхней области навигации перейдите на вкладку "Безопасность " и выберите один из следующих режимов доступа OneLake:
- Удостоверение пользователя — использует удостоверение пользователя, вошедшего в систему. Он применяет роли OneLake.
- Делегированное удостоверение — использует удостоверение владельца элемента; применяет только разрешения SQL.
Всплывающее окно запускается для подтверждения выбора. Нажмите кнопку "Да" , чтобы подтвердить изменение.

Ограничения

Применяется только к читателям: OneLake Security управляет доступом пользователей к данным в качестве зрителей. Пользователи в других ролях рабочей области (член администратора или участник) обходят OneLake Security и сохраняют полный доступ.
Объекты SQL не наследуют владение: ярлыки отображаются в конечной точке аналитики SQL в виде таблиц. При доступе к этим таблицам напрямую или через представления, хранимые процедуры и другие производные объекты SQL не несут права владения на уровне объектов; все разрешения проверяются во время выполнения, чтобы предотвратить обход безопасности.
Краткое время простоя триггера проверки сочетаний клавиш: когда ярлыки изменяют целевой объект (например, переименование, обновление URL-адреса), база данных вступает в режим однопользовательского режима кратко, пока система проверяет новый целевой объект. В течение этого периода запросы блокируются, эти операции довольно быстро, но иногда в зависимости от разных внутренних процессов может занять до 5 минут для синхронизации.
- Создание сочетаний клавиш схемы может привести к известной ошибке, которая влияет на проверку и задержку синхронизации метаданных.
Задержка распространения разрешений: изменения разрешений не являются мгновенными. Переключение между режимами безопасности (удостоверение пользователя и делегированное) может потребовать времени для распространения до вступления в силу, но должно занять менее 1 минуты.
Зависимость уровня управления: разрешения не могут применяться к пользователям или группам, которые еще не существуют в плоскости управления рабочей областью. Необходимо предоставить общий доступ к исходному элементу, либо пользователь должен быть членом роли рабочей области просмотра. Обратите внимание, что один и тот же идентификатор объекта должен находиться в обоих местах. Группа и член этой группы не считаются совпадением.
Большинство разрешительных прав доступа преобладает: когда пользователи принадлежат нескольким группам или ролям, наиболее разрешительное эффективное разрешение учитывается в примере: если у пользователя есть как DENY через одну роль, так и GRANT через другую, функция GRANT имеет приоритет.
Ограничения делегированного режима. В делегированном режиме синхронизация метаданных в сочетаниях таблиц может завершиться ошибкой, если исходный элемент имеет политики безопасности OneLake, не предоставляющие полный доступ к таблице владельцу элемента.
Поведение DENY. Если несколько ролей применяются к одной ярлыкной таблице, пересечение разрешений следует семантике SQL Server: DENY переопределяет GRANT. Это может привести к непредвиденным результатам доступа.
Ожидаемые условия ошибки: пользователи могут столкнуться с ошибками в таких сценариях, как:
- Ярлык целевого объекта переименован или недопустим
  - Пример. Если источник таблицы был удален.
- Неправильное настройка RLS (Row-Level безопасность)
  - Некоторые выражения для фильтрации RLS не поддерживаются в OneLake и могут разрешить несанкционированный доступ к данным.
  - Удаление столбца, используемого в выражении фильтра, делает недопустимым синхронизацию RLS и метаданных, пока RLS не будет исправлена на панели безопасности OneLake.
  - Для общедоступной предварительной версии мы поддерживаем только таблицы отдельных выражений. Динамические RLS и много табличные RLS в данный момент не поддерживаются.
- ограничения безопасности Column-Level (CLS)
  - СРЕДА CLS работает путем поддержания списка разрешений столбцов. Если разрешенный столбец удален или переименован, политика CLS становится недопустимой.
  - Если clS недопустим, синхронизация метаданных блокируется до тех пор, пока правило CLS не будет исправлено на панели безопасности OneLake.
- Сбой синхронизации метаданных или разрешений
  - Если в таблице есть изменения, например переименование столбца, безопасность не реплицируется в новом объекте, и вы получите ошибки пользовательского интерфейса, показывающие, что столбец не существует.
Переименования таблиц не сохраняют политики безопасности: если роли OneLake Security (OLS) определены на уровне схемы, эти роли остаются в силе только до тех пор, пока имя таблицы не изменяется. Переименование таблицы нарушает связь, и политики безопасности не будут переноситься автоматически. Это может привести к непреднамеренное воздействие данных до тех пор, пока политики не будут повторно применяться.
Роли безопасности OneLake не могут содержать имена до 124 символов; В противном случае синхронизация безопасности не может синхронизировать роли.
Роли безопасности OneLake распространяются на конечную точку аналитики SQL с префиксом OLS_.
Изменения пользователей в ролях OLS_ не поддерживаются и могут привести к непредвиденному поведению.
Группы безопасности и списки рассылки с поддержкой почты не поддерживаются.
Владелец lakehouse должен быть членом ролей администратора, члена или рабочей области участника; В противном случае безопасность не применяется к конечной точке аналитики SQL.
Владелец lakehouse не может выступать в роли учетной записи службы для корректной работы синхронизации безопасности.

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-09-08