Explicação de políticas de acesso a linhas¶

Como funciona uma política de acesso a linhas?¶

Uma política de acesso a linhas contém uma expressão que pode especificar objetos do banco de dados Snowflake (por exemplo, tabela ou exibição) e usar Funções de expressão condicional e Funções de contexto para determinar quais linhas devem ser visíveis em um determinado contexto.

O Snowflake avalia a expressão da política usando a função do proprietário da política, e não a função do operador que executou a consulta. Essa abordagem permite que o Snowflake não retorne uma linha em um resultado de consulta porque o operador da consulta não requer acesso às tabelas de mapeamento na política de acesso a linhas.

Políticas de acesso a linhas no tempo de execução da consulta¶

No tempo de execução da consulta, o Snowflake passa pelo seguinte processo:

1. O Snowflake determina se uma política de acesso a linhas está definida em um objeto de banco de dados. Se uma política for adicionada ao objeto do banco de dados, todas as linhas serão protegidas pela política.

2. O Snowflake cria uma exibição dinâmica segura (ou seja, uma exibição segura em linha) do objeto do banco de dados.

3. Os valores das colunas especificadas no comando ALTER TABLE ou ALTER VIEW (ou seja, ao adicionar uma política de acesso a linhas a uma tabela ou exibição) são vinculados aos parâmetros correspondentes na política, e a expressão da política é avaliada.

4. O Snowflake gera a saída da consulta para o usuário, que contém apenas linhas baseadas na definição da política avaliadas como TRUE.

Para obter mais detalhes sobre o plano de execução específico, consulte Perfil de consulta (neste tópico).

O Snowflake aceita políticas de acesso a linhas aninhadas, como uma política de acesso a linhas em uma tabela e uma política em uma exibição para a mesma tabela. No tempo de execução da consulta, o Snowflake avalia todas as políticas de acesso que são relevantes para uma determinada consulta na sequência a seguir:

• A política de acesso a linhas aplicável à tabela é sempre executada em primeiro lugar.

• A política para a exibição é executada após a avaliação da política para a tabela.

• Se existirem exibições aninhadas (por exemplo, Tabela 1 -> Exibição 1 -> Exibição 2 -> … Exibição n), as políticas serão aplicadas em ordem sequencial da esquerda para a direita.

Esse padrão continua por todas as políticas de acesso a linhas que houver em relação aos dados da consulta. O diagrama a seguir ilustra a relação entre um operador de consulta, tabelas, exibições e políticas.

Para obter mais informações sobre privilégios de políticas de acesso a linhas, comandos e uma implementação passo a passo, consulte:

• Privilégios da política de acesso a linhas

• DDL da política de acesso a linhas

• Uso de políticas de acesso a linhas

Caso de uso representativo: filtragem de linhas simples¶

Uma aplicação simples de uma política de acesso a linhas é especificar um atributo na política e uma função com permissão para ver esse atributo no resultado da consulta. A vantagem de políticas simples como essa é que há um custo de desempenho insignificante para o Snowflake avaliar essas políticas e retornar resultados de consulta, em comparação com o uso de políticas de acesso a linhas com tabelas de mapeamento.

Como exemplo representativo, pode ser necessário que administradores de tecnologia da informação (por exemplo, função personalizada it_admin) consultem um número de identificação do funcionário (ou seja, empl_id) antes de conceder ao funcionário privilégios adicionais para utilizar sistemas internos. Portanto, a política de acesso a linhas deve retornar linhas no resultado da consulta se o CURRENT_ROLE corresponder à função personalizada it_admin e não retornar linhas para todas as outras funções. Por exemplo:

CREATE OR REPLACE ROW ACCESS POLICY rap_it
AS (empl_id varchar) RETURNS BOOLEAN ->
  'it_admin' = current_role()
;

Essa política é a versão mais concisa de uma política de acesso a linhas porque não há outras condições para avaliar, apenas o valor de CURRENT_ROLE.

Se a hierarquia de funções precisar ser considerada, essa política também poderia usar IS_ROLE_IN_SESSION para permitir que outras funções vejam o número de ID do funcionário no resultado da consulta.

Alternativamente, para considerar condições adicionais, usar a função CASE permite incluir cláusulas WHEN/THEN/ELSE para dar suporte a uma lógica condicional mais detalhada.

