Governance і Security в Microsoft Fabric: повний гайд для дата-фахівців

Коротко: Governance і security в Microsoft Fabric — це система контролю доступу, захисту даних і відповідності нормативним вимогам, вбудована в платформу, але не налаштована автоматично. Fabric об’єднує Power BI, Synapse-подібні аналітичні workload-и, Data Factory, Real-Time Intelligence і Fabric Activator в одній екосистемі з багаторівневою моделлю доступу. Це спрощує архітектуру, але вимагає свідомого налаштування. Стаття для дата-інженерів, аналітиків і BI-фахівців, які хочуть розібратися з governance у Microsoft Fabric: від базових ролей до compliance-вимог.

Якщо хочете опанувати платформу на практиці — на сайті є навчання Microsoft Fabric: вісім модулів за три тижні з ментором.

Вступ

Microsoft Fabric — це уніфікована аналітична платформа, де governance і security присутні з першого дня. Але “присутні” не означає “налаштовані”. Більшість команд починають з Fabric як з інструменту швидкої аналітики і відкладають питання безпеки до першого аудиту або інциденту.

Ця стаття охоплює повну модель безпеки Fabric: від ієрархії ролей і дозволів до інтеграції з Microsoft Purview, роботи з OneLake та відповідності стандартам GDPR і ISO 27001. Ви отримаєте практичні чеклисти, приклади коду та розбір типових помилок, які трапляються в реальних командах.

Що таке governance і security у MS Fabric і чому це важливо вже зараз?

Fabric — це платформа з відповідальністю

Microsoft Fabric об’єднує Power BI, Synapse-подібні аналітичні workload-и, Data Factory, Real-Time Intelligence і Fabric Activator в одній платформі зі спільною основою OneLake. Це не означає одну універсальну кнопку безпеки для всього стеку. Натомість Fabric має багаторівневу модель доступу: tenant settings, workspace roles, item-level permissions, semantic model permissions, OneLake security, SQL/KQL permissions, sensitivity labels, audit і DLP-сценарії.

Різниця між security і governance принципова. Security — це хто має доступ і до чого: ролі, дозволи, автентифікація. Governance — це як дані класифікуються, відстежуються і управляються: lineage, sensitivity labels, data catalog, compliance-процеси.

Обидва напрями взаємопов’язані, але вирішують різні завдання. Можна мати відмінно налаштовані ролі і при цьому не мати жодного уявлення, звідки прийшли дані у конкретному звіті.

Де governance у Fabric закінчується і де починається ваша відповідальність

Зростання регуляторних вимог — GDPR, NIS2, галузеві стандарти — змушує організації ставитися до governance серйозніше. Fabric надає інструменти: Microsoft Purview, sensitivity labels, audit logs, RLS. Але конфігурація, класифікація даних і процеси — це відповідальність команди.

Microsoft забезпечує безпеку інфраструктури. Ви відповідаєте за те, що відбувається всередині неї.

Як влаштована модель безпеки Microsoft Fabric: ролі, рівні та дозволи

Рівні безпеки у Fabric: від тенанта до конкретного рядка даних

Модель безпеки Fabric ієрархічна. Кожен рівень накладається на попередній і дозволяє точніше контролювати доступ:

1. Tenant — глобальні налаштування в Fabric Admin Portal: хто може створювати workspace, які функції доступні, зовнішній шеринг.
2. Capacity — ресурсна одиниця (F-SKU або P-SKU), до якої прив’язані workspace. Адміністратор capacity контролює, хто може її використовувати.
3. Workspace — основний рівень організації роботи. Тут призначаються ролі для команд.
4. Item — окремі артефакти: Lakehouse, Warehouse, Semantic Model, Report. Можна надати доступ до конкретного item без доступу до всього workspace.
5. Row / Column — найгранулярніший рівень: Row-Level Security (RLS) і Column-Level Security (CLS) обмежують доступ до конкретних рядків і стовпців у даних. У Fabric ці механізми можуть реалізовуватись по-різному залежно від артефакту: через semantic model у Power BI, T-SQL permissions у Warehouse або OneLake Security preview для tabular data в OneLake. Тому важливо перевіряти, де саме застосовується правило доступу і який engine його реально виконує.

