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

Este tópico fornece uma introdução às políticas de acesso a linhas e à segurança em nível de linha.

Neste tópico:

O que é a segurança em nível de linha?

O Snowflake tem suporte para a segurança em nível de linha por meio de políticas de acesso para determinar quais linhas devem ser retornadas no resultado da consulta. A política de acesso a linhas pode ser relativamente simples para permitir que uma função específica veja as linhas, ou ser mais complexa para incluir uma tabela de mapeamento na definição da política para determinar o acesso às linhas no resultado da consulta. 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.

Uma política de acesso a linhas é um objeto em nível de esquema que decide se uma determinada linha em uma tabela ou exibição pode ser exibida a partir dos seguintes tipos de instruções:

As políticas de acesso a linhas podem incluir condições e funções na expressão da política para transformar os dados no tempo de execução da consulta quando essas condições forem atendidas. A abordagem orientada por políticas habilita a segregação de tarefas para permitir que as equipes de governança definam políticas que possam limitar a exposição de dados confidenciais. Essa abordagem também inclui o proprietário do objeto (ou seja, a função com o privilégio OWNERSHIP sobre o objeto, como uma tabela ou exibição) que normalmente tem pleno acesso aos dados subjacentes. Uma única política pode ser definida para diferentes tabelas e exibições ao mesmo tempo.

O administrador da política de acesso a linhas pode aplicar políticas de acesso a linhas a tabelas e exibições.

As políticas de acesso a linhas não impedem que linhas sejam inseridas nem que as linhas visíveis sejam atualizadas ou excluídas.

Uma política de acesso a linhas pode ser adicionada a uma tabela ou exibição quando o objeto é criado ou depois disso. Para obter mais informações, consulte Aplicação de uma política de acesso a linhas a uma tabela ou exibição (neste tópico).

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.

Dica

Se quiser atualizar uma política de acesso a linhas existente e precisar ver a definição atual da política, chame a função GET_DDL ou execute o comando DESCRIBE ROW ACCESS POLICY.

A expressão da política de acesso a linhas pode ser atualizada com o comando ALTER ROW ACCESS POLICY. Esse comando não exige descartar uma política de acesso a linhas a partir de uma tabela ou exibição. Portanto, uma tabela ou exibição que esteja protegida por uma política de acesso a linhas permanece protegida enquanto a expressão da política estiver sendo atualizada.

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.

Políticas de acesso a linhas com tabelas e exibições.

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

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()
;
Copy

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:

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:

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.

Uso de políticas de acesso a linhas com objetos e recursos do Snowflake

As seções seguintes descrevem como as políticas de acesso a linhas afetam as tabelas e exibições junto com outros recursos do Snowflake.

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:

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.

Importante

O Snowflake não aceita o uso de uma tabela externa como uma tabela de mapeamento em uma política de acesso a linhas. Ao clonar um banco de dados, o Snowflake clona a política de acesso a linhas, mas não a tabela externa. Portanto, a política no banco de dados clonado refere-se a uma tabela que não está presente no banco de dados clonado.

Se os dados na tabela externa forem necessários para a política de acesso a linhas, considere mover os dados da tabela externa para um esquema dedicado dentro do banco de dados no qual a política existe antes de completar uma operação de clonagem. Atualize a política de acesso a linhas para referenciar o nome de tabela totalmente qualificado para garantir que a política se refira a uma tabela no banco de dados clonado.

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:

Gerenciamento de políticas de acesso a linhas

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.

Ação da política

Centralizada

Híbrida

Descentralizada

Criar políticas

Responsável pela governança

Responsável pela governança

Equipes individuais

Aplicar políticas às colunas

Responsável pela governança

Equipes individuais

Equipes individuais

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

Dica

Como melhor prática, a Snowflake recomenda que sua organização reúna todas as partes interessadas relevantes para determinar a melhor abordagem de gerenciamento para implementar políticas de acesso a linhas em seu ambiente.

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.

Privilégio

Uso

CREATE

Permite a criação de uma nova política de acesso a linhas em um esquema.

APPLY

Permite a execução das operações de adição e descarte para a política de acesso a linhas em uma tabela ou exibição.

Observe que a concessão do privilégio global APPLY ROW ACCESSPOLICY (ou seja, APPLY ROW ACCESS POLICY em ACCOUNT) permite executar a operação DESCRIBE em tabelas e exibições.

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

OWNERSHIP

Concede controle total sobre a política de acesso a linhas. Requerido para alterar a maioria das propriedades de uma política de acesso a linhas. Somente uma única função pode ter este privilégio sobre um objeto específico de cada vez.

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.

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.

Operação

Privilégio necessário

Criar uma política de acesso a linhas

Uma função com o privilégio CREATE ROW ACCESS POLICY no mesmo esquema.

Alterar a política de acesso a linhas

Uma função com o privilégio OWNERSHIP na política de acesso a linhas.

Política de acesso a linhas Add/Drop

