Práticas recomendadas de controle de acesso

Este tópico descreve as práticas recomendadas e considerações importantes para gerenciar o acesso seguro à sua conta Snowflake e aos dados armazenados na conta. Principalmente, ele fornece orientação geral para configurar o controle de acesso baseado em função (RBAC), que limita o acesso a objetos com base na função de um usuário. Para considerações específicas sobre o controle de acesso baseado no usuário (UBAC), consulte Comparação e verificação de diferenças entre RBAC e UBAC.

Neste tópico:

Uso da função ACCOUNTADMIN

A função de administrador de conta (usuários com a função de sistema ACCOUNTADMIN) é a função mais poderosa do sistema. Esta função é a única responsável pela configuração dos parâmetros no nível da conta. Os usuários com a função ACCOUNTADMIN podem visualizar e gerenciar os dados de faturamento e crédito do Snowflake e podem parar qualquer instrução SQL em execução.

Note que ACCOUNTADMIN não é uma função de superusuário. Esta função só permite visualizar e gerenciar objetos na conta se esta função, ou uma função inferior em uma hierarquia de funções, tiver privilégios suficientes sobre os objetos.

Na hierarquia de funções do sistema, as outras funções de administrador são filhas deste função:

  • A função de administrador de usuários (USERADMIN) inclui os privilégios para criar e administrar usuários e funções (assumindo que a propriedade dessas funções ou usuários não tenha sido transferida para outra função).

  • A função de administrador de segurança (SECURITYADMIN definida pelo sistema) inclui o privilégio global MANAGE GRANTS para conceder ou revogar privilégios em objetos da conta. A função USERADMIN é um filho desta função na hierarquia padrão de controle de acesso. Para obter mais informações sobre as funções filho definidas pelo sistema, consulte Funções definidas pelo sistema.

  • A função de administrador do sistema (SYSADMIN) inclui os privilégios para criar warehouses, bancos de dados e todos os objetos de banco de dados (esquemas, tabelas e assim por diante).

Atenção

Por padrão, quando sua conta é provisionada, ao primeiro usuário é atribuída a função ACCOUNTADMIN. Este usuário deve então criar um ou mais usuários adicionais aos quais é atribuída a função USERADMIN. Todos os usuários restantes devem ser criados pelo(s) usuário(s) com a função USERADMIN ou outra função à qual é concedido o privilégio global CREATE USER.

Controle da atribuição da função ACCOUNTADMIN a usuários

A Snowflake recomenda enfaticamente as seguintes precauções ao atribuir a função ACCOUNTADMIN aos usuários:

  • Atribua esta função somente a um número seleto/limitado de pessoas em sua organização.

  • Todos os usuários atribuídos à função ACCOUNTADMIN também devem ser obrigados a usar autenticação multifator (MFA) para login (para detalhes, consulte Configuração do controle de acesso).

  • Atribua esta função a pelo menos dois usuários. Seguimos rigorosos procedimentos de segurança para redefinir uma senha esquecida ou perdida para os usuários com a função ACCOUNTADMIN. Estes procedimentos podem levar até dois dias úteis. Atribuir a função ACCOUNTADMIN a mais de um usuário evita ter que passar por esses procedimentos porque os usuários podem redefinir as senhas uns dos outros.

Dica

Atribuir endereços de e-mail dos funcionários atuais aos usuários ACCOUNTADMIN ajuda o suporte Snowflake a saber com quem entrar em contato em uma situação urgente.

Evite usar a função ACCOUNTADMIN para criar objetos

A função ACCOUNTADMIN é destinada a executar tarefas de configuração inicial no sistema e gerenciar objetos e tarefas em nível de conta no dia a dia. Como tal, não deve ser usada para criar objetos em sua conta, a menos que você absolutamente precise que esses objetos tenham o mais alto nível de acesso seguro. Se você criar objetos com a função ACCOUNTADMIN e quiser que os usuários tenham acesso a esses objetos, deve conceder explicitamente privilégios sobre os objetos para as funções desses usuários.

