Políticas de projeção¶

Uso da coluna¶

O Snowflake rastreia o uso da coluna. Referências indiretas a uma coluna, como uma definição de exibição, UDF (neste tópico) e uma expressão de tabela comum, impactam a projeção da coluna quando uma política de projeção é definida em uma coluna.

Quando uma política de projeção é definida na coluna e a coluna não pode ser projetada, a coluna:

• Não está incluída na saída de um resultado de consulta.

• Não pode ser inserida em outra tabela.

• Não pode ser um argumento para uma função externa ou procedimento armazenado.

Limitações¶

UDFs:

Para limitações relacionadas às funções definidas pelo usuário (UDFs), consulte Funções definidas pelo usuário (UDFs) (neste tópico).

Política:

Uma política de projeção não pode ser aplicada a:

• Uma tag, e essa tag não pode ser atribuída a uma tabela ou coluna (ou seja, “políticas de projeção baseadas em tags”).

• Uma coluna virtual ou para a coluna VALUE em uma tabela externa.

  Como solução alternativa, crie uma exibição e atribua uma política de projeção a cada coluna que não deve ser projetada.

• O value_column em uma construção PIVOT. Para detalhes relacionados, consulte UNPIVOT (neste tópico).

Uma política de projeção body não pode fazer referência a uma coluna protegida por uma política de mascaramento ou a uma tabela protegida por uma política de acesso a linhas. Para detalhes adicionais, consulte Políticas de mascaramento e acesso a linhas (neste tópico).

Considerações¶

Use políticas de projeção quando o caso de uso exigir a consulta de uma coluna confidencial sem expor diretamente o valor da coluna a um analista ou função semelhante. O valor da coluna dentro de uma coluna restrita por projeção pode ser analisado com maior flexibilidade do que um valor mascarado ou tokenizado. No entanto, considere o seguinte antes de definir uma política de projeção em uma coluna:

• Uma política de projeção não impede a segmentação de um indivíduo.

  Por exemplo, um usuário pode filtrar linhas onde a coluna name corresponde a um indivíduo específico, mesmo que a coluna seja restrita por projeção. No entanto, o usuário não pode executar uma instrução SELECT para visualizar os nomes dos indivíduos na tabela.

• Quando uma coluna restrita de projeção é a chave de junção para uma consulta que combina dados da tabela protegida com dados de uma tabela desprotegida, nada impede que o usuário projete valores da coluna na tabela desprotegida. Como resultado, se um valor na tabela desprotegida corresponder a um valor na coluna protegida, o usuário poderá obter esse valor projetando-o da tabela desprotegida.

  Por exemplo, suponha que uma política de projeção tenha sido atribuída à coluna email da tabela t_protected. Um usuário ainda pode verificar os valores na coluna t_protected.email executando:

  SELECT t_unprotected.email
    FROM t_unprotected JOIN t_protected ON t_unprotected.email = t_protected.email;
  

  Copy

• Uma restrição de projeção não garante que uma pessoa mal-intencionada não possa usar consultas deliberadas para obter dados potencialmente confidenciais de uma coluna com restrição de projeção. As políticas de projeção são mais adequadas para uso com parceiros e clientes com os quais você já tem um nível de confiança. Além disso, os provedores devem estar atentos a possíveis utilizações indevidas dos seus dados (por exemplo, revendo o histórico de acesso às suas listagens).

Exemplos de política¶

As políticas de projeção mais simples chamam a função PROJECTION_CONSTRAINT diretamente:

Permitir a projeção de coluna

CREATE OR REPLACE PROJECTION POLICY mypolicy
AS () RETURNS PROJECTION_CONSTRAINT ->
PROJECTION_CONSTRAINT(ALLOW => true)

Copy

Impedir a projeção da coluna

CREATE OR REPLACE PROJECTION POLICY mypolicy
AS () RETURNS PROJECTION_CONSTRAINT ->
PROJECTION_CONSTRAINT(ALLOW => false)

Copy

Expressões SQL mais complicadas podem ser escritas para chamar a função PROJECTION_CONSTRAINT. A expressão pode usar Funções de expressão condicional e Funções de contexto para introduzir lógica para permitir que determinados usuários com uma função específica projetem uma coluna e impedir que todos os outros usuários projetem uma coluna.

