Where Fabric Sits in the Hierarchy

As you are probably aware, Microsoft Fabric is Microsoft’s latest addition to its suite of cloud applications. A lot of the infrastructure of Fabric has its origins in Power BI – including some of the security features. There are even some pieces of Fabric documentation which explicitly instruct readers to study Power BI documentation for a deeper insight. However, unlike Power BI, Fabric is designed as an integrated data environment, whose capabilities are based on existing Azure solutions. In Fabric, users can store data in a flexible lakehouse format, create or import data, set up data pipelines, create notebooks to transform data, perform analytics, deploy machine learning models and create Power BI reports, among many other features.

An Azure account is required to use Fabric. Fabric is licensed through Azure and its computing provisions, called capacities, reside in Azure tenants. Tenants are instances of Microsoft Entra ID (MEID), formerly known as Azure Active Directory, and each tenant corresponds to an organisation, such as a company. Any Azure account must be assigned to a tenant and is accordingly bound by the tenant’s MEID rules. Furthermore, users can only access Microsoft Fabric after the tenant admin has enabled Fabric in the Admin Portal.

Each time anyone wants to create a non-Trial Fabric environment, they must also deploy an Azure resource called a Fabric Capacity. This represents the computing power available to the Fabric environment, and must exist within an Azure Resource Group.

These deployment rules mean that access to Fabric resources can be governed using existing Microsoft security tools, such as role-based access control (RBAC), service endpoints, security groups and service principals.

Security within Fabric

In Fabric, the basic logical structure for data services is the Workspace, in which users can create Items, which are the various resources that perform all the data operations available in Fabric, such as Lakehouses, pipelines, machine learning models and so on. Each workspace is a self-contained data storage and development environment, whose user access is controlled by both workspace admins and member users. User access controls include options to manage users’ workspace roles, which determine the permissions assigned to each user. Security permissions can be managed on the workspace and item levels in the Fabric UI. MEID authentication can also be employed within Fabric, as connecting Fabric items to other Azure resources requires MEID. MEID’s Conditional Access feature can also be configured for use in Fabric (see this documentation for best practice for Fabric resources linking to other Azure services).

Item-level Data Security

Below is an overview of a simple Fabric workspace I created in a trial Fabric capacity:

Creating the SecPocLH lakehouse item automatically creates a SQL analytics endpoint item with the same name. This endpoint allows users to treat their lakehouse data in a SQL-like manner, via T-SQL queries. From a security perspective, the ability to perform T-SQL queries creates the opportunity to employ multiple data-protection tools, including:

• Granular permissions – this allows you to grant or revoke access to individual tables within SQL Endpoint/Warehouse.
• Dynamic data masking – this allows users to create rules that change data values depending on the user in question. Priveledged users can see the true data, while others will only see edited values. This is intended to restrict access to sensitive data. Dynamic masking is enabled during column definition, as shown in the example query below. Here, I have enabled masking for the Name column using a custom string, which would mask the strings ‘Microsoft’ and ‘Fabric’ as ‘M-ft’ and ‘F-ic’, respectively.

• Row-level security (RLS) – in Fabric, RLS behaves the same way as it does in other Microsoft services. Security policies are created and defined via SQL queries in Warehouse/SQL Endpoint using user defined criteria to control access to Fabric data tables. Currently, Fabric does not support block predicates for RLS, only filter predicates.
• Column-level security (CLS) – like RLS, CLS is restricted to SQL queries in Warehouse/SQL Endpoint, and can be tailored to different tables within . CLS is much simpler than RLS – it consists of a GRANT statement, specifying the Fabric table name, the columns the target user may access and their username/email, like this one taken from the MS documentation:

• • GRANT SELECT ON Customers(CustomerID, FirstName, LastName, Phone, Email) TO [Charlie@contoso.com];
  • If this user runs a query attempting to access columns omitted from this GRANT statement, the query will fail.

Within the Fabric workspace overview, any item with data storage, such as the Lakehouse or Warehouse in my example, can be shared with other users, who are granted read access only. These users must be in the same MEID tenant – if necessary they can be added as guest users in the tenant.

As shown below, the most basic access option allows access only to the Lakehouse/Warehouse’s default dataset (seen as Semantic model type item in the overview above), which is auto-generated and does not allow for access to the underlying stored data itself – this can only be accessed via the “Read all” options, which allow for direct reading by SQL queries and Spark notebooks, respectively. The “build reports” option does not allow access to the data itself.

Shortcuts

