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: **Topics** + [Permitir dados mistos cleartext e criptografados em suas tabelas](#allow-mixed-plaintext-and-encrypted-data) + [Permitir valores repetidos em colunas fingerprint](#allow-repeated-values) + [Afrouxar as restrições sobre como as colunas fingerprint são nomeadas](#loose-restrictions-on-join-column-names) + [Determinar como os valores NULL são representados](#determine-null-values) Para obter mais informações sobre como definir parâmetros para esses cenários, consulte [Parâmetros de computação criptográfica](crypto-computing-parameters.md). ## 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](crypto-computing-parameters.md#parameter-allowcleartext). ## 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](crypto-computing-parameters.md#parameter-allowduplicates). ## 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](crypto-computing-parameters.md#parameter-allowjoin). ## 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](crypto-computing-parameters.md#parameter-preservenulls).