Authored by – Anush Kumaar C S
Introduction
For any data platform, data organization and security must be treated with utmost importance. While it is very important to maintain and manage data efficiently and accessibly, security is literally “the key” to provisioning the right level of access by enforcing the Principle of Least Privilege so that users will operate on their minimum limits and don’t end up giving surprises by sneaking without anyone’s knowledge.
Having said that, Snowflake, as a sophisticated data platform, treats security as if it’s a glorified empowerment to the platform users.
Many a time, customers who are willing to adapt and embark on the data journey with Snowflake wonder about the distribution of privileges and ponder questions like,
- What will the access pattern look like for an external stakeholder?
- How will Snowflake handle access isolations/segregations in a diverse workspace?
To solidify our understanding and also have these questions answered logically, let’s delve into a quick couple of concepts (or keywords, if you will) that can help us drop a seed of thought in our vast attempt to understand the Snowflake’s access control model and the interesting engineering behind it.
RBAC
Ring a bell?!! Yes, you got it right!
Role-based Access Control is an authorization framework in Snowflake that enables the administrator(s) to limit or rather channel the right permission level in a variety of ways, either within an organization or, in some cases, between organizations, based on the following aspects.
- A person’s role(persona), or
- An application
Examples of some standard roles include Data Engineer, Manager or even a Data integration platform/application.
ABAC
Attribute-based Access Control is another authorization framework that evaluates an attribute or a combination of attributes associated with a person, instead of a job role, to execute the operations pertaining to the grants behind the curtains.
Examples of such common user attributes are position, department, security clearance, etc.
Let’s relate this example with an illustration.
User ‘Tony Stark‘, the ‘Manager‘ of the ‘IT‘ department is allowed ‘select‘ access on ‘Innovations Table in Org Database‘ as long as he has ‘security clearance’.
Roles
Roles are controlling factors that effectively enforce and drive the data, object and account access control for an entire organization and their associates(clients, stakeholders etc.).
There are 2 types of roles
- System roles (or Super roles) are roles with functional + extra privileges that are mostly forbidden or rather deliberately restricted for custom roles
- Custom roles are nothing but user-defined or user-created roles
Row-level security
For starters, row-level security (commonly known as RLS) in Snowflake is a concept that’s fulfilled by one of the key features of the ‘Row Access Policy‘.
This policy controls the accessibility of a selected dataset on any relational object(table or view) basis, a rule(policy definition) that evaluates the following.
- Current session role in Snowflake session
- filter condition(record selection criteria)
- other rules that can be set in a separate mapping table
In short, RLS is responsible for SoD(Segregation of Duties) and granular governance from an administration standpoint in a centralized or decentralized manner.
RBAC versus ABAC – a concept (reality) check
Having discussed and known enough about the essential components and features in Snowflake’s security framework, let’s digest the above concepts to zero in on the significance of RBAC and how we can demystify customers’ questions, by doing a simple & quick checklist.
- Is Snowflake allowing organizations to control the data access limits for any authorized personnel as long as they’re enrolled in the system?
- Is RLS powered by RBAC and more aligned to segregate the allowed data access operations?
- Is granular access granted also based on user attributes like department, location, and even the asset they’re wanting to access?
If the answer is “YES” to all the above questions, we can very well make an assumption that ABAC is conceptually bound into Snowflake’s security model.
Summary
Given the context of the provisioning of roles in Snowflake and the interrelationship that ABAC has with RBAC in the Snowflake platform, here is the directive.
RLS is driven by roles (and their privileges) that govern the access pattern and Segregation of Duties of authorized individuals on relational assets. With this understanding, the above “assumption” transforms to the conclusion that ABAC is implicitly baked into the platform’s authorization framework, thus making RBAC the smart access control model in Snowflake.
Abbreviations & acronyms:
RBAC – Role-based Access Control
ABAC – Attribute-based Access Control
RLS – Row-level Security
SoD – Segregation of Duties
PoLP – Principle of Least Privilege