Em vez disso, a Snowflake recomenda a criação de uma hierarquia de funções alinhadas com as funções comerciais da organização e, por fim, a atribuição dessas funções à função SYSADMIN. Para obter mais informações, consulte Alinhamento do acesso a objetos com funções empresariais neste tópico.

Dica

Para ajudar a evitar que os administradores de conta usem inadvertidamente a função ACCOUNTADMIN para criar objetos, atribua a esses usuários funções adicionais e designe uma dessas funções como padrão (não faça de ACCOUNTADMIN a função padrão para nenhum usuário do sistema).

Isso não impede que os usuários usem a função ACCOUNTADMIN para criar objetos, mas os obriga a alterar explicitamente sua função para ACCOUNTADMIN sempre que fizerem login. Isso pode ajudar a aumentar a conscientização sobre a finalidade/utilidade das funções no sistema e incentivar os usuários a mudar para a função apropriada para executar uma determinada tarefa, especialmente as tarefas de administrador de contas.

Evite usar a função ACCOUNTADMIN para scripts automatizados

A Snowflake recomenda o uso de uma função diferente de ACCOUNTADMIN para scripts automatizados. Se, como recomendado, você criar uma hierarquia de funções sob a função SYSADMIN, todas as operações de objetos de warehouse e banco de dados podem ser executadas usando a função SYSADMIN ou funções inferiores na hierarquia. As únicas limitações que você encontrará são criar ou modificar usuários ou funções. Estas operações devem ser realizadas por um usuário com a função SECURITYADMIN ou outra função com privilégios de objeto suficientes.

Acesso a objetos de banco de dados

Todos os objetos de banco de dados protegíveis (tais como TABLE, FUNCTION, FILE FORMAT, STAGE, SEQUENCE, etc.) estão contidos dentro de um objeto SCHEMA dentro de um DATABASE. Como resultado, para acessar objetos de banco de dados, além dos privilégios sobre os objetos específicos do banco de dados, os usuários devem ter o privilégio USAGE no banco de dados e esquema de contêiner.

Por exemplo, suponha que mytable seja criado em mydb.myschema. Para consultar mytable, um usuário deve ter, no mínimo, os seguintes privilégios:

Banco de dados:

USAGE para mydb

Esquema:

USAGE para myschema

Tabela:

SELECT para mytable

Gerenciamento de funções personalizadas

Quando uma função personalizada é criada, ela existe isoladamente. A função deve ser atribuída a qualquer usuário que utilize os privilégios de objeto associados à função. A função personalizada também deve ser concedida a qualquer função que irá administrar os objetos criados pela função personalizada.

Importante

Por padrão, nem mesmo a função ACCOUNTADMIN pode modificar ou descartar objetos criados por uma função personalizada. A função personalizada deve ser concedida à função ACCOUNTADMIN diretamente ou, de preferência, a outra função em uma hierarquia com a função SYSADMIN como pai. A função SYSADMIN é gerenciada pela função ACCOUNTADMIN.

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

Alinhamento do acesso a objetos com funções empresariais

Considere tirar proveito das hierarquias de funções para alinhar o acesso aos objetos do banco de dados com as funções empresariais em sua organização. Em uma hierarquia de funções, são atribuídas funções a outras funções para formar uma relação de herança. As permissões concedidas a funções de nível inferior são herdadas por funções de nível superior.

Para flexibilidade ótima no controle de acesso a objetos de banco de dados, crie uma combinação de funções de acesso com diferentes permissões para os objetos e atribua-as conforme apropriado a funções funcionais:

  • Conceda permissões para objetos de banco de dados ou objetos de conta (tais como warehouses) para funções de acesso.

  • Conceda funções de acesso a funções funcionais para criar uma hierarquia de funções. Estas funções correspondem às funções empresariais de sua organização e servem como um grupo genérico para quaisquer funções de acesso necessárias para estas funções.

    Quando apropriado, conceda funções funcionais de nível inferior a funções funcionais de nível superior em uma relação pai-filho, onde as funções pais mapeiam as funções empresariais que devem incluir as permissões de funções filhas.

    Seguindo as práticas recomendadas para hierarquias de funções, conceda as funções funcionais de mais alto nível em uma hierarquia de funções ao administrador do sistema (SYSADMIN). Os administradores de sistema podem então conceder privilégios sobre objetos de banco de dados a quaisquer funções nesta hierarquia:

