As 7 melhores práticas de RBAC no Snowflake

Ao desenhar seu modelo de acesso e distribuir permissões para os usuários da empresa, busque uma estrutura em que cada usuário tenha exatamente as permissões necessárias (nem mais, nem menos) para executar seu trabalho. Por que o novo Analista Júnior de Finanças teria permissão para apagar tabelas se ele só precisa consultar uma tabela de balanço patrimonial?

Esse é o chamado Princípio do Menor Privilégio. Quando aplicado ao seu modelo de acesso no Snowflake, ele traz uma série de benefícios:

• Reduz o risco e o impacto de ameaças externas: restringir o acesso do usuário apenas ao necessário diminui o risco de vazamentos acidentais ou maliciosos. E, se um vazamento acontecer, o estrago fica limitado às áreas do banco que a(s) conta(s) comprometida(s) conseguem acessar.
• Minimiza o risco de corrupção do sistema e aumenta a estabilidade: limitar o acesso ajuda a evitar mudanças que poderiam afetar a integridade ou a estabilidade dos dados; quem tem exposição limitada não deveria poder apagar bancos de dados! :)
• Facilita a auditoria e o monitoramento: manter apenas os privilégios mínimos também significa menos privilégios para acompanhar e manter;
• Simplifica a conformidade: esse princípio também facilita o cumprimento de exigências regulatórias de proteção de dados — quando aplicáveis —, como LGPD, GDPR ou HIPAA, restringindo o acesso a dados sensíveis ao estritamente necessário.

O Princípio do Menor Privilégio é um ótimo ponto de partida, porque equilibra bem boas práticas de segurança e esforço de manutenção. Algumas empresas preferem modelos de segurança mais simples, ao custo de mais riscos, enquanto outras adotam práticas mais rigorosas. Vale a pena pesquisar sobre o modelo de segurança Zero-Trust e como o Princípio do Menor Privilégio se conecta a ele.

No artigo anterior, mencionamos diferentes tipos de roles: account roles, database roles e até instance roles. Cada uma tem diferenças fundamentais e técnicas. Para simplificar, neste artigo vamos nos concentrar nas Account Roles.

Agora, vamos explorar uma abordagem diferente para definir roles: com base na sua intenção. São 3 tipos de roles que queremos apresentar aqui:

• Access Roles servem para controlar o acesso aos seus bancos de dados;
• Functional Roles são concedidas aos usuários do Snowflake na sua empresa, e os níveis de acesso são definidos atribuindo a elas as Access Roles necessárias (seguindo o Princípio do Menor Privilégio);
• Service Roles funcionam exatamente como as Functional Roles, com a única diferença de que são destinadas a serviços, e não a usuários finais (humanos).

Vale lembrar que não existe diferença técnica entre Access, Functional e Service Roles. Todas são criadas como Account Roles.

Access Roles

As Access Roles existem para garantir diferentes níveis de acesso a bancos de dados e a objetos do banco. Pense nelas como os blocos básicos da sua hierarquia.

Uma forma simples de criar Access Roles é usar roles READ e READWRITE para cada banco de dados existente:

• READ: concede privilégios de SELECT em todas as tabelas e views do banco.
• READWRITE: concede as operações de SELECT, INSERT, UPDATE e DELETE.

É um bom ponto de partida, mas, dependendo das necessidades da empresa, dá para criar Access Roles mais granulares (por exemplo, para acessar schemas específicos dentro de um banco).

Functional Roles

As Functional Roles são pensadas para ficar alinhadas às funções de negócio e recebem um conjunto de Access Roles. Por exemplo, uma role DATA_ANALYST pode herdar os privilégios das Access Roles READ\* *criadas para alguns bancos. Já uma role DATA_ENGINEER pode herdar as roles READWRITE dos mesmos bancos.

São essas as roles que serão concedidas aos usuários finais. Você pode montá-las conforme a necessidade real, usando as Access Roles como blocos de construção (sempre tendo o Princípio do Menor Privilégio em mente).

