Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/ / /

Autenticação interna/de associação autogerenciada

Nesta página

  • Arquivos-chave
  • x.509
  • Próximos passos

Você pode exigir que os nós deconjuntos de réplicas clusters fragmentados se autentiquem uns aos outros. Para a autenticação interna dos membros, MongoDB pode utilizarkeyfiles do ou x.509 certificados.

O método selecionado é usado para toda comunicação interna. Por exemplo, quando um cliente autentica para um mongos utilizando um dos mecanismos de autenticação suportados, o mongos então utiliza o método de autenticação interna configurado para conectar aos processos mongod exigidos.

Observação

Habilitar a autenticação interna também habilita a autorização do cliente.

Os keyfiles usam o mecanismo de autenticação de desafio e resposta SCRAM, em que os keyfiles contêm a senha compartilhada para os membros.

O comprimento de uma chave deve estar entre 6 e 1024 caracteres e só pode conter caracteres no conjunto base64. MongoDB remove caracteres de espaço em branco (por exemplo x0d, x09 e x20) para conveniência entre plataformas. Como resultado, as seguintes operações produzem chaves idênticas:

echo -e "mysecretkey" > key1
echo -e "my secret key" > key1
echo -e "my secret key\n" > key2
echo -e "my secret key" > key3
echo -e "my\r\nsecret\r\nkey\r\n" > key4

Os arquivos-chave para autenticação de associação interna usam o formato YAML para permitir várias chaves em um arquivo-chave. O formato YAML aceita:

  • Uma única string de chave (igual às versões anteriores)

  • Uma sequência de strings de chave

O formato YAML é compatível com os arquivos-chave de chave única existentes que usam o formato de arquivo de texto.

Por exemplo,

Se o arquivo de chave contiver uma única chave, você poderá especificar a string da chave com ou sem aspas:

my old secret key1

Você pode especificar várias strings de chave [1] como uma sequência de strings de chave (opcionalmente entre aspas):

- my old secret key1
- my new secret key2

A capacidade de especificar várias chaves em um arquivo permite a atualização contínua das chaves sem tempo de inatividade. Consulte Teclas de rotação para conjuntos de réplicas autogerenciados e Teclas de rotação para clusters fragmentados autogerenciados.

Todas as instâncias do mongod e mongos de um sistema devem compartilhar pelo menos uma chave comum.

Em sistemas UNIX, o arquivo-chave não deve ter permissões de grupo ou mundiais. Em sistemas Windows, as permissões do arquivo-chave não são verificadas.

Você deve armazenar o arquivo de chave em cada servidor hospedando o membro do conjunto de réplicas ou clusters fragmentados.

[1] Para o mecanismo de armazenamento criptografado do MongoDB, o keyfile usado para o gerenciamento local de chaves só pode conter uma única chave.

Para especificar o arquivo de chave, utilize a configuração security.keyFile ou opção de linha de comando --keyFile .

Para obter um exemplo de autenticação interna de keyfile, consulte Atualizar conjunto de réplicas autogerenciadas para autenticação de keyfile.

Os membros de um conjunto de réplicas ou cluster fragmentado podem usar x.509 certificados para autenticação interna em vez de usar keyfiles. Isso também é conhecido como TLS Mutual ou mTLS. MongoDB suporta x.509 autenticação de certificado para uso com uma conexão TLS/SSL segura.

Observação

O MongoDB desabilita o suporte para criptografia TLS 1.0 em sistemas em que o TLS 1.1+ está disponível.

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 a 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

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

Para um exemplo de x.509 autenticação interna, consulte Usar x.509 Certificado para Autenticação de Associação com MongoDB.

Para atualizar da autenticação interna do keyfile para x.509 autenticação interna, consulte Atualizar o MongoDB autogerenciado da autenticação de keyfile para x. Autenticação do 509 .

Voltar

Autorizar usuários