Nota

Não há diferença técnica entre uma função de acesso a objetos e uma função funcional no Snowflake. A diferença está em como são usadas logicamente para montar e atribuir conjuntos de permissões a grupos de usuários.

Exemplo

Como um exemplo simples, suponha que dois bancos de dados em uma conta, fin e hr, contenham dados da folha de pagamento e dos funcionários, respectivamente. Contadores e analistas em sua organização requerem diferentes permissões sobre os objetos desses bancos de dados para desempenhar suas funções empresariais. Os contadores devem ter acesso de leitura-gravação a fin, mas podem precisar apenas de acesso de leitura a hr porque o pessoal de recursos humanos administra os dados neste banco de dados. Os analistas podem precisar de acesso somente leitura a ambos os bancos de dados.

As permissões para objetos de banco de dados existentes são concedidas através da seguinte hierarquia de funções de acesso e funções funcionais:

Nota

Quando novos objetos forem adicionados a cada banco de dados, considere a possibilidade de conceder automaticamente privilégios nos objetos a funções com base no tipo de objeto (por exemplo, esquemas, tabelas ou exibições). Para obter mais informações, consulte Simplificação do gerenciamento de concessões usando concessões futuras (neste tópico).

Função personalizada

Descrição

Privilégios

db_hr_r

Função de acesso que permite acesso somente leitura às tabelas do banco de dados hr.

USAGE para o banco de dados hr.

USAGE para todos os esquemas do banco de dados hr.

SELECT para todas as tabelas do banco de dados hr.

db_fin_r

Função de acesso que permite acesso somente leitura às tabelas do banco de dados fin.

USAGE para o banco de dados fin.

USAGE para todos os esquemas do banco de dados fin.

SELECT para todas as tabelas do banco de dados fin.

db_fin_rw

Função de acesso que permite acesso de leitura-gravação às tabelas do banco de dados fin.

USAGE para o banco de dados fin.

USAGE para todos os esquemas do banco de dados fin.

SELECT INSERT, UPDATE, DELETE para todas as tabelas do banco de dados fin.

accountant

Função funcional para os contadores em sua organização.

N/A

analyst

Função funcional para os analistas em sua organização.

N/A

O diagrama a seguir mostra a hierarquia de funções para este exemplo:

Exemplo: hierarquia de funções funcionais e de acesso

Para configurar o controle de acesso para este exemplo:

  1. Como administrador de usuários (usuário com a função USERADMIN) ou outra função com o privilégio CREATE ROLE para a conta, crie as funções de acesso e funções funcionais neste exemplo:

    CREATE ROLE db_hr_r;
    CREATE ROLE db_fin_r;
    CREATE ROLE db_fin_rw;
    CREATE ROLE accountant;
    CREATE ROLE analyst;
    
    Copy
  2. Como administrador de segurança (usuário com a função SECURITYADMIN) ou outra função com o privilégio MANAGE GRANTS para a conta, conceda as permissões mínimas exigidas para cada uma das funções de acesso:

    -- Grant read-only permissions on database HR to db_hr_r role.
    GRANT USAGE ON DATABASE hr TO ROLE db_hr_r;
    GRANT USAGE ON ALL SCHEMAS IN DATABASE hr TO ROLE db_hr_r;
    GRANT SELECT ON ALL TABLES IN DATABASE hr TO ROLE db_hr_r;
    
    -- Grant read-only permissions on database FIN to db_fin_r role.
    GRANT USAGE ON DATABASE fin TO ROLE db_fin_r;
    GRANT USAGE ON ALL SCHEMAS IN DATABASE fin TO ROLE db_fin_r;
    GRANT SELECT ON ALL TABLES IN DATABASE fin TO ROLE db_fin_r;
    
    -- Grant read-write permissions on database FIN to db_fin_rw role.
    GRANT USAGE ON DATABASE fin TO ROLE db_fin_rw;
    GRANT USAGE ON ALL SCHEMAS IN DATABASE fin TO ROLE db_fin_rw;
    GRANT SELECT,INSERT,UPDATE,DELETE ON ALL TABLES IN DATABASE fin TO ROLE db_fin_rw;
    
    Copy
  3. Como administrador de segurança (usuário com a função SECURITYADMIN) ou outra função com o privilégio MANAGE GRANTS na conta, conceda a função de acesso db_fin_rw à função funcional accountant, e conceda as funções de acesso db_hr_r db_fin_r à função funcional analyst:

    GRANT ROLE db_fin_rw TO ROLE accountant;
    GRANT ROLE db_hr_r TO ROLE analyst;
    GRANT ROLE db_fin_r TO ROLE analyst;
    
    Copy
  4. Como administrador de segurança (usuário com a função SECURITYADMIN) ou outra função com o privilégio MANAGE GRANTS para a conta, conceda as funções analyst e accountant ao administrador do sistema (SYSADMIN):

    GRANT ROLE accountant,analyst TO ROLE sysadmin;
    
    Copy
  5. Como administrador de segurança (usuário com a função SECURITYADMIN) ou outra função com o privilégio MANAGE GRANTS para a conta, conceda as funções funcionais empresariais aos usuários que desempenham essas funções empresariais em sua organização. Neste exemplo, a função funcional analyst é concedida ao usuário user1, e a função funcional accountant é concedida ao usuário user2.

    GRANT ROLE accountant TO USER user1;
    GRANT ROLE analyst TO USER user2;
    
    Copy