Service Roles

Esse tipo de role é praticamente igual a uma Functional Role, mas, em vez de ser concedida a usuários da empresa, é atribuída a Service Accounts. Elas podem ser usadas por ferramentas de terceiros, como plataformas de BI e dashboard, ou qualquer outro SaaS que precise de acesso READ ou READWRITE a objetos do banco no Snowflake (por exemplo, Airbyte, Rudderstack, Mode).

Assim como acontece com as Functional Roles, você pode montar Service Roles conforme a necessidade real, usando as Access Roles como blocos de construção e mantendo sempre o Princípio do Menor Privilégio em mente.

Com esses 3 tipos de roles, você já tem os blocos necessários para montar uma hierarquia de access roles simples e eficaz.

Um dos princípios fundamentais do desenvolvimento de software é evitar repetição de código, resumido na sigla D.R.Y. ("Don't Repeat Yourself", ou "Não se repita"). Com Access, Functional e Service Roles em mãos, dá para começar a esboçar como será sua hierarquia. Use os 4 passos a seguir para iterar.

1. Defina as Functional e Service Roles que sua empresa precisa

Levante os requisitos junto aos diferentes usuários do Snowflake na sua empresa e monte uma lista das Functional Roles necessárias, junto com os níveis de acesso exigidos. Essa lista vai servir de base para você esboçar as Access Roles necessárias.

2. Crie as Access Roles

Com a lista de requisitos pronta, fica fácil visualizar as Access Roles necessárias. Agora é só criar essas roles e conceder os privilégios apropriados nos objetos do banco correspondentes (por exemplo, FINANCE_DB_READ_ROLE).

3. Crie as Functional e Service Roles (e conceda as Access Roles a elas)

Com as Access Roles no lugar, você já tem tudo o que precisa para construir as Functional Roles para os colegas da empresa e as Service Roles para os serviços. Para atender aos requisitos definidos inicialmente, conceda as Access Roles às Functional/Service Roles que você acabou de criar (por exemplo, DATA_ANALYST).

4. Conceda as Functional Roles aos usuários e as Service Roles às Service Accounts

Pronto, sua hierarquia de roles está completa! O passo final é conceder as Functional Roles aos usuários do Snowflake e as Service Roles às Service Accounts. Se precisar de ajustes, é só repetir os passos de 1 a 4.

O que evitar…

⛔ Não conceda Access Roles diretamente a usuários finais ou Service Accounts

Se você pular a camada de Functional Roles e atribuir um conjunto de Access Roles direto para um usuário, vai ter que repetir esse trabalho toda vez que um novo usuário com responsabilidades parecidas entrar no time. Além disso, sempre que precisar de um ajuste, terá que fazê-lo manualmente para vários usuários.

Ter uma Functional Role significa que existe um único lugar para fazer ajustes. Essas mudanças se aplicam automaticamente a todos os usuários que receberam aquela Functional Role específica. A camada de Access Roles existe para padronizar o acesso aos objetos do banco em toda a sua conta — não para ser usada diretamente!

⛔ Não conceda Functional Roles a outras Functional Roles

Mantenha a coisa simples! Cada Functional Role deve ser uma composição de Access Roles. Introduzir dependências pode complicar as coisas, principalmente conforme a empresa cresce e os cargos vão evoluindo.

Você criou Access Roles para um banco de dados, mas novos schemas e tabelas não param de aparecer e você vive atualizando os privilégios? Então essa dica é para você! Dá para conceder privilégios em schemas futuros de um banco, assim como em tabelas, views ou outros objetos futuros. Assim, sempre que um novo objeto é criado, o grant é adicionado automaticamente.

Usar future grants na criação das Access Roles ajuda a reduzir o trabalho de manutenção e garante que suas roles tenham os privilégios certos quando novos objetos do banco surgirem. Sem precisar rodar um grant a cada novo objeto no banco!

