Visão geral do controle de acesso¶

Este tópico fornece informações sobre os principais tópicos de controle de acesso no Snowflake.

Neste tópico:

Estrutura de controle de acesso¶

A abordagem do Snowflake para o controle de acesso combina aspectos de ambos os modelos a seguir:

Controle de acesso discricionário (DAC): Cada objeto tem um proprietário, que pode, por sua vez, conceder acesso a esse objeto.
Controle de acesso baseado em funções (RBAC): Privilégios de acesso são atribuídos a funções, que por sua vez são atribuídas aos usuários.

Os conceitos-chave para entender o controle de acesso no Snowflake são:

Objeto mensurável: Uma entidade à qual o acesso pode ser concedido. A menos que seja permitido por uma concessão, o acesso é negado.
Função: Uma entidade à qual podem ser concedidos privilégios. As funções são, por sua vez, atribuídas aos usuários. Observe que as funções também podem ser atribuídas a outras funções, criando uma hierarquia de funções.
Privilégio: Um nível de acesso definido a um objeto. Vários privilégios distintos podem ser usados para controlar a granularidade do acesso concedido.
Usuário: Uma identidade de usuário reconhecida pelo Snowflake, seja associada a uma pessoa ou a um programa.

No modelo Snowflake, o acesso a objetos protegíveis é permitido através de privilégios atribuídos a funções, que por sua vez são atribuídas aos usuários ou a outras funções. A concessão de uma função a outra cria uma hierarquia de funções, que é explicada na seção Hierarquia de funções e herança de privilégios (neste tópico).

Além disso, cada objeto protegível tem um proprietário que pode conceder acesso a outras funções. Este modelo é diferente de um modelo de controle de acesso baseado no usuário, no qual direitos e privilégios são atribuídos a cada usuário ou grupos de usuários. O modelo do Snowflake foi projetado para proporcionar uma quantidade significativa de controle e flexibilidade.

Objetos protegíveis¶

Todo objeto protegível reside dentro de um contêiner lógico em uma hierarquia de contêineres. O contêiner mais alto é a organização do cliente. Objetos protegíveis, como tabelas, exibições, funções e estágios estão contidos em um objeto de esquema, que por sua vez está contido em um banco de dados. Todos os bancos de dados para sua conta Snowflake estão contidos no objeto de conta. Esta hierarquia de objetos e contêineres é ilustrada abaixo:

Possuir um objeto significa que uma função tem o OWNERSHIP privilégio sobre o objeto. Cada objeto protegível é propriedade de uma única função, que por padrão é a função usada para criar o objeto. Quando esta função é atribuída aos usuários, eles têm efetivamente o controle compartilhado sobre o objeto. O comando GRANT OWNERSHIP permite transferir a propriedade de um objeto de uma função para outra, inclusive para funções de banco de dados. Este comando também especifica os objetos que podem ser protegidos em cada contêiner.

Em um esquema regular, a função do proprietário tem todos os privilégios sobre o objeto por padrão, incluindo a capacidade de conceder ou revogar privilégios sobre o objeto para outras funções. Além disso, a propriedade pode ser transferida de uma função para outra. Entretanto, em um esquema de acesso gerenciado, os proprietários de objetos perdem a capacidade de tomar decisões de concessão. Somente o proprietário do esquema (isto é, a função com o privilégio OWNERSHIP no esquema) ou uma função com o privilégio MANAGE GRANTS pode conceder privilégios para objetos no esquema.

A capacidade de executar ações SQL sobre objetos é definida pelos privilégios concedidos à função ativa em uma sessão do usuário. A seguir estão exemplos de ações SQL disponíveis em vários objetos no Snowflake:

Capacidade de criar um warehouse.
Capacidade de listar tabelas contidas em um esquema.
Capacidade de adicionar dados a uma tabela.

Funções¶

Funções são as entidades às quais privilégios para objetos protegíveis podem ser concedidos e revogados. Funções são atribuídas a usuários para permitir que eles executem as ações necessárias para as funções empresariais em sua organização. A um usuário podem ser atribuídas múltiplas funções. Isto permite aos usuários trocar de função (ou seja, escolher qual função está ativa na sessão atual do Snowflake) para realizar diferentes ações usando conjuntos separados de privilégios.

Há um pequeno número de funções definidas pelo sistema em uma conta Snowflake. As funções definidas pelo sistema não podem ser descartadas. Além disso, os privilégios concedidos a estas funções pelo Snowflake não podem ser revogados.

Os usuários a quem foi concedido uma função com os privilégios necessários podem criar funções personalizadas para atender a necessidades específicas de negócios e segurança.

Funções também podem ser concedidas a outras funções, criando uma hierarquia de funções. Os privilégios associados a um função são herdados por qualquer função acima dessa função na hierarquia. Para obter mais informações sobre hierarquias de funções e herança de privilégios, consulte Hierarquia de funções e herança de privilégios (neste tópico).