Gerenciamento de acesso ao objeto de banco de dados usando funções de bancos de dados

As funções de banco de dados são essencialmente as mesmas que as funções tradicionais criadas no nível da conta (funções de conta personalizadas), exceto pelo escopo: para permitir ações SQL em objetos dentro de um banco de dados, os privilégios podem ser concedidos a uma função de banco de dados no mesmo banco de dados.

As funções do banco de dados são destinadas a atender aos seguintes casos de uso:

Facilidade de gerenciamento:

Os proprietários de bancos de dados podem gerenciar independentemente o acesso a objetos protegíveis dentro de seus próprios bancos de dados. Os proprietários dos bancos de dados podem realizar as seguintes ações:

  • Criar e gerenciar funções do banco de dados.

  • Conceder privilégios a funções do banco de dados.

    Os privilégios em objetos concedidos às funções do banco de dados devem ter escopo com objetos contidos no banco de dados onde a função existe. Os privilégios em objetos de um banco de dados (como tabelas ou exibições) não podem ser concedidos a funções de banco de dados em outro banco de dados.

    Qualquer privilégio, incluindo OWNERSHIP, pode ser concedido a funções de banco de dados nos objetos em um banco de dados. Observe que somente uma função da conta pode ter o privilégio OWNERSHIP no próprio banco de dados.

  • Criar ou ampliar hierarquias de funções. Conceda funções do banco de dados a outras funções dentro do mesmo banco de dados, e então conceda as funções da banco de dados de mais alto nível em um banco de dados para funções de conta. Para obter mais informações, consulte Hierarquia de funções e herança de privilégios.

    Observe que a concessão de uma função de banco de dados a uma função de conta concede implicitamente o privilégio USAGE no banco de dados que contém a função de banco de dados a essa função de conta. A concessão do privilégio USAGE no banco de dados não é explicitamente exigida.

Compartilhamento de dados:

Os provedores de dados no Secure Data Sharing da Snowflake podem segmentar os objetos protegíveis em um compartilhamento, criando múltiplas funções do banco de dados em um banco de dados para compartilhar e conceder privilégios em um subconjunto dos objetos do banco de dados para cada função do banco de dados. Após criar um banco de dados a partir de um compartilhamento que inclui funções de banco de dados, os consumidores de dados concedem cada função de banco de dados compartilhado a uma ou mais funções de nível de conta em sua própria conta.

Sem funções de banco de dados, os administradores de contas em contas de consumidores de dados concedem um único privilégio, IMPORTED PRIVILEGES, para permitir que seus usuários acessem todos os bancos de dados e objetos de banco de dados (tabelas, exibições seguras etc.) em um compartilhamento. Não há opção para permitir que diferentes grupos de usuários em uma conta de consumidor de dados acessem um subconjunto dos objetos compartilhados. Esta abordagem de tudo ou nada exige que os provedores de dados criem várias ações para conceder acesso a diferentes objetos 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.

