Desenvolver o MongoDB localmente com TLS
Avalie esse Tutorial
O MongoDB hospedado no Atlas está bem para desenvolvimento e apresenta certificados TLS totalmente válidos. Eu o uso junto com duas instalações locais da Community Edition. Mas uma conta de desenvolvimento gratuita do Atlas tem limites. Mesmo com uma conta paga, você não tem controle total de um sistema de nuvem do fornecedor; portanto, se seu objetivo final for o sistema local, você não poderá experimentar no Atlas com muitos detalhes de sistema. Portanto, os desenvolvedores podem optar por modelar a implantação em seu território inicial usando o Community Edition ou o Enterprise Advanced.
Se você pretende modelar a implantação de nuvem local ou de intranet, ativar o TLS torna o ambiente mais realista.
Em uma palavra, simplicidade. Para usar um certificado assinado por uma autoridade de certificação reconhecido internacionalmente, é necessário registrar um nome de domínio. Se a sua empresa mantém uma autoridade de certificação privada local (como EJBCA de código aberto ou PKI-as-a-service ), você só precisa entrar em contato com seu departamento de T.I. Caso contrário, uma cadeia de certificados autoassinada é uma escolha fácil. Esta é uma opção somente de desenvolvimento local. Lembre-se de que nenhuma instalação de produção deve apresentar uma cadeia de certificados autoassinada.
Se você estiver pronto para registrar seu nome de domínio, pode acessar o Let's Encrypt como uma opção de baixo impacto para o registro em uma autoridade de certificação genuína. Discutiremos o Let's Encrypt mais tarde neste artigo. Enquanto isso, pegaremos o caminho mais fácil e implementaremos uma cadeia de certificados autoassinada.
Observe que este artigo é apenas a posição do autor. Ele não representa a orientação oficial do MongoDB !
Você pode ter visto o gancho: "Somos profissionais — não tente fazer isso em casa?" Aqui temos a contrapositiva: "Só tente fazer isso em casa." Uma cadeia de certificados autoassinado apresenta vulnerabilidades extras, mesmo em contextos aparentemente de baixo risco, desde que haja a chance de "o Inimiga Interno". Se sua configuração de desenvolvimento envolver a transmissão de dados confidenciais para o MongoDB, mesmo dentro da empresa, um certificado autoassinado pode ser uma escolha ruim.
Durante anos, criei um certificado de servidor autoassinado sem uma autoridade de certificação de assinatura e o atribuí a uma instância do MongoDB Community Edition .
As preocupações de segurança mudou tudo isso. Uma atualização de versão menor do MongoDB que foi enviada sem aviso prévio arrancou o cobertor da minha configuração de desenvolvimento. O problema que documenta a alteração rápida do MongoDB é SERVER-72839, o servidor ignora a validação do certificado de par se nem CAFile nem clusterCAFile forem fornecidos, que você pode ler para obter os detalhes.
Atualmente, em vez de criar um certificado autoassinado, se estivermos seguindo o caminho autoassinado, devemos criar um certificado de autoridade de certificação autoassinada e assinar o certificado do servidor com esse certificado de autoridade de certificação.
Você pode pular esta seção se estiver bem informado sobre certificados SSL/TLS. Aqui, apresentamos uma visualização abreviada dos certificados de servidor e ignoramos muitos detalhes importantes que um especialista em segurança entende.
- Um certificado de servidor destina-se a provar que um servidor ao qual estamos nos conectando é realmente o servidor ao qual média nos conectar.
- Um certificado de servidor normalmente é assinado por uma autoridade de certificação que é procurada durante a conexão para validar o certificado do servidor . O certificado da autoridade de certificação pode ser raiz ou pode ser intermediário assinado novamente por um intermediário de nível superior ou pela própria raiz.
- Se for considerado que a cadeia completa foi assinada de forma criptograficamente válida, o certificado do servidor será aceito.
- A razão pela qual os certificados raiz (e, muitas vezes, os intermediários) são aceitos pelo cliente que tenta se conectar ao servidor é que eles estão presentes no armazenamento de confiança local do cliente, com a raiz apontando de volta para sua autoridade final no site da Internet mantido pelo autoridade que emite o certificado, que é o único local em que a chave privada do certificado raiz reside.
Em nossa cadeia autoassinada, o servidor terá:
- Um certificado de autoridade de certificação autoassinado.
- A chave privada do certificado de autoridade de certificação autoassinado.
- Um certificado de servidor assinado pelo certificado de autoridade de certificação autoassinado.
- A chave privada deste certificado de servidor .
Em seguida, indicaremos a localização dessas entidades na configuração do MongoDB Community Edition . Também forneceremos à nossa conexão cliente :
- O certificado do servidor e sua chave privada.
- Nunca, com relação a um certificado de servidor assinado autenticamente, estaremos de acordo com a chave privada do certificado de servidor !
- O certificado de autoridade de certificação raiz autoassinado (sem sua chave privada).
Depois disso, nosso cliente se conecta ao servidor da maneira indicada por este trecho de PHP orientado a objetos:
1 $mongodb_client = new MongoDB\Client($mongodb_uri, 2 [ 3 'tls' => true, 4 'tlsCAFile' => $mongodb_ca_cert_path, 5 'tlsCertificateKeyFile' => $mongodb_cert_path 6 ] 7 );
No trecho acima:
- O tlsCertificateKeyFile apontado pelo caminho é um .pem combinado do certificado do servidor e sua chave privada.
- O tlsCAFile apontado pelo caminho é o certificado de autoridade de certificação raiz autoassinado (sem sua chave privada).
O comando open source openssl está presente na maioria das plataformas razoáveis. Nós o usaremos para fabricar nossa cadeia de certificados autoassinadas.
1 # Creating self-signed CA cert and SAN cert for localhost 2 # aka mdbinstance.mydevelopment.net 3 #===================================================================================== 4 openssl req -x509 -nodes -sha256 -days 1825 -newkey rsa:4096 \ 5 -keyout rootCA.key -out rootCA.crt -subj="/CN=ca.mydevelopment.net" 6 openssl req -newkey rsa:4096 -keyout server.key -nodes \ 7 -out domain.csr -subj "/CN=server.mydevelopment.net" 8 openssl req -x509 -nodes -CA rootCA.crt -CAkey rootCA.key -in domain.csr \ 9 -out mdbinstance.mydevelopment.net.crt -days 3560 -nodes \ 10 -subj '/CN=<mdbinstance_mydevelopment_net>' -extensions san -config <( \ 11 echo '[req]'; \ 12 echo 'distinguished\_name=req'; \ 13 echo '[san]'; \ 14 echo 'subjectAltName=DNS:localhost,DNS:mdbinstance.mydevelopment.net') 15 cat rootCA.key rootCA.crt >rootCAcombined.pem 16 cat server.key mdbinstance.mydevelopment.net.crt >serverCert.pem
O servidor MongoDB precisará do caminho para:
- rootCAcombined.pem (o certificado CA combinado + chave privada).
- serverCert.pem (o certificado de servidor combinado + chave privada).
Seu aplicação precisará do caminho para:
- rootCA.crt (o certificado CA).
- serverCert.pem (o certificado de servidor combinado + chave privada).
Aqui está a chave net de mongod.conf. Nosso exemplo pressupõe que você esteja usando a porta 27017 e um bindIp de 0.0.0.0. Este exemplo é para uma instalação de desenvolvimento em um trecho de rede muito privado, já que deixamos o servidor MongoDB aceitando conexão de qualquer lugar.
1 # network interfaces 2 net: 3 port: 27017 4 bindIp: 0.0.0.0 5 tls: 6 mode: requireTLS 7 certificateKeyFile: /path/to/serverCert.pem 8 CAFile: /path/to/rootCAcombined.pem
Já mostramos acima a estratégia de conexão PHP.
1 mongosh --tls --tlsCAFile /path/to/rootCA.crt --tlsCertificateKeyFile /path/to/serverCert.pem 'mongodb://userid:password@hostname.domain'
Onde novamente:
- O tlsCertificateKeyFile apontado pelo caminho é um .pem combinado do certificado do servidor e sua chave privada.
- O tlsCAFile apontado pelo caminho é o certificado de autoridade de certificação raiz autoassinado (sem sua chave privada).
Observe que, ao formular uma string de conexão do Compass , os caminhos devem ser codificados em URL . Neste exemplo, as barras ( / ) dos caminhos para os arquivos de certificado armazenados localmente no cliente devem ser convertidas para %2F.
1 mongodb://userid:password@hostname.domain/?directConnection=true&tls=true&tlsCAFile=%2Fpath%2Fto%2FrootCA.crt&tlsCertificateKeyFile=%2Fpath%2Fto%2Fserver_certificate.pem
Onde novamente:
- O tlsCertificateKeyFile apontado pelo caminho é um .pem combinado do certificado do servidor e sua chave privada.
- O tlsCAFile apontado pelo caminho é o certificado de autoridade de certificação raiz autoassinado (sem sua chave privada).
Se você tem um nome de domínio registrado e deseja trabalhar com uma autoridade de certificação genuína, uma opção gratuita é Let's Encrypt. Visite o website e siga as instruções para obter um certificado de servidor para a sua instalação.
Certifique-se de que os certificados CA raiz e intermediário Vamos Criptografar fazem parte do armazenamento confiável do sistema operacional para o servidor e para qualquer cliente.
Obtenha as instruções completas para habilitar o TLS e leia mais sobre como configurar o mongod e o mongos para TLS/SSL. A resposta curta no contexto deste artigo é que a subchave TLS da chave de rede no arquivo mongod.conf deve ter a seguinte aparência:
1 net: 2 tls: 3 mode: requireTLS 4 certificateKeyFile: /etc/ssl/mongodb.pem
Onde mongodb.pem é o certificado + chave combinado do servidor .
Lembre-se quando mencionamos simplicidade no início deste artigo? A emissão automatizada de certificados Let's Encrypt envolve o protocolo ACME. Esse ambiente de gerenciamento automático de certificados tem várias implementações entre as quais você deve escolher. As implementações de ACME foram objeto de alguns CVEs, por exemplo, [1,2,3]. Você pode ver por que alguns optam por adiar essa complexidade até a produção.
- Uma cadeia de certificados autoassinada é uma escolha sensata para uma instalação realista de desenvolvimento local em um ambiente razoável "seguro".
- Uma cadeia de certificados autoassinada nunca deve ser implantada em produção.
- Uma cadeia de certificados autoassinado nunca deve ser implantada em desenvolvimento se o desenvolvimento ou o teste exercer dados sensíveis.
- Uma autoridade de certificação local empresarial representa uma alternativa importante a uma cadeia de certificados manual e autoassinada, como apresentamos aqui.
- Se você tem um nome DNS e está pronto para uma autoridade de certificação genuína, o Let's Encrypt é uma boa entrada.
- O MongoDB Community Edition apresenta opções de configuração flexíveis para modelar cenários de implementação, como vimos neste artigo.
Principais comentários nos fóruns
Ainda não há comentários sobre este artigo.
Avalie esse Tutorial