# Microsoft Fabric – Security & Access Governance Briefing

**Source:** Internal working session (transcript.txt) | **Participants:** Andy, Jacob, Joey, Chris (and "Bryce" referenced) | **Date prepared:** 2026-06-12

---

## 1. Executive Summary

The team is moving Maxim Crane's Microsoft Fabric tenant from an **ad-hoc, individual-user permission model** to a **group-driven, role-based model** governed by Microsoft Entra ID. Today, access drifts because users, service principals, and connections are added one-by-one to workspaces, semantic models, deployment pipelines, connections, and Azure resources. This creates onboarding friction, orphaned objects, and unclear ownership.

Two parallel security tracks were defined:

1. **Machine/automation access** – via **Workspace Identity** (credential-free managed service principal) for cross-workspace refreshes, pipelines, Key Vault, and ADLS Gen2 access.
2. **Human access** – via **Entra ID groups** mapped to the four built-in Fabric workspace roles (Viewer / Contributor / Member / Admin), reinforced by **Row-Level Security (RLS)** on semantic models.

The biggest unresolved tension is **auditability vs. manageability**: groups simplify onboarding, but the team needs to confirm Fabric audit logs still resolve actions back to the *individual* user (Microsoft Docs confirm: yes, audit logs capture the individual user identity, not the group).

---

## 2. Discussion Themes

| # | Theme | Pain Point Today | Direction Agreed |
|---|---|---|---|
| 1 | Workspace Identity | Created as ad-hoc service principals; permissions to Azure (Key Vault, blob, graph) granted reactively | Standardize: every new workspace identity gets a documented checklist of Azure permissions |
| 2 | Cross-workspace refresh | Reports in Reporting-Dev couldn't refresh from Maxim Data Marts | Add source workspace identity to the target workspace's Manage Access |
| 3 | User access | Individual users sprinkled across workspaces; new hire = manual add everywhere | Replace with Entra groups: `Fabric-{Env}-Workspace-{Role}` and `Fabric-{Domain}-{Role}` |
| 4 | Domain segmentation | Finance / HR / Operations data co-mingled; no domain-scoped groups | Per-domain groups (Viewer / Member / Contributor); RLS for data-level filtering |
| 5 | Dev / Test / Prod | Same admin pool across environments | Same Viewer/Contributor across envs; **restrict Admin in Prod** to deployment engineers only |
| 6 | Deployment pipelines | Pipeline permissions are separate from workspace permissions; previous owner left → pipelines orphaned | Use a group **plus** named individuals on pipelines for auditability and continuity |
| 7 | Connections | Hundreds of duplicate/orphaned connections; case-sensitive name drift; notebook connections behave oddly | Adopt naming standard `[Env] Source – Purpose`; consolidate; one workspace-identity connection per source workspace |
| 8 | Secure / sensitive data | HR (ADP) and potentially financial data need stricter isolation | Add a future `*-Secure` role tier and warehouse-level grants on those lakehouses |
| 9 | Modify semantic models | Concern users could edit shared models | Confirmed: business users do **not** edit models today — keep it that way |
| 10 | Admin portal hardening | Tenant settings largely untouched; defaults favor usability over security | Audit tenant settings; disable unused export/share defaults |

---

## 3. Use Cases Extracted

### UC-1 — Cross-Workspace Semantic Model Refresh
A Power BI report in `Reporting-Dev` needs to refresh from a lakehouse in `Maxim-Data-Marts`.
**Resolution:** Create workspace identity on `Reporting-Dev`; grant it Viewer (or higher) on `Maxim-Data-Marts`; switch the connection to "Workspace Identity" auth. *(Validated in session.)*

### UC-2 — New Developer Onboarding
Today: add user individually to every workspace, connection, pipeline, capacity.
Future: add user to one Entra group → inherits access everywhere.

### UC-3 — Domain Self-Service (Finance, HR, Operations)
Domain users edit reports in their **own** domain workspace (Member/Contributor), but are **Viewer-only** on shared gold-layer reporting workspaces. Data-level access enforced by RLS on the semantic model.