Centralização do gerenciamento de concessões usando esquemas de acesso gerenciado

Com esquemas regulares (não gerenciados) em um banco de dados, os proprietários de objetos (funções com o privilégio OWNERSHIP em um ou mais objetos) podem conceder acesso a esses objetos a outras funções, com a opção de conceder ainda mais a essas funções a capacidade de gerenciar concessões de objetos.

Para maior segurança dos objetos, considere o uso de esquemas de acesso gerenciado. 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, incluindo concessões futuras, 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 informações sobre esquemas de acesso gerenciado, consulte Criação de esquemas de acesso gerenciado.

Simplificação do gerenciamento de concessões usando concessões futuras

As concessões futuras permitem definir um conjunto inicial de privilégios em objetos de um determinado tipo (por exemplo, tabelas ou exibições) em um esquema especificado. À medida que novos objetos são criados, os privilégios definidos são automaticamente concedidos a uma função, simplificando o gerenciamento das concessões.

Considere o seguinte cenário, no qual uma determinada função recebe o privilégio SELECT para todas as novas tabelas criadas em um esquema. Em uma data posterior, é tomada a decisão de revogar o privilégio desta função e, em vez disso, concedê-lo a uma função diferente. Usando as palavras-chave ON FUTURE para novas tabelas e a palavra-chave ALL para as tabelas existentes, poucas instruções SQL são necessárias para conceder e revogar privilégios para tabelas novas e existentes. Por exemplo:

-- Grant the SELECT privilege on all new (future) tables in a schema to role R1
GRANT SELECT ON FUTURE TABLES IN SCHEMA s1 TO ROLE r1;

-- / Create tables in the schema /

-- Grant the SELECT privilege on all new tables in a schema to role R2
GRANT SELECT ON FUTURE TABLES IN SCHEMA s1 TO ROLE r2;

-- Grant the SELECT privilege on all existing tables in a schema to role R2
GRANT SELECT ON ALL TABLES IN SCHEMA s1 TO ROLE r2;

-- Revoke the SELECT privilege on all new tables in a schema (future grant) from role R1
REVOKE SELECT ON FUTURE TABLES IN SCHEMA s1 FROM ROLE r1;

-- Revoke the SELECT privilege on all existing tables in a schema from role R1
REVOKE SELECT ON ALL TABLES IN SCHEMA s1 FROM ROLE r1;
Copy

Para obter mais informações sobre futuras concessões, consulte Atribuição de concessões futuras para objetos.

Exibição de resultados de consulta

Um usuário não pode visualizar o conjunto de resultados a partir de uma consulta que outro usuário executou. Este comportamento é intencional. Por razões de segurança, somente o usuário que executou uma consulta pode acessar os resultados da consulta.

Nota

Este comportamento não é conectado ao modelo de controle de acesso do Snowflake para objetos. Mesmo um usuário com a função ACCOUNTADMIN não pode visualizar os resultados de uma consulta executada por outro usuário.

Explicação de objetos clonados e privilégios concedidos

A clonagem de um banco de dados, esquema ou tabela cria uma cópia do objeto original. O objeto clonado inclui um instantâneo dos dados presentes no objeto original quando o clone foi criado.

Um objeto clonado é considerado um novo objeto no Snowflake. Quaisquer privilégios concedidos para o objeto original não são transferidos para o objeto clonado. Entretanto, um objeto de contêiner clonado (um banco de dados ou esquema) retém quaisquer privilégios concedidos para os objetos contidos no objeto original. Por exemplo, um esquema clonado retém quaisquer privilégios concedidos para as tabelas, exibições, UDFs e outros objetos no esquema original.

Para obter mais detalhes sobre clonagem, consulte Considerações sobre clonagem e CREATE <objeto> … CLONE.

Comparação e verificação de diferenças entre RBAC e UBAC

