Implementação de privacidade diferencial¶

Requisitos estruturais para privacidade em nível de entidade¶

A estrutura de dados protegidos pela privacidade diferencial em nível de entidade deve estar em conformidade com certos requisitos. Esses requisitos devem ser atendidos para que a Snowflake possa rastrear com precisão a perda de privacidade associada às entidades.

Você deve estruturar seus dados para atender a esses requisitos antes de aplicar políticas de privacidade para implementar privacidade diferencial. A Snowflake não pode determinar se os dados estão em conformidade com esses requisitos estruturais porque eles dizem respeito ao significado dos dados, não à implementação de privacidade diferencial. Por exemplo, se as chaves de entidade de duas tabelas diferentes estiverem definidas para a coluna user_id, mas uma das colunas contiver valores para um identificador numérico enquanto a outra coluna contiver endereços de e-mail, o Snowflake não poderá vincular corretamente as informações da entidade nas duas tabelas.

Para atingir a privacidade em nível de entidade, seus dados devem estar em conformidade com os seguintes requisitos:

• Cada linha pertence a apenas um indivíduo dentro de uma entidade — Por exemplo, suponha que uma tabela contenha usuários e domicílios. Se a entidade que precisa ser protegida forem usuários, a tabela não poderá ser estruturada de forma que cada linha seja um domicílio e todos os usuários desse domicílio sejam capturados em outras colunas. Você precisaria reestruturar a tabela para que houvesse apenas uma linha por usuário, com uma coluna household_id para indicar a qual domicílio o usuário pertence.

• Identificador de entidade consistente em todas as tabelas — Você pode criar uma política de privacidade que represente a proteção necessária para uma única entidade e, em seguida, aplicar essa política a várias tabelas que contenham informações sobre a entidade. Ao atribuir a política de privacidade a cada tabela, você precisa especificar a coluna que identifica exclusivamente a entidade (ou seja, a chave da entidade). O valor que identifica exclusivamente uma entidade dentro dessas colunas de chave de entidade deve ser o mesmo. Por exemplo, suponha que a coluna email seja a chave de entidade para duas tabelas que contêm informações sobre uma entidade. Se o endereço de e-mail de uma entidade for joe@company.com em uma tabela, o endereço de e-mail na outra tabela também deverá ser joe@company.com.

• Identificador de entidade em todas as tabelas — Embora não seja necessário implementar a privacidade em nível de entidade, você pode permitir que os analistas minimizem o ruído nas junções de consulta incluindo o identificador de entidade em todas as tabelas relacionadas a uma entidade. Em alguns casos, pode ser necessário desnormalizar a coluna de chave da entidade para atender a esse requisito. Por exemplo, suponha que você tenha as seguintes tabelas onde a entidade é clientes:

  Tabela	Descrição
  customer	Diretório de clientes, onde cada linha é um cliente e tem um customer_id.
  transactions	Transações de clientes, onde cada linha é uma transação e tem um transaction_id. Cada cliente pode ter múltiplas transações.
  transaction_lines	Itens exclusivos que foram comprados em uma transação. Pode haver várias linhas em uma única transação.

  De acordo com as melhores práticas de normalização, a tabela transaction_lines teria o transaction_id, mas não o customer_id. A tabela transaction_lines seria vinculada à tabela transactions, que poderia então ser vinculada à tabela customers com customer_id.

  No entanto, para privacidade diferencial, você provavelmente deseja otimizar os dados para o analista adicionando o identificador customer_id à tabela transaction_lines. Isso permite que o analista minimize o ruído ao incluir customer_id na chave de junção ao unir a tabela transaction_lines com outra tabela.

Compartilhamento de dados¶

Exibições e tabelas seguras com uma política de privacidade são protegidas por privacidade diferencial quando adicionadas a um compartilhamento. Exibições não seguras não são protegidas por políticas de privacidade se forem consultadas por meio de um compartilhamento.

Replicação¶

Para considerações ao replicar políticas de privacidade e tabelas e exibições protegidas por privacidade, consulte Políticas de privacidade.

Preenchimento automático entre nuvens¶

Tenha em mente o seguinte ao usar o preenchimento automático entre nuvens para replicar um produto de dados:

• Os administradores na conta para a qual o produto de dados foi replicado não podem ajustar o orçamento de privacidade.

• Os administradores não podem usar uma única conta para exibir a perda de privacidade ocorrida em todas as regiões.

Clonagem¶

Para os efeitos da clonagem de tabelas e exibições protegidas por privacidade, consulte Clonagem e privacidade diferencial.

Exibições criadas em um objeto base protegido por privacidade¶

Você pode criar uma exibição em uma tabela ou exibição protegida por privacidade. No entanto, os domínios de privacidade da tabela base ou da exibição não são herdados. Como resultado, observe o seguinte:

• Os domínios de privacidade devem ser definidos nas colunas da nova exibição.

• Ajustar o domínio de privacidade da tabela base não afeta os domínios de privacidade da exibição criada nela.

Exibições materializadas¶

Você pode atribuir uma política de privacidade a uma exibição materializada para torná-la protegida por privacidade.

Outras interações entre políticas de privacidade e exibições materializadas incluem o seguinte:

• Você não pode criar uma exibição materializada com base em uma tabela ou exibição protegida por privacidade.

• Você não pode atribuir uma política de privacidade a uma tabela se ela for referenciada como a tabela base de uma exibição materializada.

UDFs¶

Analistas não podem usar uma função definida pelo usuário para consultar uma tabela protegida por privacidade.

Fluxos¶

Não é possível consultar um fluxo baseado em uma tabela protegida por privacidade.

Você não pode atribuir uma política de privacidade a um fluxo.

Outras políticas¶

As políticas de privacidade interagem com outras políticas da Snowflake das seguintes maneiras:

Políticas de mascaramento

Não é possível atribuir uma política de privacidade e uma política de mascaramento à mesma tabela ou exibição.

Políticas de acesso a linhas

As políticas de acesso a linhas têm precedência sobre uma política de privacidade. Se uma linha for bloqueada pela política de acesso a linhas, ela não será incluída nos resultados da consulta privada diferencial.

Políticas de projeção

Atualmente, não há suporte para proteger uma tabela com uma política de privacidade e qualquer uma de suas colunas com uma política de projeção ao mesmo tempo. Embora você possa atribuir as políticas dessa maneira, as consultas na tabela falharão.

Políticas de agregação

Você não pode atribuir uma política de privacidade e uma política de agregação à mesma tabela ou exibição.

Tabelas dinâmicas¶

Não é possível criar uma tabela dinâmica quando a tabela de origem referenciada é protegida por privacidade.

Você pode atribuir uma política de privacidade a uma tabela referenciada por uma tabela dinâmica existente; no entanto, depois que a política for atribuída, a tabela dinâmica não será mais atualizada.

Tabelas externas¶

Você pode atribuir uma política de privacidade a uma tabela externa. Se um analista tentar agregar em uma coluna VARIANT, a consulta falhará. No entanto, se um analista tentar agregar em uma coluna virtual, ele terá sucesso.

Time Travel¶

Para Time Travel, quando uma versão anterior de uma tabela é copiada como uma nova tabela, a versão atual de um domínio de privacidade é usada para a tabela porque o Snowflake não armazena versões anteriores do domínio de privacidade nos metadados da tabela.