This article explores the challenges of access control in modern data environments, characterized by a growing number of use cases, increasing data volumes, and expanding exposure points. We begin by reviewing the main access management models, as well as data-centric protection mechanisms, highlighting both their promises and limitations. We then examine the capabilities offered by leading market platforms and, through field experience and a Proof of Concept (PoC), reveal the gap between theoretical approaches and real-world implementation. Finally, we identify the structural causes of these weaknesses—particularly the absence of strong governance foundations—and propose a maturity-based framework to help organizations progress toward more coherent, sustainable, and business-aligned security, especially in the context of emerging AI-driven use cases. 

 

An expanding attack surface across data ecosystems 

 

Organizations have never processed so much data. Data lakes, data warehouses, BI platforms, and pipelines feeding AI models have dramatically expanded the analytical ecosystem—and with it, the number of users, systems, and access points that require protection. Where data access was once structured, controlled, and predictable, it has become increasingly distributed, open, and often poorly governed. 

The numbers speak for themselves: according to IBM, the average cost of a data breach now exceeds $4 million. Modern data environments, given the volume and sensitivity of the information they concentrate, sit directly on the front line of cyber risk. 

Yet the issue is not the lack of appropriate access control models—they have existed for years. The real question is whether modern data environments genuinely implement key IAM principles such as least privilege and Zero Trust. The honest answer is: rarely, and rarely well. 

 

Mature access control models… on paper 

 

There is no shortage of frameworks. From the most basic to the most sophisticated, access control approaches span a broad spectrum. 

ACLs (Access Control Lists) and RBAC (Role-Based Access Control) form the historical foundation of access management. Simple to deploy and widely supported natively, they remain the starting point for most environments. Their limitations, however, are well known: ACLs become unmanageable at scale when permissions must be administered object by object, while RBAC tends to create an explosion of roles that reproduces the very complexity it was designed to solve. 

ABAC (Attribute-Based Access Control) is often presented as the most advanced theoretical approach. By making access decisions based on dynamic attributes related to the user, the resource, and the context, ABAC provides significantly greater flexibility and granularity. However, successful deployment depends on a demanding prerequisite: a standardized, maintained, and governed attribute repository across the organization. 

ABE (Attribute-Based Encryption) extends the same concept to the cryptographic layer. Data is encrypted according to attribute-based policies, making access impossible without the required attributes, regardless of application-level controls. While highly relevant for the most sensitive datasets, we have only encountered a light implementation of this mechanism within a specific military context (Data-Centric Security), largely due to key management complexity and the limited native support provided by commercial platforms. 

RLS/CLS (Row-Level Security / Column-Level Security) and DDM (Dynamic Data Masking) operate directly on the data itself. 

• RLS filters query results based on user identity or attributes. 
• CLS restricts visibility of specific columns by masking or excluding sensitive fields according to user permissions. 
• DDM dynamically replaces sensitive values with masked representations without altering the stored data. 

 

Their key advantage lies in their proximity to the data layer, ensuring consistent enforcement regardless of the consuming application. Today, these mechanisms are among the most operational and immediately actionable controls available in production environments. 

QBAC (Query-Based Access Control) pushes the concept even further. Rather than filtering rows or columns, it rewrites and evaluates the query itself at runtime according to contextual rules. Similar to query-rewriting techniques studied in academic research, QBAC offers significant flexibility and adaptability. However, it remains poorly standardized and rarely industrialized. In practice, the deployments we observe often combine QBAC with DDM capabilities. 

Finally, JIT (Just-In-Time Access) focuses not on the data itself but on privilege duration. Elevated permissions are granted only when justified, for the minimum required period, before being automatically revoked. This significantly reduces standing privileges in alignment with Zero Trust principles. Native support exists across major cloud providers, while IAM platforms can supplement these capabilities by dynamically assigning preconfigured roles according to business needs. However, a recurring challenge remains: who validates access requests, how quickly can approvals be delivered, and how can organizations avoid overwhelming approvers while preserving meaningful security benefits? These questions often explain why JIT initiatives struggle to move beyond pilot phases. 

 

Data platform: fragmented capabilities 

 

An analysis of leading market platforms reveals a nuanced reality. 

Databricks and Snowflake offer some of the most mature native governance capabilities available today. Databricks’ Unity Catalog centralizes permissions management across data assets and supports RBAC, ABAC, RLS, CLS, and DDM capabilities while providing integrated SQL-accessible auditing. Snowflake follows a similar approach with Row Access Policies and Masking Policies governed through tags. These platforms currently represent the most comprehensive foundations for serious access governance. 

Power BI and Tableau, by contrast, are primarily reporting and visualization layers whose security models are designed to inherit controls from underlying data platforms. Power BI provides RLS and Object-Level Security capabilities, but these controls do not apply to users holding Admin, Member, or Contributor roles within a Power BI Service workspace. Without complementary protections on the data platform itself, such users may obtain unrestricted access to datasets. Tableau’s Virtual Connections help centralize security rules, but the platform remains less mature than specialized data platforms in this area. 

This leads to a fundamental question: where should access policies actually be defined? Within IAM systems? On the data platform? In the BI layer? 

