Fabric Security and Governance: Workspace Roles, OneLake Data Access, Item Permissions, Sensitivity Labels, Purview Integration, and Data Lineage

Security in Fabric is not optional — it is the difference between “our data platform” and “our data breach.” Every company that deploys Fabric must answer: who can see what data, who can modify what items, how do we track who accessed sensitive information, and how do we prove compliance to auditors.

This post covers every security layer in Fabric — from workspace roles (who enters the building) to row-level security (who sees which rows) to sensitivity labels (classifying data as Confidential/Internal/Public) to Purview integration (governance at scale).

Think of Fabric security like building security. Workspace roles are the building access card (which floors can you enter). Item permissions are room keys (which specific rooms). OneLake data access roles are filing cabinet locks (which drawers within a room). Row-level security is individual folder access (which documents within a drawer). Each layer narrows access further.

Table of Contents

• The Security Layers (Overview)
• Workspace Roles (Building Access)
• Admin, Member, Contributor, Viewer
• Who Gets Which Role
• Item-Level Permissions
• Sharing Items (Read, ReadAll, Reshare, Build)
• OneLake Data Access Roles
• Creating Custom Data Roles
• Row-Level Security (RLS)
• RLS in Warehouse (T-SQL)
• RLS in Lakehouse (SQL Endpoint)
• RLS in Semantic Models (DAX)
• Column-Level Security (CLS)
• Dynamic Data Masking
• Sensitivity Labels
• Classifying Data (Confidential, Internal, Public)
• How Labels Flow Downstream
• Microsoft Purview Integration
• Data Lineage
• Data Catalog
• Data Classification
• Endorsement (Promoted and Certified)
• Audit Logs
• Real-World Security Architecture
• Scenario: Multi-Team Data Platform
• Common Mistakes
• Interview Questions
• Wrapping Up

The Security Layers (Overview)

Layer 1: WORKSPACE ROLES
  "Which workspace can you access?"
  Admin / Member / Contributor / Viewer

Layer 2: ITEM PERMISSIONS
  "Which specific items (notebooks, pipelines) can you use?"
  Read / ReadAll / Reshare / Build

Layer 3: ONELAKE DATA ACCESS ROLES
  "Which tables/folders within a Lakehouse can you read?"
  Custom roles on Tables and Files folders

Layer 4: ROW-LEVEL SECURITY
  "Which rows within a table can you see?"
  Filter predicates per user/role

Layer 5: COLUMN-LEVEL SECURITY
  "Which columns can you see?"
  GRANT SELECT on specific columns only

Layer 6: DYNAMIC DATA MASKING
  "What do masked values look like?"
  Show partial/masked data to unauthorized users

Layer 7: SENSITIVITY LABELS
  "How is this data classified?"
  Confidential / Internal / Public — flows to exports

Workspace Roles (Building Access)

Role	Create Items	Edit Items	Delete Items	Share Items	Run Pipelines	View Data	Manage Access
Admin	✅	✅	✅	✅	✅	✅	✅
Member	✅	✅	✅	✅	✅	✅	❌
Contributor	✅	✅	Own items only	❌	✅	✅	❌
Viewer	❌	❌	❌	❌	❌	✅ (read-only)	❌

Who Gets Which Role

Person	Role	Why
Data Engineering Lead	Admin	Manages workspace, access control
Data Engineers	Member	Create/edit all items, run pipelines
Junior Engineers	Contributor	Create and edit but cannot share
Business Analysts	Viewer	View reports, query via SQL endpoint
External Auditors	Viewer (temporary)	Read-only access during audit period

Item-Level Permissions

Beyond workspace roles, you can share SPECIFIC items with people outside the workspace:

Sharing a Semantic Model:
  Share with: analyst@company.com
  Permissions:
    ✅ Read (can view reports built on this model)
    ✅ Build (can create their own reports on this model)
    ❌ Reshare (cannot share with others)

OneLake Data Access Roles

Control access to specific TABLES and FOLDERS within a Lakehouse:

Lakehouse: sales_lakehouse
  ├── Tables/
  │     ├── customers ← Marketing team CAN access
  │     ├── orders    ← Marketing team CAN access
  │     └── salaries  ← Marketing team CANNOT access (HR only)
  └── Files/
        └── raw_data/ ← Marketing team CANNOT access

Creating Custom Data Roles

1. Open Lakehouse → Manage OneLake data access
2. Click New role
3. Name: marketing_read
4. Add tables: customers, orders (NOT salaries)
5. Add members: marketing_group@company.com
6. Permission: Read
7. Save

Row-Level Security (RLS)

RLS in Warehouse (T-SQL)

-- Step 1: Create filter function
CREATE FUNCTION dbo.fn_region_filter(@region VARCHAR(50))
RETURNS TABLE WITH SCHEMABINDING
AS RETURN SELECT 1 AS result
WHERE @region = USER_NAME()
   OR USER_NAME() = 'admin@company.com';

-- Step 2: Apply security policy
CREATE SECURITY POLICY dbo.RegionSecurity
ADD FILTER PREDICATE dbo.fn_region_filter(region) ON gold.fact_sales
WITH (STATE = ON);

-- Result:
-- east_manager@company.com → sees only East region rows
-- west_manager@company.com → sees only West region rows
-- admin@company.com → sees ALL rows

