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) must implement controls at every layer to satisfy compliance requirements for HIPAA, SOC 2, and FedRAMP.
The Five Security Layers
Understanding how security layers interact is essential for proper implementation:
| Layer | Controls | Managed By | Scope | |---|---|---|---| | Tenant | Feature availability, export restrictions, sharing policies | Fabric Administrator | Entire organization | | Capacity | Resource access, workload prioritization | Capacity Administrator | All workspaces on capacity | | Workspace | Content access (CRUD operations) | Workspace Admin | All items in workspace | | Item | Per-item sharing, build permissions | Item owner/admin | Individual report, dataset, or artifact | | Data | Row-level security, column-level security, sensitivity labels | Model developer + admin | Data rows and columns within a dataset |
Security is cumulative: a user must pass all applicable layers to access data. A user with workspace Viewer access to a dataset still sees only the rows permitted by their RLS role.
Tenant-Level Security
Tenant settings are the broadest security controls and have the highest impact:
Export Controls: Restrict which users can export data from Power BI to Excel, CSV, or PDF. Unrestricted export is the primary data leakage vector. For regulated environments, restrict export to specific security groups with data handling training.
External Sharing: Control whether content can be shared with users outside your Azure AD tenant. B2B sharing enables collaboration with partners and clients but must be tightly controlled. Disable "Publish to web" for all users—it creates unauthenticated public URLs.
Copilot and AI Controls: Determine whether Copilot can access data for AI-powered features. In regulated environments, review what data is sent to Azure OpenAI services and ensure compliance with data residency requirements.
Service Principal Access: Control whether applications (not users) can access Fabric APIs. Enable only for designated service principal security groups used in CI/CD pipelines and embedding applications.
Workspace-Level Security
Workspace roles define what users can do with content:
Admin: Full control over the workspace—manage membership, delete any content, configure settings, and manage connections. Assign to the workspace owner and one backup administrator. Never assign broadly.
Member: Create, edit, and delete all content types. Publish reports, manage datasets, and share items. Assign to active report developers and data engineers. Members can delete content created by others—assign cautiously.
Contributor: Create and edit content they own. Cannot delete others' content or manage workspace membership. The safest role for regular developers who need to create reports against shared datasets.
Viewer: Read-only access to all published content. Cannot edit, create, or delete anything. The default role for report consumers—the majority of your user population.
Security Group Best Practice: Map workspace roles to Azure AD security groups rather than individual users. When an employee changes roles, updating group membership automatically adjusts all workspace permissions.
Row-Level Security (RLS)
RLS filters data rows based on the identity of the user viewing the report:
Static RLS: Define fixed filter expressions per role. Example: create a "West Region" role with filter [Region] = "West". Assign users manually to roles. Simple but does not scale—each new region or team requires a new role and manual user assignment.
Dynamic RLS: Use USERPRINCIPALNAME() or USERNAME() in DAX filter expressions to automatically filter data based on the logged-in user. Example: [SalesRepEmail] = USERPRINCIPALNAME(). The security table maps users to their data scope. Adding a new sales rep requires only a row in the security table, not a new role definition.
Manager Hierarchy RLS: Implement hierarchical security where managers see data for their entire reporting chain. Build a recursive parent-child relationship in the security table. A regional manager sees all data for their region; a VP sees data for all regions in their division.
Multi-Tenant RLS: For embedded analytics (ISV scenarios), use effective identity in embed tokens to isolate customer data. Each customer sees only their data from a shared dataset. Critical for SaaS applications where data isolation must be absolute.
Object-Level Security (OLS)
OLS hides entire tables or columns from specific roles:
Column-Level OLS: Hide sensitive columns (salary, SSN, patient ID) from roles that should not see them. The columns are invisible in report visuals, field lists, and DAX queries for restricted users.
Table-Level OLS: Hide entire tables from roles that do not need them. A general reporting role might see sales tables but not HR tables within the same model.
Implementation: OLS is defined in the semantic model using Tabular Editor or TMSL scripts. It cannot be configured through Power BI Desktop GUI. OLS roles are separate from RLS roles and can be combined for layered security.
Sensitivity Labels and Data Classification
Microsoft Purview sensitivity labels extend to Fabric items:
Classification: Apply sensitivity labels (Public, Internal, Confidential, Highly Confidential) to datasets, reports, and workspaces. Labels are visible to users, helping them understand the data sensitivity of what they are viewing.
Protection: Labels can enforce encryption, watermarking, and DLP policies. A "Highly Confidential" label can prevent export, restrict sharing, and add visual watermarks to reports containing sensitive data.
Inheritance: When a dataset has a sensitivity label, reports built on that dataset automatically inherit the same or higher classification. This prevents downstream content from being less protected than its source data.
Compliance Framework
| Standard | Fabric Support | Key Requirements | |---|---|---| | SOC 2 Type II | Certified | Audit logging, access controls, encryption | | HIPAA | Supported (with BAA) | PHI protection, audit trails, minimum necessary | | ISO 27001 | Certified | Information security management system | | GDPR | Compliant | Data residency, right to deletion, consent management | | FedRAMP | Select regions | Government-approved cloud controls |
Audit Logging: Fabric logs all user activities—report views, data exports, sharing events, admin changes—to the Microsoft 365 unified audit log. Retain logs for compliance periods (typically 7 years for healthcare, 5 years for financial services).
Related Resources
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.