Nota

Um proprietário de função (ou seja, a função que tem o privilégio OWNERSHIP para a função) não herda os privilégios da função que lhe pertence. A herança de privilégios só é possível dentro de uma hierarquia de funções.

Embora privilégios adicionais possam ser concedidos a funções definidas pelo sistema, isso não é recomendado. Funções definidas pelo sistema são criadas com privilégios relacionados ao gerenciamento de contas. Como melhor prática, não é recomendado misturar privilégios de gerenciamento de conta e privilégios específicos de entidade na mesma função. Se privilégios adicionais forem necessários, a Snowflake recomenda conceder os privilégios adicionais a uma função personalizada e atribuir a função personalizada à função definida pelo sistema.

Tipos de funções¶

Os seguintes tipos de funções são essencialmente os mesmos, exceto por seu escopo. Ambos os tipos permitem aos administradores autorizar e restringir o acesso a objetos em sua conta.

Nota

Exceto onde indicado na documentação do produto, o termo função se refere a qualquer um dos tipos.

Funções de conta

Para permitir ações de SQL em qualquer objeto em sua conta, conceda privilégios no objeto a uma função de conta.

Funções de banco de dados

Para limitar as ações de SQL a um único banco de dados, assim como qualquer objeto no banco de dados, conceda privilégios no objeto a uma função de banco de dados no mesmo banco de dados.

Note que as funções do banco de dados não podem ser ativadas diretamente em uma sessão. Conceda funções de banco de dados para funções de conta, que podem ser ativadas em uma sessão.

Para obter mais informações sobre as funções de banco de dados, consulte:

Hierarquia de funções e herança de privilégios (neste tópico)
Funções de banco de dados e hierarquias de banco de dados (neste tópico)
Gerenciamento de acesso ao objeto de banco de dados usando funções de bancos de dados
Funções de banco de dados no banco de dados SNOWFLAKE compartilhado.
CREATE <objeto> … CLONE

Funções de instância

Para permitir acesso a uma instância de uma classe, conceda uma função de instância a uma função de conta.

Uma classe pode ter uma ou mais funções de classe com privilégios diferentes concedidos a cada função. Quando uma instância de uma classe é criada, a(s) função(ões) de instância pode(m) ser concedida(s) a funções de conta para conceder acesso a métodos de instância.

Note que as funções de instância não podem ser ativadas diretamente em uma sessão. Conceda funções de instância para funções de conta, que podem ser ativadas em uma sessão.

Para obter mais informações, consulte Funções de instância.

Funções ativas¶

Funções ativas servem como fonte de autorização para qualquer ação executada por um usuário em uma sessão. Tanto a função primária como qualquer função secundária podem ser ativadas em uma sessão do usuário.

Uma função se torna uma função ativa de uma das seguintes maneiras:

Quando uma sessão é estabelecida pela primeira vez, a função padrão do usuário e as funções secundárias padrão são ativadas como as funções primárias e secundárias da sessão, respectivamente.

Observe que as propriedades de conexão do cliente usadas para estabelecer a sessão poderiam anular explicitamente a função primária ou funções secundárias a serem usadas.
A execução de uma instrução USE ROLE ou USE SECONDARY ROLES ativa uma função primária ou secundária diferente, respectivamente. Estas funções podem mudar no decorrer de uma sessão se qualquer um dos comandos for executado novamente.

Funções definidas pelo sistema¶

ORGADMIN

(também conhecida como administrador da organização)

Função que gerencia as operações em nível de organização. Mais especificamente, esta função:

Pode criar contas na organização.
Pode visualizar todas as contas da organização (usando SHOW ORGANIZATION ACCOUNTS), bem como todas as regiões habilitadas para a organização (usando SHOW REGIONS).
Pode visualizar informações de uso em toda a organização.

ACCOUNTADMIN

(também conhecida como administrador de conta)

Função que encapsula as funções SYSADMIN e SECURITYADMIN definidas pelo sistema. É a função de nível superior no sistema e deve ser concedida somente a um número limitado/controlado de usuários em sua conta.

SECURITYADMIN

(também conhecida como administrador de segurança)

Função que pode administrar qualquer concessão de objeto globalmente, assim como criar, monitorar e administrar usuários e funções. Mais especificamente, esta função:

Recebe o privilégio de segurança MANAGE GRANTS para poder modificar qualquer concessão, inclusive revogá-la.
Herda os privilégios da função USERADMIN através da hierarquia de funções do sistema (ou seja, a função USERADMIN é concedida à função SECURITYADMIN).

USERADMIN

(também conhecida como administrador de usuários e funções)

Função que é dedicada somente ao gerenciamento de usuários e funções. Mais especificamente, esta função:

