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

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

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

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

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

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

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

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

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

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

В режиме идентификации пользователя конечная точка аналитики SQL использует механизм сквозной аутентификации для управления доступом к данным. Когда пользователь подключается к конечной точке аналитики SQL, его удостоверение личности Entra ID передается в 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 в портале Fabric и управляются ролями рабочей области (администратор, член, соавтор).

Это важно

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

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

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

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

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

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

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

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

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

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

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

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

SQL GRANT/REVOKE на всех уровнях объектов
Определяемые SQL Безопасность на уровне строк, Безопасность на уровне столбцов и Динамическое сокрытие данных
Существующие средства и методики T-SQL, используемые базами данных или приложениями

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

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

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

Troubleshooting

В режиме идентификации пользователя результаты синхронизации безопасности можно проверить с помощью пользовательского интерфейса. Откройте конечную точку SQL Analytics, разверните папку "Безопасность" в обозревателе, а затем выберите роли базы данных (настраиваемые). Если синхронизация выполнена успешно, вы увидите роли, перечисленные с префиксом "ols_". Например, "ols_TestRole". Имена ролей с "ols_{alphanumericString}_rolename" являются ролями из других озерных домов, распространяемых по ярлыку.

Исправления распространенных ошибок синхронизации безопасности

Синхронизация безопасности завершится сбоем, если какая-либо из ролей будет ссылаться на удалённую таблицу. Удалите эти таблицы из ролей и повторите попытку синхронизации безопасности.
Субъекты службы (SPN) не могут быть владельцами схранилища данных. Убедитесь, что родительский элемент Lakehouse принадлежит учетной записи пользователя.
Все члены роли безопасности OneLake должны иметь права доступа Fabric Read к Lakehouse, чтобы синхронизация безопасности могла распознать пользователя или группу.

Ограничения

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

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

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

Last updated on 2026-01-30