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á.

Diretrizes para o cliente de criptografia C3R

O cliente de criptografia C3R é uma ferramenta que permite às organizações reunir dados confidenciais para obter novos insights da análise de dados. A ferramenta limita criptograficamente o que pode ser aprendido por qualquer parte e AWS no processo. Embora isso seja de vital importância, o processo de proteger dados criptograficamente pode adicionar uma sobrecarga significativa em termos de recursos de computação e armazenamento. Portanto, é importante entender as vantagens e desvantagens de usar cada configuração e como otimizá-las e, ao mesmo tempo, manter as garantias criptográficas desejadas. Este tópico se concentra nas implicações de desempenho de diferentes configurações no cliente e nos esquemas de criptografia C3R.

Todas as configurações de criptografia do cliente de criptografia C3R oferecem diferentes garantias criptográficas. As configurações em nível de colaboração são mais seguras por padrão. Ativar funcionalidades adicionais ao criar uma colaboração enfraquece as garantias de privacidade, permitindo que atividades como análise de frequência sejam conduzidas no texto cifrado. Para obter mais informações sobre como essas configurações são usadas e quais são suas implicações, consulte Computação criptográfica para o Clean Rooms.

Implicações de desempenho para tipos de coluna

O C3R usa três tipos de coluna: cleartext, fingerprint e sealed. Cada um desses tipos de coluna fornece garantias criptográficas diferentes e tem diferentes usos pretendidos. Nas seções a seguir, são discutidas as implicações de desempenho do tipo de coluna e o impacto no desempenho de cada configuração.

colunas Cleartext

As colunas Cleartext não são alteradas de seu formato original e não são processadas criptograficamente de forma alguma. Esse tipo de coluna não pode ser configurado e não afeta o desempenho do armazenamento ou da computação.

colunas Fingerprint

As colunas Fingerprint devem ser usadas para unir dados em várias tabelas. Para esse fim, o tamanho do texto cifrado resultante deve ser sempre o mesmo. No entanto, essas colunas são afetadas pelas configurações de nível de colaboração. As colunas Fingerprint podem ter vários graus de impacto no tamanho do arquivo de saída, dependendo do conteúdo cleartext contido na entrada.

Sobrecarga básica para colunas fingerprint

Há uma sobrecarga básica para colunas fingerprint. Essa sobrecarga é constante e substitui o tamanho dos cleartext bytes.

Os dados nas colunas fingerprint são processados criptograficamente por meio de uma função de Código de Autenticação de Mensagens por Hash (HMAC), que transforma os dados em um código de autenticação de mensagem (MAC) de 32 bytes. Esses dados são então processados por meio de um codificador base64, adicionando aproximadamente 33% ao tamanho do byte. Ele é pré-fixado com uma designação C3R de 8 bytes para designar o tipo de coluna à qual os dados pertencem e a versão do cliente que os produziu. O resultado final é 52 bytes. Esse resultado é então multiplicado pela contagem de linhas para obter a sobrecarga base total (use o número total de valores não null se preserveNulls estiver definido como verdadeiro).

A imagem a seguir mostra como BASE_OVERHEAD = C3R_DESIGNATION + (MAC * 1.33)

O texto cifrado de saída nas colunas fingerprint sempre será de 52 bytes. Isso pode ser uma diminuição significativa no armazenamento se a média cleartext dos dados de entrada for superior a 52 bytes (por exemplo, endereços completos). Isso pode ser um aumento significativo no armazenamento se a média cleartext dos dados de entrada for inferior a 52 bytes (por exemplo, idade do cliente).

Configurações de colaboração para colunas fingerprint

Configuração da preserveNulls

Quando a configuração do nível de colaboração preserveNulls é false (padrão), cada valor null é substituído por 32 bytes exclusivos e aleatórios e processado como se não fosse null. O resultado é que cada valor null agora tem 52 bytes. Isso pode adicionar requisitos de armazenamento significativos para tabelas que contêm dados muito esparsos em comparação com quando essa configuração é true e null os valores são passados como null.

Se você não precisar das garantias de privacidade dessa configuração e preferir reter valores null em seus conjuntos de dados, habilite a configuração preserveNulls no momento em que a colaboração for criada. A configuração preserveNulls não pode ser alterada após a criação da colaboração.