Caso de uso representativo: uso de uma tabela de mapeamento para filtrar o resultado da consulta¶

Uma condição de política de acesso a linhas pode fazer referência a uma tabela de mapeamento para filtrar o conjunto de resultados da consulta; entretanto, o uso de tabelas de mapeamento pode resultar em redução de desempenho em comparação ao exemplo mais simples.

Por exemplo, use uma tabela de mapeamento para determinar os valores de receita que um gerente de vendas pode ver em uma região de vendas especificada. A tabela de mapeamento deve especificar o gerente de vendas e a região de vendas (por exemplo, WW: Global, NA: América do Norte, EU: União Europeia).

Gerente de vendas	Região
Alice	WW
Bob	NA
Simon	EU

Em seguida, defina uma política com uma ou mais condições para consultar a tabela de mapeamento com uma subconsulta. No tempo de execução da consulta, o Snowflake determina se o usuário que executa a consulta corresponde à região de vendas especificada na tabela de mapeamento.

Se ocorrer uma correspondência, o usuário poderá ver essas linhas no resultado da consulta. Com base na tabela de mapeamento, os resultados esperados da consulta são os seguintes:

Empresa	Região	Receita	Quem pode ver
Acme	EU	2,5 B	Alice, Simon
Acme	NA	1,5 B	Alice, Bob

Para detalhes sobre a implementação de uma política de acesso a linhas com uma tabela de mapeamento, consulte:

• Tabelas externas (neste tópico)

• Uso de políticas de acesso a linhas

Diretrizes de desempenho de políticas¶

Políticas de acesso a linhas são projetadas para funcionar bem em uma grande variedade de cenários do mundo real. Use as seguintes dicas para proteger os dados e melhorar o desempenho:

Limitar os argumentos da política:

O Snowflake precisa verificar colunas às quais a política está vinculada, mesmo que elas não sejam referenciadas em consultas. Portanto, as políticas com menos argumentos geralmente terão melhor desempenho do que as políticas com muitos argumentos.

Simplificar a expressão SQL.:

Políticas com expressões SQL simples, tais como instruções CASE, geralmente têm melhor desempenho do que as políticas que acessam tabelas de mapeamento (ou seja, pesquisa). Minimizar o número de pesquisas na tabela melhora o desempenho.

Ao especificar uma tabela de mapeamento, substitua a referência da tabela de mapeamento por uma função memoizável. Para obter mais detalhes, consulte:

• Função memoizável (na visão geral do UDF SQL escalar).

• Usando uma função memoizável em uma política (no tópico Utilização de políticas de acesso a linhas).

Testar com cargas de trabalho realistas:

Sem uma política de acesso a linhas, a consulta SELECT COUNT(*) FROM t1 é executada em milissegundos, pois o Snowflake já sabe o número de linhas na tabela. Entretanto, adicionar uma política de acesso a linhas significa que o Snowflake precisa examinar a tabela para contar o número de linhas que são acessíveis no contexto atual. Embora a diferença de desempenho seja grande, essa consulta não é representativa da maioria das cargas de trabalho do mundo real.

Para obter mais informações sobre este exemplo, consulte a seção Considerações (neste tópico).

Agrupar por atributos:

Para tabelas muito grandes, o agrupamento por atributos utilizados para a filtragem de políticas pode melhorar o desempenho.

Para obter mais informações, consulte Chaves de clustering e tabelas clusterizadas.

Serviço de otimização de pesquisa:

O serviço de otimização de pesquisa pode melhorar o desempenho da consulta em uma tabela que utiliza uma política de mascaramento ou de acesso a linhas.

Para obter mais detalhes, consulte Suporte para tabelas com políticas de mascaramento e políticas de acesso a linhas no serviço de otimização de pesquisa.

Benefícios¶

O principal benefício de uma política de acesso a linhas é permitir que uma organização equilibre adequadamente a segurança, governança e análise de dados através de uma política extensível. A natureza extensível da política de acesso a linhas permite que uma ou mais condições sejam adicionadas ou removidas a qualquer momento para garantir que a política seja consistente com atualizações de dados, tabelas de mapeamento e a hierarquia RBAC.

Os benefícios adicionais incluem:

Facilidade de uso:

Grave uma política uma vez e aplique-a a tabelas em bancos de dados e esquemas.

Gerenciamento de alterações:

Altere facilmente as definições da política de acesso a linhas sem ter que reaplicar a política às tabelas.

Se usar uma tabela de mapeamento, atualize as informações de direitos na tabela de mapeamento referenciada pela política sem ter que alterar a política.

Administração de dados e SoD:

Um administrador de dados central, e não o proprietário do objeto, decide quais objetos proteger. As políticas de acesso a linhas são fáceis de gerenciar e apoiar através de modelos de administração centralizada, descentralizada e híbrida para proporcionar a segregação de funções (ou seja, SoD).

Autorização e governança de dados:

A política de acesso a linhas permite o acesso a dados contextuais por função ou direitos personalizados.

Limitações¶

• O uso da cláusula CHANGES em uma exibição protegida por uma política de acesso a linhas não é aceito.

• O Snowflake não aceita o uso de tabelas externas como uma tabela de mapeamento em uma política de acesso a linhas. Para obter mais informações, consulte Tabelas externas (neste tópico).

• O Snowflake não permite anexar uma política de acesso a linhas ao próprio objeto de fluxo, mas aplica a política à tabela quando o fluxo acessa uma tabela protegida por uma política de acesso a linhas. Para obter mais informações, consulte Fluxos (neste tópico).

• Não há suporte para futuras concessões de privilégios em políticas de acesso a linhas.

  Como alternativa, conceda o privilégio APPLYROW ACCESS POLICY a uma função personalizada para permitir que essa função aplique políticas de acesso a linhas em uma tabela ou exibição.

Considerações¶

• Anexar políticas de acesso a linhas a tabelas que são protegidas por outras políticas de acesso a linhas ou políticas de mascaramento pode causar erros. Para obter mais informações, consulte ALTER TABLE, ALTER EXTERNAL TABLE e ALTER VIEW.

• Incluir uma ou mais subconsultas no corpo da política pode causar erros. Quando possível, limite o número de subconsultas, limite o número de operações JOIN e simplifique as condições da cláusula WHERE.

• O Snowflake mantém estatísticas sobre colunas de tabelas e exibições que tornam possível responder a muitas consultas simples em milissegundos. Exemplos de tais consultas incluem o uso da função COUNT, select count(*) from my_table e a função MAX, select max(c) from my_table.

  Geralmente, essas estatísticas e otimizações não são aplicáveis com uma política de acesso a linhas, já que o Snowflake deve identificar o subconjunto de linhas que a consulta pode acessar. A execução de consultas deste tipo em tabelas e exibições com uma política de acesso a linhas pode levar mais tempo do que o esperado para obter os resultados da consulta, uma vez que essas estatísticas e otimizações não são utilizadas, e as estatísticas retornadas são baseadas apenas no que é permitido acessar, não nos valores estatísticos “verdadeiros” (ou seja, estatísticas na tabela ou exibição sem uma política de acesso a linhas).

• Tenha cuidado ao criar o script de configuração para um Snowflake Native App quando a política de acesso a linhas existir em um esquema com versão. Para obter detalhes, consulte considerações sobre esquema com versão.

Obtenção de objetos de banco de dados com uma política de acesso a linhas¶

A função de tabela POLICY_REFERENCES do Information Schema pode retornar informações sobre a política de acesso a linhas atribuída a um determinado objeto.

• Todos os objetos para uma determinada política:

  Especificar o nome da política de acesso a linhas (como mydb.policies.rap1):

  SELECT *
  FROM TABLE(
    mydb.INFORMATION_SCHEMA.POLICY_REFERENCES(
      POLICY_NAME=>'mydb.policies.rap1'
    )
  );
  

  Copy

• A política atribuída a um objeto específico:

  Especificar o nome do objeto (como mydb.tables.t1) e o domínio do objeto (como table):

  SELECT *
  FROM TABLE(
    mydb.INFORMATION_SCHEMA.POLICY_REFERENCES(
      REF_ENTITY_NAME => 'mydb.tables.t1',
      REF_ENTITY_DOMAIN => 'table'
    )
  );
  

  Copy

Observe que esta função de tabela é complementar à exibição POLICY_REFERENCES de Account Usage.

