Immuta
A data access control platform where policies are written once as rules and enforced across connected data platforms.
Immuta is a platform for controlling access to data. Rather than granting permissions separately in each database, policies are written as rules referring to attributes of the data and of the user, and Immuta enforces them on the connected platforms. It also supports masking values and restricting rows according to who is asking.
The problem with permissions in every system
An organisation with a warehouse, a lake and several databases has access controls in each of them. Every one has its own model of users, roles and grants.
A requirement arriving from outside, that personal data must only be visible to staff who need it, then has to be translated into each system separately. Someone grants and revokes in every place, and keeps doing so as tables are added and people change roles.
Two things go wrong reliably. Permissions drift apart, so the same rule is enforced differently in different systems. And new tables arrive without anyone remembering to apply the rule, so data is exposed by omission rather than by decision.
Immuta addresses this by moving the policy out of the individual systems.
Rules about attributes, not tables
The central idea is that a policy refers to attributes rather than to named objects.
A conventional grant says a particular role may select from a particular table. That statement is about one object and stops being true when a new table appears.
A policy here says something like: columns tagged as personal data are masked for users who do not hold a stated role.
It names no tables. Any column carrying that tag is covered, including ones created next month.
This is what changes the maintenance burden. Instead of a permission per object growing without limit, there is a set of rules, and coverage follows from how data is tagged.
It does mean tagging has to happen and has to be accurate. The rules only reach data that is labelled, so this approach depends on the classification work being done rather than removing the need for it.
Two ways to limit what is seen
Masking applies to columns. A value is hidden, partially shown or replaced depending on who is asking. An account number appears in full to one person and with most digits obscured to another. The row is still there.
Row restriction applies to rows. Someone responsible for one region sees only that region's records, with the rest absent rather than hidden.
Requirements usually need both. Staff see the records for their territory, and within those records certain personal columns remain obscured.
The important consequence is that one copy of the data serves both audiences. Without this, the usual practice is producing filtered extracts per group, which means several copies that all need maintaining and securing, and which are usually out of date.
Enforcement where the query runs
Immuta connects to data platforms and applies policy to queries as they execute against them.
The data is not moved. This matters, because the alternative approach, copying data into a controlled environment, creates exactly the duplication that causes governance problems in the first place.
The details of how enforcement works vary by platform, and the official documentation covers what is supported and how each connection behaves. That documentation is the reference rather than any general description, since capability depends on the platform.
Answering the audit question
Governance obligations usually come down to a question that is harder than it sounds: who could see this data, and under what rule.
When permissions live in six systems, answering it means assembling evidence from six places and hoping nothing was missed.
With policy centralised, the rules and their application are recorded in one place. The answer is available rather than reconstructed.
Who uses it
Immuta is used by data governance, security and platform teams in organisations subject to obligations about personal or regulated data. It appears most often where analysts need broad access to data that also carries restrictions, and where producing filtered copies per audience has become unmanageable.
Points to consider
Immuta is a commercial product. The official documentation is the reference for supported platforms, deployment options and capabilities, and current details should come from there.
It depends on classification. Policies apply to data that is tagged, so the value obtained is bounded by how consistently tagging is done. Organisations without a classification practice will need to build one alongside.
It sits between users and data platforms, which is an architectural commitment. How queries are affected and what happens if the service is unavailable are questions to understand before deployment rather than after.
Policy replaces grants rather than removing the need for thought. Badly written rules deny access that should be allowed or permit access that should not be, and reviewing them remains necessary work.
Getting started
The official documentation covers connecting data platforms, tagging, writing policies and the masking and restriction options available. Applying a single masking policy to one tagged column and querying as two different users demonstrates the model quickly and with little setup.
Key features of Immuta
Capabilities described in the official documentation.
Policies written as rules
Access is expressed in terms of data attributes and user attributes rather than as grants per table.
Enforcement across connected platforms
One policy applies to the data platforms Immuta is connected to instead of being repeated in each.
Masking of column values
Sensitive columns can be hidden, partially shown or replaced according to who is running the query.
Row level restriction
Users see only the rows a policy permits, with the restriction applied as the query runs.
Advantages of Immuta
Factual advantages that follow from the features above.
Rules do not have to be repeated
A policy expressed once covers the connected platforms rather than being maintained separately in each.
New data inherits existing rules
Because policies refer to attributes, tables tagged accordingly are covered without a new grant.
Access is auditable in one place
What the policy says and who it applied to are recorded centrally rather than scattered across systems.
One copy can serve different audiences
Masking and row restriction mean separate filtered copies do not have to be produced per group.
Common use cases for Immuta
Situations the official documentation describes this tool as being used for.
Restricting access to personal data
Columns holding personal details are masked for users whose role does not permit seeing them.
Limiting records by region
Row level rules mean staff see only the records belonging to the territory they are responsible for.
Giving analysts access without copies
Analysts query the original tables under policy rather than receiving separately prepared extracts.
Demonstrating who could see what
Central records of policy and access support answering questions from auditors and reviewers.
Official website
Everything on this page is based on the official documentation for Immuta. You can read the source here.
Immuta official documentation