Compreensão das políticas de tabela de clean room¶

As salas limpas podem implementar políticas de dados para controlar como os colaboradores podem usá-los. Essas políticas são adicionais às políticas de tabela do Snowflake definidas nas tabelas subjacentes vinculadas à sala limpa.

Cada colaborador em uma sala limpa pode definir políticas para seus próprios dados. Suas políticas são aplicadas somente às solicitações de outros usuários, e não às suas próprias solicitações. Por exemplo, se a sua política de junção permitir junções somente na coluna A, outros usuários estarão restritos a junções na coluna A, mas você poderá aplicar junções a qualquer uma de suas colunas.

As políticas de clean room podem ser definidas usando a API ou UI de clean room.

Para implementar verificações de política, estas condições devem ser verdadeiras:

O proprietário dos dados deve definir uma política na sala limpa dele. Você pode definir políticas usando a API ou a UI. Cada tipo de política é definida separadamente. A sala limpa implementa nativamente políticas de coluna, de linha e de ativação. As políticas de sala limpa não são aditivas: quando você define uma política de sala limpa, todos os valores anteriores são excluídos.

-- Sets a join policy on column HASHED_EMAIL.
CALL samooha_by_snowflake_local_db.provider.set_join_policy(
  'my_provider_cleanroom',
  ['my_db.my_sch.T1:HASHED_EMAIL']);

-- Replaces the previous join policy. Now the only column in the join policy is AGE_BND.
CALL samooha_by_snowflake_local_db.provider.set_join_policy(
  'my_provider_cleanroom',
  ['my_db.my_sch.T1:AGE_BAND']);

Copy

O modelo deve verificar a política no local apropriado do modelo. Uma política de sala limpa será verificada somente se tiver o filtro de política apropriado aplicado à coluna no modelo. Se você definir uma política de sala limpa para proteger seus dados, deverá examinar o modelo para confirmar se ele está aplicando suas políticas conforme o esperado. O seguinte modelo verifica se col1 é permitida pela política de coluna do proprietário dos dados:
```
SELECT
  IDENTIFIER( {{ col1 | column_policy }} )
FROM {{ source_table[0] }} AS c;
```
Copy
O seguinte modelo não verifica se col1 tem uma política de sala limpa:
```
SELECT
  IDENTIFIER( {{ col1 }})
FROM {{ source_table[0] }} AS c;
```
Copy
As salas limpas oferecem suporte a um filtro de modelo diferente para cada tipo de política. Entretanto, a semântica do filtro não é verificada, apenas se a coluna está na política para esse tipo de filtro. Por exemplo, no trecho a seguir, col1 é verificada na política de junção, mesmo que a coluna não esteja passando por junção. Se col1 estiver na política de junção do proprietário dos dados, a consulta poderá ser bem-sucedida; se col1 não estiver na política de junção do proprietário dos dados, a consulta será bloqueada.
```
SELECT
  IDENTIFIER( {{ col1 | join_policy }})
FROM {{ source_table[0] }} AS c;
```
Copy

Nota

As verificações de política de coluna são realizadas quando o modelo JinjaSQL é analisado. As consultas com curingas podem não ser detectadas com essas verificações, e você deve ter cuidado ao criar um modelo de análise. Se houver colunas que realmente nunca devem ser consultadas, considere criar uma exibição de sua tabela de origem que elimine essas colunas confidenciais e crie um link nessa exibição.

Políticas do Snowflake em salas limpas¶

Quando você vincula tabelas a uma sala limpa, as políticas de tabela do Snowflake nas tabelas de origem são aplicadas às tabelas vinculadas na sala limpa, mas essas políticas não são necessariamente relatadas pela API ou UI de sala limpa. Por exemplo, uma política de junção do Snowflake continua sendo aplicada à sala limpa, mas não fica visível ao chamar consumer.view_provider_join_policy ou consumer.view_join_policy. Portanto, você deve remover as políticas das tabelas vinculadas subjacentes, criar políticas de sala limpa equivalentes (quando houver) ou comunicar a existência dessas políticas claramente aos seus colaboradores para evitar que as consultas deles falhem ou se comportem de maneira inesperada («por que não consigo aplicar a junção a esta coluna?»).

Qualquer alteração feita nas políticas do Snowflake nas tabelas de origem é propagada automaticamente para as exibições vinculadas na sala limpa.

As políticas de privacidade do Snowflake impedem a criação de uma exibição a partir de uma tabela protegida; portanto, você não pode criar links em tabelas que tenham políticas de privacidade.

As seguintes políticas podem ser aplicadas diretamente a uma sala limpa:

Políticas de junção¶

Defina uma política de junção para indicar quais colunas em seus dados podem ser unidas por qualquer modelo na sala limpa. (Por outro lado, as políticas de junção do Snowflake especificam as colunas às quais aplicar a junção). As políticas de junção se aplicam a todos os modelos na sala limpa.

Uma coluna não pode estar em uma política tanto de junção quanto de coluna, mas uma coluna pode estar em ambas políticas de junção e de ativação.

Implementação de uma política de associação¶

As políticas de junção de sala limpa são aplicadas a uma coluna se o modelo aplica o filtro join_policy ou join_and_column_policy à coluna.

Se um modelo verificar uma política de junção para uma coluna e a sala limpa não tiver políticas de junção definidas, ou a coluna não estiver na política de junção, a consulta será bloqueada.

O código a seguir mostra como definir políticas de junção como provedor ou consumidor. Lembre-se de que as políticas são aplicadas apenas a consultas executadas por outra conta.

