Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
С помощью средств безопасности OneLake Fabric расширяет возможности организаций по управлению и контролю доступа к данным в разных рабочих нагрузках. Эта платформа безопасности обеспечивает администраторам большую гибкость для настройки разрешений. Администраторы могут выбирать между централизованным управлением с помощью OneLake или детализированного элемента управления на основе SQL в конечной точке аналитики SQL.
Режимы доступа в конечной точке аналитики SQL
При использовании конечной точки аналитики SQL выбранный режим access определяет, как обеспечивается безопасность данных. Fabric поддерживает две разные модели доступа, каждая из которых предлагает различные преимущества в зависимости от потребностей вашей операционной деятельности и требований соответствия.
Режим удостоверения пользователя: обеспечивает безопасность с помощью ролей и политик OneLake. В этом режиме конечная точка аналитики SQL передает удостоверение пользователя, выполнившего вход, в OneLake, и доступ на чтение полностью регулируется правилами безопасности, определенными в OneLake. Поддерживаются разрешения уровня SQL для объектов nondata (представления, хранимые процедуры, функции), обеспечивая согласованное управление такими инструментами, как Power BI, записные книжки и lakehouse.
Режим делегированного удостоверения: предоставляет полный контроль с помощью SQL. В этом режиме конечная точка аналитики SQL подключается к OneLake с помощью удостоверения владельца рабочей области или элемента , а безопасность регулируется исключительно разрешениями SQL , определенными внутри базы данных. Эта модель поддерживает традиционные подходы к безопасности, включая GRANT, REVOKE, пользовательские роли, Row-Level безопасность и динамическое маскирование данных.
Каждый режим поддерживает различные модели управления. Понимание их последствий важно для выбора правильного подхода в среде Fabric.
Это важно
Необходим доступ к артефактам для использования конечной точки SQL-аналитики. Чтобы подключиться и выполнять запросы через конечную точку аналитики SQL, пользователи должны иметь разрешение на чтение объекта, связанного с этой конечной точкой. Если у пользователя нет доступа к управляющей плоскости артефакта (например, доступа к роли рабочей области или явного разрешения на элемент), подключение к конечной точке SQL-аналитики отклоняется независимо от любых разрешений SQL, которые могут существовать для этого пользователя.
Сравнение между режимами доступа
В следующей таблице сравнивается, как и где вы устанавливаете безопасность в режиме удостоверения пользователя и делегированном режиме идентификации, разделенные по типам объектов и политикам доступа к данным:
| Целевой объект безопасности | Режим удостоверения пользователя | Режим делегированного удостоверения |
|---|---|---|
| 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 SECURITY POLICY. |
| Безопасность на уровне столбца (CLS) | Определяется в пользовательском интерфейсе OneLake как часть ролей безопасности OneLake. | Определяется с помощью SQL GRANT SELECT с списком столбцов. |
| Динамическое маскирование данных (DDM) | В системе безопасности OneLake не поддерживается. | Определяется с помощью SQL ALTER TABLE с MASKED опцией. |
Режим удостоверения пользователя в безопасности OneLake
В режиме идентификации пользователя конечная точка аналитики SQL использует механизм сквозной аутентификации для управления доступом к данным. Когда пользователь подключается к конечной точке аналитики SQL, его удостоверение личности Entra ID передается в OneLake, который выполняет проверку разрешений. Все операции чтения в таблицах оцениваются с помощью правил безопасности, определенных в OneLake Lakehouse, а не с помощью инструкций на уровне GRANT SQL или REVOKE.
Этот режим позволяет централизованно управлять безопасностью, обеспечивая согласованное применение всех возможностей 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 и управляются ролями рабочей области (администратор, член, соавтор).
Дополнительные сведения о модели разрешений с режимом идентификации пользователя см. в модели управления доступом к данным для безопасности OneLake.
Синхронизация безопасности между конечной точкой OneLake и аналитической конечной точкой SQL.
Критически важным компонентом режима идентификации пользователя является служба синхронизации безопасности. Эта фоновая служба отслеживает изменения, внесенные в роли безопасности в OneLake, и гарантирует, что эти изменения отражаются в конечной точке аналитики SQL.
Служба синхронизации безопасности отвечает за следующее:
Обнаружение изменений ролей OneLake, включая новые роли, обновления, назначения пользователей и изменения таблиц.
Преобразование политик OneLake (RLS, CLS, OLS) в эквивалентные структуры ролей базы данных, совместимые с SQL.
Обеспечение правильной проверки объектов ярлыков (таблиц, полученных из других хранилищ озёрных данных), чтобы исходные настройки безопасности OneLake были учтены даже при удаленном доступе.
Эта синхронизация гарантирует, что определения безопасности OneLake остаются достоверными, устраняя необходимость ручного вмешательства на уровне SQL для репликации поведения безопасности. Так как безопасность применяется централизованно:
Вы не можете определить RLS, CLS или OLS напрямую с помощью T-SQL в этом режиме.
Разрешения SQL по-прежнему можно применять к представлениям, функциям и хранимым процедурам с помощью
GRANTилиEXECUTEоператоров.
Повторная попытка синхронизации безопасности
Синхронизация безопасности включает механизм обратного отключения повторных попыток для защиты стабильности системы и предотвращения ненужного потребления вычислительных ресурсов:
Если при применении ролей безопасности OneLake к конечной точке аналитики SQL возникают повторяющиеся ошибки, система может временно приостановить попытки автоматической синхронизации.
Синхронизация возобновляется автоматически при изменении существующей роли безопасности OneLake или создании новой.
Ошибки синхронизации безопасности и их устранение
| Scenario | Поведение в режиме идентификации пользователя | Поведение в делегированном режиме | Корректирующее действие | Примечания. |
|---|---|---|---|---|
| Политика RLS ссылается на удаленный или переименованный столбец | Ошибка. Политика безопасности на уровне строк ссылается на столбец, который больше не существует. База данных вводит состояние ошибки до тех пор, пока политика не будет исправлена. | Ошибка: недопустимое имя столбца <column name> | Обновите или удалите одну или несколько затронутых ролей или восстановите отсутствующий столбец. | Обновление должно выполняться в лейкхаусе, где была создана роль. |
| Политика CLS ссылается на удаленный или переименованный столбец | Ошибка. Политика безопасности на уровне столбца ссылается на столбец, который больше не существует. База данных вводит состояние ошибки до тех пор, пока политика не будет исправлена. | Ошибка: недопустимое имя столбца <column name> | Обновите или удалите одну или несколько затронутых ролей или восстановите отсутствующий столбец. | Обновление должно выполняться в лейкхаусе, где была создана роль. |
| Политика RLS/CLS ссылается на удаленную или переименованную таблицу | Ошибка. Политика безопасности ссылается на таблицу, которая больше не существует. | Ошибка не появилась; запрос завершается автоматически, если таблица отсутствует. | Обновите или удалите одну или несколько затронутых ролей или восстановите недостающую таблицу. | Обновление должно выполняться в лейкхаусе, где была создана роль. |
| Политика DDM (динамическое маскирование данных) ссылается на удаленный или переименованный столбец | DDM не поддерживается из системы безопасности OneLake; необходимо реализовать с помощью SQL. | Ошибка: недопустимое имя столбца <column name> | Обновите или удалите одно или несколько затронутых правил DDM или восстановите отсутствующий столбец. | Обновите политику DDM в конечной точке аналитики SQL. |
| Системная ошибка (непредвиденный сбой) | Ошибка: произошла непредвиденная системная ошибка. Повторите попытку или обратитесь в службу поддержки. | Ошибка: при применении изменений таблицы к SQL произошла внутренняя ошибка. | Повторите операцию; Если проблема сохраняется, обратитесь к служба поддержки Майкрософт. | N/A |
| Субъект-пользователь не поддерживается | Ошибка: субъект-пользователь не поддерживается. | Ошибка: субъект-пользователь не поддерживается. | Удаление пользователя {username} из роли DefaultReader. |
Эта ошибка возникает, если пользователь больше не является допустимым Entra ID (например, пользователь покинул организацию или был удален). Удалите их из роли, чтобы устранить ошибку. |
Поведение сочетаний клавиш с синхронизацией безопасности
Безопасность OneLake обеспечивается непосредственно в источнике истины, поэтому синхронизация безопасности отключает цепочку владения для таблиц и представлений, использующих ссылки. Это гарантирует, что разрешения исходной системы всегда проверяются и учитываются, даже для запросов из другой базы данных.
В результате:
Пользователи должны иметь действующий доступ как к ярлыку источника (текущей Lakehouse или конечной точке аналитики SQL), так и к месту назначения, где физически находятся данные.
Если пользователь не имеет разрешения на любую сторону, запросы завершаются ошибкой доступа.
Такая конструкция сохраняет целостность безопасности на границах озёрных домов, одновременно снижая необходимость дублирования присвоений идентичностей между товарами производителей и потребителей.
Делегированный режим в безопасности OneLake
В режиме делегированного удостоверения конечная точка аналитики SQL сохраняет обратную совместимость с традиционной моделью безопасности SQL. Безопасность определяется и применяется на уровне подсистемы SQL, а роли безопасности OneLake и политики доступа не переносятся на доступ на уровне таблицы. Все фильтры и управление доступом, включая доступ к схемам и таблицам, Row-Level безопасность (RLS), безопасность Column-Level (CLS) и динамическое маскирование данных (DDM) должны быть определены с помощью конструкций SQL (GRANT/REVOKE, политик безопасности и т. д.).
Так как роли безопасности OneLake для конечного пользователя не применяются напрямую, любые правила безопасности, определенные в OneLake (например, правила, применяемые Spark или другими механизмами, которые считываются через OneLake), не применяются, если те же данные запрашиваются через конечную точку аналитики SQL. Выберите этот режим, когда рабочая нагрузка зависит от семантики безопасности на основе SQL или когда существующее средство T-SQL требует полной совместимости.
Когда пользователь подключается к конечной точке аналитики SQL и выдает запрос:
SQL проверяет запрос на соответствие разрешениям, определенным на уровне SQL.
Если запрос авторизован, система переходит к получению доступа к данным, хранящимся в OneLake.
Этот доступ к данным осуществляется с использованием удостоверения владельца конечной точки Lakehouse или SQL Analytics, также известного как учетная запись элемента, а не вошедшего пользователя.
Поэтому владелец элемента несет ответственность за наличие достаточных разрешений в OneLake для чтения базовых файлов от имени рабочей нагрузки. Любые несоответствия между разрешениями SQL, предоставленными конечным пользователям и доступом владельца элемента OneLake, приводят к сбоям запросов.
Этот режим поддерживает существующие средства и методики T-SQL, используемые администраторами баз данных или приложениями, с полной совместимостью для SQL GRANT/REVOKE на всех уровнях объектов и определяемых SQL RLS, CLS и DDM.
Поведение сочетаний клавиш в делегированном режиме
Так как делегированный режим подключается к OneLake с помощью удостоверения владельца элемента, ярлыки работают только при неограниченном доступе к всей исходной таблице. Если в исходной таблице применено любое правило безопасности на уровне OneLake, такое как безопасность на уровне строк (RLS) или безопасность на уровне столбцов (CLS), при этом конечная точка аналитики SQL блокирует доступ к данному ярлыку.
В результате:
Сочетания клавиш, указывающие на исходные таблицы без правил безопасности уровня данных , работают обычно в делегированном режиме.
Ярлыки, ссылающиеся на исходные таблицы с RLS или CLS в безопасности OneLake на стороне производителя, недоступны через конечную точку аналитики SQL в режиме делегирования, даже если у конечного пользователя есть разрешения SQL на объекте ярлыка.
Чтобы использовать сочетания клавиш, источник которых имеет политики безопасности OneLake, используйте режим удостоверения пользователя на конечной точке клиента, чтобы удостоверение конечного пользователя оценивалось согласно правилам безопасности OneLake источника.
Изменение режима доступа OneLake
Режим доступа определяет, как происходит аутентификация и контроль доступа к данным при запросе через аналитическую конечную точку SQL в OneLake. Вы можете переключаться между режимом удостоверения пользователя и режимом делегированного удостоверения, выполнив следующие действия.
Перейдите в рабочую область Fabric и откройте Lakehouse. В правом верхнем углу переключитесь с Lakehouse на SQL Analytics Endpoint.
В верхней области навигации перейдите на вкладку "Безопасность " и выберите один из следующих режимов доступа OneLake:
Удостоверение пользователя — использует удостоверение пользователя, вошедшего в систему. Принудительно применяет роли OneLake.
Делегированное удостоверение — использует удостоверение личности владельца элемента. Применяет только разрешения SQL.
Всплывающее окно запускается для подтверждения выбора. Выберите Да , чтобы подтвердить изменение.
Это важно
Изменение режима безопасности временно делает конечные точки аналитики SQL недоступными для всей рабочей области. Это действие отменяет все выполняемые и очередные запросы во всех конечных точках аналитики SQL в этой рабочей области. Меняйте режимы только в случае необходимости, и лучше всего в нерабочее время, чтобы избежать простоя.
Рекомендации при переключении между режимами
Это важно
Переключение между идентификацией пользователя и делегированной идентификацией (в любом направлении) в настоящее время удаляет внутренние объекты метаданных, включая функции с табличным значением (TVFs) и скалярные функции. Это поведение влияет только на определения метаданных; базовые данные в OneLake не затрагиваются.
Переключение на режим удостоверения пользователя
Разрешения SQL RLS, CLS и табличного уровня игнорируются.
Роли OneLake должны быть настроены, чтобы пользователи сохраняли доступ.
Только пользователи с разрешениями на просмотр или с общим доступом только для чтения подпадают под действие политики безопасности OneLake.
Существующие роли SQL удаляются и не могут быть восстановлены.
Переключение на режим делегированного удостоверения
Роли OneLake и политики безопасности больше не применяются.
Роли SQL и политики безопасности становятся активными.
Владелец элемента должен иметь валидный доступ к OneLake, иначе все запросы могут завершиться неудачей.
Замечания
Объекты SQL не наследуют владение: Ярлыки функционируют как таблицы в конечной точке аналитики SQL, но намеренно отклоняются от стандартной цепочки владения SQL, чтобы поддерживать единую систему безопасности.
Правило без наследования: производные объекты SQL (представления, хранимые процедуры или функции) не наследуют разрешения от владельца объекта.
Проверка во время выполнения: Разрешения проверяются в соответствии с идентификацией вызывающего во время выполнения, гарантируя, что абстракции SQL не могут обойти политики, установленные на уровне OneLake.
Зависимость от управляющей плоскости и эффективная оценка идентичности: пользователи должны иметь необходимое разрешение на использование артефакта Fabric, прежде чем смогут подключиться к SQL-аналитике. Затем авторизация доступа к данным проверяет пользователя, выполнившего вход, и его фактическое членство в поддерживаемых группах Microsoft Entra на соответствие политикам безопасности OneLake в источнике данных.
Поведение оценки разрешений: оценка разрешений зависит от типа таблицы в зависимости от текущей модели применения.
Таблицы быстрого доступа: доступ может быть запрещен, если необходимые условия авторизации не выполняются. Это результат строгих мер принудительного исполнения, а не возможность DENY на основе ролей в безопасности OneLake.
Общее правило: если принудительное исполнение не может четко проверить доступ, система применяет наиболее строгий вариант.
Дизайн Column-Level Security (CLS): CLS поддерживает строгий разрешающий список столбцов.
Переименование или удаление разрешенного столбца запрещает правило безопасности. Хотя правило сохраняется в системе, оно остается неактивным , запрещая доступ ко всему ресурсу, пока исходное именование столбцов не будет восстановлено.
Защита синхронизации: если политика недействительна, синхронизация метаданных блокируется по замыслу, пока правило не будет исправлено на панели безопасности OneLake.
Проверка схемы. Переименование столбцов без обновления политик безопасности приводит к ошибкам пользовательского интерфейса, указывающим, что столбец "не существует" до синхронизации конфигурации.
Note
В конечной точке аналитики SQL для доступа к данным применяются механизмы безопасности OneLake, в то время как метаданные схемы по-прежнему подчиняются поведению ядра SQL. Пользователи могут видеть столбцы в обозреватель объектов или
sys.columnsдаже если Column-Level Security запрещает им читать эти столбцы. Это поведение ожидаемо и является частью задумки.Распространение ролей и синхронизация (SLA):
Синхронизация безопасности OneLake: при изменении роли безопасности в режиме идентификации пользователя, обновление не происходит сразу. Обычно это происходит быстро, но для синхронизации с конечной точкой SQL-аналитики может потребоваться до 5 минут.
Автоматическое префиксирование: роли безопасности OneLake распространяются на SQL-аналитический конечный пункт с
OLS_префиксом.Приоритет синхронизации: процесс синхронизации
OLS_безопасности периодически обновляет состояние ролей. Изменения этих ролей вручную не поддерживаются и перезаписываются во время следующего цикла синхронизации. Если нет изменений для синхронизации, синхронизация безопасности не переопределяет вручную внесённые изменения.
Это важно
Когда вы получаете доступ к данным из хранилища через ярлыки в OneLake, эти семантики безопасности SQL не переводятся в политики безопасности OneLake. В результате пользователи, получающие доступ к данным через ярлык, могут видеть полные данные хранилища, независимо от SQL-политик безопасности, настроенных в хранилище производителя.
Ограничения
Применяется только к читателям: безопасность OneLake в основном применяется для пользователей, обращаюющихся к данным через рабочую область или доступ к элементам на уровне просмотра. Пользователи с более широкими ролями рабочей области, такими как администратор, член или участник , сохраняют повышенный доступ и не являются основным объектом принудительного применения безопасности OneLake.
Исключения:
Поведение запрета ярлыка: для таблиц, поддерживаемых ярлыками, применение правил все равно может ограничивать доступ для администраторов и участников в некоторых случаях.
Случаи сбоя синхронизации безопасности. Если синхронизация безопасности не может правильно применять безопасность для определенных таблиц или ролей, пользователи в ролях администратора, участника или участника, которые являются членами этих затронутых ролей, также могут столкнуться с ограниченным доступом.
RLS в режиме идентификации пользователя: Когда Построчная безопасность (RLS) настроена в режиме идентификации пользователя, определенные правила безопасности применяются для всех пользователей, включая роли администратора, члена и участника.
Видимость схемы в метаданных объекта: конечная точка аналитики SQL всегда возвращает все имена схем в метаданных объекта независимо от разрешений на уровне таблицы пользователя. Таблицы, для которых у пользователя нет разрешений, отфильтровываются и не отображаются в списке.
- В результате пользователи могут видеть схемы, которые не содержат видимых таблиц в обозревателе объектов или в
INFORMATION_SCHEMA/sysзапросах каталога.
- В результате пользователи могут видеть схемы, которые не содержат видимых таблиц в обозревателе объектов или в
Зависимость от синхронизации безопасности: в режиме идентификации пользователя процесс синхронизации безопасности синхронизирует роли безопасности OneLake с конечной точкой аналитики SQL. До завершения синхронизации SQL может временно оценивать доступ, используя существующее состояние SQL-прав для всех таблиц, включая таблицы ярлыков из других элементов. После завершения синхронизации конечная точка SQL отражает конфигурацию безопасности OneLake.
Изменения прав собственности на таблицы с поддержкой ярлыков: таблицы с поддержкой ярлыков представляются как объекты SQL в конечной точке аналитики SQL и, следовательно, поддерживают стандартные операции прав собственности SQL. Административные команды, такие как
ALTER AUTHORIZATION, могут изменить владельца таблицы, поддерживаемой ярлыком. В некоторых сценариях это может позволить работе цепочек владения, которые могут обойти политики безопасности OneLake и предоставить непреднамеренный доступ к базовым данным. До внедрения дополнительных механизмов контроля администраторы должны избегать изменения владения в таблицах, поддерживаемых ярлыками.Время простоя проверки целевого объекта: При изменении цели ярлыка (например, переименовании или обновлении URL-адреса) база данных кратко переходит в однопользовательский режим для проверки нового целевого объекта. В течение этого периода запросы блокируются. Обычно эти операции выполняются быстро, но в зависимости от внутренних процессов может занять до 5 минут для синхронизации.
- Создание сокращений схемы может вызвать известную ошибку, которая влияет на проверку и задержки синхронизации метаданных.
Кэширование маркеров делегированного режима. В делегированном режиме конечная точка аналитики SQL кэширует маркер доступа к хранилищу, используемый для извлечения данных из OneLake от имени удостоверения владельца. Если разрешения владельца изменяются, ранее выданный маркер может оставаться действительным до истечения срока действия. В результате изменения доступа, привязанные к удостоверению владельца, могут не вступили в силу немедленно и могут сохраняться до истечения срока действия маркера, как правило, до 30–60 минут.
Изменения политик безопасности OneLake GRANT/DENY применяются немедленно и не задерживаются кэшированием токена хранилища.
Отмена активного запроса. Для поддержания целостности данных и безопасности активные запросы могут быть автоматически отменены при изменении сочетания клавиш во время выполнения.
Ограничения безопасности на уровне строк (RLS):
Поддерживаются только таблицы с одним выражением. Динамические и многотабличные RLS недоступны.
Удаление столбца, используемого в выражении фильтра, останавливает синхронизацию метаданных, пока RLS не будет исправлена на панели безопасности OneLake.
Сложность ролей и синхронизация метаданных: высокая сложность ролей безопасности, в частности с участием многочисленных пересечений и семантики объединения с помощью RLS, может привести к сбою синхронизации безопасности. Сбой синхронизации безопасности предотвращает применение политик безопасности и блокирует возможность синхронизации метаданных.
Ограничения схемы и роли:
Переименование: роли безопасности OneLake привязаны к имени таблицы. Переименование таблицы нарушает связь, а политики не переносятся автоматически. Это может привести к непреднамеренному раскрытию данных до тех пор, пока политики не будут повторно применены.
Ограничения символов: имена ролей безопасности OneLake не могут превышать 124 символов; в противном случае создание роли или синхронизация завершается ошибкой в конечной точке аналитики SQL.
OLS_изменения ролей: изменения пользователей вOLS_ролях не поддерживаются и могут привести к непредвиденным поведению.
Неподдерживаемые удостоверения: группы безопасности с поддержкой электронной почты и списки рассылки в настоящее время не поддерживаются.
Требования владельца Lakehouse:
- Владелец lakehouse должен быть членом ролей рабочей области "Администратор", "Член" или "Участник"; В противном случае безопасность не применяется к конечной точке аналитики SQL.