Por exemplo, use uma expressão CASE para permitir que apenas usuários com a função personalizada analyst projetem uma coluna:

CREATE OR REPLACE PROJECTION POLICY mypolicy
AS () RETURNS PROJECTION_CONSTRAINT ->
CASE
  WHEN CURRENT_ROLE() = 'ANALYST'
    THEN PROJECTION_CONSTRAINT(ALLOW => true)
  ELSE PROJECTION_CONSTRAINT(ALLOW => false)
END;

Copy

Para casos de uso de compartilhamento de dados, o provedor pode escrever uma política de projeção para restringir a projeção de colunas para todas as contas do consumidor usando a função de contexto CURRENT_ACCOUNT ou restringir seletivamente a projeção de colunas em compartilhamentos específicos usando a função de contexto INVOKER_SHARE. Por exemplo:

Restringir todas as contas de consumidor

Neste exemplo, provider.account é o identificador da conta no formato do nome da conta:

CREATE OR REPLACE PROJECTION POLICY restrict_consumer_accounts
AS () RETURNS PROJECTION_CONSTRAINT ->
CASE
  WHEN CURRENT_ACCOUNT() = 'provider.account'
    THEN PROJECTION_CONSTRAINT(ALLOW => true)
  ELSE PROJECTION_CONSTRAINT(ALLOW => false)
END;

Copy

Restringir a compartilhamentos específicos

Considere uma conta de provedor de compartilhamento de dados que tenha uma política de projeção definida em uma coluna de uma exibição segura. Há dois compartilhamentos diferentes (SHARE1 e SHARE2) que podem acessar a exibição segura para oferecer suporte a dois consumidores diferentes de compartilhamento de dados.

Se um usuário na conta do consumidor de compartilhamento de dados tentar projetar a coluna por meio de qualquer compartilhamento, ele poderá projetar a coluna, caso contrário, a coluna não poderá ser projetada:

CREATE OR REPLACE PROJECTION POLICY projection_share
AS () RETURNS PROJECTION_CONSTRAINT ->
CASE
  WHEN INVOKER_SHARE() IN ('SHARE1', 'SHARE2')
    THEN PROJECTION_CONSTRAINT(ALLOW => true)
  ELSE PROJECTION_CONSTRAINT(ALLOW => false)
END;

Copy

Substituir uma política de projeção¶

O método recomendado para substituir uma política de projeção é usar o parâmetro FORCE para separar a política de projeção existente e atribuir a nova em um único comando. Isso permite substituir atomicamente a política antiga, sem deixar lacunas na proteção.

Por exemplo, para atribuir uma nova política de projeção a uma coluna que já está restrita à projeção:

ALTER TABLE finance.accounting.customers
  MODIFY COLUMN account_number
  SET PROJECTION POLICY proj_policy2 FORCE;

Você também pode desanexar a política de projeção de uma coluna em uma instrução (… UNSET PROJECTION POLICY) e depois definir uma nova política na coluna em uma instrução diferente (… SET PROJECTION POLICY <nome>). Se você escolher esse método, a coluna não será protegida por uma política de projeção entre a desanexação de uma política e a atribuição de outra. Uma consulta poderia potencialmente acessar dados confidenciais durante esse período.

Como descobrir as políticas de projeção¶

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

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

Copy

Identificar referências de política de projeção¶

A função de tabela POLICY_REFERENCES do Information Schema pode identificar referências de política de projeção. Existem duas opções de sintaxe diferentes:

1. Retorna uma linha para cada objeto (ou seja, tabela ou exibição) que tenha a política de projeção especificada definida em uma coluna:

   USE DATABASE my_db;
   SELECT policy_name,
          policy_kind,
          ref_entity_name,
          ref_entity_domain,
          ref_column_name,
          ref_arg_column_names,
          policy_status
   FROM TABLE(information_schema.policy_references(policy_name => 'my_db.my_schema.projpolicy'));
   

   Copy

