MongoDB.local SF, Jan 15: See the speaker lineup & ship your AI vision faster. Use WEB50 to save 50%
Find out more >
Menu Docs
Página inicial do Docs
/
Manual do banco de dados
/

x.509

O MongoDB suporta autenticação de certificado X.509 para autenticação de cliente e autenticação interna dos membros de conjuntos de réplicas e clusters fragmentados.

A autenticação de certificado x.509 requer uma conexão TLS/SSL segura.

Para uso em produção, seu MongoDB deployment deve usar certificados válidos gerados e assinados por uma autoridade de certificação. Você ou sua organização podem gerar e manter uma autoridade de certificação independente ou usar certificados gerados por fornecedores de TLS de terceiros. Obter e gerenciar certificados está além do escopo desta documentação.

Para autenticar em servidores, os clientes podem usar certificados X.509 em vez de nomes de usuário e senhas.

Requisitos de certificado do cliente:

  • Uma única Autoridade de Certificação (CA) deve emitir os certificados para o cliente e para o servidor.

  • Cada usuário único do MongoDB deve ter um certificado exclusivo.

  • O certificado X.509 não pode expirar.

    Observação

  • Os certificados do cliente devem conter os seguintes campos:

    keyUsage = digitalSignature
    extendedKeyUsage = clientAuth
  • Pelo menos um dos seguintes atributos do certificado do cliente deve ser diferente dos atributos dos certificados do servidor net.tls.clusterFile e net.tls.certificateKeyFile:

    • Organização (O)

    • Unidade organizacional (OU)

    • Componente de domínio (DC)

  • O subject de um certificado de cliente x.509, que contém o nome diferenciado (DN), deve ser diferente dos subjects dos certificados de membro x.509 . Se a implantação do MongoDB tiver tlsX509ClusterAuthDNOverride definido, o assunto do certificado de cliente x.509 não deve corresponder a esse valor.

    Importante

    Se o assunto do certificado 509 de um cliente X corresponder aos atributos O, OU e DC do certificado de nó X.509 (ou tlsX509ClusterAuthDNOverride, se definido) exatamente, a conexão do cliente será aceita, permissões completas são concedidas e uma mensagem de aviso aparece no registro.

    Somente certificados x509 de membros do cluster devem usar as mesmas combinações de atributos O, OU e DC.

Para autenticar com um certificado de cliente, você deve primeiro adicionar o subject do certificado de cliente como um usuário do MongoDB no banco de dados $external. O banco de dados $external é o banco de dados de autenticação do usuário.

Cada certificado exclusivo de cliente X.509 é para um usuário MongoDB . Você não pode usar um único certificado de cliente para autenticar mais de um usuário do MongoDB .

Para usar Sessões de cliente e garantias de consistência causal com usuários de autenticação $external (usuários Kerberos, LDAP ou X.509), os nomes de usuário não podem ter mais de 10k bytes.

A partir do MongoDB 5.0, mongod e mongos agora emitem um aviso de inicialização quando seus certificados não incluem um atributo Subject Alternative Name.

As seguintes plataformas não suportam validação de nome comum:

  • iOS 13 e superior

  • MacOS 10.15 e superior

  • Vá para 1,15 e superior

Os clientes que usam essas plataformas não se autenticarão em servidores MongoDB que usam certificados X.509 cujos nomes de host são especificados por atributos CommonName.

Para autenticação interna entre membros de clusters fragmentados e conjuntos de réplica, você pode utilizar certificados X.509 em vez de keyfiles.

