Beacons

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.

Um beacon é uma tag de Código de Autenticação de Hash-Based Mensagem (HMAC) truncada que mapeia um valor de campo de texto simples para um identificador criptografado e pesquisável armazenado junto com os dados criptografados em seu banco de dados. O beacon não altera o estado criptografado do campo. Quando você grava um valor em um campo configurado para criptografia pesquisável, o SDK de criptografia de banco de dados da AWS computa um HMAC sobre o valor de texto simples e deriva o beacon no contexto de uma partição. O HMAC completo corresponde exclusivamente ao valor do texto simples, mas o SDK trunca intencionalmente a saída para que vários valores distintos de texto simples possam ser mapeados para o mesmo farol. Essas colisões (falsos positivos) limitam a capacidade de um usuário não autorizado de inferir informações distintas sobre o texto simples subjacente.

nota

Um Código de Autenticação de Hash-based Mensagens (HMAC) é uma função hash criptográfica com chave comumente usada para fornecer integridade e autenticidade. Em sistemas de criptografia pesquisáveis, o HMAC é frequentemente usado para derivar deterministicamente beacons de valores de texto simples para que possam ser indexados e consultados.

Um HMAC completo é determinístico: para uma determinada chave, o mesmo valor de texto simples sempre produz o mesmo farol. Esse determinismo resulta em um mapeamento individual entre valores de texto simples e beacons, preservando a distribuição de frequência original dos dados. Todos os registros que compartilham o mesmo valor de texto simples são mapeados para o mesmo farol e, portanto, formam uma classe de equivalência. O tamanho de cada classe de equivalência reflete diretamente a frequência com que o valor de texto simples correspondente aparece no conjunto de dados.

Essa preservação de frequência permite ataques de análise de frequência, nos quais um observador infere valores prováveis de texto simples correlacionando as frequências observadas dos faróis com distribuições de dados conhecidas ou esperadas.

Para mitigar os ataques de análise de frequência, o SDK deriva beacons usando truncamento e particionamento. Truncar o HMAC introduz colisões controladas, de forma que nem todos os registros dentro de uma classe de equivalência necessariamente compartilhem o mesmo valor de farol. Além disso, a incorporação de um identificador de partição na derivação do beacon permite que valores de texto simples idênticos sejam mapeados para diferentes beacons nas partições. Juntas, essas técnicas promovem maior aleatoriedade para conjuntos de dados distribuídos de forma desigual, preservando o comportamento de consulta correto e eficiente.

Os beacons só podem ser construídos a partir de campos ENCRYPT_AND_SIGN marcados ou SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT em suas ações criptográficas. SIGN_ONLY O beacon em si não está assinado nem criptografado. Você não pode construir um beacon com campos marcados com DO_NOTHING.

Depois de configurar os beacons, você deve configurar um índice secundário para cada beacon antes de poder pesquisar nos campos criptografados. Para obter mais informações, consulte Configuração de índices secundários com beacons.

Entendendo a derivação de faróis entre partições

O particionamento é uma parte essencial da configuração do beacon e se aplica a todos os beacons, incluindo aqueles que usam uma única partição. Esse modelo garante uma derivação de beacon consistente e compatível com versões futuras em todos os dados e permite que você aumente o número de partições ao longo do tempo à medida que o volume ou a distribuição dos dados mudam. Ao fazer isso, você pode reduzir o vazamento de frequência e fortalecer as proteções para conjuntos de dados distribuídos de forma desigual sem reescrever os itens existentes.

As partições introduzem aleatoriedade controlada distribuindo itens em vários grupos lógicos. Isso reduz o vazamento de frequência, limita o tamanho das classes de equivalência de beacon e melhora a segurança e a privacidade de atributos com distribuições distorcidas.

Quando um item é atribuído a uma partição, o número da partição é incorporado à derivação do farol. Dentro da mesma partição, valores de texto simples idênticos produzem o mesmo farol, preservando a semântica de busca por igualdade. Em partições diferentes, o mesmo valor de texto simples produz valores de farol diferentes. Isso divide grandes classes de equivalência em grupos menores por partição e ajuda a nivelar a distribuição geral de frequência dos faróis.

