When examining security in Microsoft Fabric, you may be inclined to think only about the Workspace security and maybe Row Level Security (RLS) inside of a semantic model. The security model encompasses a lot more than just those two things.

Let’s take a look at the security model for Fabric

We can see here that the highest level is at the workspace level but it goes much deeper than that. Workspace security is identical to what was offered in Power BI, where you have the four levels of Admin, Member, Contributor and Viewer.

Limiting access to content in a Workspace

There are times that you do not want to give users access to everything inside of a workspace. If you want to limit the access to a single semantic model, warehouse, data factory pipeline, lakehouse, machine learning experiment, or model you can do that. Inside of those individual components there are even more levels which you can set inside of lakehouses, warehouses and semantic models. Data warehouses and lakehouses use similar methods to traditional databases to secure the data. You will want to create or implement roles to allow users access to the data. You will then need to run T-SQL commands to grant access on various objects to those roles. GRANT, REVOKE and DENY will work the same way that they do in a traditional SQL Server databases. Row level security (RLS) is created using a security policy you create with the command CREATE SECURITY POLICY. Remember only users with item read permissions on the lakehouse will be using RLS there. Now there may be some people that should not see portions of the database. We can even go a step further and deny the ability to select an entire tables.

Lakehouse Sharing

If you want to provide access to a lakehouse inside of Fabric, you can choose to share it. People may be able to access the shared content and nothing else inside of the workspace. When the option to share is selected there are options to consider which limit the access to the content as there are 3 options available. If you grant access to Read all Apache Spark, that is the only place to read the data and you cannot write files to OneLake either. By granting access to SQL Endpoint you can only look at SQL endpoints. It is not possible to create a semantic model with that permission. If you grant Build reports on the default dataset, then you can create a semantic model and nothing else. You can chose to check any number of these options to provide the granularity of data access required.

Preview OneLake Data Access Roles

In addition to the existing security methods, there is an even more granular method of security that Fabric added as a preview feature, and that is the OneLake data access roles. This brings in Row-Based access control (RBAC) to the data stored in OneLake, limiting data access to the folder level. By implementing OneLake access roles, you can restrict for example the ability to view files in OneLake, which would mean in a Lakehouse, the only thing that you can see are the tables that are created from those files. These permissions are not necessarily related in any way to the other data roles.

Summary

Microsoft Fabric provides a number of different ways to limit access to the data stored within workspaces and OneLake which you need to explore to restrict access to the data. Most likely your organization will want to delve into some of the more complex methods to provide least access to important information.

Contributor

Ginger Grant, Microsoft Data Platform MVP