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á.
Computação criptográfica para 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.
Permitindo misturar cleartext e dados 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, o SUM função agregada). O risco de permitir cleartext Os dados mostram 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 no cleartext e dados associados.
Por exemplo, imagine que você tivesse as colunas de City e State. A City coluna é cleartext e a State coluna é 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 for City e a outra coluna forEmailAddress, um cleartext Cityé improvável que revele algo sobre um criptografadoEmailAddress.
Para obter mais informações sobre o parâmetro para este cenário, consulte Permitir cleartext parâmetro de colunas.
Permitindo valores repetidos em fingerprint colunas
Para uma abordagem mais segura, presumimos que qualquer fingerprint a coluna contém exatamente uma instância de uma variável. Nenhum item pode ser repetido em um fingerprint coluna. O cliente de criptografia C3R mapeia esses cleartext valores em valores exclusivos que são indistinguíveis de valores aleatórios. Portanto, é impossível inferir informações sobre o cleartext a partir desses valores aleatórios.
O risco de valores repetidos em um fingerprint A coluna é 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 do fingerprint colunas que podem revelar informações sobre cleartext valores.
Novamente, suponha que o fingerprint A coluna éState, e cada linha da tabela corresponde 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, diga o fingerprint A coluna está em um identificador familiar e cada família apareceu 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.
Afrouxando as restrições sobre como fingerprint as colunas são nomeadas
Por padrão, presumimos que quando duas tabelas são unidas usando criptografia fingerprint colunas, 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 fingerprint coluna. 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 todos fingerprint colunas. 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 derivarmos os mesmos valores aleatórios para cada fingerprint coluna (ao não incorporar o nome da coluna). New Yorktem o mesmo valor aleatório nas State colunas City e. 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 Permitir JOIN parâmetro de colunas com nomes diferentes.
Determinando como NULL valores são representados
A opção disponível para você é se deseja processar criptograficamente (criptografar e HMAC) NULL valores como qualquer outro valor. Se você não processar NULL valores como qualquer outro valor, as informações podem ser reveladas.
Por exemplo, suponha que NULL na Middle Name coluna do cleartext indica pessoas sem sobrenomes. 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ê processar criptograficamente NULL valores, certas consultas SQL agem de forma diferente. Por exemplo, GROUP BY as cláusulas não serão agrupadas fingerprint
NULL valores em fingerprint colunas juntas.
Para obter mais informações sobre o parâmetro para este cenário, consulte Preservar NULL parâmetro de valores.