Você tem controle total sobre como cada item do banco de dados é atribuído a uma partição. Os itens podem ser colocados em partições específicas de forma determinística ou distribuídos aleatoriamente para ajudar a suavizar distribuições de dados desiguais. A atribuição aleatória é especialmente útil para valores de alta frequência, pois distribui esses valores em várias partições e reduz a concentração visível em qualquer partição única. A atribuição determinística pode ser usada quando o conhecimento do domínio indica que determinados valores devem ser restritos a menos partições.

O identificador da partição não é exposto no registro criptografado. Em vez disso, o número da partição é incorporado ao processo de derivação do beacon — combinado com o valor do texto simples — para que não possa ser inferido examinando os dados criptografados ou o próprio beacon. Esse design garante que as atribuições de partições permaneçam confidenciais e, ao mesmo tempo, forneça os benefícios de distribuição e privacidade dos beacons particionados.

Impacto do particionamento na consulta

O particionamento afeta a forma como Query as operações são executadas. Como as consultas do DynamoDB exigem uma correspondência exata no valor do beacon indexado e os valores do beacon diferem entre as partições, o chamador deve consultar cada partição de forma independente. Se uma tabela tiver N partições:

• A recuperação de todos os itens correspondentes requer consultas N separadas.

• Só Query é afetado.

• Scane Get as operações se comportam como antes.

O motivo é estrutural: Scan lê todos os itens e Get opera em uma chave específica; Query depende apenas da igualdade exata no índice, que se torna específico da partição.

nota

Fan-out refere-se ao número de consultas do DynamoDB que devem ser emitidas para atender a uma única solicitação lógica ao usar beacons particionados. O sistema fornece fan-out limitado, o que significa que o número máximo de consultas em nível de partição é fixo e previsível com base no número configurado de partições.

Considerações sobre desempenho

O uso de partições afeta o número de consultas do DynamoDB necessárias por solicitação lógica. O impacto no desempenho depende do tamanho esperado do resultado:

• Grandes conjuntos de resultados: quando as consultas retornam muitas páginas, as consultas extras em nível de partição adicionam pouca sobrecarga.

• Single-item pesquisas: se uma solicitação normalmente retorna um item e cinco partições são configuradas, cinco consultas são emitidas — quatro não retornam resultados — resultando em uma desaceleração quase linear.

• Localidade reduzida: os itens podem estar espalhados pelas partições, aumentando o tempo de recuperação.

Como cada partição aciona uma consulta adicional, o fan-out é um fator importante no planejamento de desempenho e capacidade.

Vantagens de desempenho

Apesar da sobrecarga adicional de consultas, as partições podem melhorar o desempenho em determinados cenários:

• Reduzindo grandes classes de equivalência: quando um valor raro compartilha um farol truncado com um valor que ocorre com frequência, as consultas pelo valor raro devem processar muitas correspondências irrelevantes. O particionamento limita o tamanho de cada classe de equivalência e reduz essa sobrecarga.

• Suportando comprimentos de farol maiores: a configuração de mais partições pode permitir o uso de comprimentos de farol maiores, o que reduz as taxas de falsos positivos e reduz a quantidade de filtragem pós-descriptografia necessária.

Tipos de faróis

O tipo de beacon que você configura determina o tipo de consultas que você é capaz de realizar. Há dois tipos de beacons que oferecem suporte à criptografia pesquisável. Os beacons padrão realizam pesquisas de igualdade. Os beacons compostos combinam cadeias de texto simples literais e beacons padrão para realizar operações complexas de banco de dados.

Beacons padrão

Os beacons padrão são a maneira mais simples de implementar criptografia pesquisável em seu banco de dados. Eles só podem realizar pesquisas de igualdade para um único campo criptografado ou virtual. Para saber mais sobre a configuração de beacons padrão, consulte Configuração de beacons padrão. Você também pode usar partições com beacons para promover a aleatoriedade quando os dados subjacentes têm uma distribuição desigual.

A seguir estão conceitos importantes para beacons padrão.

Fonte de farol

O campo a partir do qual um beacon padrão é construído é chamado de fonte do beacon. Ele identifica a localização dos dados que o beacon precisa mapear. A fonte do beacon pode ser um campo criptografado ou um campo virtual. A fonte do beacon em cada beacon padrão deve ser exclusiva. Você não pode configurar dois beacons com a mesma fonte de beacon.

Os beacons padrão podem ser usados para realizar pesquisas de igualdade para um campo criptografado ou virtual. Ou, eles podem ser usados para construir beacons compostos para realizar operações de banco de dados mais complexas. Para ajudá-lo a organizar e gerenciar beacons padrão, o SDK de criptografia de AWS banco de dados fornece os seguintes estilos de beacon opcionais que definem o uso pretendido de um beacon padrão. Para obter mais informações, consulte Definindo estilos de beacon.