Ця ієрархія дає гнучкість. Але на практиці більшість команд зупиняється на рівні workspace — і це перша типова помилка.

Ролі Workspace: Admin, Member, Contributor, Viewer — що реально означає кожна

Запам’ятайте: роль Viewer сама по собі не завжди дає можливість будувати власні звіти чи підключатися до semantic model через Excel або інші клієнти. Для цього зазвичай потрібні додаткові permissions, зокрема Build permission, а також коректно налаштовані RLS/OLS і ліцензійні умови.

Item-level permissions: коли workspace-ролей недостатньо

Item-level permissions дозволяють надати доступ до конкретного Lakehouse, Warehouse або Semantic Model без включення людини до workspace.

Класичний сценарій: зовнішній підрядник або аналітик з іншого відділу потребує доступу до одного звіту чи однієї semantic model. Додавати його до workspace навіть з роллю Viewer не завжди доречно, якщо доступ потрібен лише до конкретного item. Краще використовувати item-level permissions і надавати мінімально необхідні права.

Для semantic models це особливо важливо: Read дозволяє переглядати дозволений контент, а Build дає можливість створювати нові звіти на основі моделі або підключатися до неї з інших інструментів. Саме Build permission часто створює додатковий ризик доступу до даних, якщо RLS/OLS і sharing-політики не налаштовані правильно.

Row-Level Security та Column-Level Security в Fabric: як обмежити доступ до даних на рівні запиту

RLS у семантичних моделях Power BI всередині Fabric налаштовується через DAX-правила. Принцип простий: визначаєте роль, прописуєте фільтр, призначаєте користувачів.

Приклад налаштування RLS у DAX для фільтрації даних за регіоном менеджера:

// Таблиця: Sales
// Фільтр: показувати лише записи, де Region збігається з регіоном поточного користувача

[Region] = LOOKUPVALUE(
    UserRegions[Region],
    UserRegions[Email], USERPRINCIPALNAME()
)

// Таблиця: Sales
// Фільтр: показувати лише записи, де Region збігається з регіоном поточного користувача

[Region] = LOOKUPVALUE(
    UserRegions[Region],
    UserRegions[Email], USERPRINCIPALNAME()
)

Після визначення правила — призначте конкретних користувачів або групи Azure AD до цієї ролі в налаштуваннях Semantic Model.

Для перевірки RLS у Power BI Desktop є функція “View as role” — вона показує, що бачить користувач з певною роллю до публікації.

CLS (Column-Level Security) у Fabric Warehouse можна реалізовувати через T-SQL permissions. Наприклад, можна заборонити певній ролі читати окремий стовпець.

Важливо: перед виконанням такого коду роль analyst_role має бути створена, а потрібні користувачі або групи мають бути додані до цієї ролі.

-- Приклад column-level permission у Fabric Warehouse.
-- Перед виконанням цього коду роль analyst_role має бути створена,
-- а потрібні користувачі або групи мають бути додані до цієї ролі.

-- Обмеження доступу до стовпця salary для ролі analyst_role
DENY SELECT ON OBJECT::dbo.employees (salary) TO analyst_role;

-- Перевірка поточних дозволів
SELECT 
    dp.name AS principal_name,
    o.name AS object_name,
    c.name AS column_name,
    dpm.permission_name,
    dpm.state_desc
FROM sys.database_permissions dpm
JOIN sys.database_principals dp 
    ON dpm.grantee_principal_id = dp.principal_id
JOIN sys.objects o 
    ON dpm.major_id = o.object_id
JOIN sys.columns c 
    ON dpm.major_id = c.object_id 
    AND dpm.minor_id = c.column_id
WHERE dp.name = 'analyst_role';

