Características

Visão geral

Nesta página, você aprenderá sobre os benefícios de segurança da Queryable Encryption, como ela funciona e como se compara a outros mecanismos de segurança suportados pelo MongoDB. Você também pode visualizar um cenário fictício que demonstra o valor da Queryable Encryption na proteção de seus dados.

Queryable Encryption

A Queryable Encryption é um recurso do MongoDB que permite que um aplicativo cliente criptografe dados antes de transportá-los pela rede usando criptografia totalmente aleatória, mantendo a consultabilidade. Os dados confidenciais são criptografados e descriptografados de forma transparente pelo cliente e só são comunicados de e para o servidor de forma criptografada. As garantias de segurança para campos sensíveis que contêm dados de baixa cardinalidade (baixa frequência) e dados de alta cardinalidade são idênticas

Ao contrário da criptografia no nível do campo do lado do cliente que pode usar a Criptografia Determinística, a Queryable Encryption usa esquemas de criptografia rápidos e pesquisáveis com base em criptografia estruturada. Esses esquemas produzem valores de saída criptografados diferentes mesmo quando recebem a mesma entrada de texto não criptografado.

Considerações de segurança

• O Queryable Encryption não oferece nenhuma garantia de integridade criptográfica contra adversários com acesso à chave mestra do cliente ou às chaves de criptografia de dados.

• O Queryable Encryption não oferece nenhuma garantia de integridade criptográfica contra adversários com acesso arbitrário de gravação a coleções contendo dados criptografados.

• O MongoDB usa validação de esquema para impor a criptografia de campos específicos em uma coleção. Sem um esquema do lado do cliente, o cliente faz download do esquema do lado do servidor para que a coleção determine quais campos criptografar. Para evitar esse problema, use a validação de esquema do lado do cliente.

  Como a Queryable Encryption não fornece um mecanismo para verificar a integridade de um esquema, confiar em um esquema do lado do servidor significa confiar que o esquema do servidor não foi violado. Se um adversário comprometer o servidor, ele poderá modificar o esquema para que um campo criptografado anteriormente não seja mais rotulado para criptografia. Isso faz com que o cliente envie valores de texto sem formatação para esse campo.

  Para ver um exemplo de configuração para esquemas do lado do cliente e do servidor, consulte o exemplo de CSFLE em Aplicação de criptografia em nível de campo no lado do servidor CSFLE.

Como funciona a Queryable Encryption

O diagrama abaixo mostra o processo e a arquitetura de como a Queryable Encryption é usada em um ambiente de cliente.

Neste diagrama, o usuário é capaz de fazer query em dados criptografados aleatoriamente, como o número SSN.

O processo e os mecanismos que tornam isso possível dentro da estrutura do Queryable Encryption são os seguintes:

1. Quando o aplicativo envia a query, os drivers do MongoDB analisam primeiro a query.

2. O driver reconhece que a consulta é feita em relação a um campo criptografado e solicita a chave de criptografia do provedor de chaves provisionadas pelo cliente, como:

   • Serviço de gerenciamento de chaves da AWS (AWS KMS)

   • KMS do Google Cloud

   • Cofre de chaves do Azure

   • Qualquer provedor de chaves compatívelcom KMIP

3. O driver envia a consulta para o servidor MongoDB com os campos criptografados renderizados como texto cifrado.

4. A Queryable Encryption implementa um esquema rápido e pesquisável, o qual permite que o servidor processe query em dados totalmente criptografados, sem saber nada sobre os dados. Os dados e a própria query permanecem criptografados o tempo todo no servidor.

5. O servidor MongoDB retorna os resultados criptografados da query para o driver.

6. Os resultados da query são descriptografados com as chaves mantidas pelo driver e retornados ao cliente e mostrados como texto sem formatação.

A Queryable Encryption funciona com a ajuda das seguintes estruturas de dados. É fundamental que não sejam modificados nem excluídos, ou os resultados da query serão incorretos.

• O Queryable Encryption adiciona um campo __safeContent__ aos documentos em qualquer collection em que haja um campo criptografado do Queryable Encryption.

• O Queryable Encryption cria três collection de metadados no mesmo reconhecimento de data center da collection onde há um campo criptografado do Queryable Encryption. Eles são nomeados da seguinte forma:

  • enxcol_.<collectionName>.esc

  • enxcol_.<collectionName>.ecc

  • enxcol_.<collectionName>.ecoc

A Queryable Encryption mantém os campos criptografados seguros nos seguintes cenários:

• Acesso direto a campos criptografados por um superusuário do banco de dados

• Acesso a campos criptografados a partir da leitura da memória do servidor

• Captura de campos criptografados em uma rede insegura

• Acesso a campos criptografados em disco por meio da leitura de arquivos de banco de dados ou de backup

• Análise de frequência de ataques identificando padrões em documentos criptografados

Embora todos os clientes tenham acesso aos campos de dados não confidenciais, somente clientes da Queryable Encryption configurados adequadamente podem executar queries de leitura e gravação usando os campos de dados criptografados.

Outros mecanismos de segurança

Esta seção descreve os seguintes mecanismos de segurança compatíveis com o MongoDB e explica seus casos de uso e limitações:

• Controle de acesso com base em função

• Criptografia em descanso

• Criptografia de transporte (TLS/SSL)

Comparação de recursos

O diagrama a seguir descreve os recursos de segurança compatíveis com o MongoDB e as possíveis vulnerabilidades de segurança abordadas por eles:

Cenário

O cenário fictício a seguir demonstra o valor da Queryable Encryption na proteção dos dados do seu aplicativo e mostra também como a Queryable Encryption interage com o outro mecanismo de segurança discutido neste guia.

Nesse cenário, protegemos dados confidenciais em um sistema de gerenciamento de atendimento médico que armazena informações pessoais dos pacientes, informações de faturamento e registros médicos de uma empresa fictícia, a MedcoMD. Nenhum dos dados de pacientes é público, e dados específicos, como seu número de segurança social (SSN, um ID emitido pelo governo dos EUA), ID do paciente, informações de faturamento e informações sobre medicamentos são particularmente confidenciais e estão sujeitos a regras de privacidade. É importante para a empresa e para o paciente que os dados sejam mantidos privados e seguros.

A MedcoMD precisa desse sistema para atender aos seguintes casos de uso:

• Os médicos usam o sistema para acessar os prontuários dos pacientes, informações de faturamento e atualizar medicamentos.

• Recepcionistas usam o sistema com o objetivo de verificar a identidade dos pacientes a partir dos dados para contato forncecidos por eles.

• Os recepcionistas podem visualizar as informações de faturamento de um paciente, mas não seu número de identificação do paciente.

• Recepcionistas não podem acessar os registros médicos de um paciente.

A MedcoMD também se preocupa com a divulgação de dados confidenciais por meio de qualquer um dos seguintes métodos:

• Divulgação acidental de dados na tela de um recepcionista que pode ser vista publicamente.

• Acesso direto ao banco de dados por um superusuário, como um administrador de banco de dados.

• Captura de dados através de uma rede insegura.

• Acesso a campos criptografados a partir da leitura da memória do servidor do banco de dados

• Acesso a dados por meio da leitura de arquivos do banco de dados ou arquivos de backup.

O que a MedcoMD pode fazer para criar equilíbrio entre funcionalidade e restrições de acesso no sistema de gerenciamento de cuidados médicos da empresa?

Saiba mais

Para ver uma lista de medidas de segurança que você deve implementar para proteger sua implantação do MongoDB, consulte a Lista de verificação de segurança.

Para começar a usar a Queryable Encryption, consulte o Início Rápido.