Uma função com o privilégio APPLY ROW ACCESS POLICY na conta ou uma função com o privilégio OWNERSHIP no objeto do banco de dados e o privilégio APPLY no objeto da política de acesso a linhas.

Descartar uma política de acesso a linhas

Um dos seguintes: Uma função com o privilégio OWNERSHIP na política de acesso a linhas ou . Uma função com o privilégio OWNERSHIP no esquema em que existe a política de acesso a linhas.

Mostrar políticas de acesso a linhas

Um dos seguintes: . Uma função com o privilégio APPLY ROW ACCESS POLICY, ou . O privilégio OWNERSHIP na política de acesso a linhas, ou . O privilégio APPLY na política de acesso a linhas.

Descrever uma política de acesso a linhas

Um dos seguintes: Uma função com o privilégio APPLY ROW ACCESS POLICY, ou . O privilégio OWNERSHIP na política de acesso a linhas, ou . O privilégio APPLY na política de acesso a linhas.

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

Monitoramento de políticas de acesso a linhas com SQL

Você pode monitorar o uso da política de acesso a linhas por meio de duas exibições diferentes de Account Usage e uma tabela do Information Schema.

Pode ser útil pensar em duas abordagens gerais para determinar como monitorar o uso da política de acesso a linhas.

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

Monitoramento de políticas de acesso a linhas com Snowsight

Você pode usar a área Snowsight Monitoring » Governance para monitorar e gerar relatórios sobre o uso de políticas e tags com tabelas, exibições e colunas. Há duas interfaces diferentes: Dashboard e Tagged Objects.

Ao usar a interface Dashboard e Tagged Objects, observe os detalhes a seguir.

  • As interfaces Dashboard e Tagged Objects exigem um warehouse em execução.

  • Snowsight atualiza o Dashboard a cada 12 horas.

  • A latência das informações Tagged Objects pode ser de até duas horas e retorna até 1.000 objetos.

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.

Auditoria de políticas de acesso a linhas

O Snowflake aceita as seguintes abordagens para facilitar operações de auditoria e governança de políticas de acesso a linhas.

  • Use SHOW ROW ACCESS POLICIES para produzir uma lista de políticas de acesso a linhas que não tenham sido descartadas de sua conta.

  • Os administradores de políticas de acesso a linhas (ou seja, usuários com o privilégio OWNERSHIP de política de acesso às linhas) podem usar o Time Travel ou fluxos para capturar dados históricos sobre qualquer tabela de mapeamento referenciada em suas políticas de acesso a linhas.

  • Para determinar os dados que um determinado usuário pode acessar, o administrador da política de acesso a linhas pode assumir a função do usuário e executar uma consulta.

    • O Snowflake permite definir uma política de acesso a linhas expression com lógica personalizada para aceitar este comportamento no comando CREATE ROW ACCESS POLICY.

    • O Snowflake não tem atualmente um mecanismo padrão (por exemplo, um sistema dedicado ou função de contexto) para dar suporte a esta operação.

  • Se uma determinada política de acesso a linhas utilizar tabelas de mapeamento para determinar qual função e população de usuários pode acessar os dados de linha, o proprietário da política de acesso a linhas pode consultar as tabelas de mapeamento para determinar o acesso do usuário autorizado sob demanda.

  • O Snowflake captura e registra informações de mensagens de erro relacionadas às políticas de acesso a linhas na exibição Exibição QUERY_HISTORY de uso da conta. Se ocorrer um erro em uma consulta, o Snowflake registra a primeira mensagem de erro que ocorre durante a avaliação da consulta. Para obter mais informações sobre as mensagens de erro da política de acesso a linhas, consulte Solução de problemas de políticas de acesso a linhas.

  • Para determinar os dados que um determinado usuário acessou no passado em relação às políticas de acesso a linhas para objetos de banco de dados, use o Time Travel em combinação com a exibição ROW_ACCESS_POLICIES Account Usage e a função de tabela POLICY_REFERENCES do Information Schema.

    • Se a política e as tabelas de mapeamento, se presentes, não tiverem sido alteradas, o administrador da política de acesso a linhas pode assumir a função do usuário e executar uma consulta do Time Travel. Os valores dos parâmetros relevantes da sessão, tais como CURRENT_ROLE, estão disponíveis no resultado da consulta.

    • Se a política ou tabelas de mapeamento tiverem mudado, o administrador da política de acesso a linhas deve executar uma consulta do Time Travel na tabela de mapeamento e reconstruir a política de acesso a linhas que existia no momento do incidente especificado. Após essas etapas, o administrador da política de acesso a linhas pode começar a consultar os dados e prosseguir com a análise dos mesmos.

Solução de problemas de políticas de acesso a linhas

Os seguintes comportamentos e mensagens de erro se aplicam às políticas de acesso a linhas.

Comportamento

Mensagem de erro

Ação de solução de problemas

Não é possível definir uma política de acesso a linhas (exibição materializada).

A política de acesso a linhas não pode ser anexada a uma exibição materializada.

