Identity security & governance for Snowflake
Snowflake roles inherit from other roles, making effective data warehouse access invisible to IGA tools that stop at the identity provider. Oleria unifies users, role hierarchies, grants, and query history into a continuous identity security graph without reading your table data.
.png){kind=small}
Key Takeaways
- Snowflake roles inherit from other roles, making effective access to data warehouse tables and schemas invisible without graph traversal, a structural gap that legacy IGA tools checking only the identity provider cannot address.
- Service accounts feeding data pipelines accumulate role grants over time without expiration or review cycles, and custom roles granted to other custom roles create inheritance chains that obscure the true privilege surface of every Snowflake identity.
- Oleria unifies Snowflake users, role hierarchies, grants, and Query History activity into a continuous identity security graph without reading table data, showing which users and service accounts have exercised specific data warehouse permissions and which have not.
- Continuous Snowflake access certification through Oleria identifies dormant role memberships, over-privileged pipeline service accounts, and inherited permissions that exceed current business requirements, enabling targeted least-privilege remediation across the data warehouse.
This summary was created with AI and reviewed by an editor.
Ask AI to write a summary
Featured event: A CISO’s take
Join Jim Alkove and Ramy Houssaini to learn how forward-thinking security teams are addressing Enterprise AI Copilot risks.
See who can really query your data warehouse
Oleria's Snowflake integration gives security teams one view of who can access Snowflake data, how they got that access, and whether they use it. It brings Snowflake identity governance to users, role hierarchies and the service accounts that feed your pipelines.
In Snowflake, roles inherit from other roles, so access is rarely what it looks like on paper. Oleria unifies users, roles, grants and audit history in a continuous identity security graph, without reading your table data.
Why is Snowflake access so hard to govern?
Legacy identity governance and administration (IGA) tools only check provisioning at the identity provider (IdP). They miss how privileges inherit inside Snowflake.
- Roles hide inside roles. Custom roles granted to other roles build multi-tier trees, so true access to sensitive tables is hard to calculate.
- Top-level admin spreads. Unmonitored ACCOUNTADMIN grants create standing privilege and sidestep normal change controls.
- Service accounts carry too much. ETL and pipeline accounts often run with wide SYSADMIN rights and static passwords instead of key pairs.
- Broad grants expose sensitive records. ALL PRIVILEGES on a database or schema can open financial, PII or customer data to whole teams.
What Oleria shows you in Snowflake
How security teams use Oleria with Snowflake
- Stop ACCOUNTADMIN escalation. Track who holds and uses Snowflake's most powerful system roles in real time, and enforce admin guardrails.
- Find who can reach sensitive tables. Unroll role hierarchies to see which identities can read, write or administer sensitive tables and schemas.
- Tighten service accounts. Spot ETL identities with unrotated key pairs or excessive default roles.
- Right-size unused privilege. Compare role privileges with query history and flag permissions unused for 30, 60 or 90 days.
How does Oleria connect to Snowflake?
Oleria connects through a service account using RSA key-pair authentication and a dedicated Oleria role. It gets read-only metadata access, such as ACCOUNT_USAGE views, to inspect users, roles, grants and audit history without touching raw table content. Oleria takes a full snapshot of users, role hierarchies and object grants, then syncs changes continuously. Explore the complete Oleria Snowflake integration guide.
Snowflake identity governance FAQs
What is Snowflake identity governance?
Snowflake identity governance is the practice of controlling who can access data in Snowflake, and proving that access is appropriate. Oleria supports it by unrolling role hierarchies to each user and service account, comparing granted privileges with query history, and flagging access that is excessive, risky or unused.
Does Oleria need access to the data in my Snowflake tables?
No. Oleria only reads Snowflake system metadata views, such as ACCOUNT_USAGE and INFORMATION_SCHEMA, to analyze access controls, roles and grants. Oleria never reads underlying table content, so sensitive records stay where they are while security teams still get a complete picture of who can reach them.
How does Oleria resolve nested custom roles in Snowflake?
Oleria automatically unrolls multi-tier Snowflake role inheritance trees and evaluates object-level privilege grants at each level. The result is true effective access for every human and service account identity, so security teams can see who can actually query a sensitive table, not just which role was granted.
Can Oleria audit Snowflake service accounts and integration users?
Yes. Oleria discovers all programmatic Snowflake service accounts and integration users, tracks their default role assignments, and checks whether key-pair authentication is properly enforced. Security teams can then find pipeline accounts with excessive roles or static passwords and disable over-privileged service users from Oleria.
Ready to see who can really query your Snowflake data? Book a demo.