-- Приклад column-level permission у Fabric Warehouse.
-- Перед виконанням цього коду роль analyst_role має бути створена,
-- а потрібні користувачі або групи мають бути додані до цієї ролі.

-- Обмеження доступу до стовпця salary для ролі analyst_role
DENY SELECT ON OBJECT::dbo.employees (salary) TO analyst_role;

-- Перевірка поточних дозволів
SELECT 
    dp.name AS principal_name,
    o.name AS object_name,
    c.name AS column_name,
    dpm.permission_name,
    dpm.state_desc
FROM sys.database_permissions dpm
JOIN sys.database_principals dp 
    ON dpm.grantee_principal_id = dp.principal_id
JOIN sys.objects o 
    ON dpm.major_id = o.object_id
JOIN sys.columns c 
    ON dpm.major_id = c.object_id 
    AND dpm.minor_id = c.column_id
WHERE dp.name = 'analyst_role';

У Lakehouse granular access control краще розглядати через OneLake Security preview. Вона дозволяє налаштовувати доступ до tables/folders, а також row-level і column-level restrictions для tabular data в OneLake. Важливий нюанс: OneLake security roles насамперед застосовуються до користувачів із Viewer workspace role або Read permission на item. Admin, Member і Contributor мають ширші права, тому їх не варто використовувати як “звичайний” доступ для споживачів даних.

Сервісні принципали та managed identities: автентифікація без паролів

Для автоматизованих пайплайнів і ETL-процесів використовуйте Service Principals або Managed Identities замість облікових даних конкретних людей.

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

Типова матриця доступу для аналітичної команди:

Як Microsoft Purview інтегрується з Fabric для data governance?

Microsoft Purview у контексті Fabric: що це і навіщо

Microsoft Purview — це окремий набір сервісів для governance, compliance, data catalog, information protection, audit і DLP-сценаріїв. Він інтегрується з Microsoft Fabric і дозволяє керувати metadata, lineage, sensitivity labels, audit і data protection-сценаріями в ширшій Microsoft-екосистемі.

Водночас не варто сприймати це як повністю автоматичну магію. Конкретна видимість Fabric assets у Purview, рівень lineage, catalog-функції, DLP-політики й audit залежать від tenant settings, ліцензій, supported item types і того, які саме Purview applications використовує організація.]

Data Catalog і автоматичне сканування активів у Fabric

Після налаштування інтеграції Purview може допомагати з discovery, cataloging і lineage для Fabric assets: Lakehouses, Warehouses, semantic models, pipelines, reports та інших підтримуваних item-ів.

Що саме індексується і як глибоко зчитуються metadata, залежить від поточних можливостей Purview, типу item, ліцензій і налаштувань tenant. Класифікація даних за вмістом — наприклад, виявлення персональних даних у стовпцях — зазвичай потребує окремого налаштування sensitivity labels, classifiers, DLP або scanning policies.

Sensitivity Labels: класифікація даних від документа до таблиці в Lakehouse

Sensitivity Labels — це мітки з Microsoft 365 (Confidential, Highly Confidential, Public тощо), які поширюються на дані в Fabric.

Як це працює на практиці: мітка, застосована до Semantic Model, автоматично успадковується звітами, побудованими на її основі. Якщо хтось намагається експортувати дані з міткою “Confidential” — DLP-політика може заблокувати або зафіксувати цю дію.

Важливий нюанс: мітки потрібно спочатку визначити в Microsoft Purview compliance portal і активувати для Fabric у tenant settings.

Data Lineage в Fabric: як відстежити шлях даних від джерела до дашборду

Data Lineage у Fabric — це вбудована візуалізація потоку даних: від джерела через пайплайни і трансформації до кінцевих звітів.

Практична цінність для аудиту: коли виникає питання “звідки ці цифри у звіті?”, lineage дає відповідь за хвилини, а не за години розбору коду.

Lineage доступний безпосередньо у Fabric workspace через вкладку “Lineage view”. Purview додає ширший контекст: cross-workspace і cross-system lineage для складніших архітектур.

