Forum Discussion
Protecting sensitive columns from workspace Admins/Members in Fabric — OneLake security, RLS/CLS?
I'm designing data protection for a dataset containing highly sensitive PII (names, account numbers, national ID numbers) landing in OneLake, and I've hit a wall I'd like to confirm I'm reading correctly.
From the docs and the recent OneLake security GA material, my understanding is that OneLake security roles, RLS, CLS, and Dynamic Data Masking only constrain Viewers / item-Read users — anyone in the workspace Admin, Member, or Contributor role bypasses all of them and can read everything. Purview DLP "restrict access" looked promising, but (a) it's coarse — it blocks the whole item, not specific columns, (b) it's still in preview for SQL/KQL DBs and Warehouses, and (c) it can be configured to let workspace admins override it.
So none of the native, in-platform controls seem to actually protect data from a privileged insider or workspace admin.
Questions for anyone who's solved this in production:
1. Is the above correct as of mid-2026, or am I missing a native control that genuinely binds Admin/Member/Contributor roles?
2. For a true "even our own platform admins can't read the raw values" requirement, is the accepted pattern to encrypt or tokenize the sensitive fields before ingestion — so OneLake only ever holds ciphertext/tokens, with keys in a vault outside Fabric?
Environment: [Lakehouse / Warehouse / Fabric SQL Database — please fill in], OneLake security enabled, Purview connected.
Appreciate any real-world patterns or gotchas.
Thanks!
Hi Ira_27 ,
You're reading it right. OneLake security, RLS, CLS, and DDM mainly constrain Viewers/Read users. Workspace Admin, Member, and Contributor roles get Read on OneLake by default, and Admins/Members can edit or remove security roles, so these aren't a boundary against workspace-privileged users. Purview DLP and labels add governance, not a cryptographic barrier.If admins must not see raw values, don't land raw PII in OneLake. Tokenize or envelope-encrypt upstream and keep keys/detokenization outside Fabric (Azure Key Vault / Managed HSM or a dedicated service) under a separate identity. Fabric then only stores ciphertext or tokens. CMK protects data at rest but won't stop an admin reading plaintext once it's in a lakehouse.
Use RLS/CLS/DDM/OneLake security for normal consumer access. Add least privilege and separation of duties on workspace roles, Purview labels/DLP, tenant auditing, and an isolated workspace or tenant if raw data must exist transiently. Worth checking current docs — these controls evolve fast.
Hope this gives you a clear direction to design around. Happy to discuss further if you want to dig into any specific layer.
Resources:
- Data security overview – OneLake
- Get started with OneLake security
- Best practices for securing data in OneLake
- Fabric end-to-end security scenario
- Column-level security in Fabric warehousing
Did this answer hit the mark? A small Kudos goes a long way — it fuels the community and encourages more folks to contribute.
Got what you needed? Marking this as the Accepted Solution helps others land on the right answer faster when they search for the same thing.
4 Replies
Hi Ira_27
You are correct with regards to the workspace roles and who can view the data within a workspace. But with that being said, there is the new Purview protection policies which will supersede any workspace roles that you have in your organization. What that means is a workspace role user cannot override what's in Purview because Purview sits outside of Microsoft Fabric but still enforces the data. Yes, it is at the art level, but if that is your requirement for sensitive data, it is better off to secure the entire thing than just a piece that could potentially be shown. Protection policies in Microsoft Fabric - Microsoft Fabric | Microsoft Learn
So you wouldnt suggest column encrpytion?
Hi Ira_27 ,
You're reading it right. OneLake security, RLS, CLS, and DDM mainly constrain Viewers/Read users. Workspace Admin, Member, and Contributor roles get Read on OneLake by default, and Admins/Members can edit or remove security roles, so these aren't a boundary against workspace-privileged users. Purview DLP and labels add governance, not a cryptographic barrier.If admins must not see raw values, don't land raw PII in OneLake. Tokenize or envelope-encrypt upstream and keep keys/detokenization outside Fabric (Azure Key Vault / Managed HSM or a dedicated service) under a separate identity. Fabric then only stores ciphertext or tokens. CMK protects data at rest but won't stop an admin reading plaintext once it's in a lakehouse.
Use RLS/CLS/DDM/OneLake security for normal consumer access. Add least privilege and separation of duties on workspace roles, Purview labels/DLP, tenant auditing, and an isolated workspace or tenant if raw data must exist transiently. Worth checking current docs — these controls evolve fast.
Hope this gives you a clear direction to design around. Happy to discuss further if you want to dig into any specific layer.
Resources:
- Data security overview – OneLake
- Get started with OneLake security
- Best practices for securing data in OneLake
- Fabric end-to-end security scenario
- Column-level security in Fabric warehousing
Did this answer hit the mark? A small Kudos goes a long way — it fuels the community and encourages more folks to contribute.
Got what you needed? Marking this as the Accepted Solution helps others land on the right answer faster when they search for the same thing.
Hi Ira_27,
Thank you for reaching out to the Microsoft Fabric Community Forum. Also, thanks to Dev_Dholakia, GilbertQ, for those inputs on this thread.Has your issue been resolved? If the response provided by the community member Dev_Dholakia, GilbertQ, addressed your query, could you please confirm? It helps us ensure that the solutions provided are effective and beneficial for everyone.
Hope this helps clarify things and let me know what you find after giving these steps a try happy to help you investigate this further.
Thank you for using the Microsoft Community Forum.
