Securing all of your OneLake data

#fabcon2026 #session #learning #microsoft #fabcon2026-session

Description

Fabric includes multiple layers of security across OneLake. This session breaks down RBAC, sharing permissions, shortcut behaviors, Semantic model Row Level Security and OneLake security and shows how they interact in real-world architectures. Learn how to design secure, least-privilege data access in Fabric throughout your data estate and more importantly the steps you need to employ to test it.

Key Takeaways

Security is intentional design: must be multilayered, applicable to downstream access, and built on least-privilege principles — not bolted on after the fact
Four Fabric security layers: Entra Security Groups → Workspace Security → SQL Security → OneLake Security — use them in combination, not in isolation
Entra Security Groups should be the foundation of everything — never grant access to individual users; always go through groups for manageability
Workspace security anti-pattern: most users should NOT be added to workspaces — use sharing and OneLake catalog instead to grant object-level access without workspace membership
OneLake Security (RBAC): define roles with Row-Level Security and Object-Level Security directly on OneLake data — enforced across ALL query engines (SQL, Spark, Power BI)
SQL Security works the same as SQL Server — CREATE ROLE, GRANT/DENY permissions — but note: no IMPERSONATE in Fabric, which complicates testing
Best Practice: manage all sharing through the OneLake Catalog, grant rights on objects (not workspaces), and use OneLake Security for fine-grained control
Ginger Grant: Principal Consultant at Desert Isle Group, international speaker, author — @desertislesql

My Notes

Action Items

Resources & Links

Slides

Secure all of your OneLake Data
Principal Consultant, Desert Isle Group
International Speaker
Independent Data Consultant
Trainer, certification, custom, online
Author,
Ginger Grant
Power BI since Excel and Fabric before release
@desertislesql
www.linkedin.com/in/ginger-grant/
sessionize.com/ginger-grant/
Data Security in Fabric
Review of important elements
SQL Security in Fabric
OneLake security in Fabric
Desing Least privilege security architecture for all of One Lake
Foundations of Data Security in Modern Data Platforms
Intentional
Design
Multilayered and
applicable to
downstream
access
Flexible
leastprivilege
design
Boundary
Validation
Foundations of Data Security in Fabric
• Incorporating Entra Security Groups
• Workspace Security
• SQL Security
• OneLake Security*
• Sharing
OneLake Security
Security Options
•Sharing
•SQL Security
OneLake Security
•Implements RBAC Security on OneLake Data
•Includes both Row Level security and Object level security
Entra Groups for Users Access
Entra Security Groups need to be the basis for everything
Fabric designed to provide access through sharing
Do not need to give access to the workspace
Workspace Security
Most users have access everything
Only view permissions apply security
Best plan is to not add people to workspaces
How do you give people access to the data and not the workspace
Sharing Data
• Best managed in the OneLake Catalog
• Best Practice is granted to the objects
themselves, not workspace
• Provide limited rights
SQL Security
• Same as used in SQL Server for years
• Create using SQL Statements
• Create roles, permissions and assign them to groups
• There is no Impersonate, which makes testing difficult
• It is called SQL Security, not Power BI security, so it will not grant access to create semantic model
• If there is a semantic model based on data
CREATE ROLE Limitdata
Grant Select to Limitdata
Configuration of SQL Security
• Create a role
• Grant SELECT ton the role
• DENY SELECT on columns and tables
• Create a function for Row Level security
Use OneLake Catalog to
share the semantic model
• Workspace users with Admin or
Member access have the
permission to share
• They can share the semantic
model to users who do not have
access to the workspace
• The user can access the semantic
model from within the Power BI
Desktop, but they won’t be able to
see the data
Demonstration
SQL Security
OneLake security
OneLake Security access control
• OneLake data access controls
• Item Permissions
• Workspace permissions
• Compute or granular
permissions
OneLake Security - Preview
• Everything uses Entra
• Method for securing all of the data inside of
OneLake
• Data is secured no matter how it is accessed
• Granular role-based security
• Enforces security on the data layer
• Shortcut Security
• Only applies to users with view permissions or
where the data item is shared
• Manage in OneLake Catalog
OneLake security roles
Roles grant people access to data
• Data
• Permission
• Members
• Constraints
Works on Tables only, not views or stored procedures
Remove the default role and create new ones
Available in Lakehouse and Azure Databricks Mirrored Catalog
Roles in OneLake security
• Create the security on a lakehouse or a warehouse
• Delete the default role and add a new one
• Grant object and Row based security
• Select table then the Row and or Column
SQL Security Option Required
• Must select the SQL Security Option for SQL
Endpoints
• This will remove any other security on the objects
• User’s identity provides data access
User’s Identity
• OneLake security requires a change to to
the security model
• From within the Lakehouse SQL Endpoint
for OneLake Security you need to select
User’s Identity
• The Default is Delegated Identity
Security Best Practices
• Do not grant people workspace access to get access to data, use share for that
• Security policies are designed for share access, not workspace access
• Use OneLake catalog to manage and review access
Intentional Security by Design
Data can dictate design
Simplify the security model to avoid potential issues
For example, do not include PII data with people
Semantic Modeling in Fabric
• If you create a Direct Lake connection to a Lakehouse, you do not have to refresh it, you get the data
when the lakehouse is updated
• Currently, even if you create a Direct Lake model you cannot inherit the security if users are outside
the workspace
• If you import the data, you will need to create the row level security or column level security inside
the model
Summary
• If you want to restrict access to data accessed via a SQL Endpoint, use SQL based security
• If you need Row Level security inside a semantic model, you will need to create that as there
presently isn’t any inheritance
• OneLake Security is not ready for production
Sound off.
The mic is all yours.
Influence the product roadmap.
Join the Fabric User Panel
Join the SQL User Panel
Share your feedback directly with our
Fabric product group and researchers.
Influence our SQL roadmap and ensure
it meets your real-life needs
https://aka.ms/JoinFabricUserPanel
https://aka.ms/JoinSQLUserPanel
How was
the session?
Complete Session Surveys in
for your chance to WIN
PRIZES!
Questions?
Additional
Fabric Class
@desertislesql
www.linkedin.com/in/ginger-grant/
sessionize.com/ginger-grant/