Information Protection та DLP-політики: як запобігти витоку чутливих даних

DLP (Data Loss Prevention) політики в Microsoft Purview допомагають виявляти, попереджати або обмежувати ризикові дії з чутливими даними. Але конкретна поведінка залежить від типу item, sensitivity labels, DLP-політик, ліцензій і налаштувань Microsoft 365 / Fabric tenant.

Приклади сценаріїв:

• Попередження або audit event при спробі поширити контент із міткою “Highly Confidential”
• Сповіщення compliance-команди при виявленні чутливих даних у workspace або item
• Обмеження експорту або поширення даних у сценаріях, де це підтримується відповідними Purview / Microsoft 365 policies

Для читачів, які хочуть системно вивчити побудову надійної data-інфраструктури з дотриманням стандартів безпеки — спеціалізація Analytics & Data Engineer охоплює ці теми в контексті реальної архітектури.

5 кроків для базового governance у новому Fabric-тенанті:

1. Підключіть Fabric до Microsoft Purview і перевірте, які Fabric item types підтримуються у вашому tenant
2. Налаштуйте discovery / cataloging для критичних workspace і data assets
3. Визначте sensitivity labels відповідно до внутрішньої класифікації даних
4. Налаштуйте правила для типових чутливих даних: PII, фінансові дані, комерційна таємниця
5. Увімкніть DLP, audit і alerting для критичних сценаріїв: зовнішній доступ, експорт, поширення чутливих semantic models або reports

Щодо вартості: можливості Purview залежать від конкретних Microsoft 365 / Purview ліцензій і сценарію використання. Data Catalog, DLP, Audit Standard/Premium, Information Protection і compliance-функції мають різні умови ліцензування. Тому бюджет потрібно перевіряти за актуальною документацією Microsoft або з ліцензійним партнером.

OneLake і безпека зберігання даних: що потрібно знати кожному дата-інженеру

OneLake як єдине озеро даних: архітектурні наслідки для безпеки

OneLake — це єдине сховище для всіх Fabric-workloads, аналог OneDrive, але для даних організації. Всі Lakehouses, Warehouses і інші артефакти фізично зберігають дані в OneLake.

Централізація спрощує управління: одна точка контролю замість десятків окремих сховищ. Водночас це означає, що помилка в конфігурації на рівні OneLake може мати широкі наслідки.

Для розуміння різних підходів до організації сховищ даних — корисний контекст дає Типи баз даних у 2026.

Шифрування даних у OneLake: at rest і in transit

Microsoft автоматично шифрує дані в OneLake:
– At rest: AES-256 шифрування для всіх даних, що зберігаються
– In transit: TLS 1.2+ для всього трафіку між клієнтами і сервісами

Customer-managed keys (CMK) доступні для організацій, яким потрібен додатковий контроль над ключами шифрування. У Fabric це налаштовується через Azure Key Vault і підтримується для відповідних workspace / workloads за певних prerequisites. Перед впровадженням потрібно перевірити актуальні обмеження, підтримувані item types, регіони й ліцензійні умови.

Shortcuts у OneLake: зручність з потенційними ризиками безпеки

OneLake Shortcuts дозволяють підключати зовнішні сховища — Azure Data Lake Storage Gen2, Amazon S3, Google Cloud Storage — без фізичного копіювання даних.

Ключове питання безпеки: дозволи на Shortcut і дозволи на зовнішнє сховище — це два окремі рівні контролю. Доступ до Shortcut у Fabric не автоматично означає доступ до вихідного сховища, і навпаки.

На практиці це означає: при налаштуванні Shortcuts потрібно явно перевіряти обидві сторони — хто має доступ у Fabric і які дані реально доступні через зовнішнє сховище.

Мережева безпека: Private Links, Managed VNet та обмеження публічного доступу

Для enterprise-середовищ публічний доступ до Fabric через інтернет — це ризик, який варто мінімізувати.

Fabric підтримує кілька механізмів для мережевої безпеки й контрольованого доступу:

