Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Используя безопасность OneLake, администраторы могут выбирать между централизованным управлением через OneLake или детальным управлением на основе SQL в конечной точке аналитики SQL.
Режимы доступа в конечной точке аналитики SQL
При использовании конечной точки аналитики SQL выбранный режим access определяет, как обеспечивается безопасность данных. Fabric поддерживает две разные модели доступа, каждая из которых предлагает различные преимущества в зависимости от потребностей вашей операционной деятельности и требований соответствия.
Режим идентификации пользователя: обеспечивает безопасность с помощью ролей и политик OneLake. В этом режиме конечная точка аналитики SQL передает удостоверение пользователя, выполнившего вход, в OneLake, и доступ на чтение полностью регулируется правилами безопасности, определенными в OneLake. Этот режим поддерживает разрешения на уровне SQL на объекты, не являющиеся данными, такие как представления, хранимые процедуры и функции, обеспечивая единообразное управление между такими инструментами, как Power BI, ноутбуки и Lakehouse.
Режим делегированного удостоверения: предоставляет полный контроль с помощью SQL. В этом режиме конечная точка аналитики SQL подключается к OneLake, используя идентификатор рабочего пространства или владельца элемента, а безопасность регулируется исключительно SQL-правами , определёнными внутри базы данных. Эта модель поддерживает традиционные подходы к безопасности, включая GRANT, REVOKE, пользовательские роли, безопасность на уровне строк и динамическое маскирование данных.
Каждый режим поддерживает различные модели управления. Поймите их последствия, чтобы выбрать правильный подход для вашей среды 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. | Определяется с помощью SQL CREATE SECURITY POLICY. |
| Безопасность на уровне столбцов (CLS) | Определяется как часть ролей безопасности OneLake. | Определяется с помощью SQL GRANT SELECT с списком столбцов. |
| Динамическое маскирование данных (DDM) | В системе безопасности OneLake не поддерживается. | Определяется с помощью SQL ALTER TABLE с MASKED опцией. |
Измените режим доступа к OneLake
Режим доступа определяет, как происходит аутентификация и контроль доступа к данным при запросе через аналитическую конечную точку SQL в OneLake. Новые конечные точки аналитики SQL по умолчанию создаются в режиме доступа с делегированной идентификацией. Прежде чем использовать безопасность OneLake с конечной точкой, администратор или участник должен переключить его в режим доступа к идентификации пользователя.
Note
Чтобы использовать безопасность OneLake, достаточно переключиться в режим доступа к идентификации пользователя один раз на каждый конечный пункт аналитики SQL. Конечные точки, которые вы не переключили в режим доступа с использованием удостоверения пользователя, по-прежнему используют делегированное удостоверение для проверки разрешений.
Перейдите к конечной точке SQL-аналитики.
В интерфейсе конечной точки аналитики SQL перейдите на вкладку "Безопасность ".
Выберите Просмотр режима доступа к данным>Параметры режима доступа к данным.
Выберите режим доступа к идентификации пользователя , чтобы использовать личность авторизованного пользователя и применить роли безопасности OneLake, или выберите режим доступа к делегированной идентификации , чтобы использовать идентификатор владельца предмета и применять только разрешения SQL. Затем нажмите кнопку "Применить".
Нажмите кнопку "Продолжить", чтобы подтвердить свой выбор.
Это важно
Изменение режима безопасности делает конечные точки аналитики SQL временно недоступными во всём рабочем пространстве. Это действие отменяет все выполняемые и очередные запросы во всех конечных точках аналитики SQL в этой рабочей области. Меняйте режимы только в случае необходимости, и лучше всего в нерабочее время, чтобы избежать простоя.
Режим удостоверения пользователя в безопасности OneLake
В режиме идентификации пользователя конечная точка аналитики SQL использует механизм сквозной аутентификации для управления доступом к данным. Когда пользователь подключается к конечной точке аналитики SQL, его удостоверение личности Entra ID передается в OneLake, который выполняет проверку разрешений. Все операции чтения в таблицах оцениваются с помощью правил безопасности, определенных в OneLake Lakehouse, а не с помощью инструкций на уровне GRANT SQL или REVOKE.
Этот режим позволяет централизованно управлять безопасностью, обеспечивая согласованное применение всех возможностей Fabric, включая Power BI, записные книжки, lakehouse и конечную точку аналитики SQL. Он предназначен для моделей управления, где доступ должен быть определён один раз в OneLake и автоматически соблюдается везде.
В режиме идентификации пользователя:
Доступ к таблице полностью регулируется безопасностью OneLake. Инструкции SQL
GRANT/REVOKEв таблицах игнорируются.Опыт OneLake определяет RLS (безопасность на уровне строки), CLS (безопасность на уровне столбцов) и безопасность на уровне объектов.
SQL разрешения применяются для объектов, не относящихся к данным, таких как представления, хранимые процедуры и функции, что обеспечивает гибкость для определения пользовательской логики или точек доступа для пользователей.
Операции записи не поддерживаются в конечной точке аналитики SQL. Все записи должны выполняться через страницу Lakehouse в портале Fabric и управляются ролями рабочей области (администратор, член, соавтор).
Это важно
Сопоставление удостоверений "один к одному" между производителем и потребителем (концентратор и периферийный). Когда политики безопасности OneLake переносятся от источника (элемента, в котором определена роль) к потребителю (объекту назначения, получающему доступ к данным посредством ссылки), удостоверения, назначенные ролям безопасности OneLake в источнике, должны быть сопоставлены точно 1:1 в потребителе. Тот же принцип — будь то пользователь или группа — должен получить разрешение на Fabric Read на потребительском артефакте, как и тот, что указан в роли безопасности производителя. Вложенное или эффективное членство в группах не разрешается через эту границу.
Например, если роль безопасности OneLake на сайте производителя ссылается на user123@microsoft.com, то user123@microsoft.com (этот точный идентификатор объекта) также должен иметь разрешение Fabric на чтение в потребительском лейкхаусе. Точно так же, если роль производителя ссылается на Group A, то самому Group A должно быть предоставлено разрешение Fabric Read для потребителя — предоставление этого разрешения только члену группы A не соответствует этому условию.
Для получения дополнительной информации о модели разрешений с режимом идентификации пользователя см. Как безопасность 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 и политики доступа не переносятся на уровень доступа на уровне таблиц. Вы должны определить всю фильтрацию и контроль доступа — включая доступ к схемам и таблицам, безопасность на уровне строк (RLS), безопасность на уровне столбцов (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 источника.
Рекомендации при переключении между режимами
Это важно
Переключение между идентификацией пользователя и делегированной идентификацией (в любом направлении) в настоящее время удаляет внутренние объекты метаданных, включая функции с табличным значением (TVFs) и скалярные функции. Это поведение влияет только на определения метаданных; базовые данные в OneLake не затрагиваются.
Переключение на режим удостоверения пользователя
Разрешения SQL RLS, CLS и табличного уровня игнорируются.
Роли OneLake должны быть настроены, чтобы пользователи сохраняли доступ.
Только пользователи с разрешениями на просмотр или с общим доступом только для чтения подпадают под действие политики безопасности OneLake.
Существующие роли SQL удаляются и не могут быть восстановлены.
Переключение на режим делегированного удостоверения
Роли OneLake и политики безопасности больше не применяются.
Роли SQL и политики безопасности становятся активными.
Владелец элемента должен иметь валидный доступ к OneLake, иначе все запросы могут завершиться неудачей.
Замечания
Объекты SQL не наследуют владение: Ярлыки функционируют как таблицы в конечной точке аналитики SQL, но намеренно отклоняются от стандартной цепочки владения SQL, чтобы поддерживать единую систему безопасности.
Правило без наследования: производные объекты SQL (представления, хранимые процедуры или функции) не наследуют разрешения от владельца объекта.
Проверка во время выполнения: Разрешения проверяются в соответствии с идентификацией вызывающего во время выполнения, гарантируя, что абстракции SQL не могут обойти политики, установленные на уровне OneLake.
Зависимость от управляющей плоскости и эффективная оценка идентичности: пользователи должны иметь необходимое разрешение на использование артефакта Fabric, прежде чем смогут подключиться к SQL-аналитике. Затем авторизация доступа к данным проверяет пользователя, выполнившего вход, и его фактическое членство в поддерживаемых группах Microsoft Entra на соответствие политикам безопасности OneLake в источнике данных.
Поведение оценки разрешений: оценка разрешений зависит от типа таблицы в зависимости от текущей модели применения.
Таблицы быстрого доступа: доступ может быть запрещен, если необходимые условия авторизации не выполняются. Это результат строгих мер принудительного исполнения, а не возможность DENY на основе ролей в безопасности OneLake.
Общее правило: если принудительное исполнение не может четко проверить доступ, система применяет наиболее строгий вариант.
Дизайн безопасности на уровне столбцов (CLS): CLS поддерживает строгий список разрешённых столбцов.
Переименование или удаление разрешенного столбца запрещает правило безопасности. Хотя правило сохраняется в системе, оно остается неактивным , запрещая доступ ко всему ресурсу, пока исходное именование столбцов не будет восстановлено.
Защита синхронизации: если политика недействительна, синхронизация метаданных блокируется по замыслу, пока правило не будет исправлено на панели безопасности OneLake.
Проверка схемы. Переименование столбцов без обновления политик безопасности приводит к ошибкам пользовательского интерфейса, указывающим, что столбец "не существует" до синхронизации конфигурации.
Note
В конечной точке аналитики SQL для доступа к данным применяются механизмы безопасности OneLake, в то время как метаданные схемы по-прежнему подчиняются поведению ядра SQL. Пользователи могут видеть столбцы в обозреватель объектов или
sys.columnsдаже когда уровень безопасности на уровне столбцов не позволяет им читать эти столбцы. Это поведение ожидаемо и является частью задумки.Распространение ролей и синхронизация (SLA):
Синхронизация безопасности OneLake: при изменении роли безопасности в режиме идентификации пользователя, обновление не происходит сразу. Обычно это происходит быстро, но для синхронизации с конечной точкой SQL-аналитики может потребоваться до 5 минут.
Автоматическое префиксирование: роли безопасности OneLake распространяются на SQL-аналитический конечный пункт с
OLS_префиксом.Приоритет синхронизации: процесс синхронизации
OLS_безопасности периодически обновляет состояние ролей. Изменения этих ролей вручную не поддерживаются и перезаписываются во время следующего цикла синхронизации. Если нет изменений для синхронизации, синхронизация безопасности не переопределяет вручную внесённые изменения.
Безопасность SQL и сочетания клавиш в Warehouse: Политики безопасности, определённые с помощью конструкций SQL в Warehouse, такие как защита на уровне строк (RLS), защита на уровне столбцов (CLS) или защита на уровне объектов (OLS), применяются только в контексте выполнения SQL-запросов в Warehouse (конечная точка TDS).
Это важно
Когда вы получаете доступ к данным из хранилища через ярлыки в OneLake, эти семантики безопасности SQL не переводятся в политики безопасности OneLake. В результате пользователи, получающие доступ к данным через ярлык, могут видеть полные данные хранилища, независимо от SQL-политик безопасности, настроенных в хранилище производителя.
Ограничения
Применяется только к читателям: безопасность OneLake в основном применяется для пользователей, обращаюющихся к данным через рабочую область или доступ к элементам на уровне просмотра. Пользователи с более широкими ролями рабочей области, такими как администратор, член или участник , сохраняют повышенный доступ и не являются основным объектом принудительного применения безопасности OneLake.
Исключения:
Поведение запрета ярлыка: для таблиц, поддерживаемых ярлыками, применение правил все равно может ограничивать доступ для администраторов и участников в некоторых случаях.
Случаи сбоя синхронизации безопасности. Если синхронизация безопасности не может правильно применять безопасность для определенных таблиц или ролей, пользователи в ролях администратора, участника или участника, которые являются членами этих затронутых ролей, также могут столкнуться с ограниченным доступом.
RLS в режиме идентификации пользователя: Когда безопасность на уровне строк (RLS) настроена в режиме идентификации пользователя, заданные правила безопасности применяются ко всем пользователям, включая пользователей с ролями Admin, Member и Contributor.
Видимость схемы в метаданных объекта: конечная точка аналитики 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.