Snowflake Roles 101: Guia Completo de Controle de Acesso

O Snowflake adota uma abordagem de Role-Based Access Control (RBAC) para gerenciar o que usuários e outros sistemas podem acessar e fazer. No RBAC, ter um determinado role significa receber determinados privilégios.

Vamos alinhar a terminologia:

• User — entidade que permite que uma pessoa (ou serviço) se conecte ao Snowflake.
• Object — entidade que um User pode acessar (ex.: tabela, view, database), desde que tenha os privilégios certos.
• Privilege — operação que um User pode executar em um Object, caso o seu Role tenha recebido esse privilégio.
• Role — entidade que faz a ponte entre Users e Privileges. Privileges são concedidos a Roles, e Roles são concedidos a Users.

Em resumo, como o próprio Snowflake coloca:

Privilégios são concedidos a roles, e roles são concedidos a usuários, para especificar as operações que os usuários podem executar nos objetos do sistema.

A partir desses 4 conceitos-chave, as seções e os diagramas a seguir vão se complementando — até chegarmos a uma configuração de controle de acesso mínima, porém completa.

Users

Um Snowflake User é uma identidade que se conecta a uma Snowflake Account e executa um conjunto de operações permitidas. Cada pessoa do seu time de dados deve ter um Snowflake User próprio para se conectar e rodar queries. Um Snowflake User também pode ser usado por um sistema de terceiros — por exemplo, ferramentas de BI (como Tableau ou Looker) ou de ELT (como Stitch ou Fivetran).

No fim das contas, o que os Snowflake Users podem fazer é o foco central do controle de acesso.

Objects

Objects são as primitivas do Snowflake às quais se pode conceder acesso. Os exemplos mais óbvios são databases, schemas e tabelas, mas também entram objetos no nível da conta, como warehouses, storage integrations etc.

Veja alguns exemplos comuns de Objects no Snowflake:

Securable Object	Nível	Descrição
Database	Account-level	Databases são os objetos que mantêm todos os demais securable objects isolados e logicamente agrupados.
Schema	Database-level	Um agrupamento lógico de objetos como tabelas, views, stages etc.
Table	Schema-level	Objeto que contém os dados e ocupa armazenamento físico. Na maior parte dos casos, as tabelas são a peça-chave que faz o Snowflake ser útil. Existem alguns tipos de tabelas, cada um para um caso de uso diferente.
View	Schema-level	Uma tabela disfarçada. Dá acesso aos dados, mas não ocupa armazenamento de fato. Uma view é definida como uma query sobre outras tabelas. Existem alguns tipos de views, cada um para um caso de uso diferente.
Virtual Warehouse	Account-level	Principais recursos computacionais necessários para executar queries ou carregar dados no Snowflake.
Storage Integration	Account-level	Objeto que conecta um bucket do S3 (e também GCS e Azure Blob storage) ao Snowflake, permitindo que Users carreguem dados para o Snowflake, descarreguem deles ou consultem o conteúdo do bucket diretamente.
Snowpipe	Schema-level	Objeto que automatiza o carregamento de dados do S3 (ou GCS e Azure Blob storage) em tabelas assim que novos arquivos chegam ao bucket.
Stage	Schema-level	Local dos arquivos de dados (CSV, Parquet etc.) no cloud storage. Existem dois tipos de stages: internos (cloud storage gerenciado pelo Snowflake) e externos (cloud storage autogerenciado).

Privileges

Privileges são um conceito essencial do controle de acesso. Eles permitem executar uma operação específica — ou, às vezes, um conjunto de operações — em um objeto.

Por exemplo, em uma tabela do Snowflake, um User pode ter o privilégio de executar SELECT nos dados, INSERT de linhas, DELETE de dados etc. Em um Database do Snowflake, um User pode executar CREATE SCHEMA ou MONITOR.

A tabela abaixo descreve rapidamente alguns dos principais privilégios que podem ser concedidos aos principais objetos.

