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

Requisitos principais

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

Formato de arquivo-chave

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,

my old secret key1

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

Configuração do MongoDB para arquivo-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.

Requisitos de certificado de membro

Os certificados de membro que você usa para verificar a associação a um cluster fragmentado ou a um conjunto de réplicas (net.tls.clusterFile, se especificado, e net.tls.certificateKeyFile) devem ter as seguintes propriedades:

• Uma única Autoridade de Certificação (CA) deve emitir todas as x.509 certificados para os membros de um cluster fragmentado ou de um conjunto de réplicas.

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

• Os atributos da Organização (O 's), os atributos da Unidade organizacional (OU 's) e os componentes de domínio (DC 's) devem corresponder aos dos certificados net.tls.clusterFile e net.tls.certificateKeyFile para o outros membros do cluster (ou o valor tlsX509ClusterAuthDNOverride , se definido).

  Para corresponder, o certificado deve corresponder a todas as especificações desses atributos, mesmo a não especificação desses atributos. A ordem dos atributos não importa.

  No exemplo a seguir, os dois DN contêm especificações correspondentes para O, OU , bem como a não especificação do atributo DC .

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

  No entanto, os dois DN a seguir contêm uma incompatibilidade para o atributo OU , pois um contém duas especificações OU e o outro, apenas uma especificação.

  CN=host1,OU=Dept1,OU=Sales,O=MongoDB
  CN=host2,OU=Dept1,O=MongoDB

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

• 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 de um cluster podem ter os seguintes assuntos:

  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

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

  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. Consulte a página Avisos de expiração dos certificados x.509 para obter mais informações.

Configuração do MongoDB

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:

• security.clusterAuthMode ou --clusterAuthMode definido como x509

• net.tls.clusterFile ou --tlsClusterFile

As instâncias mongod e mongos usam o arquivo de chave de certificado para provar sua identidade aos clientes, mas ele também pode ser usado 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 do certificado com net.tls.certificateKeyFile ou --tlsCertificateKeyFile.

Para usar o certificate key file para autenticação de cliente e autenticação de associação, o certificado deve:

• Omitir extendedKeyUsage ou

• Especificar extendedKeyUsage = serverAuth, clientAuth