Controle de acesso a tabelas dinâmicas

Este tópico discute os privilégios necessários para realizar operações com tabelas dinâmicas, como criação, consulta, alteração, exibição e exclusão.

Para obter mais informações sobre o modelo de privilégio Snowflake, consulte Visão geral do controle de acesso e Privilégios de controle de acesso.

Transferência de propriedade

Para fornecer a um usuário acesso total a uma tabela dinâmica, você pode fazer o seguinte:

Ao atribuir concessões, certifique-se de especificar o tipo de objeto como DYNAMIC TABLE porque as tabelas dinâmicas têm um conjunto de privilégios diferente das tabelas regulares.

Para conceder o privilégio OWNERSHIP em tabelas dinâmicas, certifique-se de que a função receptora tenha o privilégio USAGE nos seguintes itens. Caso contrário, as atualizações agendadas subsequentes falharão.

  • O banco de dados e o esquema que contém a tabela dinâmica.

  • O warehouse usado para atualizar a tabela.

Para transferir a propriedade de uma tabela dinâmica, você pode usar o comando GRANT OWNERSHIP ou o Snowsight.

O exemplo a seguir usa o comando GRANT OWNERSHIP para conceder os privilégios de propriedade em my_dynamic_table para a função budget_admin.

GRANT OWNERSHIP ON DYNAMIC TABLE my_dynamic_table TO ROLE budget_admin;
Copy

O exemplo a seguir usa o comando GRANT OWNERSHIP para conceder os privilégios de propriedade em todas as futuras tabelas dinâmicas criadas no esquema mydb.myschema à função budget_admin.

GRANT OWNERSHIP ON FUTURE DYNAMIC TABLES IN SCHEMA mydb.myschema TO ROLE budget_admin;
Copy

Para saber mais sobre o modelo de privilégio Snowflake, consulte Visão geral do controle de acesso e Privilégios de controle de acesso.

Atualizar tabelas dinâmicas com funções secundárias e privilégios de usuário específicos

As tabelas dinâmicas podem ser configuradas para serem atualizadas com os privilégios de um usuário específico, além dos privilégios da função de proprietário. As tabelas dinâmicas que especificam EXECUTE AS USER são executadas em nome do usuário nomeado, em vez do usuário do sistema.

Por exemplo, você pode conceder a um usuário uma função primária que fornece acesso a uma tabela e uma função secundária que fornece acesso a um warehouse virtual. O usuário pode então criar uma tabela dinâmica que opera com os privilégios combinados de ambas as funções, simplificando o gerenciamento de privilégios e aumentando a flexibilidade das suas operações de dados.

Embora a opção EXECUTE AS USER permita que as tabelas dinâmicas sejam atualizadas sob a função do usuário, todas as outras operações nessas tabelas dinâmicas seguem o modelo de privilégio padrão.

Principais casos de uso

  • Gerenciar privilégios de múltiplas funções: em situações em que os usuários têm funções secundárias, eles podem criar e atualizar uma tabela dinâmica usando os privilégios combinados de suas funções primária e secundária. Essa configuração garante que o usuário que está atualizando a tabela dinâmica tenha as permissões necessárias para acessar todos os recursos necessários, mantendo a consistência com os controles de acesso baseados em funções existentes.

  • Controles granulares de segurança e governança: os usuários podem configurar medidas de segurança opcionais com opções adicionais, como REQUIRE USER, em que uma tabela dinâmica não pode ser executada a menos que um usuário seja especificado.

  • Responsabilidade por todas as operações: todas as atualizações em uma tabela dinâmica EXECUTE AS USER são atribuídas ao usuário configurado em vez de ao usuário SYSTEM. Essa atribuição ajuda a manter uma trilha de auditoria clara para todas as operações.

Controle de acesso

A função de proprietário da tabela dinâmica deve receber o privilégio IMPERSONATE no usuário especificado por EXECUTE AS USER, e o usuário especificado deve receber a função de proprietário da tabela dinâmica. Se o privilégio IMPERSONATE for revogado, a atualização da tabela dinâmica falhará e a tabela dinâmica poderá ser suspensa automaticamente.

