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

Criptografia entre nós

Todas as implantações habilitadas para TLS criptografam conexões entre nós. Você também pode habilitar o mTLS intra-cluster, que exige que os nós apresentem certificados para autenticar como clientes durante o handshake TLS. Quando um nó aceita uma conexão de entrada, ele apresenta seu certificado de servidor para que a parte que se conecta possa verificar sua identidade. Quando um nó faz uma conexão de saída com outro nó, seu comportamento depende se você habilita o mTLS intra-cluster.

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 nas 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 uma serverAuth EKU, como por meio de uma CA pública. Você não pode habilitar a509 autenticação X. entre nós com esta 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 mútua de identidade. O mTLS intra-cluster é necessário para usar a autenticação do nó X.509. No entanto, como isso exige certificados com a EKU clientAuth, você deve ter acesso a uma CA privada.

Autenticação entre nós

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

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 membros do conjunto de réplicas compartilharão um único segredo armazenado em um arquivo de chave. Cada nó comprova sua associação apresentam 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 utiliza 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 que você revogue o acesso de um nó individual revogando seu certificado, sem afetar outros nós. Além disso, autenticação e criptografia são estabelecidas juntas em um único handshake.

Os certificados de membros do cluster devem incluir509 atributos X. que os distinguem dos certificados de cliente regulares. Para saber mais sobre os atributos de certificado exigidos, consulte Certificado de Membro X..509

Criptografia entre cliente e servidor

Quando um cliente como mongosh ou um driver se conecta a uma mongod instância habilitada para TLS, o servidor apresenta seu certificado para provar sua identidade e o cliente verifica o certificado em relação a um certificado CA confiável. O cliente também confirma que o nome de host do servidor corresponde ao nome de host do certificado. Se a verificação for bem-sucedida, o TLS criptografará a conexão entre o servidor e o cliente.

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

Você allowConnectionsWithoutCertificates pode true configurar o para para permitir que o cliente se conecte sem enviar um certificado. Habilitar isso impede que os usuários se conectem com certificados incorretos, como aqueles que incluem apenas o serverAuth EKU. O servidor criptografa a conexão e comprova 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 um método como SCRAM.

Se o cliente apresentar seu próprio certificado durante a negociação, o servidor poderá verificar o certificado do cliente em relação a uma CA confiável. Isso estabelece um 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 autenticar para acessar o sistema. Os clientes podem autenticar de várias maneiras, mas este início rápido abrange a509 autenticação SCRAM e X..

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

O MongoDB usa SCRAM como o mecanismo de autenticação do 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 dos usuários no banco de dados especificado. O SCRAM não exige que o cliente apresente um certificado durante a negociação TLS.

A autenticação do 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 .