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

С помощью средств безопасности 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.

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

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

Режим удостоверения пользователя в безопасности 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 или создании новой.

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

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

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

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

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

• Если пользователь не имеет разрешения на любую сторону, запросы завершаются ошибкой доступа.

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

Такая архитектура сохраняет целостность модели безопасности между границами lakehouse, но создаёт ситуации, в которых могут возникать ошибки доступа, если роли в разных lakehouse не согласованы.

Делегированный режим в безопасности 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. Вы можете переключаться между режимом удостоверения пользователя и режимом делегированного удостоверения, выполнив следующие действия.

1. Перейдите в рабочую область Fabric и откройте Lakehouse. В правом верхнем углу переключитесь с Lakehouse на SQL Analytics Endpoint.

2. В верхней области навигации перейдите на вкладку "Безопасность " и выберите один из следующих режимов доступа OneLake:

   • Удостоверение пользователя — использует удостоверение пользователя, вошедшего в систему. Принудительно применяет роли OneLake.

   • Делегированное удостоверение — использует удостоверение личности владельца элемента. Применяет только разрешения SQL.

3. Всплывающее окно запускается для подтверждения выбора. Выберите Да , чтобы подтвердить изменение.

Рекомендации при переключении между режимами

Переключение на режим удостоверения пользователя

• Разрешения SQL RLS, CLS и табличного уровня игнорируются.

• Роли OneLake должны быть настроены, чтобы пользователи сохраняли доступ.

• Только пользователи с разрешениями на просмотр или с общим доступом только для чтения подпадают под действие политики безопасности OneLake.

• Существующие роли SQL удаляются и не могут быть восстановлены.

Переключение на режим делегированного удостоверения

• Роли OneLake и политики безопасности больше не применяются.

• Роли SQL и политики безопасности становятся активными.

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

Замечания

• Объекты SQL не наследуют владение: Ярлыки функционируют как таблицы в конечной точке аналитики SQL, но намеренно отклоняются от стандартной цепочки владения SQL, чтобы поддерживать единую систему безопасности.

  • Правило без наследования: производные объекты SQL (представления, хранимые процедуры или функции) не наследуют разрешения от владельца объекта.

  • Проверка во время выполнения: Разрешения проверяются в соответствии с идентификацией вызывающего во время выполнения, гарантируя, что абстракции SQL не могут обойти политики, установленные на уровне OneLake.

  • Безопасность с учетом проектирования: политики безопасности остаются согласованными независимо от того, осуществляется доступ к данным через SQL, Spark или Power BI.

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

  • Точное совпадение ID объекта: доступ оценивается по точному идентификатору объекта, предоставленному производителем.

  • Нет вложенного или эффективного разрешения: членство в вложенных группах или косвенное наследование не рассматривается как достаточное для принудительного применения. См. пояснение в режиме идентификации пользователя в службе безопасности 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_ безопасности периодически обновляет состояние ролей. Изменения этих ролей вручную не поддерживаются и перезаписываются во время следующего цикла синхронизации. Если нет изменений для синхронизации, синхронизация безопасности не переопределяет вручную внесённые изменения.

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

Ограничения

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

  • Исключения:

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

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

    • RLS в режиме идентификации пользователя: Когда Построчная безопасность (RLS) настроена в режиме идентификации пользователя, определенные правила безопасности применяются для всех пользователей, включая роли администратора, члена и участника.

• Видимость схемы в метаданных объекта: конечная точка аналитики SQL всегда возвращает все имена схем в метаданных объекта независимо от разрешений на уровне таблицы пользователя. Таблицы, для которых у пользователя нет разрешений, отфильтровываются и не отображаются в списке.

  • В результате пользователи могут видеть схемы, которые не содержат видимых таблиц в обозревателе объектов или в INFORMATION_SCHEMA/sys запросах каталога.

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

• Осведомленность о границах шорткатов: конечная точка аналитики SQL может изначально оценивать таблицы, поддерживаемые шорткатами, с использованием стандартной семантики SQL-объектов. После синхронизации настроек безопасности политики безопасности OneLake применяются для обеспечения того, чтобы контроль доступа соответствовал границам артефактов и рабочих пространств.

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

• Изменения прав собственности на таблицы с поддержкой ярлыков: таблицы с поддержкой ярлыков представляются как объекты 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.

  • Владелец lakehouse не может выступать в роли учетной записи службы для корректной работы синхронизации безопасности.

Связанный контент

• Рекомендации по защите данных в OneLake
• модель контроля доступа безопасности OneLake