Hierarquia de funções ativa e tabelas de mapeamento¶

As condições da política podem avaliar as funções primárias e secundárias ativas do usuário em uma sessão diretamente, procurar as funções ativas em uma tabela de mapeamento, ou fazer ambos dependendo de como o administrador da política quer escrever a política. Se a política contiver uma pesquisa de tabela de mapeamento, crie uma tabela de mapeamento centralizada e armazene-a no mesmo banco de dados que a tabela protegida. Isto é especialmente importante se a política chamar a função IS_DATABASE_ROLE_IN_SESSION. Para obter mais detalhes, consulte a função notas de uso.

Para esses casos de uso, a Snowflake recomenda gravar as condições de política para chamar a função IS_ROLE_IN_SESSION ou IS_DATABASE_ROLE_IN_SESSION dependendo se você deseja especificar uma função de conta ou de banco de dados. Para exemplos, consulte:

• Seção Exemplos na função IS_ROLE_IN_SESSION.

• IS_DATABASE_ROLE_IN_SESSION

• Compartilhamento de dados protegidos por uma política

Aplicação de uma política de acesso a linhas a uma tabela ou exibição¶

Há duas opções para adicionar uma política de acesso a linhas a uma tabela ou exibição:

1. Com uma nova tabela ou exibição, aplique a política a uma tabela com uma instrução CREATE TABLE ou uma exibição com uma instrução CREATE VIEW.

2. Com uma tabela ou exibição existente, aplique a política a uma tabela com uma instrução ALTER TABLE ou uma exibição com uma instrução ALTER VIEW.

Para uma nova tabela ou exibição, execute as seguintes instruções:

-- table
CREATE TABLE sales (
  customer   varchar,
  product    varchar,
  spend      decimal(20, 2),
  sale_date  date,
  region     varchar
)
WITH ROW ACCESS POLICY sales_policy ON (region);

-- view
CREATE VIEW sales_v WITH ROW ACCESS POLICY sales_policy ON (region)
AS SELECT * FROM sales;

Copy

Para uma tabela ou exibição existente, execute as seguintes instruções:

-- table

ALTER TABLE t1 ADD ROW ACCESS POLICY rap_t1 ON (empl_id);

-- view

ALTER VIEW v1 ADD ROW ACCESS POLICY rap_v1 ON (empl_id);

Copy

Políticas de mascaramento¶

Quando um objeto de banco de dados tem uma política de acesso a linhas e uma ou mais políticas de mascaramento, o Snowflake avalia primeiro a política de acesso a linhas.

Uma determinada coluna de tabela ou exibição pode ser especificada em uma assinatura de política de acesso a linhas ou em uma assinatura da política de mascaramento. Em outras palavras, a mesma coluna não pode ser especificada tanto em uma assinatura de política de acesso a linhas quanto em uma assinatura de política de mascaramento ao mesmo tempo.

Para obter mais informações, consulte CREATE MASKING POLICY e CREATE ROW ACCESS POLICY.

Simulação de como uma política irá funcionar¶

Chame a função POLICY_CONTEXT para simular uma consulta em uma coluna que esteja protegida por uma política de mascaramento, uma tabela ou exibição protegida por uma política de acesso a linhas, ou ambos os tipos de políticas.

Tabelas externas¶

Você pode criar uma tabela externa com uma política de acesso a linhas executando uma instrução CREATE EXTERNAL TABLE e aplicar a política à coluna VALUE.

Você pode aplicar a política de acesso a linhas à coluna VALUE de uma tabela externa existente executando uma instrução ALTER TABLE na tabela externa.

Uma política de acesso a linhas não pode ser adicionada diretamente a uma coluna virtual. Em vez disso, crie uma exibição na tabela externa e aplique a política de acesso a linhas às colunas da exibição.

Fluxos¶

Se uma política de acesso a linhas for adicionada a uma tabela, o Snowflake aplicará a política de acesso a linhas aos dados da tabela quando o fluxo acessar os dados da tabela.

Para obter mais informações, consulte Limitações.

Exibições¶

O Snowflake permite definir políticas de acesso a linhas na tabela e exibição de base. A política de tabela ou exibição de base pode ser aplicada à função de proprietário da exibição (ou seja, INVOKER_ROLE) ou operador da consulta (ou seja, CURRENT_ROLE).