Shortcuts allow you to view and use data from other resources in a Fabric lakehouse without actually copying the data into the lakehouse itself. The ability to create shortcuts and use shortcut data is enabled for most roles within the Fabric RBAC setup and is available for both the Files and Tables folders in the LH Explorer tab. Shortcuts require a connection to the original source, so authentication is necessary to make this happen. The available authentication options depend on the resource being connected to:

• Another OneLake resource – user ID is used to authorise access to the source data (i.e. the existing Fabric authentication setup is used).
• ADLS Gen2 – use MEID authentication options, which are shown below.
• Amazon S3 – credential only (username & password) – this user must have the “S3:GetObject”, “S3:GetBucketLocation” and “S3:ListBucket” permissions on the S3 data bucket being targeted for the shortcut, under S3’s Identity and Access Management (IAM) system.

Once the shortcut has been created, it will appear in the storage item (in my case, the SecPocLH lakehouse).

Data governance

Fabric has an integrated Microsoft Purview hub. This can be used to monitor and govern data, set up policies in data loss prevention, sensitive data, and more. The Purview hub can be accessed via the link in the Settings menu in the top-right corner of the Fabric interface under the Governance and insights heading.

Fabric supports information protection based on the system currently used in Power BI. This takes the form of a sensitivity label system. These labels are shorthand for painting data as targets for extra security features, such as encryption. Sensitivity labels can be applied by the user at the item level, and are automatically applied to items (of all kinds) downstream of the current item. These sensitivity labels are also tracked by Purview Hub, as we can see from the auto-generated sensitivity report from my trial workspace above (where no labels have been applied).

This same screenshot also shows that multiple aspects of the Fabric workspace can be monitored via the tabs on the left side of the interface. These integrated reports allow relevant security issues to be identified more quickly with Purview hub than without.

While the Purview hub is available for most Fabric roles, for access to the full spectrum of Purview hub capabilities, a user must be a Fabric admin. To be assigned an Admin role in Fabric, a user must either be a global admin or Power Platform admin within their Microsoft tenant or be assigned specifically as a Fabric admin by another admin account. As can be seen from the main Purview hub view below (taken from the Fabric documentation), all advanced Purview functionalities are linked to Fabric but are still managed through the Purview service proper.

 

Fabric admins also have exclusive access to the Admin Portal and default access to the admin workspace. The Admin Portal allows users to monitor resource usage and grant or withhold access on capacities, connectivity, reports and much more. The admin workspace is a read-only Fabric workspace that allows users to monitor Fabric via auto-generated reports on the usage aspects of Fabric not available through Purview hub reports, broken down by date, user ID and more. Tenant admins can share this workspace with other tenant users, in the same way as for other workspaces.

Drawbacks in Fabric (at time of writing)

Presently, Fabric only has locally-redundant storage (LRS) and, in Azure regions where it is available, zone-redundant storage (ZRS) for OneLake data. Region selection is determined by Workspace location (selected by the user). There is no currently geo-redundant storage (GRS) feature, but Microsoft has detailed a workaround for this: they recommend creating more workspaces in other regions and then using Fabric’s data factory service to periodically copy data from the primary workspace into these secondary ones. This, in effect, sets up GRS manually.

There is no private endpoint support for Fabric – if private endpoints are nevertheless required, users can solve via linking existing non-Fabric resources, such as Synapse, to Fabric. This arrangement will require authentication to allow Fabric to access the data – this can be made easier by placing these in the same Azure Resource Group, for example.

Conclusions

To maintain a secure Fabric environment, a lot of planning will be required. Security concerns will need to be weighed up alongside factors such as performance, cost, optimising data storage and ease of use. There will also be legal and sector-specific requirements to be accounted for when designing a Fabric solution.

The bulk of security decisions will likely be made at the item level, as the goal is for Fabric to be an end-to-end data solution, which will include large numbers of users with different roles who will therefore use different items to accomplish their tasks. For data storage items, effective security will additionally require using the granular access tools to manage such a wide range of users.

There are cases where security can be limited to high-level options like configuring MEID or workspace-level roles and permissions, such as an end-to-end workspace storing all the data used exclusively by a single team for migrating data.

If, on the other hand, there are lots of users from different backgrounds in a workspace or item, such as employees in different departments or even companies, the security environment would be more complex and require more intense oversight, particularly with granular tools like the T-SQL queries and sensitivity labels.

In addition, the granular security features for data stores allow for a greater range of users to access a specific storage item. If implemented properly, this gives a strong security environment while maintaining a simple and user-friendly data storage environment, greatly enhancing an organisation’s efficiency and agility with data.