O controle de acesso baseado em função (RBAC) é a base para o controle de acesso no Snowflake. RBAC fornece, por seu design, escalabilidade e controle centralizado. Usando o RBAC, você concede privilégios a funções e, em seguida, atribui usuários a essas funções, simplificando a administração, garantindo a consistência e facilitando o acesso de auditoria. RBAC é geralmente recomendado para ambientes de produção e governança de nível empresarial. O controle de acesso baseado no usuário (UBAC) destina-se a casos de uso como desenvolvimento privado e colaboração.

Você deve considerar o uso do UBAC para cenários colaborativos, como a criação de aplicativos Streamlit. Durante um processo de desenvolvimento colaborativo, o proprietário de um ativo pode querer controlar o acesso ao ativo antes de compartilhá-lo com um público mais amplo. O UBAC complementa o RBAC, oferecendo flexibilidade para conceder privilégios diretamente a usuários individuais. O UBAC é particularmente útil em cenários que se beneficiam de um modelo de controle de acesso mais granular.

O UBAC não fornece aos proprietários de objetos novos níveis de privilégio. Se você atualmente confia nos proprietários de objetos para gerenciar o acesso a seus objetos usando funções no RBAC, o uso do UBAC não altera fundamentalmente esse nível de confiança. Os proprietários de objetos já têm a capacidade de conceder acesso a qualquer função, incluindo funções amplamente acessíveis, como PUBLIC. O UBAC permite que os proprietários de objetos concedam acesso diretamente a usuários específicos. O UBAC não afeta o desempenho da consulta.

Como evitar a proliferação de concessões ao usar o UBAC

Para evitar que os proprietários de objetos concedam acesso indiscriminado a objetos, use os esquemas de acesso gerenciado. Os esquemas de acesso gerenciado removem a capacidade dos proprietários de objetos de conceder acesso a outras funções ou usuários. Somente os proprietários do esquema ou uma função com o privilégio MANAGE GRANTS podem conceder privilégios a objetos em um esquema de acesso gerenciado. A proliferação de concessões pode ocorrer com o uso de UBAC ou RBAC. Fora dos esquemas de acesso gerenciado, os proprietários de objeto podem conceder acesso a qualquer função em uma conta ao usar RBAC, assim como podem conceder privilégios a qualquer usuário ao usar UBAC.

Monitoramento dos privilégios de controle de acesso em sua conta

Você pode monitorar os privilégios concedidos a funções, usuários e aplicativos usando a exibição GRANTS_TO_ROLES em ACCOUNT_USAGE. Para obter mais informações, consulte Exibição GRANTS_TO_ROLES.

Você também pode monitorar os privilégios de controle de acesso em sua conta das seguintes maneiras:

  • Exibição de concessões diretas a todos os usuários

  • Exibição de concessões diretas a usuários específicos

  • Exibição do conjunto atual de privilégios concedidos a um objeto

  • Exibição das permissões atuais em um esquema

  • Exibição dos privilégios em um esquema de banco de dados

  • Exibição do conjunto atual de privilégios concedidos a uma função ou a um usuário

Por exemplo, para visualizar as concessões diretas a todos os usuários, execute a seguinte consulta:

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_ROLES
  WHERE granted_to = 'USER';
Copy

