As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Considerações ao usar a computação criptográfica para o Clean Rooms
A computação criptográfica para o Clean Rooms (C3R) busca maximizar a proteção de dados. No entanto, alguns casos de uso podem se beneficiar de níveis mais baixos de proteção de dados em troca de funcionalidades adicionais. Você pode fazer essas compensações específicas modificando o C3R a partir de sua configuração mais segura. Como cliente, você deve estar ciente dessas desvantagens e determinar se elas são apropriadas para seu caso de uso. Compensações a serem consideradas incluem o seguinte:
Tópicos
Para obter mais informações sobre como definir parâmetros para esses cenários, consulte Parâmetros de computação criptográfica.
Permitir dados mistos cleartext e criptografados em suas tabelas
Ter todos os dados criptografados do lado do cliente fornece a máxima proteção de dados. No entanto, isso limita certos tipos de consultas (por exemplo, a função agregada SUM). O risco de permitir dados cleartext é que é possível que qualquer pessoa com acesso às tabelas criptografadas possa inferir algumas informações sobre valores criptografados. Isso pode ser feito realizando uma análise estatística dos dados associados cleartext.
Por exemplo, imagine que você tivesse as colunas de City e State. A coluna City está cleartext e a coluna State está criptografada. Quando você vê o valor Chicago na coluna City, isso ajuda a determinar com alta probabilidade que State é Illinois. Por outro lado, se uma coluna é City e a outra coluna é EmailAddress, é improvável que um cleartext City revele algo sobre uma criptografia EmailAddress.
Para obter mais informações sobre o parâmetro para este cenário, consulte Parâmetro Permitir colunas cleartext.
Permitir valores repetidos em colunas fingerprint
Para uma abordagem mais segura, presumimos que qualquer coluna fingerprint contenha exatamente uma instância de uma variável. Nenhum item pode ser repetido em uma coluna fingerprint. O cliente de criptografia C3R mapeia esses valores cleartext em valores exclusivos que são indistinguíveis de valores aleatórios. Portanto, é impossível inferir informações sobre cleartext partir desses valores aleatórios.
O risco de valores repetidos em uma coluna fingerprint é que valores repetidos resultarão em valores repetidos de aparência aleatória. Assim, qualquer pessoa que tenha acesso às tabelas criptografadas poderia, em teoria, realizar uma análise estatística das colunas fingerprint que poderiam revelar informações sobre valores cleartext.
Novamente, suponha que a fingerprint coluna seja State, e que cada linha da tabela corresponda a uma família dos EUA. Ao fazer uma análise de frequência, pode-se inferir qual estado é California e qual é Wyoming com alta probabilidade. Essa inferência é possível porque California tem muito mais residentes do que Wyoming. Em contraste, digamos que a coluna fingerprint esteja em um identificador familiar e cada família apareça no banco de dados entre 1 e 4 vezes em um banco de dados de milhões de entradas. É improvável que uma análise de frequência revele alguma informação útil.
Para obter mais informações sobre o parâmetro para este cenário, consulte Parâmetro Permitir duplicatas.
Afrouxar as restrições sobre como as colunas fingerprint são nomeadas
Por padrão, presumimos que, quando duas tabelas são unidas usando colunas fingerprint criptografadas, essas colunas têm o mesmo nome em cada tabela. A razão técnica para esse resultado é que, por padrão, derivamos uma chave criptográfica diferente para criptografar cada coluna fingerprint. Essa chave é derivada de uma combinação da chave secreta compartilhada para a colaboração e do nome da coluna. Se tentarmos unir duas colunas com nomes de colunas diferentes, derivaremos chaves diferentes e não conseguiremos calcular uma junção válida.
Para resolver esse problema, você pode desativar o atributo que deriva as chaves do nome de cada coluna. Em seguida, o cliente de criptografia C3R usa uma única chave derivada para todas as colunas fingerprint. O risco é que outro tipo de análise de frequência possa ser feito para revelar informações.
Vamos usar o exemplo City e State novamente. Se obtivermos os mesmos valores aleatórios para cada coluna fingerprint (não incorporando o nome da coluna), New York tem o mesmo valor aleatório nas colunas City e State. Nova York é uma das poucas cidades dos EUA em que o City nome é igual ao nome State. Por outro lado, se seu conjunto de dados tiver valores completamente diferentes em cada coluna, nenhuma informação será vazada.
Para obter mais informações sobre o parâmetro para este cenário, consulte Parâmetro de permissão JOIN de colunas com nomes diferentes.
Determinar como os valores NULL são representados
A opção disponível para você é processar valores criptograficamente (criptografar e HMAC) como qualquer outro valor NULL. Se você não processar valores NULL como qualquer outro valor, as informações poderão ser reveladas.
Por exemplo, suponha que NULL na coluna Middle Name em cleartext indique pessoas sem nome do meio. Se você não criptografar esses valores, divulgará quais linhas na tabela criptografada são usadas por pessoas sem segundo nome. Essa informação pode ser um sinal de identificação para algumas pessoas em algumas populações. Mas se você processa valores NULL criptograficamente, certas consultas SQL agem de forma diferente. Por exemplo, as cláusulas GROUP BY não agrupam valores fingerprint NULL em colunas fingerprint.
Para obter mais informações sobre o parâmetro para este cenário, consulte Parâmetro de preservação de valores NULL.
