Como usar a criptografia para proteger seus dados do MongoDB

A segurança do banco de dados é um fator importante a ser considerado para qualquer aplicativo que envolva dados altamente confidenciais, como relatórios financeiros e de saúde. A proteção de dados pode ser alcançada por meio de criptografia em diferentes níveis, desde o próprio aplicativo até os arquivos que contêm os dados.

Como o MongoDB é um banco de dados não relacional, não é necessário definir colunas antes de inserir os dados; e, portanto, documentos na mesma coleção podem ter campos diferentes um do outro.

Por outro lado, para o SQL DBMS, deve-se definir colunas para os dados, portanto, todas as linhas têm as mesmas colunas. Pode-se decidir criptografar colunas individuais, arquivo de banco de dados inteiro ou dados do aplicativo antes de se envolver no processo do banco de dados.

A criptografia de colunas individuais é a mais preferida, pois é mais barata e menos dados são criptografados, melhorando assim a latência. Em geral, o desempenho geral impacta como resultado da criptografia.

Para NoSQL DBMS, essa abordagem, no entanto, não será a melhor. Considerando que nem todos os documentos podem conter todos os campos que você deseja usar em sua criptografia, a criptografia em nível de coluna não pode ser realizada.

A criptografia de dados no nível do aplicativo é bastante cara e difícil de implementar. Portanto, permanecemos com a opção de criptografar dados no nível do banco de dados.

O MongoDB fornece criptografia nativa que não exige que se pague um custo extra para proteger seus dados confidenciais.

Criptografia de dados no MongoDB

Qualquer operação de banco de dados envolve um desses dois formulários de dados, dados em repouso ou dados em movimento.

Os dados em movimento são um fluxo de dados que se movem através de qualquer tipo de rede, enquanto os dados em repouso são estáticos, portanto, não se movem para lugar algum.

Ambos os dois tipos de dados são propensos a interferência externa por usuários anônimos, a menos que a criptografia esteja envolvida. O processo de criptografia envolve:

Gerando uma chave mestra para todo o banco de dados
Gerando chaves exclusivas para cada banco de dados
Criptografando seus dados com as chaves de banco de dados que você gerou
Criptografando todo o banco de dados com a chave mestra

Criptografia de dados em trânsito

Os dados são transacionados entre o MongoDB e o aplicativo do servidor de duas maneiras, ou seja, por meio do Transport Layer Security (TLS) e do Secure Socket Layer (SSL).

Esses dois são os protocolos de criptografia mais usados para proteger dados enviados e recebidos entre dois sistemas. Basicamente, o conceito é criptografar conexões com as instâncias mongod e mongos, de modo que o tráfego de rede seja legível apenas pelo cliente pretendido.

TLS/SSL são usados no MongoDB com alguns certificados como arquivos PEM que são emitidos pela autoridade de certificação ou podem ser um certificado autoassinado. Este último tem uma limitação em que, embora o canal de comunicação seja criptografado, sempre não há validação contra a identidade do servidor, portanto, vulnerável a ataques externos no meio do caminho. Portanto, é aconselhável usar certificados de autoridade confiável que permitem que os drivers do MongoDB também verifiquem a identidade do servidor.

Além da criptografia, o TLS/SSL pode ser usado na autenticação do cliente e auths internas de membros de conjuntos de réplicas e clusters fragmentados por meio dos certificados.

Configuração de TLS/SSL para clientes

Existem várias configurações de opção TLS/SSL que podem ser usadas na configuração desses protocolos.

Por exemplo, se você quiser se conectar a uma instância do Mongod usando criptografia, inicie sua instância como,

mongo --ssl --host example.com --sslCAFile /etc/ssl/ca.pem

--ssl habilita a conexão TLS/SSL.

--sslCAFile especifica o arquivo pem da autoridade de certificação (CA) para verificação do certificado apresentado pelo mongod ou pelos mongos. O shell do Mongo verificará, portanto, o certificado emitido pela instância do mongod em relação ao arquivo CA especificado e ao nome do host.