Quando a tabela dinâmica é atualizada, a função primária da sessão de atualização é a função de proprietário da tabela dinâmica, e as funções secundárias padrão do usuário são ativadas. Os usuários podem alternar entre funções primárias com o comando USE ROLE e ajustar as funções secundárias na sessão de atualização com o comando USE SECONDARY ROLES.

Considerações entre produtos

  • Políticas de acesso a linhas e mascaramento de dados: as políticas, por exemplo, aquelas que usam CURRENT_USER(), são avaliadas com base no usuário e nas funções especificadas em vez de no usuário SYSTEM.

  • Replicação e failover: o nome de usuário e o nome da função são replicados para as implantações secundárias.

    Se um usuário ou uma função não estiver disponível na implantação secundária, o usuário será marcado como INVALID e as atualizações falharão até que o problema seja corrigido.

    Funções secundárias inválidas serão ignoradas durante a execução se as funções restantes fornecerem privilégios suficientes.

Exemplos

Configurar uma tabela dinâmica para executar atualizações como um usuário

O exemplo a seguir cria uma tabela dinâmica que executa atualizações como o usuário especificado, com a função primária definida como a função de proprietário da tabela dinâmica. As atualizações são executadas com todos os parâmetros de linhagem de usuário que o usuário tenha definido.

Se nenhuma opção para funções secundárias for explicitamente especificada, a atualização usará por padrão a configuração da sessão atual do usuário.

CREATE DYNAMIC TABLE my_dynamic_table
  [ EXECUTE AS USER my_user_name
    [ USE SECONDARY ROLES { ALL | NONE | (<role1>, <role2>, ... ) } ]
  ]
Copy

Definir uma função secundária para uma tabela dinâmica existente

O exemplo a seguir configura uma tabela dinâmica para ser executada como o usuário especificado. Se nenhuma função secundária específica for selecionada, o processo de atualização usará por padrão as funções secundárias ativas da sessão atual. Se a tabela dinâmica já estiver configurada para ser executada como um usuário específico, este comando atualizará a configuração para ser executada como o usuário que executa o comando ALTER DYNAMIC TABLE.

A execução deste comando requer o privilégio OWNERSHIP na tabela dinâmica.

ALTER DYNAMIC TABLE my_dynamic_table SET
  EXECUTE AS USER my_user_name
  [ USE SECONDARY ROLES { ALL | NONE | (<role1>, <role2>, ... ) } ]
Copy

Alternar uma tabela dinâmica para ser executada como o usuário SYSTEM

O exemplo a seguir reverte uma tabela dinâmica para ser executada sob o usuário SYSTEM usando a função de proprietário da tabela dinâmica.

A execução deste comando requer o privilégio OWNERSHIP na tabela dinâmica.

ALTER DYNAMIC TABLE my_dynamic_table UNSET EXECUTE AS USER;
Copy

Privilégios para criar uma tabela dinâmica

Para criar uma tabela dinâmica, você deve usar uma função que tenha os seguintes privilégios:

Privilégio

Objeto

CREATE DYNAMIC TABLE

Esquema no qual você planeja criar a tabela dinâmica.

SELECT

As tabelas e exibições existentes que você planeja consultar para a nova tabela dinâmica.

USAGE

Banco de dados e esquema que você planeja usar para a nova tabela dinâmica.

Warehouse que você planeja usar para atualizar a tabela.

Nota

Embora você possa executar CREATE DYNAMIC TABLE ... INITIALIZE = ON_SCHEDULE com uma função secundária que tenha o privilégio USAGE, a tabela dinâmica não será atualizada com sucesso se a função primária não tiver esse privilégio e, portanto, ela não será inicializada.

Para criar uma tabela dinâmica que depende de outra tabela dinâmica, você deve usar uma função que tenha os seguintes privilégios:

Privilégio