Para obter mais informações, consulte Limitações.

Exibições materializadas¶

O Snowflake permite adicionar uma política de acesso a linhas a uma exibição materializada desde que uma política de acesso a linhas não esteja definida na tabela ou exibição subjacente.

As políticas de acesso a linhas e as exibições materializadas têm as seguintes limitações:

• Uma exibição materializada não pode ser criada a partir de uma tabela se uma política de acesso a linhas for adicionada à tabela subjacente.

• Uma política de acesso a linhas não pode ser adicionada a uma tabela se uma exibição materializada tiver sido criada a partir daquela tabela subjacente.

Instruções CREATE TABLE¶

A seguir, um resumo de como as políticas de acesso a linhas afetam as instruções CREATE TABLE:

CREATE TABLE … CLONE:

A abordagem a seguir ajuda a proteger os dados dos usuários com o privilégio SELECT na tabela ou exibição ao acessar um objeto clonado.

• A clonagem de um objeto individual de política não é permitida.

• A clonagem de um esquema resulta na clonagem de todas as políticas dentro do esquema.

• Uma tabela clonada é mapeada para as mesmas políticas que a tabela de origem. Em outras palavras, se uma política for definida em uma tabela base ou suas colunas, a política será anexada à tabela clonada ou a suas colunas.

  • Quando uma tabela é clonada no contexto da clonagem de seu esquema principal, se a tabela de origem tiver uma referência a uma política no mesmo esquema principal (ou seja, uma referência local), a tabela clonada terá uma referência à política clonada.

  • Se a tabela de origem se referir a uma política em um esquema diferente (ou seja, uma referência estrangeira), então a tabela clonada manterá a referência estrangeira.

Para obter mais informações, consulte CREATE <objeto> … CLONE.

CREATE TABLE … LIKE:

Se uma política de acesso a linhas estiver definida na tabela base, a política de acesso a linhas não é definida em uma coluna na nova tabela. A nova tabela está vazia.

CREATE TABLE … AS SELECT:

Se uma política de acesso a linhas for definida na tabela base, a nova tabela contém as linhas filtradas com base na definição da política de acesso a linhas. A nova tabela não tem uma política de acesso a linhas definida em uma coluna.

Perfil de consulta¶

No tempo de execução da consulta, o Snowflake cria uma exibição dinâmica segura.

Ao usar o comando EXPLAIN em um objeto de banco de dados no qual uma política de acesso a linhas é definida, o resultado da consulta indica que uma política de acesso a linhas está presente. Quando uma política de acesso a linhas é definida no objeto do banco de dados, o resultado da consulta EXPLAIN especifica os seguintes valores de coluna:

• A coluna operation inclui o valor DynamicSecureView.

• A coluna object inclui o valor "<nome_do_objeto> (+ RowAccessPolicy)".

Cada etapa do plano de consulta que requer chamar a política de acesso a linhas faz com que as colunas operation e object especifiquem os valores correspondentes para aquela etapa no plano de consulta. Se a política de acesso a linhas for chamada apenas uma vez na consulta, apenas uma linha no resultado da consulta EXPLAIN inclui os valores DynamicSecureView e "<nome_do_objeto> (+ RowAccessPolicy)".

No resultado do comando EXPLAIN e na interface da Web do perfil de consulta, o Snowflake não mostra aos usuários nenhuma informação da política de acesso a linhas (ou seja, nome da política, assinatura da política, expressão da política) ou os objetos acessados pela política.

O exemplo a seguir indica uma política de acesso a linhas que é chamada apenas uma vez.

EXPLAIN SELECT * FROM my_table;

Copy

+-------+--------+--------+-------------------+--------------------------------+--------+-------------+-----------------+--------------------+---------------+
|  step |   id   | parent |     operation     |           objects              | alias  | expressions | partitionsTotal | partitionsAssigned | bytesAssigned |
+-------+--------+--------+-------------------+--------------------------------+--------+-------------+-----------------+--------------------+---------------+
...

| 1     | 2      | 1      | DynamicSecureView | "MY_TABLE (+ RowAccessPolicy)" | [NULL] | [NULL]      | [NULL]          | [NULL]             | [NULL]        |
+-------+--------+--------+-------------------+--------------------------------+--------+-------------+-----------------+--------------------+---------------+

