View a markdown version of this page

Criptografia pesquisável - AWS SDK de criptografia de banco de dados
Os beacons são adequados para meu conjunto de dados?Cenário de criptografia pesquisável

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 para SDK de criptografia de AWS banco de dados. 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 AWS de criptografia de banco de dados 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 AWS de criptografia de banco de dados difere da criptografia simétrica pesquisável definida em pesquisas acadêmicas, como a criptografia simétrica pesquisável.

Um beacon é uma tag de Código de Autenticação de Hash-Based Mensagem (HMAC) truncada que mapeia o valor de um campo de texto simples para um identificador criptografado e pesquisável. Quando você grava um valor em um campo criptografado configurado para criptografia pesquisável, o SDK de criptografia AWS de banco de dados computa um HMAC sobre o valor de texto simples. Essa saída de HMAC é uma correspondência de um para um (1:1) para o valor de texto sem formatação desse campo. O SDK trunca intencionalmente a saída do HMAC para que vários valores distintos de texto simples colidam no mesmo farol. Essas colisões (falsos positivos) limitam a capacidade de um usuário não autorizado de inferir informações confidenciais a partir de padrões de frequência. Quando você consulta um beacon, o SDK AWS de criptografia de banco de dados filtra automaticamente esses falsos positivos e retorna o resultado em texto simples da sua consulta. Para resolver ainda mais esse problema de vazamento de frequência, os beacons são particionados, permitindo que valores de texto simples idênticos produzam valores de farol diferentes nas partições. Quando a tabela usa somente uma única partição, esse comportamento corresponde naturalmente aos beacons tradicionais e não particionados.

O número médio de falsos positivos para cada farol depende do comprimento restante do farol após o truncamento e do número de partições. 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.

Tópicos

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 AWS de criptografia de banco de dados, 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 configuração adequada do farol é essencial para mitigar esses riscos. A seleção de um comprimento de farol e um esquema de particionamento apropriados preserva a confidencialidade, garantindo colisões suficientes e mitigando ataques baseados em frequência por meio da limitação da concentração de valores em qualquer farol único.

Segurança versus desempenho

  • Comprimentos de farol mais curtos e contagens de partições mais altas melhoram a segurança, aumentando as colisões e reduzindo o vazamento de frequência,

  • Comprimentos de farol mais longos e menos partições melhoram o desempenho ao reduzir os falsos positivos e a dispersão de consultas.

Em muitos cenários práticos, uma configuração bem escolhida pode equilibrar essas metas concorrentes. No entanto, a criptografia pesquisável pode não ser capaz de fornecer os níveis desejados de segurança e desempenho para cada conjunto de dados.

Antes de configurar qualquer beacon, analise cuidadosamente seu modelo de ameaça, requisitos de segurança e necessidades de desempenho e considere as características exclusivas do seu conjunto de dados para determinar se a criptografia pesquisável é uma escolha apropriada.

Distribuição

As propriedades de segurança de um beacon dependem da distribuição dos dados subjacentes e de como o beacon é configurado, incluindo quantas partições são usadas. Quando você configura um campo criptografado para criptografia pesquisável, o SDK de criptografia AWS de banco de dados calcula um HMAC sobre cada valor de texto simples gravado nesse campo e deriva o beacon usando uma chave criptográfica. Os beacons são calculados no contexto de uma partição, o que permite que valores de texto simples idênticos produzam valores de farol diferentes nas partições. Quando a tabela usa somente uma única partição, valores de texto simples idênticos sempre são mapeados para a mesma tag HMAC truncada, que pode preservar os padrões de frequência do conjunto de dados original.