Dados de exemplo para uma coluna fingerprint

Veja a seguir um exemplo de conjunto de dados de entrada e saída para uma coluna fingerprint com configurações a serem reproduzidas. Outras configurações em nível de colaboração, como allowCleartext e allowDuplicates não afetam os resultados, e podem ser definidas como true ou false se você estiver tentando se reproduzir localmente.

Exemplo de segredo compartilhado: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Exemplo de ID de colaboração: a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

allowJoinsOnColumnsWithDifferentNames: essa configuração True não afeta os requisitos de desempenho ou armazenamento. No entanto, essa configuração torna a escolha do nome da coluna irrelevante ao reproduzir os valores mostrados nas tabelas a seguir.

Colunas fingerprint de solução de problemas

Por que o texto cifrado em minhas colunas fingerprint é várias vezes maior do que o tamanho do cleartext que estava nele?

O texto cifrado em uma coluna fingerprint tem sempre 52 bytes de comprimento. Se seus dados de entrada forem pequenos (por exemplo, a idade dos clientes), eles mostrarão um aumento significativo no tamanho. Isso também pode acontecer se a configuração preserveNulls estiver definida como false.

Por que o texto cifrado em minhas colunas fingerprint é várias vezes menor do que o tamanho do cleartext que estava nele?

O texto cifrado em uma coluna fingerprint tem sempre 52 bytes de comprimento. Se seus dados de entrada forem grandes (por exemplo, os endereços completos dos clientes), eles mostrarão uma diminuição significativa no tamanho.

Como posso saber se preciso das garantias criptográficas fornecidas por preserveNulls?

Infelizmente, a resposta é que depende. No mínimo, Parâmetros de computação criptográfica deve ser revisado como a configuração preserveNulls está protegendo seus dados. No entanto, recomendamos que você consulte os requisitos de tratamento de dados da sua organização e quaisquer contratos aplicáveis à respectiva colaboração.

Por que eu tenho que incorrer na sobrecarga de base64?

Para permitir a compatibilidade com formatos de arquivo tabulares, como CSV, a codificação base64 é necessária. Embora alguns formatos de arquivo Parquet possam suportar representações binárias de dados, é importante que todos os participantes de uma colaboração representem os dados da mesma forma para garantir resultados de consulta adequados.

colunas Sealed

As colunas Sealed devem ser usadas para transferir dados entre membros de uma colaboração. O texto cifrado nessas colunas não é determinístico e tem um impacto significativo no desempenho e no armazenamento com base na configuração das colunas. Essas colunas podem ser configuradas individualmente e geralmente têm o maior impacto no desempenho do cliente de criptografia C3R e no tamanho do arquivo de saída resultante.

Sobrecarga básica para colunas sealed

Há uma sobrecarga básica para colunas sealed. Essa sobrecarga é constante e é adicionada ao tamanho dos bytes de preenchimento cleartext e (se houver).

Antes de qualquer criptografia, os dados nas colunas sealed são prefixados com um caractere de 1 byte que designa o tipo de dado contido. Se o preenchimento for selecionado, os dados serão então preenchidos e anexados com 2 bytes indicando o tamanho do bloco. Depois que esses bytes são adicionados, os dados são processados criptograficamente usando o AES-GCM e armazenados com IV (12 bytes), nonce (32 bytes) e Auth Tag (16 bytes). Esses dados são então processados por meio de um codificador base64, adicionando aproximadamente 33% ao tamanho do byte. Os dados são prefixados com uma designação C3R de 7 bytes para designar a que tipo de coluna os dados pertencem e a versão do cliente usada para produzi-los. O resultado é uma sobrecarga básica final de 91 bytes. Esse resultado pode então ser multiplicado pela contagem de linhas para obter a sobrecarga base total (use o número total de valores não nulos se preserveNulls estiver definido como verdadeiro).

A imagem a seguir mostra como BASE_OVERHEAD = C3R_DESIGNATION + ((NONCE + IV + DATA_TYPE + PAD_SIZE + AUTH_TAG) * 1.33)

Configurações de colaboração para colunas sealed

Configuração da preserveNulls

