Características
Nesta página
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 permite que um aplicativo do cliente criptografe dados antes de transportá-los pela rede usando criptografia totalmente aleatória, mantendo a capacidade de query. Os dados confidenciais são criptografados e descriptografados de forma transparente pelo cliente e comunicados somente de e para o servidor de forma criptografada.
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.
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 Queryable Encryption são os seguintes:
Quando o aplicativo envia a query, os drivers do MongoDB analisam primeiro a query.
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
Azure Key Vault
Qualquer provedor de chaves compatívelcom KMIP
O driver envia a consulta para o servidor MongoDB com os campos criptografados renderizados como texto cifrado.
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.
O servidor MongoDB retorna os resultados criptografados da query para o driver.
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 duas coleções de metadados internos no mesmo banco de dados da coleção onde há um campo criptografado do Queryable Encryption. Eles são nomeados da seguinte forma:
enxcol_.<collectionName>.esc
enxcol_.<collectionName>.ecoc
Aviso
Não modifique essas estruturas de dados, pois, se o fizer, os resultados da query estarão incorretos e a segurança poderá ser afetada.
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 com campos 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.
Importante
Sistema de gerenciamento remoto de chaves
Ao utilizar a Queryable Encryption em produção, você deve utilizar um sistema de gerenciamento de chaves (KMS) remoto para armazenar sua chave de criptografia.
Para ver uma lista de todos os provedores de KMS compatíveis, consulte Provedores de KMS.
Para saber mais sobre por que você deve usar um KMS remoto, consulte Motivos para usar um Sistema de Gerenciamento de Chaves Remotas.
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
O controle de acesso com base em função é um mecanismo de segurança que permite aos administradores conceder e restringir permissões de nível de coleção para os usuários. Com a definição e atribuição de funções adequadas, esta solução evita a divulgação acidental de dados e acesso.
O controle de acesso baseado em funções não pode proteger contra os seguintes cenários:
Captura dos dados em uma rede insegura
Acesso a dados no disco por meio da leitura de arquivos do banco de dados ou de backup
Acesso aos dados lendo a memória do servidor
Acesso direto aos dados por um superusuário do banco de dados
Para saber mais, consulte Controle de acesso baseado em funções.
Criptografia em descanso
A criptografia em descanso é um mecanismo que criptografa arquivos de banco de dados em disco. Esse mecanismo impede que uma pessoa que não tenha credenciais de banco de dados, mas tenha acesso ao computador que hospeda seu banco de dados, visualize seus dados.
Esse mecanismo não protege seus dados contra os seguintes cenários:
Captura dos dados em uma rede insegura
Acesso aos dados lendo a memória do servidor
Acesso direto aos dados por um superusuário do banco de dados
Para saber mais, consulte a página Criptografia em descanso.
Criptografia de transporte (TLS/SSL)
A criptografia de transporte usando TLS/SSL criptografa seus dados pela rede. O TLS/SSL protege seus dados enquanto eles trafegam por uma rede insegura, mas não pode proteger seus dados de um usuário privilegiado ou quando eles ficam no disco.
Para saber mais, consulte Criptografia de transporte usando TLS/SSL
Comparação de recursos
Para saber mais sobre a criptografia no nível do campo do lado do cliente, consulte Recursos de criptografia no nível do campo do lado do cliente.
A tabela a seguir descreve possíveis preocupações de segurança e como os recursos de criptografia do MongoDB as abordam. Use esses mecanismos juntos: Controle de acesso baseado em funções, Criptografia em repouso, Criptografia de transporte e Criptografia em criptografia em execução. Observe que você não pode usar a criptografia em nível de campo do lado do cliente e a Queryable Encryption na mesma coleção.
Importante
Este é um resumo de alto nível destinado a comparação geral. Para obter informações detalhadas, consulte a Visão geral da Queryable Encryption e design e análise de um esquema de criptografia de banco de dados de documentos sem estado whitepapers.
Ameaça | Criptografia de transporte TLS/SSL | Encryption at rest (EaR) | Queryable Encryption (Equality) + TLS/SSL + EaR | CSFLE + TLS/SSL + EaR |
---|---|---|---|---|
Snooping de rede (o invasor tem acesso ao tráfego de rede) | Mostra metadados da operação | Mostra metadados da operação | Mostra metadados da operação | Mostra metadados da operação |
Recuperações de banco de dados a partir do disco (o invasor tem acesso ao disco físico) | Mostra o banco de banco de dados | Mostra o tamanho dos metadados do banco de banco de dados e da operação | Mostra o tamanho dos metadados do banco de banco de dados e da operação | Mostra o tamanho dos metadados do banco de banco de dados e da operação |
Exfiltração de banco de dados de disco e memória (o invasor tem acesso físico ao disco e vários snapshots do banco de dados de dados) [1] | Mostra o banco de banco de dados | Mostra o banco de banco de dados | Mostra o tamanho dos metadados do banco de banco de dados e da operação | Mostra a frequência de valores e metadados da operação |
Ameaça persistente avançada (o invasor tem acesso contínuo e de longo prazo à rede, ao disco e à memória enquanto permanece sem ser detectado) | Mostra o banco de banco de dados | Mostra o banco de banco de dados | A Queryable Encryption não foi projetada para proteger contra um Atlas. Consulte o whitepaper para obter detalhes. | O CSFLE não foi projetado para proteger contra um Atp. Consulte o whitepaper para obter detalhes. |
[1] | Isso pressupõe que a saída ocorra entre operações concluídas. Ver whitepaper para obter detalhes. |
Aviso
A Queryable Encryption contra a exfiltração de dados, não contra invasores com acesso persistente a um ambiente ou contra aqueles que podem recuperar snapshots do banco de dados de dados e transcrições/registros de query que os acompanhem.
Ao usar a Queryable Encryption, as queries de igualdade e faixa oferecem segurança semelhante contra invasores com snapshots de banco de dados de dados. No entanto, um invasor com acesso a instantâneos do banco de dados de dados e informações de query está além do escopo das garantias de segurança do Queryable Encryption. Isso é especialmente verdadeiro para queries de intervalo, mesmo que apenas um pequeno número de transcrições ou registros de query seja recuperado. 6.1Consulte: Intervalo de Queries no Modelo Persistente no whitepaper de visão geral para obter detalhes.
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?
várias plataformas
MedcoMD usa os seguintes mecanismos de segurança para satisfazer seus casos de uso e proteger contra a divulgação de dados médicos sensíveis:
Criptografia de transporte (TLS/SSL) para proteger os dados enquanto trafegam pela rede.
Criptografia em repouso para proteger contra a liberação de dados por meio da leitura de arquivos do banco de dados ou de backup.
Controle de acesso com base em função para limitar o acesso dos usuários de banco de dados às coleções necessárias para que executem suas tarefas.
Criptografia de campos confidenciais com Queryable Encryption para atender aos seguintes casos de uso e restrições:
Evite a leitura de dados da memória do servidor, pois os dados criptografados com Queryable Encryption nunca estão no servidor do banco de dados de forma não criptografada.
Permita que os recepcionistas verifiquem a identidade dos pacientes e evite a divulgação acidental de dados confidenciais na tela pública do recepcionista, fornecendo aos recepcionistas um cliente que não esteja habilitado para Queryable Encryption.
Permita que os profissionais visualizem dados confidenciais de forma privada em seus consultórios, fornecendo aos consultas um cliente habilitado para Queryable Encryption.
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.