Microsoft Fabric Security — Who Gets to See What, and Who Decides
- Harri Jaakkonen
- Feb 25
- 9 min read
Series · Part 2 of 2
Access controls, permission models, data protection through sensitivity labels, governance tooling, and compliance.
You have done Part 1. Conditional Access is configured. Private Links are under discussion. The network team is happy, or at least no longer actively unhappy. You have a presentation slide that says "Authentication via Entra ID — always on" and a compliance officer who has stopped asking uncomfortable questions.
And then a data analyst sends a message at 10am.
"Hey, I can see the HR salary bands in the sales Warehouse. I don't think I'm supposed to. Also, I exported it to Excel. Should I delete the file?"
The perimeter was fine. The castle wall held. The problem walked in through the front door with a valid badge — because someone gave that badge too much access, and nobody had defined what "access" actually meant inside the platform.
This is where most incidents in Fabric begin. Not at the network layer. Inside it.
One Workspace, One Security Boundary — Treat It That Way
Fabric's workspace is the primary security container. Everything inside a workspace — Lakehouses, Warehouses, Notebooks, Reports, Semantic Models — is visible to everyone who has workspace access. You do not accidentally browse across workspaces into another team's data. But within a workspace, the boundary is wide.
Fabric manages that boundary through workspace roles. Four levels, each a different degree of trust.
Role | What They Can Do |
Viewer | Read and query. Cannot run Notebooks, create items, or touch underlying files. |
Contributor | Create and modify items. A working data engineer. |
Member | Manage access for others, up to their own level. |
Admin | Full control. Including removing other Admins. |
This is clean in theory. In practice, the story goes like this: the first workspace gets set up carefully. The second one is a copy with the same roles. By the fifth workspace, someone asks whoever is in the meeting to just "add the whole data team as Members because we're all going to need access eventually." And by workspace fifteen, you have quietly lost the security model you started with.
The failure mode is always gradual and always feels reasonable in the moment. Start strict. Change roles when there is a specific, named reason — not a general "it's easier."
When the Workspace Is Too Broad: Item-Level Permissions
Not everyone who needs access to a report needs access to the entire workspace it lives in. Not every service account that reads from a Lakehouse endpoint needs to see the Notebooks, the staging tables, the half-finished analyses that are also sitting in the same workspace.
Item-level permissions give you surgical access control. You can share a specific Lakehouse, a specific Warehouse endpoint, a specific Semantic Model — with a user or a service principal — without granting any workspace role at all. That user sees exactly that item, and nothing else in the workspace exists as far as they are concerned.
This is the right tool for cross-team collaboration, for external stakeholders who need a dashboard but not your data engineering internals, and for service accounts where least-privilege is not a preference but a requirement. The mechanics are in the Share Fabric items guide.
One thing to watch: workspace roles and item permissions stack. If someone has both, the effective permission is the union. That is usually fine, but it is worth understanding before you debug a permissions issue and discover that a user has access through two different paths, one of which you had forgotten about.
The Analyst Who Could See Too Much
Back to our analyst. They had Viewer access to the sales Workspace. Viewer is supposed to be the safe, read-only role. And it is — to a point.
The problem was that the Warehouse in that workspace contained salary data that lived in the same schema as the sales data. Nobody had told the Warehouse about the security requirement. It was just there, in a table, visible to anyone who could run a SQL query.
This is exactly what row-level security (RLS), column-level security (CLS), and object-level security (OLS) exist to prevent — and exactly the layer that most teams forget to configure because workspace roles feel sufficient until they are not.
Row-Level Security (RLS)
Filters which rows come back. Same table, same query — different results per identity. For DirectLake datasets, triggers a DirectQuery fallback when RLS is defined in SQL.
Column-Level Security (CLS)
The column exists in the schema. The analyst cannot query it — returns a permission error, not null. The column is real. It is just not theirs.
Object-Level Security (OLS)
The table does not appear to exist at all if you lack OLS access. Not hidden with an error. Invisible.
In the salary scenario: CLS on the salary column, or OLS on the HR table entirely, would have caught it. Workspace roles and item permissions alone could not.
The Export Problem: Labels That Follow the Data
The analyst deleted the Excel file. Problem solved, more or less. But the more interesting question is why an exported Excel file containing payroll-adjacent data was even possible to create and handle outside of Fabric.
Microsoft Purview Information Protection sensitivity labels are the answer to this. And they work in a way that is worth understanding, because it is different from most tagging systems.
Sensitivity labels in Microsoft 365 — General, Confidential, Highly Confidential, and so on — are already applied to documents, emails, and Teams messages in most enterprise environments. In Fabric, you apply those same labels to Fabric items. And then something useful happens: the label follows the data.
A Lakehouse labeled Confidential passes that label to any report built on it. That report, when exported to Excel, carries the label into the file. If the label has an encryption policy attached, the Excel file is encrypted outside of Fabric. The user cannot remove the label by saving as a different format or copying the data into a new sheet.
If the salary Warehouse had been labeled Highly Confidential with an encryption policy, the exported Excel file would have been unreadable to anyone without the right permissions — regardless of where the file ended up.
Sensitivity label activity across the Fabric estate is visible and auditable through Microsoft Purview.
Purview: Knowing What You Have and Where It Went
At scale, you lose track of your data. Not through negligence — through complexity. A Lakehouse is created for a project. It gets used as a source for three Dataflows. Those Dataflows feed two Warehouses. The Warehouses back six reports. Those reports get exported, shared, and embedded in Power BI apps.
Three months later, someone asks: where does the customer PII actually live in the platform? How does it move? Who has touched it?
Without tooling, that question takes days to answer. With Microsoft Purview, it is a lineage query. The Purview hub inside Fabric surfaces the data map, the classification status, and the movement history directly in the Fabric UI.
Data lineage — a visual trace of where data originated, how it was transformed, and where it ended up. See lineage in Fabric. The thing auditors ask for when something goes wrong.
Sensitivity label insights — an aggregated view of how labels are distributed across your Fabric estate, so you can see at a glance what is classified, what is not, and what is classified incorrectly.
Data loss prevention (DLP) policies — rules that catch and block sensitive data from leaving Fabric through unauthorized channels. See DLP for Power BI and Fabric. A policy here could have flagged the export before the file hit the analyst's desktop.
Purview is not a replacement for access controls. It is the layer that tells you whether your access controls are working.
When Regulations Write the Architecture: Multi-Geo
Some problems are not about access. They are about geography.
A European financial services company stores customer data in a Fabric workspace. Their legal team tells them the data cannot leave the EU. Their infrastructure team has provisioned Fabric with the default tenant configuration, which lands metadata in the US.
This is a fixable problem. Fabric supports Multi-Geo capacities — you create a Fabric capacity in West Europe, assign the workspace to that capacity, and the data lives there. The EU data does not cross borders. The US-based capacity serves other workspaces. A single Fabric tenant, multiple geographies, each with data sovereignty enforced at the capacity level.
The tradeoff is management overhead. Each geography needs its own capacity. Cross-geo data movement — if your architecture requires it — does not happen automatically and is entirely your responsibility to understand and control. The platform supports the partitioning; it does not enforce the business rules on your behalf.
For global organizations, this is how you make compliance work without fragmenting your analytics platform into separate tenants per country.
Audit Logs: The Record You Need Before You Need It
At some point, you will be asked to prove what happened. Not because of a crisis — because of a routine compliance audit, or because a user submitted an access complaint, or because an automated DLP alert fired and someone wants to trace the chain of events.
Fabric produces audit logs for everything that matters: item access, permission changes, exports, capacity events, shared items. These logs flow through the Microsoft 365 audit log infrastructure. To pull them, follow Track user activities in Microsoft Fabric. The full list of tracked operations is in the Fabric operation list.
If you have a SIEM — Microsoft Sentinel, Splunk, whatever your organization runs — the audit logs are the feed to ingest. The coverage is broad enough that most investigation scenarios are answerable from audit data alone.
Audit logs tell you what happened, not what was allowed to happen. Audit is evidence, not prevention.
Who Administers This? Everyone and No One Is Not an Answer
Fabric's admin model is designed for organizations where the central IT team cannot — and realistically should not — own every governance decision for every business unit.
The model, described in the admin overview, is layered delegation. Tenant admins set global policy. Capacity admins manage compute allocation. Workspace admins manage their workspace. Domain admins govern groups of related workspaces. Each level can act independently within the bounds that the level above has established.
The failure mode is when delegation becomes a workaround. When someone cannot get access through the right channel, so they are made a workspace admin instead. When "admin" gets handed out because it is the fastest way to unblock someone. When nobody reviews what was delegated six months ago, and those delegations are still active long after the original rationale expired.
Delegate deliberately. Review periodically. The cadence matters more than the initial configuration.
The Platform Is Compliant. Are You?
Fabric is built on Microsoft's Security Development Lifecycle and participates in a broad set of compliance certifications. The Microsoft Trust Center is the authoritative reference. For regulated industries — healthcare, financial services, public sector — this is where you go when legal asks "is this platform GDPR-compliant" or "can we hold HIPAA data here."
The honest answer is nuanced. The platform meets those standards. Your use of the platform has to meet them too. GDPR compliance is not just about where data is stored — it is about who can access it, how long it is retained, whether individuals can request deletion, and whether you can demonstrate control. Fabric gives you the tools to do all of that. Using the tools is your work, not Microsoft's.
The Analyst Sent One More Message
A week after the salary incident, the analyst sent another message.
"I tried to access the HR workspace to check a number for a report. I got an access denied. Should I have access?"
The answer was no. And the answer came back in five minutes, from someone who knew what the workspace was for, why it was configured the way it was, and who the right person to ask was.
That is what a well-governed Fabric environment looks like. Not a system where every access request goes smoothly, but a system where the boundaries are deliberate, the answers are findable, and the exceptions are decisions — not accidents.
The encryption was always on. The authentication was always Entra. But the security was built by the team.
Getting Fabric Security Right Is Harder Than It Looks
Workspace design, access control layering, Purview integration, Multi-Geo compliance architecture — each of these is straightforward in isolation. The difficulty is getting them to work together consistently, across a growing number of workspaces, teams, and geographies, without accumulating the kind of configuration debt that quietly erodes your security posture over time.
Fortytwo works with organizations to design and implement Microsoft Fabric security from the ground up — permission models, sensitivity label strategies, Purview governance, and audit pipeline setup — so that the boundaries are deliberate before the data arrives, not patched in after an incident.
New to the series? Part 1 covers authentication, network security, and encryption — the platform foundation.
Official references
Comments