Políticas de agregação¶

Limitações¶

Para esta versão preliminar:

• Se a consulta usar uma construção de agrupamento explícita, ela deverá ser uma cláusula GROUP BY. A consulta não pode usar construções relacionadas como GROUP BY ROLLUP, GROUP BY CUBE ou GROUP BY GROUPING SETS.

• A maioria dos operadores de conjuntos não são permitidos quando uma das consultas atua em uma tabela com agregação restrita. Como exceção, UNION ALL é suportado, mas cada grupo de resultados deve satisfazer o tamanho mínimo do grupo das tabelas com restrição de agregação que estão sendo consultadas (consulte Requisitos de consulta para obter detalhes).

• Se uma coluna de uma tabela com restrição de agregação estiver protegida por uma política de projeção, uma consulta nessa tabela não poderá usar a coluna como argumento da função COUNT.

• CTEs recursivos não são permitidos em consultas em uma tabela ou exibição com agregação restrita.

• As funções de janela não são permitidas em consultas em uma tabela ou exibição com agregação restrita.

• Uma consulta em uma tabela com restrição de agregação não pode usar uma subconsulta correlacionada ou uma junção lateral quando há referências de ou para a parte da consulta que atende aos requisitos da política de agregação. Os exemplos a seguir ilustram os tipos de consultas que são proibidas.

  Exemplo 1

  Supondo que protected_table seja restrito por agregação, a consulta a seguir não será permitida porque a parte da consulta que agrega dados faz referência a outra parte da consulta fora da subconsulta:

  SELECT c1, c2
  FROM open_table
  WHERE c1 = (SELECT x FROM protected_table WHERE y = open_table.c2);
  

  Copy

  Exemplo 2

  Supondo que protected_table seja restrito por agregação, a consulta a seguir não será permitida porque a subconsulta faz referência à parte da consulta que agrega dados, que está fora da subconsulta:

  SELECT
    SUM(SELECT COUNT(*) FROM open_table ot WHERE pt.id = ot.id)
  FROM protected_table pt;
  

  Copy

Considerações¶

Considere o seguinte ao usar políticas de agregação para proteger dados confidenciais:

• As políticas de agregação protegem os dados de um registro individual, não de uma entidade. Se um conjunto de dados contiver vários registros pertencentes à mesma entidade, uma política de agregação protegerá apenas a privacidade de um registro específico pertencente a essa entidade, e não a entidade inteira.

• Embora as políticas de agregação limitem o acesso a registos individuais, elas não garantem que um agente mal-intencionado não possa utilizar consultas deliberadas para obter dados potencialmente sensíveis de uma tabela com agregação restrita. Com tentativas de consulta suficientes, um agente mal-intencionado poderia contornar os requisitos de agregação para determinar um valor de uma linha individual. As políticas de agregaçã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).

Chamada de funções internas do corpo¶

O corpo de uma política de agregação utiliza duas funções internas para definir as restrições da política: NO_AGGREGATION_CONSTRAINT e AGGREGATION_CONSTRAINT. Quando as condições do corpo chamam uma dessas funções, o valor retornado da função determina como as consultas na tabela ou exibição restrita por agregação devem ser formuladas para retornar resultados.

NO_AGGREGATION_CONSTRAINT

Quando o corpo da política retorna um valor dessa função, as consultas podem retornar dados de uma tabela ou exibição com restrição de agregação sem restrições. Por exemplo, o corpo da política poderia chamar esta função quando um administrador precisasse obter resultados não agregados da tabela ou exibição com restrição de agregação.

Chame NO_AGGREGATION_CONSTRAINT sem argumento.

AGGREGATION_CONSTRAINT

Quando o corpo da política retorna um valor desta função, as consultas devem agregar dados para retornar resultados. Use o argumento MIN_GROUP_SIZE para especificar quantos registros devem ser incluídos em cada grupo de agregação.

A sintaxe da função AGGREGATION_CONSTRAINT é:

AGGREGATION_CONSTRAINT ( MIN_GROUP_SIZE => <integer_expression> )

Copy

Onde integer_expression resolve o tamanho mínimo do grupo da política.

Há uma diferença entre passar 1 e 0 como argumento para a função. Ambos exigem que os resultados sejam agregados.

• Passar um 1 também exige que cada grupo de agregação contenha pelo menos um registro da tabela restrita por agregação. Portanto, para junções externas, pelo menos um registro da tabela com restrição de agregação deve corresponder a um registro de uma tabela desprotegida.

• Passar um 0 permite que a consulta retorne grupos que consistem inteiramente em registros de outra tabela. Portanto, para junções externas entre uma tabela com restrição de agregação e uma tabela desprotegida, um grupo pode consistir em registros da tabela desprotegida que não correspondam a nenhum registro na tabela com restrição de agregação.

Exemplos de política¶

Tamanho mínimo fixo do grupo

A política de agregação mais simples chama a função AGGREGATION_CONSTRAINT diretamente e define um tamanho mínimo de grupo constante que é aplicado a todas as consultas na tabela. Por exemplo, o comando a seguir cria uma política de agregação com um tamanho mínimo de grupo de 5:

CREATE AGGREGATION POLICY my_agg_policy
  AS () RETURNS AGGREGATION_CONSTRAINT -> AGGREGATION_CONSTRAINT(MIN_GROUP_SIZE => 5);

Copy

Política condicional

Os administradores de políticas podem definir a expressão SQL de uma política de agregação para que consultas diferentes tenham restrições diferentes com base em fatores como a função do usuário que executa a consulta. Essa estratégia pode permitir que um usuário consulte uma tabela sem restrições enquanto exige que outros agreguem resultados.

Por exemplo, a política de agregação a seguir oferece aos usuários com a função ADMIN acesso irrestrito a uma tabela, ao mesmo tempo que exige que todas as outras consultas agreguem dados em grupos de pelo menos 5 linhas.

CREATE AGGREGATION POLICY my_agg_policy
  AS () RETURNS AGGREGATION_CONSTRAINT ->
    CASE
      WHEN CURRENT_ROLE() = 'ADMIN'
        THEN NO_AGGREGATION_CONSTRAINT()
      ELSE AGGREGATION_CONSTRAINT(MIN_GROUP_SIZE => 5)
    END;

Copy

Substituição de uma política de agregação¶

O método recomendado para substituir uma política de agregação é usar o parâmetro FORCE para desanexar a política de agregaçã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 agregação a uma tabela que já está com agregação restrita:

ALTER TABLE privacy SET AGGREGATION POLICY agg_policy_2 FORCE;

Você também pode desanexar a política de agregação de uma tabela ou exibição em uma instrução (… UNSET AGGREGATION POLICY) e, em seguida, definir uma nova política na tabela ou exibição em uma instrução diferente (… SET AGGREGATION POLICY <nome>). Se você escolher esse método, a tabela não será protegida por uma política de agregaçã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 políticas de agregação¶

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

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

Copy

Identificação de referências de política de agregação¶

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

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

   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(policy_name => 'my_db.my_schema.aggpolicy'));
   

   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

Outras políticas¶

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

Você pode anexar outras políticas a uma tabela com agregação restrita. Uma consulta bem-sucedida na tabela deve atender aos requisitos de todas as políticas.

Se uma política de acesso a linhas for atribuída a uma tabela com restrição de agregação, uma linha excluída dos resultados da consulta com base na política de acesso a linhas não será incluída no cálculo dos resultados agregados.

O corpo de uma política de mascaramento, política de acesso a linhas ou política de projeção não pode fazer referência a uma tabela com restrição de agregação, incluindo suas colunas. Da mesma forma, o corpo da outra política não pode incluir uma UDF que faça referência à tabela restrita por agregação.

Exibições e exibições materializadas¶

Você pode atribuir uma política de agregação às exibições e exibições materializadas. Quando uma política de agregação é aplicada a uma exibição, a tabela subjacente não fica restrita à agregação. Esta tabela base ainda pode ser consultada sem restrições.

Para evitar a possibilidade de exposição de dados confidenciais, todas as exibições com restrição de agregação são tratadas como se fossem exibições seguras, mesmo que não o sejam.

A possibilidade de criar uma exibição a partir de uma tabela com agregação restrita depende do tipo de exibição:

• Você pode criar uma exibição regular a partir de uma ou mais tabelas com restrição de agregação; no entanto, as consultas nessa exibição devem agregar dados de uma forma que atenda às restrições dessas tabelas base.

• Você não pode criar uma exibição materializada com base em uma tabela ou exibição restrita por agregação, nem pode atribuir uma política de agregação a uma tabela ou exibição na qual uma exibição materializada se baseia.

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 agregação não é permitida.

• A clonagem de um banco de dados resulta na clonagem de todas as políticas de agregação do banco de dados.

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

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

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

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

Snowflake oferece suporte aos seguintes privilégios no objeto de política de agregaçã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 agregação¶

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

• CREATE AGGREGATION POLICY

• ALTER AGGREGATION POLICY

• DESCRIBE AGGREGATION POLICY

• DROP AGGREGATION POLICY

• SHOW AGGREGATION 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 agregaçã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 agregação em um objeto.

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

   USE ROLE securityadmin;
   GRANT USAGE ON DATABASE mydb TO ROLE agg_policy_admin;
   GRANT USAGE ON SCHEMA mydb.schema TO ROLE proj_policy_admin;
   GRANT CREATE AGGREGATION POLICY ON SCHEMA mydb.schema TO ROLE aggregation_policy_admin;
   GRANT APPLY ON AGGREGATION POLICY ON ACCOUNT TO ROLE aggregation_policy_admin;
   

   Copy

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

   Por exemplo, a função personalizada finance_role pode receber a permissão para definir a política de agregaçã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 AGGREGATION POLICY ON SCHEMA mydb.schema TO ROLE aggregation_policy_admin;
   GRANT APPLY ON AGGREGATION POLICY cost_center TO ROLE finance_role;
   

   Copy