Controle de acesso Snowflake em escala

Cada vez mais empresas colocam o Snowflake no centro de seu data platforms. Mesmo que seja uma solução gerenciada, o senhor ainda precisa administrar o ambiente. Isso pode ser um desafio, especialmente para grandes empresas.

Um dos desafios é controle de acesso. É uma peça fundamental de qualquer programa data governance. O Snowflake fornece recursos prontos para uso para ajudar a enfrentar esse desafio. Mas quando o senhor tem dezenas de usuários e terabytes de data, os recursos incorporados não são suficientes. O senhor precisa pensar em uma estratégia para gerenciar sua conta.

Nós já estivemos lá. Para um dos nossos clientes, Na Alemanha, gerenciamos uma conta com mais de 50 usuários ativos. Projetamos uma solução para dimensionar o gerenciamento do controle de acesso.

Este artigo descreverá os principais aprendizados do ano passado.

Antes de entrarmos para a empresa, a conta foi criada e muitas ideias boas foram implementadas. Funções personalizadas foi criado. Os usuários eram gerenciados com cuidado. Mas havia algumas limitações:

Criamos um novo sistema para gerenciar o controle de acesso e combater essas deficiências.

Primeiro, revogamos todas as concessões de função padrão (SYSADMIN, USERADMIN...) para os usuários... Apenas algumas pessoas puderam assumir essas funções. Elas eram as pessoas responsáveis pela administração.

Em segundo lugar, criamos uma estrutura de controle de acesso com base em funções personalizadas. Definimos dois tipos de funções personalizadas:

Optamos por definir funções de acesso no datanível de base. Ele facilita a replicação dos privilégios de um ambiente para outro usando a clonagem de cópia zero. Também foi um compensação entre a flexibilidade que concedemos aos usuários finais e a aplicação rigorosa do princípio do menor privilégio.

No nível do database, definimos três níveis de funções de acesso:

Aplicamos uma estratégia semelhante ao acesso ao depósito com dois tipos de funções:

Abaixo está uma ilustração de nossa estrutura. As setas representam subsídios.

Nesse ponto, tínhamos uma ideia melhor de como gerenciaríamos as permissões, mas também tínhamos problemas com o gerenciamento de usuários.

Configuramos Login único para permitir que os usuários do Snowflake fazer login por meio do Azure Active Directory (AAD). Dessa forma, eliminamos a complexidade de manter duas bases de usuários data e o processo de desligamento foi mais robusto. Na verdade, só tivemos que desativar o usuário no AAD e a exclusão foi replicada automaticamente no Snowflake.

Como há um mapeamento entre grupos e funções do AD no Snowflake, conseguimos conceder uma função a cada usuário que criamos. Seguimos o mesmo processo para cada novo usuário.

Esse é o processo para usuários humanos reais, mas não aborda uma das limitações mencionadas no início deste artigo: o uso de credenciais pessoais para trabalhos automatizados.

É por isso que introduzimos o contas de serviço. O gerenciamento da conta de serviço é muito semelhante ao que acabamos de descrever. A única diferença é que criamos uma função funcional para cada conta de serviço. Existe uma relacionamento individualizado entre as contas de serviço e suas funções. Assim, limitamos estritamente o escopo das permissões de cada conta de serviço.

Essas etapas foram grandes melhorias. Tudo foi documentado. As equipes adotaram rapidamente a nova estrutura. Ficamos felizes.

Porém, ainda estávamos gastando muito tempo concedendo acesso manualmente e, como era muito manual, também estava sujeito a erros. Ficou clara a necessidade de uma ferramenta para automatizar essas tarefas.

Tínhamos algumas opções:

Finalmente, criamos uma CLI em Python.

Preferimos usar o Terraform para implantar infraestrutura e somente infraestrutura. Comportamentos indesejados podem ocorrer quando o senhor começa a gerenciar seus usuários e suas permissões com o Terraform. Por exemplo, a rotação de segredos é muito difícil de gerenciar.

Gostamos do bash, mas somente para operações simples e ad-hoc. Aqui, precisamos carregar arquivos de configuração, interagir com a API do Snowflake e manipular estruturas data. Isso é possível, mas seria difícil de manter a longo prazo.

Além desse aspecto, precisávamos de confiabilidade. Uma maneira de conseguir isso é escrever testes. Isso é mais fácil de fazer em linguagens de programação como Python.

Quando o senhor executa a ferramenta, eis o que acontece nos bastidores.

Por padrão, a ferramenta não cria uma função que já exista. O mesmo vale para os privilégios. A ferramenta calcula o diferença entre a configuração e o ambiente remoto e aplica as alterações necessárias. Isso nos permite evitar qualquer tempo de inatividade.

Inicialmente, executamos essa ferramenta localmente. Mas isso poderia gerar problemas. Por exemplo, poderíamos ter conflitos entre dois engenheiros que tentassem fazer alterações ao mesmo tempo. É por isso que configuramos um fluxo de trabalho baseado nos recursos de CI/CD do Azure DevOps (ADO).

Observação: estávamos usando o ADO, mas o senhor pode fazer o mesmo com o GitHub, o GitLab ou o Bitbucket.

Aqui está o processo final.

Esse fluxo de trabalho totalmente automatizado funciona muito bem. Os testes estão detectando os padrões no início do pipeline de CI. E a revisão obrigatória também é uma forma de evitar incidentes.

Além disso, as solicitações pull servem como uma espécie de documentação de todas as demandas.

Faz um pouco menos de um ano que começamos a usar essa solução. Embora tenha sido necessário um investimento inicial de tempo para a implementação, valeu totalmente a pena.

Agora passamos mais tempo discutindo com os usuários sobre suas solicitações e não na implementação real. A maioria das solicitações pode ser resolvida em cerca de 10 linhas de YAML. Isso é muito eficiente e tem um bom dimensionamento. Ainda recebemos novos usuários e podemos atender à demanda. Além disso, resolvemos os problemas iniciais. Portanto, foi um sucesso!