Securing and governing your medallion layers in Fabric Data Warehouse

Coauthor - Artur Vieira

Part 4 of a series on medallion architecture with Fabric Data Warehouse 

Security should follow the layers, not fight them 

In Part 1 we chose the pattern, in Part 2 we built the layers, and in Part 3 we covered the operating practices that keep them healthy. Security is the natural next step, because a medallion architecture already gives you something most platforms do not: three clearly different audiences. 

A medallion architecture creates clear boundaries between raw, refined, and curated data. Applying security and governance at those boundaries helps reduce unnecessary exposure, simplify access decisions, and give each audience the data it needs without opening every layer.. 

The following approach shows how to secure and govern a medallion pipeline in Fabric Data Warehouse. 

Why this matters 

Most access problems in analytics platforms are not dramatic breaches. They are cases of unnecessary access, such as an analyst who can read raw customer records because the entire warehouse was shared or a service account with more permissions than its task requires. 

A medallion architecture simplifies this work because each layer already signals a different level of sensitivity. Raw data is typically the most exposed and least useful to a business user, while curated data is shaped for broader consumption. The security model should follow that progression. 

The goal is simple: as data moves toward Gold, the audience can expand because the data has been cleaned, shaped, and protected for broader use. 

Rule 1: Separate the layers before you secure them 

Access control is much easier when the layers are separate objects. This is the same layout rule from Part 1, now with a security payoff. 

In Fabric,  If Bronze, Silver, and Gold live in separate workspaces, you can keep the Bronze workspace restricted to a small engineering group while giving a wider audience access to the Gold workspace. Separate workspaces also provide clearer access boundaries and can help isolate workloads across the medallion layers. 

Workspace roles and item permissions are not the same thing, and the difference matters for medallion. Admin, Member, and Contributor all receive CONTROL on every warehouse and SQL analytics endpoint in the workspace: full read/write access plus the ability to manage SQL permissions. Viewer receives CONNECT and ReadData, so viewers can read every table and view with T-SQL. When you share a single warehouse instead, you choose the level: Read lets the recipient connect only, “Read all data using SQL” grants ReadData (the equivalent of db_datareader), and “Read all data using Apache Spark” grants ReadAll over the warehouse’s files in OneLake. 

ReadData and ReadAll are separate permissions that do not overlap. Treat ReadAll as an engineering permission: row-level and column-level security apply only to queries on the warehouse or SQL analytics endpoint, so Spark access to the underlying files should go only to people who are allowed to see everything in that layer. 

Do this well: 

• Put each layer in its own workspace when governance matters, or at least in its own Fabric item. 

• Assign workspace roles deliberately. Admin, Member, Contributor, and Viewer are not interchangeable. 

• Give analysts Viewer access to Gold and no path into the Bronze workspace at all. 

• Share Gold with “Read all data using SQL” for consumers, or share with Read only and add T-SQL GRANTs when they should see just some objects. 

Rule of thumb: if one workspace role grants access to raw and curated data at the same time, the layout is doing security a disservice. 

Rule 2: Grant the least privilege each layer needs 

Within a warehouse, Fabric Data Warehouse supports granular SQL permissions. You can grant or deny access to schemas, tables, views, and procedures, which is especially useful when multiple medallion layers share one warehouse. 

If Bronze and Silver sit in the same warehouse separated by schemas, revoke general read access on the Bronze schema and let only engineers or a service identity use it. Most consumers should never need more than read access to Gold. 

Do this well: 

• Default to read-only for anyone who consumes data rather than builds it. 

• Give pipelines and service identities only the permissions their job requires, on the layers they actually touch. 

• Review permissions when a layer changes owners, not only when someone complains about access. 

Rule of thumb: many people need Gold, a few need Silver, and very few should need Bronze. 

Rule 3: Use row-level security when one table serves many audiences 

Row-level security in Fabric Data Warehouse controls which rows a user can view based on group membership or execution context. This lets one Gold table safely support audiences such as different regions, departments, or customers without creating a separate table for each group. 

This belongs mostly in Gold. That is where a single fact table often serves several regions, departments, or customers at once. Bronze and Silver are usually restricted to a small team already, so filtering rows there solves a problem you should not have. 