• Private Link — приватний доступ до Fabric через мережеву інфраструктуру Azure замість публічного інтернет-доступу
• Managed private endpoints — приватне підключення Fabric workloads до підтримуваних джерел даних
• VNet data gateway / on-premises data gateway — контрольований доступ до джерел у приватних мережах або on-premises середовищах
• Tenant-level controls — політики доступу, зовнішнього поширення, cross-tenant сценаріїв і регіональних обмежень]

Практичний чеклист: 7 налаштувань безпеки OneLake, які варто перевірити в кожному тенанті:

• Перевірити tenant-level network settings, Private Link і зовнішній доступ відповідно до політик організації
• Налаштувати Private Link або managed private endpoints для production-сценаріїв, де це потрібно
• Перевірити, чи всі Shortcuts мають задокументовані джерела, власників і рівень чутливості даних
• Активувати Customer-Managed Keys, якщо цього вимагає compliance або внутрішня security-політика
• Перевірити cross-tenant access і external sharing у Fabric Admin Portal
• Переконатися, що Service Principals і managed identities мають мінімально необхідні права
• Налаштувати audit, alerting і моніторинг аномальної активності через Microsoft Purview Audit, Microsoft Sentinel або інший SIEM

Чи відповідає Microsoft Fabric вимогам GDPR, ISO 27001 та інших стандартів?

Що Microsoft гарантує на рівні платформи (і що — ні)

Microsoft Fabric успадковує частину compliance-capabilities Microsoft cloud ecosystem і має відповідні сертифікації та audit reports, які варто перевіряти в Microsoft Trust Center / Service Trust Portal. Але відповідність GDPR, ISO 27001, SOC, HIPAA або галузевим вимогам у конкретній організації залежить не лише від платформи, а й від конфігурації, процесів і контролів замовника.

Модель shared responsibility чітка: Microsoft відповідає за безпеку й доступність хмарної платформи, а організація — за конфігурацію доступу, класифікацію даних, retention-політики, процеси, навчання персоналу й виконання власних compliance-вимог.

GDPR і Fabric: де проходить межа відповідальності

GDPR вимагає, серед іншого, права на видалення персональних даних (right to erasure). У контексті Delta Lake і OneLake це технічно нетривіальне завдання.

Delta Lake підтримує операції DELETE і VACUUM, але є нюанси:

• Time travel зберігає попередні версії даних — потрібно явно запускати VACUUM з відповідними параметрами
• Дані можуть бути кешовані або скопійовані в похідні таблиці — lineage допомагає відстежити всі копії
• Backup-копії потребують окремого процесу видалення

Практичний підхід: документуйте, де зберігаються персональні дані (data catalog), і будуйте процес erasure як частину операційних процедур, а не як разову дію.

Audit Logs у Fabric: як відстежувати дії користувачів для compliance

Fabric логує події через Microsoft Purview Audit і Power BI Activity Log. Що фіксується:

• Перегляд і завантаження звітів
• Зміни в workspace і налаштуваннях доступу
• Операції з даними в Lakehouse і Warehouse
• Дії адміністраторів на рівні tenant

За поточною документацією Microsoft, Audit Standard зберігає нові audit records за замовчуванням 180 днів. Audit Premium розширює можливості аудиту й може забезпечувати довший retention, зокрема до 1 року за замовчуванням для відповідних сценаріїв. Для довготривалого зберігання audit data варто налаштовувати retention policies або експорт у SIEM / Log Analytics.

Data residency: дані Fabric прив’язані до регіону tenant / capacity і налаштувань розміщення даних. Для організацій із вимогами до локалізації даних потрібно перевірити регіон tenant, capacity, workspace і підтримувані data residency options до старту проєкту. Перенесення вже створених середовищ між регіонами може бути складним і потребувати окремого плану міграції.

Позиція автора: governance — це організаційна проблема, замаскована під технічну

Більшість governance-провалів, які трапляються в командах, мають одну спільну рису: технічні інструменти були доступні, але процеси і культура — ні.