Objeto

SELECT

Tabela dinâmica que você planeja consultar para criar a nova tabela dinâmica.

OPERATE

Todas as tabelas dinâmicas upstream das quais a nova tabela dinâmica depende. Necessário apenas se você definir a tabela dinâmica para ser atualizada de forma síncrona na criação.

Privilégios para consultar uma tabela dinâmica

Para consultar uma tabela dinâmica, você pode usar uma função que tenha privilégios para criar uma tabela dinâmica. Para cenários em que um usuário só precisa consultar uma tabela dinâmica – por exemplo, um analista de dados – use uma função que tenha os seguintes privilégios:

Privilégio

Objeto

USAGE

Banco de dados e esquema que contém a tabela dinâmica.

Warehouse utilizado para executar a consulta.

SELECT

A tabela dinâmica que está sendo consultada.

Privilégios para alterar uma tabela dinâmica

Para alterar uma tabela dinâmica, você deve usar uma função que tenha o privilégio OWNERSHIP ou OPERATE nessa tabela dinâmica.

Se você tiver o privilégio OPERATE em uma tabela dinâmica, poderá fazer o seguinte com o comando ALTER DYNAMIC TABLE:

Se você tiver o privilégio OWNERSHIP em uma tabela dinâmica, poderá fazer o seguinte, além das operações listadas acima:

Privilégios para visualizar os metadados de uma tabela dinâmica

Para exibir metadados, você deve usar uma função que tenha privilégio MONITOR nessa tabela dinâmica.

Para cenários em que o usuário só precisa visualizar os metadados e a exibição Information Schema de uma tabela dinâmica (por exemplo, funções ocupadas por cientistas de dados), use uma função que tenha o privilégio MONITOR nessa tabela dinâmica. Embora o privilégio OPERATE conceda esse acesso, ele também inclui a capacidade de alterar tabelas dinâmicas, tornando MONITOR a opção mais adequada para cenários em que um usuário não precisa alterar uma tabela dinâmica.

Se você tiver o privilégio MONITOR em uma tabela dinâmica, poderá fazer o seguinte:

  • Usar o comando DESCRIBE DYNAMIC TABLE e a página de detalhes de tabelas dinâmicas Snowsight para visualizar os detalhes específicos de uma tabela dinâmica. Os campos a seguir ficarão ocultos se você tiver apenas o privilégio SELECT em uma tabela dinâmica: text, warehouse, scheduling_state, last_suspended_on e suspend_reason_code (somente UI).

  • Usar o comando SHOW DYNAMIC TABLES para visualizar a quais tabelas dinâmicas você tem acesso.

  • Chame a função de tabela DYNAMIC_TABLE_GRAPH_HISTORY para exibir o histórico do gráficos.

  • Chame a função de tabela DYNAMIC_TABLE_REFRESH_HISTORY para exibir o histórico de atualizações.

Privilégios para descartar uma tabela dinâmica

Para descartar uma tabela dinâmica, você deve usar uma função que tenha o privilégio OWNERSHIP nessa tabela dinâmica.

Privilégios para uso de warehouses duplos

Todos os requisitos de privilégio para usar INITIALIZATION_WAREHOUSE são os mesmos que WAREHOUSE.

Operação

Privilégio

CREATE DYNAMIC TABLE usando INITIALIZATION_WAREHOUSE

CREATE DYNAMIC TABLE e USAGE em ambos os warehouses, o WAREHOUSE e INITIALIZATION_WAREHOUSE.

ALTER DYNAMIC TABLE … SET / UNSET INITIALIZATION_WAREHOUSE

OWNERSHIP ou OPERATE na tabela dinâmica e USAGE no warehouse aplicável.

ALTER DYNAMIC TABLE … REFRESH em uma tabela dinâmica que usa INITIALIZATION_WAREHOUSE

OPERATE na tabela dinâmica e USAGE no warehouse aplicável.

Para obter mais informações, consulte Entender o uso do warehouse para tabelas dinâmicas.