RLS in Semantic Models (DAX)

// In the semantic model, create a role:
// Role name: RegionalAccess
// Table: fact_sales
// DAX filter: [region] = USERPRINCIPALNAME()

Column-Level Security (CLS)

-- Grant access to specific columns only
GRANT SELECT ON gold.dim_customer (customer_id, name, city, country) TO [analyst@company.com];
-- Analyst sees name and city but NOT email, phone, or salary

DENY SELECT ON gold.dim_customer (email, phone, ssn) TO [marketing_group];

Dynamic Data Masking

-- Mask email: shows nXXX@XXXX.com
ALTER TABLE gold.dim_customer ALTER COLUMN email ADD MASKED WITH (FUNCTION = 'email()');

-- Mask phone: shows 416-XXX-XXXX
ALTER TABLE gold.dim_customer ALTER COLUMN phone ADD MASKED WITH (FUNCTION = 'partial(3,"XXX-XXX-",4)');

-- Mask salary: shows 0
ALTER TABLE gold.dim_customer ALTER COLUMN salary ADD MASKED WITH (FUNCTION = 'default()');

-- Unmask for specific users
GRANT UNMASK ON gold.dim_customer TO [hr_admin@company.com];

Sensitivity Labels

Classify data to control how it can be exported and shared:

Label	Meaning	Export Controls
Public	Non-sensitive	No restrictions
Internal	Company-internal	Warning on external sharing
Confidential	Sensitive business data	Encryption on export, restricted sharing
Highly Confidential	PII, financial, regulated	Encrypted, audit-logged, no external sharing

Labels apply to: Lakehouses, Warehouses, Semantic Models, Reports, Pipelines. They flow downstream — a report built on a Confidential dataset automatically inherits the Confidential label.

Microsoft Purview Integration

Data Lineage

Purview shows the complete flow of data through Fabric:

Azure SQL → Pipeline → Bronze Lakehouse → Notebook → Silver Lakehouse → Notebook → Warehouse → Semantic Model → Report

Every hop is visible. Click any item to see its upstream sources and downstream consumers.

Data Catalog

Purview catalogs ALL Fabric items — searchable by name, description, tags, classification. Analysts can discover datasets without asking engineers “where is the customer data?”

Endorsement (Promoted and Certified)

Status	Meaning	Who Can Set
None	Default — not validated	Anyone
Promoted	“This is recommended for use”	Any Member
Certified	“This is officially validated and trusted”	Designated Certifiers only

gold.dim_customer → Certified ✅ (approved by data governance team)
staging.stg_temp_data → None (experimental, not for production use)

Real-World Security Architecture

Workspace: DataEng_Prod (production)
  Roles: DE Lead = Admin, Engineers = Member, Analysts = Viewer

  Lakehouse: silver_lakehouse
    OneLake roles: engineering_team = full access
                   analyst_team = Tables only (no Files)

  Warehouse: gold_warehouse
    Schemas:
      staging → DENY SELECT to analysts (engineers only)
      gold → GRANT SELECT to analysts
      reports → GRANT SELECT to analysts

    RLS: Regional managers see only their region
    CLS: HR columns (salary, SSN) visible to HR role only
    Masking: Email/phone masked for marketing team

  Semantic Model: Sales Analytics
    Direct Lake on gold_warehouse
    RLS Role: RegionalAccess (DAX filter on region)
    Label: Confidential
    Endorsement: Certified ✅

  Report: Monthly Revenue Dashboard
    Inherits Confidential label from semantic model
    RLS enforced — each manager sees only their data

Common Mistakes

1. Giving everyone Admin role — Admin can delete items and manage access. Most engineers need Member, most analysts need Viewer.

2. Not implementing RLS — without it, every Viewer sees ALL data. Regional managers see other regions. Compliance violation.

3. Forgetting sensitivity labels — a Confidential report exported to Excel without a label loses its protection. Labels travel with the data.

4. Not using OneLake data access roles — workspace Viewer sees ALL tables in a Lakehouse. Use data access roles to restrict to specific tables.

5. Relying only on workspace roles — workspace roles are coarse (all-or-nothing per workspace). Combine with item permissions, data access roles, and RLS for fine-grained control.

Interview Questions

Q: How does the security model work in Fabric? A: Seven layers from coarsest to finest: workspace roles (building access), item permissions (specific items), OneLake data access roles (tables/folders), row-level security (which rows), column-level security (which columns), dynamic data masking (masked values for unauthorized users), and sensitivity labels (data classification). Each layer narrows access further.

Q: What is the difference between RLS in Warehouse vs Semantic Model? A: Warehouse RLS uses T-SQL filter predicates — applies to SQL queries against the warehouse. Semantic Model RLS uses DAX filters — applies to Power BI reports. For complete protection, implement RLS at both layers.

Wrapping Up

Security is not a feature — it is a requirement. Every production Fabric deployment needs workspace roles for access control, RLS for data-level isolation, sensitivity labels for classification, and Purview for governance. The seven layers work together to create defense-in-depth.

Related posts: – Fabric Warehouse Practical Guide – Fabric Foundations – Git Integration & CI/CD

---

Naveen Vuppula is a Senior Data Engineering Consultant and app developer based in Ontario, Canada. He writes about Python, SQL, AWS, Azure, and everything data engineering at DriveDataScience.com.