Secure your Snowflake surface
Role hierarchy that grants more than it appears, masking policy coverage, and access history as evidence. We don’t connect to Snowflake to collect evidence for its own sake — we connect to secure it, and the compliance artefacts follow from that work.
Book a Demo[01] What This Surface Exposes
Where Snowflake goes wrong
Snowflake goes wrong through deep role hierarchies: inherited grants routinely exceed what any individual role name implies.
- Role hierarchies where inherited grants exceed what any single role suggests
- ACCOUNTADMIN used for routine work rather than reserved
- Masking and row access policies absent on columns holding personal data
- Shares exposing data to external accounts without review
- Network policies absent, permitting access from anywhere
[02] What We Secure
What we watch, catch and fix on Snowflake
On Snowflake we flatten the role hierarchy into effective access per user, since inheritance here is deep and easy to misjudge.
- Role hierarchy flattened to effective access per user, since inheritance here is deep and easy to misjudge
- ACCOUNTADMIN usage monitored as standing privilege
- Masking policy coverage measured against classified columns rather than assumed
- Outbound share inventory reviewed as data transfer
- Network policy enforcement verified
[03] Where It Lands
Where Snowflake lands in your registers
Every datastore becomes an asset register entry carrying its data classification, encryption state, and retention position. Access reviews cover database roles and grants alongside application access. The risk register maps each store to the specific exposure it represents — a production replica in a development environment is a named risk against a named asset, with an owner and a date.
[04] How We Engage
On Snowflake specifically
On Snowflake, we apply masking policies, tighten network policies, and reduce ACCOUNTADMIN usage. Role hierarchy redesign we project-manage with your data team given the breadth of impact.
Platform licence
Everything you need to find and fix it yourself, with no ceiling on the depth of the answer.
- Every connected tool monitored for misconfiguration and drift, with findings mapped to the assets and risks they affect
- Remediation guidance that tells you what is wrong and exactly how to fix it — however deep or awkward the issue is. We are engineers running a security company, so the answer is the real one, not a link to vendor documentation
- Assets, access reviews, and risk register populated from the tools themselves rather than from spreadsheets
- Unlimited integrations and unlimited users, with anything missing built within two weeks
Managed service
Every tool you connect through Konfirmity comes under our care, with our team doing the work.
- Continuous misconfiguration and drift monitoring across every connected tool, watched by our analysts rather than by a dashboard waiting for you
- Incident response led by us, with containment coordinated with your team
- Remediation performed directly wherever you have granted us the authority to act — and where we cannot act, we project-manage the fix to completion rather than handing you a ticket
- Decision support on the tools themselves: where something is failing you on capability or costing more than it returns, we will tell you, and help you replace it
[05] Snowflake FAQs
What Snowflake access does Konfirmity need?
Konfirmity needs a dedicated role with USAGE on the account and read access to the ACCOUNT_USAGE schema. That covers role hierarchy, masking policy coverage, network policy and access history without querying your data.
Do you check masking policy coverage?
Yes, against classified columns rather than assuming policies are applied. A masking policy that exists but is not attached to the columns holding personal data protects nothing, and that gap is invisible unless coverage is measured directly.
PostgreSQL
MySQL
MongoDB
Databricks
Google BigQuery