O exemplo a seguir indica uma política de acesso a linhas que é chamada duas vezes para a mesma tabela:

EXPLAIN SELECT product FROM sales
  WHERE revenue > (SELECT AVG(revenue) FROM sales)
  ORDER BY product;

Copy

+--------+--------+--------+-------------------+-----------------------------+--------+-------------+-----------------+--------------------+---------------+
|  step  |   id   | parent |     operation     |           objects           | alias  | expressions | partitionsTotal | partitionsAssigned | bytesAssigned |
+--------+--------+--------+-------------------+-----------------------------+--------+-------------+-----------------+--------------------+---------------+
...
| 1      | 0      | [NULL] | DynamicSecureView | "SALES (+ RowAccessPolicy)" | [NULL] | [NULL]      | [NULL]          | [NULL]             | [NULL]        |
...
| 2      | 2      | 1      | DynamicSecureView | "SALES (+ RowAccessPolicy)" | [NULL] | [NULL]      | [NULL]          | [NULL]             | [NULL]        |
+--------+--------+--------+-------------------+-----------------------------+--------+-------------+-----------------+--------------------+---------------+

Time Travel¶

O Snowflake suporta o Time Travel em tabelas e exibições com uma política de acesso a linhas.

No tempo de execução da consulta, o Snowflake avalia as tabelas de mapeamento da política de acesso a linhas no momento da consulta; em outras palavras, o Time Travel não afeta a tabela de mapeamento.

Para obter mais informações, consulte Compreensão e uso do Time Travel.

Replicação¶

As políticas de acesso a linhas e suas atribuições podem ser replicadas usando replicação de banco de dados e grupos de replicação.

Para replicação de banco de dados, a operação de replicação falha se uma das seguintes condições for verdadeira:

• O banco de dados primário está em uma conta Enterprise (ou superior) e contém uma política, mas uma ou mais das contas aprovadas para replicação estão em edições anteriores.

• Uma tabela ou exibição contida no banco de dados primário tem uma referência pendente a uma política de acesso a linhas em outro banco de dados.

O comportamento de referência pendente para a replicação de banco de dados pode ser evitado ao replicar múltiplos bancos de dados em um grupo de replicação.

Nota

Se ações de failover ou failback forem usadas, a conta Snowflake deve ser Business Critical Edition ou superior.

Para obter mais informações, consulte Introdução à replicação e failover em várias contas.

Data Sharing¶

Uso:

• Se o provedor atribuir uma política a uma tabela ou exibição compartilhada e as condições da política chamarem a função CURRENT_ROLE ou CURRENT_USER, ou as condições da política chamarem a função UDF segura, o Snowflake retorna um valor NULL para a função ou o UDF na conta do consumidor.

  A razão é que o proprietário dos dados que estão sendo compartilhados não costuma controlar os usuários ou as funções na conta na qual a tabela ou exibição está sendo compartilhada. Como alternativa, use a função CURRENT_ACCOUNT nas condições da política.

  Como alternativa, como provedor, escreva as condições da política para chamar a função IS_DATABASE_ROLE_IN_SESSION e compartilhar a função do banco de dados. Como consumidor, conceda a função de banco de dados compartilhada a uma função de conta. Para obter mais detalhes, consulte Compartilhamento de dados protegidos por uma política.

Limitações:

• Um provedor de compartilhamento de dados não pode criar uma política em uma conta de leitor.

• Os consumidores que compartilham dados não podem aplicar uma política a uma tabela ou exibição compartilhada. Como alternativa, importe o banco de dados compartilhado e crie exibições locais a partir da tabela ou exibição compartilhada.

• Os consumidores que compartilham dados não podem consultar uma tabela ou exibição compartilhada que faz referência a dois fornecedores provedores. Por exemplo:

  • rap1 é uma política de acesso a linhas que protege a tabela chamada t1, onde t1 está na ação chamada share1 de um provedor.

  • As condições da política rap1 referem-se a uma tabela de mapeamento chamada t2, em que t2 vem de share2 e de um provedor diferente.

  • A consulta do consumidor em t1 falha.

  • O provedor de t1 pode consultar t1.