Recebe os privilégios de segurança CREATE USER e CREATE ROLE.
Pode criar usuários e funções na conta.

Esta função também pode gerenciar usuários e funções que lhe pertencem. Somente a função com o privilégio OWNERSHIP para um objeto (ou seja, usuário ou função), ou uma função superior, pode modificar as propriedades do objeto.

SYSADMIN

(também conhecida como administrador de sistema)

Função que tem privilégios para criar warehouses e bancos de dados (e outros objetos) em uma conta.

Se, como recomendado, você criar uma hierarquia de funções que, em última instância, atribui todas as funções personalizadas à função SYSADMIN, esta função também tem a capacidade de conceder privilégios para warehouses, bancos de dados e outros objetos a outras funções.

PUBLIC

Pseudofunção que é concedida automaticamente a cada usuário e a cada função em sua conta. A função PUBLIC pode possuir objetos protegíveis, como qualquer outra função; entretanto, os objetos de propriedade da função estão, por definição, disponíveis para qualquer outro usuário e função em sua conta.

Esta função é tipicamente utilizada em casos onde o controle de acesso explícito não é necessário e todos os usuários são vistos como iguais no que diz respeito a seus direitos de acesso.

Funções personalizadas¶

Funções de conta personalizadas podem ser criadas usando a função USERADMIN (ou uma função superior), bem como por qualquer função que tenha recebido o privilégio CREATE ROLE.

As funções personalizadas de banco de dados podem ser criadas pelo proprietário do banco (ou seja, a função que tem o privilégio OWNERSHIP no banco de dados).

Por padrão, uma função recém-criada não é atribuída a nenhum usuário, nem é concedida a nenhuma outra função.

Ao criar funções que servirão como proprietários de objetos protegíveis no sistema, a Snowflake recomenda a criação de uma hierarquia de funções personalizadas, com a função personalizada superior atribuída à função de sistema SYSADMIN. Essa estrutura de funções permite aos administradores do sistema gerenciar todos os objetos da conta, tais como warehouses e objetos de banco de dados, enquanto restringe o gerenciamento de usuários e funções à função USERADMIN.

Por outro lado, se uma função personalizada não for atribuída a SYSADMIN através de uma hierarquia de funções, os administradores do sistema não conseguirão gerenciar os objetos de propriedade da função. Somente aquelas funções às quais foi concedido o privilégio MANAGE GRANTS (somente a função SECURITYADMIN por padrão) podem visualizar os objetos e modificar suas concessões de acesso.

Para instruções sobre como criar funções personalizadas, consulte Criação de funções personalizadas.

Privilégios¶

Os privilégios de controle de acesso determinam quem pode acessar e executar operações em objetos específicos do Snowflake. Para cada objeto protegível, há um conjunto de privilégios que podem ser concedidos para ele. Para objetos existentes, os privilégios devem ser concedidos sobre objetos individuais (por exemplo, o privilégio SELECT na tabela mytable). Para simplificar o gerenciamento de concessões, concessões futuras permitem definir um conjunto inicial de privilégios sobre objetos criados em um esquema (ou seja, conceder o privilégio SELECT em todas as tabelas novas criadas no esquema myschema a uma função especificada).

Privilégios são gerenciados utilizando os comandos GRANT <privilégios> e REVOKE <privilégios>.

Em esquemas regulares (isto é, não gerenciados), o uso destes comandos é restrito à função que possui um objeto (isto é, tem o privilégio OWNERSHIP sobre o objeto) ou qualquer função que tenha o privilégio global MANAGE GRANTS para o objeto (apenas a função SECURITYADMIN por padrão).
Em esquemas de acesso gerenciado, os proprietários de objetos perdem a capacidade de tomar decisões de concessão. Somente o proprietário do esquema ou um função com o privilégio MANAGE GRANTS pode conceder privilégios sobre objetos do esquema, incluindo futuras concessões, centralizando o gerenciamento de privilégios.

Note que uma função que detém o privilégio global MANAGE GRANTS pode conceder privilégios adicionais à função atual (concessor).

Para obter mais detalhes, consulte Privilégios de controle de acesso.

Hierarquia de funções e herança de privilégios¶

O diagrama seguinte ilustra a hierarquia para as funções definidas pelo sistema, bem como a estrutura recomendada para funções adicionais de conta e funções de banco de dados definidas pelo usuário. A função de banco de dados de nível mais alto na hierarquia de exemplo é concedida a uma função de conta personalizada (isto é, definida pelo usuário). Por sua vez, esta função é concedida a outra função personalizada em uma estrutura recomendada que permite que a função SYSADMIN definida pelo sistema herde os privilégios das funções personalizadas da conta e das funções do banco de dados:

Nota

ORGADMIN é uma função de sistema separada que gerencia as operações em nível de organização. Esta função não está incluída na hierarquia das funções do sistema.

