Data access that follows your identity provider, down to the row.
Left alone, a warehouse fills up with grants made by hand to individual people. We replace that with roles, masking and row-level policies in Snowflake and Unity Catalog, provisioned from Okta or Entra ID groups and requested through your identity governance process.
Identity providerOkta · Entra ID groupsAccess requests and reviewsSailPoint · Saviynt
02 · Provisioning
SCIM provisioningusers · groupsGrants and policies as codeTerraform
03 · Data platform
Snowflake rolesfunctional and access rolesUnity Catalogcatalog and schema privilegesMasking and row policiestags · column masks · row filters
04 · Evidence
Audit queriesaccess history · grants
SnowflakeDatabricksOktaMicrosoft Entra ID
in short·15-second read
Data governance decides who can see which data, how it is classified, and how that is proven to auditors.
Cohash designs access control in Snowflake and Databricks Unity Catalog, tied to your identity provider. We provision users and groups from Okta or Entra ID through SCIM or Databricks automatic identity management, and apply masking and row-level policies driven by tags and group membership.
you probably need this if
Grants in Snowflake or Databricks were made to individual users and nobody ever took them away.
PII and PHI columns are masked in one table and visible in its copy.
Auditors ask who can see member data and the answer takes a week of queries.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Data Governance & Access, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · data governance & access3 open
openGrants in Snowflake or Databricks were made to individual users and nobody ever took them away.
recurringPII and PHI columns are masked in one table and visible in its copy.
blockedAuditors ask who can see member data and the answer takes a week of queries.
exposure
Identity provider integrationRole and privilege designMasking and row-level securityClassification and taggingAccess requests and reviewsService principals and agents
startrehearsehandover
Assess
Design
Implement
Prove and maintain
we are here
ready to hand over
The workspaces share one Unity Catalog metastore.
New columns are covered once tagged, and the CI check catches the ones that aren't.
Role and privilege model for Snowflake or Unity Catalog
Identity provider provisioning configuration
chapter 01 · where it hurts
Why teams reach out
Grants in Snowflake or Databricks were made to individual users and nobody ever took them away.
PII and PHI columns are masked in one table and visible in its copy.
Auditors ask who can see member data and the answer takes a week of queries.
chapter 02 · what we change
How we solve it
Identity provider integration
Role and privilege design
Masking and row-level security
Classification and tagging
Access requests and reviews
Service principals and agents
chapter 03 · how it runs
Our approach
Assess
Design
Implement
Prove and maintain
chapter 04 · where you end up
What changes
The workspaces share one Unity Catalog metastore.
New columns are covered once tagged, and the CI check catches the ones that aren't.
Role and privilege model for Snowflake or Unity Catalog
Identity provider provisioning configuration
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
We set up Snowflake SCIM from Okta or Entra ID, so each pushed group maps to a Snowflake role. On Databricks we use automatic identity management or SCIM, with nested Entra groups where supported.
We split functional from access roles in Snowflake and use catalog and schema privileges in Unity Catalog. Direct grants to individual users are off the table.
In Snowflake we use masking and row access policies. In Unity Catalog it's row filters and column masks, including attribute-based policies that key off governed tags.
Sensitive columns such as PII and PHI found and tagged, so policies apply to every table carrying the tag rather than one table at a time.
People request data access in SailPoint, Saviynt or Entra ID Governance, and certify it there too. The warehouse role is what they're requesting.
We give pipelines, BI tools and AI agents their own scoped roles, rotate their credentials and audit how they're used.
capability 01 / 06in production
Identity provider integration
We set up Snowflake SCIM from Okta or Entra ID, so each pushed group maps to a Snowflake role. On Databricks we use automatic identity management or SCIM, with nested Entra groups where supported.
We split functional from access roles in Snowflake and use catalog and schema privileges in Unity Catalog. Direct grants to individual users are off the table.
In Snowflake we use masking and row access policies. In Unity Catalog it's row filters and column masks, including attribute-based policies that key off governed tags.
We pieced these together from Data Governance & Access situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Databricks workspaces still on the Hive metastore with legacy table ACLs
composite · not a client story
Beforethe situation
Three Databricks workspaces still use their own Hive metastores. Some clusters run legacy table access control, data sits in the DBFS root, and groups were created locally in each workspace instead of synced from Entra ID.
What we dothe work
We run the UCX assessment workflow to inventory tables, mounts, clusters and groups. Workspace-local groups become account groups fed from Entra ID. External tables are upgraded with SYNC, DBFS-root data moves to governed storage, and grants get rewritten as Unity Catalog privileges in Terraform.
Afterwhere you end up
The workspaces share one Unity Catalog metastore. Groups come from Entra ID, grants live in code, and lineage and audit logs cover the migrated tables.
case file 02
Snowflake PII masked column by column, and new columns slipping through
composite · not a client story
Beforethe situation
A security team wrote masking policies for the PII columns they knew about two years ago. New tables arrive from dbt every week and nobody applies the policies, so a recent scan found unmasked national ID numbers in a staging schema.
What we dothe work
A short list of sensitivity tags, with masking policies attached to the tags. Tag a schema or table and the matching columns are covered. dbt sets the tags in model config, CI fails builds that add untagged PII-looking columns, and row access policies take care of regions.
Afterwhere you end up
New columns are covered once tagged, and the CI check catches the ones that aren't. Masking rules live in a few policies instead of hundreds of column assignments.
How identity provider groups become warehouse roles and policies
Okta or Entra ID pushes users and groups to Snowflake through SCIM and to Databricks through automatic identity management or SCIM. Groups map to roles and Unity Catalog privileges, while tag-driven masking and row policies decide what each role sees.
01 · Identity
Identity providerOkta · Entra ID groups → SCIM provisioning · SCIM groups
Access requests and reviewsSailPoint · Saviynt → Identity provider · approved group
02 · Provisioning
SCIM provisioningusers · groups → Snowflake roles · group to role→ Unity Catalog · account groups
Grants and policies as codeTerraform → Masking and row policies · deploy policies
03 · Data platform
Snowflake rolesfunctional and access roles → Audit queries · access history
Unity Catalogcatalog and schema privileges
Masking and row policiestags · column masks · row filters → Snowflake roles · masking and row access→ Unity Catalog · row filters and masks
04 · Evidence
Audit queriesaccess history · grants → Access requests and reviews · review evidence
Read the diagram as text
Access requests and reviews → Identity provider: approved group
Identity provider → SCIM provisioning: SCIM groups
SCIM provisioning → Snowflake roles: group to role
SCIM provisioning → Unity Catalog: account groups
Grants and policies as code → Masking and row policies: deploy policies
Masking and row policies → Snowflake roles: masking and row access
Masking and row policies → Unity Catalog: row filters and masks
Snowflake roles → Audit queries: access history
Audit queries → Access requests and reviews: review evidence
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Assess
Current roles, grants, sensitive data and identity provider setup reviewed, including grants made directly to users.
step 02
Design
Nothing gets built until data owners, security and IAM have agreed the role model, tag taxonomy, policy design and provisioning approach.
step 03
Implement
Provisioning, roles and policies deployed as code with Terraform, and tested with user personas.
step 04
Prove and maintain
Audit queries, access review campaigns, and runbooks so the next new data set isn't onboarded from scratch.
you keep
What you're left with
We write these for your Data Governance & Access setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
inventory01
Role and privilege model for Snowflake or Unity Catalog
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
00:0006:0012:0018:0000:00
roles we staff
Data governance lead
Data steward
Data access engineer (Unity Catalog, Snowflake RBAC)
Data quality engineer
Privacy analyst
due diligence · data governance & access
Questions to ask any partner, including us.
Put these to anyone bidding on your Data Governance & Access work. The ones who've done it answer differently from the ones who've read about it.
Q1
How will you find every grant made directly to a user instead of a role?
Direct grants skip the role model and outlive job changes. Snowflake's account usage views and Unity Catalog's information schema will list them. If a partner doesn't start there, ask why.
Q2
Will masking follow tags, or be attached column by column?
Masking assigned column by column misses every new table. With tag-based masking in Snowflake, or governed tags and ABAC in Unity Catalog, one policy picks up columns as they arrive.
Q3
Once this is live, how does a data access request reach our IGA platform and its certification campaigns?
If warehouse roles aren't visible to SailPoint or Saviynt, they drop out of access reviews. Auditors notice that gap quickly.
Q4
Which service principals and AI agents can read sensitive data today, and who owns each?
Pipelines, BI service accounts and new agents often hold broad read access with no named owner. They need the same review that people get.
Q5
With Entra ID and Databricks, are you going with automatic identity management or SCIM, and what's the reasoning?
Databricks says not to mix them for the same identities. Pick one and you've also picked how nested groups, cross-tenant directories and provisioning errors behave.
01Do we need SCIM for Databricks if we use Entra ID?
Not always. Microsoft documents that Azure Databricks automatic identity management syncs users, service principals and groups from Entra ID, including nested groups, and is on by default for accounts created after 1 August 2025. SCIM is still needed for some setups, such as cross-tenant directories. Databricks advises against mixing the two for the same identities.
02Can Snowflake roles come from Okta groups?
It does. Okta and Microsoft Entra ID can both provision Snowflake over SCIM, and each pushed group turns into a role. The role hierarchy and privileges inside Snowflake still need designing.
03Are Unity Catalog attribute-based policies ready for production?
Some of it. Databricks announced general availability for ABAC row filter and column mask policies, governed tags and data classification. The rest of ABAC was still beta last time we checked. Check your compute first. Policies need Databricks Runtime 16.4 or above, or serverless.
04Do you also cover data catalogs and lineage?
Yes, as part of governance. We usually start with the platform's own catalog and lineage, in Unity Catalog or Snowflake, and add a separate catalog tool only when you need one across platforms.
05Do tag-based masking and row access policies need a particular Snowflake edition?
Yes. Both need Enterprise Edition or higher. On Standard, the usual fallback is secure views that filter and mask, which work but are harder to maintain. If governance is a priority, we price the edition change alongside the design.
related
Often paired with
Projects on Data Governance & Access usually end up touching one of these, so they're worth a look.