• Funções externas:

  O Snowflake retorna um erro se:

  • A política atribuída a uma tabela ou exibição compartilhada é atualizada para chamar uma função externa.

  • A política chama uma função externa e você tenta atribuir a política a uma tabela ou exibição compartilhada.

Snowflake Native App Framework¶

Para obter detalhes sobre como usar políticas de acesso a linhas com Snowflake Native App, consulte:

• Restrições ao compartilhamento de conteúdo de dados que contém políticas.

• Definição de políticas em exibições de proxy.

• Funções de contexto bloqueadas.

Escolha de uma abordagem de gerenciamento centralizada, híbrida ou descentralizada¶

Para gerenciar as políticas de acesso a linhas de forma eficaz, é útil considerar se sua abordagem para filtrar linhas deve seguir uma abordagem de governança centralizada, descentralizada ou híbrida.

A tabela a seguir resume algumas das considerações com cada uma dessas três abordagens.

Para exemplos de sintaxe, consulte Resumo de comandos DDL, operações e privilégios.

Privilégios da política de acesso a linhas¶

O Snowflake permite os seguintes privilégios de política de acesso a linhas para determinar se os usuários podem criar, definir e possuir políticas de acesso a linhas.

Observe que operar em qualquer objeto de um esquema também requer o privilégio USAGE no banco de dados e esquema principais.

DDL da política de acesso a linhas¶

O Snowflake aceita os seguintes comandos e operações DDL para gerenciar as políticas de acesso a linhas.

• CREATE ROW ACCESS POLICY

• ALTER ROW ACCESS POLICY

• DROP ROW ACCESS POLICY

• SHOW ROW ACCESS POLICIES

• DESCRIBE ROW ACCESS POLICY

• ALTER TABLE ALTER EXTERNAL TABLE e ALTER VIEW (para adicionar/remover uma política em uma tabela ou exibição)

Resumo de comandos DDL, operações e privilégios¶

A tabela a seguir resume a relação entre as operações DDL da política de acesso a linhas e seus privilégios necessários.

Observe que operar em qualquer objeto de um esquema também requer o privilégio USAGE no banco de dados e esquema principais.

O Snowflake aceita diferentes permissões para criar e definir uma política de acesso a linhas para um objeto.

1. Para uma abordagem centralizada de gerenciamento de políticas de acesso a linhas, na qual a função personalizada rap_admin cria e define políticas de acesso a linhas em todos os objetos, são necessárias as seguintes permissões:

   use role securityadmin;
   grant create row access policy on schema <db_name.schema_name> to role rap_admin;
   grant apply row access policy on account to role rap_admin;
   

   Copy

2. Em uma abordagem híbrida de gerenciamento, uma única função tem o privilégio CREATE ROW ACCESS POLICY para assegurar a criação de políticas consistentes e otimizar o desempenho de consultas, e equipes ou funções individuais têm o privilégio APPLY para uma política específica de acesso a linhas para proteger suas tabelas e exibições.

   Por exemplo, a função personalizada finance_role pode receber permissão para adicionar a política de acesso a linhas rap_finance nas tabelas e exibições que a função possui:

   use role securityadmin;
   grant create row access policy on schema <db_name.schema_name> to role rap_admin;
   grant apply on row access policy rap_finance to role finance_role;
   

   Copy

Descubra as políticas de acesso a linhas¶

Você pode usar a exibição ROW_ACCESS_POLICIES no esquema Account Usage do banco de dados SNOWFLAKE compartilhado. Essa exibição é um catálogo de todas as políticas de acesso a linhas em sua conta Snowflake. Por exemplo:

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.ROW_ACCESS_POLICIES
ORDER BY POLICY_NAME;

Copy

Identificar atribuições¶

O Snowflake oferece suporte a diferentes opções para identificar atribuições de política de acesso a linhas, dependendo se a consulta precisa ser direcionada à conta ou a um banco de dados específico.

• Consulta em nível de conta:

  Use a exibição Account Usage POLICY_REFERENCES para determinar todas as tabelas que têm uma política de acesso a linhas. Por exemplo:

  SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.POLICY_REFERENCES
  ORDER BY POLICY_NAME, REF_COLUMN_NAME;
  

  Copy

