Microsoft Fabric: (Part 3 of 5)
An insight 42 Technical Deep Dive Series
The Elephant in the Room: Security, Compliance, and Network Separation
In the first two parts of this series, we explored the ambitious vision of Microsoft Fabric and its potential to unify the modern data estate. However, as with any powerful new technology, the devil is in the details. For enterprise organizations, particularly those in highly regulated industries, the most critical details are security, compliance, and the ability to isolate and control network traffic. While Fabric offers a compelling vision of a simplified, all-in-one data platform, its SaaS (Software-as-a-Service) nature introduces a new set of challenges that must be carefully considered.
This post will take a critical look at the security and compliance landscape of Microsoft Fabric. We will dissect its multi-layered security model, examine the challenges of achieving true network separation in a multi-tenant SaaS environment, and discuss the practical realities of meeting stringent compliance requirements like GDPR in 2025 and beyond.
Fabric’s Multi-Layered Security Model
Microsoft has built a comprehensive, multi-layered security model for Fabric, leveraging the mature security capabilities of the Azure platform. This model can be broken down into several distinct layers, each providing a different level of protection.
Figure 1: The multi-layered security model of Microsoft Fabric, from network security to compliance.
A Layer-by-Layer Breakdown
The security model consists of five interconnected layers, each addressing a specific aspect of data protection:
| Layer | Key Features | Description |
|---|---|---|
| Network Security | Private Links, Managed Private Endpoints, Managed VNets, Firewall Rules | Provides options for securing network traffic to and from the Fabric service, but with significant limitations compared to traditional IaaS/PaaS. |
| Identity & Access | Microsoft Entra ID, Conditional Access, MFA, Service Principals | Leverages the robust identity and access management capabilities of Entra ID to control who can access the platform and what they can do. |
| Data Security | Encryption at Rest (MS-managed & CMK), TLS 1.2/1.3, Row-Level Security | Protects data both in transit and at rest, with options for customer-managed encryption keys for enhanced control. |
| Governance | Microsoft Purview, Sensitivity Labels, Data Loss Prevention (DLP), Audit Logging | Integrates with Microsoft Purview to provide a unified governance and compliance solution across the entire data estate. |
| Compliance | GDPR, SOX, PCI DSS, EU Data Boundary | Designed to meet a wide range of industry and regional compliance requirements, including the EU Data Boundary for data residency. |
While this layered approach provides a strong security posture on paper, the reality of implementing and managing it in a complex enterprise environment can be challenging, especially when it comes to network separation.
The Challenge of Network Separation in a SaaS World
One of the biggest challenges with Microsoft Fabric is the inherent trade-off between the simplicity of a SaaS offering and the control of a traditional IaaS (Infrastructure-as-a-Service) or PaaS (Platform-as-a-Service) solution. In a traditional cloud environment, organizations have full control over their virtual network (VNet), allowing them to implement strict network isolation, custom routing, and fine-grained firewall rules. In Fabric, however, the control plane, storage layer, and compute layer are all managed by Microsoft in a multi-tenant environment, creating what many in the community have called an “amalgamated” and challenging architecture [1].
Figure 2: The network separation challenges in Microsoft Fabric compared to a traditional IaaS/PaaS approach, showing available workarounds.
Key Network Separation Shortcomings
The SaaS model introduces several limitations that enterprise architects must understand:
| Limitation | Impact | Risk Level |
|---|---|---|
| No VNet Injection | Cannot inject Fabric into your own virtual network. Loss of control over inbound/outbound traffic with NSGs and firewalls. | High |
| Limited Network Isolation | Logical isolation between tenants exists, but underlying infrastructure is shared. Concern for strict data sovereignty requirements. | Medium-High |
| Shared Metadata Platform | Metadata platform storing permissions/authorization is shared. Logical isolation only, no physical isolation. | Medium |
| Merged Control/Data Planes | Control and data planes amalgamated in SaaS model. Difficult to implement traditional separated architecture security. | High |
Workarounds and Their Limitations
To address these shortcomings, Microsoft has introduced several features, but each comes with its own set of limitations:
| Workaround | What It Does | Limitation |
|---|---|---|
| Managed Private Endpoints | Securely connect to data sources from within Fabric | Only works for outbound traffic; no inbound protection |
| Private Links | Private, dedicated connection to the Fabric service | Configured at tenant level; complex to manage |
| Multi-Geo Capacities | Control data residency of compute and storage | Tenant metadata remains in home region |
| Multiple Tenants | Complete isolation through separate Entra ID tenants | Requires separate licenses; management overhead |
Navigating the Compliance Maze in 2025
For organizations operating in the EU, the compliance landscape is becoming increasingly complex. Regulations like the General Data Protection Regulation (GDPR) and the upcoming AI Act place strict requirements on how data is stored, processed, and governed. While Microsoft has made significant investments in ensuring that Fabric is compliant with these regulations, including making it an EU Data Boundary service [2], the architectural challenges we’ve discussed can make it difficult to prove compliance to auditors.
The Multi-Tenant Conundrum
The multi-tenant nature of Fabric, combined with the lack of full network control, can create a compliance nightmare. How do you prove to an auditor that your data is truly isolated when it resides on a shared infrastructure? How do you manage encryption keys and access policies in a way that meets the stringent requirements of GDPR?
One potential workaround is to use multiple tenants, creating a separate Entra ID tenant for each business unit or data domain that requires strict isolation. However, this approach introduces its own set of challenges:
| Challenge | Description |
|---|---|
| Licensing Complexity | Each tenant requires its own set of licenses, which can significantly increase costs. |
| Management Overhead | Managing multiple tenants, each with its own set of users, permissions, and configurations, can be a major administrative burden. |
| Data Sharing Challenges | Sharing data between tenants can be complex, requiring the use of guest accounts and other workarounds. |
| Identity Federation | Users may need multiple identities or complex B2B guest configurations. |
Compliance Checklist for 2025
For organizations planning to adopt Fabric in a regulated environment, consider the following:
| Requirement | Fabric Capability | Gap/Consideration |
|---|---|---|
| Data Residency | EU Data Boundary, Multi-Geo | Metadata may still reside outside preferred region |
| Encryption at Rest | Microsoft-managed keys, CMK option | CMK requires additional configuration and management |
| Access Audit | Microsoft Purview, Audit Logging | Ensure logs meet retention requirements |
| Data Classification | Sensitivity Labels, DLP | Requires Microsoft 365 E5 or equivalent |
| Network Isolation | Private Links, Managed Endpoints | Not equivalent to VNet injection |
The Road Ahead: A Balancing Act
Microsoft Fabric is a powerful and ambitious platform that has the potential to revolutionize the world of data and analytics. However, its SaaS nature introduces a new set of security and compliance challenges that cannot be ignored. For organizations that require the highest levels of security, control, and isolation, the current state of Fabric may not be sufficient.
Key Insight: The trade-off between SaaS simplicity and enterprise control is real. Organizations must carefully evaluate whether Fabric’s current security capabilities meet their specific compliance requirements, or whether workarounds like multi-tenant architectures are necessary.
In the next part of this series, we will delve deeper into the practical solutions and workarounds for these challenges. We will explore multi-tenant architecture patterns in more detail, provide a comprehensive guide to Fabric’s licensing model, and offer practical advice on how to navigate the complex trade-offs between simplicity and control.
References
[1] Fabric shortcomings : r/MicrosoftFabric
[2] What is the EU Data Boundary? – Microsoft Privacy
← Previous: Part 2: Data Lakes and DWH Architecture | Next: Part 4: Multi-Tenant Architecture and Licensing
#FabricSecurity #NetworkIsolation #SaaSSecurity #FabricCompliance #GDPR #MultiTenant #PrivateLinks #DataResidency #EUDataBoundary #FabricGovernance #CMKEncryption #EnterpriseSecurity #AzureFabric #CloudSecurity #DataProtection