Para um exemplo mais específico de hierarquia de funções e herança de privilégios, considere o seguinte cenário:

A Função 3 foi concedida à Função 2.

A Função 2 foi concedida à Função 1.

A Função 1 foi concedida ao Usuário 1.

Neste cenário:

A Função 2 herda o Privilégio C.

A Função 1 herda os Privilégios B e C.

O Usuário 1 tem todos os três privilégios.

Funções de banco de dados e hierarquias de banco de dados¶

As seguintes limitações se aplicam atualmente às funções de banco de dados:

Se uma função de banco de dados for concedida a um compartilhamento, então nenhuma outra função de banco de dados pode ser concedida a essa função de banco de dados. Por exemplo, se a função de banco de dados d1.r1 for concedida a um compartilhamento, então a tentativa de conceder a função de banco de dados d1.r2 a d1.r1 é bloqueada.

Além disso, se uma função de banco de dados for concedida a uma outra função de banco de dados, a função de banco de dados do beneficiado não poderá ser concedida a um compartilhamento.

As funções de banco de dados que são concedidas a um compartilhamento podem ser concedidas a outras funções de banco de dados, assim como as funções de conta.
Funções de conta não podem ser atribuídas a funções de banco de dados em uma hierarquia de funções.

Modelo de aplicação com funções primárias e secundárias¶

Cada sessão de usuário ativa tem uma “função atual”, também chamada função primária. Quando uma sessão é iniciada (por exemplo, um usuário se conecta via JDBC/ODBC ou faz login na interface da Web do Snowflake), a função atual é determinada com base nos seguintes critérios:

Se uma função foi especificada como parte da conexão e essa é uma função que já foi concedida ao usuário que se conecta, a função especificada torna-se a função atual.
Se nenhuma função foi especificada e uma função padrão foi definida para o usuário que se conecta, essa função se torna a função atual.
Se nenhuma função foi especificada e uma função padrão não foi definida para o usuário que se conecta, é utilizada a função do sistema PUBLIC.

Além disso, um conjunto de funções secundárias pode ser ativado em uma sessão do usuário. Um usuário pode executar ações SQL sobre objetos em uma sessão utilizando os privilégios agregados concedidos às funções primárias e secundárias. As funções devem ser concedidas ao usuário antes de poderem ser ativadas em uma sessão. Note que, enquanto uma sessão deve ter exatamente uma função primária ativa de cada vez, pode-se ativar qualquer número de funções secundárias ao mesmo tempo.

Nota

Uma função de banco de dados não pode ser uma função primária ou secundária. Para assumir os privilégios concedidos a uma função de banco de dados, conceda a função de banco de dados a uma função de conta. Somente as funções da conta podem ser ativadas em uma sessão.

A autorização para executar instruções CREATE <objeto> vem apenas da função principal. Quando um objeto é criado, sua propriedade é definida para a função primária atualmente ativa. Entretanto, para qualquer outra ação SQL, qualquer permissão concedida a qualquer função primária ou secundária ativo pode ser usada para autorizar a ação. Por exemplo, se qualquer função em uma hierarquia de funções secundárias possuísse um objeto (ou seja, tem o privilégio OWNERSHIP sobre o objeto), as funções secundárias autorizariam a realização de quaisquer ações DDL sobre o objeto. Tanto a função primária quanto todas as funções secundárias herdam privilégios de quaisquer funções inferiores em suas hierarquias de funções.

Para organizações cujo modelo de segurança inclui um grande número de funções, cada uma com uma fina granularidade de autorização através de permissões, o uso de funções secundárias simplifica o gerenciamento de funções. Todas as funções que foram concedidas a um usuário podem ser ativadas em uma sessão. As funções secundárias são particularmente úteis para operações SQL como junções de bancos de dados que, de outra forma, exigiriam a criação de uma função pai para as funções que têm permissões para acessar os objetos em cada banco de dados.

Durante uma sessão, o usuário pode usar o comando USE ROLE ou USE SECONDARY ROLES para mudar as funções primárias ou secundárias atuais, respectivamente. O usuário pode usar a função CURRENT_SECONDARY_ROLES para mostrar todas as funções secundárias ativas para a sessão atual.

Quando você cria um objeto que requer um ou mais privilégios para uso, apenas a função principal e aquelas funções que ele herda direta ou indiretamente são consideradas ao buscar as concessões desses privilégios.

Para qualquer outra instrução que exija um ou mais privilégios (por exemplo, consultar uma tabela exige o privilégio SELECT em uma tabela com o privilégio USAGE no banco de dados e esquema), a função primária, as funções secundárias e quaisquer outras função que são herdadas são consideradas quando se busca a concessão desses privilégios.

Nota

Não existe um conceito de “superusuário” ou “superfunção” no Snowflake que possa ignorar as verificações de autorização. Todo acesso requer privilégios de acesso apropriados.