Quando a configuração do nível de colaboração preserveNulls é false (padrão), cada valor null é exclusivo, aleatório de 32 bytes e processado como se não fosse null. O resultado é que cada valor null agora tem 91 bytes (mais se for preenchido). Isso pode adicionar requisitos de armazenamento significativos para tabelas que contêm dados muito esparsos em comparação com quando essa configuração é true e null os valores são passados comonull.

Se você não precisar das garantias de privacidade dessa configuração e preferir reter valores null em seus conjuntos de dados, habilite a configuração preserveNulls no momento em que a colaboração for criada. A configuração preserveNulls não pode ser alterada após a criação da colaboração.

Colunas sealed de configurações do esquema: tipos de preenchimento

Tipo de almofada de none

Selecionar um tipo de bloco de none não adiciona nenhum preenchimento ao cleartext e não adiciona nenhuma sobrecarga adicional à sobrecarga básica descrita anteriormente. Nenhum preenchimento resulta no tamanho de saída mais eficiente em termos de espaço. No entanto, ele não oferece as mesmas garantias de privacidade que os tipos de preenchimento fixed e max. Isso ocorre porque o tamanho do subjacente cleartext é discernível do tamanho do texto cifrado.

Tipo de almofada de fixed

Selecionar um tipo de bloco de fixed é uma medida de preservação da privacidade para ocultar os tamanhos dos dados contidos em uma coluna. Isso é feito preenchendo tudo o que é cleartext fornecido pad_length antes de ser criptografado. Qualquer dado que exceda esse tamanho faz com que o cliente de criptografia C3R falhe.

Como o preenchimento é adicionado ao cleartext antes de ser criptografado, o AES-GCM tem um mapeamento de 1 para 1 de dois bytes de texto cifrado cleartext. A codificação base64 adicionará 33 por cento. A sobrecarga adicional de armazenamento do preenchimento pode ser calculada subtraindo o comprimento médio do valor cleartext do pad_length e multiplicando-o por 1,33. O resultado é a sobrecarga média de preenchimento por registro. Esse resultado pode então ser multiplicado pelo número de linhas para obter a sobrecarga total de preenchimento (use o número total de valores não null se preserveNulls estiver definido como true).

PADDING_OVERHEAD = (PAD_LENGTH - AVG_CLEARTEXT_LENGTH) * 1.33 * ROW_COUNT

Recomendamos que você selecione o mínimo pad_length que engloba o maior valor em uma coluna. Por exemplo, se o maior valor for 50 bytes, um pad_length de 50 é suficiente. Um valor maior do que isso só aumentará a sobrecarga de armazenamento.

O preenchimento fixo não adiciona nenhuma sobrecarga computacional significativa.

Tipo de almofada de max

Selecionar um tipo de bloco de max é uma medida de preservação da privacidade para ocultar os tamanhos dos dados contidos em uma coluna. Isso é feito preenchendo todo o valor cleartext até o maior valor na coluna, mais o adicional, pad_length antes de ser criptografado. Geralmente, o preenchimento max fornece as mesmas garantias que o preenchimento fixed para um único conjunto de dados, ao mesmo tempo em que permite não saber o maior valor cleartext na coluna. No entanto, o preenchimento max pode não fornecer as mesmas garantias de privacidade que o preenchimento fixed entre atualizações, pois o maior valor nos conjuntos de dados individuais pode ser diferente.

Recomendamos que você selecione um adicional pad_length de 0 ao usar o preenchimento max. Esse comprimento preenche todos os valores para que tenham o mesmo tamanho do maior valor na coluna. Um valor maior do que isso só aumentará a sobrecarga de armazenamento.

Se o maior valor cleartext for conhecido para uma determinada coluna, recomendamos que você use o tipo fixed pad em vez disso. O uso do preenchimento fixed cria consistência nos conjuntos de dados atualizados. O uso do preenchimento max resulta em cada subconjunto de dados sendo preenchido até o maior valor que estava no subconjunto.

Dados de exemplo para uma coluna sealed

