Security Best Practices in Microsoft Fabric
Secure your Microsoft Fabric environment with proper access controls, workspace roles, row-level security, and data classification governance policies.
Security in Microsoft Fabric operates at five distinct layers—tenant, capacity, workspace, item, and data—each providing progressively finer-grained access control. A comprehensive Fabric security strategy addresses all five layers, because a gap at any level creates exposure. Organizations in regulated industries (healthcare, finance, government) face additional compliance requirements that make layered security not just a best practice but a regulatory mandate. Our Microsoft Fabric consulting team implements security architectures for enterprises where data breaches carry regulatory penalties, reputational damage, and legal liability.
I have been designing security architectures for enterprise data platforms for over 25 years, and the most common mistake I see is treating security as a single layer—typically workspace permissions. Teams set up workspace roles, consider security "done," and move on. Six months later, they discover that a contractor with Viewer access to a workspace can export underlying data containing PII, that a bidirectional relationship in a Power BI model bypasses row-level security, or that a Spark notebook has hardcoded credentials to a production database. Layered security prevents these scenarios by ensuring that a failure at one layer is caught by controls at another.
The Five Security Layers in Microsoft Fabric
| Layer | Scope | Controls | Primary Admin |
|---|---|---|---|
| Tenant | Entire organization | Tenant settings, conditional access, DLP | Fabric Admin / Global Admin |
| Capacity | Compute resources | Capacity admin roles, auto-scaling limits | Capacity Admin |
| Workspace | Content containers | Workspace roles (Admin, Member, Contributor, Viewer) | Workspace Admin |
| Item | Individual artifacts | Item-level sharing, per-item permissions | Item Owner |
| Data | Row and column level | Row-level security (RLS), column-level security (CLS), object-level security (OLS) | Data Modeler / Security Admin |
Each layer narrows access further. A user must pass all five layers to access specific data:
- Tenant: Are Fabric features enabled for this user's security group?
- Capacity: Is this user's workspace assigned to a capacity they can access?
- Workspace: Does this user have an appropriate workspace role?
- Item: Has this specific report/dataset been shared with this user?
- Data: Does row-level security allow this user to see these specific rows?
Layer 1: Tenant-Level Security
Tenant settings are the broadest security controls. Key security-relevant settings:
| Setting | Security Impact | Recommended Configuration |
|---|---|---|
| Export data controls | Determines what data can leave Fabric | Restrict underlying data export; allow aggregated exports for business users |
| External sharing | Controls sharing outside your Azure AD tenant | Restrict to specific security groups |
| Publish to web | Makes content publicly accessible | Disable in all enterprise environments |
| Custom visual restrictions | Custom visuals can access data in the visual | Allow only certified/organizational visuals |
| Sensitivity labels | Information classification and protection | Enable with mandatory labeling policy |
| Conditional Access | Azure AD policies for device/location requirements | Require compliant devices, block risky sign-ins |
Conditional Access policies are critically important and often overlooked. They allow you to enforce: - Multi-factor authentication for all Fabric access - Access only from compliant/managed devices - Block access from untrusted locations or countries - Require terms of use acceptance - Session controls (sign-out after inactivity)
Configure Conditional Access in Azure AD (now Entra ID) and target the Power BI and Microsoft Fabric cloud apps.
Layer 2: Capacity-Level Security
Capacity security controls who can administer and use Fabric capacity resources:
| Role | Permissions | Typical Assignees |
|---|---|---|
| Capacity Admin | Assign workspaces, configure settings, view metrics | Platform team leads |
| Capacity Contributor | Add workspaces to capacity (cannot remove or configure) | Department leads |
**Security consideration**: Capacity isolation is a physical security boundary. Workspaces on different capacities cannot share compute resources. For regulated data, use dedicated capacities to ensure that sensitive workloads do not share infrastructure with general-purpose analytics. See our capacity planning guide for multi-capacity architecture patterns.
Layer 3: Workspace-Level Security
Workspace roles are the primary content access control mechanism:
| Role | Create/Edit | Delete Others' Content | Share | Manage Permissions |
|---|---|---|---|---|
| Admin | Yes | Yes | Yes | Yes |
| Member | Yes | No | Yes | No |
| Contributor | Yes | No | No | No |
| Viewer | No | No | No | No |
Best practices for workspace security:
- Use Azure AD security groups exclusively. Never assign individual users to workspace roles. Security groups enable centralized management and audit trails.
- Minimize Admin and Member assignments. 2-3 Admins per workspace maximum. Members should be limited to active developers.
- Separate dev/test/prod workspaces. Developers have Member access to dev workspaces but only Viewer access to production. This prevents accidental production changes.
- **Audit workspace access quarterly.** Use the Admin API to export workspace role assignments and review with workspace owners.
See our workspace design guide for detailed patterns on workspace structure and access management.
Layer 4: Item-Level Security
Item-level permissions provide granular access to individual artifacts without granting workspace-wide access:
| Sharing Method | Use Case | Permissions Granted |
|---|---|---|
| Direct share (report) | Share a specific report with a colleague | View report + underlying data through report visuals |
| Direct share (semantic model) | Share dataset for Build permission | Build new reports on the shared dataset |
| App distribution | Distribute curated content to business users | View-only access to app contents |
| Link sharing | Generate a shareable URL | View access with optional edit permission |
| Embed | Embed in Teams, SharePoint, or custom app | View access within embedded context |
App distribution is the recommended method for delivering content to large audiences. Apps provide: - Curated content packages (selected reports, not everything in workspace) - Separate permissions from workspace roles (app viewers do not need workspace access) - Automatic updates when source content changes - Navigation structure that guides users to the right reports
Key security gap: When you share a report, the recipient can see all data in the report—unless RLS is configured. Sharing a report does not automatically restrict data to the recipient's scope. This is the most common security misunderstanding in Power BI deployments.
Layer 5: Data-Level Security
Data-level security is the most granular and most critical layer, especially for multi-tenant or role-based access patterns.
Row-Level Security (RLS)
Row-level security restricts which rows a user can see based on their identity:
| RLS Pattern | Implementation | Use Case |
|---|---|---|
| Static RLS | Hardcoded filter in role definition | Region = "West" for West team users |
| Dynamic RLS | USERNAME() or USERPRINCIPALNAME() in DAX filter | Each user sees only their own data |
| Manager hierarchy | Parent-child relationship with username mapping | Managers see their team's data |
| Custom security table | Mapping table: User → allowed dimension values | Flexible, maintainable at scale |
Dynamic RLS with a security table is the enterprise-recommended pattern:
Create a UserSecurity table with columns: UserEmail, DimensionKey (e.g., RegionKey, DepartmentKey). Create a relationship from UserSecurity to your dimension table. Define the RLS role with a DAX filter on UserSecurity that checks USERPRINCIPALNAME() = UserSecurity[UserEmail].
This pattern is maintainable because adding or changing user access only requires updating the UserSecurity table—no DAX modifications needed. For detailed implementation patterns, see our dynamic RLS guide.
Object-Level Security (OLS)
OLS hides specific tables or columns from certain roles:
| OLS Use Case | Implementation | Effect |
|---|---|---|
| Hide salary data from non-HR users | OLS role restricting Salary column access | Column not visible in reports or DAX |
| Hide financial projections from general users | OLS role restricting Forecast table | Table not accessible in any context |
| Restrict PII columns | OLS role hiding SSN, DOB columns | Columns invisible even in data export |
OLS is configured in Tabular Editor (not available in Power BI Desktop UI). It complements RLS by hiding entire columns/tables rather than filtering rows. This is essential for HIPAA-compliant analytics where certain data elements (SSN, medical record numbers) must be completely inaccessible to unauthorized users.
Column-Level Security (CLS) in Fabric Warehouse
The Fabric SQL Warehouse supports T-SQL GRANT and DENY at the column level:
| CLS Method | Syntax | Use Case |
|---|---|---|
| DENY SELECT on column | DENY SELECT ON dbo.Table(Column) TO Role | Block specific columns |
| GRANT SELECT on specific columns | GRANT SELECT ON dbo.Table(Col1, Col2) TO Role | Allow only specific columns |
| Dynamic Data Masking | CREATE TABLE with MASKED column definition | Show masked values (e.g., XXX-XX-1234) |
Security for Specific Fabric Workloads
Lakehouse Security
| Security Control | Implementation | Notes |
|---|---|---|
| Workspace RBAC | Standard workspace roles apply | Controls who can access Lakehouse items |
| SQL endpoint RLS | T-SQL security policies on SQL endpoint | Applies when querying via SQL |
| OneLake file access | Workspace role controls file access | No file-level ACLs currently |
| Shortcut security | Source permissions apply | OneLake shortcuts inherit source security |
Notebook Security
| Risk | Mitigation |
|---|---|
| Hardcoded credentials in notebook code | Use Azure Key Vault references |
| Notebook outputs visible to workspace viewers | Use separate dev/prod workspaces |
| PIP install of malicious packages | Restrict allowed packages via workspace libraries |
| Data exfiltration via notebook output | Monitor notebook runs via audit logs |
Pipeline Security
| Risk | Mitigation |
|---|---|
| Connection credentials exposed | Use managed identities or Key Vault |
| Pipeline runs accessing unauthorized data | Scope service principal permissions |
| Pipeline output to unsecured locations | Validate destination security before pipeline deployment |
Security Monitoring and Auditing
| Audit Source | What It Captures | Access Method |
|---|---|---|
| Unified Audit Log | All user and admin activities in Fabric | Microsoft 365 Compliance Center |
| Power BI Activity Log | Report views, exports, sharing actions | Admin API: Get-PowerBIActivityEvent |
| Capacity Metrics | Resource consumption per workspace | Capacity Metrics app |
| Azure AD Sign-in Logs | Authentication events, conditional access results | Azure AD portal |
| Sensitivity Label Activity | Label application and changes | Microsoft Purview compliance portal |
**Automate security monitoring** by exporting audit logs daily to a Fabric Lakehouse. Build a security monitoring dashboard that tracks: - Failed access attempts and unusual access patterns - High-volume data exports (potential data exfiltration) - Sensitivity label downgrades (potential classification violations) - New external sharing events (potential unauthorized sharing) - Workspace permission changes (access control modifications)
Security Configuration Checklist
| Priority | Security Control | Status |
|---|---|---|
| P0 | Disable Publish to web | |
| P0 | Restrict underlying data export | |
| P0 | Enable sensitivity labels with mandatory policy | |
| P0 | Configure Conditional Access (MFA, device compliance) | |
| P1 | Restrict workspace creation to security groups | |
| P1 | Implement RLS on all datasets with sensitive data | |
| P1 | Configure OLS for PII columns | |
| P1 | Enable audit logging and export to Lakehouse | |
| P2 | Restrict external sharing to security groups | |
| P2 | Review and remove custom visual permissions | |
| P2 | Implement security monitoring dashboard | |
| P2 | Schedule quarterly access reviews |
Common Security Mistakes
Mistake 1: Relying solely on workspace permissions Workspace Viewer can see ALL content in the workspace. Without RLS, a regional manager can see all regions' data. Always implement RLS when data access should be scoped by user identity.
Mistake 2: Not testing RLS RLS rules must be tested with "View as Role" in Power BI Desktop before deployment. Untested RLS rules frequently have gaps—especially around handling blank filter contexts.
Mistake 3: Bidirectional relationships breaking RLS Bidirectional cross-filtering can allow RLS filters to propagate in unexpected directions, potentially exposing data. Test thoroughly and prefer single-direction relationships.
Mistake 4: Ignoring export controls A user with report access can export underlying data to Excel unless export restrictions are configured at the tenant level. This is the most common data leakage vector in Power BI.
Mistake 5: No audit logging Without audit logging, you cannot detect or investigate security incidents. Enable logging before users access the system, not after an incident occurs.
Getting Started with Fabric Security
- Assess current state: Audit existing workspace permissions, sharing, and RLS configurations
- **Implement tenant settings**: Follow our tenant settings guide for security-critical configurations
- **Design workspace architecture**: Use our workspace design patterns for proper isolation
- Implement data-level security: Configure RLS, OLS, and CLS for sensitive data
- Enable monitoring: Set up audit logging and security dashboards
- Schedule reviews: Quarterly access reviews and annual security assessments
For organizations that need comprehensive Fabric security implementation, our Fabric consulting team provides security assessments, architecture design, RLS implementation, and compliance documentation. We specialize in regulated industries where security gaps carry legal and financial consequences. Contact us to discuss your Fabric security needs.
Frequently Asked Questions
What compliance certifications does Fabric support?
Microsoft Fabric supports SOC 1/2, ISO 27001, HIPAA (with Business Associate Agreement), GDPR, and FedRAMP in applicable regions. Check Microsoft compliance documentation for current certifications.
How does row-level security work in Fabric?
RLS uses DAX expressions to filter data based on user identity. You define roles in semantic models with filter expressions, then assign users to roles in Power BI Service. Filters apply across all reports using that model.