Object	Object Privilege	Descrição
Database	USAGE	Permite usar e visualizar o database, mas são necessários privilégios adicionais para executar qualquer ação sobre ele.
	MONITOR	Permite executar o comando DESCRIBE.
	CREATE SCHEMA	Permite criar (ou clonar) um schema no database.
	IMPORTED PRIVILEGES	Aplica-se apenas a databases compartilhados e permite que outras account roles acessem os objetos compartilhados. Para saber mais sobre imported privileges, veja https://docs.snowflake.com/en/user-guide/data-share-consumers#option-1-objects-in-a-share-not-associated-with-a-database-role.
Schema	USAGE	Permite ver e usar o schema, mas ainda exige privilégios adicionais sobre objetos no nível do schema para visualizá-los ou executar comandos sobre eles.
	MONITOR	Permite executar o comando DESCRIBE.
	CREATE TABLE / CREATE VIEW / CREATE STAGE / CREATE PIPE	/ CREATE STAGE / CREATE PIPE Permite criar uma table / view / stage / pipe no schema.
Table	SELECT	Permite consultar a tabela para recuperar dados.
	INSERT	Permite inserir linhas na tabela.
	UPDATE	Permite atualizar dados existentes na tabela.
	TRUNCATE	Permite apagar todos os dados da tabela.
	DELETE	Permite apagar todas as linhas ou um subconjunto específico delas na tabela.
View	SELECT	Permite consultar a view para recuperar dados (independentemente das tabelas subjacentes e dos privilégios concedidos sobre elas).
Stage	USAGE	Permite usar o external stage em um comando SQL.
	READ	Permite executar qualquer comando que leia do internal stage. (GET, LIST, COPY INTO)
	WRITE	Permite executar qualquer comando que escreva no internal stage. (PUT, REMOVE, COPY INTO)

A lista completa de object privileges disponíveis para o controle de acesso no Snowflake está aqui.

Com essa lista em mente, vale lembrar — na hora de auditar acessos — que os privilégios são concedidos em níveis diferentes, dependendo de onde o objeto é criado (ou seja, account-level, database-level, schema-level).

Privilégio de Ownership

O Snowflake adota uma abordagem de Role-Based Access Control (RBAC) […]

👆A primeira frase desta seção era apenas parcialmente verdadeira. O Snowflake combina o RBAC com um conceito-chave de outro modelo de controle de acesso — o Discretionary Access Control (DAC). No DAC, todo objeto precisa ter um dono.

Na implementação de DAC do Snowflake, cada objeto pertence ao Role usado para criá-lo. Um Role ser dono de um objeto significa que ele tem o privilégio OWNERSHIP sobre esse objeto.

É importante entender que Users não são donos de objetos — Roles são. Se todos os Analysts do seu time de dados têm o mesmo Role, isso significa que os objetos criados por um Analyst serão de propriedade de todos os Analysts.

Vale notar que o privilégio OWNERSHIP sobre um objeto pode ser transferido para outro Role. Por exemplo, talvez você queira transferir a propriedade de uma tabela para um role "mais poderoso", para limitar quem pode conceder acesso a ela a outros roles.

Privilégios em objetos futuros

Às vezes, na configuração inicial do controle de acesso, alguns objetos ainda nem existem. Mesmo assim, você já sabe que vai querer que um determinado role tenha acesso a eles assim que forem criados. O Snowflake permite agir de forma proativa, concedendo certos privilégios em objetos futuros.

Por exemplo, um role ANALYST pode receber o privilégio SELECT em tabelas futuras do database GOLDEN_DB, ou em tabelas futuras de um schema específico. Veja esta documentação do Snowflake para saber mais sobre a precedência de grants em objetos futuros.

Roles

Pense nos roles do Snowflake como chaves. 🔑 Você tem uma chave de casa, outra do carro e talvez uma do escritório. Se você tem um vizinho próximo, pode ser que ele tenha uma cópia reserva da chave da sua casa (para emergências). As chaves da sua casa dão acesso a ela tanto para você quanto para o seu vizinho.