2. Devolver uma linha para cada política atribuída à tabela chamada my_table:

   USE DATABASE my_db;
   USE SCHEMA information_schema;
   SELECT policy_name,
          policy_kind,
          ref_entity_name,
          ref_entity_domain,
          ref_column_name,
          ref_arg_column_names,
          policy_status
   FROM TABLE(information_schema.policy_references(ref_entity_name => 'my_db.my_schema.my_table', ref_entity_domain => 'table'));
   

   Copy

Políticas de mascaramento e acesso a linhas¶

Esta seção descreve como uma política de projeção interage com uma política de mascaramento e uma política de acesso a linhas.

Várias políticas:

Uma coluna pode ter uma política de mascaramento e uma política de projeção ao mesmo tempo, e a tabela que contém esta coluna pode ser protegida por uma política de acesso a linhas. Se todas as três políticas estiverem presentes, o Snowflake processará a tabela e as políticas da seguinte forma:

1. Aplique filtros de linha de acordo com a política de acesso a linhas.

2. Determine se a consulta está tentando projetar alguma coluna restrita pela política de projeção e, em caso afirmativo, rejeite a consulta.

3. Aplique máscaras de coluna de acordo com a política de mascaramento.

Uma coluna protegida por uma política de mascaramento também pode ter projeção restrita. Por exemplo, uma política de mascaramento definida em uma coluna contendo números de conta pode ter uma condição que permite que usuários com a função personalizada finance_admin vejam os números de conta e outra condição para substituir os números de conta por um hash para todas as outras funções.

Uma política de projeção pode restringir ainda mais a coluna de forma que os usuários com a função personalizada analyst não possam projetar a coluna. Observe que os usuários com a função personalizada analyst ainda podem analisar a coluna agrupando hashes ou unindo-se a esses hashes.

Snowflake recomenda que os administradores de políticas trabalhem com responsáveis internos de conformidade e regulamentação para determinar as colunas que devem ser restritas à projeção.

Avaliação de políticas:

Uma coluna restrita por projeção não pode ser referenciada por uma política de mascaramento ou por uma política de acesso a linhas ao:

• Atribuir uma política de acesso a linhas para uma tabela.

• Enumerar uma ou mais colunas em uma política de mascaramento condicional.

• Executar uma pesquisa na tabela de mapeamento.

Conforme mencionado em Limitações (neste tópico), uma política de projeção body não pode fazer referência a uma coluna protegida por uma política de mascaramento ou a uma tabela protegida por uma política de acesso a linhas.

Objetos dependentes com outras políticas de projeção¶

Considere a seguinte série de objetos:

base_table » v1 » v2

Onde:

• v1 é uma exibição construída a partir da tabela chamada base_table.

• v2 é uma exibição construída a partir de v1.

Se houver uma consulta em uma coluna em uma exibição com restrição de projeção e essa coluna depender de uma coluna com restrição de projeção em base_table, a coluna da exibição será projetada somente se ambas as políticas de projeção permitirem que a coluna seja projetada.

O Snowflake verifica a cadeia de linhagem da coluna até a tabela base para garantir que quaisquer referências à coluna não sejam restritas à projeção. Se alguma coluna na cadeia de linhagem estiver restrita à projeção e a coluna não puder ser projetada, o Snowflake bloqueará a consulta.

Exibições e exibições materializadas¶

Uma política de projeção em uma coluna de exibição restringe a coluna de exibição e não a coluna da tabela base subjacente.

Com relação às referências, uma política de projeção que restringe uma coluna da tabela é transferida para uma exibição que faz referência à coluna restrita da tabela.

Fluxos e tarefas¶

As políticas de projeção em colunas de uma tabela são transferidas para um fluxo na mesma tabela. Observe que uma política de projeção não pode ser definida em um fluxo.

Da mesma forma, uma coluna com projeção restrita permanece restrita quando uma tarefa faz referência à coluna restrita.

UNPIVOT¶

O resultado de uma construção UNPIVOT depende se uma coluna foi inicialmente restringida por uma política de projeção. Nota:

• Colunas restritas antes e depois da execução de UNPIVOT permanecem com projeção restrita.

• O name_column sempre aparece no resultado da consulta.

• Se alguma coluna em column_list tiver restrição de projeção, value_column também terá restrição de projeção.

Objetos clonados¶

A abordagem a seguir ajuda a proteger dados de usuários com o privilégio SELECT em uma tabela ou exibição clonada armazenada no banco de dados ou esquema clonado:

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

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