• Consulta em nível de banco de dados:

  Todo banco de dados do Snowflake inclui um Snowflake Information Schema. Use a função de tabela POLICY_REFERENCES do Information Schema para determinar todos os objetos associados a uma política específica de acesso a linhas:

  SELECT *
  FROM TABLE(
    my_db.INFORMATION_SCHEMA.POLICY_REFERENCES(
      POLICY_NAME => 'rap_t1'
    )
  );
  

  Copy

Acesso à área de governança no Snowsight¶

Para acessar a área Governance, sua conta Snowflake deve ser Enterprise Edition ou superior. Além disso, você deve executar um dos seguintes procedimentos:

• Use a função ACCOUNTADMIN.

• Use uma função de conta receba diretamente as funções de banco de dados GOVERNANCE_VIEWER e OBJECT_VIEWER.

  Você deve usar uma função de conta com essas concessões de função de banco de dados. Atualmente, Snowsight não avalia hierarquias de funções e funções de banco de dados definidas pelo usuário com acesso a tabelas, exibições, políticas de acesso a dados e tags.

  Para determinar se a função da sua conta tem essas duas funções de banco de dados, use um comando SHOW GRANTS:

  SHOW GRANTS LIKE '%VIEWER%' TO ROLE data_engineer;
  

  Copy

  |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
  | created_on                    | privilege | granted_on    | name                        | granted_to | grantee_name    | grant_option | granted_by |
  |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
  | 2024-01-24 17:12:26.984 +0000 | USAGE     | DATABASE_ROLE | SNOWFLAKE.GOVERNANCE_VIEWER | ROLE       | DATA_ENGINEER   | false        |            |
  | 2024-01-24 17:12:47.967 +0000 | USAGE     | DATABASE_ROLE | SNOWFLAKE.OBJECT_VIEWER     | ROLE       | DATA_ENGINEER   | false        |            |
  |-------------------------------+-----------+---------------+-----------------------------+------------+-----------------+--------------+------------|
  

  
  

  Se a função da sua conta não receber uma ou ambas as funções de banco de dados, use o comando GRANT DATABASE ROLE e execute o comando SHOW GRANTS novamente para confirmar as concessões:

  USE ROLE ACCOUNTADMIN;
  GRANT DATABASE ROLE SNOWFLAKE.GOVERNANCE_VIEWER TO ROLE data_engineer;
  GRANT DATABASE ROLE SNOWFLAKE.OBJECT_VIEWER TO ROLE data_engineer;
  SHOW GRANTS LIKE '%VIEWER%' TO ROLE data_engineer;
  

  Copy

  Para obter detalhes sobre essas funções de banco de dados, consulte Funções de banco de dados SNOWFLAKE.

Painel¶

Como administrador de dados, você pode usar a interface do Dashboard para monitorar o uso de tags e políticas das seguintes maneiras.

• Cobertura: especifica a contagem e a porcentagem com base no fato de uma tabela, exibição ou coluna ter uma política ou tag.

• Prevalência: lista e conta as políticas e tags usadas com mais frequência.

A cobertura e a prevalência fornecem um instantâneo de quão bem os dados estão protegidos e marcados com tag.

Quando você seleciona um número de contagem, porcentagem, nome de política ou nome de tag, a interface Tagged Objects é aberta. A interface Tagged Objects atualiza os filtros automaticamente com base em sua seleção em Dashboard.

As informações de monitoramento são uma alternativa ou um complemento à execução de operações complexas e de consulta intensa em várias exibições do Account Usage.

Essas exibições podem incluir, sem limitação, as exibições COLUMNS, POLICY_REFERENCES, TABLES, TAG_REFERENCES e VIEWS.

Objetos marcados¶

Como administrador de dados, você pode usar essa tabela para associar rapidamente a cobertura e a prevalência no Dashboard a uma lista de tabelas, exibições ou colunas específicas. Você também pode filtrar os resultados da tabela manualmente da seguinte forma.

• Escolha Tables ou Columns.

• Para as tags, você pode filtrar com tags, sem tags ou por uma tag específica.

• Para políticas, você pode filtrar com políticas, sem políticas ou por uma política específica.

Quando você seleciona uma linha na tabela, a guia Table Details ou Columns em Data » Databases é aberta. Você pode editar as atribuições de tags e políticas conforme necessário.