Do mesmo jeito, no Snowflake, um role concedido a um usuário dá a ele acesso a várias operações e objetos. Veja uma ilustração de como o nosso organograma poderia ser mapeado para Snowflake Roles.

No Snowflake, existem três tipos principais de Role:

• account roles
• database roles
• instance roles

Além desses, há também os application roles, ligados às Snowflake Native Applications — um tema bacana, que merece post próprio e foge ao escopo do Snowflake Roles 101.

Account Role

Os roles originais do Snowflake, os Account Roles, são os roles padrão que:

• podem receber privilégios em todos os securable objects da conta;
• têm nomes únicos no nível da Account; e
• podem ser concedidos a Users ou a outros Account Roles.

Database Role

Como o nome sugere, um Database Role está ligado a um Database específico e:

• só pode receber privilégios específicos dos objetos desse database (schemas, tabelas, views etc.);
• tem nome único dentro do Database em que foi criado;
• pode ser concedido a outros Database Roles (do mesmo Database) e a Account Roles;
• não pode ser concedido diretamente a Users; e
• recebe, por padrão, o privilégio USAGE sobre o seu database.

Instance Role

Os Instance Roles são o tipo de role menos utilizado. Eles estão ligados a uma Snowflake Class Instance, são concedidos a Account Roles e permitem que Users executem métodos da Class Instance.

Até o momento desta publicação, apenas o Snowflake pode criar Classes. Saiba mais sobre as Snowflake Classes disponíveis aqui.

Qual tipo de Role usar?

Se você está começando, os Account Roles vão te levar bem longe.

A coisa fica interessante quando você começa a pensar em database roles e no potencial deles para simplificar e padronizar a sua configuração, permitindo que o dono de um database gerencie os privilégios por conta própria, sem precisar do ACCOUNTADMIN.

Além disso, se você trabalha com Snowflake Shares para compartilhar seus dados, os database roles tornam o controle de acesso muito mais fácil de configurar.

Roles também podem ser concedidos a outros Roles — e é assim que se cria uma Hierarquia de Roles.

A forma mais simples de definir uma hierarquia de Roles é por meio de um exemplo. Na hierarquia abaixo, Splinter, com o role SYSADMIN, tem a soma dos privilégios dos roles DATA_ENG_ROLE, ANALYST_ROLE e DB_MANAGER_ROLE, enquanto Kim só tem os privilégios de DATA_ENG_ROLE e DB_MANAGER_ROLE.

Ao criar uma conta Snowflake e abrir Admin / Users & Roles, você verá um conjunto de roles que o Snowflake cria por padrão. Esses roles system-defined* não podem ser excluídos, nem é possível alterar o conjunto padrão de privilégios de cada um deles. Todos têm uma finalidade definida:

• ACCOUNTADMIN — o role no "modo deus", que pode fazer qualquer coisa no nível da conta. Tenha critério ao concedê-lo. Note que o role ACCOUNTADMIN herda todos os privilégios de SECURITYADMIN e SYSADMIN.
• SECURITYADMIN — esse role tem o privilégio de conta MANAGE GRANTS, o que permite conceder (ou revogar) grants em todos os objetos da conta para (ou de) outros roles. Note que o role SECURITYADMIN herda todos os privilégios repassados a ele pelo role USERADMIN.
• USERADMIN — como o nome sugere, esse role serve para criar e gerenciar usuários (com a ajuda dos privilégios de conta CREATE USER e CREATE ROLE).
• SYSADMIN — esse role pode criar todos os objetos da conta (incluindo databases, warehouses e outros objetos no nível do schema).
• PUBLIC — todos os usuários da conta recebem o role PUBLIC por padrão, mas, sem acesso explícito a objetos, ele não consegue fazer muita coisa. Ainda assim, muito cuidado para não conceder a ele, sem querer, privilégios sobre dados importantes — todos os usuários da conta poderiam acessá-los. Ou, melhor ainda, não conceda nenhum privilégio ao role PUBLIC. 😉

