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

Q: Чи успадковують ярлики Microsoft Fabric дозволи користувачів автоматично?

Внутрішні ярлики використовують вашу особисту ідентичність у Entra ID, тобто вам потрібен явний доступ на читання і до робочого простору, де розміщено ярлик, і до цільового робочого простору. Натомість зовнішні ярлики використовують ідентичність збереженого підключення, тож будь-хто, хто має доступ до lakehouse, може читати зовнішні дані.

Q: Що станеться з даними, якщо я видалю ярлик Microsoft Fabric?

Видалення самого об’єкта ярлика не видаляє дані за цільовим шляхом. Фізичні файли або таблиці залишаються повністю недоторканими, якщо ярлик не було налаштовано як доступний для запису і користувач явно не видалив файли через шлях ярлика з достатніми дозволами на цільовому шляху.

Q: Як зовнішні хмарні ярлики виконують автентифікацію для AWS S3 або Google Cloud Storage?

Зовнішні хмарні ярлики автентифікуються за допомогою збереженого підключення, налаштованого під час створення, а не передають облікові дані окремих користувачів. Тому основним бар’єром безпеки для користувачів, які запитують дані з кількох хмар, є списки контролю доступу до робочих просторів.

Q: Що означає правило «stricter-wins» у Fabric?

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

By Mirko Peters · 2026-10-30

Дізнайтеся, як працюють дозволи для ярликів Microsoft Fabric, і порівняйте передачу внутрішньої ідентичності користувача з правилами безпеки для збережених зовнішніх підключень.

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

Cover: Microsoft Fabric Shortcuts - Simply Explained

Дозволи для ярликів 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, він не може змінювати чи керувати конфігурацією ярлика. Такий дворівневий контроль гарантує, що жодна окрема помилка налаштування не зможе повністю зруйнувати периметр безпеки організації, however, він вимагає ретельної документації під час координації між окремими ІТ-відділами.

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

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

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

Висновок

Опанування дозволів для ярликів Microsoft Fabric вимагає фундаментальної зміни мислення щодо доступу до даних і управління ними. Поєднуючи наскрізну передачу ідентичності користувача для внутрішніх робочих навантажень із суворо контрольованими збереженими обліковими даними для мультихмарних джерел, ви можете побудувати гнучке аналітичне середовище без копіювання даних і без шкоди для безпеки. Щоб дослідити ширші архітектурні стратегії, формати даних і компроміси, обов'язково послухайте повний епізод, щоб отримати детальний огляд сучасного управління хмарними даними.

Поширені запитання

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

Внутрішні ярлики використовують вашу особисту ідентичність Entra ID, тобто вам потрібен явний доступ на читання і до робочого простору ярлика, і до цільового робочого простору. Зовнішні ж ярлики використовують збережену ідентичність підключення, що дозволяє будь-кому з доступом до lakehouse читати зовнішні дані.

Що станеться з даними, якщо я видалю ярлик Microsoft Fabric?

Видалення самого об’єкта-ярлика не видаляє дані за цільовим шляхом. Фізичні файли чи таблиці залишаються повністю в безпеці, якщо ярлик не було налаштовано як такий, що допускає запис, і користувач не видалив файли через шлях ярлика явно, маючи достатні дозволи для цільового розташування.

Як зовнішні хмарні ярлики виконують автентифікацію для AWS S3 або Google Cloud Storage?

Зовнішні хмарні ярлики автентифікуються, використовуючи збережене з’єднання, налаштоване під час створення, а не передаючи облікові дані окремих користувачів. Тому списки контролю доступу робочої області є основним бар’єром безпеки для користувачів, які запитують дані з кількох хмар.

Що означає правило безпеки stricter-wins у Fabric?

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