Veja a seguir um exemplo de conjunto de dados de entrada e saída para uma coluna sealed com configurações a serem reproduzidas. Outras configurações em nível de colaboração, como allowCleartext, allowJoinsOnColumnsWithDifferentNames e allowDuplicates não afetam os resultados e podem ser definidas como true ou false se você estiver tentando se reproduzir localmente. Embora essas sejam as configurações básicas a serem reproduzidas, a coluna sealed não é determinística e os valores mudarão sempre. O objetivo é mostrar os bytes de entrada em comparação com os bytes de saída. Os valores pad_length de exemplo foram escolhidos intencionalmente. Eles mostram que o preenchimento fixed resulta nos mesmos valores do preenchimento max com as configurações pad_length mínimas recomendadas ou quando um preenchimento adicional é desejado.

Exemplo de segredo compartilhado: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Exemplo de ID de colaboração: a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

Tipo de preenchimento de none

Tipo de almofada de fixed (Exemplo 1)

Neste exemplo, pad_length é 62 e a maior entrada é 62 bytes.

Tipo de almofada de fixed (Exemplo 2)

Neste exemplo, pad_length é 162 e a maior entrada é 62 bytes.

Tipo de almofada de max (Exemplo 1)

Neste exemplo, pad_length é 0 e a maior entrada é 62 bytes.

Tipo de almofada de max (Exemplo 2)

Neste exemplo, pad_length é 100 e a maior entrada é 62 bytes.

Colunas sealed de solução de problemas

Por que o texto cifrado em minhas colunas sealed é várias vezes maior do que o tamanho do cleartext que estava nele?

Isso depende de diversos fatores. Por um lado, o texto cifrado em uma coluna Cleartext tem sempre pelo menos 91 bytes de comprimento. Se seus dados de entrada forem pequenos (por exemplo, a idade dos clientes), eles mostrarão um aumento significativo no tamanho. Segundo, se preserveNulls fossem definidos como false e seus dados de entrada contivessem muitos valores null, cada um desses valores null teria sido transformado em 91 bytes de texto cifrado. Por fim, se você usa preenchimento, por definição, bytes são adicionados aos dados cleartext antes de serem criptografados.

A maioria dos meus dados em uma coluna sealed é muito pequena e preciso usar preenchimento. Posso simplesmente remover os valores grandes e processá-los separadamente para economizar espaço?

Não recomendamos remover valores grandes e processá-los separadamente. Isso altera as garantias de privacidade que o cliente de criptografia C3R está fornecendo. Como modelo de ameaça, suponha que um observador possa ver os dois conjuntos de dados criptografados. Se o observador perceber que um subconjunto de dados tem uma coluna preenchida significativamente mais ou menos do que outro subconjunto, ele poderá fazer inferências sobre o tamanho dos dados em cada subconjunto. Por exemplo, suponha que uma coluna fullName seja preenchida com um total de 40 bytes em um arquivo e seja preenchida com 800 bytes em outro arquivo. Um observador pode presumir que um conjunto de dados contém o nome mais longo do mundo (747 bytes).

Preciso fornecer preenchimento extra ao usar o tipo de preenchimentomax?

Não. Ao usar o preenchimento max, recomendamos que o pad_length, também conhecido como preenchimento adicional além do maior valor na coluna, seja definido como 0.

Posso simplesmente escolher um grande pad_length ao usar o preenchimento fixed para evitar me preocupar se o maior valor caberá?

Sim, mas o tamanho grande da almofada é ineficiente e usa mais espaço de armazenamento do que o necessário. Recomendamos que você verifique o tamanho do maior valor e defina pad_length com esse valor.

Como posso saber se preciso das garantias criptográficas fornecidas por preserveNulls?

Infelizmente, a resposta é que depende. No mínimo, Computação criptográfica para o Clean Rooms deve ser revisado como a configuração preserveNulls está protegendo seus dados. No entanto, recomendamos que você consulte os requisitos de tratamento de dados da sua organização e quaisquer contratos aplicáveis à respectiva colaboração.

Por que eu tenho que incorrer na sobrecarga de base64?

Para permitir a compatibilidade com formatos de arquivo tabulares, como CSV, a codificação base64 é necessária. Embora alguns formatos de arquivo Parquet possam suportar representações binárias de dados, é importante que todos os participantes de uma colaboração representem os dados da mesma forma para garantir resultados de consulta adequados.