Fabric дає всі необхідні інструменти. Purview, sensitivity labels, RLS, audit logs — все це існує і працює. Але якщо в команді немає людини, відповідальної за governance, якщо немає процесу onboarding нових користувачів, якщо класифікація даних відкладається “на потім” — жодні технічні налаштування не допоможуть.

5 організаційних практик governance, важливіших за будь-які технічні налаштування:

1. Призначте Data Owner для кожного критичного dataset — людина, яка відповідає за класифікацію і якість даних
2. Включіть governance у процес onboarding — кожен новий користувач Fabric має знати, які дані він може бачити і чому
3. Проводьте регулярний access review — раз на квартал перевіряйте, хто має доступ до чого, і видаляйте зайвих
4. Документуйте data lineage як частину delivery — не окремий проєкт, а стандарт роботи
5. Робіть governance видимим для бізнесу — compliance-звіти, дашборди якості даних, регулярні звіти для стейкхолдерів

Типові помилки при налаштуванні governance і security в Microsoft Fabric

Помилка 1: Workspace як єдиний рівень контролю доступу

Що роблять: всім аналітикам дають роль Contributor або Member на рівні workspace.

Чому це проблема: аналітик, якому потрібен доступ до одного звіту, отримує доступ до всіх артефактів workspace, включно з raw-даними і конфігураційними файлами.

Як правильно: використовуйте item-level permissions для точкового доступу. Workspace-ролі — для команди, що активно працює з усіма артефактами. Item-level — для всіх інших.

Помилка 2: Ігнорування sensitivity labels і класифікації даних

Що роблять: не налаштовують sensitivity labels, бо “це зайва робота” або “розберемося пізніше”.

Чому це проблема: без міток складніше будувати ефективні DLP-політики, audit-сценарії й контроль зовнішнього доступу. Дані з персональною інформацією або фінансовими показниками можуть бути експортовані чи поширені за межі організації без належного контролю.

Як правильно: визначте мінімальну класифікацію — наприклад 3–4 рівні чутливості — і налаштуйте правила для типових типів даних: PII, фінансові дані, комерційна інформація. Це не закриває всі ризики автоматично, але створює основу для DLP, audit і compliance-процесів.

Помилка 3: Shortcuts без аудиту зовнішніх джерел

Що роблять: підключають Shortcuts до S3 або ADLS без перевірки, які дані там зберігаються і хто має доступ до вихідного сховища.

Чому це проблема: дані у зовнішньому сховищі можуть містити чутливу інформацію, яка не підпадає під governance-правила Fabric. Або навпаки — доступ до Shortcut надається ширшому колу людей, ніж передбачалося.

Як правильно: документуйте кожен Shortcut: джерело, тип даних, власник, рівень чутливості. Включіть Shortcuts у регулярний access review.

Помилка 4: Відсутність процесу offboarding користувачів

Що роблять: при звільненні співробітника або завершенні роботи підрядника не видаляють їх доступ до Fabric workspace і артефактів.

Чому це проблема: колишній підрядник може зберігати доступ до production-даних тижнями після завершення контракту. Це класичний сценарій для аудиторських зауважень і потенційних інцидентів.

Як правильно: включіть відкликання доступу до Fabric у стандартний offboarding-чеклист HR і IT. Автоматизуйте через Azure AD групи — коли людину видаляють з групи, доступ відкликається автоматично.

Помилка 5: Governance як разове налаштування

Що роблять: налаштовують governance при запуску платформи і вважають завдання виконаним.

Чому це проблема: нові workspace, нові користувачі, нові джерела даних з’являються постійно. Без ongoing-процесу governance-налаштування застарівають за кілька місяців.

Як правильно: призначте відповідального за governance review (може бути частиною ролі Data Engineer або Platform Engineer). Встановіть регулярний ритм: щоквартальний access review, щомісячна перевірка нових workspace, щорічний повний аудит.

