Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/ / / /

Características

Nesta página

  • Visão geral
  • Criptografia no nível de campo do cliente
  • Outros mecanismos de segurança
  • Controle de acesso com base em função
  • Criptografia em descanso
  • Criptografia de transporte (TLS/SSL)
  • Comparação de recursos
  • Cenário
  • várias plataformas
  • Saiba mais

Nesta página, você pode aprender sobre os benefícios de segurança da criptografia no nível do campo do lado do cliente (CSFLE) e como o CSFLE 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 do CSFLE na proteção de seus dados.

A criptografia no nível de campo do lado do cliente (CSFLE) é um recurso do MongoDB que permite que um aplicativo cliente criptografe dados antes de transportá-los pela rede. 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. O CSFLE 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

Enquanto todos os clientes têm acesso aos campos de dados não confidenciais, somente clientes CSFLE configurados adequadamente podem ler e gravar os campos de dados criptografados.

Importante

Sistema de gerenciamento remoto de chaves

Ao usar o CSFLE em produção, você deve usar um sistema de gerenciamento de chaves (KMS) remoto para armazenar sua chave de criptografia.

Para visualizar um guia passo a passo que demonstra como usar um KMS remoto com CSFLE, consulte Tutoriais do .

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.

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)

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.

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.

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

Para saber mais sobre o Queryable Encryption, consulte Recursos do Queryable Encryption.

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.

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

O cenário fictício a seguir demonstra o valor da criptografia no nível do campo do lado do cliente (CSFLE) na proteção dos dados do seu aplicativo e como o CSFLE interage com o outro mecanismo de segurança discutido neste guia.

Nesse cenário, protegemos dados confidenciais em um sistema de gerenciamento de consultas médicas que armazena informações pessoais de pacientes, informações de seguros e registros médicas para uma empresa fictício, a MedicoMD. Nenhum dos dados dos pacientes é público, e dados específicos, como o número do seguro social (SSN, um ID emitido pelo governo dos EUA), o número da apólice de seguro e as medições de sinais normais são particularmente sensíveis e sujeitos à conformidade com a privacidade. É importante para a empresa e para o doente que os dados sejam mantidos em privado e seguros.

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

  • Os consultas usam o sistema para acessar os registros médicas dos pacientes, informações sobre seguros e adicionar novas medições de sinais fatais.

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

  • Os refeitórios podem visualizar o provedor da apólice de seguro de um cliente, mas não o número da apólice.

  • 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?

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.

  • Criptografando campos confidenciais com CSFLE para satisfazer os seguintes casos de uso e restrições:

    • Impedir a leitura de dados do servidor da memória do servidor, pois os dados criptografados CSFLE nunca estão no reconhecimento de data center do servidor de forma não criptografada.

    • Permita que os receptadores verifiquem as identidades dos pacientes e evite a abertura acidental de dados confidenciais em uma tela visível publicamente de um requisitor, fornecendo aos receptadores um cliente que não é habilitado para CSFLE.

    • Permita que os métodos visualizem dados confidenciais de forma privada em seus consultórios, fornecendo aos pacientes um cliente habilitado para CSFLE.

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 o CSFLE, consulte o Início Rápido.

Voltar

Criptografia no nível de campo do cliente