Identity and access management (IAM) systems have become essential components of organizational workflows, allowing users to access the appropriate tools without requiring admin privileges. But when it comes to data access control, organizations are often left wondering why the user information stored in their IAM software can’t also be leveraged to manage access to data. Why does the user identification that gets them into systems and platforms not automatically extend to data sources and tables?
Barriers to Integrated Identity and Access Management
Organizations adopt SSO identity platforms like Okta for their centralized authorization patterns, which make granting access to resources and applications easier than ever. However, finding a way to use Okta to control data access in cloud warehouse platforms such as Snowflake and Databricks often leads to a dead end. Why?
It comes down to a disconnect between the IAM platform and the cloud data platforms. For example, Snowflake leverages roles and grants to control access to tables in a Snowflake account. However, those roles are not tied to Okta groups or attributes, so the user information in the two platforms exists in silos.
As a result, data platform teams must manually manage access through each individual platform – and since modern data stacks typically consist of multiple cloud data platforms, this task is exceedingly tedious and inefficient. Writing new code for each new user and data source can be an hours-long job that diminishes data engineering productivity and delays time to data access and insights.
Why Dynamic Data Policies are Key to Identity and Access Management
Incorporating identity management into data platforms’ access control decisions requires a dynamic approach that can scale across platforms. The most streamlined solution is to adopt a data security platform like Immuta, which abstracts policy from platform and leverages user attributes to automate policy enforcement.
Immuta’s attribute-based access control (ABAC) enables data platform teams to define data entitlement rules based entirely on groups and/or attributes that have been applied in Okta. This means access can be granted to certain tables in Snowflake or Databricks only if the user is a member of a particular Okta group or possesses a certain attribute. The attribute metadata considered by an ABAC model can range from the user’s department or intended action, to the data’s level of sensitivity or date of access.
By separating policy from platform, Immuta acts as an invisible layer that integrates with Okta and cloud data platforms like Snowflake or Databricks for consistent, automated data policy enforcement. Let’s take a step-by-step look at how this works.
Enforcing Automated Identity and Access Management Across Platforms
Integrating identity and access management across platforms starts with integrating Immuta and our IAM, which is Okta in this case. Once that’s complete, we’ll build a single Immuta Subscription Policy to automatically grant access to data in Snowflake and Databricks using the Okta Group/Attribute assignment. Here’s how:
First, we’ll log into our Okta instance and build a new application to be associated with Immuta.
Next we’ll connect Immuta to this Okta application from the Immuta UI.
Now that Okta and Immuta are integrated, we can log into Immuta via our Okta account to view data sources that we’re assigned to.
The next step is to build an Immuta Subscription Policy to grant appropriate access based on Okta group membership.
Let’s say we want to allow users that are members of the “Sales Team West” group in Okta to have access to data in Snowflake and Databricks that has been identified and tagged as “Sales Data.”
First, we’ll classify and tag only the tables in Databricks and Snowflake that are considered “Sales Data.” This tag will allow an Immuta policy to automatically grant access to these tables as soon as the Okta group condition is met.
Next, we’ll put Okta users into the “Sales Team West” group.
Finally, we’ll build the single Immuta Subscription Policy that will grant access to the appropriate data based on the Okta group membership.
To quickly validate that members from the “Sales Team West” group only have access to data previously tagged as “Sales Data,” we can log into Immuta as an Okta user.
As we’ll see, the Okta user is appropriately subscribed to the data that they are authorized to see. Immuta’s dynamic ABAC capabilities allow us to enforce this policy across platforms without having to recreate new policies for individual roles, data platforms, and data sources.
Conclusion
Using Immuta with Okta to govern access to data can greatly reduce the time to data access, so data teams can maximize their data’s value and the ROI of their cloud platforms. The Immuta Subscription Policy is designed to be a “set it and forget it policy,” so the only required updates will be adding users to their associated Okta group. From there, Immuta handles the entire access policy orchestration into your existing cloud warehouse.
