Was this helpful?
Was this helpful?
In today’s world of modern privacy regulations, deciding what a single user can see is not just about who they are, but what they are doing. For example, the same user may not be able to see credit card information normally, but if they are doing fraud detection work, they are allowed to.
This may sound silly because it’s the same person doing the analysis, so why should we make this distinction? This gets into a larger discussion about controls. When most think about controls, we think about data controls - how do we hide enough information (hide rows, mask columns) to lower our risk. There’s a second control called contextual controls; what this amounts to is having a user agree they will only use data for a certain purpose and not step beyond that purpose. Combining contextual controls with data controls is the most effective way to reduce your overall risk.
In addition to the data controls you’ve seen, Immuta is also able to enforce contextual controls through what we term purposes. You are able to assign exceptions to policies, and those exceptions can be the purpose of the analysis in addition to who the user is (and what attributes they have). This is done through Immuta projects; projects contain data sources, have members, and are also protected by policy, but most importantly, projects can also have a purpose which can act as an exception to data policy. Projects can also be a self-service mechanism for users to access data for predetermined purposes without having to involve humans for ad hoc approvals.
The goal of Immuta is to modernize the management of data policies in organizations. One key aspect of modernization is to remove day-to-day human involvement in policy decision making, which is fragile and subjective. One decision process is how and when to make exceptions to policies.
This decision process could be something like: “because Morgan is analyzing employee attrition and retention, they should be able to see employee satisfaction survey data.” Notice it is not “because Morgan is HR, they should be able to see employee satisfaction survey data.” It’s not who Morgan is, but what Morgan is doing that should allow them heightened access. The purpose for data access drives the policy decision and can be approved objectively because you are not approving who can see data, but what can be done with it. However, if Morgan has to ask permission every time there is a new survey, this becomes a subjective and time-consuming process for the organization.
This is where purposes and purpose-based access control can help. Purposes allow you to define exceptions to rules as the purpose for which the user is acting. The key point here is you can define these purposes ahead of time, before any user actually tries to get an exception. Immuta projects are valuable not just for purpose-based access control, but because of the documentation trail they provide, the collaboration they allow, and the data access process they automate.
Additionally, to ensure that purposes are being used correctly and applied accurately, project purposes must be approved before the purpose is active in a project. That approver will see the lists of tables, the project members, and project documentation and decide if they want to approve it or not. This approval is recorded by Immuta, creating a documentation trail. After a purpose is approved within a project, any changes to the members or data sources will require the purpose to be re-approved, ensuring that the project continues to be compliant to an organization's requirements.
Purpose-based access control makes access decisions based on the purpose for which a given user or tool intends to use the data, which reduces risk and aligns with many privacy regulations, such as GDPR and CCPA. This method of data access also provides flexibility for you to override policies and grant access to unmasked data to an individual for a very specific reason, without time-consuming and ad hoc manual approvals.
Immuta recommends using to create exceptions to global data policies.
See this for instructions on how to implement purpose-based access control for your organization.