Você também pode querer conectar a instância do MongoDB que requer um certificado de cliente. Usamos o exemplo de código abaixo

mongo --ssl --host hostname.example.com --sslPEMKeyFile /etc/ssl/client.pem --sslCAFile /etc/ssl/ca.pem

A opção --sslPEMKeyFile especifica o arquivo .pem que contém o certificado do shell do mongo e uma chave para apresentar ao mongod ou à instância do mongo. Durante o processo de conexão:

O shell do mongo verificará se o certificado é da Autoridade de Certificação especificada que é (--sslCAFile) e, caso contrário, o shell não conseguirá se conectar.

Em segundo lugar, o shell também verificará se o nome do host especificado na opção --host corresponde ao SAN/CN no certificado apresentado pelo mongod ou mongos. Se esse nome de host não corresponder a nenhum dos dois, a conexão falhará.

Se você não quiser usar certificados autoassinados, deverá garantir que a rede de conexão seja confiável.

Além disso, você precisa reduzir a exposição da chave privada, especialmente quando estão envolvidos conjuntos de réplicas/cluster fragmentado. Isso pode ser feito usando certificados diferentes em servidores diferentes.

As opções adicionais que podem ser usadas nas conexões são:

requireSSL:isso restringirá cada servidor a usar apenas conexões criptografadas por TLS/SSL.

--sslAllowConnectionsWithoutCertificates:Permite a validação se apenas o cliente apresentar um certificado, caso contrário, se não houver certificado, o cliente ainda estará conectado em modo criptografado. Por exemplo:

mongod --sslMode requireSSL --sslAllowConnectionsWithoutCertificates --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

sslDisabledProtocols:esta opção impede que os servidores aceitem conexões de entrada que utilizam protocolos específicos. Isso pode ser feito com:

mongod --sslMode requireSSL --sslDisabledProtocols TLS1_0,TLS1_1 --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

Criptografia de dados em repouso

A partir da versão 3.2, o MongoDB introduziu uma opção de criptografia nativa para o mecanismo de armazenamento WiredTiger. O acesso aos dados neste armazenamento por terceiros só pode ser obtido por meio de uma chave de descriptografia para decodificar os dados em um formato legível.

O algoritmo de criptografia de criptografia comumente usado no MongoDB é o AES256-GCM. Ele usa a mesma chave secreta para criptografar e descriptografar dados. A criptografia pode ser ativada usando o modo FIPS, garantindo assim que a criptografia atenda ao mais alto padrão e conformidade.

Todos os arquivos de banco de dados são criptografados usando a criptografia de dados transparente (TDE) no nível de armazenamento.

Sempre que um arquivo é criptografado, uma chave de criptografia privada exclusiva é gerada e é bom entender como essas chaves são gerenciadas e armazenadas. Todas as chaves de banco de dados geradas são posteriormente criptografadas com uma chave mestra.

A diferença entre as chaves do banco de dados e a chave mestra é que as chaves do banco de dados podem ser armazenadas junto com os próprios dados criptografados, mas para a chave mestra, o MongoDB aconselha que ela seja armazenada em um servidor diferente dos dados criptografados, como a chave corporativa de terceiros soluções de gestão.

Com dados replicados, os critérios de criptografia não são compartilhados com os outros nós, pois os dados não são criptografados nativamente pela rede. Pode-se reutilizar a mesma chave para os nós, mas a melhor prática é usar chaves individuais exclusivas para cada nó.

Chaves de criptografia rotativas

A chave gerenciada usada para descriptografar dados confidenciais deve ser alternada ou substituída pelo menos uma vez por ano. Existem duas opções no MongoDB para realizar a rotação.

Rotação principal do KMIP

Neste caso, apenas a chave mestra é alterada, pois é gerenciada externamente. O processo para girar a chave é conforme descrito abaixo.

A chave mestra para os membros secundários no conjunto de réplicas é girada uma de cada vez. Ou seja