Verifique se uma política de acesso a linhas pode ser definida na exibição materializada. Consulte Exibições materializadas (neste tópico).

Não é possível criar uma política de acesso a linhas (booleano).

003551=SQL compilation error: O tipo de retorno da política de acesso a linhas “”{0}”” não é BOOLEAN.

Uma definição de política de acesso a linhas deve ter RETURNS BOOLEAN. Reescreva a política de acesso a linhas, como mostrado em CREATE ROW ACCESS POLICY.

Não é possível criar uma política de acesso a linhas (banco de dados).

Esta sessão não dispõe de um banco de dados atual. Chame “USE DATABASE” ou use um nome qualificado.

Como uma política de acesso a linhas é um objeto em nível de esquema, defina um banco de dados e esquema para a sessão atual ou use o nome totalmente qualificado no comando CREATE ROW ACCESS POLICY. Para obter mais informações, consulte Resolução de nomes de objetos.

Não é possível criar uma política de acesso a linhas (o objeto existe)

Erro de compilação SQL: O objeto ‘<nome>” já existe.

Como já existe uma política de acesso a linhas no esquema com o nome indicado, recrie a política de acesso a linhas com um valor name diferente.

Não é possível criar uma política de acesso a linhas (propriedade do esquema).

Erro de controle de acesso SQL: Privilégios insuficientes para operar no esquema “S1”.

Verifique os privilégios para criar uma política de acesso a linhas em Resumo de comandos, operações e privilégios DDL (neste tópico).

Não é possível criar uma política de acesso a linhas (uso do esquema).

Erro de compilação SQL: O esquema ‘<nome_do_esquema>” não existe ou não é autorizado.

Verifique se o esquema especificado existe e os privilégios para criar uma política de acesso a linhas em Resumo de comandos, operações e privilégios DDL (neste tópico).

Não é possível descrever uma política de acesso a linhas (somente uso).

Erro de compilação SQL: A política de acesso a linhas “RLS_AUTHZ_DB.S_B.P1” não existe ou não é autorizada.

Ter o privilégio USAGE para o banco de dados e o esquema principais onde existe a política de acesso a linhas não é suficiente para executar uma operação DESCRIBE na política de acesso a linhas. Verifique se a política de acesso a linhas existe e os privilégios para descrever uma política de acesso a linhas em Resumo de comandos, operações e privilégios DDL (neste tópico).

Não é possível descartar uma política de acesso a linhas. (manutenção).

Erro de compilação SQL: A política de acesso a linhas “RLS_AUTHZ_DB.S_B.P1” não existe ou não é autorizada.

Verifique se a política de acesso a linhas especificada existe e os privilégios para descartar uma política de acesso a linhas em Resumo de comandos, operações e privilégios DDL (neste tópico).

Não é possível executar UNDROP em uma política de acesso a linhas. (manutenção).

Recurso sem suporte “UNDROP sem suporte para objetos do tipo ROW_ACCESS_POLICY”.

Para restabelecer uma política de acesso a linhas, execute um comando CREATE ROW ACCESS POLICY e depois adicione a política de acesso a linhas a um objeto de banco de dados usando um comando ALTER TABLE ou ALTER VIEW como mostrado em ALTER TABLE ou ALTER VIEW.

Não é possível atualizar uma política de acesso a linhas (nome/operação).

Erro de compilação SQL: O objeto encontrado é do tipo “ROW_ACCESS_POLICY”, não o tipo especificado “MASKING_POLICY”.

Verifique novamente a consulta quanto ao nome do objeto e a operação pretendida para o objeto. . . Por exemplo, o Snowflake não aceita o ALTER ROW ACCESS POLICY <nome>;. . . Ao invés disso, use um comando CREATE OR REPLACE ROW ACCESS POLICY para atualizar uma política de acesso a linhas. Para obter mais informações sobre operações de políticas de acesso a linhas, consulte Resumo de comandos, operações e privilégios DDL (neste tópico).

Não é possível utilizar políticas de acesso a linhas com um recurso ou serviço do Snowflake (recurso sem suporte).

Recurso sem suporte “CREATE ON OBJECTS ENFORCED BY ROW ACCESS POLICY”.

Alguns recursos e serviços do Snowflake não aceitam políticas de acesso a linhas. Para obter mais informações, consulte as seções Limitações e Uso de políticas de acesso a linhas com objetos e recursos do Snowflake neste tópico.

Não é possível atualizar uma política de acesso a linhas (token sem suporte).

Recurso sem suporte “TOK_ROW_ACCESS_POLICY”.

TOK refere-se ao token, que pode ser retornado se uma consulta não tiver suporte e/ou se for imprecisa; o compilador SQL do Snowflake não sabe como processar a consulta. . Por exemplo alter row access policy p1_test set comment = 'test policy 1';. Neste exemplo, o comando ALTER não pode ser usado diretamente no objeto da política; use um comando ALTER TABLE ou ALTER VIEW em vez disso, como mostrado em Resumo de comandos, operações e privilégios DDL (neste tópico).

Próximos tópicos: