Menu Docs

Página inicial do DocsDesenvolver aplicaçõesManual do MongoDB

Criptografia em repouso

Nesta página

  • Mecanismo de armazenamento criptografado
  • Criptografia em nível de aplicativo

A criptografia em repouso, quando usada em conjunto com a criptografia de transporte e as boas políticas de segurança que protegem contas, senhas e chaves de criptografia relevantes, pode ajudar a garantir a conformidade com os padrões de segurança e privacidade, incluindo HIPAA, PCI-DSS e FERPA.

Observação

Funcionalidade de empresas

Disponível apenas no MongoDB Enterprise.

Importante

Disponível apenas para o WiredTiger Storage Engine.

MongoDB Enterprise 3.2 introduz uma opção de criptografia nativa para o mecanismo de armazenamento WiredTiger. Este recurso permite que o MongoDB criptografe arquivos de dados de forma que apenas as partes com a chave de descriptografia possam decodificar e ler os dados.

Observação

Alterado na versão 4.0

O MongoDB Enterprise no Windows não é mais compatível com AES256-GCM como uma cifra de bloco para criptografia em repouso. Esse uso é compatível apenas com Linux.

Se a criptografia estiver ativada, o modo de criptografia padrão que o MongoDB Enterprise usa é o AES256-CBC (ou o Advanced Encryption Standard de 256 bits no modo Cipher Block Chaining) via OpenSSL. O AES-256 usa uma chave simétrica, ou seja, a mesma chave para criptografar e descriptografar texto. O MongoDB Enterprise para Linux também oferece suporte à criptografia autenticada AES256-GCM (ou Advanced Encryption Standard de 256 bits no modo Galois/Counter).

O Mecanismo de Armazenamento Criptografado usa o provedor de criptografia certificado do sistema operacional subjacente para executar operações criptográficas. Por exemplo, uma instalação MongoDB em um sistema operacional Linux usa o módulo OpenSSL libcrypto FIPS-140.

Para executar MongoDB em um modo compatível com FIP:

  1. Configure o sistema operacional para ser executado no modo de aplicação de FIPS.

  2. Configure o MongoDB para habilitar a configuração do net.tls.FIPSMode.

  3. Reinicie o mongod ou mongos.

  4. Verifique o arquivo de log do servidor para confirmar se o modo FIPS está habilitado. Se o modo FIPS estiver habilitado, a mensagem FIPS 140-2 mode activated será exibida no arquivo de log.

Para obter mais informações, consulte Configurar MongoDB para FIPS.

Observação

Backup do AES256-GCM e do sistema de arquivos

Paramecanismos de armazenamento criptografado que usam o modo de criptografia AES256-GCM , AES256-GCM exige que cada processo use um valor de bloco contador exclusivo com a chave.

Para mecanismo de armazenamento criptografado configurado com cifra AES256-GCM :

  • Restauração a partir de um hot backup
    A partir da versão 4.2, se você restaurar a partir de arquivos obtidos via backup "quente" (ou seja, o mongod está em execução), o MongoDB pode detectar chaves "sujas" na inicialização e rolar automaticamente a chave do banco de dados para evitar a reutilização IV (Initialization Vector).
  • Restaurando a partir do Cold Backup

    No entanto, se você restaurar a partir de arquivos obtidos via backup "frio" (ou seja, o mongod não está em execução), o MongoDB não poderá detectar chaves "sujas" na inicialização, e a reutilização do IV anulará as garantias de confidencialidade e integridade.

    A partir do 4,2, para evitar a reutilização das chaves após restaurar de um snapshot de sistema de arquivos frio, o MongoDB adiciona uma nova opção de linha de comando --eseDatabaseKeyRollover. Quando iniciada com a opção --eseDatabaseKeyRollover, a instância mongod rola as chaves de banco de dados configuradas com AES256-GCM cifra e sai.

Dica

  • Em geral, se estiver usando backups baseados em sistema de arquivos para o MongoDB Enterprise 4.2+, use o recurso de backup "hot", se possível.

  • Para as versões 4.0 e anteriores do MongoDB Enterprise, se você usar AES256-GCM modo de criptografia, não faça cópias de seus arquivos de dados ou restaure a partir de snapshots do sistema de arquivos ("quente" ou "frio").

O processo de criptografia de dados inclui:

  • Gerando uma chave mestre.

  • Gerando chaves para cada banco de dados.

  • Criptografando dados com as chaves do banco de dados.

  • Criptografando as chaves do banco de dados com a chave mestre.

A criptografia ocorre de forma transparente na camada de armazenamento, ou seja, todos os arquivos de dados são totalmente criptografados a partir de uma perspectiva do sistema de arquivos, e os dados só existem em um estado não criptografado na memória e durante a transmissão.

