Forum Discussion
Helper IEnhancing Microsoft Fabric: Security at the network level
As we are all aware, the Microsoft Fabric, as a SaaS platform, is accessible by default over the public internet through Microsoft-managed endpoints. While this architecture provides flexibility and scalability, it also expands our exposure surface.
We can restrict access and authorization at the tenant and workspace levels, as well as other options at the portal admin level.
However, a key risk remains: if an attacker compromises a user’s credentials/Service Principals/Managed identities and no additional safeguards exist, they can access Fabric artifacts remotely from anywhere in the world(Say, Datawarehouse, Lakehouse, Portal itself, etc.).
Unlike traditional on-premises systems that require internal network or VPN access, Fabric operates on the open internet — making authentication the sole line of defense.
Security Implication: If authentication fails, our data becomes directly exposed to external threats.
A few of the following practical solutions are available:
To mitigate this risk, we should establish multi-layered network-level defenses within Microsoft Fabric. We need to have a comprehensive security framework(for all components in the Fabric) that includes:
Multi-Factor Authentication (MFA): Adds a secondary verification layer beyond passwords.
Conditional Access Policies: Enforce Zero Trust principles, restricting logins from untrusted IPs or abnormal locations.
Device Compliance Requirements: Ensures only secure, managed devices can access Fabric.
Network Restriction: Limits access to approved public ranges or private networks of the organization.
Additionally, we can have component-specific protections — for example, enabling Azure Private Link for the Warehouse to ensure data access is contained within our private network environment.
Can anyone provide a specific, comprehensive list of recommendations for all components, such as Lakehouse, Event Hour, Semantic Model, Notebooks, etc.?
Hi ChiruGalla,
That makes sense. Going forward, IT solutions like SaaS platforms such as Microsoft Fabric should use a Zero Trust security model instead of traditional perimeter-based controls. Since Fabric uses Microsoft-managed public endpoints, legacy on-premises network isolation cannot be replicated. Identity is now the main security boundary, strengthened by authentication and authorization methods like phishing-resistant MFA, Conditional Access, device compliance, Privileged Identity Management, and governance of Service Principals and Managed Identities. Network controls like Private Link offer extra protection in certain cases, but they are selective and may cause architectural trade-offs. The best tenant-level strategy is a layered defense-in-depth approach, combining Zero Trust, least-privilege RBAC, data protection controls like sensitivity labels and RLS/OLS, and continuous monitoring with audit logs and security tools. This approach ensures that even if credentials are compromised, access stays restricted, monitored, and governed.
Thank you.
11 Replies
KevinChantSuper User
Here's the link to the Microsoft fabric Security White paper which should answer all your questions:
Microsoft Fabric security white paper - Microsoft Fabric | Microsoft Learn
v-sgandrathiCommunity Support
Hi ChiruGalla,
Boosting security in Microsoft Fabric means thinking in layers, since it’s a SaaS platform open to the internet via Microsoft’s endpoints. While permissions at the tenant, workspace, and item level help manage access, they mostly depend on identity authentication. If someone’s credentials or service principals get compromised, attackers could reach all sorts of Fabric resources, like Lakehouses, Warehouses, Eventhouses, Semantic Models, Notebooks, and Pipelines, from anywhere. That’s why it’s key to back up identity protection with extra network and device controls to cut down exposure.
On the identity side, it’s smart to require Multi-Factor Authentication (MFA) for everyone, turn off outdated authentication, and use phishing-resistant options if possible. Conditional Access policies should stick to Zero Trust, only allow logins from trusted IPs, compliant devices, or safe locations, and block anonymous or risky sign-ins. Admin roles (like Fabric Admin or Capacity Admin) should use Privileged Identity Management (PIM) with just-in-time access. Service principals need certificate-based authentication, regular secret rotation, and minimal permissions.
For tenant and network security, set Fabric tenant options to limit external sharing, disable Publish to Web unless needed, keep XMLA endpoints limited, and restrict use to certain security groups. Use Conditional Access to lock sign-ins to your corporate network or managed devices, adding an extra network layer even though Fabric is online. Keep an eye out for risky sign-ins or weird travel events, and monitor for token misuse.
When it comes to specific components, stick to Azure AD authentication for Warehouses, turn on auditing, use Row-Level Security (RLS), and use Private Link where you can. For Lakehouses and OneLake, manage access through roles, permissions, sensitivity labels, and audits. Eventhouses should use RBAC, set retention rules, limit ingestion endpoints, and log queries. Semantic Models should apply RLS and Object-Level Security (OLS), restrict downloads and XMLA write access, and use sensitivity labels. Notebooks and Spark jobs should rely on managed identities, secure secrets, limit contributor rights, and log executions. Pipelines should use managed identities, limit editing, rotate credentials, and watch for odd activity.
Overall, make sure to use sensitivity labels, DLP policies, unified audit logs, and connect to Sentinel or Defender for advanced threat detection. Set up alerts for things like big data exports, odd locations, privilege changes, or unusual admin actions. At the end of the day, the goal is to layer up security, combining strong identity checks, Conditional Access, device compliance, private connectivity, granular permissions, data protection, and centralized monitoring, so even if credentials get compromised, attackers hit a wall instead of getting free access.
Thank you.
- Olufemi7
Hello ChiruGalla,
Microsoft Fabric is SaaS, so security must follow a Zero Trust model. While the control plane is internet-facing, you can implement layered protections across identity, network (where supported), and governance.
1. Identity (Foundational – Mandatory)
• Enforce MFA (phishing-resistant preferred)
• Apply Conditional Access (device compliance, trusted IP ranges, risk-based policies)
• Disable legacy authentication
• Use PIM for Fabric, Capacity, and Workspace Admin roles
• Restrict service principals and managed identities2. Workspace Governance
• Apply least-privilege RBAC
• Separate Dev/Test/Prod workspaces
• Disable external sharing if not required
• Block “Publish to web”3. Component-Level Controls
Warehouse (SQL endpoint)
• Use Private Link (where supported)
• Apply IP firewall rules
• Monitor SQL activityLakehouse / OneLake
• Apply sensitivity labels and DLP
• Restrict external sharing
• Monitor access via audit logsEventhouse (Real-Time Analytics)
• Restrict ingestion endpoints
• Apply database-level RBAC
• Monitor KQL commandsSemantic Models
• Implement RLS / OLS
• Restrict XMLA endpoint access
• Disable export of sensitive dataNotebooks / Pipelines
• Use Managed Identity instead of stored credentials
• Restrict artifact creation/edit permissions
• Monitor execution logs4. Monitoring & Detection
• Enable Fabric Activity Logs
• Monitor Entra ID sign-in logs
• Integrate with Microsoft Sentinel (if available)Fabric security should be layered: Identity + Conditional Access + RBAC + Private Link (where supported) + Continuous monitoring.
ChiruGallaHello Olufemi7 ,
Thank you for your response.
As I mentioned in my original thread, there is no rule of thumb to improve/follow strict guidelines to achieve network-level security, unlike any on-premise network/Data Centers
If we want to implement rigid policies, we may have to compromise on a few other things. Say, if we are seriously considering implementing the Private links for the Data Warehouse, it would affect several other things as mentioned in the following link.https://learn.microsoft.com/en-us/fabric/security/security-private-links-overview
The ideal way to keep the Fabric environment safe at the tenant level is to leverage on implemeting sound authentication, authorization policies, and the implementation of Conditional Access, and the optimal usage of SP's and MIs.
Please feel free to add/edit if necessary.
Thanks
-Chiru
- Olufemi7
Hello ChiruGalla,
Microsoft Fabric has no universal network-level security model; network controls like Private Link are optional and selective, so the most effective tenant-level protection is layered Zero Trust with MFA, Conditional Access, least-privilege RBAC, careful SP/MI management, and continuous monitoring (Microsoft Docs).
- v-sgandrathi
Hi ChiruGalla,
Thank you Olufemi7 for your response.
Since we haven't heard back from you yet, I'd like to confirm if you've successfully resolved this issue or if you need further help?
If you still have any questions or need more support, please feel free to let us know.We are more than happy to continue to help you.
- v-sgandrathi
Hi ChiruGalla,
Agreed, Microsoft Fabric doesn’t fully match traditional network-centric security models used in on-premises setups, since it’s a SaaS platform accessed via Microsoft-managed public endpoints. As a result, network controls like Private Link are selective, scenario-specific, and can come with architectural trade-offs.
Your point about Zero Trust as the practical baseline is spot on. In Fabric, tenant-level protection works best when identity is the main security boundary, supported by strong Conditional Access, phishing-resistant MFA, device compliance, and strict governance over Service Principals and Managed Identities. These measures offer consistent protection across Fabric, even where network isolation is limited.
Instead of trying to copy legacy network isolation, it’s better to use network controls as an extra layer where possible (such as SQL endpoints with Private Link), but focus on identity-first security, least-privilege RBAC, monitoring, and data protection as the main defense.
This layered approach helps reduce risk through contextual access controls and continuous monitoring, rather than depending only on perimeter security.
Thank you.
- ChiruGalla
Yes, that makes complete sense.
Moving forward, all IT solutions will have to implement "ZERO TRUST" mechanisms/policies to secure their data, along with the default security measures/best practices provided by the product groups/vendors.
- v-sgandrathi
Hi ChiruGalla,
That makes sense. Going forward, IT solutions like SaaS platforms such as Microsoft Fabric should use a Zero Trust security model instead of traditional perimeter-based controls. Since Fabric uses Microsoft-managed public endpoints, legacy on-premises network isolation cannot be replicated. Identity is now the main security boundary, strengthened by authentication and authorization methods like phishing-resistant MFA, Conditional Access, device compliance, Privileged Identity Management, and governance of Service Principals and Managed Identities. Network controls like Private Link offer extra protection in certain cases, but they are selective and may cause architectural trade-offs. The best tenant-level strategy is a layered defense-in-depth approach, combining Zero Trust, least-privilege RBAC, data protection controls like sensitivity labels and RLS/OLS, and continuous monitoring with audit logs and security tools. This approach ensures that even if credentials are compromised, access stays restricted, monitored, and governed.
Thank you.
- v-sgandrathi
Hi ChiruGalla,
I wanted to follow up on our previous suggestions regarding the issue. We would love to hear back from you to ensure we can assist you further.
Thank you.