Solução de problemas de aumentos imprevistos no tamanho do texto cifrado

Digamos que você criptografou seus dados e o tamanho dos dados resultantes seja surpreendentemente grande. As etapas a seguir podem ajudá-lo a identificar onde ocorreu o aumento de tamanho e quais ações, se houver, você pode tomar.

Identificar onde ocorreu o aumento de tamanho

Antes de solucionar o motivo pelo qual seus dados criptografados são significativamente maiores do que seus dados cleartext, você deve primeiro identificar onde está o aumento no tamanho. As colunas Cleartext podem ser ignoradas com segurança porque não foram alteradas. Examine as colunas fingerprint e sealed restantes e escolha uma que pareça significativa.

Identificar o motivo pelo qual o aumento de tamanho ocorreu

Uma coluna fingerprint ou sealed pode contribuir para o aumento do tamanho.

O aumento de tamanho vem de uma coluna fingerprint?

Se a coluna que mais contribui para o aumento no armazenamento for uma coluna fingerprint, provavelmente é porque os dados cleartext são pequenos (por exemplo, idade do cliente). Cada texto cifrado fingerprint resultante tem 52 bytes de comprimento. Infelizmente, nada pode ser feito sobre esse problema em uma column-by-column base. Para obter mais informações, consulte Sobrecarga básica para colunas fingerprint para obter detalhes sobre essa coluna, inclusive como ela afeta os requisitos de armazenamento.

A outra causa possível do aumento de tamanho em uma coluna fingerprint é a configuração de colaboração, preserveNulls. Se a configuração de colaboração para preserveNulls estiver desativada (a configuração padrão), todos os valores null nas colunas fingerprint se tornarão 52 bytes de texto cifrado. Não há nada que possa ser feito para isso na colaboração atual. A configuração preserveNulls é definida no momento em que uma colaboração é criada e todos os colaboradores devem usar a mesma configuração para garantir os resultados corretos da consulta. Para obter mais informações sobre a configuração preserveNulls e como ativá-la afeta as garantias de privacidade de seus dados, consulte Computação criptográfica para o Clean Rooms.

O aumento de tamanho vem de uma coluna sealed?

Se a coluna que mais contribui para o aumento no armazenamento for uma coluna sealed, há alguns detalhes que podem contribuir para o aumento do tamanho.

Se os dados cleartext forem pequenos (por exemplo, idade do cliente), cada texto cifrado sealed resultante terá pelo menos 91 bytes de comprimento. Infelizmente, nada pode ser feito sobre esse problema. Para obter mais informações, consulte Sobrecarga básica para colunas sealed para obter detalhes sobre essa coluna, inclusive como ela afeta os requisitos de armazenamento.

A segunda principal causa do aumento do armazenamento nas colunas sealed é o preenchimento. O preenchimento adiciona bytes extras ao cleartext antes de ser criptografado para ocultar o tamanho dos valores individuais em um conjunto de dados. Recomendamos que você defina o preenchimento com o valor mínimo possível para seu conjunto de dados. No mínimo, pad_length para o preenchimento fixed deve ser definido para abranger o maior valor possível na coluna. Qualquer configuração maior do que essa não adiciona garantias adicionais de privacidade. Por exemplo, se você sabe que o maior valor possível em uma coluna pode ser de 50 bytes, recomendamos que você defina o valor pad_length para 50 bytes. No entanto, se a coluna sealed estiver usando preenchimento max, recomendamos que você defina pad_length como 0 bytes. Isso ocorre porque o preenchimento max se refere ao preenchimento adicional além do maior valor na coluna.

A causa final possível do aumento de tamanho em uma coluna sealed é a configuração de colaboração, preserveNulls. Se a configuração de colaboração para preserveNulls estiver desativada (a configuração padrão), todos os valores null nas colunas sealed se tornarão 91 bytes de texto cifrado. Não há nada que possa ser feito para isso na colaboração atual. A configuração preserveNulls é definida no momento em que uma colaboração é criada, e todos os colaboradores devem usar a mesma configuração para garantir os resultados corretos da consulta. Para obter mais informações sobre essa configuração e como ativá-la afeta as garantias de privacidade de seus dados, consulte Computação criptográfica para o Clean Rooms.