Разрешения для ярлыков Microsoft Fabric: внутренние и внешние правила безопасности

By Mirko Peters · 2026-10-30

Разберитесь, как работают разрешения для ярлыков Microsoft Fabric: сравниваем сквозную передачу идентичности внутреннего пользователя и правила безопасности для внешних сохранённых подключений.

Automatically translated with AI from the original post. Read the English original

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

Главное

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

Как работают разрешения для ярлыков Microsoft Fabric

Когда вы настраиваете указатели между разными источниками данных в OneLake, безопасность редко бывает настройкой «задал и забыл». В отличие от традиционных моделей хранилищ данных, где разрешения централизованы и единообразно применяются к клонированным таблицам, ярлыки Fabric создают проблему раздвоенной идентичности. Есть путь ярлыка, с которого пользователь начинает запрос, и целевой путь, где физически находятся данные. Fabric оценивает оба конечных пункта, прежде чем вернуть хотя бы одну строку данных, поэтому архитектура безопасности становится важным обязательным условием проектирования для облачных администраторов.

Основная философия безопасности Fabric опирается на принцип наименьших привилегий, но ярлыки обходят правила традиционного доступа к данным. Поскольку при создании ярлыка данные не перемещаются, разрешения, привязанные к базовой учётной записи хранения, внешнему бакету Amazon S3 или связанному lakehouse, необходимо тщательно сопоставить. Если пользователь имеет доступ на чтение к рабочей области с ярлыком, но не имеет доступа к исходному контейнеру, запрос завершится ошибкой. И наоборот, чрезмерно широкие разрешения для идентичности сохранённого подключения могут непреднамеренно открыть конфиденциальные внешние файлы неавторизованным опытным пользователям.

Внутренние ярлыки и распространение идентичности пользователя

Внутренние ярлыки, то есть указывающие с одного элемента Fabric на другой, например с lakehouse в рабочей области продаж на общую таблицу клиентов, работают с вашей точной идентичностью Entra ID. Когда вы запрашиваете внутренний ярлык, Fabric проверяет, есть ли у вашей учётной записи явные права на чтение целевой рабочей области и элемента. Если у вас нет разрешения на просмотр исходных таблиц, ярлык возвращает ошибку.

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

Внешние ярлыки и сохранённые идентификаторы подключения

Внешние ярлыки полностью меняют картину с точки зрения безопасности. Когда вы указываете lakehouse в Fabric на учётную запись Azure Data Lake Storage Gen2, Amazon S3, Google Cloud Storage или локальное сетевое расположение через шлюз данных, передача идентичности пользователя прекращается на границе Fabric. Вместо этого внешние ярлыки проходят аутентификацию с помощью сохранённого идентификатора подключения.

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

Правило «более строгое побеждает»

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

Чтобы оценить это правило, нужно смотреть на оба конца указателя:

• Разрешения пути ярлыка: назначения ролей (Admin, Member, Contributor, Viewer) в рабочей области и lakehouse, где находится ярлык.
• Разрешения целевого пути: списки контроля доступа (ACL), политики IAM или разрешения базы данных, применённые непосредственно к исходным файлам или таблицам.

Если пользователь является Contributor в рабочей области, где размещён ярлык, но имеет только роль Viewer в целевой учётной записи хранения, он сможет только читать данные. И наоборот: если у пользователя полные административные права на исходный набор данных, но его роль в рабочей области ограничена Viewer, он не сможет изменять или управлять конфигурацией ярлыка. Такое двухуровневое применение правил гарантирует, что никакая единичная ошибка конфигурации не откроет полностью периметр безопасности организации, однако при координации между отдельными ИT-отделами требуется тщательная документация.

Риски записываемых ярлыков и каскадного удаления

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

Ярлыки Fabric не выполняют каскадного удаления исходных данных, если вы удаляете сам объект ярлыка: ваши целевые данные остаются полностью в безопасности. Однако если ярлык доступен для записи и у пользователя есть разрешения на удаление по целевому пути, удаление файлов или папок через путь ярлыка необратимо сотрёт данные в источнике. Ярлык служит прямым входом в целевую систему хранения, и случайный скрипт очистки или непреднамеренное действие пользователя могут разрушить несущие конструкции быстрее, чем это сделали бы традиционные конвейеры данных.

Заключение

Освоение разрешений для ярлыков Microsoft Fabric требует фундаментальной смены взгляда на доступ к данным и управление ими. Balancing передачи идентичности пользователя для внутренних нагрузок с жёстко контролируемыми сохранёнными учётными данными для мультиоблачных источников позволяет создать отзывчивую среду аналитики с нулевым копированием без ущерба для безопасности. Чтобы изучить более широкие архитектурные стратегии, форматы данных и компромиссы, обязательно послушайте полный выпуск, в котором подробно разобрано современное управление облачными данными.

Часто задаваемые вопросы

Наследуют ли ярлыки Microsoft Fabric разрешения пользователя автоматически?

Внутренние ярлыки используют вашу персональную идентичность Entra ID, то есть вам необходимо иметь явный доступ на чтение как к рабочей области ярлыка, так и к целевой рабочей области. Внешние ярлыки, однако, используют сохранённый идентификатор подключения, поэтому любой, у кого есть доступ к lakehouse, может читать внешние данные.

Что произойдёт с данными, если я удалю ярлык Microsoft Fabric?

Удаление самого объекта-ярлыка не удаляет данные по целевому пути. Физические файлы или таблицы остаются в полной сохранности, если только ярлык не был настроен как доступный для записи и пользователь не удалил файлы через путь ярлыка при достаточных разрешениях на целевом объекте.

Как внешние облачные ярлыки выполняют аутентификацию для AWS S3 или Google Cloud Storage?

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

Что означает правило безопасности stricter-wins в Fabric?

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