• Uma tabela clonada é mapeada para as mesmas políticas de projeção que a tabela de origem.

  • 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 de projeção no mesmo esquema principal (ou seja, uma referência local), a tabela clonada terá uma referência à política de projeção clonada.

  • Se a tabela de origem se referir a uma política de projeção 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.

Replicação¶

As políticas de projeção 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 projeção 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.

Funções definidas pelo usuário (UDFs)¶

Observe o seguinte em relação às restrições de projeção e UDFs:

UDFs de SQL escalares:

Snowflake avalia UDF e, em seguida, aplica a política de projeção à coluna restrita de projeção.

Se uma coluna em uma instrução SELECT for derivada transitivamente de uma UDF, que também é derivada de uma coluna com restrição de projeção, o Snowflake bloqueará a consulta. Em outras palavras:

Coluna pc_column » UDF » (na instrução SELECT)

Onde:

• pc_column refere-se a uma coluna restrita por projeção.

Como a coluna na instrução SELECT pode ser rastreada até uma coluna restrita por projeção, o Snowflake bloqueia a consulta.

SQL UDTFs:

As funções de tabela definidas pelo usuário SQL (UDTF) seguem o mesmo comportamento de UDFs SQL, exceto que, como as linhas são retornadas na saída da função, o Snowflake avalia cada coluna da tabela independentemente para determinar se a coluna deve ser projetada na saída da função.

Outras UDFs:

O seguinte se aplica a Introdução a UDFs de Java, Introdução a UDFs de JavaScript, Introdução a UDFs de Python:

• Uma coluna restrita por projeção é restrita na saída da UDTF.

Registro em log e tabelas de eventos:

Quando uma UDF, UDTF ou UDF JavaScript tem um argumento restrito à projeção, o Snowflake não captura detalhes de log e eventos na tabela de eventos correspondente. No entanto, o Snowflake permite que a UDF/UDTF seja executada e não falha na instrução que chama a UDF/UDTF devido a motivos de registro.

Privilégios da política de projeção¶

Snowflake oferece suporte aos seguintes privilégios no objeto de política de projeção.

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

Para obter mais detalhes, consulte Resumo de comandos DDL, operações e privilégios (neste tópico).

Referência DDL da política de projeção¶

O Snowflake oferece suporte ao seguinte DDL para criar e gerenciar políticas de projeção.

• CREATE PROJECTION POLICY

• ALTER PROJECTION POLICY

• DESCRIBE PROJECTION POLICY

• DROP PROJECTION POLICY

• SHOW PROJECTION POLICIES

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

A tabela a seguir resume a relação entre privilégios da política de projeção e operações DDL.

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 projeção em um objeto.

1. Para uma abordagem centralizada de gerenciamento de políticas de projeção, na qual a função personalizada projection_policy_admin cria e define políticas de projeção: em todas as colunas, são necessárias as seguintes permissões:

   USE ROLE securityadmin;
   GRANT USAGE ON DATABASE mydb TO ROLE projection_policy_admin;
   GRANT USAGE ON SCHEMA mydb.schema TO ROLE projection_policy_admin;
   
   GRANT CREATE PROJECTION POLICY ON SCHEMA mydb.schema TO ROLE projection_policy_admin;
   GRANT APPLY ON PROJECTION POLICY ON ACCOUNT TO ROLE projection_policy_admin;
   

   Copy

2. Em uma abordagem híbrida de gerenciamento, uma única função tem o privilégio CREATE PROJECTIONPOLICY para assegurar que as políticas de projeção sejam nomeadas de forma consistente e que equipes ou funções individuais tenham o privilégio APPLY para uma política de projeção específica.

   Por exemplo, a função personalizada finance_role pode receber a permissão para definir a política de projeção cost_center em tabelas e exibições que a função possui (ou seja, a função tem o privilégio OWNERSHIP sobre a tabela ou exibição):

   USE ROLE securityadmin;
   GRANT CREATE PROJECTION POLICY ON SCHEMA mydb.schema TO ROLE projection_policy_admin;
   GRANT APPLY ON PROJECTION POLICY cost_center TO ROLE finance_role;
   

   Copy