The “One Policy” Approach to Policy-Based Access Management

In his Lord of the Rings series, J.R.R. Tolkien writes of 19 rings of power that give their bearers wealth, dominion, and control. Of these, the most powerful is the “One Ring,” which affords its bearer control over all other rings and, by extension, the entire  world.

What do rings have to do with data security? As organizations continue migrating data to the cloud, more users have greater access to data resources. However, this needs to be managed effectively in order to align with compliance laws and regulations and avoid unnecessary risk.

You could choose to enforce data access management through a collection of disparate, specialized policies for different data sources and user types. But what if you could achieve the same level of security – across your cloud ecosystem – with just a single policy? In this blog, I’ll share how some of our customers are implementing cloud data security and enabling users with enhanced access through “One Policy” to rule them all.

The Challenges of Policy-Based Access Management

Most modern data teams face a common challenge – the enhanced flexibility of cloud data platforms makes data more accessible, but also adds a layer of risk of data breaches or leaks. To address this challenge, they implement data access controls, policy-based rules that determine whether or not specific data can be accessed by specific users.

Many leading cloud platforms come with built-in data access control capabilities. The Snowflake Data Cloud, for example, gives teams the ability to apply either discretionary access control (DAC) or role-based access control (RBAC)policies on their data. Similarly, the Databricks Lakehouse Platform allows teams to enforce access control lists (ACLs) across their Databricks clusters.

As organizations scale their cloud data use and adopt multiple platforms, these built-in capabilities aren’t always able to keep up. RBAC, DAC, and ACLs are all relatively static access control methods, locking teams into more rigid access management structures that aren’t suited for steady growth. For instance, if someone wanted access to “finance data,” you could create a role for the table associated with finance. You could create a similar role for those who need to access “HR data.” But what if a user needs access to only some of the finance tables and wants to join them with HR tables? Then another role needs to be created, enforced, and maintained. It’s easy to see how this issue could get out of hand.

When teams try to scale policy management with static access controls, they end up with issues like role explosion and approval bottlenecks. These limit what users can access and how fast they can access it – nearly half (44%) of the respondents in our 2024 State of Data Security Report shared that accessing a new data set can take a week or more. This makes it incredibly difficult for an organization to scale operations and increase revenue. How can we avoid these policy-based access management blockers?

Defining The “One Policy” Approach to Data Access Management

Using dynamic attribute-based access controls (ABAC), you can reduce the number of policies required to achieve access management needs down to the single, effective “One Policy.” According to GigaOm, leveraging ABAC can reduce policy burden by 93x compared to RBAC.

The “One Policy” approach leverages user attributes and data tagging and classification to dynamically enforce access controls for all users, regardless of their roles, departments, etc. To implement this approach, you must do the following:

1. Determine Relevant Tags: Tags can include classifiers such as level of sensitivity, data type/source, location of origin, and more. These tags should be generated and applied with the end goal – dynamic and compliant access control – in mind.
2. Apply Tagging to Tables: By running sensitive data discovery on your organization’s data, you can tag and classify data appropriately. This process should also incorporate metadata from data catalogs like Alation or Collibra, providing an additional layer of detail to tags without manual effort. Access determinations can then be made based on these tags.
3. Create an Access Policy: With a tag schema created and applied, you can create a single access policy that leverages user attributes and predetermined tags in order to make the appropriate access determinations.

The key is that the policy never changes – only the data’s classification and/or users will change over time. The policy will stay the same as long as the table tags and attributes align and continue to follow the hierarchy that your company sets forth. You can simplify this model by matching a single table tag to an attribute, or make it more elaborate by using elements that express a hierarchy of domains, source systems, and security classifications.

“One Policy” in Action: Thomson Reuters’ Experience

The “One Policy” concept originated from Immuta’s work with organizations like leading financial services firms, healthcare providers, and news and media companies like Thomson Reuters (TR).

The TR team came to Immuta with a need to simplify and automate their Snowflake environment for access to tables. Our first step was to define their requirements for  automation. TR already had a very good model in place where data access was determined based on the following classifiers:

• Data Domain: Which group owns the data (HR, Finance, etc.)
• Source System: Where the data originates (SAP, Salesforce, etc.)
• Security Classification: Hierarchical levels based on sensitivity (shown below)

For access, TR’s team requires a match of these three classifiers. The security classification is hierarchical, so a user having access to the “Strictly Confidential” level means they automatically gain access to the other lower levels of security. Using these elements, we built out a single Immuta Subscription Policy (One Policy) that automates access for all of Thomson Reuters’ data users in three steps:

Step 1: Develop Tagging Structure

The first step is developing a tagging structure for the tables themselves. This is of the form: <Data Domain>.<Source System>.<Security Classification>.  A given table tag would look something like “Finance.SAP.SC.” The Security Classification may have multiple entries and should be in the order of least-privilege to the broadest access.  If a table is confidential, the Security Classification tag would be SC.C and if a table is public, the classification would be SC.C.I.P. Each level of the Security Classification needs to be present in the tag for the One Policy to work.

Step 2: Add Attributes to Users to Match Table Tags

Using our “@hasTagsAsAttributes” feature, we can add attributes to a user that allow access when they match our predetermined table tags.

In the image above, each table has been tagged with the scheme outlined earlier. You can see the Data Domain, Source System, and Security Classification clearly. Each user has attributes that specify the data they can access, and each table has tags applied for access determinations.

Step 3: Create & Apply One Policy

Let’s take a look at the One Policy that links attributes and tags to grant access.

Breaking down the graphic example above, @hasTagsAsAttributes works like a WHERE clause with a wildcard at the end. The “AllowedDomain” attribute is placed on the user, and the “dataSource” tag comes from the tagged data sets. Say a user had the following characteristics:

• Data Domain: Finance
• Source System: SAP
• Security Classification: SC (strictly confidential)

Under the One Policy, based on their attributes they would be granted access to all three of the tables shown below. They are a direct match to the “Finance.SAP.SC.C” table, they have hierarchical access to the “Finance.Salesforce.SC.C” table, and they have security clearance for the “HR.SAP.SC” table. If our user only had “.C” security classification, then they would not have access to either of the “.SC” tables.

“One Policy” for Policy-Based Access Management

Through Thomson Reuters’ experience, we can see the true power of the “One Policy.” Their team was able to use a single policy to automate data access across all domains, freeing up data engineers to focus on other priorities and seeing a 60x increase in data usage throughout the company.

Much like the One Ring, this kind of policy can manage to wrangle all access determinations under one commanding presence, making policy-based access management a more streamlined and practical process. Unlike the One Ring, however, this policy approach doesn’t need to be destroyed in the pits of Mount Doom. Instead, it can destroy the blockers of role explosion and approval bottlenecks, and make accessing data a smooth and secure process for all.

To learn more about policy management, check out The Data Policy Management Report we compiled with 451 Research. If you’d like to discuss your potential use of a “One Policy” approach, schedule a demo with our team today.