-- Set join policies on two columns in a clean room where you are a provider.
CALL samooha_by_snowflake_local_db.provider.set_join_policy(
  'my_provider_cleanroom',
  ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:HASHED_EMAIL', 'MYDB.MYSCH.EXPOSURES:HASHED_EMAIL']);

-- Set join policies on two columns in a clean room where you are a consumer.
CALL samooha_by_snowflake_local_db.consumer.set_join_policy(
  'my_consumer_cleanroom',
  ['SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:HASHED_EMAIL', 'MYDB.MYSCH.EXPOSURES:HASHED_EMAIL']);

Copy

Os procedimentos a seguir são usados para visualizar ou gerenciar políticas de associação no código:

consumer.set_join_policy
consumer.view_provider_join_policy
consumer.view_join_policy
provider.view_join_policy
provider.set_join_policy

Políticas de coluna¶

Defina uma política de coluna para indicar quais das suas colunas podem ser projetadas nos resultados da análise com base em um modelo específico. As políticas de coluna são aplicadas a modelos específicos em uma determinada sala limpa.

Uma coluna não pode estar em uma junção e em uma política de coluna. Uma coluna pode estar tanto em uma política de ativação quanto em uma política de coluna.

Implementação de uma política de coluna¶

As políticas de coluna de sala limpa são aplicadas a uma coluna somente se o modelo usa o filtro column_policy ou join_and_column_policy.

Se uma sala limpa verificar uma política de coluna para uma coluna e a coluna não estiver na política de coluna, ou a sala limpa não tiver políticas de coluna, a consulta será bloqueada.

O código a seguir mostra como definir políticas de coluna para três colunas quando acessadas pelo modelo prod_overlap_analysis. O exemplo a seguir mostra como definir a política como provedor e consumidor. Lembre-se de que as políticas são aplicadas apenas a consultas executadas por outra conta.

-- Set column policy on prod_overlap_analysis template in a clean room where
-- you are a provider.
call samooha_by_snowflake_local_db.provider.set_column_policy(
  'my_provider_cleanroom',
  ['prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:STATUS',
   'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:AGE_BAND',
   'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:DAYS_ACTIVE']);

-- Set column policy on prod_overlap_analysis template in a clean room where
-- you are a consumer.
call samooha_by_snowflake_local_db.consumer.set_column_policy(
  'my_consumer_cleanroom',
  ['prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:STATUS',
   'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:AGE_BAND',
   'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:DAYS_ACTIVE']);

Copy

Os procedimentos a seguir são usados para visualizar ou gerenciar políticas de coluna no código:

consumer.set_column_policy
consumer.view_column_policy
consumer.view_provider_column_policy
provider.set_column_policy
provider.view_column_policy

Políticas de ativação¶

Defina uma política de ativação para indicar quais das suas colunas podem ser ativadas por um modelo de ativação. A ativação salva os resultados da consulta em uma tabela na conta Snowflake do provedor ou do consumidor, ou em um conector de ativação de terceiros.

Uma coluna pode fazer parte de uma política de ativação, bem como de qualquer outra política.

Implementação de uma política de ativação¶

As políticas de ativação podem ser definidas na UI de clean rooms se o modelo permitir a ativação.

As políticas de ativação são definidas para uma coluna específica em um determinado modelo.

As políticas de ativação são aplicadas a uma coluna somente se o modelo aplica o filtro activation_policy à coluna.

O código a seguir demonstra a configuração de uma política de ativação para permitir que as colunas HASHED_EMAIL e REGION_CODE sejam ativadas em uma sala limpa. Essa política afeta todos os usuários e modelos de ativação na sala limpa. Existem procedimentos equivalentes para provedores e consumidores em uma sala limpa. Chame o procedimento que reflete sua função na sala limpa.

-- Set activation policy on prod_overlap_analysis template in a clean room where you are a provider
call samooha_by_snowflake_local_db.provider.set_activation_policy('my_cleanroom', [
    'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:HASHED_EMAIL',
    'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE.DEMO.CUSTOMERS:REGION_CODE' ]);

-- Set activation policy on prod_overlap_analysis template in a clean room where you are a consumer
call samooha_by_snowflake_local_db.consumer.set_activation_policy('my_cleanroom', [
    'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE_NAME.DEMO.CUSTOMERS:HASHED_EMAIL',
    'prod_overlap_analysis:SAMOOHA_SAMPLE_DATABASE_NAME.DEMO.CUSTOMERS:REGION_CODE' ]);

Copy

Os procedimentos a seguir são usados para gerenciar as políticas de ativação no código:

consumer.set_activation_policy
provider.set_activation_policy

Políticas de agregação¶

As políticas de agregação exigem que todas as consultas em uma tabela contenham agregações (GROUP BY, COUNT e outras funções), além de especificar um número mínimo de linhas por grupo de resultados, ou o grupo será omitido dos resultados.

As clean rooms não têm sua própria implementação de políticas de agregação; para aplicar restrições de agregação nos dados vinculados, aplique uma política de agregação na tabela de origem ou implemente restrições de agregação em seu modelo.

Alguns modelos fornecidos pelo Snowflake usam os parâmetros threshold e threshold_value definidos para um usuário ou modelo. Esses valores podem ser modificados na UI de clean rooms, ou chamando provider.add_consumers ou provider/consumer.set_privacy. Se definido para um consumidor, você pode acessar esses valores em seu modelo.