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 conectada possa verificar sua identidade. Quando um nó faz uma conexão de saída para outro nó, seu comportamento depende de você habilitar o mTLS intra-cluster.

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

Sem mTLS intra-cluster, 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 do 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 esta configuração se você só puder obter certificados com um serverAuth EKU, como por meio de uma CA pública. Você não pode habilitar a autenticação X.509 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 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

Quando um cliente como ou um driver se conecta a mongosh uma mongod instância de 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ê 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 .