Quando uma role customizada é criada, ela existe de forma isolada — e o mesmo vale para quaisquer objetos criados por ela. Por padrão, nem a role ACCOUNTADMIN consegue modificar ou apagar objetos criados por uma role customizada. Ou seja, quando uma role não tem um "pai", você corre o risco de criar objetos na sua conta que só ficam acessíveis por aquela role.

Ao conceder uma role customizada ao SYSADMIN, você garante que, no mínimo, as roles SYSADMIN (e ACCOUNTADMIN) também conseguirão gerenciar os objetos criados por essa role.

Para fechar: adote a boa prática de conceder suas Functional Roles ao SYSADMIN por padrão.

O Snowsight tem um recurso bem útil para visualizar a hierarquia de roles existente na conta do Snowflake. Dá para enxergar as roles que você criou e como elas se conectam.

Procure a opção Graph em Users & Roles. Depois, use a opção Focus para observar uma role específica e suas roles pai/filhas.

Ou, em outras palavras, use a role apropriada para cada operação administrativa. Lembre do Princípio do Menor Privilégio!

Por padrão, a role ACCOUNTADMIN tem muito mais privilégios do que o necessário para suas operações e tarefas do dia a dia, então o ideal é evitar usá-la, a não ser que haja um bom motivo. Veja o que usar no lugar para as operações mais comuns:

• Se você precisa criar usuários ou roles, use USERADMIN!
• Se precisa gerenciar grants (por exemplo, conceder uma role a um usuário), use SECURITYADMIN!
• Se precisa criar objetos como bancos de dados, schemas ou virtual warehouses, use SYSADMIN!
• Se precisa criar bancos ou objetos do banco, como tabelas, views ou outros, pode usar SYSADMIN!
• Se quer fazer operações ad-hoc com dados em uma tabela (como um SELECT ou um INSERT), use uma Functional Role apropriada!
• E, por fim, se você quer conectar um serviço de terceiros ao Snowflake, de jeito nenhum use ACCOUNTADMIN! No lugar, crie e use uma Service Role adequada :)

Por exemplo, o pacote SELECT dbt-snowflake-monitoring exige um privilégio especial IMPORTED PRIVILEGES no banco SNOWFLAKE, que só pode ser concedido pela role ACCOUNTADMIN. Nesse caso, use USERADMIN para criar uma Access Role só para esse privilégio, conceda o privilégio usando ACCOUNTADMIN e use SECURITYADMIN para atribuir a Access Role a uma Service Role para o dbt.

Contexto

Você é Data Engineer em uma equipe de dados e está começando a implementar o Snowflake na sua organização. Pediram para você gerenciar 3 bancos de dados:

Uma breve descrição dos 3 bancos:

• HR_DB contém dados sobre funcionários e headcount;
• FINANCE_DB contém dados financeiros, como balanços e demonstrações financeiras;
• REPORTING_DB contém dados para analytics e reporting.

Sua missão agora é garantir que todo mundo na empresa tenha o acesso certo a esses bancos.

Requisitos

Você conversou com os diferentes usuários do Snowflake na empresa e levantou os seguintes requisitos:

1. Richard, Data Analyst que atua com os times de Finanças e RH, pede para conseguir ler todos os dados de Finanças e RH para suas análises. Ele também quer poder criar tabelas de reporting no banco de Reporting.
2. Lily, Data Engineer da empresa, precisa trabalhar no carregamento de dados históricos nos bancos de Finanças e RH.
3. O time de Finanças está usando uma nova ferramenta SaaS, que precisa ler dados dos bancos de Finanças e RH e, como bônus, vai gravar alguns dados processados de volta no banco de Finanças.
4. Pediram para você configurar uma nova ferramenta de BI e dashboard que vai consumir dados do banco de Reporting.

Use o código a seguir para criar os bancos no Snowflake:

use role SYSADMIN ;

create database FINANCE_DB ;
create database HR_DB ;
create database REPORTING_DB ;

-- Create tables, views, ...
-- ...

Passos

Definir as Functional e Service Roles

Com os requisitos em mãos, comece montando uma lista para deixar claro exatamente do que você precisa.