Campos com distribuições altamente distorcidas requerem cuidados especiais. Por exemplo, considere um banco de dados que armazena a cidade de residência de todos os residentes de Illinois. Se você construir um farol a partir do City campo criptografado, o valor “Chicago” ocorrerá com muito mais frequência do que em outras cidades. Mesmo que um usuário não autorizado possa acessar apenas itens criptografados e valores de beacon, esse desequilíbrio pode permitir que eles inferam quais registros correspondem aos residentes de Chicago observando beacons super-representados. Truncar o farol pode reduzir esse vazamento forçando mais colisões, mas o comprimento do farol necessário para ocultar suficientemente a inclinação severa pode causar uma sobrecarga significativa no desempenho devido ao aumento de falsos positivos.

Para configurar beacons com segurança, você deve analisar a distribuição de frequência de seus dados e entender como o truncamento e o particionamento interagem. O número de bits retidos em um farol determina a quantidade de informações estatísticas expostas, enquanto o número de partições limita o quão concentrado qualquer valor de farol único pode se tornar. Comprimentos de farol mais curtos e mais partições reduzem o vazamento de frequência, mas aumentam os falsos positivos e a difusão de consultas. Comprimentos de farol maiores e menos partições melhoram a eficiência da consulta, mas expõem mais informações sobre a distribuição subjacente.

Em alguns casos extremos, as cargas de trabalho não são viáveis quando a tabela usa somente uma única partição. Atributos com populações muito pequenas ou resultados binários altamente desequilibrados, como resultados de exames médicos em que os valores NEGATIVOS dominam, não podem ser protegidos usando apenas o truncamento. Com uma partição, um farol curto o suficiente para ocultar a distribuição reúne todos os valores em uma única tag, enquanto um farol mais longo facilita a identificação de valores raros. Nesses casos, beacons particionados são necessários para viabilizar a criptografia pesquisável. Ao distribuir valores super-representados em várias partições, essa abordagem reduz o tamanho das classes de equivalência e limita o vazamento de frequência de maneiras que não são possíveis ao usar uma única partição.

Correlação

É altamente recomendável que você evite construir 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 construir 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 construir beacons a partir de campos que contenham os mesmos valores de texto simples. Por exemplo, você não deve construir 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 AWS de banco de dados 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á construir 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.

Avalie cuidadosamente a distribuição dos campos que você escolhe para beaconizar e determine quanto truncamento é necessário para atender aos seus requisitos de segurança. Os tópicos a seguir neste capítulo pressupõem que, dentro de cada partição, os valores do farol são distribuídos uniformemente e que os dados subjacentes não introduzem correlações que enfraqueceriam essas suposições.

Cenário de criptografia pesquisável

O exemplo a seguir demonstra uma solução de criptografia pesquisável e ilustra os principais conceitos discutidos neste capítulo. Nesse cenário, certos valores de campo ocorrem com muita frequência, o que levaria a grandes classes de equivalência e maior vazamento de frequência se uma única partição fosse usada. Para resolver isso, a configuração usa várias partições para que valores altamente frequentes sejam distribuídos de maneira mais uniforme, reduzindo o vazamento e preservando a capacidade de realizar pesquisas de igualdade eficientes.

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 LastName campo, configure um farol padrão chamado LastNamepara mapear os valores de texto simples gravados no LastName campo 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

Em um conjunto de dados com muitos funcionários, certos sobrenomes, como Jones, Smith ou Johnson, podem ocorrer com muito mais frequência do que outros. Para reduzir o vazamento de frequência e limitar o tamanho das classes de equivalência de beacon, você deve configurar o LastNamebeacon para usar mais de uma partição.

Quando as partições são habilitadas, cada item é atribuído a uma partição no momento da gravação e o número da partição é incorporado à derivação do beacon. Como resultado, funcionários com o mesmo sobrenome podem ser mapeados para valores de farol diferentes nas partições. Isso distribui nomes altamente frequentes em várias partições, reduzindo a representação excessiva de qualquer valor de farol único.

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

LastName = Jones

Ao consultar um sobrenome específico de alta frequência, como Jones, o aplicativo deve emitir uma consulta por partição usando o LastNamebeacon. Em seguida, o SDK de criptografia de AWS banco de dados decifra os resultados e filtra automaticamente todos os falsos positivos, retornando os registros corretos em texto simples.