Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/
Segurança

x.509

Nesta página

  • Autoridade de certificação
  • Certificados de Cliente x.509
  • Certificados de Nó x.509

O MongoDB suporta autenticação de certificado x.509 para autenticação de clientes e autenticação interna dos nós de conjuntos de réplicas e clusters fragmentados.

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

Autoridade de certificação

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.

Certificados de Cliente x.509

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

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

    mongod / mongos registra um aviso na conexão se o certificado x.509 apresentado expirar dentro de 30 dias a partir da hora do sistema do host mongod/mongos.

  • 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)

    Observação

    Você também pode desabilitar o parâmetro enforceUserClusterSeparation durante a inicialização para desabilitar automaticamente a verificação do O/OU/DC . Isto permite que certificados de membro autentiquem-se como usuários armazenados no banco de banco de dados do $external .

  • 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 de um certificado x.509 do cliente corresponder aos atributos O, OU e DC do certificado x.509 do membro (ou tlsX509ClusterAuthDNOverride, se definido) exatamente, a conexão do cliente será aceita, todas as permissões serão concedidas e uma mensagem de aviso será exibida no registro.

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

Usuário do MongoDB e $external banco de dados

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 de cliente x.509 exclusivo é 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 Client Sessions e Causal Consistency Guarantees 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.

Aviso de inicialização do certificado de conexão TLS X509

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.

Certificados de Nó x.509

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

Requisitos de certificado de membro

Use certificados de membro para verificar a associação a um cluster fragmentado ou a um conjunto de réplicas. Os caminhos do arquivo de certificado do nó são configurados com as opções net.tls.clusterFile e net.tls.certificateKeyFile. Os nós têm os seguintes requisitos de configuração:

  • A configuração do membro do cluster deve especificar um valor não vazio para pelo menos um dos atributos utilizados para autenticação. Por padrão, o MongoDB aceita:

    • a Organização (O)

    • a Unidade Organizacional (OU)

    • o componente de domínio (DC)

    Você pode especificar atributos alternativos para utilizar para autenticação configurando net.tls.clusterAuthX509.extensionValue.

  • A configuração do membro do cluster deve incluir o mesmo net.tls.clusterAuthX509.attributes e utilizar valores correspondentes. A ordem dos atributos não importa. O exemplo a seguir define O e OU, mas não DC:

    net:
      tls:
        clusterAuthX509:
          attributes: O=MongoDB, OU=MongoDB Server

Observação

Se você desabilitar o parâmetro enforceUserClusterSeparation , os seguintes comportamentos se aplicarão:

  • A verificação O/OU/DC estará desativada se clusterAuthMode estiver keyFile no seu arquivo de configuração. Isto permite que clientes que possuem certificados de membro se autentiquem como usuários armazenados no banco de dados $external .

  • O servidor não iniciará se clusterAuthMode não estiver keyFile em seu arquivo de configuração.

Se você definir o parâmetro enforceUserClusterSeparation como false, o servidor não fará distinção entre certificados de cliente, que os aplicativos usam para autenticar, e certificados intra-cluster, que têm acesso privilegiado. Isso não terá efeito se o seu clusterAuthMode for keyFile. No entanto, se o seu clusterAuthMode for x509, os certificados de usuário que usam o esquema permitido serão confundidos com certificados de cluster e concedidos acesso privilegiado.

Seus certificados existentes receberão privilégios internos se você fizer o seguinte:

  1. Crie um usuário, com um nome permitido por este parâmetro.

  2. Configure o parâmetro enforceUserClusterSeparation para false.

  3. Defina clusterAuthMode como x509.

Você não deve atualizar de keyFile para x509 sem validar que removeu usuários com privilégios elevados que o sinalizador enforceUserClusterSeparation lhe permitido criar.

Para configurar o parâmetro enforceUserClusterSeparation para false, execute o seguinte comando durante a inicialização:

mongod --setParameter enforceUserClusterSeparation=false

Os certificados têm os seguintes requisitos:

  • 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.

  • Pelo menos uma das entradas de nome alternativo do assunto (SAN) deve corresponder ao nome de host do servidor usado por outros membros do cluster. Ao comparar SANs, o MongoDB pode comparar nomes DNS ou endereços IP.

    Se você não especificar subjectAltName, o MongoDB compara o nome comum (CN). No entanto, esse uso de CN ficou obsoleto de acordo com RFC2818

  • 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

Configuração do MongoDB para Autenticação de Membros

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:

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

Próximo

Autenticar clientes