Por exemplo, para mostrar concessões diretas a usuários específicos:

  1. Execute o seguinte comando para mostrar todas as concessões a um usuário específico:

    SHOW GRANTS TO USER <user_name>;
    
    Copy
  2. Filtre o resultado da etapa anterior para mostrar apenas os privilégios concedidos diretamente ao usuário, não por meio de funções:

    SELECT * FROM TABLE(RESULT_SCAN(LAST_QUERY_ID())
     WHERE "role" is null;
    
    Copy

Por exemplo, para visualizar o conjunto atual de privilégios concedidos a um objeto, você pode executar o comando SHOW GRANTS.

Nota

A execução do comando SHOW GRANTS em um objeto específico requer os mesmos privilégios de objeto que a execução do comando SHOW para esse tipo de objeto.

Por exemplo, a execução do comando SHOW GRANTS em uma tabela requer os seguintes privilégios na tabela e em seu banco de dados e esquema:

Banco de dados:

USAGE

Esquema:

USAGE

Tabela:

qualquer privilégio

Por exemplo, para visualizar as permissões atuais em um esquema, execute o seguinte comando:

SHOW GRANTS ON SCHEMA <database_name>.<schema_name>;
Copy

Por exemplo, para visualizar os privilégios em database_a.schema_1 que foram concedidos em Criação de funções personalizadas, execute o seguinte comando:

SHOW GRANTS ON SCHEMA database_a.schema_1;
Copy

O Snowflake retorna os seguintes resultados:

+-------------------------------+-----------------------+------------+----------------------+------------+--------------------------+--------------+---------------+
| created_on                    | privilege             | granted_on | name                 | granted_to | grantee_name             | grant_option | granted_by    |
|-------------------------------+-----------------------+------------+----------------------+------------+--------------------------+--------------+---------------|
| 2022-03-07 09:04:23.635 -0800 | USAGE                 | SCHEMA     | database_a.schema_1  | ROLE       | R1                       | false        | SECURITYADMIN |
+-------------------------------+-----------------------+------------+----------------------+------------+--------------------------+--------------+---------------+

Você também pode executar o comando SHOW GRANTS para visualizar o conjunto atual de privilégios concedidos a você:

  • Uma função:

    SHOW GRANTS TO ROLE <role_name>;
    
    Copy

    Por exemplo, execute o seguinte comando para visualizar os privilégios concedidos na função r1, criada como uma função personalizada:

    SHOW GRANTS TO ROLE r1;
    
    Copy

    O Snowflake retorna os seguintes resultados:

    +-------------------------------+-----------+------------+----------------------+------------+--------------+--------------+---------------+
    | created_on                    | privilege | granted_on | name                 | granted_to | grantee_name | grant_option | granted_by    |
    |-------------------------------+-----------+------------+----------------------+------------+--------------+--------------+---------------|
    | 2022-03-07 09:08:43.773 -0800 | USAGE     | DATABASE   | D1                   | ROLE       | R1           | false        | SECURITYADMIN |
    | 2022-03-07 09:08:55.253 -0800 | USAGE     | SCHEMA     | D1.S1                | ROLE       | R1           | false        | SECURITYADMIN |
    | 2022-03-07 09:09:07.206 -0800 | SELECT    | TABLE      | D1.S1.T1             | ROLE       | R1           | false        | SECURITYADMIN |
    | 2022-03-07 09:08:34.838 -0800 | USAGE     | WAREHOUSE  | W1                   | ROLE       | R1           | false        | SECURITYADMIN |
    +-------------------------------+-----------+------------+----------------------+------------+--------------+--------------+---------------+
    
  • Um usuário:

    SHOW GRANTS TO USER <user_name>;
    
    Copy

    Por exemplo, execute o seguinte comando para visualizar os privilégios concedidos ao usuário user1:

    SHOW GRANTS TO USER user1;
    
    Copy

    O Snowflake retorna os seguintes resultados:

    +-------------------------------+-----------+------------+---------------------------+-----------+------------+--------------+--------------+---------------+
    | created_on                    | privilege | granted_on | name                      |  role     | granted_to | grantee_name | grant_option | granted_by    |
    |-------------------------------+-----------+------------+---------------------------+-----------+------------+--------------+------------------------------|
    | 2025-05-07 09:08:43.773 -0800 | USAGE     | DATABASE   | test_db                   | null      | USER       | user1        | false        | SECURITYADMIN |
    | 2025-05-07 09:08:55.253 -0800 | USAGE     | SCHEMA     | test_db.test_sch          | null      | USER       | user1        | false        | SECURITYADMIN |
    | 2025-05-07 09:08:55.253 -0800 | SELECT    | TABLE      | test_db.test_sch.test_tbl | null      | USER       | user1        | false        | SECURITYADMIN |
    | 2025-05-07 09:08:34.838 -0800 | USAGE     | WAREHOUSE  | test_wh                   | null      | USER       | user1        | false        | SECURITYADMIN |
    +-------------------------------+-----------+------------+---------------------------+-----------+------------+--------------+--------------+---------------+