### UC-4 — Promotion to Production
Anyone in IT may push Dev → Test. Only a small group (e.g., `Fabric-Prod-Workspace-Admin`) may push Test → Prod. Pipeline ownership stays auditable via individual + group assignment.

### UC-5 — Workspace Identity Accessing External Azure Resources
Workspace identity needs Key Vault Secrets User, Storage Blob Data Reader/Contributor on ADLS Gen2, etc. Build a standard "WS-Identity provisioning checklist."

### UC-6 — Secure Domain (HR / Financial PII)
Lakehouse/warehouse-level grants restricted to a `Fabric-HR-Secure` group; even tenant admins outside that group cannot read rows.

### UC-7 — Connection Consolidation
Eliminate duplicate connections (e.g., notebook connections that re-create themselves on deploy) using a naming convention and group-based access on the connection itself.

---

## 4. Action-Item Takeaways

| Owner | Action | Priority |
|---|---|---|
| Jacob | Draft Entra group catalog (env × role, domain × role) and circulate | High |
| Jacob/Joey | Stand up test in repurposed CI/CD workspaces — prove audit trail when groups are used | High |
| Joey | Document workspace-identity provisioning checklist (Key Vault, blob, etc.) | High |
| Chris | Validate which connections are actually in use; delete orphans | Medium |
| Andy | Review Fabric **tenant admin settings** vs. Microsoft baseline (export, sharing, SPN-can-use-APIs) | Medium |
| All | Define naming standard for connections and workspace identities | Medium |
| All | Decide policy on individual + group dual-assignment for deployment pipelines | Medium |
| All | Plan a `*-Secure` tier for HR / financial data | Low (future) |

---

## 5. Microsoft Best-Practice Alignment