One scope note: row-level and column-level security apply to queries on the warehouse or SQL analytics endpoint. Power BI semantic models in Direct Lake mode fall back to DirectQuery to honor them, so include that in your Gold performance testing. 

Do this well: 

• Apply row-level security to every table that requires audience-specific filtering. If a table has no row-level security policy, users with access to that table can view all rows permitted by their other assigned permissions. 

• Account for pipeline identities in the predicate, so data movement is not blocked by the filter. 

•  Test as a restricted user, not only as an administrator, so modeling mistakes surface before publication. 

Rule of thumb: use row-level security to share one trusted table safely, not to compensate for a missing Gold model. 

Rule 4: Protect sensitive columns instead of hoping nobody queries them 

Some fields should not travel all the way to Gold. The cleanest control is simply not exposing a sensitive column in the curated layer at all. 

When a sensitive field must remain in the warehouse, use column-level security to block access for roles that should not see it. Use dynamic data masking when the column must remain available but its value should be obscured for users without permission to view the original data. 

Implement column-level security with a GRANT SELECT that lists only the permitted columns; any query that touches another column fails. Masking behaves differently. Administrators, members, and contributors hold CONTROL on the warehouse and see unmasked data by default, and a user with query access can infer masked values through range filters. Use masking to prevent accidental exposure, and rely on column-level security and least privilege when a value must stay hidden. 

Do this well: 

• Drop identifiers in Silver or Gold when the business question does not need them. 

• Use column-level security when a role should not see a field at all, and masking when the field must be present but obscured. 

• Grant the unmask narrowly and treat it as a decision worth recording. 

Rule of thumb: the safest sensitive column is the one Gold never carries. 

Rule 5: Make governance visible 

Security defines who can access data. Governance explains where the data came from, what it means, how it should be handled, and how it is being used. 

Fabric’s lineage view helps trace how data moved between items, especially when pipelines and dataflows do the work. Descriptions on tables and columns are worth the effort, because they tell the next person which fields are sensitive and how a value was derived. Audit logs matter most on Bronze and Silver, where unexpected access is the signal you actually want to catch. 

Do this well

• Document how Gold fields are derived from Silver, so a report can be traced back to its source. 

• Keep a catalog of sensitive fields and where they live in each layer. 

• Review access to each workspace and item on a schedule, rather than only after an incident. 

Rule of thumb: if nobody can explain where a Gold number came from, governance is missing even when security is fine. 

Compliance in a medallion pipeline 

A clear medallion design also makes compliance work easier to reason about. Bronze typically holds personal data in its rawest form, and Silver is a natural place to pseudonymize, filter, or otherwise reduce what moves forward. 

 When a deletion request arrives, use the layer boundaries to identify every copy of the affected data and remove or update it according to your organization’s retention and deletion requirements. Then refresh downstream Silver and Gold data so the corrected state is reflected throughout the pipeline. Better still, decide early whether sensitive data needs to land in Bronze at all. The least expensive compliance problem is the one you never create. 

Access at a glance 

Use this as a starting point when you map audiences to layers. 

Takeaway 

Secure each layer for its audience. Bronze stays highly restricted, Silver stays moderately restricted, and Gold is widely readable but carefully shaped. 

Use workspace roles and item permissions as your first line of control, then SQL permissions, row-level security, column-level security, and masking for the fine-grained cases. Pair that with lineage and audit so the pipeline can be explained, not just accessed. 

Done well, a medallion architecture does not only deliver clean data. It also makes it obvious who should see what. 

Ready to go deeper? Explore the Fabric Data Warehouse security documentation, then stay tuned for Part 5 of this series, where we’ll cover performance tuning your medallion pipeline.

References 

• Row-level security in Fabric Data Warehouse  

• Implement row-level security in Fabric Data Warehouse  

• Column-level security in Fabric Data Warehouse  

• Dynamic data masking in Fabric Data Warehouse Workspace roles in Fabric Data Warehouse Share your warehouse and manage permissions (Read, ReadData, ReadAll)  

• SQL granular permissions in Fabric Data Warehouse  

This post is part of our Medallion Architecture on Fabric Data Warehouse series: 

• Choosing your medallion pattern in Fabric Data Warehouse 

• Building the Bronze → Silver → Gold layers 

• Fabric DW best practices for medallion architectures 

• Securing and governing your layers 

• Performance tuning your medallion pipeline