Criptografia pesquisável - AWS SDK de criptografia de banco de dados

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

Criptografia pesquisável

Nossa biblioteca de criptografia do lado do cliente foi renomeada como SDK de criptografia de banco de dados da AWS. Este guia do desenvolvedor ainda fornece informações sobre o DynamoDB Encryption Client.

A criptografia pesquisável permite pesquisar registros criptografados sem descriptografar todo o banco de dados. Isso é feito usando beacons, que criam um mapa entre o valor de texto simples gravado em um campo e o valor criptografado que está realmente armazenado em seu banco de dados. O SDK de criptografia de banco de dados da AWS armazena o beacon em um novo campo que ele adiciona ao registro. Dependendo do tipo de beacon que você usa, você pode realizar pesquisas de correspondência exata ou consultas complexas mais personalizadas em seus dados criptografados.

nota

A criptografia pesquisável no SDK de criptografia de banco de dados da AWS difere da criptografia simétrica pesquisável definida em pesquisas acadêmicas, como a criptografia simétrica pesquisável.

Um beacon é uma tag truncada do código de autenticação de mensagens por hash (HMAC) que cria um mapa entre o texto simples e os valores criptografados de um campo. Quando você grava um novo valor em um campo criptografado configurado para criptografia pesquisável, o SDK de criptografia de banco de dados da AWS calcula um HMAC sobre o valor de texto sem formatação. Essa saída de HMAC é uma correspondência de um para um (1:1) para o valor de texto sem formatação desse campo. A saída de HMAC é truncada para que vários valores de texto simples distintos sejam mapeados para a mesma etiqueta de HMAC truncada. Esses falsos positivos limitam a capacidade de um usuário não autorizado de identificar informações diferenciadas sobre o valor do texto sem formatação. Quando você consulta um beacon, o SDK de criptografia de banco de dados da AWS filtra automaticamente esses falsos positivos e retorna o resultado da sua consulta em texto simples.

O número médio de falsos positivos gerados para cada beacon é determinado pelo comprimento do beacon restante após o truncamento. Para obter ajuda na determinação do comprimento adequado do beacon para sua implementação, consulte Determinação do comprimento do beacon.

nota

A criptografia pesquisável foi projetada para ser implementada em bancos de dados novos e não preenchidos. Qualquer beacon configurado em um banco de dados existente mapeará somente os novos registros enviados para o banco de dados, não há como um beacon mapear os dados existentes.

Os beacons são adequados para meu conjunto de dados?

Usar beacons para realizar consultas de dados criptografados reduz o desempenho de custos associados aos banco de dados de criptografia do lado do cliente. Quando você usa beacons, há uma compensação inerente entre a eficiência de suas consultas e a quantidade de informações reveladas sobre a distribuição dos dados. O beacon não altera o estado criptografado do campo. Quando você criptografa e assina um campo com o SDK de criptografia de banco de dados da AWS, o valor em texto simples do campo nunca é exposto ao banco de dados. O banco de dados armazena o valor aleatório e criptografado do campo.

Os beacons são armazenados junto com os campos criptografados a partir dos quais são calculados. Isso significa que, mesmo que um usuário não autorizado não consiga visualizar os valores de texto simples de um campo criptografado, ele poderá realizar análises estatísticas nos beacons para saber mais sobre a distribuição do seu conjunto de dados e, em casos extremos, identificar os valores de texto simples para os quais um beacon mapeia. A maneira como você configura seus beacons pode mitigar esses riscos. Em particular, escolher o comprimento correto do beacon pode ajudá-lo a preservar a confidencialidade do seu conjunto de dados.

Segurança versus desempenho
  • Quanto menor o comprimento do beacon, mais segurança é preservada.

  • Quanto maior o comprimento do beacon, mais desempenho é preservado.

A criptografia pesquisável pode não ser capaz de fornecer os níveis desejados de desempenho e segurança para todos os conjuntos de dados. Analise seu modelo de ameaça, requisitos de segurança e necessidades de desempenho antes de configurar qualquer beacon.

Considere os seguintes requisitos de exclusividade do conjunto de dados ao determinar se a criptografia pesquisável é adequada para seu conjunto de dados.