mongod --enableEncryption --kmipRotateMasterKey \ --kmipServerName <KMIP Server HostName> \--kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

Após a conclusão do processo, o mongod será encerrado e você precisará reiniciar o secundário sem o parâmetro kmipRotateMasterKey

mongod --enableEncryption --kmipServerName <KMIP Server HostName> \
  --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

O primário do conjunto de réplicas é reduzido:
Usando o método rs.stepDown(), o primário é desativado, forçando a eleição de um novo primário.
Verifique o status dos nós usando o método rs.status() e se o primário indicar que foi reduzido, gire sua chave mestra. Reinicie o membro rebaixado incluindo a opção kmipRotateMasterKey.
```
mongod --enableEncryption --kmipRotateMasterKey \
  --kmipServerName <KMIP Server HostName> \
  --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem
```

Registro

O MongoDB sempre trabalha com um arquivo de log para registrar algum status ou informações especificadas em intervalos diferentes.

No entanto, o arquivo de log não é criptografado como parte do mecanismo de armazenamento. Isso representa um risco, pois uma instância do mongod em execução com log pode gerar dados potencialmente confidenciais para os arquivos de log apenas como parte do log normal.

A partir do MongoDB versão 3.4, há a configuração security.redactClientLogData que impede que dados potencialmente confidenciais sejam registrados no log do processo do mongod. No entanto, esta opção pode complicar o diagnóstico de log.
Vários noves Torne-se um DBA do MongoDB - Trazendo o MongoDB para a produçãoSaiba mais sobre o que você precisa saber para implantar, monitorar, gerenciar e dimensionar o MongoDBBaixe gratuitamente

Desempenho de criptografia no MongoDB

A criptografia em algum ponto resulta em maior latência, portanto, degradando o desempenho de um banco de dados. Este é geralmente o caso quando um grande volume de documentos está envolvido.

Criptografia e descriptografia exigem mais recursos, portanto, é importante entender esse relacionamento para ajustar o planejamento de capacidade de acordo.

Em relação aos testes do MongoDB, um mecanismo de armazenamento criptografado experimentará uma latência entre 10% a 20% na carga mais alta. Isso geralmente acontece quando um usuário grava uma grande quantidade de dados no banco de dados, resultando em desempenho reduzido. Para operações de leitura, a degradação do desempenho é insignificante, cerca de 5 a 10%.

Para uma melhor prática de criptografia no MongoDB, o mecanismo de armazenamento WiredTiger é o mais preferido devido ao seu alto desempenho, segurança e escalabilidade. Além disso, otimiza a criptografia de arquivos de banco de dados para o nível de página, o que tem grande mérito, pois, se um usuário ler ou gravar dados no banco de dados criptografado, a operação de taxa de transferência será aplicada apenas à página na qual os dados estão armazenados, e não a todo o banco de dados. base de dados.

Isso reduzirá a quantidade de dados que precisarão ser criptografados e descriptografados para o processamento de um único dado.

Resumo

A segurança de dados para informações confidenciais é uma obrigação e há necessidade de protegê-las sem degradar o desempenho do sistema de banco de dados.

O MongoDB fornece procedimentos de criptografia nativos robustos que podem nos ajudar a proteger nossos dados tanto em repouso quanto em movimento. Além disso, os procedimentos de criptografia devem estar de acordo com os padrões estabelecidos por diferentes organizações.

O avançado mecanismo de armazenamento WiredTiger oferece uma opção melhor devido aos seus méritos associados, como alto desempenho, escalabilidade e segurança. Ao criptografar dados em conjuntos de réplicas, é uma boa prática usar chaves mestras diferentes para cada um, além de alterá-las pelo menos uma vez por ano.

No entanto, com a disponibilidade de opções de criptografia de terceiros, não há garantia de que sua implantação corresponderá a elas em termos de escalabilidade. Portanto, é bastante ponderado empregar criptografia em nível de banco de dados.