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 da Snowflake para o controle de acesso combina os aspectos dos seguintes modelos:

  • 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.

  • Controle de acesso baseado no usuário (UBAC): os privilégios de acesso são atribuídos diretamente aos usuários. O controle de acesso considera os privilégios atribuídos diretamente aos usuários somente quando USE SECONDARY ROLE estiver definido como ALL.

Para obter mais informações sobre funções secundárias, consulte USE SECONDARY ROLES e Autorização por meio de função primária e funções secundárias.

Vários conceitos fundamentais para entender o controle de acesso no Snowflake incluem:

  • 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.

  • 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 ela associada a uma pessoa ou a um serviço. Um usuário também é uma entidade à qual podem ser concedidos privilégios.

No Snowflake, os privilégios atribuídos a funções ou usuários permitem o acesso a objetos seguros. As funções podem ser atribuídas a usuários ou a outras funções. A concessão de uma função a outra função cria uma hierarquia de funções, descrita com mais detalhes em Hierarquia de funções e herança de privilégios. Normalmente, você usa o RBAC para gerenciar o acesso a objetos seguros no Snowflake.

O diagrama a seguir ilustra como DAC, RBAC e UBAC oferecem suporte à atribuição adequada de privilégios em diferentes objetos protegíveis. Neste exemplo, a função 1 tem o privilégio OWNERSHIP tanto no objeto 1 quanto no objeto 2. Em outras palavras, a função 1 é proprietária de ambos os objetos. Isso ilustra o DAC.

Os privilégios no objeto 1 podem ser concedidos à função 2, que pode então ser concedida ao usuário 1 e ao usuário 2. Em outras palavras, o usuário 1 e o usuário 2 têm acesso ao objeto 1, limitado por esses privilégios, porque ambos os usuários têm a função 2. Esta parte da figura ilustra o RBAC.

Os privilégios no objeto 2 podem ser concedidos diretamente ao usuário 3 e ao usuário 4. Esta parte da figura ilustra como você pode usar o UBAC para estender a estrutura de controle de acesso do Snowflake, fornecendo uma quantidade significativa de controle e flexibilidade.

Relações de controle de acesso

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:

Hierarquia de objetos de banco de dados protegíveis

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 (a função com o privilégio OWNERSHIP no esquema) ou uma função com o privilégio MANAGE GRANTS pode conceder privilégios a 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. Por exemplo, se a função ativa em sua sessão tiver recebido os privilégios CREATE, USAGE, SELECT e WRITE em um esquema de banco de dados Snowflake específico, você poderá criar um warehouse, listar as tabelas contidas e adicionar dados a uma tabela nesse esquema.

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. Isso permite que os usuários troquem de função (ou seja, escolham qual função está ativa na sessão atual do Snowflake) para executar ações diferentes 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 às 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.

Nota

O proprietário de uma função (a função que tem o privilégio OWNERSHIP na 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.

Dica

Você pode usar grupos de usuários da organização para implementar funções consistentes em todas as contas de uma organização. Para obter mais informações, consulte Usuários da organização.

Tipos de funções

Os seguintes tipos de função variam em seu escopo, o que permite que os administradores autorizem e restrinjam 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:

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 do aplicativo:

Para permitir o acesso do consumidor aos objetos em um Snowflake Native App, o provedor cria a função do aplicativo e concede privilégios à função do aplicativo no script de configuração.

No entanto, para oferecer suporte a funcionalidades específicas a um determinado recurso, como conceder acesso a objetos dos quais o Snowflake é o proprietário, o Snowflake pode fornecer uma ou mais funções de aplicativo do sistema. Você pode conceder funções de aplicativo do sistema a funções de conta a seu critério.

As funções de aplicativo do sistema são discutidas no contexto de um recurso específico porque esse recurso é o único lugar em que você pode usar as funções de aplicativo do sistema. Por exemplo:

Funções de serviço:

Para permitir que uma função acesse pontos de extremidade do serviço, conceda a função de serviço a essa função. Você pode conceder uma função de serviço a uma função de conta, uma função de aplicativo ou uma função de banco de dados. Para obter mais informações, consulte Gerenciar privilégios relacionados ao serviço.

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

GLOBALORGADMIN:

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

Função que executa tarefas no nível da organização, como o gerenciamento do ciclo de vida das contas e a exibição de informações de uso no nível da organização. A função existe somente na conta da organização.

ORGADMIN:

Função que usa uma conta normal para gerenciar operações no nível da organização. A função ORGADMIN será eliminada em um lançamento futuro, portanto, os administradores da organização são incentivados a usar a função GLOBALORGADMIN.

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.

    Nota

    O privilégio MANAGE GRANTS oferece a capacidade de conceder e revogar privilégios. Isso não dá ao SECURITYADMIN a capacidade de realizar outras ações, como criar objetos. Para criar um objeto, a função SECURITYADMIN também deve receber os privilégios necessários para criar o objeto. Por exemplo, para criar uma função de banco de dados, o SECURITYADMIN também deve receber o privilégio CREATE DATABASE ROLE, conforme descrito em Requisitos de controle de acesso de CREATE DATABASE ROLE.

  • Herda os privilégios da função USERADMIN por meio da hierarquia de funções do sistema (ou seja, a função USERADMIN é concedida a 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 em 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 do banco de dados podem ser criadas pelo proprietário do banco de dados (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 em objetos individuais (como 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 em objetos criados em um esquema (por exemplo, conceder o privilégio SELECT em todas as novas tabelas criadas no esquema myschema a uma função especificada).

Os privilégios são gerenciados por meio dos seguintes comandos:

Em esquemas regulares (não gerenciados), o uso desses comandos é restrito à função que possui um objeto (tem o privilégio OWNERSHIP no objeto), a quaisquer funções ou usuários que tenham o privilégio global MANAGE GRANTS para o objeto (somente 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 do exemplo é concedida a uma função de conta personalizada (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:

Exemplo de hierarquia de funções

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.

Herança de privilégios para funções concedidas

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.

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

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.

Autorização por meio de função primária e funções secundárias

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

  1. 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.

  2. 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.

  3. 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.

Para visualizar a função atual de uma sessão, execute a função CURRENT_ROLE.

Além disso, um conjunto de funções secundárias pode ser ativado em uma sessão de 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. Observe que, embora uma sessão deva ter exatamente uma função primária ativa por vez, ela pode ativar qualquer número de funções secundárias ao mesmo tempo.

Nota

Uma função de banco de dados não pode ser nem primária nem 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 for proprietária de um objeto (tiver o privilégio OWNERSHIP no objeto), as funções secundárias autorizarão a execução de qualquer ação DDL no objeto. Tanto a função principal quanto todas as funções secundárias herdam privilégios de quaisquer funções inferiores em suas hierarquias de funções.

Operações de função primária e secundária

Para organizações cujo modelo de segurança inclui um grande número de funções, cada uma com uma granularidade fina de autorização definida por 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 o curso de uma sessão, você pode executar o comando USE ROLE ou USE SECONDARY ROLES para alterar as funções primárias ou secundárias atuais, respectivamente. Você pode usar a função CURRENT_SECONDARY_ROLES para mostrar todas as funções secundárias ativas da 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 no esquema), a função primária, as funções secundárias e quaisquer outras funções herdadas são consideradas na pesquisa das concessões 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.

Linguagem: Português