Para as Functional Roles:

Para as Service Roles:

⚠️ Conceder permissões READWRITE completas em todos os schemas de um banco para uma ferramenta de terceiros, como estamos fazendo aqui (Finance SaaS), pode não ser a melhor ideia na vida real. Num cenário mais realista, a ferramenta só teria acesso a um conjunto específico de schemas dos quais precisa ler ou nos quais precisa escrever. Lembre-se: este é um modelo simplificado.

Criar as Access Roles

Com base nas tabelas acima, dá para identificar as Access Roles necessárias:

• HR_READ_ROLE
• HR_READWRITE_ROLE
• FINANCE_READ_ROLE
• FINANCE_READWRITE_ROLE
• REPORTING_READ_ROLE
• REPORTING_READWRITE_ROLE

Como já mencionado, as roles READ e READWRITE permitirão executar, respectivamente, comandos SELECT ou SELECT, INSERT, UPDATE e DELETE. Veja como fica:

E estes são os comandos para executar no Snowflake:

-- Create Access Roles for HR_DB
use role USERADMIN ;

create role HR_READ_ROLE
        comment = 'Access Role READ for HR_DB' ;
create role HR_READWRITE_ROLE
        comment = 'Access Role READWRITE for HR_DB' ;

-- Grant Privileges to Access Roles for HR_DB
use role SECURITYADMIN ;

-- Granting Privileges to HR_READ_ROLE
-- Database
grant usage on database HR_DB to role HR_READ_ROLE ;

Expandir código

Repare que dá para aproveitar convenções fixas de nomenclatura para bancos de dados e Access Roles. É possível criar um único script e usar templating para reaproveitar e implantar facilmente vários bancos junto com suas respectivas Access Roles. Veja um exemplo:

-- Assign values to the following variables accordingly
set database_name = 'HR_DB';
set role_read_name = 'HR_READ_ROLE';
set role_readwrite_name = 'HR_READWRITE_ROLE';

-- Create database
use role SYSADMIN ;
create database identifier($database_name) ;

-- Create Access Roles for the database
use role USERADMIN ;
create role identifier($role_read_name) ;
create role identifier($role_readwrite_name) ;

-- Grant Privileges to READ role

Expandir código

Criar as Functional Roles

Com as Access Roles no lugar, fica fácil criar Functional Roles que representem as necessidades dos usuários. É aqui que entramos nos requisitos.

Começando pelo pedido do Richard:

🎯 Richard, Data Analyst que atua com os times de Finanças e RH, pede para conseguir ler todos os dados de Finanças e RH para suas análises. Ele também quer poder escrever tabelas no banco de Reporting.

Veja como fica:

Essa é uma implementação simples de Access e Functional Roles para atender às necessidades do Richard. A role ANALYST_ROLE é a Functional Role, e é a pai de HR_READ_ROLE, FINANCE_READ_ROLE e REPORTING_READWRITE_ROLE (todas Access Roles).

O Richard então recebe a ANALYST_ROLE. Agora ele consegue consultar tabelas em HR_DB e FINANCE_DB e modificar dados em REPORTING_DB. E a role também pode ser concedida a qualquer outra pessoa do time do Richard com responsabilidades parecidas. 🎉

No Snowflake, fica assim:

-- Create Functional Role ANALYST_ROLE
use role USERADMIN ;

create role ANALYST_ROLE
        comment = 'Functional Role for Data Analysts' ;

-- Grants to role ANALYST_ROLE
use role SECURITYADMIN ;

grant role HR_READ_ROLE to role ANALYST_ROLE ;
grant role FINANCE_READ_ROLE to role ANALYST_ROLE ;
grant role REPORTING_READWRITE_ROLE to role ANALYST_ROLE ;

-- Grant Functional Role to SYSADMIN (good practice mentioned before)
grant role ANALYST_ROLE to role SYSADMIN ;

Expandir código

Agora, aplicando os mesmos princípios para a Lily:

