Data Analyst Professional · Модуль 14 · Урок 49 із 51
Публікація Power BI і керування доступом
Publish — це security change. Перед релізом треба визначити audience, workspace/app role, semantic-model permissions, RLS, Build/export/reshare, external access, expiry та audit.
Спосіб поширення під audience
| Сценарій | Канал | Контроль |
|---|---|---|
| Команда розробки | workspace | Admin/Member/Contributor за функцією |
| Велика внутрішня аудиторія | Power BI app | audience groups, read, RLS |
| Точковий reviewer | share link/direct share | specific people, no reshare/build unless needed |
| External partner | approved B2B/embedded path | tenant policy, identity, contract, expiry |
| Відкриті public data | Publish to web лише після public review | без authentication; model detail may be exposed |
Publish to web — це публікація в Інтернет
Не використовуйте для confidential або proprietary data
Microsoft прямо попереджає: будь-хто в Інтернеті може переглядати report без authentication, включно з detail-level data, які model агрегує. Для internal portal використовуйте secure Embed/SharePoint або інший approved authenticated path.
Навіть якщо visual не показує column, underlying model, exports, drill/filter і metadata треба розглядати як attack surface. Public release проходить окремий data-owner/security sign-off.
Workspace roles і RLS
Power BI RLS не обмежує workspace Admin, Member або Contributor. Щоб перевірити consumer experience, тестуйте як Viewer/app audience і через Test as role; авторський admin view не є security test.
Permission layers, які часто плутають
- Read: перегляд item.
- Build: створення нового content на semantic model; не додавайте автоматично.
- Write: зміна content/model; RLS не захищає від автора з write.
- Reshare: можливість розширити audience.
- Export: дані виходять у файл; перевірте label/protection і tenant policy.
- External: identity, guest lifecycle, contract і expiry.
Sensitivity label не замінює Power BI permissions у service. Вона класифікує content і може переносити protection у supported exports; access до service керується permissions.
Release і revoke checklist
Owner / audience / purpose / classification
Workspace + app + item permissions
Security groups; no unexplained direct users
RLS roles tested with representative accounts
Build / export / reshare / external rules
Refresh credentials and gateway owner
Publish-to-web codes = none (unless approved public)
Access expiry / quarterly review / revoke owner
Audit evidence and incident contactПрактика
- Створіть access matrix для creator, reviewer і consumer.
- Перевірте RLS як Viewer, не як Admin.
- Приберіть зайві Build/reshare/export permissions.
- Запишіть public/private decision і expiry.
- Проведіть revoke drill: user, group, share link, app audience, embed code.
Офіційні джерела
Готовність до тесту
Ви обираєте distribution channel під audience, тестуєте RLS у consumer role, керуєте Build/export/reshare і маєте revoke path.
Закріпіть матеріал уроку
Три сценарні питання. Для зарахування уроку потрібно дати щонайменше дві правильні відповіді.