Distribution

A quantidade de segurança preservada por um beacon depende da distribuição do seu conjunto de dados. Quando você configura um campo criptografado, o SDK de criptografia de banco de dados da AWS calcula um HMAC sobre o valor de texto gravado sem formatação. Todos os beacons calculados para um determinado campo são calculados usando a mesma chave, com exceção dos bancos de dados multilocatários que usam uma chave distinta para cada locatário. Isso significa que, se o mesmo valor de texto simples for gravado no campo várias vezes, a mesma tag HMAC será criada para cada instância desse valor de texto sem formatação.

Você deve evitar criar beacons a partir de campos que contenham valores muito comuns. Por exemplo, considere um banco de dados que armazena o endereço de cada residente do estado de Illinois. Se você construir um beacon a partir do City campo criptografado, o beacon calculado sobre "Chicago" estará sobre-representado devido à grande porcentagem da população de Illinois que vive em Chicago. Mesmo que um usuário não autorizado possa ler apenas os valores criptografados e os valores do beacon, ele poderá identificar quais registros contêm dados para residentes de Chicago se o beacon preservar essa distribuição. Para minimizar a quantidade de informações distintivas reveladas sobre sua distribuição, você deve truncar suficientemente o beacon. O comprimento do beacon necessário para ocultar essa distribuição desigual tem custos de desempenho significativos que podem não atender às necessidades do seu aplicativo.

Você deve analisar cuidadosamente a distribuição do seu conjunto de dados para determinar o quanto seus beacons precisam ser truncados. O comprimento do beacon restante após o truncamento se correlaciona diretamente com a quantidade de informações estatísticas que podem ser identificadas sobre sua distribuição. Talvez seja necessário escolher comprimentos de beacon mais curtos para minimizar suficientemente a quantidade de informações distintivas reveladas sobre seu conjunto de dados.

Em casos extremos, você não pode calcular o comprimento do beacon para um conjunto de dados distribuído de forma desigual que equilibre efetivamente o desempenho e a segurança. Por exemplo, você não deve construir um beacon a partir de um campo que armazena o resultado de um exame médico para uma doença rara. Como se espera que os resultados de NEGATIVE sejam significativamente mais prevalentes no conjunto de dados, os resultados de POSITIVE podem ser facilmente identificados pela raridade. É muito difícil ocultar a distribuição quando o campo tem apenas dois valores possíveis. Se você usar um comprimento de beacon curto o suficiente para ocultar a distribuição, todos os valores de texto simples serão mapeados para a mesma tag HMAC. Se você usar um comprimento de beacon maior, é óbvio quais beacons são mapeados para valores POSITIVE de texto simples.

Correlação

É altamente recomendável que você evite criar beacons distintos a partir de campos com valores correlacionados. Os beacons construídos a partir de campos correlacionados exigem comprimentos de beacon mais curtos para minimizar suficientemente a quantidade de informações reveladas sobre a distribuição de cada conjunto de dados a um usuário não autorizado. Você deve analisar cuidadosamente o seu conjunto de dados, incluindo a sua entropia e distribuição conjunta de valores correlacionados, para determinar o quanto seus beacons precisam ser truncados. Se o comprimento do beacon resultante não atender às suas necessidades de desempenho, os beacons podem não ser adequados para seu conjunto de dados.

Por exemplo, você não deve criar dois beacons separados de campos City e ZIPCode porque o CEP provavelmente estará associado a apenas uma cidade. Normalmente, os falsos positivos gerados por um beacon limitam a capacidade de um usuário não autorizado de identificar informações diferenciadas sobre seu conjunto de dados. Mas a correlação entre os campos City e ZIPCode significa que um usuário não autorizado pode identificar facilmente quais resultados são falsos positivos e distinguir os diferentes CEPs.