Across most environments we observe, the answer is unfortunately: everywhere at once, often without consistency, governance, or centralized visibility. 

 

What the field reveals: fragile security by design 

 

Observations gathered across client engagements consistently reveal a structural gap between theoretical recommendations and real-world implementations. 

The first recurring pattern is the open data lake. Access restrictions are enforced not at the data layer itself, but through consuming applications. Each application manages its own security rules based on the connected user. This model works—until an application is compromised, misconfigured, or bypassed. At that point, the entire data lake may effectively become exposed. 

A second pattern is equally common. Access controls technically exist, but are bypassed in practice through service accounts and intermediary application privileges. When a request reaches the data platform, the originating user is no longer visible; only the technical account used by the application remains. As a result, access policies become generic and frequently more permissive than necessary. 

Advanced mechanisms such as ABAC remain the exception rather than the rule. More sophisticated approaches are even rarer, with very few examples observed in large-scale production data environments. 

 

Proof of Concept: confirming our observations 

 

To validate these findings, we conducted a Proof of Concept based on a Databricks and Power BI architecture using a fictional transactional dataset containing five million records and six representative user profiles. 

 

 

The tested architecture combined Unity Catalog on the Databricks side (centralized governance, SQL Warehouse, Delta tables) with Power BI Desktop for reporting, while evaluating two connection modes in parallel. 

The most significant finding emerged from the comparison between DirectQuery and Import Mode. 

In DirectQuery, each request is transmitted to Databricks in real time, user identity is propagated, and Unity Catalog policies are enforced at every interaction. 

In Import Mode, data is cached within Power BI’s VertiPaq engine. Databricks security policies are applied only during the initial load. Any subsequent changes to permissions in Unity Catalog have no effect until the dataset is refreshed. This behavior was experimentally confirmed: enabling a masking policy after data import did not impact data already stored in the cache. 

Since Import Mode is often favored in enterprise environments for performance and simplicity, it represents a structural vulnerability whenever datasets require differentiated access rights. This is not a configuration issue—it is a consequence of the architecture itself and is frequently overlooked during design decisions. 

To mitigate this risk, organizations can implement Power BI’s native dynamic RLS using DAX, although these capabilities remain less advanced than security controls embedded directly within modern data platforms. 

Databricks’ RLS and DDM capabilities proved operational and relatively straightforward to implement, with policies propagating properly from schemas to underlying tables. However, Databricks’ implementation of ABAC remains more limited than what many practitioners associate with fully contextual access control. Contextual parameters such as time of day, IP address, or user location cannot currently be used directly; policy evaluation primarily relies on user/group tags and resource attributes. Additional flexibility can nevertheless be achieved through federation with groups managed by IAM systems. 

 

The root cause: a lack of governance foundations 

 

Organizations struggling to deploy advanced controls are not doing so because they underestimate the risks. Most fully understand the challenges. 

What they often lack are the foundational governance capabilities upon which these controls depend. 

Across the majority of environments we assess, the most common gaps include: 

• A structured and sustainably maintained data classification framework, enabling consistent filtering, masking, and restriction policies. 
• A reliable and governed attribute repository, supporting dynamic approaches such as ABAC. 
• A centralized data catalog, providing visibility, traceability, and consistency across access controls. 
• Cross-functional access governance, aligning IAM, data platforms, and analytics tools. 
• Active involvement of IAM teams in data-related initiatives, preventing fragmented access management practices. 

It is precisely within this fragmented governance space that the most significant risks tend to emerge. 

 

A progressive maturity journey is the way forward 

 

Faced with these challenges, organizations are often tempted to define an ideal target state and measure the gap. This is usually the wrong approach. 

Organizations differ widely in maturity, technical constraints, regulatory requirements, and business needs. Rather than aiming for a single end-state, a more practical approach is to progress through successive maturity stages. 

 

The objective is not necessarily to reach the highest maturity level. It is to understand where the organization stands today, identify what prevents advancement to the next stage, and prioritize investment in the missing foundations, whether technical, organizational, or governance-related, without which meaningful progress remains impossible. 

 

Key takeaways 

 

In modern data environments, the challenge is no longer the availability of mature access control mechanisms—they already exist. The challenge lies in implementing them consistently, centrally, and operationally. 

The rapid expansion of exposure surfaces, the fragmentation of controls across IAM systems, data platforms, and BI tools, and the gap between theoretical models and actual implementations all contribute to security architectures that are inherently fragile. 

Our field experience and PoC demonstrate that common architectural choices—such as Power BI Import Mode or application-centric access controls—can create structural vulnerabilities despite the presence of advanced capabilities such as RLS, DDM, and ABAC. 

Ultimately, the main limitation is not technological. It is the absence of governance foundations: data classification, attribute repositories, centralized catalogs, and close collaboration between IAM and data teams. 

As AI use cases continue to expand, these challenges become even more critical. Organizations increasingly require reliable and dynamic propagation of access rights across architectures that are more open, interconnected, and unpredictable than ever before. 

The path forward therefore lies in a structured convergence between IAM and data governance—one capable of delivering robust, scalable, and sustainable access control across the modern data ecosystem.