IT Admin Security Engineer Data Architect — A layered reference for designing, implementing, and auditing Microsoft Fabric security.
Defense-in-Depth Security Model
Microsoft Fabric implements a layered security approach — every layer adds protection so that no single breach compromises your entire estate. Click any layer to jump to its section.
Defense-in-depth means no single layer is sufficient on its own. Even if an attacker bypasses identity controls, workspace isolation, data-level security, and network restrictions each provide additional barriers. Implement all layers for a robust security posture.
Identity & Access Management
Microsoft Entra ID is the single identity provider for all Fabric access — every request is authenticated before it reaches any resource.
Human Identity
🔑 Microsoft Entra ID
All Fabric authentication goes through Entra ID. Users sign in with organizational accounts, and every API call requires a valid Entra token.
- Single Sign-On (SSO) — seamless access across Fabric, Power BI, and Microsoft 365
- Multi-Factor Authentication (MFA) — enforce MFA for all users, especially admins
- Entra ID Groups — assign workspace roles and security policies to groups, not individuals
🚦 Conditional Access
Use Entra ID Conditional Access policies to control how and from where users access Fabric.
- Location-based — restrict to trusted networks or named locations
- Device compliance — require Intune-compliant or domain-joined devices
- Session controls — enforce sign-in frequency, block persistent sessions
- Risk-based — step-up MFA for risky sign-ins detected by Entra ID Protection
Workload Identity
🤖 Service Principals
Use service principals for automation and CI/CD pipelines instead of user accounts.
- Enable "Service principals can use Fabric APIs" in admin portal
- Assign to security groups for scoped access
- Use certificates over secrets — shorter rotation, no password leaks
- Apply Conditional Access policies to restrict where they operate
🔗 Managed Identities
Managed identities enable credential-free authentication from Fabric to Azure resources.
- System-assigned — lifecycle tied to the Fabric resource
- User-assigned — reusable across multiple resources
- Use for connecting to ADLS, Key Vault, SQL without storing credentials
Workspace Identity
Each Fabric workspace can have an automatically managed workspace identity — an Entra ID service principal tied to the workspace lifecycle. It enables credential-free, secure access from Fabric items to external Azure resources without managing secrets or certificates.
🪪 What It Is
- A managed Entra ID service principal automatically created for the workspace
- Authenticates the workspace (not a user) when accessing external resources
- Credentials managed entirely by Fabric — no secrets or certificates to rotate
- Automatically deleted when the workspace is removed
- Registered in the tenant's Entra ID as an app registration you can assign RBAC roles to
⚙️ How to Enable
- Open workspace Settings → Identity
- Toggle "Workspace identity" to On
- Copy the generated Application (client) ID and Object ID
- On the target Azure resource (e.g., ADLS Gen2), assign RBAC roles using the identity's Object ID
- Configure Fabric items to use "Workspace Identity" as the authentication method
Supported Scenarios
CREDENTIAL = 'WorkspaceIdentity' for supported bulk loads.Trusted Workspace Access
Trusted workspace access allows Fabric to securely connect to firewall-enabled or private-endpoint–only Azure storage accounts — without opening public network access.
🔒 How It Works
- Storage account has public access disabled (firewall-only)
- Add a resource instance rule on the storage account that trusts the specific Fabric workspace
- Workspace identity authenticates with Entra ID and presents the workspace's identity token
- Azure Storage validates the token against the resource instance rule and grants access
No VNet, private endpoint, or IP whitelisting required from the Fabric side.
🛡️ Configuration Steps
- Enable workspace identity (see above)
- Create the storage account resource instance rule using an ARM template or PowerShell — Fabric workspace rules cannot be added from the Azure portal UI
- Use resource type
Microsoft.Fabric/workspaceswith the fixed Fabric resource ID format:/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/Fabric/providers/Microsoft.Fabric/workspaces/{workspaceId} - Assign RBAC (e.g.,
Storage Blob Data Contributor) to the workspace identity's Object ID - In Fabric, configure the connection with "Workspace Identity" auth
The subscription GUID and resource group name above are literal constants required by Fabric — only {workspaceId} changes.
OnCopy & OnWrite Access Patterns
📥 OnCopy (Read from firewalled storage)
- Fabric reads data from ADLS behind a firewall during copy/ingest operations
- Requires
Storage Blob Data Readerrole on the workspace identity - Used by: Shortcuts, Copy Activity, T-SQL COPY INTO, Dataflows Gen2
- Data is copied into OneLake — subsequent reads don't hit the external source
📤 OnWrite (Write back to firewalled storage)
- Fabric writes results or exports data back to protected ADLS accounts
- Requires
Storage Blob Data Contributorrole on the workspace identity - Used by: Data Pipelines (sink), Spark notebooks, Warehouse CETAS
- Supports incremental write patterns for ETL/ELT pipelines
Requirements, limitations, and known issues
- F SKU needed for Trusted Workspace Access — workspace identity itself can be created in any workspace, but consuming it for trusted workspace access requires a purchased F SKU capacity
- No personal workspaces — "My Workspace" cannot have a workspace identity
- One identity per workspace — you cannot create multiple identities for a single workspace
- Identity name = workspace name — the identity's display name always matches the workspace name and cannot be customized
- Admin role required — only workspace Admins can enable/manage the identity
- RBAC propagation delay — after assigning roles, allow up to 5 minutes for changes to take effect
- No cross-tenant support — workspace identity can only access resources in the same Entra ID tenant
- Do NOT modify the app registration — deleting or renaming the Entra ID service principal/app registration behind the identity will break Fabric functionality (adding API permissions is safe)
- Implicit trust within workspace — anyone with a workspace role (Member, Contributor) can assume the identity for supported operations; follow least-privilege workspace role assignments
- Connector coverage is evolving — not all Fabric connectors support workspace identity authentication yet; check the latest docs for your specific data source
- Contributor role removed (July 2025) — workspace identity no longer gets automatic Contributor access; admins must explicitly assign roles on target resources
- Don't use personal user accounts for scheduled refreshes, pipelines, or automated processes — if that user leaves, all dependent workloads break
- Don't forget to add the resource instance rule on the storage account — RBAC alone won't bypass the firewall
- Don't confuse workspace identity with managed identity for Azure resources — workspace identity is Fabric-specific
Workspace Security
Workspaces are the primary security boundary in Fabric — they determine who can access, create, and manage artifacts.
Built-in Workspace Roles
| Role | Permissions | Typical Assignment | OneLake Access |
|---|---|---|---|
| Admin | Full control: manage access, delete workspace, configure settings | Workspace owners, IT admins | Full |
| Member | Create, edit, delete artifacts; publish reports; share items | Data engineers, developers | Full |
| Contributor | Create and edit artifacts; cannot manage workspace access, but can share individual items when granted Reshare | Analysts, junior developers | Full |
| Viewer | View and interact with artifacts (read-only); can also reshare items if granted Reshare | Business users, stakeholders | Restricted by OneLake security roles |
Admin, Member, and Contributor roles have full read/write access to all OneLake data in the workspace, so they bypass OneLake security roles. Those roles apply to users in the Viewer role or to users granted item-level Read access. Design your workspace access carefully — don't give Member/Contributor access to users who should only see a subset of data.
Workspace Isolation Patterns
🏗️ Environment Separation
Separate workspaces for Dev → Test → Prod. Each environment has its own access list, ensuring developers can't accidentally modify production data.
🏢 Domain Boundaries
Organize workspaces into Fabric Domains (Finance, Marketing, HR) so domain owners can apply delegated governance settings. Note that domain assignment is an organizational and discoverability construct — it does not by itself change item visibility or access.
🔒 Sensitivity Tiers
Create separate workspaces for sensitive vs. non-sensitive data. Apply stricter Conditional Access and audit policies to high-sensitivity workspaces.
⚡ Capacity Isolation
Assign critical workspaces to dedicated capacities. This provides resource isolation and ensures one team's heavy workloads don't impact another's.
Use Entra ID security groups for role assignments instead of individual users. This makes access auditable, scalable, and easy to update when team members change.
Item-Level Permissions
Beyond workspace roles, you can grant granular permissions on individual items — reports, semantic models, warehouses, and more.
Permission Types
Not every Fabric item supports every permission below. Confirm the item's permission panel and documentation before designing an access model around ReadAll, ReadData, Execute, or Reshare.
| Permission | What It Allows | How It's Granted |
|---|---|---|
| Read | View and interact with the item | Sharing dialog, app audience, direct link |
| ReadAll | Access the underlying data in OneLake (files and folders) | Item permissions panel |
| ReadData | Query data via SQL analytics endpoint | Item permissions panel |
| Write | Edit the item (notebooks, reports, pipelines) | Workspace role (Contributor+) or item-level grant |
| Reshare | Share the item with other users | Sharing dialog option "Allow recipients to share" |
| Execute | Run pipelines or notebooks | Item permissions panel |
Sharing & Distribution
📤 Direct Sharing
Share individual items with specific users or groups. Choose whether recipients can reshare or build on the data. Use sparingly — it creates hard-to-audit one-off permissions.
📱 Fabric Apps
Package reports and dashboards into an app with defined audiences. Apps provide a curated, read-only experience — the recommended way to distribute content to business users.
🏷️ Endorsement Signals
- Promoted — workspace members mark items as reliable and ready for use
- Certified — designated reviewers certify items meet governance standards
Endorsed items appear with badges in search, making trusted data easy to find.
If you find yourself sharing dozens of items individually, you probably need to redesign your workspace structure. Prefer workspace roles + apps over per-item sharing. Run the access review in Admin Portal quarterly to clean up stale permissions.
Data-Level Security
Control exactly which rows, columns, and objects each user can see — even when they have access to the item itself.
Choose the Right Control
Rows: RLS
Filter records by user, region, department, or another business attribute in Warehouse, semantic models, or OneLake.
Columns: CLS
Prevent roles from querying sensitive columns in Warehouse or through OneLake security policies.
Objects: OLS
Hide tables, folders, schemas, or model objects through OneLake or semantic-model security.
Values: DDM
Return masked values to nonprivileged SQL users while keeping the stored data unchanged.
Source Policy: OneLake
Define object, row, and column access at the data source for enforcement through supported engines.
Warehouse SQL controls apply to SQL queries, semantic-model roles apply through Power BI, and OneLake policies apply at the shared data source through supported engines. Choose the lowest layer that must consistently enforce the requirement.
Row-Level Security (RLS)
RLS filters data at query time so users only see rows they're authorized to access. Available in Power BI semantic models and Fabric Warehouse.
Implementation example: Warehouse RLS
-- Create a security predicate function CREATE FUNCTION dbo.fn_security_predicate(@Region AS nvarchar(50)) RETURNS TABLE WITH SCHEMABINDING AS RETURN SELECT 1 AS result WHERE @Region = USER_NAME() OR USER_NAME() = 'admin@contoso.com'; -- Apply security policy to a table CREATE SECURITY POLICY RegionFilter ADD FILTER PREDICATE dbo.fn_security_predicate(Region) ON dbo.SalesData WITH (STATE = ON);
Define roles and DAX filter expressions in Power BI Desktop. Test with "View as role" before publishing. RLS is enforced in the Power BI service, apps, and embedded scenarios — but not when querying the underlying lakehouse directly.
Column-Level Security (CLS)
CLS restricts access to specific columns using standard SQL GRANT and DENY statements in Fabric Warehouse.
Implementation example: Warehouse CLS
-- Deny access to salary column for a specific role DENY SELECT ON dbo.Employees(Salary, SSN) TO [LimitedAccess]; -- Grant access to only specific columns GRANT SELECT ON dbo.Employees(EmployeeId, Name, Department) TO [LimitedAccess];
Object-Level Security (OLS)
OLS hides entire tables or columns from specific users in Power BI semantic models. Unlike CLS which returns an error, OLS makes the object completely invisible — users don't even see it in field lists.
- Configure OLS in Tabular Editor or XMLA endpoint
- Define roles with
Nonepermission on specific tables or columns - Users in that role won't see the objects in reports, DAX queries, or metadata
Dynamic Data Masking (DDM)
DDM masks sensitive data in query results without changing the stored data. Non-privileged users see masked values; privileged users see the original. Available in both Fabric Warehouse and Lakehouse SQL analytics endpoint.
Implementation example: Dynamic Data Masking
-- Mask email column with partial masking ALTER TABLE dbo.Customers ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()'); -- Mask phone with custom partial mask (show last 4 digits) ALTER TABLE dbo.Customers ALTER COLUMN Phone ADD MASKED WITH (FUNCTION = 'partial(0,"XXX-XXX-",4)'); -- Full mask on SSN (returns "xxxx") ALTER TABLE dbo.Customers ALTER COLUMN SSN ADD MASKED WITH (FUNCTION = 'default()'); -- Grant UNMASK to privileged roles GRANT UNMASK ON dbo.Customers TO [PrivilegedAnalysts];
DDM, RLS, CLS, and OLS are complementary, not alternatives. A robust setup uses RLS to filter rows, CLS to restrict columns, DDM to mask remaining sensitive values, and OLS to hide objects from Power BI users who shouldn't see them at all.
OneLake Security
The unified data-plane security model for OneLake — define access once across objects, rows, and columns, then enforce it through supported analytics engines.
Workspace roles and item permissions form the control plane: they govern who can discover, configure, share, or manage an item. OneLake security roles form the data plane: they govern which data a principal can read or write inside the item. A secure design evaluates both planes.
Model at a Glance
OneLake Security Role Model
🔑 Permissions & Type
Roles use a grant-only model. Grant Read, or ReadWrite where the item type supports granular writes.
- No explicit deny role type
- ReadWrite can apply to selected folders and tables
- A grant from another role can expand effective access
🗂️ Data in Role
Scope a role to structured or unstructured data, from broad containers down to fine-grained table policies.
- OLS: schemas, tables, folders, and subfolders
- CLS: selected columns in Delta or virtualized Iceberg tables
- RLS: row-filter expressions for tabular data
👥 Members in Role
Assign Microsoft Entra users, security groups, or non-user identities directly, or use virtual membership based on Fabric permissions.
- Prefer security groups over individual assignments
- Review the built-in DefaultReader role
- Remove users from DefaultReader when assigning restricted roles
How Policies Are Evaluated
The user receives only the objects, rows, and columns allowed by every control in that role.
OLS ∩ RLS ∩ CLSAccess provided by any role generally contributes to the user's effective permissions.
Role 1 ∪ Role 2 ∪ ...If any applicable role hides a column, the SQL analytics endpoint blocks that column.
Effective access is limited by permissions at both the shortcut location and its target.
Shortcut access ∩ target accessWhen row and column restrictions must apply together, define them in the same OneLake security role. Unsupported combinations across separate roles can cause query failures, and grants from another role can unintentionally broaden access.
Central Policy, Distributed Enforcement
OneLake stores the security definitions and calculates each principal's effective access. A supported query engine receives that effective policy and enforces it during query execution. This enables engine-native filtering and optimization while keeping OneLake as the source of truth.
Enforces OLS, RLS, and CLS for supported tables and runtime versions.
Use querying-user identity mode so policies are evaluated per user.
The semantic model must use Direct Lake on OneLake mode.
Retrieve effective access and enforce the policy in their own query layer.
Partially secured RLS or CLS tables are blocked rather than returned without filtering.
Shortcut Security
➡️ Passthrough
The querying user's identity is evaluated at the target. This is the default for same-tenant OneLake-to-OneLake shortcuts.
🔗 Delegated
A connection identity accesses the target, while OneLake security limits what the calling user can consume through the shortcut.
🛡️ Most Restrictive Path
Effective access is constrained by both the shortcut location and its target. Source policies remain authoritative in downstream workspaces.
Operate the Model
Review principals, update workspace roles in bulk, and administer OneLake roles across workspaces. See Catalog & Governance for the wider catalog experience.
Stream API, application, engine, and shortcut access events into a lakehouse. Use the Fabric audit log for control-plane changes such as role edits and sharing.
Key Limitations & Considerations
Admins, Members, and Contributors already have broad data access. Use Viewer or item-level Read for restricted consumers.
Edit or remove this broad ReadAll assignment before expecting a restricted custom role to reduce lakehouse access.
Values remain protected, but some experiences and error messages can still reveal table or column names.
Role changes take minutes; Entra group updates and engine caches can take substantially longer.
Design for documented role, member, and permission limits. Prefer group-based roles over one role per user.
Guests need compatible Entra settings, and some engines can't resolve distribution-list membership.
Keep authoritative data and security policies in a primary workspace, assign consumers Viewer plus the appropriate OneLake roles, and expose the secured source to downstream workspaces through shortcuts. This avoids duplicating policies and keeps source owners in control.
📚 Continue by Goal
Information Protection
Classify, label, and protect data throughout its lifecycle with Microsoft Purview and Data Loss Prevention policies.
Sensitivity Labels
Microsoft Purview sensitivity labels (e.g., "Public," "Internal," "Confidential," "Highly Confidential") can be applied to Fabric artifacts to classify and protect data.
🏷️ How Labels Work
- Applied to lakehouses, warehouses, semantic models, reports, and more
- Labels flow downstream automatically — a labeled lakehouse passes its label to reports built on it
- Labels can enforce encryption on exported files (Excel, PDF, PowerPoint)
- Labels are visible in workspace lists, search results, and lineage views
⚙️ Configuration
- Define labels in the Microsoft Purview compliance portal
- Set auto-labeling policies to automatically apply labels based on content patterns (e.g., credit card numbers, SSNs)
- Enable mandatory labeling in Fabric admin portal — fully enforced for Power BI items, with expanding support for other Fabric items
- Control who can apply or change specific labels with label scoping
Data Loss Prevention (DLP)
DLP policies for Fabric and Power BI evaluate supported items when their data changes, helping surface and contain sensitive data.
- Evaluation on data change — supported items (such as semantic models and lakehouses) are scanned when their data is updated, not as a real-time network-egress filter
- Policy tips — show inline warnings to owners when a policy matches
- Restrict access (preview) — limit who can reach a matched item
- Alert admins — send notifications when DLP rules are triggered
- Sensitive info types & trainable classifiers — detection goes beyond simple regex rules
Fabric DLP does not act as a generic export/download block across the platform, and DLP is not currently supported for Copilot in Fabric AI interactions. Verify supported item types in the current Microsoft Purview documentation before relying on DLP as a control.
Encryption & Key Management
🔐 Encryption at Rest
All data stored in OneLake is encrypted at rest using Microsoft-managed keys by default. For regulated workloads, enable customer-managed keys (CMK) to retain control of your encryption keys via Azure Key Vault.
🔒 Encryption in Transit
All communications use TLS 1.2+ encryption. This applies to user-to-Fabric, Fabric-to-data-source, and inter-service traffic within the platform.
Copilot & AI Data Boundaries
✅ Controls Copilot Respects
- Workspace and item permissions
- RLS and CLS on supported access paths
- Tenant isolation
- Unified audit logging and Purview DSPM for AI monitoring
⚠️ Boundaries to Review
- Labels and Fabric DLP aren't direct Copilot enforcement controls
- Over-permissioned source content remains over-permissioned to AI
- Cross-region processing depends on tenant settings
- Confirm data residency and compliance requirements before rollout
Audit your permissions model before rolling out Copilot. Over-permissioned content is the #1 source of AI data security incidents. Because labels and DLP don't gate Copilot, workspace and item permissions plus RLS/CLS are your real enforcement boundary. Also confirm the cross-geo processing tenant setting matches your compliance requirements.
Network Security
Control network traffic to, from, and within Fabric using private connectivity, managed networks, and zero-trust architecture.
🔒 Inbound — Users to Fabric
- Azure Private Link — route all traffic through private endpoints in your VNet
- Conditional Access — enforce device compliance, location, MFA
- Tenant restrictions — prevent data exfiltration to unauthorized tenants
🔗 Outbound — Fabric to Data
- Managed Private Endpoints (MPE) — Fabric connects to resources through Azure backbone
- VNet Data Gateways — bridge to on-premises or VNet-isolated resources
- Trusted Workspace Access — firewalled storage trusts specific Fabric workspaces
🛡️ Internal — Between Services
- Managed VNets — Spark runs in Fabric-managed VNets with controlled egress
- Service tags — NSG rules using
DataFactoryandPowerBItags - Encryption in transit — TLS 1.2+ for all communications
Network Decision Quick Reference
| Scenario | Approach | SKU Min |
|---|---|---|
| Corporate-only access to Fabric | Private Link + block public | F64 |
| Spark reads from firewalled ADLS | Managed Private Endpoints | F64 |
| OneLake shortcuts to firewalled storage | Trusted Workspace Access | F2 |
| On-premises SQL connectivity | VNet Data Gateway | F2 |
| Full zero-trust posture | Private Link + MPE + Managed VNet + CA | F64 |
🌐 Continue with the Full Networking Guide
Architecture, setup, DNS, and troubleshooting → Private Links ↗Monitoring & Audit
Continuous monitoring, audit trails, and threat detection to ensure your security controls are working and to investigate incidents.
Investigate sharing, permission, administration, and user activity.
Answer who accessed which data, when, through which engine or shortcut, and with what result.
Detect anomalous activity and apply supported real-time session controls.
Correlate operational failures, capacity pressure, tenant settings, and workload behavior with security events.
- Forward Fabric audit logs to Microsoft Sentinel for centralized security monitoring and automated incident response
- Enable OneLake diagnostics for workspaces that hold sensitive or regulated data
- Enable MDCA policies — at minimum: unusual data download, risky sign-in, mass sharing detection
- Review admin portal weekly — check tenant settings, new workspace creation, and external sharing activity
- Automate alerts — use Activator or Logic Apps to notify security teams of critical events
Putting It All Together
See how all 8 security layers work together in a real scenario — a multinational company deploying Fabric for regional sales analytics.
Contoso Corp has three sales regions — EMEA, Americas, and APAC. Regional analysts should only see their own region's data. A central analytics team needs full access. Customer PII (emails, phone numbers) must be masked for most users. The platform ingests data from an on-premises SQL Server via a gateway and must meet enterprise compliance requirements.
View implementation
SG-Sales-EMEA, SG-Sales-Americas, SG-Sales-APAC, and SG-Analytics-Central.
Apply a Conditional Access policy requiring MFA for all Fabric access and blocking sign-ins from non-compliant devices.
Create a service principal SP-Sales-ETL for automated data pipelines — no interactive user required.
View implementation
Sales-Dev and Sales-Prod. The central analytics team gets Contributor on both.
Regional groups get Viewer on Prod only — they never see Dev. The ETL service principal gets Contributor on Prod for automated loads.
Both workspaces are assigned to the "Sales" domain for governance and to a dedicated F64 capacity to prevent noisy-neighbor issues.
View implementation
ReadData permission to the data science team for ad-hoc SQL queries, without granting workspace access.
All production semantic models carry the "Certified" endorsement badge.
View implementation
[Region] = USERPRINCIPALNAME() mapped via a security table, so EMEA analysts see only EMEA rows.Column-Level Security: The
ProfitMargin column is restricted — only SG-Analytics-Central can see it.Dynamic Data Masking:
CustomerEmail shows as jXXX@XXX.com for regional analysts; the central team sees full values.
View implementation
SP-Sales-ETL can access /raw/, apply regional RLS to curated sales tables, and hide sensitive source columns with CLS.
Supported Spark, SQL, and Direct Lake access paths then evaluate the policies defined at the source instead of relying on separate rules in every consumer.
View implementation
View implementation
View implementation
No single layer is sufficient on its own. An EMEA analyst in this scenario is protected by: identity (MFA + group membership) → workspace (Viewer role, Prod only) → item (app audience) → data (RLS filters EMEA rows, CLS hides margins, DDM masks email) → OneLake (no raw folder access) → labels (export restrictions) → network (private connectivity) → monitoring (anomaly alerts). Compromise of any one layer still leaves 7 others enforcing protection.
Security Hardening Checklist
Track your Fabric security posture across all layers. Progress is saved in your browser.