Planeje sua configuração de TLS para implantações autogerenciadas

Criptografia entre nós

All TLS-enabled deployments encrypt connections between nodes. You can also enable intra-cluster mTLS, which requires nodes to present certificates to authenticate as clients during the TLS handshake. When a node accepts an incoming connection, it presents its server certificate so that the connecting party can verify its identity. When a node makes an outbound connection to another node, its behavior depends on whether you enable intra-cluster mTLS.

Use a tabela a seguir para determinar o que você precisa para cada modo de criptografia:

Sem o mTLS intracluster, os nós não apresentam um certificado para autenticar como cliente em conexões de saída. O nó de conexão verifica o certificado de servidor do nó de recebimento, mas o nó de recebimento não verifica a identidade do nó de conexão por meio do handshake TLS. Use essa configuração se você só puder obter certificados com um serverAuth EKU, como por meio de uma CA pública. Não é possível ativar a autenticação X.509 entre nós com essa configuração.

Com o mTLS intra-cluster, cada nó também apresenta um certificado em conexões de saída para outros nós, fornecendo verificação de identidade mútua. O mTLS intra-cluster é necessário para usar a autenticação de nó X.509. No entanto, como requer certificados com o EKU clientAuth, você deve ter acesso a uma CA privada.

Autenticação entre nós

Os nós do conjunto de réplicas se autenticam para confirmar que apenas nós autorizados participam da replicação. Por padrão, os conjuntos de réplicas habilitados para autorização usam autenticação de arquivo-chave entre nós. No entanto, se você habilitar o mTLS intra-cluster, poderá usar a autenticação de certificado X.509 em vez disso.

Use a tabela a seguir para determinar o que você precisa para cada modo de autenticação:

Se você usar a autenticação de arquivo de chave, todos os nós do conjunto de réplicas compartilharão um único segredo armazenado em um arquivo de chave. Cada nó prova sua associação apresentando o segredo compartilhado quando se conecta a outros nós no conjunto. Como todos os nós compartilham a mesma chave, se você quiser revogar o acesso de um nó individual, deverá substituir o arquivo de chave em todos os nós.

A autenticação X.509 usa o certificado de cluster de cada nó para verificar a associação. Como a troca de certificados ocorre durante o handshake TLS, a autenticação de nó X.509 requer mTLS intra-cluster para que os nós tenham verificação mútua de identidade. A identidade de certificado exclusiva de cada nó permite revogar o acesso de um nó individual revogando seu certificado, sem afetar outros nós. Além disso, a autenticação e a criptografia são estabelecidas juntas em um único handshake.

Os certificados de nó do cluster devem incluir atributos X.509 que os distinguem dos certificados de cliente regulares. Para saber mais sobre os atributos de certificado necessários, consulte Certificado X.509 do nó.

Criptografia entre cliente e servidor

When a client such as mongosh or a driver connects to a TLS-enabled mongod instance, the server presents its certificate to prove its identity, and the client verifies the certificate against a trusted CA certificate. The client also confirms that the server's hostname matches the certificate's hostname. If verification succeeds, TLS encrypts the connection between server and client.

Use a tabela a seguir para determinar o que você precisa para cada modo de criptografia:

Você pode definir allowConnectionsWithoutCertificates como true para permitir que o cliente se conecte sem enviar um certificado. A ativação disso impede que os usuários se conectem com certificados incorretos, como aqueles que incluem apenas o EKU serverAuth. O servidor criptografa a conexão e prova sua própria identidade para o cliente, mas o servidor não pode verificar a identidade do cliente por meio do handshake TLS. O cliente deve autenticar por meio de um método como o SCRAM.

Se o cliente apresentar seu próprio certificado durante o handshake, o servidor poderá verificar o certificado do cliente em relação a uma CA confiável. Isso estabelece TLS mútuo entre servidor e cliente. O cliente deve apresentar um certificado para habilitar a autenticação de cliente X.509 entre cliente e servidor.

Autenticação entre cliente e servidor

Depois de estabelecer a conexão TLS, os clientes devem se autenticar para acessar a implantação. Os clientes podem se autenticar de várias maneiras, mas este início rápido abrange SCRAM e autenticação X.509.

Use a tabela a seguir para determinar o que você precisa para cada modo de autenticação:

O MongoDB usa o SCRAM como o mecanismo de autenticação de cliente padrão. O cliente fornece um nome de usuário, senha e o banco de dados de autenticação, e o MongoDB verifica as credenciais em relação aos usuários no banco de dados especificado. O SCRAM não exige que o cliente apresente um certificado durante o handshake TLS.

A autenticação de cliente X.509 usa o certificado que o cliente apresenta durante a conexão. Depois que o TLS mútuo é estabelecido, o cliente se autentica no banco de dados $external usando o mecanismo MONGODB-X509 . O MongoDB mapeia o campo de assunto no certificado para um usuário no banco de dados $external .