Você deve evitar criar beacons a partir de campos que contenham os mesmos valores de texto simples. Por exemplo, você não deve criar um beacon a partir dos campos mobilePhone e preferredPhone, pois eles provavelmente têm os mesmos valores. Se você criar beacons distintos dos dois campos, o SDK de criptografia de banco de dados da AWS criará os beacons para cada campo em chaves diferentes. Isso resulta em duas tags HMAC diferentes para o mesmo valor de texto simples. É improvável que os dois beacons distintos tenham os mesmos falsos positivos e um usuário não autorizado poderá distinguir números de telefone diferentes.

Mesmo que seu conjunto de dados contenha campos correlacionados ou tenha uma distribuição desigual, você poderá criar beacons que preservem a confidencialidade do seu conjunto de dados usando beacons menores. No entanto, o comprimento do beacon não garante que cada valor exclusivo em seu conjunto de dados produza vários falsos positivos que minimizem efetivamente a quantidade de informações distintivas reveladas sobre seu conjunto de dados. O comprimento do beacon estima apenas o número médio de falsos positivos produzidos. Quanto mais desigualmente distribuído seu conjunto de dados, menos efetivo é o comprimento do beacon na determinação do número médio de falsos positivos produzidos.

Considere cuidadosamente a distribuição dos campos a partir dos quais você constrói os beacons e considere o quanto você precisará truncar o comprimento do beacon para atender aos seus requisitos de segurança. Os tópicos a seguir neste capítulo pressupõem que seus beacons estejam distribuídos uniformemente e não contenham dados correlacionados.

Cenário de criptografia pesquisável

O exemplo a seguir demonstra uma solução de criptografia simples que pode ser pesquisada. No aplicativo, os campos de exemplo usados neste exemplo podem não atender às recomendações de exclusividade de distribuição e correlação para beacons. É possível usar esse exemplo para referência ao ler sobre os conceitos de criptografia pesquisável neste capítulo.

Considere um banco de dados chamado Employees que monitora os dados dos funcionários de uma empresa. Cada registro no banco de dados contém campos chamados EmployeeID, LastName, FirstName e Address. Cada campo no banco de dados Employees é identificado pela chave primária EmployeeID.

Veja a seguir um exemplo de um registro de texto sem formatação no banco de dados.

{ "EmployeeID": 101, "LastName": "Jones", "FirstName": "Mary", "Address": { "Street": "123 Main", "City": "Anytown", "State": "OH", "ZIPCode": 12345 } }

Se você marcou os campos LastName e FirstName como ENCRYPT_AND_SIGN em suas ações criptográficas, os valores nesses campos são criptografados localmente antes de serem carregados no banco de dados. Os dados criptografados enviados são totalmente aleatórios, o banco de dados não reconhece esses dados como protegidos. Ele apenas detecta entradas de dados típicas. Isso significa que o registro que está realmente armazenado no banco de dados pode ter a seguinte aparência.

{ "PersonID": 101, "LastName": "1d76e94a2063578637d51371b363c9682bad926cbd", "FirstName": "21d6d54b0aaabc411e9f9b34b6d53aa4ef3b0a35", "Address": { "Street": "123 Main", "City": "Anytown", "State": "OH", "ZIPCode": 12345 } }

Se você precisar consultar o banco de dados para obter correspondências exatas no campo LastName, configure um beacon padrão chamado LastName para mapear os valores de texto simples gravados no campo LastName para os valores criptografados armazenados no banco de dados.

Esse beacon calcula HMACs a partir dos valores de texto simples no campo LastName. Cada saída HMAC é truncada para que não seja mais uma correspondência exata para o valor do texto sem formatação. Por exemplo, o hash completo e o hash truncado para Jones podem ter a seguinte aparência.

Hash completo

2aa4e9b404c68182562b6ec761fcca5306de527826a69468885e59dc36d0c3f824bdd44cab45526f70a2a18322000264f5451acf75f9f817e2b35099d408c833

Hash truncado

b35099d408c833

Depois que o beacon padrão for configurado, você poderá realizar pesquisas de igualdade no campo LastName. Por exemplo, se você quiser pesquisar por Jones, use o beacon LastName para realizar a consulta a seguir.

LastName = Jones

O SDK de criptografia de banco de dados da AWS filtra automaticamente esses falsos positivos e retorna o resultado da sua consulta em texto simples.