In the past decade, Snowflake has grown to become the default solution for storing and querying enterprise data. Together, Snowflake’s ten thousand customers run more than five billion queries every single day. If you’re among those ten thousand, Snowflake is probably your single largest repository of sensitive data, from customer behavior, to PII, to payment info. As more and more services build on top of the data warehouse, managing access to that data only gets harder to scale.
With over half of data breaches involving credentials, the most important action you can take to secure your Snowflake data is to establish tight access control and to apply the principle of least privilege to users and roles in Snowflake. However, most organizations struggle to achieve this. They have no idea who really has access to what data in Snowflake, or whether that access is being used. Let’s look at why this is, and how Veza can help restore visibility to permissions in Snowflake.
Why you don’t have visibility into permissions in Snowflake today
Organizations attempting to adhere to the principle of least privilege and follow identity security best practices in Snowflake are confronted by a fundamental lack of visibility into access at the object level, such as to specific tables, views, or schemas. In other words, they don’t really know who can perform what action on what data in Snowflake. And if you can’t see who has what privileges, you can’t hope to meaningfully apply the principle of least privilege. This lack of visibility into access in Snowflake is driven by four key challenges.
Complexity
In some ways, Snowflake’s system of role-based access control (RBAC) may seem straightforward: each user can be allocated one or more roles, each of which confers a set of privileges to act on objects in Snowflake. However, actually applying RBAC to manage access to data in Snowflake at scale can be complicated in practice for several reasons:
- Snowflake supports more than fifty distinct types of privilege, and over a dozen object types. Understanding even simple privilege statements in Snowflake require specific and extensive expertise in Snowflake’s access model.
- Users can be assigned more than one role, and any two roles can overlap significantly in the privileges they grant.
- Roles are hierarchical: that is, role A can be granted to B, and role B can be granted to role C. So any user assigned role C will also have all the privileges of roles A and B. Role hierarchies make it easier for a user to acquire extensive privileges quickly, without the person assigning a role being aware of how much access they’re actually granting.
- Accidentally nesting a highly-privileged role, like SYSADMIN, under a role with a safe-sounding name like MARKETING can spread dangerous privileges to many identities. These kinds of mistakes are difficult to discover and often remain undetected until they permit access to an attacker.
Scale
Both the amount of data and the breadth of use cases supported by the Data Cloud means that security and governance teams are managing many more identities with access to many more resources than was normal in the on-prem era. An enterprise Snowflake deployment might include thousands of users, with access to hundreds of thousands of tables, schemas and views. The old paradigms for securing access, like the manual quarterly access review, simply can’t keep up with the scale of the modern data warehouse. This is only becoming more true as non-human identities proliferate to outnumber their human counterparts 17:1.
Siloed access data
Most organizations manage access to the Data Cloud via an Identity Provider (IdP) like Okta or Azure AD. For example, it’s common for multiple users in the IdP to share access to a single local User in Snowflake. This makes it hard to determine who really has access to what in Snowflake. Teams granting access to Snowflake in the IdP don’t know what access they are really giving users at the object level. Meanwhile admins in Snowflake looking at the permissions of a local role or user don’t know how many federated identities get those permissions or how many would be affected by a change.
Team enablement
One of the most significant challenges in maintaining least privilege in Snowflake isn’t directly related to Snowflake’s access control system at all. It’s simply that, in a fast-paced working environment, IAM teams are under pressure to enable teams that depend on access to the Data Cloud for their work. This focus on enablement has two important consequences:
- The need to grant access needed today will always be more urgent than the need to remove access no longer needed, leading to a tendency for identities to accumulate privileges over time.
- Tight timeframes for granting access may prevent IAM teams from taking the necessary time to find the most privilege-efficient way to meet an access request, or even from fully understanding what the outcome of granting a new role will be at the object level,
The cost of not knowing who has access to what in Snowflake
The challenges discussed above make it difficult to maintain best practices and least privilege in Snowflake. This can lead to a number of significant risks.
Ransomware attacks and data breaches
The most obvious consequence of failing to maintain least privilege is that an over-privileged identity may be compromised by attackers, leading to a ransomware attack or a public breach of sensitive data. The consequences of such an attack can be dire, with major ransomware attacks now costing north of a billion dollars. Beyond the direct monetary cost, organizations often take a severe reputational hit when a breach becomes known, leading to customer churn, falling stock prices and loss of new business opportunities.
Compliance failures
Insufficient access control measures can also lead to regulatory consequences, such as failing an audit under a compliance framework like Sarbanes Oxley. Again, the impact of such a failure includes not just the monetary expense of getting back into compliance, but also the reputational cost of being seen to have failed in your obligation to protect user’s data.
Technical debt
On the one hand, the complexity and scale of managing access make it hard for IAM teams to know what they’re doing. On the other, the need to enable stakeholders pressures IAM teams to respond to access requests fast. Put these two problems together and you create ideal conditions for half-measures and workarounds that create technical debt. For example, take the problem of role sprawl:
A large enterprise might have 500 local Snowflake roles. When a user asks for access to a particular object, like the CUSTOMER table, it’s difficult to choose a role that will both give the access required, and also not grant a lot of access to assets the user doesn’t need. Without being able to understand the outcome of granting any of the 500 available roles, the simplest options are either to grant access to a highly privileged role, leading to excess privilege, or to create the 501st local role, making the problem even harder to solve next time. Over the course of years, organizations can end up with hundreds of roles used by few or no identities, and thousands of users with privileges that they never use.
Excess spend
For many organizations, Snowflake is one of the largest line items in their budget. Beyond the security and compliance costs of failing to apply least privilege, there is also a potentially huge dollar cost. Each dormant identity and each unused data object represents wasted spend.
In addition, the cost of compliance with any relevant regulatory frameworks is greatly increased by the need for slow, manual processes based on vague or fallible information, like local role names.
How Veza can Help
Access Visibility: Who has access to what in Snowflake?
Veza is powered by its Access Graph, which gives organizations the ability to visualize access relationships between all identities and systems by connecting users, groups, roles, and permissions. This means that you can truly know who has access to what in Snowflake. For example, below you can see Veza’s visualization of all identities with access to the CUSTOMER table in Snowflake, including both local users and federated identities in Okta. Veza shows not just who has access, but what kind of access—create, read, update, and delete—and how they have it, including showing the effect of role hierarchies.
This complete visibility at the object level allows you to:
- Find unintended access to sensitive data in Snowflake
- Diagnose and fix the cause of unintended access
- Reveal misconfigurations like Users without MFA enabled with access to sensitive data
Access Reviews
Veza’s Access Graph lets you know the full permissions of any identity on all data objects in Snowflake. This means that Veza can make your compliance simpler, cheaper, and more robust. Veza’s Access Reviews product can automatically compile, schedule and assign access reviews based on the granular permissions of users. Decision makers have access to all the context shown by the access graph, to help them make the right decision. Meanwhile, integration with your ITSM tools like Jira and ServiceNow allow you to automate follow-ups to make sure that rejected access is actually removed.
Activity Monitoring
The Principle of Least Privilege states that any identity should have only the privileges it needs to do its work. For identity teams this poses the challenge of knowing which privileges are needed and which are not. A good start would be to know if an identity is actually using the privileges it has. With Activity Monitoring, Veza compares the access an identity or role is permitted to have to tables, schemas and views in Snowflake to the access it actually uses over a period of time. This comparison is expressed in the form of an Over-Provisioned Access Score (OPAS). For example, an identity with access to 10 tables, that has only actually used 3 tables in the last 30 days, would have an OPAS of 70%.
In practice, Veza has found that almost all Snowflake users have an OPAS of higher than 80%. This means that by identifying unused access, Activity Monitoring has the potential to help you reduce the total amount of privileges in Snowflake by up to 80%, making it the biggest single action you can take to make least privilege a reality in your organization.
Role Insights & Role Mining
The visibility into granular permissions provided by Veza’s Access Graph empowers you to restore RBAC best practices and role hygiene in your Snowflake Data Cloud. With a wide range of out-of-the-box insights and the ability to create your own custom queries, Veza’s role mining capabilities allow you to:
- Remove roles that are dormant, duplicative, or used by only a few identities.
- Split up overly generic roles with too many users into more targeted and less privileged roles.
- Identify and untangle complex role hierarchies with multiple layers of inheritance
- Easily right-size over-permissioned roles by referencing activity monitoring data.
- Triage roles for review by identifying roles with a high blast radius (access to a high proportion of your total schema) or powerful privileges like write and delete.
Role Recommendations
Once you’ve cleaned up your RBAC and weeded out dormant, duplicative and excessively permissioned roles, Veza’s role recommendation tool gives you an easy way to apply the principle of least privilege to respond to access requests going forward.
Let’s say Adam requests read access to the CUSTOMER table in Snowflake. Veza analyzes all available Snowflake roles and recommends the role that grants Adam the access he needs, while adding the smallest possible number of new resources. Instead of being blind to the true amount of access they’re granting, your IAM teams can be confident that they are enabling their stakeholders fast while also following the least privilege.
The Veza Advantage
Securing your sensitive data in Snowflake means establishing meaningful access controls, and you can’t do that if you are blind to permissions—to who can take what action on what data. With the power of Veza’s Access Graph behind you, you can:
- Remove the risk created by excess privilege and misconfigured identities.
- Ace your compliance obligations, while spending less time and money on manual reviews.
- Empower your teams with the access they need, when they need it.\