Para criptografar todo o tráfego de rede do MongoDB, você pode usar TLS/SSL (Transport Layer Security/Secure Sockets Layer). Consulte Configurar mongod e mongos para TLS/SSL e Configuração TLS/SSL para Clientes.

Importante

O gerenciamento seguro das chaves de criptografia é fundamental.

As chaves do banco de dados são internas ao servidor e só são paginadas em disco em formato criptografado. O MongoDB nunca pagina a chave mestra para o disco em nenhuma circunstância.

Somente a chave mestre é externa ao servidor (ou seja, separado dos dados e das chaves do banco de dados) e requer gerenciamento externo. Para gerenciar a chave mestre, o mecanismo de armazenamento criptografado do MongoDB oferece suporte a duas opções de gerenciamento de chaves:

  • Integração com um dispositivo de gerenciamento de chaves de terceiros por meio do Protocolo de interoperabilidade de gerenciamento de chaves (KMIP). Recomendado

    Observação

    Para uma integração com um dispositivo de gerenciamento de chave de terceiros usando o KMIP, você deve permitir as seguintes operações de KMIP:

    • Criar (operation_create)

    • Obter (operation_get)

    • Ativar (operation_activate)

  • Gerenciamento de chaves locais por meio de um arquivo-chave.

Para configurar o MongoDB para criptografia e usar uma das duas opções de gerenciamento de chaves, consulte Configurar criptografia.

A criptografia não faz parte da replicação:

  • As chaves mestres e as chaves do banco de dados não são replicadas, e

  • Os dados não são criptografados de forma nativa pela rede.

Embora você possa reutilizar a mesma chave para os nós, o MongoDB recomenda o uso de chaves individuais para cada nó, bem como o uso de criptografia de transporte.

Para obter detalhes, consulte Rotacionar chaves de encriptação.

Disponível apenas no MongoDB Enterprise.

A partir do MongoDB 6.0 Enterprise, é possível gerenciar com segurança as chaves para criptografar o log de auditoria do MongoDB usando um servidor Protocolo de interoperabilidade de gerenciamento de chaves (KMIP) externo.

O KMIP simplifica o gerenciamento de chaves criptográficas e elimina o uso de processos de gerenciamento de chaves não padrão.

A versão do protocolo KMIP padrão é 1.2. Você pode configurar o MongoDB para usar a versão KMIP 1.0 ou 1.1 no arquivo de configuração do servidor MongoDB.

Para usar um servidor KMIP com criptografia de log de auditoria, defina estas configurações e parâmetros:

Para testar a criptografia do registro de auditoria, você também pode utilizar a configuração do auditLog.localAuditKeyFile.

A partir do MongoDB 6.0, se você precisar fazer o downgrade para uma versão anterior do MongoDB, primeiro desabilite a criptografia de log de auditoria removendo auditLog.auditEncryptionKeyIdentifier ou auditLog.localAuditKeyFile. Os registros de auditorias criptografados existentes permanecem criptografados e você pode manter qualquer procedimento que você desenvolveu para armazenamento e processamento de registros criptografados.

Observação

Para a criptografia do registro de auditoria, o destino do registro de auditoria deve ser um arquivo. syslog não pode ser usado como destino.

Esta seção se aplica se você não estiver usando um servidor de Protocolo de Interoperabilidade de Gerenciamento de Chaves (KMIP) externo para gerenciar chaves para criptografar o log de auditoria, como mostrado na seção anterior.

O arquivo de registro de auditoria não é criptografado como parte do mecanismo de armazenamento criptografado do MongoDB. Um mongod em execução com log pode gerar informações potencialmente confidenciais para arquivos de log como parte de operações normais, dependendo do detalhamento do log configurado.

Use a configuração security.redactClientLogData para evitar que informações potencialmente confidenciais entrem no log do processo mongod. Configurar o redactClientLogData reduz os detalhes no log e pode complicar o diagnóstico de log.

Consulte a entrada do manual de redação de registros para obter mais informações.

O Application Level Encryption fornece criptografia por campo ou por documento dentro da camada de aplicativo.

Novo na versão 4.2: os drivers da série 4.2 do MongoDB fornecem um framework de criptografia no nível do campo do lado do cliente. Para obter mais informações, consulte Criptografia no nível do campo do lado do cliente.

Para criptografar documentos completos, escrever rotinas de criptografia e descriptografia personalizadas ou usar uma solução comercial.

Para obter uma lista dos parceiros certificados da MongoDB, consulte a Lista de parceiros.

← Instalar libmongocrypt