Por fim, o ORGADMIN merece atenção especial. Ele é usado em operações no nível da organização, como criar mais contas Snowflake, e não se encaixa muito bem na hierarquia padrão de roles.

Ao criar roles customizados e montar uma hierarquia, o Snowflake recomenda que todos os roles customizados sejam, no fim das contas, descendentes do SYSADMIN.

Pela nossa experiência em várias contas Snowflake, é comum ver a maior parte dos objetos do database criados e pertencendo ao ACCOUNTADMIN. Isso costuma ser uma má prática, sugere que se pensou pouco no controle de acesso e é um sinal de que o ACCOUNTADMIN está sendo usado como role padrão — o que pode levar a erros destrutivos, como apagar dados ou usuários. Vamos cobrir algumas boas práticas de controle de acesso na Parte II desta série. 🙌

Role padrão do usuário

Ao se conectar ao Snowflake, o usuário inicia uma session, que, na maioria dos casos, exige a definição de um role. Se nenhum for especificado, o Snowflake recorre ao role padrão do usuário.

Secondary Roles

Os secondary roles são uma forma de permitir que um usuário aproveite as capacidades de acesso de vários roles ao mesmo tempo. A maior parte dos clientes do Snowflake usa apenas o role principal (um único role), mas os secondary roles são um recurso poderoso, que pode evitar a necessidade de combinar vários roles.

Assim como você executa use role para definir o role principal em uma sessão, dá para executar use secondary roles. A principal diferença é que esse comando aceita duas opções:

1. use secondary roles all ativa todos os roles aos quais o usuário tem acesso;
2. use secondary roles none desativa os secondary roles.

Tá, tá — "Mostra o SQL logo!! 💢", já entendi.

Vamos montar o quebra-cabeça com um exemplo de ponta a ponta de bootstrap de uma conta Snowflake nova, deixando Kim e Rufus aptos a usá-la conforme suas necessidades.

Em resumo:

• Criamos Users, Roles e o Database.

use role SECURITYADMIN;
create role DATA_ENGINEER_ROLE;
create role DB_MANAGER_ROLE;
create role ANALYST_ROLE;

use role USERADMIN;
create user KIM;

use role SYSADMIN; -- objects are owned by the active role
create database SOURCE_DB;
create warehouse ANALYSIS_WH;

• Privilégios em securable objects são concedidos aos Roles.

use role SECURITYADMIN;

grant USAGE, MODIFY, CREATE SCHEMA
	on database SOURCE_DB to role DB_MANAGER_ROLE;
grant USAGE on database SOURCE_DB to role ANALYST_ROLE;

grant USAGE, OPERATE
	on warehouse ANALYSIS_WH to role ANALYST_ROLE;

• Os Roles são conectados em uma hierarquia, criando herança de privilégios.

use role SECURITYADMIN;

grant role DB_MANAGER_ROLE to role DATA_ENGINEER_ROLE;
grant role ANALYST_ROLE to role DATA_ENGINEER_ROLE;
grant role DATA_ENGINEER_ROLE to role SYSADMIN;

• Os Users ganham acesso a securable objects ao receberem Roles.

use role SECURITYADMIN;

grant role DATA_ENGINEER_ROLE to user KIM;
grant role ANALYST_ROLE to user RUFUS;

Com isso, chegamos a uma configuração que:

1. permite que Kim:
2. crie schemas e use o SOURCE_DB;
3. use e opere o ANALYSIS_WH;
4. permite que Rufus:
5. use o SOURCE_DB (se você está se perguntando se faltam privilégios adicionais sobre schemas e databases — você está 💯 certo, mas eles foram omitidos para simplificar);
6. use e opere o ANALYSIS_WH.

Apesar de ser uma configuração bem simples, o exemplo acima oferece todos os blocos necessários para implementar seu próprio modelo RBAC no Snowflake. Em um post de continuação, a Parte II, vamos cobrir as melhores práticas de RBAC no Snowflake e trazer algumas recomendações com opinião formada.