Você pode criar um farol padrão que realiza pesquisas de igualdade para um único campo criptografado ou pode criar um farol padrão que realiza pesquisas de igualdade na concatenação de vários camposENCRYPT_AND_SIGN,SIGN_ONLY, e SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT criando um campo virtual.

Campos virtuais

Um campo virtual é um campo conceitual construído a partir de um ou mais campos de origem. A criação de um campo virtual não grava um novo campo em seu registro. O campo virtual não é armazenado explicitamente em seu banco de dados. Ele é usado na configuração de beacon padrão para fornecer instruções ao beacon sobre como identificar um segmento específico de um campo ou concatenar vários campos em um registro para realizar uma consulta específica. Um campo virtual exige pelo menos um campo criptografado.

nota

O exemplo a seguir demonstra os tipos de transformações e consultas que você pode realizar com um campo virtual. 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.

Por exemplo, se você quiser realizar pesquisas de igualdade na concatenação dos campos FirstName e LastName, você pode criar um dos campos virtuais a seguir.

• Um campo NameTag virtual, construído a partir da primeira letra do campo FirstName, seguida pelo campo LastName, tudo em minúsculas. Esse campo virtual permite que você consulte NameTag=mjones.

• Um campo LastFirst virtual, que é construído a partir do campo LastName, seguido pelo campo FirstName. Esse campo virtual permite que você consulte LastFirst=JonesMary.

Ou, se você quiser realizar pesquisas de igualdade em um segmento específico de um campo criptografado, crie um campo virtual que identifique o segmento que você deseja consultar.

Por exemplo, se você quiser consultar um campo IPAddress criptografado usando os três primeiros segmentos do endereço IP, crie o seguinte campo virtual.

• Um campo IPSegment virtual, construído a partir de Segments(‘.’, 0, 3). Esse campo virtual permite que você consulte IPSegment=192.0.2. A consulta retorna todos os registros com um valor IPAddress que começa com "192.0.2".

Os campos virtuais devem ser exclusivos. Dois campos virtuais não podem ser construídos exatamente a partir dos mesmos campos de origem.

Para obter ajuda na configuração de campos virtuais e os beacons que os usam, consulte Criar um campo virtual.

Beacons compostos

Os beacons compostos criam índices que melhoram o desempenho das consultas e permitem que você execute operações de banco de dados mais complexas. É possível usar beacons compostos para combinar cadeias de texto simples literais e beacons padrão para realizar consultas complexas em registros criptografados, como consultar dois tipos de registro diferentes de um único índice ou consultar uma combinação de campos com uma chave de classificação. Para obter mais exemplos de soluções de beacon composto, consulte Escolher um tipo de beacon.

Os faróis compostos podem ser construídos a partir de faróis padrão ou uma combinação de faróis padrão e campos assinados. Eles são construídos a partir de uma lista de partes. Todos os beacons compostos devem incluir uma lista de partes criptografadas que identifique os campos ENCRYPT_AND_SIGN incluídos no beacon. Cada campo ENCRYPT_AND_SIGN deve ser identificado por um beacon padrão. Os faróis compostos mais complexos também podem incluir uma lista de partes assinadas que identificam o texto simples SIGN_ONLY ou os SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT campos incluídos no farol e uma lista de partes do construtor que identificam todas as maneiras possíveis pelas quais o farol composto pode montar os campos.

nota

O SDK AWS de criptografia de banco de dados também oferece suporte a beacons assinados que podem ser configurados inteiramente a partir de texto simples SIGN_ONLY e campos. SIGN_AND_INCLUDE_IN_ENCRYPTION_CONTEXT Os beacons assinados são um tipo de farol composto que indexa e executa consultas complexas em campos assinados, mas não criptografados. Para obter mais informações, consulte Criação de beacons assinados.

Para obter ajuda com a configuração de beacons compostos, consulte Configurar beacons compostos.

O tipo de beacon que você configura determina o beacon composto determina os tipos de consultas que você pode realizar. Por exemplo, você pode tornar algumas partes criptografadas e assinadas opcionais para permitir mais flexibilidade em suas consultas. Para obter mais informações sobre os tipos de consultas que os beacons compostos podem realizar, consulte Consultar beacons.