Cross-referenced with [Fabric Security baseline](https://learn.microsoft.com/azure/well-architected/microsoft-fabric/security), [Workspace roles](https://learn.microsoft.com/fabric/fundamentals/roles-workspaces), [RLS](https://learn.microsoft.com/fabric/security/service-admin-row-level-security), and [Deployment pipelines](https://learn.microsoft.com/fabric/cicd/deployment-pipelines/understand-the-deployment-process#permissions).

### 5.1 Identity & Access — Zero Trust foundation
- **Use workspace identity** for service-to-service auth — credential-free, no rotation overhead. ✅ matches team direction.
- ⚠️ **Important change (July 27, 2025):** New workspace identities **no longer get default Contributor access** to their own workspace. You must grant the role explicitly. *(This is exactly what Joey ran into.)*
- **Always map roles to Entra security groups**, not individuals. Microsoft explicitly recommends this for both workspace roles and RLS role mappings.
- **Audit logs still capture the individual user** even when access is granted via a group — so the team's auditability concern is mitigated.
- Enforce **Conditional Access + MFA + PIM** for admin roles.

### 5.2 Workspace Role Model (built-in)
| Role | Read | Write | Share | Manage | Best fit |
|---|---|---|---|---|---|
| Viewer | ✅ | ❌ | ❌ | ❌ | Business consumers; RLS enforced here |
| Contributor | ✅ | ✅ | ❌ | ❌ | IT developers in Dev/Test |
| Member | ✅ | ✅ | ✅ | partial | Domain power users, deployment engineers |
| Admin | ✅ | ✅ | ✅ | ✅ | Tenant/Workspace owners; smallest possible group in Prod |

**RLS reminder:** RLS only filters for **Viewer** role — Contributors/Members/Admins bypass RLS. So domain power users with Member/Contributor see all rows in their workspace's semantic models.

### 5.3 Deployment Pipelines (the gotcha)
- Pipeline permissions are **independent** of workspace permissions.
- To deploy: must be both `Pipeline Admin` **and** at least `Contributor` on both source and target workspaces.
- Microsoft 365 groups are **not** supported as pipeline admins — use **security groups** or individuals.
- ✅ Team's plan (group + named individuals) is the recommended pattern for continuity *and* auditability.

### 5.4 Isolation Boundaries
- Workspaces are the **primary security boundary** — Microsoft recommends one workspace per domain/team/medallion-layer. ✅
- For HR/PII: combine workspace isolation with **OneLake security roles** (folder/table-level RBAC) for the Secure tier.

### 5.5 Connections
- Workspace identity is the **recommended Prod auth** for connections; user-based is OK in Dev/Test for traceability.
- Standardize naming early — Fabric auto-creates connections on copy/deploy, so drift is inevitable without a convention.

### 5.6 Tenant Hardening Checklist (review in admin portal)
1. Restrict workspace creation to admins.
2. Disable "anyone with the link" sharing.
3. Disable external sharing if not required.
4. Require sensitivity labels.
5. Enforce OAuth/managed-identity; disable basic auth.
6. Confirm "Service principals can use Fabric APIs" is enabled only for the SPNs that need it.
7. Enable audit log export to a SIEM / Log Analytics.

### 5.7 Workspace Limits (heads-up)
Rolling out Aug 2025: **max 1,000 users/groups per workspace role**. Group-based access protects you from ever hitting this.

---

## 6. Visuals for Managers

### 6.1 Two-Layer Security Model

```mermaid
flowchart LR
    subgraph IDENTITY["Identity Layer — Microsoft Entra ID"]
      U[Users]
      G[Security Groups]
      WI[Workspace Identity / Service Principal]
      U --> G
    end

    subgraph FABRIC["Microsoft Fabric"]
      WS[Workspaces<br/>Viewer / Contributor / Member / Admin]
      SM[Semantic Models<br/>+ Row-Level Security]
      DP[Deployment Pipelines]
      CN[Connections]
    end

    subgraph AZURE["Azure Resources"]
      KV[Key Vault]
      ADLS[ADLS Gen2 / Blob]
      SQL[SQL / DB sources]
    end

    G -->|access| WS
    WS -->|inherit| SM
    G -->|RLS mapping| SM
    G -->|Pipeline Admin + workspace role| DP
    WI -->|auth| CN
    WI -->|granted role| KV
    WI -->|granted role| ADLS
    WI -->|granted role| SQL
    CN --> WS
```

### 6.2 Target Entra Group Catalog (proposed)

```mermaid
flowchart TB
    classDef it fill:#dbeafe,stroke:#1d4ed8,color:#0b1f55
    classDef domain fill:#dcfce7,stroke:#15803d,color:#052e16
    classDef secure fill:#fee2e2,stroke:#b91c1c,color:#450a0a

    subgraph IT["IT / Platform groups (env-scoped)"]
      A1[Fabric-Dev-Workspace-Admin]:::it
      A2[Fabric-Dev-Workspace-Member]:::it
      A3[Fabric-Dev-Workspace-Contributor]:::it
      A4[Fabric-Dev-Workspace-Viewer]:::it
      B1[Fabric-Test-Workspace-Admin]:::it
      B2[Fabric-Test-Workspace-Contributor]:::it
      C1[Fabric-Prod-Workspace-Admin<br/>SMALL — deploy engineers]:::it
      C2[Fabric-Prod-Workspace-Contributor]:::it
      C3[Fabric-Prod-Workspace-Viewer]:::it
    end

    subgraph DOM["Domain groups (business)"]
      F1[Fabric-Finance-Viewer]:::domain
      F2[Fabric-Finance-Contributor]:::domain
      F3[Fabric-Finance-Member]:::domain
      H1[Fabric-HR-Viewer]:::domain
      O1[Fabric-Operations-Viewer]:::domain
      O2[Fabric-Operations-Contributor]:::domain
    end

    subgraph SEC["Secure tier (future)"]
      S1[Fabric-HR-Secure]:::secure
      S2[Fabric-Finance-Secure]:::secure
    end
```

### 6.3 Where Each Control Lives

```mermaid
flowchart LR
    USER[Business User]
    USER -->|in| GRP[Entra Group]
    GRP -->|workspace role| WS1[Domain Workspace<br/>Gold Reports]
    WS1 -->|opens| RPT[Power BI Report]
    RPT -->|reads| SM[Semantic Model]
    SM -->|RLS filter by group| ROWS[(Rows user can see)]

    subgraph CTRL1["Controls access to the WORKSPACE"]
      GRP
    end
    subgraph CTRL2["Controls which ROWS are visible"]
      SM
    end
    subgraph CTRL3["Controls which TABLES/FOLDERS (Secure tier)"]
      OLS[OneLake Security Roles]
    end
    OLS -.->|optional| SM
```

### 6.4 Promotion / CI-CD Flow with Auditability

```mermaid
flowchart LR
    DEV[Dev Workspace<br/>everyone can deploy] --> TST[Test Workspace<br/>most of IT]
    TST --> PRD[Prod Workspace<br/>only Prod-Admin group]
    DEV -.->|Pipeline Admin = group<br/>+ named individuals| PIPE[Deployment Pipeline]
    TST -.-> PIPE
    PRD -.-> PIPE
    PIPE -.->|Fabric audit log<br/>captures named user| LOG[(Audit / SIEM)]
```

### 6.5 Workspace Identity Provisioning Checklist (machine access)

```mermaid
flowchart TD
    START([New Workspace Identity needed]) --> CREATE[Create WS Identity<br/>in Workspace Settings]
    CREATE --> GRANT[Explicitly grant the<br/>workspace role<br/>⚠ no default Contributor since Jul 2025]
    GRANT --> NEEDS{What does it need<br/>to reach?}
    NEEDS -->|Another Fabric WS| W[Add WS Identity to<br/>target workspace role]
    NEEDS -->|Key Vault secrets| K[Grant Key Vault<br/>Secrets User on the vault]
    NEEDS -->|ADLS Gen2 / Blob| B[Grant Storage Blob<br/>Data Reader/Contributor]
    NEEDS -->|External SQL / API| S[Add to data-source<br/>access list]
    W & K & B & S --> CONN[Create Fabric connection<br/>auth = Workspace Identity]
    CONN --> DOC[Record in inventory<br/>standard naming]
```

### 6.6 Current vs. Target State (manager view)

```mermaid
flowchart LR
    subgraph TODAY["TODAY — high friction"]
      T1[Users added individually<br/>to each workspace]
      T2[Hundreds of duplicate<br/>connections]
      T3[Service principals<br/>provisioned ad-hoc]
      T4[Prod deploy access<br/>= same as Dev]
      T5[Auditability OK<br/>but onboarding slow]
    end

    subgraph TARGET["TARGET — low friction, governed"]
      G1[Entra groups by<br/>env × role and<br/>domain × role]
      G2[Standardized connection<br/>naming + WI auth in Prod]
      G3[Workspace Identity<br/>with provisioning checklist]
      G4[Restricted Prod-Admin<br/>group + named individuals]
      G5[Audit log retained;<br/>onboarding = 1 group add]
    end

    TODAY -->|3-phase rollout:<br/>1 Groups, 2 WS Identity, 3 Connections cleanup| TARGET
```

---

## 7. Recommended Sequencing

1. **Stand up the Entra group catalog** (one week). Naming standard, no permission changes yet.
2. **Pilot in CI/CD workspaces** — assign groups, perform actions as different members, confirm Fabric audit log resolves to the individual.
3. **Workspace Identity provisioning checklist** — publish, then retrofit existing workspaces one domain at a time.
4. **Migrate users**: replace individual assignments with group assignments domain-by-domain (Finance first, since data-mart use case is already live).
5. **Connection consolidation** — once groups are on connections, delete orphans.
6. **Tenant-admin hardening pass** against the Microsoft Fabric security baseline.
7. **Secure tier** — design and apply OneLake security roles for HR / financial data.

---

## 8. Open Questions to Resolve

- Does Fabric audit log resolve individual identity when access is granted *only* via a nested group? (Plan: test in CI/CD workspace; Microsoft Docs say yes.)
- For deployment pipelines, will dual-assignment (group + individual) cause "who deployed" attribution to flip? (Test.)
- Is the older on-prem SQL Server compatible with the service-account model Chris is building, or only the new SQL platform?
- Is "Fabric IQ" (mentioned at end) relevant to governance posture? Triage separately.

---

*Prepared from the meeting transcript and cross-referenced with Microsoft Learn (Fabric Well-Architected security guidance, Workspace Roles reference, RLS guidance, Deployment Pipelines permissions, Azure Security Baseline for Fabric).*