🎯 Lily, Data Engineer da empresa, precisa trabalhar no carregamento de dados históricos nos bancos de Finanças e RH.

Um exemplo parecido para uma Functional Role de Data Engineering:

A montagem é parecida, mas, nesse caso, a role ENGINEER_ROLE se torna pai de HR_READWRITE_ROLE e FINANCE_READWRITE_ROLE, sendo então concedida à Lily.

O SQL fica assim:

-- Create Functional Role ENGINEER_ROLE
use role USERADMIN ;

create role ENGINEER_ROLE
        comment = 'Functional Role for Data Engineers' ;

-- Grants to role ANALYST_ROLE
use role SECURITYADMIN ;

grant role HR_READWRITE_ROLE to role ENGINEER_ROLE ;
grant role FINANCE_READWRITE_ROLE to role ENGINEER_ROLE ;

-- Grant Functional Role to SYSADMIN (good practice mentioned before)
grant role ENGINEER_ROLE to role SYSADMIN ;

Expandir código

Agora, trabalhando nos requisitos do novo Finance SaaS:

🎯 O time de Finanças está usando uma nova ferramenta SaaS, que precisa ler dados dos bancos de Finanças e RH e, como bônus, vai gravar alguns dados processados de volta no banco de Finanças.

Tranquilo, né? Veja o diagrama:

Aqui é criada uma nova Service Role, chamada FINANCE_SAAS_ROLE. Ela funciona basicamente como uma Functional Role, com a única diferença de que será usada de forma programática, e não por uma pessoa. A role herda os privilégios de FINANCE_READWRITE_ROLE e HR_READ_ROLE, e é concedida a uma Service Account do Snowflake para uso pelo serviço.

No código:

-- Create Service Role FINANCE_SAAS_ROLE
use role USERADMIN ;

create role FINANCE_SAAS_ROLE
        comment = 'Service Role for Finance SaaS' ;

-- Grants to role FINANCE_SAAS_ROLE
use role SECURITYADMIN ;

grant role FINANCE_READWRITE_ROLE to role FINANCE_SAAS_ROLE ;
grant role HR_READ_ROLE to role FINANCE_SAAS_ROLE ;

-- Grant Service Role to SYSADMIN (good practice mentioned before)
grant role FINANCE_SAAS_ROLE to role SYSADMIN ;

Expandir código

Agora, partindo para o caso da ferramenta de BI:

🎯 Pediram para você configurar uma nova ferramenta de BI e dashboards que vai consumir dados do banco de Reporting.

Mais do mesmo?

Nesse caso, a única Access Role de que BI_ROLE precisa é a REPORTING_READ_ROLE. Pronto: a ferramenta de BI já vai conseguir executar queries SELECT para popular seus dashboards! 🎉

No código:

-- Create Service Role BI_ROLE
use role USERADMIN ;

create role BI_ROLE
        comment = 'Service Role for BI and Insights Tool' ;

-- Grants to role BI_ROLE
use role SECURITYADMIN ;

grant role REPORTING_READ_ROLE to role BI_ROLE ;

-- Grant Service Role to SYSADMIN (good practice mentioned before)
grant role BI_ROLE to role SYSADMIN ;

-- Grant role to service account

Expandir código

Fechando o ciclo

Com todos os casos de uso cobertos, nossa hierarquia inicial de roles está completa! Juntando tudo, fica assim:

Bônus - Lidando com mudanças e ajustes

Uma das vantagens de ter uma hierarquia DRY é que ela se adapta com facilidade a novos requisitos. Por exemplo, imagine que a Data Engineer Lily esqueceu de pedir acesso READWRITE ao REPORTING_DB. Esse pedido se resolve sem dor de cabeça:

-- Adjust DATA_ENGINEER functional role
use role SECURITYADMIN ;
grant role REPORTING_READWRITE_ROLE to role DATA_ENGINEER ;

Pronto: agora você gerencia uma hierarquia que se adapta facilmente a novos requisitos de negócio! 🎉