Skip to Content

Wiki source code of Fabric Security for Admins

Version 1.1 by Dimitri Rupp on 2026/07/08 13:38
Show last authors
1 {{box cssClass="floatinginfobox" title="**Auf dieser Seite**"}}
2 {{toc/}}
3 {{/box}}
4
5 = Fabric Security for Admins =
6
7 {{info}}
8 **Zielgruppe:** Fabric-Workspace-Admins
9 **Inhalt:** Role-based access control, Pipeline/Notebook/Dataflow-Governance, Lakehouse-RBAC, Lifecycle Management (Git + Deployment), Data Retention, Disaster Recovery.
10 {{/info}}
11
12 == Securing the foundation ==
13
14 At the heart of our governance model lies the principle of **role-based access control** within **Fabric workspaces**. **Security posture** is defined by the **roles assigned to its members**.
15
16 * **Workspace Admins** hold **full control**, including the ability to manage **permissions**, **configure settings**, and **deploy resources**.
17
18 == Data Pipelines ==
19
20 Although all workspace Admins possess full access to the workspace and its items, their ability to **maintain specific pipelines** may be **constrained by access limitations** to the **underlying source systems**.
21
22 To address this governance challenge, we utilise **shared connections**. By default, when a pipeline is shared via Git or deployed across environments, the connection details may not transfer or may break due to authentication context.
23
24 == Notebooks ==
25
26 In Microsoft Fabric, notebooks **inherit the access permissions of the workspace** in which they reside. Any user with workspace access can **view** the contents of a notebook.
27
28 **Execution rights**, however, are governed not only by workspace roles but also by the user's **access to the underlying data** the notebook reads or writes.
29
30 == Dataflows ==
31
32 In Microsoft Fabric, **Dataflows Gen2** are governed primarily by **workspace-level permissions**. Any user assigned a role above **Viewer** — **Contributor**, **Member**, or **Admin** — can view, edit, and execute Dataflows Gen2 within the workspace.
33
34 However, **successful execution depends on the connection credentials** used by the Dataflow.
35
36 == Workspace roles in Fabric ==
37
38 |=Role / Group|=Members
39 |**Admins**|Power BI Admin group
40 |**Members**|##Fabric_Connector## (SPN), Roxana Stauber
41
42 == Lakehouse Data Access — Roles, Permissions, and Controls ==
43
44 Accessing data in the Lakehouse is governed by a **layered security model** that reflects both **workspace-level permissions** and **item-specific controls**. While workspace roles determine **visibility** and **edit rights**, actual interaction with **tables**, **files**, and **shortcuts** can be further refined.
45
46 === Access ===
47
48 All **workspace members** in Microsoft Fabric **inherit access to Lakehouses** within the workspace **by default**. However, **OneLake Security**, when enabled, **takes precedence** over workspace-level permissions.
49
50 {{warning}}
51 **Stand:** Workspace membership is **not** governed by OneLake Security in telefabric, as the feature is currently in preview.
52 {{/warning}}
53
54 === RBAC in spl_gold_lh ===
55
56 At this stage, **direct access to ##spl_gold_lh## via the SQL endpoint** is restricted to **members of the PBI Power Users group**.
57
58 To facilitate controlled access, a **dedicated database role named ##powerusers##** has been created within the Lakehouse. **Schema-level access control** is enforced via this role.
59
60 === RBAC in shared_data_lh ===
61
62 Check the ##securityRoles## query in the **Queries → Shared queries** section of ##shared_data_lh##.
63
64 === Who can access all Lakehouses? ===
65
66 * **Power BI Admin** group
67 * **Fabric_Connector** (SPN for Board)
68 * **Roxana Stauber**
69
70 === Access level based on role ===
71
72 |=Role|=Members|=Access
73 |**Super user**|Power BI Admin group · Roxana Stauber · ##Fabric_Connector## (SPN for Board)|**All Lakehouses**
74 |**Developers**|Kazerounian Sanaz · Dubkov Andrii · Alexander Sachsenmaier · Diaz Marcos|##spl_gold_lh## only
75 |**SPN**|##Fabric Odoo Reader## · ##Fabric AI Reader##|##shared_data_lh## only
76
77 {{mermaid}}
78 flowchart TB
79 subgraph SU[Super Users — all Lakehouses]
80 SU1[Power BI Admin group]
81 SU2[Roxana Stauber]
82 SU3[Fabric_Connector SPN]
83 end
84 subgraph DEV[Developers — spl_gold_lh only]
85 D1[Kazerounian Sanaz]
86 D2[Dubkov Andrii]
87 D3[Alexander Sachsenmaier]
88 D4[Diaz Marcos]
89 end
90 subgraph SPN[SPNs — shared_data_lh only]
91 S1[Fabric Odoo Reader]
92 S2[Fabric AI Reader]
93 end
94 SU --> ALL[(All Lakehouses<br/>incl. Bronze + Silver + Gold)]
95 DEV --> GOLD[(spl_gold_lh)]
96 SPN --> SHARED[(shared_data_lh)]
97 classDef gold fill:#ffd54f,stroke:#b45f06,stroke-width:1px,color:#000
98 classDef shared fill:#c8e6c9,stroke:#2e7d32,stroke-width:1px
99 class GOLD gold
100 class SHARED shared
101 {{/mermaid}}
102
103 == Lifecycle Management ==
104
105 Microsoft Fabric provides a **unified platform** for managing the **full lifecycle of both data assets and workspace content** — from **ingestion and transformation** to **deployment and governance**.
106
107 === Lifecycle for workspace items ===
108
109 Fabric supports **continuous integration and deployment** through core features like **Git integration** and **deployment pipelines**.
110
111 === Git Integration ===
112
113 The Fabric workspace is connected to the **Fabric repository in the SPL Tele GitHub**. This GitHub repository serves as the **source control** for the Fabric workspace. Contributors can use this repository to **track changes**, **manage deployments**, and **collaborate** efficiently on workspace enhancements.
114
115 → Setup-Details: [[Git Integration in Fabric>>doc:IT-Wiki.02-Tools.Fabric.Git-Integration.WebHome]]
116
117 === Deployment pipelines ===
118
119 Deployment pipelines automate the **promotion of items across environments** (**Development → Test → Production**). At this stage, only a **test deployment pipeline** is being used in our implementation. This pipeline serves as a **deployment method** to push items from the ##Fabric_Dev## workspace.
120
121 == Data retention policy ==
122
123 In Fabric Lakehouses, data is typically stored in **Delta tables**, which maintain **transactional logs** and **version history**. Over time, these logs **accumulate obsolete files and metadata**. To manage this:
124
125 * A **weekly automated VACUUM operation** is executed via notebook. This operation cleans up unreferenced files older than the retention threshold.
126
127 Separately, data in the Lakehouse as **shortcuts** from the **ADLS Gen2 account** has a **separate lifecycle management** — the blobs are **deleted after 30 days**.
128
129 == Disaster recovery ==
130
131 When you delete a table or file from a Lakehouse in Fabric, it is **not immediately and permanently erased**. Instead, the system **retains the deleted object for 7 days**, during which it can be **recovered**.
132
133 This applies to:
134
135 * **Delta tables**
136 * **Individual files or folders**
137 * **Lakehouse metadata**
138
139 → More: [[Microsoft Fabric disaster recovery experience — specific guidance (Microsoft Learn)>>https://learn.microsoft.com/en-us/fabric/security/experience-disaster-recovery]]
140
141 == Key points ==
142
143 * **GitHub** for **CI/CD** of workspace items
144 * **Deployment pipeline** running in ##Fabric_Dev##
145 * **Lakehouse VACUUM** runs **weekly**
146 * Data is **soft-deleted** and can be **recovered within 7 days**