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
Computação criptográfica para Clean Rooms (C3R) é um recurso AWS Clean Rooms que pode ser usado além das regras de [análise](analysis-rules.md). Com o C3R, as organizações podem reunir dados confidenciais para obter novos insights da análise de dados e, ao mesmo tempo, limitar criptograficamente o que pode ser aprendido por qualquer parte do processo. O C3R pode ser usado por duas ou mais partes que desejam colaborar com seus dados confidenciais, mas precisam usar apenas dados criptografados na nuvem.
O cliente de criptografia C3R é uma ferramenta de criptografia do lado do cliente que você pode usar para [criptografar seus dados](glossary.md#glossary-encryption) para uso. AWS Clean Rooms Quando você usa o cliente de criptografia C3R, os dados permanecem protegidos criptograficamente enquanto são usados em uma colaboração. AWS Clean Rooms Como em uma AWS Clean Rooms colaboração regular, os dados de entrada são tabelas de banco de dados relacionais e o cálculo é expresso como uma consulta SQL. No entanto, o C3R suporta apenas um subconjunto limitado de consultas SQL em dados criptografados.
Especificamente, o C3R suporta SQL JOIN and SELECT declarações sobre dados protegidos criptograficamente. Cada coluna na tabela de entrada pode ser usada em exatamente um dos seguintes tipos de instrução SQL:
+ Colunas protegidas criptograficamente para uso em JOIN declarações são chamadas **fingerprint colunas**.
+ Colunas protegidas criptograficamente para uso em SELECT declarações são chamadas **sealed colunas**.
+ Colunas que não são protegidas criptograficamente para uso em JOIN or SELECT declarações são chamadas **cleartext colunas**.
Em alguns casos, GROUP BY as declarações são apoiadas em fingerprint colunas. Para obter mais informações, consulte [colunas Fingerprint](crypto-computing-column-types.md#fingerprint-columns). Atualmente, o C3R não suporta o uso de outras construções SQL em dados criptografados, como WHERE cláusulas ou funções agregadas como SUM and AVERAGE, mesmo que, de outra forma, fossem permitidos pelas regras de análise relevantes.
O C3R foi projetado para proteger dados em células individuais de uma tabela. Usando a configuração padrão do C3R, os dados subjacentes que um cliente disponibiliza para terceiros por meio de uma colaboração permanecem criptografados enquanto o conteúdo está em uso no AWS Clean Rooms. O C3R usa criptografia AES-GCM padrão da indústria para todos sealed colunas e uma função pseudoaleatória padrão do setor, conhecida como Código de Autenticação de Mensagens Baseado em Hash (HMAC), para proteção fingerprint colunas.
Embora o C3R criptografe os dados em suas tabelas, as seguintes informações ainda podem ser inferidas:
+ Informações sobre as tabelas em si, incluindo o número de colunas, os nomes das colunas e o número de linhas na tabela.
+ Como acontece com a maioria das formas padrão de criptografia, o C3R não tenta ocultar o tamanho dos valores criptografados. O C3R oferece a capacidade de preencher valores criptografados para ocultar o tamanho exato dos textos transparentes. No entanto, um limite superior no comprimento dos textos não criptografados em cada coluna ainda pode ser revelado para outra pessoa.
+ Informações em nível de log, como quando uma linha específica foi adicionada a uma tabela C3R criptografada.
Para obter mais informações sobre o C3R, consulte os tópicos a seguir.
**Topics**
+ [Considerações ao usar a computação criptográfica para o Clean Rooms](crypto-computing-considerations.md)
+ [Tipos de arquivos e dados suportados na computação criptográfica para o Clean Rooms](crypto-computing-file-types.md)
+ [Nomes de colunas em computação criptográfica para o Clean Rooms](crypto-computing-column-names.md)
+ [Tipos de colunas em computação criptográfica para o Clean Rooms](crypto-computing-column-types.md)
+ [Parâmetros de computação criptográfica](crypto-computing-parameters.md)
+ [Sinalizadores opcionais em computação criptográfica para o Clean Rooms](crypto-computing-optional-flags.md)
+ [Consultas com computação criptográfica para o Clean Rooms](crypto-computing-queries.md)
+ [Diretrizes para o cliente de criptografia C3R](crypto-computing-guidelines.md)
# 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).
# Tipos de arquivos e dados suportados na computação criptográfica para o Clean Rooms
O cliente de criptografia C3R reconhece os seguintes tipos de arquivo:
+ Arquivos CSV
+ arquivos Parquet
Você pode usar o sinalizador `--fileFormat` no cliente de criptografia C3R para especificar explicitamente um formato de arquivo. Quando especificado explicitamente, o formato do arquivo não é determinado pela extensão do arquivo.
**Topics**
+ [Arquivos CSV](#csv-file-type)
+ [arquivos Parquet](#parquet-file-type)
+ [Criptografar valores que não sejam de string](#encrypt-non-string-values)
## Arquivos CSV
Presume-se que um arquivo com extensão.csv esteja no formato CSV e contenha texto codificado em UTF-8. O cliente de criptografia C3R trata todos os valores como cadeias de caracteres.
### Propriedades compatíveis em arquivos.csv
O cliente de criptografia C3R exige que os arquivos.csv tenham as seguintes propriedades:
+ Pode ou não conter uma linha de cabeçalho inicial que nomeie cada coluna de forma exclusiva.
+ Delimitado por vírgula. (Atualmente, não há suporte para delimitadores personalizados.)
+ Texto codificado em UTF-8.
#### Corte de espaço em branco a partir de entradas.csv
Os espaços em branco à esquerda e à direita são cortados das entradas.csv.
#### Codificação personalizada NULL para um arquivo.csv
Um arquivo.csv pode usar codificação personalizada NULL.
Com o cliente de criptografia C3R, você pode especificar codificações personalizadas para entradas NULL nos dados de entrada usando o sinalizador `--csvInputNULLValue=`. O cliente de criptografia C3R pode usar codificações personalizadas no arquivo de saída gerado para entradas NULL usando o sinalizador `--csvOutputNULLValue=`.
**nota**
Uma entrada NULL é considerada *sem* conteúdo, especificamente no contexto de um formato tabular mais rico, como uma tabela SQL. Embora o domínio.csv não suporte explicitamente essa caracterização por motivos históricos, é uma convenção comum considerar uma entrada vazia que contém apenas espaço em branco NULL. Portanto, esse é o comportamento padrão do cliente de criptografia C3R e pode ser personalizado conforme necessário.
### Como as entradas.csv são interpretadas pelo C3R
A tabela a seguir fornece exemplos de como as entradas.csv são organizadas (cleartext a cleartext para maior clareza) com base nos valores (se houver) fornecidos para os sinalizadores `--csvInputNULLValue=` e `--csvOutputNULLValue=`. Os espaços em branco à esquerda e à direita fora das aspas são cortados antes que o C3R interprete o significado de qualquer valor.
| `` | `` | Entrada | Saída |
| --- |--- |--- |--- |
| Nenhum | Nenhum | ,AnyProduct, | ,AnyProduct, |
| Nenhum | Nenhum | , AnyProduct , | ,AnyProduct, |
| Nenhum | Nenhum | ,"AnyProduct", | ,AnyProduct, |
| Nenhum | Nenhum | , "AnyProduct" , | ,AnyProduct, |
| Nenhum | Nenhum | ,, | ,, |
| Nenhum | Nenhum | , , | ,, |
| Nenhum | Nenhum | ,"", | ,, |
| Nenhum | Nenhum | ," ", | ," ", |
| Nenhum | Nenhum | , " " , | ," ", |
| "AnyProduct" | "NULL" | ,AnyProduct, | ,NULL, |
| "AnyProduct" | "NULL" | , AnyProduct , | ,NULL, |
| "AnyProduct" | "NULL" | ,"AnyProduct", | ,NULL, |
| "AnyProduct" | "NULL" | , "AnyProduct" , | ,NULL, |
| Nenhum | "NULL" | ,, | ,NULL, |
| Nenhum | "NULL" | , , | ,NULL, |
| Nenhum | "NULL" | ,"", | ,NULL, |
| Nenhum | "NULL" | ," ", | ," ", |
| Nenhum | "NULL" | , " " , | ," ", |
| "" | "NULL" | ,, | ,NULL, |
| "" | "NULL" | , , | ,NULL, |
| "" | "NULL" | ,"", | ,"", |
| "" | "NULL" | ," ", | ," ", |
| "" | "NULL" | , " " , | ," ", |
| "\$1"\$1"" | "NULL" | ,, | ,, |
| "\$1"\$1"" | "NULL" | , , | ,, |
| "\$1"\$1"" | "NULL" | ,"", | ,NULL, |
| "\$1"\$1"" | "NULL" | ," ", | ," ", |
| "\$1"\$1"" | "NULL" | , " " , | ," ", |
### Arquivo CSV sem cabeçalhos
O arquivo.csv de origem não precisa ter cabeçalhos na primeira linha que nomeiem cada coluna de forma exclusiva. No entanto, um arquivo.csv sem uma linha de cabeçalho requer um esquema de criptografia posicional. O esquema de criptografia posicional é necessário em vez do esquema mapeado típico usado para arquivos.csv com uma linha de cabeçalho e arquivos Parquet.
Um esquema de criptografia posicional especifica as colunas de saída por posição em vez de por nome. Um esquema de criptografia mapeado mapeia os nomes das colunas de origem para os nomes das colunas de destino. Para obter mais informações, incluindo uma discussão detalhada e exemplos dos dois formatos de esquema, consulte [Esquemas de tabelas mapeadas e posicionais](create-schema.md#mapped-and-positional-schemas).
## arquivos Parquet
Presume-se que um arquivo com uma extensão .parquet esteja no formato Apache Parquet.
### Tipos de dados compatíveis Parquet
O cliente de criptografia C3R pode processar qualquer dado não complexo (ou seja, tipo primitivo) em um arquivo Parquet que represente um tipo de dados suportado pelo AWS Clean Rooms.
No entanto, somente colunas de string podem ser usadas para colunas sealed.
Os seguintes tipos de dados Parquet são compatíveis:
+ Tipo primitivo `Binary` com as seguintes anotações lógicas:
+ Nenhum se `--parquetBinaryAsString` estiver definido (tipo de dados `STRING`)
+ `Decimal(scale, precision)` (tipo de dados`DECIMAL`)
+ `String` (tipo de dados `STRING`)
+ Tipo de dados primitivo `Boolean` sem anotação lógica (tipo de dados `BOOLEAN`)
+ Tipo de dados primitivo `Double` sem anotação lógica (tipo de dados `DOUBLE`)
+ Tipo de dados primitivo `Fixed_Len_Binary_Array` com anotação lógica `Decimal(scale, precision)` (tipo de dados `DECIMAL`)
+ Tipo de dados primitivo `Float` sem anotação lógica (tipo de dados `FLOAT`)
+ Tipo de dados primitivo `Int32` com as seguintes anotações lógicas:
+ Nenhum (tipo de dados `INT`)
+ `Date` (tipo de dados `DATE`)
+ `Decimal(scale, precision)` (tipo de dados `DECIMAL`)
+ `Int(16, true)` (tipo de dados `SMALLINT`)
+ `Int(32, true)` (tipo de dados `INT`)
+ Tipo de dados primitivo `Int64` com as seguintes anotações lógicas:
+ Nenhum (tipo de dados `BIGINT`)
+ `Decimal(scale, precision)` (tipo de dados `DECIMAL`)
+ `Int(64, true)` (tipo de dados `BIGINT`)
+ `Timestamp(isUTCAdjusted, TimeUnit.MILLIS)` (tipo de dados `TIMESTAMP`)
+ `Timestamp(isUTCAdjusted, TimeUnit.MICROS)` (tipo de dados `TIMESTAMP`)
+ `Timestamp(isUTCAdjusted, TimeUnit.NANOS)` (tipo de dados `TIMESTAMP`)
## Criptografar valores que não sejam de string
Atualmente, somente valores de string são compatíveis com as colunas sealed.
Para arquivos.csv, o cliente de criptografia C3R trata todos os valores como texto codificado em UTF-8 e não faz nenhuma tentativa de interpretá-los de forma diferente antes da criptografia.
Para colunas de impressão digital, os tipos são agrupados em classes de equivalência. Uma classe de equivalência é um conjunto de tipos de dados que podem ser comparados de forma inequívoca em termos de igualdade por meio de um tipo de dados representativo.
As classes de equivalência permitem que impressões digitais idênticas sejam atribuídas ao mesmo valor semântico, independentemente da representação original. No entanto, o mesmo valor em duas classes de equivalência não resultará na mesma coluna de impressão digital.
Por exemplo, o valor `INTEGRAL` `42` receberá a mesma impressão digital, independentemente de ser originalmente um `SMALLINT`, `INT` ou `BIGINT`. Além disso, o valor `INTEGRAL` `0` nunca corresponderá ao valor `BOOLEAN` `FALSE` (que é representado pelo valor `0`).
As seguintes classes de equivalência e AWS Clean Rooms os tipos de dados correspondentes são suportados por colunas de impressão digital:
| Classe de equivalência | Tipos de dados AWS Clean Rooms compatíveis |
| --- | --- |
| BOOLEAN | BOOLEAN |
| DATE | DATE |
| INTEGRAL | BIGINT, INT, SMALLINT |
| STRING | CHAR, STRING, VARCHAR |
# Nomes de colunas em computação criptográfica para o Clean Rooms
Por padrão, os nomes das colunas são importantes na Computação Criptográfica para o Clean Rooms.
Se o valor do parâmetro **Permitir JOIN de colunas com nomes diferentes** for **falso**, os nomes das colunas serão usados durante a criptografia das colunas fingerprint. Por esse motivo, por padrão, os colaboradores devem se coordenar com antecedência e usar os mesmos nomes de colunas de destino para dados que usarão instruções JOIN em consultas. Por padrão, colunas criptografadas para JOIN com nomes diferentes não são bem-sucedidas JOIN em nenhum valor.
Se o valor do parâmetro **Permitir JOIN de colunas com nomes diferentes** for **verdadeiro**, as instruções JOIN em colunas criptografadas como colunas fingerprint serão bem-sucedidas. Criptografar dados com esse parâmetro pode permitir alguma inferência dos valores cleartext. Por exemplo, se uma linha tiver o mesmo valor de Código de Autenticação de Mensagens por Hash (HMAC) na coluna `City` e na coluna `State`, o valor poderá ser `New York`.
## Normalização dos nomes dos cabeçalhos das colunas
Os nomes dos cabeçalhos das colunas são normalizados pelo cliente de criptografia C3R. Qualquer espaço em branco à esquerda e à direita é removido e o nome da coluna é colocado em minúsculas para a saída transformada.
A normalização é aplicada antes de todos os outros cálculos, cálculos ou outras operações que possam ser afetadas pelos nomes das colunas. O arquivo de saída emitido contém apenas os nomes normalizados.
# Tipos de colunas em computação criptográfica para o Clean Rooms
Este tópico fornece informações sobre os tipos de coluna na Computação Criptográfica para o Clean Rooms.
**Topics**
+ [colunas Fingerprint](#fingerprint-columns)
+ [Colunas seladas](#sealed-columns)
+ [colunas Cleartext](#cleartext-columns)
## colunas Fingerprint
*Colunas Fingerprint* são colunas protegidas criptograficamente para uso em instruções de JOIN.
Os dados das colunas fingerprint não podem ser descriptografados. Somente dados de colunas seladas podem ser descriptografados.
As colunas Fingerprint só devem ser usadas nas seguintes cláusulas e funções SQL:
+ JOIN (INNER, OUTER, LEFT, RIGHT, or FULL) em relação a outras colunas fingerprint:
+ Se o valor do parâmetro `allowJoinsOnColumnsWithDifferentNames` for definido como `false`, as duas colunas fingerprint do JOIN também deverão ter o mesmo nome.
+ `SELECT COUNT()`
+ `SELECT COUNT(DISTINCT )`
+ `GROUP BY` (Use somente se a colaboração tiver definido o valor do parâmetro `preserveNulls` como `true`.)
As consultas que violam essas restrições podem gerar resultados incorretos.
## Colunas seladas
*Colunas seladas* são colunas protegidas criptograficamente para uso em instruções de SELECT.
As colunas seladas devem ser usadas somente nas seguintes cláusulas e funções SQL:
+ `SELECT`
+ `SELECT ... AS`
+ `SELECT COUNT()`
**nota**
Não há suporte ao `SELECT COUNT(DISTINCT )`.
As consultas que violam essas restrições podem gerar resultados incorretos.
### Preenchimento de dados para uma coluna sealed antes da criptografia
Quando você especifica que uma coluna deve ser uma coluna sealed, o C3R pergunta que tipo de *preenchimento* escolher. Preencher os dados antes da criptografia é opcional. Sem preenchimento (um tipo de bloco de `none`), o comprimento dos dados criptografados indica o tamanho do cleartext. Em algumas circunstâncias, o tamanho do cleartext pode expor o texto sem formatação. Com o preenchimento (um tipo de teclado de `fixed` ou `max`), todos os valores são primeiro preenchidos em um tamanho comum e depois criptografados. Com o preenchimento, o tamanho dos dados criptografados não fornece informações sobre o tamanho original de cleartext, além de fornecer um limite superior para seu tamanho.
Se quiser preenchimento para uma coluna e o comprimento máximo em bytes dos dados nessa coluna for conhecido, use o preenchimento de `fixed`. Use um valor `length` que seja pelo menos tão grande quanto o comprimento em bytes do valor mais longo nessa coluna.
**nota**
Ocorre um erro e a criptografia falha se um valor for maior que o fornecido `length`.
Se quiser preenchimento para uma coluna e a extensão máxima em bytes dos dados nessa coluna não for conhecido, use o preenchimento `max`. Esse modo de preenchimento preenche todos os dados até o tamanho do valor mais longo, mais bytes adicionais `length`.
**nota**
Talvez você queira criptografar dados em lotes ou atualizar suas tabelas com novos dados periodicamente. Lembre-se de que o preenchimento de `max` preencherá as entradas até o comprimento (mais de `length` bytes) da entrada de texto simples mais longa em um determinado lote. Isso significa que o tamanho do texto cifrado pode variar de lote para lote. Portanto, se você souber o comprimento máximo de bytes de uma coluna, deverá usar `fixed` em vez de `max`.
## colunas Cleartext
As *colunas Cleartext* são protegidas criptograficamente para uso em declarações JOIN ou SELECT.
As colunas Cleartext podem ser usadas em qualquer parte da consulta SQL.
# Parâmetros de computação criptográfica
[Os parâmetros de computação criptográfica estão disponíveis para colaborações usando a Computação Criptográfica para o Clean Rooms (C3R) ao criar uma colaboração.](create-collaboration.md) Você pode criar uma colaboração usando o AWS Clean Rooms console ou a operação `CreateCollaboration` da API. No console, você pode definir valores para os parâmetros em Parâmetros de **computação criptográfica** depois de ativar a opção **Suporte à computação criptográfica**. Para obter mais informações, consulte os tópicos a seguir.
**Topics**
+ [Parâmetro Permitir colunas cleartext](#parameter-allowcleartext)
+ [Parâmetro Permitir duplicatas](#parameter-allowduplicates)
+ [Parâmetro de permissão JOIN de colunas com nomes diferentes](#parameter-allowjoin)
+ [Parâmetro de preservação de valores NULL](#parameter-preservenulls)
## Parâmetro Permitir colunas cleartext
No console, você pode definir o parâmetro **Permitir colunas cleartext** ao [criar uma colaboração](create-collaboration.md) para especificar se os dados cleartext são permitidos em uma tabela com dados criptografados.
A tabela a seguir descreve os valores do parâmetro **Permitir colunas cleartext**.
| Valor do parâmetro | Description |
| --- | --- |
| Não | As colunas Cleartext não são permitidas na tabela criptografada. Todos os dados são protegidos criptograficamente. |
| Sim | As colunas Cleartext são permitidas na tabela criptografada. As colunas Cleartext não são protegidas criptograficamente e são incluídas como cleartext. Você deve observar o que os dados cleartext de suas linhas podem revelar sobre os outros dados na tabela. Para executar SUM ou AVG em colunas específicas, as colunas devem estar dentro de cleartext. |
Usando a operação da API `CreateCollaboration`, para o parâmetro `dataEncryptionMetadata`, você pode definir o valor `allowCleartext` como `true` ou `false`. Para obter mais informações sobre operações de API, consulte a [Referência de API do AWS Clean Rooms](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html).
As colunas Cleartext correspondem às colunas que são classificadas como cleartext no esquema específico da tabela. Os dados nessas colunas não são criptografados e podem ser usados de qualquer forma. Cleartextas colunas podem ser úteis se os dados não and/or forem confidenciais, se for necessária mais flexibilidade do que uma sealed coluna ou fingerprint coluna criptografada permite.
## Parâmetro Permitir duplicatas
No console, você pode definir o parâmetro **Permitir duplicatas** ao [criar uma colaboração](create-collaboration.md) para especificar se as colunas criptografadas para consultas JOIN podem conter valores não duplicados NULL.
**Importante**
Os parâmetros **Permitir duplicatas**, [**Permitir JOIN de colunas com nomes diferentes**](#parameter-allowjoin) e [**Preservar valores NULL**](#parameter-preservenulls) têm efeitos separados, mas relacionados.
A tabela a seguir descreve os valores do parâmetro **Permitir duplicatas**.
| Valor do parâmetro | Description |
| --- | --- |
| Não | Valores repetidos não são permitidos em uma coluna fingerprint. Todos os valores em uma única coluna fingerprint devem ser exclusivos. |
| Sim | Valores repetidos são permitidos em uma coluna fingerprint. Se você precisar unir colunas com valores repetidos, defina esse valor como **Sim**. Quando definido como **Sim**, os padrões de frequência que aparecem nas colunas fingerprint da tabela C3R ou nos resultados podem implicar em algumas informações adicionais sobre a estrutura dos dados cleartext. |
Usando a operação da API `CreateCollaboration`, para o parâmetro `dataEncryptionMetadata`, você pode definir o valor `allowDuplicates` como `true` ou `false`. Para obter mais informações sobre operações de API, consulte a [Referência de API do AWS Clean Rooms](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html).
Por padrão, se dados criptografados precisarem ser usados em consultas JOIN, o cliente de criptografia C3R exigirá que essas colunas não tenham valores duplicados. Esse requisito é um esforço para aumentar a proteção de dados. Esse comportamento pode ajudar a garantir que padrões repetidos nos dados não sejam observáveis. No entanto, se quiser trabalhar com dados criptografados em consultas JOIN e não estiver preocupado com valores duplicados, o parâmetro **Permitir duplicatas** pode desativar essa verificação conservadora.
## Parâmetro de permissão JOIN de colunas com nomes diferentes
No console, você pode definir o parâmetro **Permitir JOIN de colunas com nomes diferentes** ao [criar uma colaboração](create-collaboration.md) para especificar se as instruções JOIN entre colunas com nomes diferentes são suportadas.
Para obter mais informações, consulte [Normalização dos nomes dos cabeçalhos das colunas](crypto-computing-column-names.md#column-header-names-normalization).
A tabela a seguir descreve os valores do parâmetro **Permitir JOIN de colunas com nomes diferentes**.
| Valor do parâmetro | Description |
| --- | --- |
| Não | Não há suporte para junções de colunas fingerprint com nomes diferentes. Declarações JOINsó fornecem resultados precisos em colunas que têm o mesmo nome. O valor **Não** fornece maior segurança das informações, mas exige que os participantes da colaboração concordem previamente com os nomes das colunas. Se duas colunas tiverem nomes diferentes quando criptografadas como colunas fingerprint e a opção **Permitir JOIN de colunas com nomes diferentes** estiver definida como **Não**, as instruções JOIN nessas colunas não produzirão resultados. Isso ocorre porque nenhum valor pós-criptografia é compartilhado entre eles. |
| Sim | Há suporte para junções de colunas com nomes diferentes fingerprint. Para maior flexibilidade, os usuários podem definir esse valor como **Sim**, o que permite instruções JOIN em colunas, independentemente do nome da coluna. Se definido como **Sim**, o cliente de criptografia C3R não considera o nome da coluna ao proteger as colunas fingerprint. Como resultado, valores comuns em diferentes colunas fingerprint são observáveis na tabela C3R. Por exemplo, se uma linha tiver o mesmo valor JOIN criptografado em uma coluna `City` e em uma coluna `State`, pode ser razoável inferir que esse valor é `New York`. |
Usando a operação da API `CreateCollaboration`, para o parâmetro `dataEncryptionMetadata`, você pode definir o valor `allowJoinsOnColumnsWithDifferentNames` como `true` ou `false`. Para obter mais informações sobre operações de API, consulte a [Referência de API do AWS Clean Rooms](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html).
Por padrão, a criptografia da coluna fingerprint `targetHeader` é afetada pela configuração dessa coluna [Etapa 4: gerar um esquema de criptografia para um arquivo tabular](gen-encryption-schema-csv.md). Portanto, o mesmo valor cleartext tem representações criptografadas diferentes em cada coluna fingerprint diferente para a qual é criptografado.
Esse parâmetro pode ser útil para impedir a inferência de valores cleartext em alguns casos. Por exemplo, ver o mesmo valor criptografado em colunas fingerprint `City` e `State` pode ser usado para inferir razoavelmente que o valor é `New York`. No entanto, o uso desse parâmetro requer coordenação adicional com antecedência, para que todas as colunas a serem unidas nas consultas tenham nomes compartilhados.
Você pode usar o parâmetro **Permitir JOIN de colunas com nomes diferentes** para afrouxar essa restrição. Quando o valor do parâmetro é definido como `Yes`, ele permite que qualquer coluna criptografada JOIN seja usada em conjunto, independentemente do nome.
## Parâmetro de preservação de valores NULL
No console, você pode definir o parâmetro **Preservar valores NULL** ao [criar uma colaboração](create-collaboration.md) para indicar que não há nenhum valor presente para essa coluna.
A tabela a seguir descreve os valores do parâmetro **Preservar valores NULL**.
| Valor do parâmetro | Description |
| --- | --- |
| Não | Os valores NULL não são preservados. Os valores NULL não aparecem como NULL em uma tabela criptografada. Os valores NULL aparecem como valores aleatórios exclusivos em uma tabela C3R. |
| Sim | Os valores NULL são preservados. Os valores NULL aparecem como NULL em uma tabela criptografada. Se você precisar de semântica de valores NULL SQL, você pode definir esse valor como Sim. Como resultado, as entradas NULL aparecem como NULL na tabela C3R, independentemente de a coluna estar criptografada e independentemente da configuração do parâmetro para Permitir duplicatas. |
Usando a operação da API `CreateCollaboration`, para o parâmetro `dataEncryptionMetadata`, você pode definir o valor `preserveNulls` como `true` ou `false`. Para obter mais informações sobre operações de API, consulte a [Referência de API do AWS Clean Rooms](https://docs.aws.amazon.com/clean-rooms/latest/apireference/Welcome.html).
Quando o parâmetro **Preservar valores NULL** estiver definido como **Não** para a colaboração:
1. As entradas NULL nas colunas `cleartext` permanecem inalteradas.
1. As entradas NULL em colunas `fingerprint` criptografadas são criptografadas como valores aleatórios para ocultar seu conteúdo. A união em uma coluna criptografada com entradas NULL na coluna cleartext não produz nenhuma correspondência para nenhuma das entradas NULL. Nenhuma combinação é feita porque cada uma recebe seu próprio conteúdo aleatório exclusivo.
1. As entradas NULL em colunas `sealed` criptografadas são criptografadas.
Quando o valor do parâmetro **Preservar valores NULL** é definido como **Sim** para a colaboração, as entradas NULL de todas as colunas permanecem inalteradas, independentemente de a coluna NULL estar criptografada.
O parâmetro **Preservar valores NULL** é útil em cenários como enriquecimento de dados, nos quais você deseja compartilhar a falta de informações expressas como NULL. O parâmetro **Preservar valores NULL** também é útil no formato fingerprint HMAC se você tiver valores NULL na coluna que deseja JOIN ou GROUP BY.
Se o valor dos parâmetros **Permitir duplicatas** e **Preservar valores NULL** estiver definido como **Não**, ter mais de uma entrada NULL em uma coluna fingerprint produzirá um erro e interromperá a criptografia. Se o valor de um dos parâmetros for definido como **Sim**, esse erro não ocorrerá.
# Sinalizadores opcionais em computação criptográfica para o Clean Rooms
As seções a seguir descrevem os sinalizadores opcionais que você pode definir ao [criptografar dados](encrypt-data.md) usando o cliente de criptografia C3R para personalização e teste de arquivos tabulares.
**Topics**
+ [sinalizador `--csvInputNULLValue`](#optional-flags-CSVinputNullValue)
+ [sinalizador `--csvOutputNULLValue`](#optional-flags-CSVoutputNullValue)
+ [sinalizador `--enableStackTraces`](#optional-flags-enablestacktraces)
+ [sinalizador `--dryRun`](#optional-flags-dry-run)
+ [sinalizador `--tempDir`](#optional-flags-working-dir)
## sinalizador `--csvInputNULLValue`
Você pode usar o sinalizador `--csvInputNULLValue` para especificar codificações personalizadas para entradas NULL nos dados de entrada ao [criptografar dados](encrypt-data.md) usando o cliente de criptografia C3R.
A tabela a seguir resume o uso e os parâmetros desse sinalizador.
| Usage | Parâmetros |
| --- | --- |
| Opcional. Os usuários podem especificar codificações personalizadas para entradas NULL nos dados de entrada. | Codificação de valores NULL especificada pelo usuário no arquivo CSV de entrada |
Uma entrada NULL é uma entrada considerada sem conteúdo, especificamente no contexto de um formato tabular mais rico, como uma tabela SQL. Embora o domínio.csv não suporte explicitamente essa caracterização por motivos históricos, é uma convenção comum considerar uma entrada vazia contendo apenas espaço em branco NULL. Portanto, esse é o comportamento padrão do cliente de criptografia C3R e pode ser personalizado conforme necessário.
## sinalizador `--csvOutputNULLValue`
Você pode usar o sinalizador `--csvOutputNULLValue` para especificar codificações personalizadas para entradas NULL nos dados de saída ao [criptografar dados](encrypt-data.md) usando o cliente de criptografia C3R.
A tabela a seguir resume o uso e os parâmetros desse sinalizador.
| Usage | Parâmetros |
| --- | --- |
| Opcional. Os usuários podem especificar codificações personalizadas no arquivo de saída gerado para as entradas NULL. | Codificação de valores NULL especificada pelo usuário no arquivo CSV de saída |
Uma entrada NULL é uma entrada considerada sem conteúdo, especificamente no contexto de um formato tabular mais rico, como uma tabela SQL. Embora o domínio.csv não suporte explicitamente essa caracterização por motivos históricos, é uma convenção comum considerar uma entrada vazia contendo apenas espaço em branco NULL. Portanto, esse é o comportamento padrão do cliente de criptografia C3R e pode ser personalizado conforme necessário.
## sinalizador `--enableStackTraces`
Ao [criptografar dados](encrypt-data.md) usando o cliente de criptografia C3R, use o sinalizador `--enableStackTraces` para fornecer informações contextuais adicionais para relatórios de erros quando o C3R encontrar um erro.
AWS não coleta erros. Se você encontrar um erro, use o rastreamento de pilha para solucionar o erro sozinho ou envie o rastreamento de pilha para Suporte obter ajuda.
A tabela a seguir resume o uso e os parâmetros desse sinalizador.
| Usage | Parâmetros |
| --- | --- |
| Opcional. Usado para fornecer informações contextuais adicionais para relatórios de erros quando o cliente de criptografia C3R encontra um erro. | Nenhum |
## sinalizador `--dryRun`
Os comandos [criptografar](encrypt-data.md) e [descriptografar o cliente de criptografia](decrypt-data.md) C3R incluem um sinalizador opcional `--dryRun`. O sinalizador pega todos os argumentos fornecidos pelo usuário e verifica sua validade e consistência.
Você pode usar o sinalizador `--dryRun` para verificar se o arquivo do esquema é válido e consistente com o arquivo de entrada correspondente.
A tabela a seguir resume o uso e os parâmetros desse sinalizador.
| Usage | Parâmetros |
| --- | --- |
| Opcional. Faz com que o cliente de criptografia C3R analise os parâmetros e verifique os arquivos, mas não realiza criptografia nem descriptografia. | Nenhum |
## sinalizador `--tempDir`
Talvez você queira usar um diretório temporário porque, às vezes, arquivos criptografados podem ser maiores do que arquivos não criptografados, dependendo de suas configurações. Os conjuntos de dados também devem ser criptografados por colaboração para funcionarem corretamente.
Ao [criptografar dados](encrypt-data.md) usando o C3R, use o sinalizador `--tempDir` para especificar o local em que os arquivos temporários podem ser criados durante o processamento da entrada.
A tabela a seguir resume o uso e os parâmetros desse sinalizador.
| Usage | Parâmetros |
| --- | --- |
| Os usuários podem especificar o local onde os arquivos temporários podem ser criados durante o processamento da entrada. | O padrão é o diretório temporário do sistema. |
# Consultas com computação criptográfica para o Clean Rooms
Este tópico fornece informações sobre como escrever consultas que usam tabelas de dados que foram criptografadas usando Computação Criptográfica para o Clean Rooms.
**Topics**
+ [Consultas que se ramificam em NULL](#queries-branch-on-null)
+ [Mapeamento de uma coluna de origem para várias colunas de destino](#queries-mapping)
+ [Usar os mesmos dados para ambas as consultas JOIN e SELECT](#queries-using-same-data)
## Consultas que se ramificam em NULL
Ter uma ramificação de consulta em uma instrução NULL significa usar uma sintaxe como `IF x IS NULL THEN 0 ELSE 1`.
As consultas sempre podem se ramificar nas instruções NULL em colunas cleartext.
As consultas podem se ramificar em nas instruções NULL em colunas sealed e colunas fingerprint somente quando o valor do parâmetro **Preservar valores NULL** (`preserveNulls`) estiver definido como `true`.
As consultas que violam essas restrições podem gerar resultados incorretos.
## Mapeamento de uma coluna de origem para várias colunas de destino
Uma coluna de origem pode ser mapeada para várias colunas de destino. Por exemplo, talvez você queira usar JOIN e SELECT em uma coluna.
Para obter mais informações, consulte [Usar os mesmos dados para ambas as consultas JOIN e SELECT](#queries-using-same-data).
## Usar os mesmos dados para ambas as consultas JOIN e SELECT
Se os dados em uma coluna não forem confidenciais, eles poderão aparecer em uma coluna de destino cleartext, o que permite que sejam usados para qualquer finalidade.
Se os dados em uma coluna forem confidenciais e precisarem ser usados para consultas SELECT, mapeie essa coluna de origem para duas colunas de destino no arquivo de saída JOIN. Uma coluna é criptografada com `type` como coluna fingerprint e uma coluna é criptografada com `type` como coluna selada. A geração do esquema interativo do cliente de criptografia C3R sugere sufixos de cabeçalho de `_fingerprint` e `_sealed`. Esses sufixos de cabeçalho podem ser uma convenção útil para diferenciar essas colunas rapidamente.
# 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 Clean Rooms](crypto-computing.md).
**Topics**
+ [Implicações de desempenho para tipos de coluna](#performance-implications)
+ [Solução de problemas de aumentos imprevistos no tamanho do texto cifrado](#troubleshooting-ciphertext-size)
## 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.
**Topics**
+ [colunas Cleartext](#cleartext-columns)
+ [colunas Fingerprint](#guidelines-fingerprint-columns)
+ [colunas Sealed](#guidelines-sealed-columns)
### 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.
**Topics**
+ [Sobrecarga básica para colunas fingerprint](#fingerprint-columns-base-overhead)
+ [Configurações de colaboração para colunas fingerprint](#fingerprint-columns-collab-settings)
+ [Dados de exemplo para uma coluna fingerprint](#collab-set-sample-data)
+ [Colunas fingerprint de solução de problemas](#fingerprint-columns-troubleshooting)
#### 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)` *
![\[A sobrecarga básica de 52 bytes para uma coluna fingerprint.\]](http://docs.aws.amazon.com/pt_br/clean-rooms/latest/userguide/images/base-overhead-fingerprint.PNG)
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.
**Exemplo 1**
| | |
| --- |--- |
| Input | null |
| preserveNulls | TRUE |
| Output | null |
| Deterministic | Yes |
| Bytes de entrada | 0 |
| Bytes de saída | 0 |
**Exemplo 2**
| | |
| --- |--- |
| Input | null |
| preserveNulls | FALSE |
| Output | 01:hmac:3lkFjthvV3IUu6mMvFc1a\$1XAHwgw/ElmOq4p3Yg25kk= |
| Deterministic | No |
| Bytes de entrada | 0 |
| Bytes de saída | 52 |
**Exemplo 3**
| | |
| --- |--- |
| Input | empty string |
| preserveNulls | - |
| Output | 01:hmac:oKTgi3Gba\$1eUb3JteSz2EMgXUkF1WgM77UP0Ydw5kPQ= |
| Deterministic | Yes |
| Bytes de entrada | 0 |
| Bytes de saída | 52 |
**Exemplo 4**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyz |
| preserveNulls | - |
| Output | 01:hmac:kU/IqwG7FMmzzshr0B9scomE0UJUEE7j9keTctplGww= |
| Deterministic | Yes |
| Bytes de entrada | 26 |
| Bytes de saída | 52 |
**Exemplo 5**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 |
| preserveNulls | - |
| Output | 01:hmac:ks3htnQbw2vdhCRFF6JNzW5LMndJaHG57uvE26mBtSs= |
| Deterministic | Yes |
| Bytes de entrada | 62 |
| Bytes de saída | 52 |
#### 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](crypto-computing-parameters.md) 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.
**Topics**
+ [Sobrecarga básica para colunas sealed](#sealed-columns-base-overhead)
+ [Configurações de colaboração para colunas sealed](#sealed-columns-collab-settings)
+ [Colunas sealed de configurações do esquema: tipos de preenchimento](#sealed-collab-pad-type)
+ [Dados de exemplo para uma coluna sealed](#sealed-collab-sample-data)
+ [Colunas sealed de solução de problemas](#troubleshooting-sealed-columns)
#### 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)` *
![\[A sobrecarga básica de 91 bytes para uma coluna sealed.\]](http://docs.aws.amazon.com/pt_br/clean-rooms/latest/userguide/images/base-overhead-sealed.PNG)
#### 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 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.
#### Colunas sealed de configurações do esquema: tipos de preenchimento
**Topics**
+ [Tipo de almofada de `none`](#pad-type-none)
+ [Tipo de almofada de `fixed`](#pad-type-fixed)
+ [Tipo de almofada de `max`](#pad-type-max)
##### 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`
**Topics**
+ [Tipo de preenchimento de `none`](#sealed-pad-type-none)
+ [Tipo de almofada de `fixed` (Exemplo 1)](#sealed-pad-type-fixed)
+ [Tipo de almofada de `fixed` (Exemplo 2)](#sealed-pad-type-fixed-2)
+ [Tipo de almofada de `max` (Exemplo 1)](#sealed-pad-type-max)
+ [Tipo de almofada de `max` (Exemplo 2)](#sealed-pad-type-max-2)
##### Tipo de preenchimento de `none`
**Exemplo 1**
| | |
| --- |--- |
| Input | null |
| preserveNulls | TRUE |
| Output | null |
| Deterministic | Yes |
| Bytes de entrada | 0 |
| Bytes de saída | 0 |
**Exemplo 2**
| | |
| --- |--- |
| Input | null |
| preserveNulls | FALSE |
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSPbNIJfG3iXmu6cbCUrizuV |
| Deterministic | No |
| Bytes de entrada | 0 |
| Bytes de saída | 91 |
**Exemplo 3**
| | |
| --- |--- |
| Input | empty string |
| preserveNulls | - |
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSPEM6qR8DWC2PB2GMlX41YK |
| Deterministic | No |
| Bytes de entrada | 0 |
| Bytes de saída | 91 |
**Exemplo 4**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyz |
| preserveNulls | - |
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9sGL5VLDQeHzh6DmPpyWNuI= |
| Deterministic | No |
| Bytes de entrada | 26 |
| Bytes de saída | 127 |
**Exemplo 5**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 |
| preserveNulls | - |
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnnohrHIGSX54ua\$11/JfcVjc= |
| Deterministic | No |
| Bytes de entrada | 62 |
| Bytes de saída | 175 |
##### Tipo de almofada de `fixed` (Exemplo 1)
Neste exemplo, `pad_length` é 62 e a maior entrada é 62 bytes.
**Exemplo 1**
| | |
| --- |--- |
| Input | null |
| preserveNulls | TRUE |
| Output | null |
| Deterministic | Yes |
| Bytes de entrada | 0 |
| Bytes de saída | 0 |
**Exemplo 2**
| | |
| --- |--- |
| Input | null |
| preserveNulls | FALSE |
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoNpATs0GzbnLkor4L\$1/aSuA= |
| Deterministic | No |
| Bytes de entrada | 0 |
| Bytes de saída | 175 |
**Exemplo 3**
| | |
| --- |--- |
| Input | empty string |
| preserveNulls | - |
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoLB53l07VZpA6OwkuXu29CA= |
| Deterministic | No |
| Bytes de entrada | 0 |
| Bytes de saída | 175 |
**Exemplo 4**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyz |
| preserveNulls | - |
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcutBAcO\$1Mb9tuU2KIHH31AWg= |
| Deterministic | No |
| Bytes de entrada | 26 |
| Bytes de saída | 175 |
**Exemplo 5**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 |
| preserveNulls | - |
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnnohrHIGSX54ua\$11/JfcVjc= |
| Deterministic | No |
| Bytes de entrada | 62 |
| Bytes de saída | 175 |
##### Tipo de almofada de `fixed` (Exemplo 2)
Neste exemplo, `pad_length` é 162 e a maior entrada é 62 bytes.
**Exemplo 1**
| | |
| --- |--- |
| Input | null |
| preserveNulls | TRUE |
| Output | null |
| Deterministic | Yes |
| Bytes de entrada | 0 |
| Bytes de saída | 0 |
**Exemplo 2**
| | |
| --- |--- |
| Input | null |
| preserveNulls | FALSE |
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv/xAySX\$1xcntotL703aBTBb |
| Deterministic | No |
| Bytes de entrada | 0 |
| Bytes de saída | 307 |
**Exemplo 3**
| | |
| --- |--- |
| Input | empty string |
| preserveNulls | - |
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv84lVaT9Yd\$16oQx65/\$1gdVT |
| Deterministic | No |
| Bytes de entrada | 0 |
| Bytes de saída | 307 |
**Exemplo 4**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyz |
| preserveNulls | - |
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwtX5Hnl\$1WyfO6ks3QMaRDGSf |
| Deterministic | No |
| Bytes de entrada | 26 |
| Bytes de saída | 307 |
**Exemplo 5**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 |
| preserveNulls | - |
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwjkJXQZOgPdeFX9Yr/8alV5i |
| Deterministic | No |
| Bytes de entrada | 62 |
| Bytes de saída | 307 |
##### Tipo de almofada de `max` (Exemplo 1)
Neste exemplo, `pad_length` é 0 e a maior entrada é 62 bytes.
**Exemplo 1**
| | |
| --- |--- |
| Input | null |
| preserveNulls | TRUE |
| Output | null |
| Deterministic | Yes |
| Bytes de entrada | 0 |
| Bytes de saída | 0 |
**Exemplo 2**
| | |
| --- |--- |
| Input | null |
| preserveNulls | FALSE |
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoNpATs0GzbnLkor4L\$1/aSuA= |
| Deterministic | No |
| Bytes de entrada | 0 |
| Bytes de saída | 175 |
**Exemplo 3**
| | |
| --- |--- |
| Input | empty string |
| preserveNulls | - |
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcoLB53l07VZpA6OwkuXu29CA= |
| Deterministic | No |
| Bytes de entrada | 0 |
| Bytes de saída | 175 |
**Exemplo 4**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyz |
| preserveNulls | - |
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcutBAcO\$1Mb9tuU2KIHH31AWg= |
| Deterministic | No |
| Bytes de entrada | 26 |
| Bytes de saída | 175 |
**Exemplo 5**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 |
| preserveNulls | - |
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnnohrHIGSX54ua\$11/JfcVjc= |
| Deterministic | No |
| Bytes de entrada | 62 |
| Bytes de saída | 175 |
##### Tipo de almofada de `max` (Exemplo 2)
Neste exemplo, `pad_length` é 100 e a maior entrada é 62 bytes.
**Exemplo 1**
| | |
| --- |--- |
| Input | null |
| preserveNulls | TRUE |
| Output | null |
| Deterministic | Yes |
| Bytes de entrada | 0 |
| Bytes de saída | 0 |
**Exemplo 2**
| | |
| --- |--- |
| Input | null |
| preserveNulls | FALSE |
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfssGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv/xAySX\$1xcntotL703aBTBb |
| Deterministic | No |
| Bytes de entrada | 0 |
| Bytes de saída | 307 |
**Exemplo 3**
| | |
| --- |--- |
| Input | empty string |
| preserveNulls | - |
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfstGSNWfMRp7nSb7SMX2s3JKLOhK1\$17r75Tk\$1Mx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwv84lVaT9Yd\$16oQx65/\$1gdVT |
| Deterministic | No |
| Bytes de entrada | 0 |
| Bytes de saída | 307 |
**Exemplo 4**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyz |
| preserveNulls | - |
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6pkx9jy48Fcg1yOPvBqRSZ7oqy1V3UKfYTLEZb/hCz7oaIneVsrcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwtX5Hnl\$1WyfO6ks3QMaRDGSf |
| Deterministic | No |
| Bytes de entrada | 26 |
| Bytes de saída | 307 |
**Exemplo 5**
| | |
| --- |--- |
| Input | abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 |
| preserveNulls | - |
| Output | 01:enc:bm9uY2UwMTIzNDU2Nzg5MG5vbmNlMDEyMzQ1Njc4OTBqfRYZ98t5KU6aWfsteEE1GKEPiRzyh0h7t6OmWMLTWCvO2ckr6plwtH/8tRFnn2rF91bcB9G4\$1n8GiRfJNmqdP4/QOQ3cXb/pbvPcnkB0xbLWD7zNdAqQGR0rXoSESdW0I0vpNoGcBfv4cJbG0A3h1DvtkSSVc2B80OOGppzdDqhrUVN5wFNyn8vgfPMqDaeJk5bn\$18o4WtG/ClipNcjDXvXVtK4vfCohcCA6uwrmwjkJXQZOgPdeFX9Yr/8alV5i |
| Deterministic | No |
| Bytes de entrada | 62 |
| Bytes de saída | 307 |
#### 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 preenchimento`max`?**
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 Clean Rooms](crypto-computing.md) 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.
**Topics**
+ [O aumento de tamanho vem de uma coluna fingerprint?](#size-increase-from-fingerprint)
+ [O aumento de tamanho vem de uma coluna sealed?](#size-increase-from-sealed)
#### 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](#fingerprint-columns-base-overhead) 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 Clean Rooms](crypto-computing.md).
#### 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](#sealed-columns-base-overhead) 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 Clean Rooms](crypto-computing.md).