Forum Discussion
Fabric Security Issues
Hi Anonymous ,
Thanks for reaching out to the Microsoft fabric community forum.
suparnababu8 Thanks for your prompt responseAnonymous ,
Potential Workarounds
Given the current limitations, here are some strategies you might consider:Separate Workspaces for Different Layers:
Maintain separate workspaces for ingestion (bronze) and curated (silver/gold) layers.
Restrict access to the ingestion workspace to only service principals or specific users responsible for data ingestion.
Grant the curated team access only to the curated workspace, ensuring they cannot modify raw data .
Use of Viewer Role with SQL Endpoint:
Assign the Viewer role to users in the curated workspace.
Instruct users to access data exclusively through the SQL analytics endpoint, which enforces read-only access.
Note that this approach limits users from using notebooks or the Lakehouse UI for data exploration.
Implement Row-Level and Column-Level Security:
Within the curated workspace, apply Row-Level Security (RLS) and Column-Level Security (CLS) to control data access at a more granular level.
This ensures that even if users have broader access, they can only view data they're authorized to see.
Monitor and Audit Activities:
Implement monitoring and auditing to track data access and modifications.
While this doesn't prevent unauthorized changes, it can help in identifying and addressing them promptly.
Lakehouse sharing and permission management - Microsoft Fabric | Microsoft Learn
Give users access to workspaces - Microsoft Fabric | Microsoft Learn
Implement medallion lakehouse architecture in Fabric - Microsoft Fabric | Microsoft LearnIf this post helped resolve your issue, please consider giving it Kudos and marking it as the Accepted Solution. This not only acknowledges the support provided but also helps other community members find relevant solutions more easily.
We appreciate your engagement and thank you for being an active part of the community.
Best regards,
LakshmiNarayana.
Hi Anonymous
Thank you for detailed explained of your problem. Let me answer your questions as follows
- Is there a way to prevent data manipulation language operations in a lakehouse (INSERT, UPDATE, DELETE, ALTER) to members of a workspace (override priviledges granted to the workspace member role)?
At present microsoft fabric, doen;t support for INSERT,UPDATE,DELETE and ALTER operations and also not provide read only access to the lakehouse of workspace roles/memebers. For example if you shared a lakehouse with a member having read access, but if the user has Member role , then thatuser can be able to modify the tables(by using spark). If you want to restrict the user, you can inplemet RLS or CLS. read more detaisl here Microsoft Fabric end-to-end security scenario - Microsoft Fabric | Microsoft Learn
- Is there now a way — or is there going to be a way — to delegate security of shortcutted tables to the target lakehouse, thereby removing the need to grant access to the source lakehouse?
Currently, if fabric users want to use shortcuuts in Fabric, they must have permision to access the original lakehouse. This makes it to difficult to seperate roles properly. There is not a way to give security permiissions only for the target lakehouse without giviing access to the sorurce lakehouse. Microsoft introduced, to create secuirity settings specifiically for shortcuts, allowing users to access them without needing permision for the original lakehouse.
- Does Microsoft Purview allow us the ability to override workspace membership and grant users read access and the ability to create views in a lakehouse without enabling full modification rights?
Yes, Purview helps with Govenrnace and security, but it's not clear where you can override workspace memership roles in Fabric. If your organisation uses Purview, it will help you manage data access polices, but it will not completely fix the issue of inherited workspsce. Since you are not managing M365, you can check with your M365 Team to see if Purview can enfore reda only access.
So, Use SQL analytics point in lakehosue only for read only access, bcz you can able to performa DML operations. Use seperate workspaces for different roles. If you want to introduce DML operations in Lakehouse you can submit your idea here Fabric Ideas - Microsoft Fabric Community
Thank you again!
Did I answer your question? Mark my post as a solution!
Proud to be a Super User!
No, this did not answer my question.
To your first point:
- Even the link you provided contains inaccurate information/guidance (https://learn.microsoft.com/en-us/fabric/security/security-scenario). It says, "Your data analysts need access to the second lakehouse in the gold workspace. They'll connect to the SQL analytics endpoint of that lakehouse to write SQL queries and perform analysis. So, you share that lakehouse with them and provide access only to objects they need (such as tables, rows, and columns with masking rules) in the lakehouse SQL analytics endpoint by using the SQL security model. Data analysts can now only access data that's relevant to their role and department and they can't access the other items in the workspace, such as the pipelines and notebooks" which is inaccurate because you can't just give access to the "second" lakehouse (which contains shortcuts) without granting access to the original lakehouse. Again, this is an issue.
- Secondly, we already understand how to set up RLS/CLS security but this doesn't allow us to restrict users from modifying tables in a lakehouse. It will only show them the data they have access to but if they are a member/contributor of the workspace, they can still go into the lakehouse and modify tables. So, RLS/CLS does not have relevance with regard to my original question.
- As a side note: you would think that more granular (item-level permissions) would override workspace permissions but that does not appear to be the case.
To the second point:
- I believe you are saying Microsoft introduced security setting specifically for shortcuts, can you provide more information on that (link to more information, etc.)?
And finally, to your statement about using SQL analytics endpoint so I CAN perform DML operations…I want to RESTRICT DML operations (not find a way to perform them). And you are inaccurate in that statement as well because in stand-alone warehouses, you can perform DML operations but in the SQL End Point of a lakehouse (warehouse tied to a lakehouse), DML operations are restricted by default. However, DML operations can still be performed on the lakehouse if you have above viewer access and there is no way currently (from what I can tell) to restrict it which again is what I am trying to do.