Бонус — помилка з Fabric Free Trial: команди тестують Fabric на реальних production-даних у trial-середовищі без governance-налаштувань, sensitivity labels, access review і audit-процесів. Trial не означає відсутність ризиків: якщо дані реальні, до них потрібно застосовувати ті самі правила класифікації, доступу й моніторингу, що й у production.

FAQ: питання про governance і security MS Fabric

Питання: Що таке governance і security в Microsoft Fabric?

Відповідь: Governance і security в Microsoft Fabric — це набір інструментів і політик для контролю доступу, захисту даних та відповідності нормативним вимогам. Security визначає, хто може бачити, редагувати та використовувати конкретні дані і артефакти. Governance охоплює ширший контекст: класифікацію даних, відстеження lineage, data catalog і compliance-процеси. Основу складають ролі workspace, item-level permissions, Microsoft Purview, sensitivity labels і Row-Level Security. Разом вони формують повну модель управління даними на платформі.

Питання: Як налаштувати безпеку доступу до даних у Microsoft Fabric?

Відповідь: Налаштування безпеки починається з визначення ролей на рівні workspace: Admin, Member, Contributor, Viewer. Для точнішого контролю використовуйте item-level permissions — вони дозволяють надати доступ до конкретного артефакту без доступу до всього workspace. Для семантичних моделей налаштуйте Row-Level Security через DAX-правила. Додатково активуйте sensitivity labels через Microsoft Purview і увімкніть аудит подій у Fabric Admin Portal.

Питання: Як Microsoft Purview допомагає з governance у Fabric?

Відповідь: Microsoft Purview допомагає керувати metadata, lineage, sensitivity labels, audit і DLP-сценаріями в Microsoft Fabric. У практичному сенсі це означає, що команда може бачити, які data assets існують, як вони пов’язані між собою, які мітки чутливості мають і які дії з ними виконують користувачі. Водночас Purview не замінює процеси всередині команди: data owners, access review, класифікація даних і правила зовнішнього доступу все одно мають бути визначені організацією.

Питання: Чи підтримує Microsoft Fabric Row-Level Security і Column-Level Security?

Відповідь: Так, але реалізація залежить від артефакту. У Power BI semantic models RLS зазвичай налаштовується через DAX-правила. У Fabric Warehouse можна використовувати T-SQL permissions і SQL security-механізми. Для Lakehouse і tabular data в OneLake актуальним напрямом є OneLake Security preview, яка підтримує granular access control, зокрема row-level і column-level restrictions. Перед production-впровадженням важливо перевірити, який саме engine буде виконувати запити — Power BI, SQL Endpoint, Spark, Warehouse або інший клієнт — і чи застосовуються потрібні правила доступу саме в цьому сценарії.

Підсумок: governance у Microsoft Fabric потрібно проєктувати з першого дня

Microsoft Fabric дає сильний набір інструментів для security і governance: workspace roles, item-level permissions, semantic model permissions, RLS, CLS, sensitivity labels, audit logs, Purview integration, OneLake Security preview, Private Link і managed private endpoints. Але жоден із цих інструментів не гарантує безпеку автоматично.

Практичний порядок дій для команди:

• Почніть із моделі доступу: хто створює workspace, хто володіє даними, хто має право читати, редагувати й поширювати артефакти
• Визначте базову класифікацію даних: public, internal, confidential, highly confidential
• Налаштуйте sensitivity labels і DLP-політики для критичних типів даних
• Використовуйте item-level permissions і Build permission замість широкого доступу на рівні workspace
• Запровадьте регулярний access review: мінімум раз на квартал
• Документуйте OneLake Shortcuts: джерело, власник, тип даних, рівень чутливості
• Увімкніть audit і налаштуйте довготривале зберігання логів, якщо цього вимагає compliance
• Для автоматизації використовуйте Service Principals або managed identities, а не персональні облікові записи

Головна думка проста: Fabric спрощує технічну архітектуру, але не скасовує відповідальність за governance. Якщо команда не визначила data owners, не проводить access review і не класифікує дані, навіть найкраща платформа не захистить від хаосу.