Use certificados de membro para verificar a associação a um cluster fragmentado ou a um conjunto de réplicas. Os certificados de membro são armazenados em net.tls.clusterFile e net.tls.certificateKeyFile. Requisitos de certificado de membro:

  • Uma única CA (Certificate Authority, autoridade de certificação) deve emitir todos os certificados x.509 para os membros de um cluster fragmentado ou de um conjunto de réplicas.

  • O certificado x.509 não pode expirar.

    Observação

    O mongod / mongos registra um aviso na conexão se o certificado x.509 apresentado expirar dentro de 30 dias do horário do sistema host mongod/mongos.

  • O nome diferenciado (DN), encontrado no certificado de membro subject, deve especificar um valor não vazio para pelo menos um dos seguintes atributos:

    • a Organização (O)

    • a Unidade Organizacional (OU)

    • o componente de domínio (DC)

  • Em sistemas de vários clusters, cada cluster deve usar um certificado de membro X.509 diferente. Cada certificado deve ter valores exclusivos nos campos O, OU e DC Campos de nome distinto (DN).

    Se dois clusters tiverem certificados com os mesmos valores de DN, um servidor comprometido em um cluster poderá se autenticar como membro do outro.

  • Cada certificado de membro do agrupamento deve ter Os, OUs e DCs idênticos em seus certificados net.tls.clusterFile e net.tls.certificateKeyFile . Isso também se aplica ao valor tlsX509ClusterAuthDNOverride , se definido. A ordem dos atributos não importa.

    Aqui está um exemplo. Os dois DNs abaixo possuem especificações correspondentes para O e OU, e DC não é especificado.

    CN=host1,OU=Dept1,O=MongoDB,ST=NY,C=US
    C=US, ST=CA, O=MongoDB, OU=Dept1, CN=host2

    O exemplo a seguir está incorreto porque os DNs não correspondem. Um DN possui duas especificações OU e o outro possui apenas uma especificação OU .

    CN=host1,OU=Dept1,OU=Sales,O=MongoDB
    CN=host2,OU=Dept1,O=MongoDB
  • As entradas Nome comum (CN) ou uma das entradas nome alternativo do assunto (SAN) devem corresponder ao servidor para outros membros do cluster. A partir do MongoDB 4.2, ao comparar SANs, o MongoDB pode comparar nomes DNS ou endereços IP. Nas versões anteriores, o MongoDB compara apenas os nomes DNS.

    Por exemplo, os certificados para um cluster podem ter os seguintes subjects:

    subject= CN=<myhostname1>,OU=Dept1,O=MongoDB,ST=NY,C=US
    subject= CN=<myhostname2>,OU=Dept1,O=MongoDB,ST=NY,C=US
    subject= CN=<myhostname3>,OU=Dept1,O=MongoDB,ST=NY,C=US
  • Se o certificado utilizado como certificateKeyFile incluir extendedKeyUsage, o valor deverá incluir clientAuth ("Autenticação de cliente Web TLS") e serverAuth ("Autenticação de servidor Web TLS").

    extendedKeyUsage = clientAuth, serverAuth
  • Se o certificado utilizado como clusterFile incluir extendedKeyUsage, o valor deverá incluir clientAuth.

    extendedKeyUsage = clientAuth

Você pode usar TLS para autenticação interna entre cada membro do seu conjunto de réplicas (cada instância mongod) ou cluster fragmentado (cada instância mongod e mongos).

Para usar TLS para autenticação interna, use as seguintes configurações:

Importante

Se você definir --tlsMode como um valor diferente de disabled, o MongoDB usará o certificado especificado em net.tls.certificateKeyFile para a autenticação de servidor e cliente em conexões internas do conjunto de réplicas. Essa configuração de certificado se aplica independentemente da definição de security.clusterAuthMode como X.509.

As instâncias mongod e mongos usam seus arquivos de chave de certificado para provar sua identidade aos clientes, mas os arquivos de chave de certificado também podem ser usados para autenticação de associação. Se você não especificar um arquivo de cluster, os nós utilizarão seus arquivos de chave de certificado para autenticação de associação. Especifique o arquivo de chave de certificado com net.tls.certificateKeyFile ou --tlsCertificateKeyFile.

Para usar o arquivo de chave de certificado para autenticação de cliente e autenticação de associação, o certificado deve:

  • Omitir extendedKeyUsage ou

  • Especificar extendedKeyUsage = serverAuth, clientAuth

Voltar

Autenticar clientes

Nesta página